Service Component Architecture & Declarative Services Component Model

Question

According to Wikipedia,

Service Component Architecture (SCA) is a software technology used for composing applications that follow Service Oriented Architecture (SOA) principles. It is a development model that comes with many advantages including:

• Separation of business logic from the details of its service implementation.

• Supports services in a multitude of languages including C++, Java, COBOL, and PHP as well as XML, BPEL, and XSLT

• The ability to seamlessly work with various communications constructs including One-Way, Asynchronous, Call-Return, and Notification.

• The ability to "bind" to legacy components or services, accessed normally by technologies such as Web Services, EJB, JMS, JCA, RMI, RPC, CORBA and others.

• The ability to declare (outside of business logic) the Quality of Service requirements, such as Security, Transactions and the use of Reliable Messaging

• Data could be represented in Service Data Objects

I would add,

• Loose Coupling between the different modules (components).

I did implement a simple software using SCA technology, and I could see the power of SCA heterogeneity and its platform independence, with help of Tuscany Tutorial.

Today, I am looking at another model that seems a bit related. It is the Declarative Services Component Model (DS), which is a component model that simplifies the creation of components that publish and/or reference OSGi Services. In DS, an OSGI bundle seems to be wrapped as a component by adding an XML component declaration file to the bundle resources. The XML file generally contains declarations of the bundle services and references, something SIMILAR to SCA composite file. Here's an example of such file:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.eng.test.ds.consumer">
   <implementation class="it.eng.test.ds.consumer.Consumer"/>
   <reference bind="bindHappy" cardinality="0..1" interface="it.eng.test.ds.happy.IHappy" name="IHappy" policy="dynamic" unbind="unbindHappy"/>
   <reference bind="bindSad" cardinality="0..1" interface="it.eng.test.ds.sad.ISad" name="ISad" policy="dynamic" unbind="unbindSad"/>
</scr:component>

My questions is: Is there any kind of relationship between SCA and DS? Can DS achieve the SCA heterogeneity, and its component isolation? For example, Can DS provide services or references to/from different platforms like SCA components? Can a DS component be independent (isolated) in the same sense an SCA component is isolated?

Answer 1

DS and SCA are complimentary things. One is not a substitute for the other. You can use DS to build OSGi services. These services can be using in an OSGi framework. SCA can be used to describe a larger SOA design across multiple nodes. OSGi can be an implementation type for SCA components. So use DS for OSGi services when using OSGi as an implementation type for SCA.

Answer 2

I think both models serve a different purpose though they are both service based. DS is part of the OSGi framework and while it is possible to use remote services, but mainly ds is constrained to java/OSGi. There are frameworks like Apache Wicket which provide some kind of integration for declarative services in a web environment.

DS is a powerful framework for java/OSGi. One of the main distictions to most other frameworks I know is the dynamic side of OSGi. Services can come and go any time. Related to the concurrency converter service (in your linked example): In OSGi you could exhange the implementation at runtime, mock it for test purposes etc. An OSGi bundle (mainly a java project with meta information) may provider 0...n service components). Mostly best practice is to separate the service definition from the implementions into distinct bundles (unlike in the example you linked). To cut it short: Isolation would be better with ds, heterogeneity (support for different technological platforms) is not aimed at by ds (of course it could be achieved in one way or another if you make some effort). Hope that helps.

Answer 3

As B.J. mentioned in his answer, DS can be used as an SCA component implementation type. Similarly, Spring beans, POJOs or a BPEL process can be used as SCA component implementation types.

OSGi bundles aren't an implementation type but a packaging mechanism supported by SCA. In particular, the SCA Java POJO specification uses OSGi for Java artifact modularity. SCA provides additional modularity mechanisms such as composites (see http://java.dzone.com/articles/service-composition-modularity).

The SCA Java specification also outlines how dynamic wiring of services works but does not require SCA runtimes to support that capability. I don't know if Tuscany supports dynamic wiring but Fabric3 (www.fabric3.org) does. For example, Fabric3 supports dynamic service reference injection (addition, removal, update). This is particularly useful with multiplicity references (i.e. references that are collections of wired services). Dynamic wiring works for both local as well as distributed services.