[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 3/23/2004: [RSD] WI-12 WSDL Support for v2.0 BSI
Discussion|OASIS.ebBP.WSDL Proposal;
Topic|;
Point|Summary-Additional Detail;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00175.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00064.html;
mm1@
||Attachment from Martin Roberts: http://www.bindsys.com/bindstudio/demosdocumentation.htm
Jean-Jacques and Mayilraj briefed the updated proposal yesterday to introduce in BPSS the new activity type called OperationActivity, that performs like a BusinessTransactionActivity or a CollaborationActivity. An OperationActivity references an operation within a WSDL interface. This proposal has been refined and takes into account the discussions
about clearly differentiating the use of WSDL, its limitations, maintaining the business level concepts from the interface description, etc. JJ has just sent his proposal. Below are the summary details surrounding all our discussions as well as points to consider prior to vote. 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 [1].
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 (remember this is v2.0 only).
Key points for balanced use of WSDL within ebBP:
* Separate simple OperationActivity to describe a touchpoint of a
web service to the web service-enabled BSI.
o Why or why not to use business transaction constructs?
+ WSDL does not differentiate between business signals
or messages.
# Signals are required for a business transaction.
+ What about a composed web services - using WSDL could
make tracking context difficult.
+ A business transaction patterns can weakly map to WSDL
request-response, but lacks the underlying semantics
or composibility.
+ Fundamental differences between web services and BPSS.
BPSS lives on top of web services technologies.
+ Describe simple WSDL to describe the BSI itself with
four basic definitions, or allow more definition with
signals. Build interoperable BSIs working on top of
web services technology. Keep separate internal
organization from how you publish your behavior from
your B2B partners.
+ Going into more detail here could tightly couple the
technologies. Don't dilute different levels or
building blocks in the stack. WSDL operates on a
different level and placing them at the same level may
cause other issues [1].
o Why or why not to use Requesting and Responding Business
Activity constructs?
+ See WSDL constraints below.
* Understand any constraints in the use of WSDL for an activity.
o Separate the business protocol from the message exchange.
o WSDL can't accommodate role binding changes.
o A generic type is not defined in WSDL (abstract is bound to
one concrete).
o Allows setting of simple operation of a composed web service.
o Signals are required for valid business transactions, which
are outside WSDL capabilities.
WSDL and BSI
* Understand any constraints in the use of WSDL for the BSI.
o A BT can relate to more than one BTA, which requires
multiple WSDL.
o WSDL can't accommodate more than one positive response.
o Using WSDL exclusively may limit enablement of a WS BSI.
o Allow BSI to interact with non-BSI through operation. Allows
non-ebXML parties to collaborate.
o WSDL lacks transactional semantics.
o Model BSI at a high level as a web service (for message and
signals only in v2.0).
o Enable further progress on WSDL for CPA.
o Limit the WSDL definition to the BSI not entire composition
of business collaboration. Gain functionality without
compromising the underlying base concepts.
* Define the template for the BSI including these concepts.
o Will support this summary proposal.
o Desire to encourage seamless interoperation. ebBP can enable
WSDL but in a transparent manner.
Open points raised by the team include:
* Do we build hooks for extensions?
* Do we use Venetian blind substitution group and hooks for lower
level artifacts like WSDL definitions? Or do we consider "Garden
of Eden rewrites" (Venetian blind) which means we have both
complexTypes and elements for them globally available
[Roberts/Moberg]. Note challenges to tools cited by Roberts in
February 2004.
As an aside, be able to communicate this in the upcoming Reliable
Infrastructure OASIS symposium (Transaction track).
[1] I have seen specific reference to the use (potential misuse) in
other venues, in attempting to instill implicitly, through xsd:string,
through other proprietary mechanisms, the business semantics that are
inherent in BPSS (and the concepts it recognizes such as the business
transaction patterns).
||Discussion|WSDL Proposal;
||Topic|;
||Point|Summary;
||JJD@
||||I would like to re-iterate my firm belief that a WSDL operation is not
||like a business transaction. It really does not work the same way:
||a) at design time (via the BT/BTA mechanism) and semantically.
||b) semantically: it just happens that a BT can be configured to operate
||without signals, but in that case, it really has nothing to see with
||Business or Transaction for that matter. The intent of BPSS is to choose
||which signals are meaningful for a particular BT, but not to remove all
||of them altogether.
||
||I understand why Anders and John are suggesting what they are
||suggesting, this is a logical design, and this is what I would normally
||vote for. However, I am afraid that we will bring confusion to both WSDL
||and BPSS by calling a Business Transaction an operation, because in
||essence it is not as I said in b)
||
||I would like to clarify the proposal to take into account Dale's remark.
||The way the proposal was defined does not reference any WSDL fine in the
||BPSS definition. Only abstract interface and operation names are
||referenced in the BPSS. The actual WSDL fine link will be in the CPP.
||That way we don't have to make assumption on its modular design. The BSI
||will look for the interface and operation name in the WSDL file and bind
||it to that port.
||
||Of course there is now a bit of pressure in the CPPA team to come up
||with an asymmetric mechanism to establish the CPPA in the BSI that is
||ebXML capable and read maybe the other party's WSDL in a UDDI
||repository. Don't ask me how this would work, I have no idea.
||
||The current proposal works for both inbound or outbound operations.
||@JJD
||
||Point|Proposal;
||JJD@
||The proposal has not changed, only the meaning of interface and name
||<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>
||@JJD
@mm1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]