Wednesday, September 14, 2011

SCA (Service Component Architecture)- Part 2

This is the second part in the series of articles that will cover SCA. See Part 1 for some background.


How do I create an SCA component/Composite?
The below sections use the SCA java programming model to describe the annotations that are available, followed by an example.


Brief Overview of Annotations
The below is a very brief overview of the Annotations in SCA. This is just meant as a cursory reference. Please refer the SCA spec for details.

 @Service
 A Java class component uses @Service annotation to specify the interface of the services implemented. 


@Remotable
This annotation defines a remotable service in the Java interface of the service. Remotable services use by-value data exchange semantics. 



Local service
A local service can only be invoked by clients that are part of the same module. A Java local service interface is defined without a @Remotable annotation.


@AllowPassByReference
This annotation on the implementation of a remotable service is used to declare that whether
it allows pass by reference data exchange semantics on calls to it. 
Local services use by-reference data exchange semantics, so changes made to parameters are seen by both the client and the service provider.

@Scope
A @Scope annotation on either the service's interface definition or on the service class denotes a scoped service.  The scope values could be:
  • stateless: This is the default and each request in this mode is handled separately.
  • request: In this mode the requests are directed to the same Java interface for all local service invocations that occur while servicing a remote service request.
  • session : In this mode the requests are directed to the same Java instance for all requests in the same "session".
  • module :In this mode the requests are directed to the same Java instance for all requests within the same "module".

The SCA runtime will prevent concurrent execution of methods on an instance of these implementations except for the module scoped one.

Lifecycle methods on a scoped service are implemented using @Init(called only once at the start of its scope and after its properties and references have been injected) annotation and @Destroy(called when its scope ends) annotation.


@Property

This annotation on a field or method in the Java class defines the configuration properties of a Java component implementation. It takes the name of the property and the boolean to specify whether injection is required.

@Reference
This annotation is used to acquire access to a service using reference injection it takes the name of the reference and whether it is required.

@Context
This annotation along with a field of type ModuleContext is used to access a service.

@Oneway
This annotation is used to mark a non-blocking method. The method returns immediately allowing the client to continue execution.


@Session and @SessionID
These annotations along with @Scope is used to implement conversational services. A session is used to maintain information about a single conversation between a client and a remotable service. Thus, SCA simplifies the design of conversational services while leaving the details of ID generation, state management and routing to the SCA container.

@Callback
This annotation can be used to provide callback services on a remotable service interface. It takes the Java Class object of the interface as a parameter. The Callback service provides asynchronous communication from a service provider to its client. 



Examples  (Taken from Apache Tuscany)


Catalog Interface
package abc;
import org.oasisopen.sca.annotation.Remotable;


@Remotable
public interface Catalog {
    Item[] get();
}


Cart Interface


@Remotable
public interface Cart extends Collection<String, Item> {
}


Total Interface


@Remotable
public interface Total {
    String getTotal();
}

Catalog Interface Implementation


package abc;
import org.oasisopen.sca.annotation.Init;
import org.oasisopen.sca.annotation.Property;
import org.oasisopen.sca.annotation.Reference;


public class FruitsCatalogImpl implements Catalog { 
    @Property
    public String currencyCode = "USD";

    @Reference
    public CurrencyConverter currencyConverter;

    private List<Item> catalog = new ArrayList<Item>();
   
   @Init
    public void init() {
        //some code
    }
    public Item[] get() {
       return catalogArray;
    }
}


Shopping Cart Implementation 


package abc;
import org.apache.tuscany.sca.data.collection.Entry;
import org.apache.tuscany.sca.data.collection.NotFoundException;
import org.oasisopen.sca.annotation.Init;
import org.oasisopen.sca.annotation.Scope;


@Scope("COMPOSITE")
public class ShoppingCartImpl implements Cart, Total { 
    private Map<String, Item> cart; 
    @Init
    public void init() {}


    public Entry<String, Item>[] getAll() {
        return entries;
    }


    public Item get(String key) throws NotFoundException {
       //return item
    }


    public String post(String key, Item item) {
       //put in cart and return key.
        return key;
    }


    public void put(String key, Item item) throws NotFoundException {
        //update item
    }

    public void delete(String key) throws NotFoundException {}


    public Entry<String, Item>[] query(String queryString) {
     }

    public String getTotal() {
        //return total
    }
}


SCDL File
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1"
targetNamespace="http://store"
name="store">

      <component name="Store">
        <tuscany:implementation.widget location="uiservices/store.html"/>
        <service name="Widget">
         <tuscany:binding.http uri="/store"/>
        </service>
<reference name="catalog" target="Catalog"/>
 <reference name="shoppingCart" target="ShoppingCart/Cart"/>
 <reference name="shoppingTotal" target="ShoppingCart/Total"/>
       </component>

<component name="Catalog">
<implementation.java class="services.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<tuscany:binding.jsonrpc uri="/Catalog"/>
    </service>
<reference name="currencyConverter" target="CurrencyConverter"/>
</component>
 
<component name="ShoppingCart">
<implementation.java class="services.ShoppingCartImpl"/>
<service name="Cart">
<tuscany:binding.atom uri="/ShoppingCart/Cart"/>
</service>    
<service name="Total">
<tuscany:binding.jsonrpc uri="/ShoppingCart/Total"/>
</service>    
</component>


<component name="CurrencyConverter">
<implementation.java class="services.CurrencyConverterImpl"/>
</component>  


       <service name="CompositeWidget" promote="Store/Widget">
         <tuscany:binding.http uri="/compositestore"/>
        </service>
</composite>

Thursday, September 1, 2011

SCA(Service Component Architecture)- Part 1

This is the part 1 in the series of articles that will cover the first three sections in the following aspects of SCA(Service Component Architecture):

  • What is SCA?
  • Is SCA better than JBI?
  • When do I use SCA?
  • How do I create an SCA Component/Composite?
  • How do I consume SCA?

What is SCA?
SCA can be plainly thought of as a way to create components and then assemble them so that they can work together. The Components that make up an application, can be built in Java or any one of the programming languages supported by SCA. A different technology, for instance, BPEL can be used as well.


Component   
The components vary in complexity, ranging from a simple java classes to ones which have multiple components including local or distributed Java classes, BPEL components etc. SCA defined a logical construct called composites which is nothing but an assembly of components. An application could consist of one composite or multiple. The components could be implemented using different languages or technologies if so desired. However, the components themselves have a few fundamental features:


  • Business logic exposed as Services. A Service is nothing but a set of operations that be invoked by a client.For instance a Java component might use an interface to describe the service.
  • Consuming other services as References
  • Property allows a component to read configuration or other initialization data.
  • binding can be thought of as a protocol to communicate with the service or reference and there can be multiple bindings per service/reference.


                                                           Figure 1: A component
SDO
SCA components can access data using SDO along with JDBC or JPA from a database. SDO is optional and can be thought of as the "DAO" pattern that Java defines. SDO might be the subject of another post later on.


Composite


An SCA composite is an ".composite" file which uses an XML-based format called the Service Component Definition Language (SCDL) to describe the components and their relationship.Example:




<composite name="myComposite">
   <component name="abc">
    ...
   </component>
   <component name="xyz">
      ...
   </component>
</composite>


                                                 Figure 2: A Composite




Domains
It's tough to describe domains in a way that most of us understand the word domain. Domains can be thought of as multiple SCA runtimes installed in local or distributed fashion. Since SCA doesn't define how distributed domains communicate with each other, its tough to describe what truly makes up a domain and how to map the definition of a composite to different domains? I may have not understood the specs correctly but t's probably not possible in SCA to have a composite cross multiple domains.  To me this is a significant limitation that I am hoping somebody clarifies.


(Maybe OSGI remote services can help here but that is the subject of a future post).




                                                Figure 3: An SCA Domain


Is SCA better than JBI?
It's like comparing apples to oranges ( Sorry, it's always fun to say this :-) ). To put it very succinctly JBI is what middleware vendors can use to provide or extend the runtime. SCA is what developers and assemblers can use to develop and deploy services ( as components and composites). So there is some overlap but not much. To me they are complementary and probably debated a lot because of Sun versus the "others" focus. Sun was focusing ( not sure if they still do) on JBI and the "others" were focusing on SCA. Probably what Sun is proposing has more to do with the middleware vendors themselves which the "others" are trying to avoid by focusing on the programming and component model instead of how the runtime is expected to behave.

   JBI would be more applicable for ESB vendors than component developers but I still think JBI has a role to play in Enterprise architectures because we do need more than a "point-to-point" model which SCA proposes. What if I have an SCA component that needs to broadcast a message(or event) which needs to be transformed differently for each of the target endpoints? It would be interesting to find out, how would this be implemented in SCA? Maybe we will have some "component" that either intercepts the point to point communication( is there such a thing in SCA?) or the message is actually directed to this mediator  (this breaks loose coupling?) which can then use BPEL, JMS or some other fan-out mechanism to broadcast this to the other components? Do I see an SCA+ Camel combination coming? :-)

I would hope that there is more synergy between JBI and SCA and this article does talk about one. It's from 2008, so I am not sure if this was updated or improved in recent time.

When do I use SCA?
SCA should be used to implement SOA when the organization doesn't already have any well-established SOA culture. Most often, the organization either has or tries to create a bunch of web services hoping that it would lead to SOA. Having web services is a good thing but it cannot lead to SOA unless the following criteria are met:

  • Loosely coupled. A web service that depends on another web service to finish it's processing is not SOA. It cannot reliably predict if the other service is running or even SHOULD be running. Web services should be truly independant of each other and no assumptions should be made as to their availability.
  • Composition of web services. Some framework or mechanism to exist that can combine, orchestrate or choreograph ( I won't go into the difference here :-) ) these services to implement business logic. Without effective coordination, having web services that are controlled by some inflexible and non-declarative piece of software is as bad as not having the web services in the first place.
  • Location Transparency: Again, services should be registered and located in a way that avoids violating the loosely coupled principle. It also means that there is a single mechanism to find and locate services and it's well established.
  • QoS, Governance: Without effective QoS and Governance support, web services are hard to maintain and grow. Do we know what is the impact of bringing down a particular service? Who can access a particular service? What are the Web service policy requirements and wow can a client satisfy these requirements?

SCA is a step forward in that direction as it has a bunch of specifications that can define how to create Service Oriented Business Applications ( SOBA). These specifications achieve the above SOA requirements and should be .  SCA has a programming model that allows one to use any of the supported programming languages ( C++, Java, BPEL etc).


Additionally, SCA provides the following things:
  • A platform neutral service component model that spans technologies and is not dependent on a particular language.
  • A client programming model to allow clients to access service components deployed in the runtime. SCA Developers can develop components using the various technologies they are familiar with, such as Enterprise Java Bean (EJBs), and use SCA to glue the components together.
  • Defines a standard model for defining dependencies between components. These dependencies are defined by wiring SCA components together using references.
  • Defines a standard deployment model for packaging components into a service module.
  • SCA has multiple bindings ( and not just web services) including JMS, BPEL, REST etc. I read about an interesting aspect of this when someone used SCA to define a "widget" composite/component in SCA and then provided the implementation of that Widget in HTML/JS. The Widget component was using the java components as references within the HTML/JS code. JSON and ATOM binding was used to expose the java components over the wire. A very interesting example of SCA indeed! I would have to locate this resource and link it here. If any one of you can find it, please let me know. 
  • An asynchronous programming model.


Caution:
An SCA runtime can implemented many different bindings including Web service, JMS, JCA, EJB etc. There is also an SCA service binding which is not defined by the spec and can be used only within a domain by an SCA runtime.The implementation of this binding type is not intended to be inter-operable. For interoperability the standardized binding types like web services should be used.

The opinions and statements in this communication are my own and do not necessarily reflect the opinions or policies of CA.