Service Component Architecture in Real Life

About you:

About this article:
We are going to do a walk through of two samples of how to get started with SCA. First we'll write a small SCA application that uses the services provided by an SCA composite to do something useful. Having covered that, we'll show you how to take some code and package it as a composite so it can be used in SCA applications.

Introduction
In Service Component Architecture, we write service-oriented applications that use services provided by SCA composites. In the SCA component model, the smallest piece of accessible code is a component; a composite is composed of components. (To quote analyst David Chappell, if components are the atoms of SCA, then composites are molecules.) The composite includes the details of the code, the services provided by that code, and references to any other pieces of code the composite uses.

One of the great benefits of SCA is that the skills used to invoke, assemble and create composites will be useable across many vendor environments because of the broad industry support for SCA. Using the same skill set, we can access services built on different architectures like POJOs, EJB session beans, and RMI.

This example relies on a set of Java objects and methods that implement a calculator. We know it's much more compact than the kinds of components you will work with in the future—but we are going to use this because having very compact code helps to focus on what's new in SCA and the key pieces of code that will help use and create composites.

Before We Begin
We will be using an SCA composite defined in an XML file. This file tells the SCA runtime environment what it needs to provide a service. The SCA runtime is the engine that allows components to use each other across different bindings and manages communications across implementations. In this sample, we will only need a container that implements the SCA Java Component model.

In our simple calculator example, we will put all of the components in the same place for convenience. A more sophisticated example might include other architectures, bindings, and policies. A composite might use a component written as a Web service and accessed across a Java message queue, with the requirement that all requests to the service be encrypted. The particular composite we are showing today is actually just a collection of POJOs, which means that the whole thing runs in a single JVM. (That also means the XML overhead of SOAP services doesn't apply here).

In this article the SCA runtime we'll use is Apache Tuscany, an open source implementation of SCA.

Part One: How to Use a Pre-existing Composite
To start, we'll look at the sample code included with this article. Download it here.

Here's how to invoke a POJO calculator object without SCA:

public static void main(String[] args) throws Exception
{
CalculatorService calculatorService =
new OriginalCalculatorServiceImpl();
// Now we call the POJO directly...
System.out.println("3.7232 + 2.4289 = " +
calculatorService.add(3.7232, 2.4289));
} 

Now here's the same application with SCA:

public static void main(String[] args) throws Exception
{
SCADomain scaDomain = SCADomain.newInstance("PojoComponent.composite");
CalculatorService calculatorService =
scaDomain.getService(CalculatorService.class,
"CalculatorServiceComponent");
// Now we call the composite directly...
System.out.println("3.7232 + 2.4289 = " +
calculatorService.add(3.7232, 2.4289));
} 

As we can see, calling the POJO and calling the composite are very similar. The difference is in how we set things up. In the POJO, example we just call the constructor function; whereas in the SCA example we create an SCADomain, then we call getService() to get a POJO that represents the SCA composite.

Developers often take a similar approach when using JAX-RPC or JAX-WS. With those APIs, a proxy object is created and treated like a POJO. The proxy takes care of the connection and puts SOAP on the wire. SCA takes that approach and extends it beyond Web services. In this example, we're using SCA to invoke a POJO, but we could use SCA to invoke an EJB, an RMI service or something else.

What Do I Get?
By adding SCA support to what was originally a POJO-based application, the new application works the same way, but it's far more flexible. If we wanted to use a Web service instead of a POJO, we wouldn't change the application at all. SCA takes all of the details of the infrastructure out of the application. If our original example accessed a SOAP service over JMS, there would be a significant amount of plumbing code in the application. With SCA, the application is virtually identical to the simple POJO version, and it doesn't have to change if the calculator service is replaced.

We don't really know or care how the POJO object was created, we just talk to it. If an administrator changes the definition of the composite, the application keeps working:

• The new composite might use a Web service or an EJB session bean instead of a POJO, but the application would still work.



• The new composite might use SOAP or RMI instead of invoking the code directly, but the application would still work.



• The new composite might use SOAP and require that all requests to the service by encrypted, but the application would still work.

The fact that all SCA services are invoked the same way means that application developers don't have to learn the details of every API that might be in the infrastructure. That's another huge benefit of SCA. Even if everyone in our organization uses Java, the APIs might include JAX-WS, JAX-RPC, EJB, RMI, JCA, JMS and others. With SCA, all we have to learn is how to create a POJO and call its methods.

The original calculator required a single line of code to create the POJO, while the SCA version required two. That extra line of code gives us a tremendous amount of flexibility.