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

[Monica Martin <mmartin@certivo.net>]

Here's some additional detail that helps maximize what is said here and
the value that ebXML with domain and process expertise can envelope (or
provide an umbrella over Web Services). This comment came from a Web
Services counterpart (with no comment on the assumptions made)......

========================================================================
========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.  
========================================================================
========
The next step is to be able to capture these thoughts and communicate to
benefit for ebXML.

-----Original Message-----
From: David RR Webber - XMLGlobal [mailto:Gnosis_@compuserve.com]
Sent: Friday, September 20, 2002 8:09 AM
To: ebXML Mkt Steering
Subject: [ebxml-mktg-sc] web services trends?


http://www.eweek.com/article2/0,3959,537450,00.asp

Jet blue use case - but turns out only piece is the credit
card authorization!  

http://www.cw360.com/article&rd=&i=&ard=115939&fv=1

Google - API's into the Google engine - so people can add
search, spell-check and more to their applications.

Search engine vendors are desperate for any upside - 
notice they are offering free fish - hoping to hook 
bigger catch.  Once performance goes in a hole - then
they can sell dedicated service.   However the model
here is good - web service offering up nothing but
content information - not trying to run a business process.

Then 

 http://www.infoworld.com/articles/hn/xml/02/09/19/020919hnbpi.xml

where the message is:

"Sargent, like Patel and St. John, is rolling out Web services
internally 
based on individual projects aimed at making enterprisewide data 
available to the process layer. As the standards mature, the 
companies will each move onto to larger-scale deployments, they said.

Testing the waters.

Clearly our challenge appears to be:

a) Showing how ebXML and web services together will solve the
     real big problem

b) Countering the FUD by running our own survey around ebXML
     adoption - canvas ebXML participants today - find out how many
     have done or are planning initial projects.

c) Getting better WP materials out there on what I'm calling XIS - 
     XML Integration System - that show clearly how to deploy
     agile information systems based around the full depth of ebXML
     architecture, with a web service adjunct to manage lightweight
     information points, and point services - like credit card checks.

As Peter Coffee says - nothing new here - this is B2B EDI with
realtime-EDI for event checking, and then XML and some OO 
sprinkled in!!!   

What makes it different and compelling is the ebXML infrastructure,
providing you with an open system based on business semantics.

DW.