Re: [ebsoa] SOA and Shared Semantics

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Dale Moberg wrote:
> 
> -----Original Rant----- was From: Ann Wrightson
> [mailto:ann.wrightson@csw.co.uk]
> 
> Which raises a bigger issue, relative to packaging ebSOA output as
> (only) relevant to the "ebXML way" (rant approaching :)
> 
> The bigger and more comprehensive a standard, the more useful it looks
> to its creators, *and the less useful it is likely to be on the ground*
> since adopting it entails grabbing larger "territory" within a solution.
> The last thing I need is comprehensive standards (I do most of my work
> in projects trying to build stuff that works rather than in standards).
> I need neat and usable solutions to specific interoperability problems
> that I can introduce *alongside divers other approaches in a clean way*.
> If a collection of neat solutions also fit together well to build a
> bigger picture when they are adopted incrementally, this is good, but in
> a project context, in my experience, needs to manifest (be sellable) as
> a "nice to have" future opportunity bonus, not a present necessity.
> 
> Fit-for-purpose standards: 0) do something useful 1) work with a v. wide
> range of tools 2) are simple and modular 3) do not change (!!) 4) are
> easy for adopters from a wide range of IT backgrounds to understand and
> use.
> 
> End of rant.
> 
> Rant discussion--
> 
> 0. Don't know what ebSOA scope is. Thought I knew, but am awaiting for
> consensus. 

+1. More than two months into the effort, I still am not able to answer
this question when people ask me. I ask very straightforward, pointed
questions, and all I get in response is a reference to some other
initiative. I am also unclear on how useful this initiative might be to
folks who don't want to utilize any part of the ebXML framework - that
is, those folks who say "I don't see enough ebXML-compliant software in
the market to make me feel comfortable investing in this framework"
(something I hear quite frequently)

Thanks,
Joe

> So I can't comment on the larger issue of "only relevant to
> ebXML" That exclusivity was not part of the scope IMO, but including it
> as one relevant factor was part of the scope (or I thought it was).
> 
> 1. Adopting ebXML does not entail grabbing any more territory than what
> the specification you choose to use covers. The "highly aligned, loosely
> coupled" design principle was to allow you to use CC/UBL and WSDL if you
> wanted to. Using ebMS (ebXML Messaging) doesn't require using any other
> spec. Were you looking for the term "monolithic"? This is what large
> vender detracters say when they are "on message".
> 
> If ebXML Messaging had, for example, been written as 20 different
> smaller specifications, would you really be better off for b2b
> messaging? Would the 20 work together? Would security (WSS) be done
> before routing to your app? Or after? (You better hope before. But the
> SOAP processing model is nondetermistic (unless you put in an order
> specifying header block) on this point, so maybe you better wait for the
> first couple of patches.) And if you error on WSS, will you fault before
> you comply with (your choice out of 2) Reliable Messaging header blocks?
> If you do, you will get the error back again repeatedly! The total
> free-for-all of "dynamic" WS is there for you to adopt! Go for it. It is
> not an accident that the study of dynamical systems includes chaos
> theory.
> 
> 2. Good luck finding venders that do WS in an interoperable way, with
> clean modularity.
> If you haven't found the problems with the lack of coordination, you are
> probably still dealing with very simple systems.
> 
> 3. Ironically ebXML modules aspired precisely to meet your expressed
> goal of "adoptable incrementally and fitting together to solve specific
> groups of interop problems." It is my understanding that ebXML people
> are still working to attain that goal so I am afraid that new versions
> will be part of that reality for a while. Maybe WS won't have versions?

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton