OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[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


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?

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

 

Demo_scenario_1k.pdf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]