[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 5/24/2004: Operation Activity (Operation Invocation or Action)Summary [RSD]
OASIS.ebBP.WI-12-WSDL Support;
Topic|;
Point|;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00175.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00064.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00080.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00089.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00097.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00098.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00105.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00111.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200403/msg00073.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200404/msg00022.html;
Attachment|http://www.bindsys.com/bindstudio/demosdocumentation.htm;
Attachment|http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/5594/ebbp-mtgminutes-021604.txt;
Attachment|http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/6054/ebbp-mtgMinutes-032204.txt;
mm1@
In today's call I was asked to provide a summary of the report, proposal
and discussions surrounding OperationActivity (Invocation or Action -
Name can be changed). OperationActivity references an abstract WSDL
interface and operation names (one side of the interface while BTA and
CA acknowledge the collaborative interaction). The actual WSDL fine link
will be in the CPP. The BSI could look for the interface and operation
name in the WSDL file and bind it to that port.
Several postings (see end of this email) have attempted to differentiate
the use of WSDL, its limitations, maintaining the business level
concepts from the interface description, and WSDL's focus on the server
(not the client even in WSDL v2.0). Below are the summary details
surrounding all our discussions and points to evaluate/consider. Note
that the WSDL definition for OperationActivity is separate from the
discussion of how / to what extent we define the BSI.
Potential requirements include:
1. Differentiate MEP and business transaction patterns and business
transactions.
2. Accommodate dispatch and reach (evidentiary or traceability
requirements) [v3.0] See work item 67. Also reference:
http://www.uncitral.org/english/texts/electcom/ml-ecomm.htm
3. Enable the use of WSDL while maintaining seamless integration with
ebBP, through the BSI.
4. Keep it simple (v2.0 focus).
5. Keep the internal behavior separate from the collaborative process.
Keep separate internal organization from how you publish your behavior
from your B2B partners.
Options proposed over the varied discussions (the first two have been
discussed primarily and have been part of a straw poll:
* Create a constrained BT pattern to allow the use of WSDL.
* Create a OperationActivity (or InvocationAction) to allow use of
WSDL. [1]
* Create an extension mechansim that could hook to a WSDL. Allow
capability to replace an item using the Venetian Blind
substitution group method as well as defined hooks for lower level
artifacts, such as the WSDL definitions.
[1] This could be equated to a WSDL extension of the Business Action
that constraints its use.
To create some boundaries here are two important definitions:
* Business Transaction (BT): A business transaction is a set of
business information and business signal exchanges amongst two
business partners that must occur in an agreed format, sequence
and time period. A BT is a re-useable protocol between two roles.
The business transaction protocol is independent of underlying and
transport signals such as reliable messaging [1]
* WSDL: At an abstract level, WSDL describes a Web service in terms
of the messages it sends and receives; messages are described
independent of a specific wire format using a type system,
typically XML Schema. An /operation/ associates a message exchange
pattern with one or more messages. A /message exchange pattern/
identifies the sequence and cardinality of messages sent and/or
received as well as who they are logically sent to and/or received
from. An /interface/ groups together operations without any
commitment to transport or wire format..........Web Services
Description Language (WSDL) message exchange patterns define the
sequence and cardinality of abstract messages listed in an
operation. Message exchange patterns also define which other nodes
send messages to, and receive messages from, the service
implementing the operation. [2]
[1] UMM, R10, Annex 1 and ebXML BPSS v1.1.
[2] WSDL v2.0, 26 March 2004 (Core Language and Message Exchange Patterns)
The intent of BPSS is to choose the effective use of the guiding BT
patterns where signals are meaningful for a particular BT. The patterns
guides the actrual exchange of messages and signals between the partners
to achieve the required electronic commerce transaction. A business
signal is an object that is transmitted back to an activity that
initiated the transfer of execution control. Business signals have
specific business purpose and are separate from lower protocol and
transport signals as specified in the ebXML Message Service
Specification. The state of a given business transaction activity
instance can be explicitely calculated at run-time by evaluating these
signals.
Characteristics surrounding WSDL vs. business transactions and patterns
in ebBP:
* WSDL fails to differentiate business signals or messages (every
exchange is a message without the semantics associated with their
usage).
o Looking at the UMM R10, the six patterns can involve or
involve business signals (with specified restrictions on
their use).
o Signals are not a part of the WSDL MEP.
* WSDL involves an interface and ebBP does not.
o Although abstract, an abstract WSDL interface binds to a
concrete binding.
o The WSDL exists below the BSI that supports web
service-enabled and non-enabled capabilities. See
definitions above and W3C site.
* WSDL has not matured to handle a composed web service (where
context could be difficult to track - maps to our multi-party
discussion).
* WSDL does not include the business protocol that exists in ebBP.
o Business protocol exceptions can occur with use of the BT
patterns. See UMM R10.
o WSDL only recognizes technical failures (WSDL faults or
fault messages).
* At this time, we recognize six BT patterns in ebBP with at least
one more to be developed (contract-formation). Each of these
patterns includes semantics related to contractual terms and
obligations, receipt and acceptance acknowledgements, substantive
Business Acceptance, etc.
o WSDL v2.0 (working draft) currently recognizes six _web
service_ patterns and does not recognize other than web
services. Only one appears to have relevance to our
discussion, out-in (based on a server-side visible model only).
* WSDL is bound to a particular role (even with new emerging
technologies, roles do not change - additional interfaces have to
be defined to support a party that assumes more than one role
during a collaboration.
* A BT can relate to more than one BTA which requires multiple WSDL.
The BT actually can go over several kinds of MEP. Any binding to
WSDL should occur at the CPPA [3].
o A BTA can include a request and many possible responses (at
a minimum success and failure). WSDL can only handle one
response to any given request.
o The BTA can be executed more than once, converse to WSDL. [4]
* WSDL lacks transactional semantics.
o Dependencies may apply to other specifications including but
not limited to WS-T (AT/BA), WS-C, WS-CAF, BTP et al.
o In v3.0 ebBP, we have discussed the possibility to use
shared context and WS-CAF to enable multi-party
collaboration. Our use of WSDL now may impact this later.
[3] Dale Moberg, 9 February 2004 (see _References_).
[4] Looping may be provided by other technologies but not WSDL in and of
itself.
If we define an OperationInvocationActivity/Action/xyz:
* We keep the semantics separate.
* We alleviate confusion that a business transaction = a WSDL interface.
* We allow a WSDL abstract interface to be used and bound elsewhere.
* We have to define what the statuses are it can return (see those
enumeration values in BTA or CA). [5]
* We have to establish relationships to Document Envelope and roles
(see note above about role constraints). [5]
* We would have to determine any other side effects that may occur,
if any.
If we attach a new constrained BT pattern to the Operation:
* We would have to evaluate if this pattern related to the
business-defined ones that exist. Looking at the WSDL MEP I cannot
see that is true (WSDL is server side focused and doesn't equate
any substantive response from a client or expectations from a
client that any ack is required).
* We would have explicitly define what the pattern looked like and
cascade all other restrictions into the ebBP for its use.
o Other restrictions may be challenging to implement in ebBP.
+ Grammar, sequence, schema, content, and activity
processing such as handoff for application level
processing (AcceptanceAcknowledgement although this
may in itself become a business message in v3.0).
+ How to apply use of WSDL in different compositional
layers of ebBP.
* We would need to determine other side effects that may occur, if any.
In v3.0, we anticipate we will attach dispatch-reach requirements. Those
requirements will be applied regardless of activities or actions are
defined in ebBP.
I encourage everyone to comment on this summary, add your thoughts,
diagrams, modeling input, etc. I have attached below an additional input
I received today from JJ Dubray.
_References:_
Original Dubray proposal, 9 February:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00175.html
References compiled by Dubray, Krishnan and Martin, 16 February:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00064.html
Type concern from Moberg, 9 February 2004:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00080.html
Tell question to Dubray, 9 February:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00089.html
Tell, UNCITRAL reference on dispatch-reach, 12 February:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00097.html
Roberts, Request for a white paper stating how WSDL and BT, 12 February:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00098.html
St. Amand, Need for traceability:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00105.html
Roberts, Request for extension to support WSDL:
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00111.html
Martin, Summary report and proposal:
http://www.oasis-open.org/archives/ebxml-bp/200403/msg00073.html
Martin, Straw poll vote notice:
http://www.oasis-open.org/archives/ebxml-bp/200404/msg00022.html
Roberts, How BindStudio separates BT and use of WSDL:
http://www.bindsys.com/bindstudio/demosdocumentation.htm
Meeting minutes on detailed WI-12 discussion, 16 February and 22 March
2004:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/5594/ebbp-mtgminutes-021604.txt
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/6054/ebbp-mtgMinutes-032204.txt
Meeting minutes 24 May 2004, attached.
Other references from:
UMM, R10, Chapters 8 and 9.
ebXML BPSS v1.1
Code provided:
<Process>
<OperationDefinition
name="xs:NCName" || guid="xs:anyURi" >
fromRole="xs:string" >
toRole="xs:string" >
fromRoleGUIDREF="GUIDREF" >
toRoleGUIDREF="GUIDREF" >
>
<InitiatingOperation
name="xs:NCName" || guid="xs:anyURi" >
interface="xs:string" >
name="xs:string" >
namespace="xs:anyURI" >
<documentation />?
</InitiatingOperation >
<RespondingOperation
name="xs:NCName" || guid="xs:anyURi" >
interface="xs:string" >
name="xs:string" >
namespace="xs:anyURI" >
<documentation />?
</RespondingOperation >
<documentation />?
</OperationDefinition>
<OperationActivity
name="xs:NCName" || guid="xs:anyURi" >
timeToPerform="xs:duration" >
isConcurrent="xs:boolean" >
beginsWhen="xs:string" >
endsWhen="xs:string" >
preCondition="xs:string" >
postCondition="xs:string" >
>
</Process>
_Dubray, 24 May 2004_
WS Collaboration
Made of several operations without Made of several BT
with an explicit relationship (chor)
explicit relationship to each other
Does not require a BSI or agreement Requires a BSI
mechanisms Requires
"negotiated" agreements
Operation BT
Req, Response, Fault* Request,Response*,
Fault*
No state alignment protocol Business
transaction protocol
Directed (A->B) No direction
specified (BTA)
Looking at this set of properties it is legitimate to ask the question
whether we want to make an operation invocation a BT (it clearly looks
like a subset). However, it is not because we can do something that we
should do something. This question is as legitimate (not more) to ask
whether a CORBA call or an RPC should be part of a collaboration. I
don't think I would find many people asking for invoking a method from a
BPSS. The reason why this question is relevant is because, WS is an
internet ready technology and many businesses may decide to expose them
[sic].
If we make an operation look like a BT we would:
a) bring confusion, "so why do I need all this stuff if an operation IS
A business transaction". Transaction is about state alignment (not
rollback/compensation - rollback/compensation is a convenience mechanism
to serve state alignment). A web service operation does not give you any
kind of state alignment guarantee. ebXML BPSS and the ebXML architecture
has been carefully designed and tested to provide state alignment
capabilities via the concept of signals. Let me know if you need an
explanation on this (the short version is that in the WS, only the
consumer of the service knows the outcome, that kind of works for one of
services like "creditCheck" where the interaction does not depend on
previous states being reached. Imagine a world where we carry out
interactions without being sure of the past????). A web service
operation by itself CANNOT guaranty state alignment in any situation.
b) we will have to hack BPSS pretty much everywhere to explain that a
operation BT does not work like a BT
- cannot be used in any order (so we have to specify the roles
somewhere)
- cannot be changed via "substitution set mechanism"
- cannot be augmented to use a business transaction protocol
- use a different "CPP/A" mechanism
- different exception mechanism (technical failure)
-...
Making an operation a BT will require that we annotate EVERY aspect of
BPSS to specify how this works with the operation BT pattern. It will
also limit our ability to use other WS stack spec as we see fit.
I recommend that we keep operation and BT separate and create an
operation activity which has its own behavior totally independent from
the BT behavior. I recognize that this is a hybrid approach, but we are
dealing with technologies that had and will have different paths.
JJ-
@mm1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]