RE: [ebxml-bp] WSDL / BPSS proposal

["Jean-Jacques Dubray" <jeanjadu@Attachmate.com>]

You write that a OperationActivity is different from BT/BTA, since it 
looks very similar to RequestResponseTransaction could you elaborate on 
the reasons why ?
JJ>I responded to that in an ealier email (direction cannot be inverted
like a BT in two different BTAs with opposite roles)

secondly how does OperationActivity handle semantics and obligations 
related to dispatch, reach?

JJ>What do mean with dispatch and reach?

thanks
/Anders

Jean-Jacques Dubray wrote:

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


-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////