Re: [ebxml-dev] RE: ebXML deliveries

[Duane Nickull <duane@xmlglobal.com>]

Hello Farrukh:


I must apologize for the late reply.  I decided to drive to and from San 
Fransisco to attend the latest UN/CEFACT ebTWG meeting.  In retrospect, 
  it was not a good idea.

Having an architecture team write an initial white paper on all ebXML as 
a set of web services was favoured by the architecture group becuase it 
must span all other groups.  The goal is not to define the actual 
services,  just to ensure that the requirements are well documented and 
enough information is present to allow each appropriate group to define 
itself as web services.


Becuase ebXML architecture is the joint responsibility of both OASIS and 
UN/CEFACT, it would normally be done by both groups, however, only the 
UN/CEFACT group has materialized.

I have also been a proponent of RAWS/ROWS within our group.  Your 
initiative should serve as a model for other groups.  Architecture will 
never define the interfaces for WS.

The white paper is in its' infancy.  There is no clear ETA from the 
group right now.

Other comments inline:

> I believe that exporting ebXML defines services as web services should be the
> purview of the technical committee that defines that ebXML specification and
> understands its past, present ad future.
>>>>


Fully agree.


> As far as I know currently there are only two services in ebXML (ebXML Messaging
> Service and ebXML Registry service). As mentioned Registry Service is already
> defined as a web service. The OASIS ebXML Messaging Service TC may well decide
> to provide a web service interface for it in the future.
>>>>>>>>>

There are many other services that can be defined.  That is what the 
architecture group will do.  Some suggestions for services are:

1.  CPA negotiation

A WS could take in two or more CPP's and one Business Process Schema and 
generate a suggested CPA plus a COntext Rules Message.

2.  Core Components Realization

A WS could take in a Context Rules Message and one or more COre 
Components and return a Business INformation Entity (a context specific 
core components)

3.  A Core Components Syntax Specific Engine

A WS could accept BIE's, which are still syntax neutral, and an argument 
for which syntax to use, and return a syntax and context specific 
fragment to build a message payload.

4.  CPP Builder

A WS could take in a list of strings/other Datatypes and return a CPP 
document.

etc. etc.

Since RAWS already exists,  I have proposed that our group point at that 
work.

 
> So in summary, I do not see how/why "the new UN CEFACT electronic business
> architecture group" should be "preparing a white paper on ebXML as a set of web
> services". And indeed if they are for some very good reasons for doing so (that
> I fail to see), then have the TCs that define the ebXML services specifications
> been consulted?

 >>>>>>
Not yet, however they will be.  This will not be a closed door approach. 
  IN fact,  the UN/CEFACT guidelines specifically mandate an open 
approach.  Again,  the reason Architecture is tackling this is becuase 
it spans multiple groups.  Architecture will not define the WS,  just 
produce a White Paper describing advantages of using WS and suggesting a 
logical breakdown of services for each functional area of ebXML besides 
MSG and Registry which are already defined.

I hope we can count of your participation as I believe all of us can 
benefit from your expertise from RAWS.

Duane Nickull