RE: Alignment of OASIS ASAP and jCAM

[Keith Swenson <KSwenson@us.fujitsu.com>]

Title: RE: Alignment of OASIS ASAP and jCAM

David,

I am glad that you see a good possibility for alignment between ASAP and ebXML.  I agree with you that on the surface ASAP appears to be a very basic, simple interaction pattern that could be implemented by ebXML infrastructure.  In this way ASAP is an application of, and a replacement for, ebXML.

I would caution against jumping to the conclusion that "BPSS V2 already has support for ASAP" at least until we have had a chance to compare the specifications in detail.  My brief overview does not cover ASAP in sufficient depth to be sure of this.  I am open minded and would be happy if we find this to be true.

I am confused by the statement that "ASAP could be viewed as BPSS-lite".  I was under the impression that BPSS was a language that could be used to describe interaction patterns (a.k.a. process definitions).  ASAP is a protocol; it is only one particular interaction pattern. 

Don't assume that because ASAP is a fixed protocol that it is necessarily simple.  There are 5 different requests (with responses) that can be made to an Instance, 3 to a Factory, and 3 to an Observer.  These 11 request/response pairs have well defined meanings (which is the real value of ASAP).  Defining an exchange very similar to ASAP is certainly very easy.  The question that I have is whether the exact pattern and the exact message structure can be described.  If not, what assumptions does ebXML bring that conflicts with assumptions from ASAP;  what can be done to resolve these differences?

Assuming that BPSS can describe the exact same message exchange, is there an implementation of ebXML that would be interested in demonstrating interoperability with an ASAP client/server.  We have two demonstrations slated for October, and showing the ability to implement ASAP in an ebXML infrastructure would be newsworthy and likely to be covered in the press.  At the June demonstration we had more than 2000 people observing, including many member of the press.

One place where I know that the ebXML is far more mature is in the formalization of the business agreements between parties.  I am wondering if the factory should be providing literally an ebXML CPA document as a property that can be accessed at any time. ( well really at the time that the engines are connected.)  I would appreciate some some detailed consideration of what ASAP currently supports, and how this meshes with a CPA.

One thing that has tripped up implementation of ASAP in other standards is the way that ASAP allows one service to refer to another service.  A request to one resource can return (as data) the address of another resource.  This seems like a natural capability in a hypertext world, but it seems that some formalisms being developed seem to make this difficult.  Another area of difficulty is that ASAP defines part of the message structure, but not the complete structure. There are generic components that all ASAP implementations carry, but there is the context data and the result data which are completely defined by the current business case.  Mixing those together is no problem using XML Schema, but some tools have a difficulty dealing with this kind of flexibility at run time.  I don't see any indication of this problem in the ebXML standards so far, but I am not an expert.

Overall I am very hopeful that these standards can fit together, but there is real work to be done.  The devil is always in the details.  We probably won't be able to prove anything until we get an interoperability test running.

-Keith

> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Monday, September 13, 2004 9:47 AM
> To: Keith Swensen
> Cc: ASAP (E-mail); TC, CAM OASIS,; ebXML BP
> Subject: Aignment of OASIS ASAP and jCAM
>
>
> Keith,
> ...
>
> #2 -  from the BPSS perspective - BPSS V2 already has support for the
>          ASAP process flow model - via the BTA mechanism -
> the endsWhen
>          conditional and a single document definition - in
> fact ASAP could
>           very much be viewed as BPSS-lite in this regard. 
> Therefore we
>          can easily model ASAP processes in BPSS - with the added
>          advantage of being able to extend those processes as needed.
>
>          To explore this - I'd recommend looking at the BPSS models
>          at my development site:  http://drrw.net/visualscripts/#ebxml
>
> #3 -  Again the ASAP agreement profile - URL + document - looks
>          like ebXML CPA-lite - so the potential exists to use CPA to
>          decribe ASAP configurations.  This would provide much more
>           robust authentication and business agreement formalization -
>           where needed - particularly for process steps have
> legalIntent.
>
>            This is something we have also recently refined in
> the BPSS V2
>             work.
>
> In summary - looks like jCAM templates are a great fit for
> formalizing ASAP document exchange handling as XML scripts -
> while BPSS V2 and CPA provide the roadmap for covering off
> the 20% side that falls outside the 80% sweetspot that ASAP
> is aiming at.
>
> Look forward to working on these aspects in due course.
>
> Thanks, DW.