There has been a significant lack of standards and specifications that provide prescriptive and definitive guidelines into how service-oriented business applications are to be developed. However, with the inception of Service Component Architecture (SCA) by OSOA, SOA has been made a realistic proposition for enterprise developers and architects. SCA is now being ratified under the OASIS Open Composite Services Architecture (OpenCSA) initiative.

What is SCA?

SCA is a set of specifications, addressing both runtime vendors and enterprise application developers and architects, for developing applications based on service oriented architectural principles and paradigms. SCA advocates a compositional architectural pattern for building enterprise class service oriented applications. It addresses the assembly of both fine-grained tightly coupled and coarse-grained loosely coupled components. SCA composition is based on recursive assembly where fine-grained tightly coupled components are composed together to build coarse-grained components. These coarse grained components can be used in a higher-level contexts to build even coarser grained components and enterprise applications.

SCA Key Concepts

The key SCA concepts are,

Assembly Model

SCA assembly model primarily defines the recursive assembly of components into services. The recursive assembly allows fine-grained components to be wired into what in SCA terms is called composites. These composites than can be used as components in higher-level composites and applications. The type of a component generally defines the services exposed by the component, properties that can be configured on the components and dependencies the component has on services exposed by other components.

The diagram below shows an example of an SCA assembly model,

In the diagram above Composite X is composed of two components Component Y and Component Z, which themselves are composites. Composite X exposes its service using web services.

Composite Y is composed of a Java component, a Groovy component and a Jython component. The service offered by Java component is promoted outside the composite. The Java component depends on services offered by the Groovy and Jython components. In SCA terminology these dependencies are called references. All the references for the Java component are satisfied by services offered by other components within the same composite. However, the reference on the Groovy component has been promoted outside the composite and will have to be satisfied in a context within which Composite Y is used as a component. In the diagram above this is achieved using the service promoted by Composite Z.

Composite Z is composed of a Java component, a BPEL component and a Spring component, the service offered by the BPEL component is promoted to be used when the composite is used as a component in a higher level composite.

As you can see SCA allows building of compositional service-oriented applications using components built on heterogeneous technologies and platforms. SCA assembly model is generally expressed in an XML based language called Service Component Description Language (SCDL).

Client & Implementation Model

SCA client and implementation (C & I) model describes how components, services, references etc are represented, defined and packaged in multiple languages and technology platforms. The current SCA suite of specifications cover the client and implementation model for Java, Spring, BPEL, C++ etc.

Bindings

SCA bindings enable services and references to be accessed over multiple transport and data binding protocols. The current SCA suite of specifications cover bindings for Web Services, JMS, EJB etc.

Intents and Policies

The policy framework is one of the key aspects of SCA. Policy framework allows Quality of Service (QoS) aspects to be defined, managed, enforced and governed, orthogonally to component implementations and assembly using declarative intents and corresponding policy sets. Like all the other SCA aspects, policy framework is highly extensible as well. Policy framework allows policies to be defined using standard mechanisms like WS-Policy or using your own policy language.

Note: I will cover SCA assembly model, client & implementation model, policy framework and bindings in detail later.

Current SCA Specifications at OpenCSA

The current set of SCA specifications hosted on the OSOA site includes,

SCA Assembly Model
SCA Policy Framework
SCA Java Client & Implementation
SCA BPEL Client & Implementation
SCA Spring Client & Implementation
SCA C++ Client & Implementation
SCA Web Services Binding
SCA JMS Binding

Summary

SCA provides a set of specifications, addressing both runtime vendors and enterprise developers/architects, for building service-oriented enterprise applications. For the first time we have a set of specifications that address how SOA can be built rather than what SOA is about. I have provided a bird's eye view of SCA as a technology. In the coming days I will cover in further detail each aspect of SCA as well as practical examples on building SCA based applications using one of the open source SCA runtimes I am heavily involved with, Fabric3.

I have got some interesting views of comparing spaces and JMS, which I will cover later.

The panel discussion in the morning was led by Cedric, Wayne Beaton, Bruce Tate and Eric Doernenburg. The panel discussed a lot of topics related to development including,

Heinz's session was quite refreshing in increasing developer productivity. I think I will try to cover the whole of Heinz's session in another blog by the end of this weekend. It does deserve an entry on its own.

John Davies from C24 gave a session on a case study on the use of grid in investment banking. It started with a lot of promise in terms of real world examples of using grid-enabled technologies. Didn't cover much in the end. As I said earlier, I have got an interesting entry coming up comparing JMS and spaces, I warn you guys, it is going to be a bit controversial :-)

James presented a nice session on ActiveMQ. Covered some of the advanced features. He was quite excited about message groups. We already use that at work using Oracle AQ's support for correlation ids in messages. Interacting with a JMS server from the telnet console was pretty cool. Other features included,

Overall the conference was a nice experience. Without naming names, I thought some technologies were overly hyped up. All in all, TSS did a very good job organizing the conference.

I missed the session by Bruce Snyder on JBI & Servicemix due to work commitments. There were also a parallel session by Rikard Oberg on WSRP.

The next session was by the Terraccotta on transparent JVM clustering. Imagine the piece of code below,

public class MyCache {

  private Map cache = new HashMap();
  
  public synchronized Object get(String key) {
    return cache.get(key);
  }
  
  public synchronized void put(String key, Object value) {
    cache.put(key, value);
  }
  
}

A mundane thread-safe cache. Now imagine you can take this class and transparently apply the native Java syntax and semantics for threading across multiple JVMs on a replicated instance of this class. This is what Terracotta provides. I have seen this is implemented in a few payment switches I have come across. However it is nice to have a product that allows you to transparently cluster any application. There are a lot of use cases I can use this in the applications I am working on, including cluster-wide singletons, keeping track of cluster-wide running totals etc.

The next talk was on JPA by Mike Keith. The talk was more API and spec focused. The talk before by Patrick Linskey on a more subjective view of JPA would have been more interesting. I don't want to over-elaborate on JPA itself as more than enough has already been written on the topic. However, I would say Hibernate style criteria objects would have been great. An interesting thing was pluggable persistence providers and Spring 2.0 offering a JPA provider. I think this concept started out in EJB 2.0 and disappeared from the final version. I am a bit skeptical about the portability aspect, I am sure the vendors will be tempting developers with proprietary annotations. Do you want a good example, Spec has left to the providers on how to perform eager fetching. So the provders can say, hey, you can use sub-select fetch or join fetch using our proprietary annotations. I have similar apprehensions about the whole concept of bulk updates and the grey area around how the current attached objects are kept in sync with the underlying datastore.

The last session for the day was by Nati Shalom from Gigaspaces and Rod. They showed a neat example on how Spring can hide the transport intricacies of accessing a clustered space. I think a lot of people are doing the same kind of things with spaces, with Mule providing similar support. I have been playing around with writing a spaces binding for the SCA implementation Tuscany. It was quite interesting when Nati said we didn't need relational databases anymore (or did I get him wrong?). It may be true for greenfield projects with the rubustness provided by spaces implementation like Gigaspaces (how about durable storage?). However, with terrabytes of corporate data residing in enterprise relational databases and systems being built around existing information set, databases are here to say. The key is finding the right synergy between using existing information stores with space-based grid paradigm. Anyway, the demo was quite impressive. I am sure I will be going back to Nati on more info on how this fits into stuff I have been doing. On a side note it was quite nice to catch up with Rod after a while.

The next session I attended was by Geert Bevin on flow and continuations. Geert did a good job explaining continuations at a conceptual level. It is a quite powerful concept and quite affective for complex control logic that is difficult to solve with primitive control constructs available in modern programming languages. Geert , then showed how continuations were implemented in the RIFE web application framework. It was interesting how RIFE implemented pause and continuation by byte-code amendment and taking a snapshot of the stack frame. I am not sure how efficient this is. It would also be interesting to see whether a future version of Java language would have language level support for continuations.

Next session was something I was eagerly waiting for, Gavin King’s session on Seam. I was a bit disappointed with the session as a whole, as Gavin spent half of the session on how flawed was the whole concept of stateless architecture and criticising dependency injection and some of the popular DI frameworks. Al though, some of Gavin’s arguments were valid and interesting, the point on HTTP session replication and the Servlet specification mandating a call to setAttribute to enable session replication was factually incorrect. Though, I have always had the same opinion on developers being concerned about using stateful session beans, because of state replication overheads in a cluster, however having no inhibitions in dumping everything and the kitchen sink into the HTTP session. All in all, Seam appeared to be an interesting framework for integrating JSF and EJB component models with a heavy emphasis on stateful session beans.

Mike Keith presented a session on EJB 3.0. It was more on the component model rather than JPA. I am not sure I quite like this concept of being able to inject only certain kind of references into only managed components like EJBs, Servlets etc. This will encourage the developers to write everything as an EJB or a Servlet. I am looking forward to Mike’s session on JPA tomorrow.

I was really in two minds about whether to go for Gregor Hohpe’s session on SOA or Ross Mason’s session on Mule. Finally, ended up at Ross’s session because of the recent work I have been doing with Mule. The session was pretty basic, didn’t get to know much more than what I already knew. However, had an interesting chat with Ross on roadmap for Mule.

Last session for the day was by Cedric Beust on TestNG. Junit has revolutionized the way we test in the last five years or so. It has been a wonderful framework. However, it has also shaped our psychology and mindset on jow we do testing. This is more of the fault of us using JUnit for something it was not intended for. Junit is a unit-testing framework and by design has an extremely stateless paradigm for testing. This doesn’t really fit into the more complex requirements of functional, component-level and system testing. To test a complex piece of functionality you often need to execute a set of tests in a stateful context, and this is what TestNG offers. Cedric’s session was the best of the day. It was quiet relieving that TestNG annotations can use either Java 5 or Javadoc tags for JDK 1.4.

Methods that intercept invocations to business methods or lifecycle events can be defined either in the bean class or in separator interceptor classes. Only one interceptor method is allowed per class. The interceptor methods should be annotated with the @AroundInvoke annotation and should have the signature, Object <methodName>(javax.ejb.InvocationContext). If the bean class has a method with the above signature and annotation, the method will be used to interpose on all the business method invocations on that bean. Additionally, you can define interceptors for all the business methods on the bean or individual business methods using the @Interceptors annotation. The value of this annotation is the list of interceptor classes. The interceptor classes are required to have a single interceptor method with the same signature and annotation as explained earlier. Interceptor classes have the same lifecycle as the associated bean instance and can have dependency injection, which will be done using the same naming context as the bean.

InvocationContext

Order of Interception

Example

Bean Class

package com.acme.ejb;

import javax.ejb.AroundInvoke;
import javax.ejb.Interceptors;
import javax.ejb.InvocationContext;
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;

@Stateless
@WebService
@Interceptors( { Interceptor2.class })
public class HelloWorldBean {

	@Interceptors( { Interceptor1.class })
	@WebMethod
	public String sayHello() {
		return "Hello";
	}

	@WebMethod
	public String sayHi() {
		return "Hi";
	}

	@AroundInvoke
	public Object log(InvocationContext invocationContext) throws Exception {
		System.err.println(invocationContext.getMethod().getName() + " called from interceptor 3");
		return invocationContext.proceed();
	}

}

Interceptor Classes

package com.acme.ejb;

import javax.ejb.AroundInvoke;
import javax.ejb.InvocationContext;

public class Interceptor1 {

	@AroundInvoke
	public Object log(InvocationContext invocationContext) throws Exception {
		System.err.println(invocationContext.getMethod().getName() + " called from interceptor 1");
		return invocationContext.proceed();
	}

}

package com.acme.ejb;

import javax.ejb.AroundInvoke;
import javax.ejb.InvocationContext;

public class Interceptor2 {

	@AroundInvoke
	public Object log(InvocationContext invocationContext) throws Exception {
		System.err.println(invocationContext.getMethod().getName() + " called from interceptor 2");
		return invocationContext.proceed();
	}

}

Testing the Example using Glassfish

The types of resources that can be injected in are generally the ones currently available for lookup from the java:comp/env namespace, by defining them in the deployment descriptor, as specified by the Servlet 2.4 specification. Resource injection relies on J2SE 5.0 annotaions. J2SE 5.0 is a pre-requirement for Servlet 2.5.

Injectable Classes

The classes that can be injected with external dependencies are,

Resource Types

The annotaions available for dependency injection are

Example

The snippet below shows a simple example of injecting a datasource into a Servlet,


public class MyServlet extends HttpServlet {
@Resource(name="myDs") DataSource myDataSource;
}


This injects a datasource by the JNDI name myDs into the field myDataSource. If the name attribute is not specified, the field name is treated as the JNDI name.

Improvements?

Would you want the resource injection mechanism to be extended to ay classes load by the web application classloader, rather than only those classes whose lifecycle are managed by the container. Would the Servlet specification require EJB 3 persistence contexts to be injectable to web application classes?

A good example if often when you use light-weight domain modelling using Java. You woudln't want to expose the internal state of your domain objects to external entities. However, you are forced to add the so called public getters and setters to your private instance variables so that your persistence frameworks can set them or the view framework can get them. This is indeed an anti-pattern, that breaks one of the cornerstones of object orientation, i.e data encapsulation. These getters and setters are not part of the public behaviour of the entity you are modelling.

There are two solutions that some into my mind,

A C++ style friend access mechansim, where you can specify arbitrary visibility enablement between classes. This means you can allow the internal state of your domain classes be accessed by only persistent and domain classes.

Allow the semantics of package and protected access to be extended to hierarchical packages. This means for example, classes in com.acme.domain.persist and com.acme.domain.view would have the same access permissions on the classes within com.acme.domain as the classes within the same package.

Note: Some persistence frameworks do enable private field level access. However, as soon as you deny ReflectPermission in a J2EE environment (recommended by the spec) you will start running into problems.

I used to think this was an inevitable by-product of distributed systems where it was not such a good idea to transport state and behaviour. However, I soon realised in most but not all of the systems, this was caused by the over-emphasis on use case analysis without significant attention to proper domain modelling. The system was seen as a black box monolith that accepted user requests and produced responses. This led to the design of a bunch of stateless services exchanging dump data between the invoker and the invoked. As a result, domain logic was often duplicated in the various application layers.

Couple of weeks ago, I started on this new project and have had the fortune to work with Rod Johnson (I always wanted to work with him since the first time I met him in a restaurant in Brick Lane three years ago). This project has brought a breath of fresh air into my experience with J2EE. Here we no longer think in terms of dump transfer objects and entity beans. Here we no longer have use cases as the sole design artefact. More than everything, we have a rich reusable domain model built using object-oriented paradigms like inheritance, composition, polymorphism and re-entrancy. And even more important the persistence of the domain layer is transparent using Hibernate. Our object layer doesn't remotely resemble the data layer. I am hugely impressed with Hibernate's persistence capabilities (though there is scope for improvement as any other software; I had some difficulty mapping polymorphic collections).

I think with a proper attach/detach strategy, and transparent data versioning you could have a rich domain layer that can be seamlessly reused in the distributed process spaces of your application. After reading the early draft of EJB 3.0, I understand most of these stuff will be supported by entity EJBs. Anyway, it is a long way to go before the spec becomes final and vendors start supporting it. For the time being, we have some fantastic commercial and open source O/R mappers and JDO implementations, that will move us forward from the "old-school" J2EE of transfer objects and entity beans towards rich domain model and transparent persistence.

One of the main disadvantages in handcrafting details is that details change frequently forcing you to make changes to your programs to capture the changes. The more changes you make manually, the more bugs you introduce in the system. In my experience hand-coded details create the most number of bugs in the system. So, how do you get around this? The answer is metadata!! You externalize the details from your code to metadata. Then have an abstract framework that can interpret the metadata. For this you can have a number of strategies like static code generation based on metadata or a more dynamic reflective framework that can interpret the metadata. This means the only place you introduce bugs is in the framework. A bug in the framework will be manifested in every single artefact of your system that uses the framework, which makes the bugs easier to find and fix.

J2EE introduced the art of meta-programming to the enterprise Java world. With deployment descriptors you externalize a huge amount of meta information from the code and you delegate the tasks of interpreting the meta information to the containers. This was further enhanced by the introduction of great tools like XDoclet that used doclet based metadata to extract more details out of the code. Then came tools like Middlegen that generated your entity beans from the metadata in the database. If I look back to around four years ago on how I wrote entity beans and how I write them now, I would say it has been a quantum leap. This doesn't need to stop there. In my current project we used fastlane readers backed by stored procedures for bulk reads. All our fastlane readers are generated using a custom Ant task and Velocity based templates driven by metadata in the database. The next step would be to capture your domain logic in terms of metadata (you can even have a custom domain language) and drive your business components off that meta information. Less code you write, less bugs you have and more maintainable your system is.

Some of the advantages I have found on using meta-programming are,

• It is easy to find and fix bugs
• You spend less time with details
• Your system is more adaptable to changes
• You spend less time on repetitive and redundant tasks
• Your system is better designed as you spend more time in writing a robust framework and less time with the details

One of the JCSC violations we used to have highly frequently, pretty early in the project was missing @author tag in the JavaDoc comments. This caused us a huge amount problem for tracking where poor code was being originated and often involved going back to CVS and check who wrote a particular bit of code. This made us enforce a standard that every single class in the system had to have an @author tag.

The result of this was amazing. Developers started working meticulously in writing better code to make sure that their names didn't appear in the "Hall of Shame" ;-). They also started having pride in their work and with pride came responsibility. In a couple of weeks the quality ratings based on the measurements started increasing, there were more unit tests being run, all the classes started having proper JavaDoc comments and the code quality started increasing significantly.

Code that is not owned encourages poor coding practices that lead to totally un-maintainable code and ultimately utter anarchy. This isn't anything specific to our industry, whatever craft you do, it is extremely important to take pride in your work. It is important to let people know it is your piece of work. It is not about promoting finger pointing or blame culture. It is about having pride in your work. It is also a mark of responsibility. It is about taking ownership and having the motivation to produce better results.