RE: [ebxml-mktg-sc] 9/23/2002: Web Services trends and ebXML

[David RR Webber - XMLGlobal <Gnosis_@compuserve.com>]

Monica,

I STRONGLY disagree with this world view!!!

Yes - ebXML does provide a UMM model view that WS does not.

However ebXML ALSO provides key underpinning that is 
just totalling missing in WS.

So - to me WS is a thin layer in the middle - focusing on a narrow
part of the solution space - thats scrambling to re-invent peices
that ebXML already delivers.

It very much is an opportunistic approach based around the 
Nike - just do it - build out - load, fire, aim.

And now they are scrambling to add substance around that
thin start of UDDI + SOAP + WSDL.

On the BPEL4WS- this is a classic example - we now have four
of these (not counting prior non-XML workflow efforts!)

BPMI, BPSS, WS-I and BPEL4WS - no surprise that customers
are crying "foul" - and forcing vendors to sit down and come up
with just ONE single approach here.

So rather than ebXML having a narrower bottom - its very
clear that only ebXML is addressing the KEY need of 
transaction assembly and integration.  WS right now is very
much that realtime-EDI content and service delivery.  Sooner 
or later people will realize there is no free lunch.  You need
the mature and secure interchange model (so this is exactly
what we see - that WS is adding all this - reinventing the ebMS
wheel within W3C).

The right intersection to me is to prevent this chaos - define
WS as a layer within the overall architecture.  Therefore you 
end up with ebXML + WS - where WS leverage the information
architecture of ebXML - registry, assembly, dictionary components,
and the partner model - CPA/CPP, and then there is a common
BP system in the middle that orchestrates the two delivery 
models - ebMS or WS.   The modelling UMM layer then sits
above both of these as a neutral representation.  Notice this
also continues with the ebXML philosophy of allowing layers
to be used standalone, or in combinations as needed.

DW.
=============================================================
Message text written by Monica Martin
>========================================================================
========Actually, I think the issue is that WS are coming from the
bottom up
(infrastructure to domain) and ebXML is coming from the top down (domain
to infrastructure).  So when WS get up to the domain level, they will
have a "wider top" than ebXML - they will support more domains.  When
ebXML gets down to the infrastructure level, it will have a "narrower
bottom" than WS - it will provide less infrastructure.

Given that there are tremendous economies of scale in reusing
infrastructure, WS will become the dominant model for exchanging
documents.  WS-* and BPEL4WS are examples of higher and higher levels of
infrastructure expanding the reach of the model.  But they are not
focused on any particular domain.  I think the reasonable course for
ebXML to follow is to redefine itself as a domain model on top of the WS
infrastructure.

Take all of the requirements definition and business modeling in ebXML
as the input for generating a set of conventions for using the WS
infrastructure.  Define the CPP WS for interrogating CPPs.  Define a
mechanical way to generate a BPEL4WS choreography from a CPA.  Define a
mechanical way to define the required WS-Security and WS-Coordination
properties from a CPA.  And so on.  A good test to see if ebXML is doing
this right is to check that there are no ebXML header elements in SOAP
messages.  
<