SOA with Service Component Architecture and Enterprise Service Bus

Service Component Architecture

We have been creating IT assets in the form of programs and codes since many years, and been implementing SOA architecture. This doesn't mean that we follow a big bang approach and throw away all old assets in place of new. Instead, the success of any SOA effort depends largely on how we can make the existing assets co-exist with new architecture principles and patterns. To this end, Service Component Architecture (SCA) aims at creating new and transforms existing, IT assets into re-usable services more easily. These IT assets can then be rapidly adapted to changing business requirements. In this section, we will introduce SCA and also look into some working samples for the same.

What is SCA?

SCA introduces the notion of services and references. A component which implements some business logic offers their capabilities through service-oriented interfaces. Components may also consume functionality offered by other components through service-oriented interfaces, called service references. If you follow SOA best practices, you will perhaps appreciate the importance of fine-grained tight coupling and coarse-grained loose coupling between components. SCA composition aids recursive assembly of coarse-grained components out of fine-grained tightly coupled components. These coarse-grained components can even be recursively assembled to form higher levels of coarse-grained components. In SCA, a composite is a recursive assembly of fine-grained components. All these are shown in the SCA assembly model in the following screenshot:

SOA with Service Component Architecture and Enterprise Service Bus

Apache Tuscany SCA Java

Apache Tuscany SCA is a sub-project within open-source Apache Tuscany, which has got a Java implementation of SCA. Tuscany SCA is integrated with Tomcat, Jetty, and Geronimo.

SCA Java runtime is composed of core and extensions. The core wires functional units together and provides SPIs that extensions can interact with. Extensions enhance SCA runtime functionality such as service discovery, reliability, support for transport protocols, and so on.

Tuscany SCA Java is available for download at:

SCA Sample Using Tuscany SCA Java

The sample here provides a single booking service with a default SCA (java) binding. The BookingAgentServiceComponent exercises this component by calling three other components that is, FlightServiceComponent, HotelServiceComponent, and CabServiceComponent as shown in the BookingAgent SCA assembly diagram shown below:

SOA with Service Component Architecture and Enterprise Service Bus

Code the Sample Artifacts

The sample consists of two sets of artifacts. The first set is the individual fine-grained service components. The second set is the coarse-grained service component, which wires the referenced fine-grained service components.

Code Fine-Grained Service Components

There are three fine-grained service components whose code is self explanatory and are listed below:


public interface IFlightService{ 
String bookFlight(String date, int seats, String flightClass);
public class FlightServiceImpl implements IFlightService{
public String bookFlight(String date, int seats, String flightClass){
return "Success";


public interface IHotelService{ 
String bookHotel(String date, int beds, String hotelClass);
public class HotelServiceImpl implements IHotelService{
public String bookHotel(String date, int beds, String hotelClass){
return "Success";


public interface ICabService{ 
String bookCab(String date, String cabType);
public class CabServiceImpl implements ICabService{
public String bookCab(String date, String cabType){
return "Success";

Code BookingAgent Service Component

BookingAgentServiceComponent depends on three referenced service components, which are the fine-grained service components listed previously. They are initialized by the dependency injection by the SCA runtime. Also, for the actual business method invocation, the call is delegated to the referenced service components as shown in the bookTourPackage method in the following code:

public class BookingAgentServiceComponent implements IBookingAgent{
private IFlightService flightService;
private IHotelService hotelService;
private ICabService cabService;
public void setFlightService(IFlightService flightService) {
this.flightService = flightService;
public void setHotelService(IHotelService hotelService) {
this.hotelService = hotelService;
public void setCabService(ICabService cabService) {
this.cabService = cabService;
public String bookTourPackage(String date,
int people, String tourPack){
String flightBooked = flightService.bookFlight(date, people, tourPack);
String hotelBooked = hotelService.bookHotel(date, people, tourPack);
String cabBooked = cabService.bookCab(date, tourPack);
if((flightBooked.equals("Success")) && (hotelBooked.equals("Success")) && (cabBooked.equals("Success"))){
return "Success";
return "Failure";

Code BookingAgent Client

The BookingAgentClient first creates an instance of SCADomain and then gets a reference of the BookingAgentServiceComponent using the name of the configured service component. Then it executes the business method, bookTourPackage.

public class BookingAgentClient{
public static void main(String[] args) throws Exception {
SCADomain scaDomain = SCADomain.newInstance("BookingAgent.composite");
IBookingAgent bookingAgent = scaDomain.getService(IBookingAgent.class, "BookingAgentServiceComponent");
String result = bookingAgent.bookTourPackage("20Dec2008", 5, "Economy");
System.out.println("BookingAgentClient.bookedTourPackage : "+ result);

Build and Run the SCA Sample

You can download the required code for this article from Unzip the file and the code of our interest is in the folder 3216_04_Code. There is also a README.txt file, which gives detailed steps to build and run the samples.

To build the sample in a single command, it is easy for you to go to ch04sca folder and execute the following command:

cd ch04sca

Now, you can execute the BookingAgentClient program by executing:

ant run

You can see that the BookingAgentServiceComponent will delegates calls to book individual line items to the referred service components and if all the individual bookings are done right, the overall transaction is "success". The following figure shows the screenshot of such a success scenario:

SOA with Service Component Architecture and Enterprise Service Bus



Message-Oriented Middleware

We now move on to the next stage of discussion on the different platform level services available for integration. message-oriented middleware (MOM) is the main aspect we need to discuss in this context.

What is MOM?

Just like using sockets for Inter-Process Communications (IPC), we use messaging when multiple processes need to communicate with each other to share data. Of course we can get the same effect when we use files or use a shared database for data level integration. But at times we may also require other Quality of service (QoS) features, a few amongst them will be described later. Thus, a MOM manages the movement of messages between systems connected by a network in a reliable fashion by separating the message sending step from the message receiving step so that the message exchange takes place in a loosely coupled and detached manner. The dynamics of message delivery in a MOM is shown in the following figure:

SOA with Service Component Architecture and Enterprise Service Bus

Here, the message delivery happens in the following steps:

  • The sender process will just 'fire and forget' the message.
  • The MOM will 'store and forward' the message.
  • The receiver process will 'asynchronously receive' the message later.

Since the entire process happens in stages, even if one of the players in one of these stages is not ready for the message transmission, it won't affect the previous stages or the players involved there.

Benefits of Using MOM

MOM will have a set of features which makes it different from other style of communications such as RPC or Sockets, which may be required by some class of applications. Let us now look into some of these features.

  • Asynchronous Style of communication: In MOM communications, a sender application after sending the message need not wait for either the sending of the message to complete or to get a response from the receiving applications. Both these after effects can be affected later, perhaps in a different thread of execution. This will increase application responsiveness.
  • Platform or Language level interoperability: The world is never ideal, and we never have the luxury to always work with cutting edge technologies alone or to chose the platform or language of choice of all interconnecting systems. Sometimes there may be legacy systems, while sometimes there may be SOA-based web service interfaces to interconnect. Whatever be the case, a MOM allows them all to communicate through a common messaging paradigm. This universal connectivity is sometimes called as the Message Bus pattern.
  • Application down times: Applications interconnecting together can sit in any geography or in any time zone, and all of them will have their own down times too. Hence, if a sender application sends some message to a receiver and the receiving application is not up at that time, the message shouldn't get lost. Further, when the receiver comes up the next time, it should receive the message once and exactly once. An MOM, with it's store and forward capability will give the maximum flexibility for interacting systems to exchange messages at their own pace.
  • Peak time processing and Throttling: For a receiving application, there may be peak hours of the day during which it cannot process further request messages. Any further processing might degrade even the undergoing request processing. Hence, some kind of admission control or queuing up of additional requests to be processed further is required. Such mechanisms are the norm for a MOM with its store queues.
  • Reliability: Message stores are introduced at multiple stages in the message delivery path. At the sender's end and at the receiver's end, message stores will guarantee staged message delivery which guarantees message reliability in stages. So, if a step in the message delivery fails, the step can be replayed retrieving the message again from the previous step (or previous stage message store).
  • Mediating services: By using a MOM, an application becomes disconnected from the other applications. One application needs to reconnect only to the messaging system, not to all the other messaging applications it need to interconnect with. The applications are thus loosely coupled, still interconnected.

All the above features distinguish MOM from its counterpart styles of message interactions, which we leverage in many architectural patterns such as the Enterprise Service Bus, which we shall describe next.

Enterprise Service Bus

Enterprise Service Bus (ESB) is an architectural style for integrating systems, applications, and services. ESB provides a technology stack which acts like an integration bus to which multiple applications can talk. So, if two or more applications need to talk to each other, they don't need to integrate directly, but only need to talk to the ESB. The ESB will do the mediation services on behalf of the communicating applications, which may or may not be transparent to these communicating applications.


In order to understand ESB better, we need to understand the technical context under which we have to discuss this concept. The context is Enterprise Application Integration (EAI), which deals with the sharing of data and processes, amongst connected systems in an enterprise. Traditionally, we have been doing EAI to do integration. EAI defines connection points between systems and applications. But when we consider integration in the context of SOA, we need to think more than just integration—we need to think in terms of services and service-based integration. Services expose standards, and if there is a way to leverage this standardization in services in defining the integration points too, then it would open up new possibilities in terms of standard connectors and adaptors.

Before we get into the details of ESB, it makes sense to compare and contrast it with other integration architectures as well. In EAI, the Point-to-Point, and the Hub and Spoke architectures are frequently used in many bespoke solutions. They are used in many vendor products too. These architectures are schematically shown in the following figure:

SOA with Service Component Architecture and Enterprise Service Bus

In Point-to-point, we define an integration solution for a pair of applications. At the integration points, we have tight coupling, since both ends have knowledge about their peers. Each peer combination need to have its own set of connectors. Hence, the number of connectors increases as the number of applications increases. Whereas in the Hub and Spoke architecture, we have a centralized hub (or broker) to which all applications are connected. Each application connects with the central hub through lightweight connectors. The lightweight connectors facilitates for application integration with minimum or zero changes to the existing applications.

Now, we will look into the Enterprise Message Bus and the Enterprise Service Bus architectures.

SOA with Service Component Architecture and Enterprise Service Bus

The Enterprise Message Bus makes use of the MOM stack and toolset to provide a common messaging backbone for applications to interconnect. Sometimes, the applications have to use adapter which handles scenarios such as invoking CICS transactions. Such an adapter may provide connectivity between the applications and the message bus using proprietary bus APIs, and application APIs.

When you move from a traditional MOM to the ESB-based architecture, the major difference is that the applications communicate through a Service Oriented Architecture (SOA) backbone. This backbone is again built over the common MOM, but it provides Intelligent Connectors. These Intelligent Connectors are abstract in the sense that they only define the transport binding protocols and service interface, not the real implementation details. They are intelligent, because they have logic built-in along with the ESB to selectively bind to services at run time. This capability enhances agility for applications by allowing late binding of services and deferred service choice. Moreover, since these intelligent connectors are deployable in the ESB runtime, they are even available as COTS (component off the shelf) libraries. This means that the ESB will open up a market for vendors to build and sell connectors for proprietary EIS systems, which will expose standard interfaces outside the ESB.

Java Business Integration

Java Business Integration (JBI) provides a collaboration framework which provides standard interfaces for integration components and protocols to plug into, thus allowing the assembly of Service Oriented Integration (SOI) frameworks following the ESB pattern. JBI is based on JSR 208, which is an extension of Java 2 Enterprise Edition (J2EE) and is specific for JBI Service Provider Interfaces (SPI). SOA and SOI are the targets of JBI and hence it is built around WSDL. Integration components can be plugged into the JBI environment using a service model-based on WSDL.

For readers who would like to delve deep into Java Business Integration, you are advised to refer to Service Oriented Java Business Integration by Binildas A. Christudas ISBN: 1847194400 published by Packt Publishing.


Project OpenESB is an open-source implementation of JSR-208 (JBI) hosted by community and is available for download at OpenESB allows easy integration of web services thus creating loosely coupled enterprise class composite applications.

OpenESB Architecture provides the following salient features, which distinguishes itself from other closed ESB solutions available in the market today:

  • Application Server support: OpenESB has got good integration with Glassfish application server, thus enabling the integration components to leverage the reliability, scalability, resiliency, deployment, and management capabilities of the application server.
  • Composite application support: In OpenESB, we can use BPEL and similar composite application support tools to create composite applications which are self-contained artifacts that contain other sub-artifacts.
  • Composite Application Editor: OpenESB comes with Composite Application Editor that helps the user 'wire-together' and create new Composite Applications from fine-grained services.
  • JBI Bus: The JBI Bus provides a pluggable infrastructure which can host a set of integration component, which can integrate various types of IT assets in the enterprise. The JBI bus provides an in-memory messaging bus called the Normalized Message Router (NMR). It is through this NMR the messages which are normalized and in standard abstract WSDL format flows.
  • Service Engines and Binding Components: JBI supports two types of components, such as Service Engines and Binding Components. Service Engines provide business logic and transformation services to other components, as well as consume such services. Binding components provide services external to the OpenESB environment available to the NMR.
  • Business Logic Units: These are processing units similar to a BPEL component which can orchestrate the services available at the ESB and provide higher level of business process functionality again at the ESB.
  • Global Service Collaboration Networks: OpenESB supports for a services fabric style of service assembly which is a kind of service virtualization which divides the organization's information assets into "Virtual Services" without regard to the transport or binding protocol of the actual implementation components.
  • Monitoring: OpenESB also provides the ability to centrally monitor, manage, and administer the distributed runtime system of the ESB.

Another noticeable factor which advocates the popularity of OpenESB is the huge list of components and library support available in the industry which can plug easily into the OpenESB JBI infrastructure, a part of which is shown in the following screenshot taken from the OpenESB website:

SOA with Service Component Architecture and Enterprise Service Bus


SOA is not a single product or single reference architecture to be followed, but is all about best practices, reference architectures, processes, toolsets, and frameworks along with many other things which will help you and your organization increase the responsiveness and agility of your enterprise architecture. In this article we had a look at the Service Component Architecture (SCA). We also discussed how Enterprise Service Bus (ESB) provides you with a wider framework upon which you can enable your integration points for open and flexible information flow.


You've been reading an excerpt of:

Service Oriented Architecture with Java

Explore Title