IBM and BEA are pushing a new technology 'SCA' to build services. It provides a framework to create loosely coupled composite-application, where dependencies of components are defined declaratively. The components can be written in different languages and on different platform. Lets take a close looks of it with respect to existing technologies currently available starting with overview.
Overview of SCA
SCA defines a component framework to create services. The basic building block for SCA is a component implementation. One component can compose of other components. The dependency between components is defined in the assembly-descriptor, which provide loose-coupling among components. The dependent components can be local or remote and can be implemented in different technologies.
A component implementation is described by the following attributes:
- Services: This describes the function this type of component provides
- References: This describes the dependencies this type of component has in order to function
- Properties: This defines configuration parameters that can controls how the program logic can behave. For example, what currency to use.
- Intent policies: This describes assumptions on how the component will behave. There are two types of policies.
- Implementation policy- Impact the behavior of an implementation. For example, transaction, monitor and logging
- Interaction policy - defines how the components behave with one another. For example, security.
The key benefits of SCA are:
- Loose Coupling: Components integrate with other components without needing to know how other components are implemented. Components can be easily invoked either synchronously or asynchronously.
- Flexibility: Components can easily be replaced by other components. It also provides the flexibility to create solutions using existing services (bottom up) or model the business and develop the solution (top down).
- Productivity: It enables you to focus on your business logic rather than be slowed with concerns about infrastructure. SCA simplifies development experience for all developers (including J2EE and Integration Developers), integrators and application deployers.
Now, lets see sample codes to understand how a SCA based service is created. (All codes are taken from Apache Tuscany SCA user-guide : http://incubator.apache.org/tuscany/sca-java-user-guide.html)
The service is defined as an interface:
1 public interface CalculatorService {
2 double add(double n1, double n2);
3 double subtract(double n1, double n2);
4 double multiply(double n1, double n2);
5 double divide(double n1, double n2);
6 }
The service is implemented as Java Class:
1 public class CalculatorServiceImpl implements CalculatorService {
2
3 private AddService addService;
4 private SubtractService subtractService;
5 private MultiplyService multiplyService;
6 private DivideService divideService;
7
8 @Reference
9 public void setAddService(AddService addService) {
10 this.addService = addService;
11 }
12
13 ...set methods for the other attributes would go here
14
15 public double add(double n1, double n2) {
16 return addService.add(n1, n2);
17 }
18
19 ...implementations of the other methods would go here
20 }
In the code above, note that 'setAddService' method has an annotation 'Reference'. It indicates that 'AddService' is an interface. Its implementation will be defined in the assembly-descriptor (a XML file) using dependency-injection pattern. This is an example where SCA is acting as IoC (Inversion of Control) engine like Spring-framework.
The reference component 'AddService' is defined as an Interface:
1 public interface AddService {
2
3 double add(double n1, double n2);
4 }
The component is implemented as Java Class:
1 public class AddServiceImpl implements AddService {
2
3 public double add(double n1, double n2) {
4 return n1 + n2;
5 }
6 }
So far, a service and one component are defined and implemented. The service-implementation has a dependency on the component (AddService). This is defined in the assembly-descriptor:
1 <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
2 name="Calculator">
3
4 <service name="CalculatorService" promote="CalculatorServiceComponent/CalculatorService">
5 <interface.java interface="calculator.CalculatorService"/>
6 <binding.jsonrpc/>
7 </service>
8
9 <component name="CalculatorServiceComponent">
10 <implementation.java class="calculator.CalculatorServiceImpl"/>
11 <reference name="addService" target="AddServiceComponent" />
12 <!-- references to SubtractComponent, MultiplyComponent and DivideComponent -->
13 </component>
14
15 <component name="AddServiceComponent">
16 <implementation.java class="calculator.AddServiceImpl"/>
17 </component>
18
19 <!-- definitions of SubtractComponent, MultiplyComponent and DivideComponent -->
20
21 </composite>
In the code above, the 'reference' tag defines the implementation of 'AddService' component. This provides loose-coupling between components. If the implementation of AddService component is changed, change in assembly-descriptor is required only. The assembly-descriptor defines the binding and policy information too.
Lets review different aspect of SCA.
SCA as an IoC Container (Similar to Spring)
SCA's component can be compared to Spring's bean. SCA components have properties and references. The references are other dependent components. The dependent components (references) & properties are populated using the setters or constructors following injection design pattern. This is similar to the bean-definition in Spring-framework. Auto-wiring feature of SCA 1.0 is similar to Spring's Auto-wire feature too.
Looking at SCA specification, it seems that SCA is not providing any additional feature, which is not available in Spring IoC. However, if SCA IoC is provided by the SCA-runtime, it will be available for all the application by default. This would not require to include any other IoC container in the project.
SCA as Java EE Container
SCA provides a framework to create java components similar to EJBs. The new components are implemented as POJOs, and its attributes (security, binding etc.) are defined using annotation or assembly descriptor. IBM and BEA are suggesting to implement entire business-layer using SCA framework. However, Java EE specification provides other standard guidelines too:
- Transaction
- Thread Management
- Security
- Web Service Stype (Wrapped, Unwrapped, JAXB Serialization etc.)
- Object Pooling
- JCA
- Connection Pooling
Currently, SCA specification does not address above features in its version 1.0 specification. For another couple of years, it is certain that Java EE stack will be used by the projects. Until SCA matures and provides all the functionality available in Java EE, it is not likely that the customers would decide to move to this new technology. Lets wait and see how the industry takes its own course.
Assembly Descriptor
SCA defines an assembly descriptor to define the services, references and properties. SCA supports to use components created in different languages and platform to be used as references. This will help in creating a new service using the existing components written in other languages. But, the existing components cannot be used as SCA component as it is. It would require to create a SCA wrapper following SCA specification. In real world, there are very few cases where the client uses different technologies in one domain. The client may have multiple technologies in different domain. In that case, the integration should be done using orchestration (BPEL). Even SCA supports composition of components in a single domain.
Conclusion
SCA is an interesting technology and big product companies (IBM, BEA etc.) are behind it. However, this new technology is being offered as a replacement to a well established & mature Java EE technology. Very likely, the next release of Java EE (6) would include all the new features provided by SCA. SCA does not provide a roadmap whether it can be used as business-layer of web-application. Almost all enterprises have web-applications, and they want to have minimum set of technologies. Current Java EE technology provides a good framework to create new services. Bringing new technology to create new services or migration effort to transform current services (business layer) to new technology has its own challenges and risks.
Since big companies are behind SCA, it cannot be written off easily. They can try to force the existing user-base (like Microsoft) to use the new technology. But, it would not be an easy task for them. For next couple of years, it is not likely that the new projects would use SCA based system until it establishes itself as a mature technology similar to Java EE. We'll watch closely how it evolves.
