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

["David RR Webber" <david@drrw.info>]

Zachary,

 

I like to believe that CAM is a salve that can help with these situations.  But I also

did some work for the State of Maryland earlier this year looking at how their

ugly legacy world can be helped by adding an ebXML messaging component.

Clearly web access is a very powerful tool - but the trick is to link that into

the backends via a common XML format that works for every access point,

(forms, IVR, email, etc) and brings consistency and security to the chaos.

 

It's usually a case of keeping the legacy system afloat for long enough that

you can get a better solution up and taking over.

 

What you need from the new solution is that it does not fall into the

same ugly pits as the old.   I believe that is a large part of what we are

preaching here - that our methods do improve on the past.

 

Cheers, DW.

----- Original Message -----

From: Zachary Alexander

To: 'David RR Webber' ; regrep@lists.oasis-open.org

Sent: Monday, December 22, 2003 12:35 PM

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

David,

 

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

http://www.ebTDesign.com

http://www.p2pspeaker.com

http://www.p2peconomy.com

 

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: 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

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.