This article is more than 1 year old
The Holy Grail of services: SCA
Service Component Architecture as a way to build SOA
How many times lately have you come across a column on Service Oriented Architecture (or SOA)? Or an article telling you that SOA is the next big thing? Or that SOA is the way we should all be building systems?
Personally, it seems to happen to me all the time. Recently, I was in a hotel in Frankfurt, and was waiting in the lobby to meet up with a colleague for dinner, when I picked a business magazine form a table in the lobby. The headline article on the front of the (English language) magazine was all about SOA!
So SOA is big news – we can all testify to that, but what exactly is SOA? More importantly, at least form our perspective might be the question “how should we be building SOA-based systems” (at least when using Java)?
In this first of a two columns I will try to address these questions and in particular to introduce Service Component Architecture (or SCA) as a way to build SOA systems in Java (although it should be noted that SCA is not limited to Java). The next column will look at an example of a SCA application.
Service Oriented Architectures
SOA is an architectural approach to building software systems that focuses on business level services and the invocation mechanisms used to call these services. Within this architecture, each of the services is an independent functional entity that possesses a well-defined, invocable, interface. These services can each be called in defined sequences to form business processes.
The keys aspects relating to SOA are:
- That the services provided are at the business level – not at a low level functional API like level.
- That the services are capable of being invoked via external systems.
- That the business process behind the system can be represented explicitly and used as the basis of the systems flow-of-control.
Interestingly, as I am sure many of you will be thinking “none of this is a new concept” – indeed far from it. In fact, the concept of high level services being invoked to implement business level processes has been around almost as long as there have been networked systems to integrate. However, previous attempts required large infrastructures, complex systems with heavy weight integration architectures that tended to reduce take-up.
The current SOA based momentum is based around a set of standards which collectively define Web Service-based SOA. These standards build upon the underlying web services standards and extend them with standards that provide for reliable messaging, transactions, security and (with BPEL) business processes themselves. These standards are admittedly in a state of flux, with new standards emerging, other standards nearing maturity and initial standards even fixed – already there are standards that support invocation, discovery, business processes, transactions, compensations, security etc. One thing is clear, that Web Service-based SOA is here and that the major application server vendors within the Java world are investing heavily in its development.
So services are here to stay and are currently the must-have technology of today! But how do you build them? One way is to do it all yourself – using low level web services toolkits and frameworks (such as Apache AXIS or Suns Java Web Services Developer Pack and Java API for XML-based RPC (JAX-RPC) 1.1). However, doing this involves working at the underlying enabling technologies level. While this is certainly not impossible (and many people work very successfully at this level) it requires detailed knowledge of the various tools and how they work together to implement a service.
An alternative approach is offered by the Service Component Architecture (or SCA) standard. SCA represents a broad industry effort (involving organisations such as IBM, BEA, Oracle, RedHat etc.) to develop a standard that simplifies the creation, implementation and deployment of Services within a Service Oriented Architecture. This can be combined with the Service Data Objects (SDO) specification that aims to provide simplified data exchanges to simplify greatly the construction of SOA based systems.
Figure 1 illustrates the relationship between SCA and the implementation of the service on the one hand, and the underlying technologies used to access a service on the other. That is, it acts as a framework that abstracts away much of the detail of the underlying communications or invocation technologies from the creation of the service and how it is implemented. As such, it is analogous to the way that RMI hides the details of how the underlying network communication occurs and how a remote method call is actually realised.
Service Component Architecture
Essentially, Service Component Architecture is nothing more than a set of specifications that describes a model for the construction of services. These services can be based on existing business logic implementations (for example existing Java EJBs or POJOs) or as assemblies of other services.
Key SCA Concepts
There are a number of key concepts within SCA, including:
- The underlying implementation class
- The Service Component
- Service Assembly
We will discuss each of these on Page 2.
SCA is designed to support implementations of many different technologies – it is not just Java – although that is our focus here. Whatever implementation technology is used, it is the implementation code that determines the Services, References and Properties that are then configured by a Component within a Composite. That is, an implementations interface (for example, in our case a java interface) can be used to define the services a component makes available. In turn, the properties a JavaBean makes available can be used as the properties of the component to allow for dynamic configuration of the service.
This is the basic building block of SCA. A component is defined declaratively and is a configured instance of an implementation. This definition specifies the services the component makes available, the implementation that these services relate to (e.g. a Java class), properties that can be used of configure the service at run time as well as policies for security and transactional support.
Figure 2 illustrates the core concepts behind an SCA component. These core concepts are:
- The implementation class for example implements in Java.
- The services it makes available which can be automatically generated form a Java interface or Java class.
- The properties used to configure the implementation class (derived from set and get methods on the implementation class).
- Service references which are references to other services used by the component that will be resolved at deployment time.
As you might expect, it is also possible to create a new service form existing services – thereby creating a higher-level service. These composite services still have the set of service interfaces that they define, properties that can be used to configure the Composite service and references to other services. However, in these composite services, the implementation is provided by other services, wired together in specific ways.
Figure 3 illustrates a typical Composite assembly, which contains:
- Two components, one of which is itself a composite (Composite A) and one which directly contains the implementation code (Component B).
- It offers a service on the left which is derived from the service presented by Composite A.
- It declares business dependencies via Service References which must be satisfied via wiring made outside the composite. Essentially, this is a call from the implementation class within Component B to another service.
- Wires connect services/references together – these show how services and references are connected.
- Properties. A composite’s properties are an aggregate of its inner components and composites properties.
When a service is deployed, it’s bound to an access mechanism such as web services accessed over SOAP or JMS etc. Thus, it is at this point that the low-level communications protocols are handled. How the semantics of synchronous, asynchronous and asynchronous with call back invocation in the particular protocol is also handled at this point.
There are currently at least two SCA implementations that you might like to take a look at. The first is the Apache Tuscany incubator project – you can download it here. This project provides a reference implementation of the core features of SCA. At present, SCA supports Java and C++ (although it should be noted that the SCA standard is intended to support a wider range of languages and environments). Tuscany also provides an implementation of the Service Data Object (SDO) standard that is used within SCA to handle different forms of data within services. It also provides an implementation of the Data Access Service (DAS) that provides a service interface to relational databases.
IBM offers another implementation of the SCA standard, as part of its Feature Pack for SOA for WebSphere 6.1. This is built on top of Tuscany and can be viewed as a customisation of Tuscany that simplifies SCA projects when deployed to WebSphere.
SCA or Service Component Architecture moves the level of abstraction up for the creation of Services changing the focus of the developer to that of service creator rather than that of integrator (for various access technologies). ®