JavaOne 2010 - Developing Composite Applications for the Cloud with Apache Tuscany (SCA)

A great take on a great technology, SCA (Service Component Architecture), was given by Jean-Sebastien Delfino (IBM) and Luciano Resende (Shutterfly). Can Tuscany (a SCA  implementation) shield you from the complexities of component assembly/component integration/deployment/inter-component communications/client protocols/… in the Cloud? It turns out that many of these problems are not specific to the Cloud, they apply to any distributed environment, but the live demo made it a point to show how SCA works in a Cloud.

First they quickly reviewed the SCA goals:

1. Abstract out the APIs, protocols and QoS (as in addressing, authentication levels, etc…) that define a service
2. A structure for application componentization (refer to my earlier post Patterns For Modularity )
3. A way to assemble/wire/re-wire components
4. Encourage Open Source implementations (Tuscany, Fabric3, etc…)
5. Encourage products implementations (IBM WebSphere Process Server, Oracle has an implementation inside its BPEL Process Manager, Tibco ActiveMatrix, SAP NetWeaver Platform, etc…)
6. Target SOA, multi-languages applications, application integration

But how can SCA help you in the Cloud? To answer this we need to look at the SCA Composite (briefly, in the SCA Assembly Model a Composite is the main unit of work  providing Components to implement the business function, exposing the Services  through various bindings such as WS or JMS, and listing its dependencies on other Composites through References). A Composite is defined in a SCDL (Service Component Definition Language) file. The Components can be coded in Java (POJOs or Spring Beans for e.g.), BPEL, JEE, Groovy, XQuery, etc… The multi-language support means that a Component can target different Cloud vendors’ run-times. The Service bindings are similarly diversified (WS, JMS, JCA, SLSB or Stateless Session Bean, HTTP, JSON, etc…) which means that various Cloud clients can access the same Component through various bindings. Finally one Composite can refer to another co-located or remotely located Composite, which makes them suitable for distributed environments such as the Cloud.

Let’s take a look at the Apache Tuscany project run-time. It comes in two flavors: Java, the most common run-time and the SCA native run-time (Components can be written in Python for potential deployments in the Google Application Engine Cloud or can be written in C++ – for situations requiring a small footprint). Scheme support for Components is currently experimental.

The demo was quite convincing: A SCA Composite was written in Java and deployed to Amazon EC2. Another Java Composite, part of the same application, was  pushed to Google Application Engine. That same Composite’s Component was re-written in Python and moved to Google Application Engine Cloud, the application behaved as before. Finally that same Composite’s Component was re-written in C++ and pushed to Amazon EC2, the application behaved as before. What’s worth mentioning is the minimal effort  required to move from one Component implementation to the other: Just one line of change in the SCDL .composite file.

So far so good but as mentioned before not really Cloud-specific. The Tuscany folks have recently forked another project, Nuvem, to address some Cloud-specific issues. Various utilities standardize access to Cloud services such as User Authentication and Authorization, Distributed Cache, Data Store and Queuing. This nicely complements the libcloud effort described in my earlier post where we saw common functionality to manage the various Clouds (list, reboot, create, destroy, etc…) getting standardized but Nuvem seems redundant with some areas of the Simple Cloud API (such as Queuing). Right now Nuvem is concentrating on Amazon and Google Application Engine.  What I liked about Nuvem was the REST-approach: REST itself is Cloud friendly, all operations are described in 4 simple verbs, this should help simplify the API. But no demo was given of the Nuvem capabilities, I guess the project is still too young. Jean Sebastien actually shared a wish list for Nuvem: XMPP (for EC2, it’s there for GAE), Maven, OpenID, hierarchical cache, key/value store, RDBMS, etc…

In conclusion developing a distributed application for deployment in your data center should not be fundamentally different from developing that same application for deployment in the Cloud. It’s the plumbing that differs but that’s transparent to the application. So the Cloud in itself should not be enough to entice you to adopt Tuscany or another SCA implementation. The complexity of the application, the desire to make it modular and service-oriented, the need to expose it business logic through many bindings and the option to support many component models (read many languages/frameworks) should entice you to adopt Tuscany or another SCA implementation.

About these ads