OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

>>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 :-)

Sanjay Patil
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
> purview of the technical committee that defines that ebXML specification
> understands its past, present ad future.

Fully agree.

> As far as I know currently there are only two services in ebXML (ebXML
> Service and ebXML Registry service). As mentioned Registry Service is
> defined as a web service. The OASIS ebXML Messaging Service TC may well
> 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 

etc. etc.

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

> 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
> I fail to see), then have the TCs that define the ebXML services
> 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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC