|Subject:||Re: Alignment of OASIS ASAP and jCAM|
|From:||David RR Webber (dav...@drrw.info)|
|Date:||Sep 14, 2004 8:38:36 am|
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.
Keith Swenson wrote:
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.
-----Original Message----- From: David RR Webber [mailto:dav...@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
#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.