Big SCA Update

The SCA working groups have been hard at work updating a baseline set of specifications for SOAs. Today, the official Open SOA web site has been launched. I encourage you to visit it and provide feedback.

A few points to note:

1) It's great to see that a bunch of new partners have joined the effort, including RedHat (I keep running into this Mark Little guy), Sun Microsystems, Tibco, Progress/Sonic, CapeClear, Software AG and others. This represents a real consolidation of the integration space around SCA as the standard basis for describing SOA components and their interactions.

2) The focus has really moved firmly to SOA as the design center. There has been significant attention paid to BPEL and managed policies. To my way of thinking, BPEL support is a key bellwether for credibility in the SOA space, since most organizations are moving in this direction to leverage service functionality in more sophisticated business processes. Second, managed policies are a key part of a global strategy for SOAs, so this is an important step in improving customer comfort in the Web services management space.

3) The updated Assembly spec is simpler and that translates to "simply better".

4) Oracle's SOA Suite will leverage SCA as the basic description unit of the integration technologies in Fusion middleware, as Thomas Kurian pointed out at JavaOne this year. With the momentum that our applications and middleware businesses are gathering, this is going to be a fantastic showcase of what we're doing. I've had a lot of fun working on the service fabric. It's also built using Spring, which has been a blast to use. More on that subject....

5) Last, and from a Java programmers perspective, some very interesting news: there is now a Spring integration that allows Spring-based applications to tie in directly to an SCA-based SOA environment. As Spring becomes a de facto standard in many organizations for building J2EE applications, we're opening the door to transparent SCA-based integration for these investments. Plus now there's a practical open source story for Java developers to get on board with SCA without worrying about new learning curves or lots of new constructs. With Spring, it can be just POJOs: turtles all the way down. I had a lot of folks ask me directly about Java programming and SCA. Spring is a great answer.

So why is this important? At least two reasons.

1) It means that customers can expect to see some structure and standardization around how SOA components are built. For example, SCA will describe the packaging and metadata around a BPEL process, which will move beyond process standardization to deployment standardization. It also means that there will be a normal model for understanding services and their interactions. The same metadata can describe relationships between BPEL process and ESB functionality, for example.

2) This will start to cut down on proprietary aspects of SOA infrastructure that have lead to interoperability nightmares. For example, the use and definition of Web services policies will be more clearly constrained. With WS-Policy, we have grammar, but with SCA, we'll have real usage models that vendors can work together to define across product sets.

Good stuff.