Monday, November 09, 2009

SCA a step forward or a just hype?

When Oracle introduced the new version of the Oracle SOA Suite 11g, it introduced a new abstraction layer, the Service Component Architecture (SCA).

The SCA can be seen from a technical point of view, as a container that holds a set of SOA components. These components interact with each other and can be exposed to the outside world as a service. The components itself can call external services, these are called references.

From functional point of view, the SCA is an abstract object that contains a set of business requirements. These requirements are implemented via the various SOA components and are hidden to the outside world.

The biggest advantage of the SCA, is the way the business can talk to the IT and vice versa. With the introduction of SOA technology a few years ago, the two worlds come together. SCA is the finally the bridge of these two worlds. With SCA the business can talk about their requirements and their information flows that need to be processed and orchestrated. While the IT can listen and map the requirements to the different SCA composites with their SOA components, without having discussions with the business on the implementation.

Earlier I wrote a dutch article when I discussed if SOA itself is a hype. In my opinion it is not. The same applies for SCA. It is a next step in the evolution of integration. Think about when we used technologies such as hub-spoke model, EIS, EAI and technologies such as CORBA etc.

While SCA is relative new, the main discussion on SCA composite, how big or how small we make the SCA. Do we design small SCA composites with a few business requirements or do we design large SCA composites that holds a large number of business requirements. The answer is always in the middle. It depends on the non functional requirements of the customer.

When implementing a green field project based on SCA, the SCA composite can be designed to handle particulare business requirements. Examples are:
  • OrderHandling - handle all the requirements of an order; create/update/change
  • CustomerInfo - Handle all the business requirment of the customer
Aoother view is from technical/implementation view. SCA composite can be designed for handling 'low' level functionality.
  • ProcessNotifications - handle all notifications from and to other systems
  • MaintainCRMInfo - handle all requests to the CRM system; update/delete/query/etc
  • ProcessJMSMessgae - hanle all the message from the vaious JMS queues
Using an existing SOA application to migratie to SCA, the most common approach is to migrate it 1-on-1. This makes every component in your old SOA application an SCA composite. This is the fastest way to by into the SCA world. The next step is to use the benefits of SCA; combine multiple SCA composites into a single composite.

A architectural decision should be made how we build the the SCA. With SOA/SCA it is all about re-usability. Are we designed SCA's based on the business flow or are we desiging SCA's from technical point of view. To goal is to find the correct balance. You want to design a service once and reuse it many times. From that point of view you would build small SCA's. But you could also choose for a large SCA's with multiple services that are exposed to the outside world. But in this case, the SCA is relative large, which increases the maintainability.

What you want is to define and design services and create composites that reference to this services. This will result that the service is designed once and reused many times.

Technically I think this is possible with the Oracle SOA Suite rel 11g, but it needs some hand-craft. We should manually change the composite.xml file and change the references and wiring within the composite. We could also use tools as subversion to create references with composites. This is with the option 'external:'. But again it needs some hand-craft.

The SCA is the next step of making the bridge between business and technology smalleras it already was with SOA, but we are not there yet. I would like to have a SCA 'reference' functionality and also inheritance. I hope that the team of OASIS team will look into this.

1 comment:

Michael Rowley said...

Nice post. For people interested in SCA, they may be interested in the book that Jim Marino and I coauthored called "Understanding SCA" (http://scabook.com).

In addition to the factors you mention in your post, I'd say that when you decide what to put into a composite you should also think about deployment granularity and encapsulation. Composites are deployed as a unit, so you should put things together that you want to have deployed together. Composites also can provide encapsulation for the components within them, so you can use them to limit visibility to lower-level components that should only be accessible through well-known access points.

Post a Comment

Post a Comment