[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] [ebBP] 6/7/2004: Update for WI-12 WSDL Support
Monica,
For me this is the key phrase:
"* 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."
If we can capture this - where it is a QoS or set of perscribed roles,
that apply when using a WS based exchange - then I believe we
have enough for V2. Basically I'm focused on the transport layer
as a means to implement what the BPSS requires - expressed as
a neutral set of business needs - I believe we have that clearly
spelled out. Right now only ebMS and CPPA are able to support
those to sufficient levels. However - its not just WS - its *any*
transport - that given sufficient support - can operate the BPSS.
It's just that we are calling out WS as another example here...
Thanks, DW
----- Original Message -----
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Monday, June 07, 2004 9:59 AM
Subject: [ebxml-bp] [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]