The SCA Web Service binding
specified in this document applies to the services and references
of an SCA composites. It defines the manner in which a
service can be made available as a web service, and in which a
reference can invoke a web service.

This binding is a WSDL-based
binding; that means it either references an existing WSDL binding
or allows one to specify enough information to generate one. When
an existing WSDL binding is not referenced, rules defined in this
document allow one to generate a WSDL binding.

Status:

This document was last
revised or approved by the OASIS Service Component Architecture /
Bindings (SCA-Bindings) TC on the above date. The level of approval
is also listed above. Check the “Latest Version” or
“Latest Approved Version” location noted above for
possible later revisions of this document.

Technical Committee members
should send comments on this specification to the Technical
Committee’s email list. Others should send comments to the
Technical Committee by using the “Send A Comment”
button on the Technical Committee’s web page at http://www.oasis-open.org/committees/sca-bindings/.

For information on whether
any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing
terms, please refer to the Intellectual Property Rights section of
the Technical Committee web page (http://www.oasis-open.org/committees/sca-bindings/ipr.php.

All capitalized terms in
the following text have the meanings assigned to them in the OASIS
Intellectual Property Rights Policy (the "OASIS IPR Policy"). The
full Policy may be found at the OASIS website.

This document and
translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this section are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, including by
removing the copyright notice or references to OASIS, except as
needed for the purpose of developing any document or deliverable
produced by an OASIS Technical Committee (in which case the rules
applicable to copyrights, as set forth in the OASIS IPR Policy,
must be followed) or as required to translate it into languages
other than English.

The limited permissions
granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.

This document and the
information contained herein is provided on an "AS IS" basis and
OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any
OASIS Party or any other party that believes it has patent claims
that would necessarily be infringed by implementations of this
OASIS Committee Specification or OASIS Standard, to notify OASIS TC
Administrator and provide an indication of its willingness to grant
patent licenses to such patent claims in a manner consistent with
the IPR Mode of the OASIS Technical Committee that produced this
specification.

OASIS invites any party to
contact the OASIS TC Administrator if it is aware of a claim of
ownership of any patent claims that would necessarily be infringed
by implementations of this specification by a patent holder that is
not willing to provide a license to such patent claims in a manner
consistent with the IPR Mode of the OASIS Technical Committee that
produced this specification. OASIS may include such claims on its
website, but disclaims any obligation to do so.

OASIS takes no position
regarding the validity or scope of any intellectual property or
other rights that might be claimed to pertain to the implementation
or use of the technology described in this document or the extent
to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to
identify any such rights. Information on OASIS' procedures with
respect to rights in any document or deliverable produced by an
OASIS Technical Committee can be found on the OASIS website. Copies
of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this OASIS
Committee Specification or OASIS Standard, can be obtained from the
OASIS TC Administrator. OASIS makes no representation that any
information or list of intellectual property rights will at any
time be complete, or that any claims in such list are, in fact,
Essential Claims.

The names "OASIS" is a
trademark of OASIS, the owner and developer of this specification,
and should be used only to refer to the organization and its
official outputs. OASIS welcomes reference to, and implementation
and use of, specifications, while reserving the right to enforce
its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php
for above guidance.

The SCA Web Service
binding specified in this document applies to the services and
references of composites [SCA-Assembly]. It defines the
manner in which a service can be made available as a web service,
and in which a reference can invoke a web service.

This binding is a
WSDL-based binding; that means it either references an existing
WSDL binding or allows one to specify enough information to
generate one. When an existing WSDL binding is not referenced,
rules defined in this document allow one to generate a WSDL
binding.

The Web Service binding
can point to an existing WSDL [WSDL] document, separately authored,
that specifies the details of the WSDL binding and portType schema
to be used to provide or invoke the web service. In this case
the SCA web services binding allows anything that is valid in a
WSDL binding, including rpc-encoded style and binding
extensions. It is the responsibility of the SCA system
provider to ensure support for all options specified in the
binding. Interoperation of such services is not
guaranteed.

The SCA Web Service
binding also provides attributes that can be used to provide the
details of a WSDL SOAP binding. This allows a WSDL document
to be synthesized in the case that one does not already
exist. In this case only WS-I compliant mapping is
supported.

In most cases it is
expected that a binding applied to a composite’s reference
will point to an existing WSDL document that describes the web
service to be invoked. The binding applied to a
composite’s service may use either approach.

The
SCA Web Service binding can be further customized through the use
of SCA Policy Sets. For example, a requirement to conform to
a WS-I profile [WSI-Profiles] could be represented with a policy
set.

The Web Service binding element is defined by the following
pseudo-schema.

<binding.ws name="xs:NCName"

requires="list of xs:QNames"

uri="xs:anyURI"

wsdlElement="xs:anyURI"?

wsdli:wsdlLocation="list of
xs:anyURI pairs"?

...>

<wsa:EndpointReference>...</wsa:EndpointReference>*

...

</binding.ws>

·/binding.ws/@name- as defined in the SCA Assembly Specification
[SCA-Assembly].

·/binding.ws/@requires- as defined in the SCA Assembly Specification
[SCA-Assembly].

·/binding.ws/@uri- the resolution algorithm of Section 2.1 below
describes how this attribute is interpreted.

·/binding.ws/@wsdlElement– optional attribute that specifies the
URI of a WSDL element. The use of this attribute indicates that the
SCA binding points to the specified element in an existing WSDL
document. The URI can have the following forms:

oService:

<WSDL-namespace-URI>#wsdl.service(<service-name>)

In this case, all the endpoints in the WSDL Service that
have equivalent portTypes with the SCA service or reference must be
available to the SCA service or reference.

oPort (WSDL 1.1):

<WSDL-namespace-URI>#wsdl.port(<service-name>/<port-name>)

In this case, the identified port in the WSDL 1.1 Service
must have an equivalent portType with the SCA service or
reference.

oEndpoint (WSDL
2.0):

<WSDL-namespace-URI>#wsdl.endpoint(<service-name>/<endpoint-name>)

In this case, the identified endpoint in the WSDL 2.0
Service must have an equivalent portType with the SCA service or
reference.

oBinding:

<WSDL-namespace-URI>#wsdl.binding(<binding-name>)

In this case, the identified WSDL binding must have an
equivalent portType with the SCA service or reference. In
this case, the endpoint address URI for an SCA reference MUST be
provided by either the@uriattribute on the binding or a
WS-AddressingEndpointReferenceelement,
except where the SCA Assembly specification states that the@uriattribute
is optional. The endpoint address URI for an SCA service or
the callback element of an SCA reference is determined as specified
in section 2.1. For thecallbackelement of an SCA
service, the binding MUST NOT specify an endpoint address URI or a
WS-Addressing EndpointReference..

·/binding.ws/@wsdli:wsdlLocation– optional attribute
that specifies the location(s) of the WSDL document(s) associated
with specific namespace(s). This attribute can be specified in the
event that the <WSDL-namespace-URI> in the
‘endpoint’ attribute is not dereferencable, or when the
intended WSDL document is to be found at a different location than
the one pointed to by the <WSDL-namespace-URI>. The use
of this attribute indicates that the WSDL binding points to an
existing WSDL document. The semantics of this attribute are
specified in Section 7.1 of WSDL 2.0 [WSDL].

·/binding.ws/wsa:EndpointReference– optional WS-Addressing [WS-Addr]
EndpointReference that specifies the endpoint for the service or
reference. When this element is present along with the@wsdlElementattribute on the parent element, the@wsdlElementattribute value
MUST be of the ‘Binding’ form as specified above, i.e.
<WSDL-namespace-URI>#wsdl.binding(<binding-name>).

·/binding.ws/@{any}-
this is an extensibility mechanism to allow extensibility via
attributes.

·/binding.ws/any– this is an extensibility mechanism to
allow extensibility via elements.

The rules for resolving
the URI at which an SCA service is hosted, or SCA reference
targets, when used with binding.ws (in precedence order)
are:

1.The URIs in the endpoint(s) of the referenced
WSDL
or
The URI specified by thewsa:Addresselement of
thewsa:EndpointReference,

2.The explicitly stated URI in the@uriattribute
of thebinding.wselement, which may be relative,

3.The implicit URI as defined by the Assembly
specification

The URI in the WSDL
endpoint or in thewsa:Addressof an EPR may be
a relative URI, in which case it is relative to the URI defined in
(2) or (3). Thewsa:Addresselement can be
the empty relative URI, in which case it uses the URI defined in
(2) or (3) directly. This allows the EPR writer to specify
reference parameters, metadata and other EPR contents while
allowing the URI to be chosen by the deployer.

To reference a WSDL
document and also specify an EPR, the@wsdlElementattribute must
refer to a binding element in the WSDL and not an endpoint or
service.

Whenbinding.wsis
used on a service or reference with an interface that is not
defined byinterface.wsdl, then a WSDL
interface for the service or reference is derived from the
interface by the rules defined for that interface
type.

For example, forinterface.java,
the mapping to a WSDL portType is as defined in the SCA Java Common
Annotations and API Specification [SCA-JCAA].

binding.wsimplementations may
use appropriate standards, for example WS-I AP 1.0 or MTOM, to map
interface parameters to binary attachments transparently to the
target component.

Any service with one or
more web service bindings with HTTP endpoints SHOULD return a WSDL
description of the service in response to an HTTP GET request with
the “?wsdl” suffix to that HTTP endpoint. If none
of the web service bindings have HTTP endpoints, then some other
means of obtaining the WSDL description of the service should be
provided. This may include out of band mechanisms, for
example publication to a UDDI registry.

Refer to section 4 for a
detailed definition of the rules that SHOULD be used for generating
the WSDL description of an SCA service with one or more web service
bindings.

SCA runtime implementations may
provide additional metadata that is associated with a web service
binding, for example to enable JAX-WS [JAX-WS] handlers to be
executed as part of the target component dispatch. The
specification of such metadata is SCA runtime-specific and is
outside of the scope of this document.

When a Web Service
binding is specified using the wsdlElement attribute, the details
of the binding are specified by the WSDL element referenced by the
value of the attribute. WSDL elements allow for extensibility via
elements as well as attribute. The Web Service binding allows the
use of such extensibility in WSDL. Note that as a consequence of
this, when using this form of Web Service binding, it is not
possible to determine whether the binding is supported by the SCA
runtime without parsing the referenced WSDL element and its
dependent elements.

The SCA runtime MUST raise
an error if the web service binding is configured with a policy
intent(s) that conflicts with a binding instance's
configuration. For example, it is an error to use the SOAP
policy intent

The following snippets
show the sca.composite file for the MyValueComposite file
containing the service element for the MyValueService and reference
element for the StockQuoteService. Both the service and the
reference use a Web Service binding.

This example shows a
service and reference using the SCA Web Service binding, using
existing WSDL documents in both cases. In each case there is a
single binding element, whose name defaults to the
service/reference name.

The service’s
binding is defined by the WSDL document associated with the given
URI. This service must conform to WS-I Basic Profile
1.1.

The reference’s
first binding is defined by the specified WSDL service in the WSDL
document at the given location. The reference may use any of
the WSDL service’s ports/endpoints to invoke the target
service. The reference’s second binding is defined by the
specified WSDL binding. The specific endpoint URI to be invoked is
provided via the@uriattribute.

The next example shows the simplest form of
the binding element without WSDL document, assuming all defaults
for portType mapping and SOAP binding synthesis. The service and reference each have a single binding
element, whose name defaults to the service/reference
name.

The service is to be made available at a
location determined by the deployment of this component. It
will have a single port address and SOAP binding, with a simple
WS-I BasicProfile 1.1 compliant binding, and using the default
options for mapping the Java interface to a WSDL portType.

The reference indicates a service to be
invoked which must have a SOAP binding and portType that matches
the default options for binding synthesis and interface
mapping. One particular use of this case would be where
the reference is to an SCA service with a web service binding which
itself uses all the defaults.

<?xmlversion="1.0"encoding="ASCII"?>

<compositexmlns="http://docs.oasis-open.org/ns/opencsa/sca/200712"

name="MyValueComposite">

<servicename="MyValueService">

<interface.javainterface="services.myvalue.MyValueService"/>

<binding.ws/>

...

</service>

...

<referencename="StockQuoteService">

<interface.javainterface="services.stockquote.StockQuoteService"/>

<binding.wsuri="http://www.example.org/StockQuoteService"/>

</reference>

</composite>

The next example shows the use of the
binding element without a WSDL document, with multiple SOAP
bindings with non-default values. The SOAP 1.2 binding name
defaults to the service name, the SOAP 1.1 binding is given an
explicit name. The reference has a web service binding which
uses SOAP 1.2, but otherwise uses all the defaults for SOAP
binding. The reference binding name defaults to the reference
name.

This policy set applies to binding.ws
and provides the conversation intent. The conversation intent is
provided by using WS-ReliableMessaging protocol which has a concept
of a Sequence. This Sequence (which appears as a wsrm:Sequence SOAP
header in the message) is used as a correlation mechanism, on the
wire, to implement conversational semantics.

This section defines the rules that SHOULD
be used for generation of a WSDL document that describes an SCA
service with one or more web service bindings that require a SOAP
binding.

A WSDL document may be generated for an SCA
service with non-SOAP web service bindings, or other bindings. For
non-SOAP web service bindings that do not refer to an existing WSDL
document, or non-web service bindings, the generation rules below
may be considered a template, and a similar approach taken.

A separate WSDL document is generated for
each SCA service. Each has its own unique target
namespace. This is to ensure that bindings on different
services of the same component do not clash. The WSDL service
has one or more ports for each web service binding on the SCA
service that has a SOAP requirement, or that refers to an existing
WSDL binding, depending on the requirements of the web service
binding. Each of those ports has a single binding.

Additional ports and bindings may be
generated in this WSDL document for non-web service bindings, or
web service bindings with non-SOAP requirements. The manner
in which that is done is undefined.

The binding elements themselves may be
generated as defined below, or may be imported from existing WSDL
documents in the case that the web service binding refers to the
binding element of such a document.

The target namespace of the WSDL document,
and of the service, ports and generated binding elements is:

An SCA service has a
single interface. This interface is always imported into the
generated WSDL document. This may be done directly for
WSDL-defined interfaces, or indirectly via a WSDL generated from
the interface type for the service.