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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: [ebBP] 6/7/2004: Update for WI-12 WSDL Support


Discussion|OASIS.ebBP.WI12-WSDL Support;
Topic|;
Point|Update on options and proposals;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00177.html; 

Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00178.html; 

Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00143.html;

mm1@
I sent out a detailed summary about the discussions on the 
OperationActivity (or what it name becomes) on 24 May 2004 [1]. Since 
that time there have been some important discussions, suggestions and 
inputs from the team, some of which are still under development [2]. 
We've had two detailed proposals from Anders Tell and JJ Dubray. As John 
Yunker has intimated, these two proposals can co-exist, in that their 
use depends on the business environment constraints.  Kenji has 
indicated, and others have agreed that the operations (and MEP) exist 
below our view of business transaction patterns and business 
transactions. As John Yunker said (and Kenji alluded to in his 
response), "If we are not to treat Operation Activity as a 
specialization of Business Transaction, then we MUST recognize that the 
Operation Activity lives at a layer of the stack BELOW the business 
transaction (e.g. the only reason for an operation activity is to 
support a business transaction)."

I think we have to look to our guiding principles from other sources 
such as UNCITRAL, other UN legal documents and the ebXML eCommerce 
Patterns (v1.0) [3]. We do anticipate we will be adding more support in 
a later version. So, this is our first step to lay the groundwork.

Here are some additional thoughts and observations from our team as we 
come to closure on this item and anticipate a vote.

    * Need to evaluate if both parties have the same information using
      web services if a message is received.
    * Differentiate non-repudiation and reliability in messaging from
      the business process.
    * Need to accommodate legal enforceability - See reference above.
      Anders has proposed we have reasonable certainty (in the context
      of legal enforceability). I think this was envisioned for ebXML
      from the beginning (see eCommerce patterns).
    * Web services focus of server only is not the sameas a
      request-response. However, this does not preclude their use.
    * The assignment of constraints including the business semantical
      relevance of dispatch and reach will likely occur above the web
      services that are directed.
    * Multiple web services operations map to a business transaction.
      They appear to live at different layers of abstraction (CPA
      binding and web services). However, trading partners may choose
      not to use signals and use messaging to provide state information [4].
    * Here's a BPSS component hierarchy and summary of possible proposal
      provided by Kenji:
          o BC -> BT -> BusinessAction -> DocumentEnvelope ->
            BusinessDocument
          o Document Envelope maps to message exchange and are a lower
            abstraction than ebMS.
          o If we accept web services as a component / realization of
            business transaction, we can simply rely on CPPA's WSDL
            binding work.

I would like to bring this proposal to today's call:

    * Allow Kenji to provide a short proposal on the DocumentEnvelope.
    * Enable use of web services via the OperationActivity or through
      the DocumentEnvelope proposal (these two may become a combined or
      updated proposal). I'll call it 'thingy' for now until a decision
      is made.
    * Consider that for v2.0, with the capability to extend the business
      transaction patterns, a group of trading partners could decide to
      define their own that includes the 'thingy.'  The planned
      extensibility supports Anders' suggestion to define a highly
      constrained business transaction pattern.
    * Consider for v3.0, we consider a technical note that addresses how
      use of web services is accomplished and with more research how
      that occurs in the context of a constrained business transaction
      pattern. Further definition defined by the team.

Please be ready to discuss in today's call as there has been quite a bit 
of complementary traffic on this and related issues since our last call. 
Thanks.

[1] Summary: 
http://www.oasis-open.org/archives/ebxml-bp/200405/msg00143.html
[2] Comments from Kenji Nagahashi: 
http://www.oasis-open.org/archives/ebxml-bp/200405/msg00177.html; and 
http://www.oasis-open.org/archives/ebxml-bp/200405/msg00178.html
Comments from John Yunker: 
http://www.oasis-open.org/archives/ebxml-bp/200406/msg00015.html and
http://www.oasis-open.org/archives/ebxml-bp/200406/msg00013.html
[3] ebXML eCommerce Patterns, v1.0: http://www.ebxml.org/specs/bpWS.pdf
[4] We have not resolved as a team if this results in state alignment.
@mm1





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