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

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' ;  
  

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