Re: Alignment of OASIS ASAP and jCAM

[David RR Webber <david@drrw.info>]

Keith,

OK excellent observations.

Some clarifications - by referring to ASAP as BPSS-lite - I did indeed 
mean to call-out that ASAP only
has one interaction model - and that a BPSS BTA model can be created 
that mirrors that.  I believe
BPSS V2 with the fact that it includes endsWhen, beginsWhen 
conditionals, and extensible variable
and context mechanism, and ability to have flow constructs - can model 
an ASAP.  What I'm seeing is
we could package this as a set of model components - and then people 
would not even be aware
they are doing BPSS - but instead - would simply assemble together their 
ASAP based exchanges
using those components.

Then if they needed to extend this using ebMS and other more elaborate 
mechanisms that ebXML
supports - they can merely take that base model and start inserting 
those parts too.

Alternatively - they can mix-in match.  Where some of their partners are 
using ebMS and some
ASAP then this should be seamless at the model level - since the model 
would constrain what
they could do where.

This is of course where we get into the "devil is in the details" note!  
It would definately be interesting
to see if a modified ebMS server could recieve in an ASAP SOAP message 
and then generate
an outbound ebMS message with the same payload - but to a different 
receipient.

That would be a first step toward some level of co-existence.

Actually if I was going to build this - I'd take Hermes and an ASAP 
implementation - let the ASAP
handler do the inbound receipt - and just have it place the payload onto 
the Hermes outbound message
queue - and then set the CPA ID delivery details - and let Hermes build 
the outbound from there....
Then all I'd have to create is that data handler servlet that sits on 
the ASAP side an moves the payload
over to the ebMS queue.

Thanks, DW


Keith Swenson wrote:

> 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.
>  
>