RE: [regrep] Re: [ebxml-dev] RE: ebXML deliveries

["Patil, Sanjay" <SPatil@iona.com>]

>>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
>> <snip/>

Duane, I guess your list of possible web services was just for outlining
the possibilities and open ended. I want to use this opportunity to
bring forth a prime candidate for web service enablement in ebXML
architecture (of course, IMHO) that shouldn't be left in the dark...

Support for generating web services from the BPSS. The Business processes
modeled under the framework of BPSS are essentially the applications
that enterprises would like to expose to their partners as web services.
Even though the BPSS schema as such does not prevent one from utilizing
web services for binding of the business processes compliant with the BPSS.
It will greatly boost the adoption of BPSS and other ebXML specs CPP/CPA, 
TRP, if there is also support for generation of web service definitions 
(BPSS) registration of these web services (ROWS), invocation of the
web services (RAWS, TRP), so an and so forth .. This picture however, IMHO,
requires taking the web services a lot further in order to accommodate 
essential business transaction features - business process flow notation and

rules for validation at runtime, carry security tokens, transaction 
contexts, ...

A right sprinkle of web services on ebXML architecture is something
like icing on the cake, IMO, as ebXML already has solutions for all the 
areas that are addressed by web services and in addition. Also, I guess
selling the cake is difficult without this particular icing at present :-)

thanks,
Sanjay Patil
----------------------------------------------------------------------------
------------------------------
IONA
Total Business Integration (TM) 
Phone: 408 350 9619                                 http://www.iona.com


-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Monday, October 15, 2001 10:18 AM
To: Farrukh Najmi
Cc: Miguel Cruz Picão; ebxml-dev@lists.ebxml.org;
regrep@lists.oasis-open.org; ian.c.jones@bt.com
Subject: [regrep] Re: [ebxml-dev] RE: ebXML deliveries


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





----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>