RE: [ebsoa] SOA and Shared Semantics

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

-----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. 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?