Remote Services
A remote service could be running in a different process on the same physical computer or on a different computer. In the loan approval example we'll now show how it can interact with remote services. We'll first expose CreditCheck as a service in its own right and then we will replace it with an externally provided CreditCheck Web service.

Exposing Components as Remote Services
Let's expand our scenario. Suppose the MostMortgage Company has a business partner who is interested in using the CreditCheck functionality. In response to that, the CreditCheck component can be made into a Web Service that can be accessed by the LoanApproval component or by the business partner. With SCA, this is surprisingly easy and involves simply splitting off the CreditCheck component into a new composite, adding a service element to this new composite file and then wiring the service element to the CreditCheck component that provides the implementation of the service (see Figure 6).

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsdli="http://www.w3.org/2006/01/wsdl-instance" name="CreditComposite">

    <service name="CreditCheckWebService">
       <interface.wsdl interface="http://credit#wsdl.interface(CreditCheck)"
wsdl:wsdlLocation="http://credit wsdl/credit.wsdl" />
       <binding.ws endpoint="http://credit#wsdl.endpoint(CreditCheck
Service/CreditCheckSoapPort)"
conformanceURIs="http://ws-i.org/profiles/basic/1.1"
location="wsdl/credit.wsdl" />
       <reference>CreditCheckServiceComponent</reference>
    </service>

    <component name="CreditCheckServiceComponent">
       <implementation.java class="credit.CreditCheckImpl"/>
    </component>

</composite>

Note that the new service element references a WSDL file to both describe the service interface and describe the binding.

Replacing Local Components with Remote Services
In the previous section we made CreditCheck a remote component. Now we show how MortgageComposite can be changed to reference this remote Web Service. All we have to do is change the SCDL file for the MortgageComposite. We add a reference element named CreditCheckReference to declare the remote CreditCheck Web Service and we rewire the creditCheck reference on the LoanApprovalComponent to this new reference.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="MortgageComposite">

    <component name="LoanApprovalComponent">
       ...
       <reference name="creditCheck">CreditCheckReference</reference>
       ...
    </component>

    <reference name="CreditCheckReference">
       <interface.java interface="mortgage.CreditCheck" />
       <binding.ws endpoint="http://credit#wsdl.endpoint(CreditCheckService/CreditCheckSoapPort)"
location="wsdl/credit.wsdl" />
    </reference>

    ...

</composite>

Note that the reference in SCDL specifies a binding called "binding.ws". The binding information indicates the protocol used to send messages across the wire. The system integrator here has the flexibility to configure any binding that's appropriate to enable secure communication between MortgageComposite and CreditComposite. Our system diagram is now updated as shown in Figure 7.

The CreditCheck Web Service isn't required to be implemented as an SCA component. Suppose that there's an existing CreditCheck Web Service offered by a third party. We can take the same approach to call this Web Service. The only difference is that the WSDL would contain the URL of the hosted Web Service. In the next diagram, the CreditCheck Web Service is provided as an Axis2 service and is deployed in an Apache Tomcat server (see Figure 8).

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="MortgageComposite">

    <component name="LoanApprovalComponent">
       ...
       <reference name="creditCheck">CreditCheckReference1</reference>
       ...
    </component>
    <reference name="CreditCheckReference1">
       <interface.java interface="mortgage.CreditCheck" />
       <binding.ws endpoint="http://credit#wsdl.endpoint(CreditCheckService/CreditCheckSoapPort1)"
location="wsdl/credit.wsdl" />
    </reference>
    ...
</composite>

Multi-Language Extensions
So far we've talked about Java language components and local and remote services but we've talked very little about the alternatives. You may have realized by now that all SCA does, through its SCDL, is describe components and the way that they can be assembled. It doesn't mandate how those components will be implemented or indeed how messages will be passed along the wires that join one component to another. Runtime implementations are free to add new implementation extensions. The Apache Tuscany project has provided extension APIs to make providing new implementation-type support as easy as possible. The Apache Tuscany Java technology SCA runtime implementation currently supports the following implementation types: implementation.java, implementation.javascript, and implementation.ruby. Using the extension mechanism the Tuscany community is currently working on Spring and BPEL implementation types.

The Apache Tuscany C++ SCA runtime implementation currently supports the following implementation types: implementation.cpp, implementation.python, and implementation.ruby.

Currently the PHP SCA runtime implementation only supports SCA components implemented in PHP.

You may have noticed in Figure 8 that we've changed the MortgageCalculator component from Java to use the JavaScript container from the Apache Tuscany Java SCA runtime.

The JavaScript implementation of MortgageCalculator.getMonthlyPayment() is as follows:

function getMonthlyPayment(principal, years, interestRate) {
    var monthlyRate = interestRate / 12.0 / 100.0;
    var p = Math.pow(1 + monthlyRate, years * 12);
    var q = p / (p - 1);
    var monthlyPayment = principal * monthlyRate * q;
    return monthlyPayment;
}

The component-type file (no changes required):

<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

    <service name="MortgageCalculatorService">
       <interface.java interface="mortgage.MortgageCalculator"/>
    </service>

</componentType>

We can now change the Mortgage composite to reference the Javascript MortgageCalculator component as follows:

<component name="MortgageCalculatorJSComponent"
xmlns:js="http://incubator.apache.org/tuscany/xmlns/container/js/1.0-incubator-M2">
    <js:implementation.js script="MortgageCalculator.js" />
</component>

Bindings and Extensibility
The protocols used to transfer messages from one component to another are also extensible. As an example, the Apache Tuscany runtime provides explicit extension APIs to aid the building of new bindings. The Apache Tuscany Java SCA runtime implemen-tation currently supports the following bindings: binding.ws, binding.celtix, binding.jsonrpc, and binding.rmi.

As you have seen, SCA defines an assembly model that can leverage existing technologies. We used the Java and JavaScript languages and communicated with external Web Services. This means SCA can be introduced incrementally into an organization without having to rewrite or replace existing applications. The evolving list of implementation types and bindings available in Apache Tuscany is representative of commonly used technologies and is constantly growing. The implementation and binding extension APIs can be used to build specific extensions where support isn't provided by default.

Quality of Service and Policy
SCA cleanly separates component implementation from the mechanisms that components use to exchange messages. This separation also allows the policies for message transmission to be stated independently of component implementation. So if you require messages transmitted, for example, reliably, within a transaction context or in encrypted form then the addition of statements of policy to the SCDL files will support this. The specifications for these policy statements aren't complete yet but you can see draft versions up on the OSOA site (www.osoa.org/display/Main/Service+Component+Architecture+Specifications).

Accessing SCA Services from Non-SCA Clients
In our MostMortgage example we've already shown that our SCA-based system can expose a service interface for others to call and can call service interfaces provided by others.

In the latter case SCA can call any service that's reachable using a protocol that the SCA runtime supports. We've shown how the CreditCheck Web Service can be provided by some third party and it need not be implemented using SCA. In our example we relied on accessing the WSDL description of the service and used a Web Service (SOAP/HTTP) binding to talk to it.

We haven't demonstrated yet how a non-SCA client can talk to SCA services. In our example we used SCA to expose the CreditCheckComponent for others to call via Web Services. Any Web Service-capable client could then call our service regardless of the technology used to implement the client. SCA does however provide APIs for non-SCA clients to invoke an SCA service locally.

public class MortgageClient {
    public static void main(String[] args) throws Exception {

       // Locate the service using SCA APIs
       CompositeContext context = CurrentCompositeContext.getContext();
       LoanApproval loanApplication = context.locateService(LoanApproval.class,
       "LoanApplicationComponent");
       ...
       // Invoke the service
       boolean result = loanApplication.approve(customer, 200000d, 30);
    }
}

Note that the SCA API class CurrentCompositeContext allows a service to be located by name. This is the component name as it appears in the composite file. The result of this location step is a service instance or proxy that implements the service interface. When a method is invoked by the client code (approve() in this case), the SCA runtime will dispatch the operation parameters to the correct method in the component implementation according to the definitions in the SCDL file.

SDO and DAS
This article has focused on how the Service Component Architecture allows components to be described and assembled into working compositions. There's also a sister technology, Service Data Objects (SDO), that describes a common API for accessing data. This is important to SCA because it allows the Apache Tuscany and PHP SCA runtimes to provide a common API for accessing the messages that arrive at, or are sent from, components. SCA and SDO work well together but can, of course, be used independently. More information and specifications for SDO can be found on the OSOA site (www.osoa.org/display/Main/Service+Data+Objects+Home).

The PHP SDO PECL extension provides an implementation of SDO for PHP. The Apache Tuscany project provides implementations of SDO for the Java language and C++. Both projects provide an implementation of a Data Access Service (DAS) that integrates the SDO data model with data storage systems such as relational databases.

Summary
SCA provides a concise and flexible model for describing and developing SOA applications and addresses the strategic requirements demanded by agile IT environments. The SCA programming model focuses on describing components and the way that they're assembled together. It's inclusive of existing technologies with a primary goal of operating well as an addition to existing heterogeneous environments. This article aimed to provide a broad perspective of Service Component Architecture to intrigue the user to explore the technology further at (www.osoa.org) and experiment with the technology through three available free open source implementations, the Apache Tuscany (http://incubator.apache.org/tuscany/), SCA runtimes for the Java language and C++, and the SCA for PHP (www.osoa.org/display/PHP/SOA+PHP+Homepage) runtime.

Resources

• The Open Services Architecture specification site - www.osoa.org/display/Main/Home
• The Apache Tuscany incubator project - http://incubator.apache.org/tuscany/
• The PHP PECL SOA Project - http://pecl.php.net/package/ sca_sdo and the homepage at
  www.osoa.org/display/PHP/SOA+PHP+Homepage
• The loan approval pplication examples -
  http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/samples.M2/mortgage/