A challenge facing many organizations is how to quickly and effectively react to frequent changes in business requirements, whilst improving productivity and reducing costs. To achieve this, you need a flexible infrastructure that can meet the demands of a changing marketplace and seize emerging opportunities. To address this challenge, Service Oriented Architecture (SOA) promotes an architectural approach that replaces rigid proprietary systems with heterogeneous, "loosely-coupled" services. The Service Component Architecture (SCA), along with Service Data Objects (SDO), makes this architectural concept a reality and provides the programming model to build SOA solutions for agile businesses.

SCA is a powerful and simple business level programming model that extends prior approaches to be able to implement services based solutions. SCA defines how services can be described, assembled, and deployed in a meta-data driven fashion, independent of an implementation language and a deployment platform. The approach is based on the idea that each business function consists of one or more components brought together into a composite application. These, in turn, are composed into a network of services that create specific business solutions.

This article describes some of the key values of SCA by modeling an SOA based solution for a fictitious company called MostMortgage. We shall assume a simple business process in which an applicant signs up for a loan and provides his or her identity information and loan requirements. MostMortgage evaluates the new applicant based on their credit approval and searches for an appropriate mortgage rate.

By using the SCA programing model, MostMortgage's developer can build a solution for this problem quickly and effectively, separating the business logic from technology concerns and enabling re-use of existing applications. In this case, there is already a well understood credit appliction that can be re-used (CreditCheck); and MostMortgage has a subscription to a Web service that searches for the best loan rates (FindRates).

The solution developer first completes the following steps:

1)  Define the business logic for LoanApproval and AccountVerification;
2)  Define references for each component (this identifies what other services, if any, the component is dependent on);
3)  Define the services provided by each component, if any;
4)  Assemble the components and choose the binding to be used.

The MostMortgage solution (as shown in Figure 1) is then ready for deployment.

Components can be implemented in any language supported by an SCA runtime, including BPEL, Java, Ruby, and C++. Outside of any program logic, these components can be assembled or "wired" into a composition using any appropriate binding, such as WS-* or JMS.

Let's update the MostMortgage application by making one technology domain change and one business domain change.

First, we improve the security of the calls to the CreditCheck component, which happens to run in a remote data center. The MostMortgage company developer need not be concerned about these new infrastructure requirements. SCA separates infrastructure capabilities from business logic and allows the security requirements to be defined as policies during assembly. The resulting flexibility enables IT infrastructure policies to change at anytime without requiring a re-code.

Secondly, it is decided to introduce a bespoke rate optimization layer in front of the FindRate Web service (see Figure 2). MostMortgage can add value to the white box FindRate service by combining a mortgage account with in-house financial products. Here, the developer is involved, but he is able to reuse his previous work directly in a controlled and modular way by simply extending the assembly to include the new RateOptimizer component.

It is important not to forget the complexity introduced by handling data in such a heterogeneous network of services. A technology called Service Data Objects (SDO) addresses this problem. SDO offers a format-neutral API that provides a uniform way to access data, regardless of how it is physically stored. By using SDO, the solution developer will not pollute a business application with code to handle diverse choices of data access, such as JDBC Result Sets, JCA records, DOM, JAXB, and EJB entities.

SDO supports a disconnected style of data access and can record a summary based on any changes made to data objects. SDO's ability to maintain a summary of the changes made allows data transfers to include only the portion of data that has changed, therefore improving environments where bandwidth is a constraint. The change summary information can be used to resolve data access conflicts and concurrency issues.

SDO supplies a powerful yet simple programming model for data with first class support for XML and the ability to automatically persist data via the use of a Data Access Service (DAS). A DAS allows the data to be stored or retrieved from a relational database or another repository, and helps to link the SDO models to enterprise data storage.

SCA and SDO provide technologies that simplify the development of SOA solutions. SCA and SDO technologies work well together and independently. More detailed information about SCA and SDO will be available in future articles.

The importance of these technologies has led many vendors who experienced customer pain points to collaborate and develop specifications for SCA and SDO, and crystallize best practices that have been utilized for the past few years. More information about the Open SOA collaboration and its many participating vendors can be found at www.osoa.org.

You can try out Java and C++ implementations of the SCA and SDO technologies by visiting the Apache Tuscany open source project at incubator.apache.org/tuscany . Tuscany provides a simple "on ramp" for developers who want to create applications using a service-oriented approach. As an early implementer of SCA and SDO specifications, the Tuscany project is able to provide timely feedback on the specification to the Open SOA collaboration. Other implementations of this technology are also beginning to appear, for example, the PHP PECL SDO project at http://pecl.php.net/package/sca_sdo.

In summary, today's organizations must be able to quickly react to change. SCA promotes flexible and reusable solutions by encouraging componentization and by clearly separating business logic from underlying technology concerns. SCA and SDO independently increase developer productivity by shielding them from infrastructure complexity and the necessity to develop deep infrastructure technology skills. SCA and SDO together provide IT with a flexible model for building SOA based solutions and, more importantly, for effectively and efficiently handling change.