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:]

Sent: Sunday,
 December 21, 2003 1:47 PM

To: 

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.