OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [regrep] V3.0 of ebXML for SOA (SOA-NOT)



Is there any room in ebXML-Land for someone that is not wedded to the notion that a web frontend solves all problems?  I have seen some really nasty backend systems that were impossible to partition and/or scale.  I have worked with networks that very overloaded and resource constrained. Is there any room for “an ebXML Registry-Lite” and/or “Nomadic Application Support?”


Zachary Alexander

The IT Investment Architect

ebTDesign LLC, (703) 283-4325





-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sunday, December 21, 2003 1:47 PM
To: regrep@lists.oasis-open.org
Subject: [regrep] V3.0 of ebXML for SOA


Duane raised some interesting points that I'd like to

focus on - in regard to - creating a new 3.0 release of



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



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



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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]