OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-cppa] Version 3 extensions for WS agreements and profiles.


This time with the schema draft updates J

 


From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Tuesday, September 04, 2007 10:19 AM
To: ebxml-cppa
Subject: [ebxml-cppa] Version 3 extensions for WS agreements and profiles.

 

Here is the final extensibility framework appendix for version 3 that there has been interest in explicitly documenting in the draft version.

 

I am also including a copy of the draft current schema as there have been some modifications since Aug 24.

 

Major editorial tasks:

 

1. Go through the entire version 2 material and update as needed for version 3. Note the errata and additions (like ActionBinding etc) explicitly. Fold in the partyId material.

2. Add annotations to the schema systematically; much can be pulled from specification for the old elements.

3. Update all examples for new and old cases.

4. Finish extensibility remarks, especially to describe how to add new collaboration protocol “modules” for future developments.

5. Conversion XSLT (finished).

6. XSLT for creating candidate ActionBindings from ebBP 2.0 inputs (design phase).

 

A.   Using CPPA for Web Service Agreements

In order to announce capabilities or document agreements about aspects of web service collaboration protocols, web services DocExchange extension modules are added to a CPP or CPA using either the WSSenderBinding or WSReceiverBinding elements. Within these elements, the WSDLOperation and WSDLPolicy elements are used as containers for WSDL 1.1 [WSDL11] and 2.0 [WSDL20] or WS-Policy [WSPolicy] information.

 

Each WSDLOperation only needs to include or reference the “interface” aspects of WSDL. These aspects are found within portType or interface and any QName referenced other elements. (The precise elements needed differ in WSDL versions 1.1 [WSDL11] and 2.0 [WSDL20]).

 

For each ActionBinding, the interface’s operation first needs to be identified. The WSDLOperation/@operationRef uses a URI Reference to identify the operation.

 

This reference is constructed by appending a fragment identifier to the wsdl file location as discussed [WSDL20] or a W3C note [WSDL11Ref] that is constructed using an Xpointer fragment syntax:

 

http://example.org/hello1.wsdl#wsdl.interfaceOperation(Hello/sayHello)

 

where the interface local name “Hello” starts the path, and is followed by the local name of the operation, “sayHello”.


Because an operation can involve both requests and responses, the identification of the specific document that is being sent is specified as the value of the WSDLOperation@messageRef attribute, which contains an Xpointer value indicating the relevant document information. The list of faults is identified by WSDLOperation@faultRef Xpointer fragment identifiers.

 

WSDL content may also be placed verbatim within the WSDLOperation content model. In this case, a bare fragment identifier (beginning with a “#”) indicates that the WSDL is found within the element content, or the

 

The question of how to make use of wsdl:service, wsdl:binding or wsdl extensions is left to the implementations that consume CPAs. It is expected that installed CPAs be checked so that configuration information is consistent.

 

On the wsdl consumer side, the capability to act as a client is marked by an entirely empty WSDLOperation element. An empty element indicates that the client is capable of conforming or agrees to conform with whatever the wsdl specifies pertaining to input, output, and faults.

 

Support for CPPs and CPAs that make use of WSDL for describing MEPs between a sender and a receiver is provided by extensions to the DocExchange components. Because each DocExchange module pertains to some aspect of an ebXML Action. WSDL provides message descriptions from the standpoint of the service and so for the most commonly used MEPs

 

WSSenderBinding

The WSSenderBinding element describes properties related to sending messages by means of web services. The  WSSenderBinding element MUST include the WSDLOperation element

WSSenderBinding/@version

Version attribute is initially 3.0 to indicate that semantics are given as part of CPPA version 3.0.

 

WSReceiverBinding

The WSReceiverBinding element describes properties related to receiving messages using the Web Services Message Service. The WSReceiverBinding element is an alternative to the ebXMLReceiverBinding element and MUST include the WSDLOperation element

WSReceiverBinding/@version

Version attribute is initially 3.0 to indicate that semantics are given as part of CPPA version 3.0.

WSDLOperation/@version

The REQUIRED version attribute identifies the version of the WSDL specification being used.

WSDLOperation/@operationRef

The REQUIRED operationRef attribute provides an Xpointer fragment identifier to the wsdl operation [WSDL20] or to the wsdl portType [WSDL11],[WSDL11Ref].

WSDLOperation@messageRef

The REQUIRED messageRef attribute provides a list of Xpointer [XPOINTER] fragment identifiers are used for this reference.  For [WSDL11], the relevant wsdl:parts of wsdl:message should be referenced. For [WSDL20], the relevant global element declarations will be referenced

each of the form:

wsdl.interfaceMessageReference(interface/operation/message)

WSDLOperation@faultRefList

The IMPLIED faultRef attribute provides a list of Xpointer [XPOINTER] fragment identifiers are used for this list of  references each of the form: wsdl.interfaceFaultReference(interface/operation/message/fault)

SenderPolicy

Container for WS-Policy that applies to the Action of the ActionBinding that references this element. In a CPPA, this will be an agreed upon PolicyAlternative that holds between Sender and Receiver for the Action that is bound to this policy. In a CPP, this will be a policy that in canonical form can include many PolicyAlternatives.

ReceiverPolicy

Container for WS-Policy that applies to the Action of the ActionBinding that references this element. In a CPPA, this will be an agreed upon PolicyAlternative that holds between Sender and Receiver for the Action that is bound to this policy. In a CPP, this will be a policy that in canonical form can include many PolicyAlternatives.

SenderPolicy/@version

Version of WS-Policy.

ReceiverPolicy/@version

Version of WS-Policy.

 

 

 

 

B.   Using CPPA for Web Service Agreements

In order to announce capabilities or document agreements about aspects of web service collaboration protocols, web services DocExchange extension modules are added to a CPP or CPA using either the WSSenderBinding or WSReceiverBinding elements. Within these elements, the WSDLOperation and WSDLPolicy elements are used as containers for WSDL 1.1 [WSDL11] and 2.0 [WSDL20] or WS-Policy [WSPolicy] information.

 

Each WSDLOperation only needs to include or reference the “interface” aspects of WSDL. These aspects are found within portType or interface and any QName referenced other elements. (The precise elements needed differ in WSDL versions 1.1 [WSDL11] and 2.0 [WSDL20]).

 

For each ActionBinding, the interface’s operation first needs to be identified. The WSDLOperation/@operationRef uses a URI Reference to identify the operation.

 

This reference is constructed by appending a fragment identifier to the wsdl file location as discussed [WSDL20] or a W3C note [WSDL11Ref] that is constructed using an Xpointer fragment syntax:

 

http://example.org/hello1.wsdl#wsdl.interfaceOperation(Hello/sayHello)

 

where the interface local name “Hello” starts the path, and is followed by the local name of the operation, “sayHello”.


Because an operation can involve both requests and responses, the identification of the specific document that is being sent is specified as the value of the WSDLOperation@messageRef attribute, which contains an Xpointer value indicating the relevant document information. The list of faults is identified by WSDLOperation@faultRef Xpointer fragment identifiers.

 

WSDL content may also be placed verbatim within the WSDLOperation content model. In this case, a bare fragment identifier (beginning with a “#”) indicates that the WSDL is found within the element content, or the

 

The question of how to make use of wsdl:service, wsdl:binding or wsdl extensions is left to the implementations that consume CPAs. It is expected that installed CPAs be checked so that configuration information is consistent.

 

On the wsdl consumer side, the capability to act as a client is marked by an entirely empty WSDLOperation element. An empty element indicates that the client is capable of conforming or agrees to conform with whatever the wsdl specifies pertaining to input, output, and faults.

 

Support for CPPs and CPAs that make use of WSDL for describing MEPs between a sender and a receiver is provided by extensions to the DocExchange components. Because each DocExchange module pertains to some aspect of an ebXML Action. WSDL provides message descriptions from the standpoint of the service and so for the most commonly used MEPs

 

WSSenderBinding

The WSSenderBinding element describes properties related to sending messages by means of web services. The  WSSenderBinding element MUST include the WSDLOperation element

WSSenderBinding/@version

Version attribute is initially 3.0 to indicate that semantics are given as part of CPPA version 3.0.

 

WSReceiverBinding

The WSReceiverBinding element describes properties related to receiving messages using the Web Services Message Service. The WSReceiverBinding element is an alternative to the ebXMLReceiverBinding element and MUST include the WSDLOperation element

WSReceiverBinding/@version

Version attribute is initially 3.0 to indicate that semantics are given as part of CPPA version 3.0.

WSDLOperation/@version

The REQUIRED version attribute identifies the version of the WSDL specification being used.

WSDLOperation/@operationRef

The REQUIRED operationRef attribute provides an Xpointer fragment identifier to the wsdl operation [WSDL20] or to the wsdl portType [WSDL11],[WSDL11Ref].

WSDLOperation@messageRef

The REQUIRED messageRef attribute provides a list of Xpointer [XPOINTER] fragment identifiers are used for this reference.  For [WSDL11], the relevant wsdl:parts of wsdl:message should be referenced. For [WSDL20], the relevant global element declarations will be referenced

each of the form:

wsdl.interfaceMessageReference(interface/operation/message)

WSDLOperation@faultRefList

The IMPLIED faultRef attribute provides a list of Xpointer [XPOINTER] fragment identifiers are used for this list of  references each of the form: wsdl.interfaceFaultReference(interface/operation/message/fault)

SenderPolicy

Container for WS-Policy that applies to the Action of the ActionBinding that references this element. In a CPPA, this will be an agreed upon PolicyAlternative that holds between Sender and Receiver for the Action that is bound to this policy. In a CPP, this will be a policy that in canonical form can include many PolicyAlternatives.

ReceiverPolicy

Container for WS-Policy that applies to the Action of the ActionBinding that references this element. In a CPPA, this will be an agreed upon PolicyAlternative that holds between Sender and Receiver for the Action that is bound to this policy. In a CPP, this will be a policy that in canonical form can include many PolicyAlternatives.

SenderPolicy/@version

Version of WS-Policy.

ReceiverPolicy/@version

Version of WS-Policy.

 

 

cppa-3.0-aug-29-2007.xsd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]