OSOA Home

Introduction

One of the major value propositions of the SCA technology is its support for a middleware-neutral programming model. SCA supports and encourages a model where the developer can focus on building the business logic without worrying about how to provide access to the business logic or how to access other business logic provided elsewhere. Under SCA, instead of intermixing code for the business logic with any middleware specific API, access to the business logic is configured declaratively outside the code. Such an architecture has the benefit of providing needed business agility by catering for many clients with different kinds of access protocol requirements in an efficient manner.
 
Bindings are used by services and references of SCA components. Services use bindings to describe the access mechanism that clients use to call the service. The clients may be another SCA component or a client entirely external to the SCA domain. References use bindings to describe the access mechanism used to call a service provided elsewhere, which may be a service provided by another SCA component or a service which exists outside theernal to SCA.
 
SCA supports the use of multiple different types of bindings. Examples include the SCA default binding, Web service, session EJB, JMS, and JCA. SCA also provides an extensibility mechanism by which an SCA runtime can add support for additional binding types.
 

Overview of the SCA Binding

The SCA binding can be used for service interactions between references and services contained within the SCA domain.  It provides a very simple, easy-to-use way for an assembler to wire a reference to a service within an SCA composite, or at the Domain level.  It tells the SCA runtime to make the connection between the reference and the service, without being prescriptive about how it should be done.  The SCA runtime is then free to use any communication method it has available that is suitable for implementing the wire.  The form of its implementation is not defined by the SCA specification. It can be implemented in different ways by different SCA runtimes, and is therefore not an interoperable binding type. For interoperability, an interoperable binding type such as the Web service binding should be used.
 
As an example, if the SCA runtime finds that the component with the reference is running in the same Java VM as the component with the service, the runtime may choose to implement the wire via an in-memory copy mechanism.  Or if a messaging infrastructure connects the two nodes running the components, it may choose to use messaging infrastructure to transmit operations between a reference and  service.

Overview of Web Services Binding

 
Typically, Web services are described using WSDL. The Web service binding provides a way to integrate an existing WSDL port/endpoint or create a synthesized WSDL port/endpoint to expose a SCA service or wire to an external Web service.

The Web services binding [1] supports both WSDL 1.1 [2] and WSDL 2.0 [3]. There are two ways to use the Web services binding:
 

1. Reference an existing WSDL element, which can be a binding, a WSDL 1.1 port or a WSDL 2.0 endpoint, or a WSDL service.
2. Use SCA Web service binding metadata, including any defaults, to create a synthesized WSDL 1.1 port/WSDL 2.0 endpoint.

In the first option, since the Web services binding references an existing WSDL document, all the features and functionality of WSDL are available to the user. This is meant for advanced users that understand WSDL and also for reusing existing WSDL documents. The second option provides a way to use Web services technology without having to define a WSDL document. The Web services binding provides defaults for SOAP (both SOAP version 1.1 [4] and SOAP version 1.2 [5]) based Web services that are WS-I Basic Profile [6] compliant. This is meant to allow users to create SOAP-based services and references that are interoperable without necessarily authoring a WSDL document.

A sca:binding.ws element provides the capability to point to an existing WSDL port/endpoint using the URI scheme used by WSDL 2.0, provide the WSDL document location and a list of WS-I profiles that the port/endpoint conforms to.
 
The SCA Web Service binding can be customized through the use of intents and SCA Policy Sets. For example, requirements for which SOAP version to use or a requirement to conform to a WS-I profile [6] can be represented by means of intents linked to suitable policy set(s), for example.
 

Web Service Binding Examples

Below is an example of a Web services binding that is used to reference a Web service that is external to the SCA system and has an existing WSDL document that describes the Web service. The service's binding is defined by the WSDL document associated with the given URI at the given location.

<reference name="StockQuoteReference1">

    <interface.wsdl interface="http://www.stockquote.org/StockQuoteService#wsdl.interface(StockQuote)"/>

    <binding.ws wsdlElement="http://www.stockquote.org/StockQuoteService#wsdl.service(StockQuoteService)"
        wsdli:wsdlLocation="http://www.stockquote.org/StockQuoteService
            http://www.stockquote.org/StockQuoteService.wsdl" />

</reference>

The next example does not use a WSDL document. 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.

<reference name="StockQuoteReference1">

    <interface.wsdl interface="http://www.stockquote.org/StockQuoteService#wsdl.interface(StockQuote)"/>

    <binding.ws uri="http://www.sqs.com/StockQuoteService" requires="soap/1.2"/>

</reference>

Overview of the JMS Binding

Messaging bindings are a common pattern of behavior where the communications protocol is handled by a messaging provider.  Typically messaging providers do not have an inbuilt way of defining interfaces and operations that correspond to that defined in a WSDL port type.  Messages have a format which correspond in some way to the schema of an input or output message of an operation in the interface of a service or reference, however some means is required in order to identify the specific operation and map the message information in to the required form.  Messaging bindings define the manner in which operations within SCA interfaces are selected based on message content, and the manner in which messages are mapped to the input and output types for the selected operation.
 
The JMS binding [10] is an example of a messaging binding based on the Java Messaging Service API which describes the resources involved in delivering and receiving messages using JMS concepts, such as Destinations and ConnectionFactories.  The JMS allows use of Queue and Topic type destinations, and supports both JCA-based and ASF-based JMS providers.  It also specifies the way in which JMS messages are exchanged when using bidirectional interfaces and conversations, as there is no standard way to do this within JMS itself. 
 
The JMS binding allows JMS headers and user properties to be set on a per-operation basis.
 
In addition to describing the connection to messaging resources, the JMS binding specifies the default operation selection and mapping of messages to input/output types.  SCA providers may allow extensions for custom behavior.
 
The JMS binding is most suited to a Java environment, given that JMS is a Java API.  Other environments may map the JMS concepts to their native concepts, or define alternative messaging bindings using a similar approach.
 

Example JMS Binding

The following example shows the JMS binding being used on a reference with no further attributes or elements.  In this case, it is left to the deployer to identify the resources to which the binding is connected:

<reference name="StockQuoteService">
    <interface.java interface="StockQuoteService" />

    <binding.jms/>

</reference>

This second example shows the JMS binding being used on a service where it identifies existing JMS messaging resources such as Queues and activation specification:

<service name="StockQuoteService">

    <interface.java interface="StockQuoteService" />

    <binding.jms>

        <destination name="MyValueServiceQ" create="never"/>
        <activationSpec name="MyValueServiceAS" create="never"/>

     </binding.jms>

</service>

References

[1] SCA Web Services Binding Specification
[2] WSDL 1.1 Specification
[3] WSDL 2.0 Specification
[4] http://www.w3.org/TR/soap12/SOAP 1.1 Specification
[5] SOAP 1.2 Specification
[6] WS-I Basic Profile
[7] WS-Addressing Specification
[8] WS-Policy Specification
[9] SCA JMS Binding Specification
[10] SCA JMS Specification
[11] SCA JCA Binding Specification