If there is an ebXML Architecture, it should not be agnostic to implementation. In other words, ebxml-bp should be specified over BPEL.
-matt
On Dec 22, 2003, at 12:27 PM, Duane Nickull wrote:
The fact is that the architecture needs to be updated if ebXML is to survive. The architecture is not, and likely will never, contain enough details that it can be implemented by itself. Implementors will need to rely heavily on the other TC's and some sort of process to map their requirements to the specific technologies needed for the SOA to work.
Architectures job is to help guide the requirements to a set of components, agnostic of the underlying technology (ie - BPEL vs. BPSS), as long as the technology does the job at hand.
Duane
David RR Webber wrote:
Duane,
As with all these items - its the input BEFORE that counts too - in making sure whatever transpires is most effectively leveraging
our limited resources.
I'd like to see OASIS and the Board themselves giving us guidance too. It needs to be thought through carefully - not
just a - great lets setup a committee!
As with any undertaking - careful planning up front makes
all the difference downstream - the best answer may not
be the first move you look at.
Cheers, DW.
----- Original Message ----- From: "Duane Nickull" <>
To: "David RR Webber" <>
Cc: <>
Sent: Monday, December 22, 2003 10:48 AM
Subject: Re: [regrep] V3.0 of ebXML for SOA
David:
Great - so we can count on your input to the group then?? (If and when approved)
Duane
David RR Webber wrote:
Duane raised some interesting points that I'd like to
focus on - in regard to - creating a new 3.0 release of
ebXML.
My biggest departure point is around the single
issue of a perscribed architecture as opposed to
a suggested architecture.
I believe that trying to force certain technology
components down peoples throats as "you must
have this to be ebXML compliant" is a serious
mistake - and especially in the area of payloads.
One of the reasons payloads were never perscribed
is exactly that.
The great strength of ebXML is that you can eat just
the pieces you need.
Next up - Registry and CAM components offer a
phased approach - that is based on sound business ROI
to discreet problems - around information alignment and
interoperablity.
Now - if people discover they really can save money and
work more efficiently by using your technology - you will
not have to force them to use it - they will come to it
themselves - and that's essential longterm.
So - again - its comes back to - articulating where those
ROI factors are - from a business-centric view - and that
is what we need to spend our effort on IMHO.
As for the SOA fit - yes - we do need to make sure that
SOA literature includes ebXML components as options
there - and so again - the value proposition needs to be
made at that level. But its not a case anymore from
the technology level of saying "you must have this to
have an SOA" - as UDDI found out - that dog does not
hunt.
Identify the business needs in a replicatable and formal
way - and the technology to accomplish that will then
make sense for people. Again the OASIS BCM TC is
focused there.
The platform for "ebXML Architecture" may actually be
a losing proposition - and instead just perpetuates the
notion of SOA v ebXML - whereas if the effort is
"ebXML V3.0 for SOA" I think you have a much much stronger message that
all the TCs can signup to - to make sure their piece
of the pie makes ebXML for SOA a compelling
business success.
Cheers, DW.
--
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
--
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
___________________________
Matthew MacKenzie
Senior Architect
Intelligent Documents Business Unit
Adobe Systems Canada Inc.
http://www.adobe.com/
506 869.0175
