[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] RE: Alignment of OASIS ASAP and jCAM
Keith, Just going back over my e-mail's here - at first blush - the ebMS format uses some eb: tags, in a very similar way - so my sense is that you would have to have those eb: tags in there. Whether these could co-exist with the as: tags is another question - and certainly things like <as:SenderKey> probably map onto <eb:From><eb:PartyID> and so on. However other things like the Service and Action are crucial - as those must match what is defined in the CPA for the business partners - as the ebMS will check those against the stored CPA(s) it keeps for that partyID. Here's the eb layout for the message header - so you would have to provide these items. Notice - Dale just posted a note to the BPSS list about the gap between WSDL and CPA in this area. Basically if ASAP is using the CPA to augment the WSDL - it would be fine - since the CPA carries all those things that WSDL does not. From the BPSS side - Dale is working on some alignments to show how a BPSS process BTA can have a set of WSDL definitions that could be used along with the CPA. Hope this is helpful Thanks, DW. <eb:MessageHeader> <eb:From> <eb:PartyId eb:type="urn:x12:org:I05:01">927645168</eb:PartyId> </eb:From> <eb:To> <eb:PartyId eb:type="urn:x12:org:I05:01">090993098</eb:PartyId> </eb:To> <eb:CPAId>A_CPA_ID_010430</eb:CPAId> <eb:ConversationId>3489</eb:ConversationId> <eb:Service>urn:nih.gov:ear:exchange</eb:Service> <eb:Action>ResponseMessage</eb:Action> <eb:MessageData> <eb:MessageId>5422</eb:MessageId> <eb:Timestamp>2004-08-18T09:52:17</eb:Timestamp> </eb:MessageData> </eb:MessageHeader> Keith Swenson wrote: > 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? > > -Keith > > > -----Original Message----- > > From: David RR Webber [mailto:david@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 > > > > > > Keith, > > > > 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: > > > > > 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. > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]