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
- 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
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.
