[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] 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”.
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
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”.
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]