|Subject:||RE: [ebxml-bp] RE: Alignment of OASIS ASAP and jCAM|
|From:||Keith Swenson (KSwe...@us.fujitsu.com)|
|Date:||Sep 19, 2004 10:27:21 pm|
bin00001.bin - 341k
Title: RE: [ebxml-bp] RE: Alignment of OASIS ASAP and jCAM
The attached document contains the ASAP demo scenario. This document lists the exact schema for the example, and specific sample messages that might be included in the exchange. Take for example this one:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Header> <as:Request xmlns:as="http://www.oasis-open.org/asap/0.9/asap.xsd"> <as:SenderKey>http://harness/customer</as:SenderKey> <as:ReceiverKey> http://SAMEERP:9004/iflowjsp/jsp/ProcDef.jsp?planName=Retailer </as:ReceiverKey> <as:ResponseRequired>Yes</as:ResponseRequired> </as:Request> </soap:Header> <soap:Body> <as:GetPropertiesRq xmlns:as="http://www.oasis-open.org/asap/0.9/asap.xsd"/> </soap:Body> </soap:Envelope>
This is the message to get the properties (which includes the instance schema) from a factory resource. My question, quite simply is, what would have to be changed in order to call this an ebXML message -- to fit in with the ebXML requirements?
-----Original Message----- From: David RR Webber [mailto:dav...@drrw.info] Sent: Tuesday, September 14, 2004 8:52 AM To: Keith Swenson Cc: ASAP (E-mail); TC, CAM OASIS,; ebXML BP Subject: Re: [ebxml-bp] RE: Alignment of OASIS ASAP and jCAM
I think we're touching here on some fundamental aspects.
One reason why simple webservices cannot interact with ebMS is because they are purely based on WSDL alone. And WSDL alone was never designed to solve eBusiness integration needs. However - ASAP has solved many of these gaps because it is providing a formal static definition of many of those missing peices. These would be -
#1 - clear interaction model with descrete deterministic behaviours and outcomes. #2 - means to manage error conditions and signal subsequent action steps. #3 - robust context driven data handling. #4 - definition of a business partner relationship #5 - ability to share the interaction model with your partners in a clear, open and simple manner
Because ASAP has addressed these in a limited way - whereas ebXML provides the generalized handling - this can potentially be a case of a base function set - that can be extended as needed.
BTW - we should also consider the case of an ebMS message envelope being able to be processed directly by an ASAP server. Again - if we could figure out how to construct an ebMS package subset that an ASAP server could handle - that would be huge. And of course vice versa would then beckon.
It's definately probably too much to consider for October- but we could certainly attempt to look at the enveloping structures right now - and talk about work in progress - assumming that looks strongly feasible after an initial assessment...
What might be feasible is to show how jCAM validations can be invoked in tandem with ASAP as a first signficant step.
Thanks, DW ======================================== 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.