SCA and Loose Coupling

In Oracle SOA Suite 11 it is easy to put everything into a SCA Composit that makes a SOA solution – BPEL processes, integration logic, business rules, human interaction – you name it.

The question architects should consider is whether conceptually all these belong tightly bundled together.

The answer depends on the desired degree of loose coupling.

If you want to add a SOA-Layer on top of a fixed application it may be feasible to wire integration aspects in the new “Mediators” with business process logic in BPEL. This tightly coupled design may be fine when the integrated application (or a set of applications) will stay for the foreseeable future.

Yet, how would a design look like if you want to achieve loose coupling, where processes orchestrate Business Services whose implementation is easily exchangeable? Then the business aspects in processes and business rules should be isolated from integration logic that is close to end systems.

Then it becomes possible to exchange the underlying applications and the affected integration logic with no changes to the orchestrating process logic in your business related SCA Composites.

Such integration logic could translate the exchanged data into the aplication data dialect and knows their protocols. Following the separation of concern principle such logic is very different to the more business related aspects in highler level BPEL business processes and and should be deployed in distinct chunks. This means business aspects and low level technical aspects do not belong in the same SCA composite.

Following this distinction, for integration aspects you could create own SCA composites, one for each orchestrated Business Service. Or, if you have more demanding integration requirements, consinder creating fassades to end systems that are based on services developed in the “new” Oracle Service bus (OSB – ex BEA Aqualogic Service Bus).

OSB belongs now to Oracle SOA Suite, yet the integration into one holistic IDE and console that consolidates SCA, mediator, BPEL and OSB is one of the major things to look for in future releases of Oracle SOA Suite 😉


2 responses to “SCA and Loose Coupling

  1. Hi Hajo,

    Great that you started a blog, and even better that you started with your two favorite topics: BPA suite and loose coupling!
    I think the points about loose coupling and SCA service design are very valid: as Ronald put it nicely here SCA is a way of encapsulating services. This brings us to a problem: at this time the SOA Suite does not support nested composites. So if you want to do separation of concerns and encapsulations of ‘private services’, you are in trouble!
    I look forward to hearing your view on this!

  2. Hello, i came across your blog and am interested in fllow your blog!
    I read the first book about SCA: and this is a very good book.

    For me SCA is a means to compose Services out of components, named composites, in a language and protocol transparent way.

    These Services can then be exposed by an ESB, i.e. OSB from Oracle and used within the BPM where the business processes are modelled and executed. This way you get your loose coupling and business flexibility.

    Curious on your view on this!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s