Page 1 of 4   next page »

Many articles have already been written about service-oriented architecture (SOA) and Service Component Architecture (SCA), for example, see references [1] and [2]. In this article we'll focus on a freely available, open source implementation of the Service Component Architecture that provides a simple way to implement SOA solutions. This SCA implementation is being developed in the Apache Tuscany Incubator project. The project started in 2006 and is being used by many who are looking for a simple SOA infrastructure. The recent Tuscany SCA version 1.0, which was released in September 2007, supports the Service Component Architecture specifications 1.0. In addition to implementing the SCA specifications, Tuscany is also a nursery for new ideas. Some of these ideas will find their way into the specifications and some will be regarded as extensions available in Apache Tuscany Incubator. For example, support for Ruby, JavaScript, XQuery, data binding and Web 2.0 are currently extensions beyond the specification.

This article will walk you through what is available in Apache Tuscany Incubator and therefore highlight the benefits of SCA.

Using Tuscany SCA
A Common Approach to Application Construction and Deployment
Enterprise software development is increasingly influenced by technology choices, regulations, competition and expectations for responsiveness to change. Enterprises need the flexibility to adopt new business practices (like outsourcing of mortgage handling by a bank), enforce new regulations, and extend or down-size without much cost (mergers and acquisitions). In addition, as the complexity of the enterprise grows, a common management paradigm becomes a necessity for managing business applications. Service Component Architecture provides a simple programming model to address these challenges. SCA's simple language maps easily to the business. Let's consider we are building a banking application that handles account inquiries. Table 1 maps business-level questions to SCA.

SCA provides a consistent model of distributed applications and of the components from which they are constructed. This model explicitly separates business logic (Component/Services/References) from the details of how a running application is assembled (Composite/Wire) and deployed. This promotes a common terminology and supports a common understanding of the capability of applications and the way those applications work together. This common model also provides the hooks for tooling, governance, monitoring, and management in the service-oriented world.

When it comes to building a solution for real, one of the most important questions is likely to be "how can existing IT infrastructure and skills be used?" Tuscany SCA does not invent new technologies for component implementations (Implementation) and message exchange (Binding). It neither requires you to learn a new programming language nor communications protocols. You are free to leverage your existing investment in applications, technology, and skills as long as suitable support exists in Tuscany SCA. This is not much of a hurdle; Tuscany SCA has a straightforward extensibility model so new or proprietary technologies can easily be included.

The following sections describe Tuscany SCA in the context of three familiar scenarios. It should be noted that Tuscany SCA is not restricted to these scenarios. The sample code and configuration used here can be found in the Tuscany SCA Java distribution [3] and is available under the Apache License [4].

Enterprise Applications
In a typical enterprise, business functions are implemented using various technologies, business data is represented in different formats, and business applications communicate using heterogeneous protocols. It is almost impossible to converge all applications onto one technology stack such as Web services and so it remains difficult and costly to integrate different applications in an enterprise. Enterprises face many challenges including the following.

•  Business applications are tightly coupled with the IT infrastructure and early design decisions have to be made before real deployment.
•  Application developers are forced to learn and understand many technologies beyond business domain knowledge
•  Business logic is polluted and coupled to various technology-specific API calls imposed by the IT infrastructure. It's not easy to write and not easy to change.

SCA separates business services from the concerns related to specific hardware, software and network protocols by providing a unified programming model that allows the SCA runtime to handle these issues transparently. Let's look at a simple business scenario to see how Tuscany SCA can help enterprise application integration. The scenario here is the BigBank demo from the Tuscany SCA distribution [5]. As illustrated in Figure 1, the application comprises a number of assembled components and ultimately returns a total account balance in response to account inquires.

The use of the SCA programming model allows the BigBank developer to decouple the process of designing and creating the scenario from infrastructure concerns. In the BigBank composite, basic units of business logic are modelled as SCA components called AccountComponent, StockQuoteComponent, etc. Their business logic is implemented using Java and various scripting languages. Components are assembled by wiring references to services. Once all business logic is implemented, appropriate bindings are applied to references and services to indicate how the components should communicate.

The XML-based SCA configuration language describes all of the information about loosely coupled enterprise services and the bindings to be used. Since binding information can be changed in the SCA configuration without changing the business logic, the implementation code is not polluted with protocol handling information and, furthermore, bindings can be changed during deployment without impacting the application.

The following SCA configuration shows the AccountService exposed using JSONRPC (binding.jsonrpc) and Web services (binding.ws). The service can easily be made accessible over RMI by simply adding binding.rmi.

<component name="AccountServiceComponent">
    <implementation.java class="bigbank.account.AccountServiceImpl" />

    <service name="AccountService">
       <tuscany:binding.jsonrpc uri="/AccountJSONService" />
       <binding.ws
       wsdlElement="http://bigbank#wsdl.port(AccountService/AccountServiceSoap)" />
    </service>

    ...
</component>

The following SCA configuration shows bindings applied to component references. Again these bindings can be changed or augmented without changing the business logic.

<component name="AccountServiceComponent">
    ...
    <reference name="calculatorService">
       <tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService" />
    </reference>

    <reference name="stockQuoteService">
       <binding.ws uri="http://localhost:8081/services/StockQuoteWebService" />
    </reference>
    ...
</component>

Page 1 of 4   next page »