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

[Matthew MacKenzie <matt@xmlglobal.com>]

Sanjay,

Maybe the right approach is to define an abstract web service which serves
as a BPSS handler, so that all the form and protocol issues are well
specified to an implementor, sort of like the Java servlet API.  The servlet
provider can implement a number of handler methods, and access the already
initialized infrastructure components.  In the case of servlets, one example
is the session object, in the case of BPSS, one such component might be a
CPAManager, or a SecurityManager which support the concrete application's
decision making process, e.g. "Is this a valid partner?" "Is this partner
using the agreed upon security?".

Regards,

Matt MacKenzie

----- Original Message -----
From: "Patil, Sanjay" <SPatil@iona.com>
To: "'Duane Nickull'" <duane@xmlglobal.com>; "Farrukh Najmi"
<Farrukh.Najmi@Sun.COM>
Cc: "Miguel Cruz Picão" <mp@viatecla.pt>; <ebxml-dev@lists.ebxml.org>;
<regrep@lists.oasis-open.org>; <ian.c.jones@bt.com>
Sent: Monday, October 15, 2001 10:56 AM
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 :-)
>
> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>