[ebxml-bp] 2/16/2004: WSDL / BPSS proposal (WI-12) [RSD]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|oasis.ebBP.WSDL;
Topic|;
Point|Boundaries for WSDL-BPSS proposal;

mm1@
re: WI 12
Reference: Dubray, proposal - 
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00064.html
There are a host of emails after that. JJ has also provided a previous 
white paper on Multi-Party collaboration.

Jean-Jacques will brief his proposal today to introduce in BPSS a new 
activity type called OperationActivity, that performs like a 
BusinessTransactionActivity or a CollaborationActivity.  An 
OperationActivity references an operation within a WSDL interface.

Key points raised by the team include:

    * Do we build hooks for extensions? How do we gain functionality
      without compromising the underlying base concepts (unless we
      choose to do so)?
    * 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]. Do these design choices create any challenges in
      tools?
    * How does this affect the flexibility we are trying to place in the
      use of Roles and composition? (Martin)

Potential requirements include:

    * Moberg: Differentiate MEP and business transaction patterns and
      business transactions.
    * Tell: 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
    * Roberts: Define BusinessTransaction as an abstract class to be
      overloaded with subclasses for each of the 6 known transcation
      patterns, where the main difference is the default values for the
      flags to: a) overriding of flag values even when using a pattern
      and b) external new patterns for cases where the 6 existing do not
      work.

I look forward to the discussion today. Thanks.

@mm1

--- Begin Message ---

• From: Jean-Jacques Dubray <jeanjadu@Attachmate.com>
• To: Jean-Jacques Dubray <jeanjadu@Attachmate.com>, ebxml-bp@lists.oasis-open.org
• Date: Sun, 08 Feb 2004 20:10:55 -0800

Discussion|oasis.ebBP;

Topic|WSDL;

Point|Intoduction;

 

||Following our discussion at the f2f meeting, here is my proposal for

||extending BPSS to support WSDL operations

 

JJD@

This proposal is based on WSDL 2.0. Even though this specification is still about 9 months before it becomes a W3C recommendation, it is very stable at this point as we are approaching the last call.

 

We introduce in BPSS a new activity type called OperationActivity, that performs like a BusinessTransactionActivity or a CollaborationActivity

 

An OperationActivity references an operation within a WSDL interface.

 

 

@JJD

 

Point|Schema;

JJD@

The schema introduces two new elements:

 

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

 

The model is a bit different from BT / BTA since an operation definition cannot be inverted (from/to role). This is why the definition features fromRole and toRole and not the operationActicity.

 

An interface is referenced both in the initiating operation and the responding operation. These two operations have to be exact mirrors of each other.

 

Any fault is by definition generating a Business Failure (equivalent to isPositiveResponse = false)

 

Similarly WSDL features of the references interface allow us to assert the value of these attributes: isAuthenticated, isConfidential and isTamperDetectable

 

I will publish a mapping between WSDL features and these values as soon as I can find a description of the features.

 

@JJD

 

Point|Other approaches;

JJD@
I don’t think we need to wrap WSDL messages in Document envelopes. WSDL features are often defined at the interface level (which I think is better granularity than at the document envelope level). Of course I understand why it is defined at the document envelope level, maybe BPSS could have a dual approach with default values for these parameters and overwrite whenever necessary. This could greatly simplify the reading of BPSS instances.

 

@JJD

 

||Hope that helps,

||

||Cheers

||

||JJ

 

--- End Message ---