Skip to Content

Service Component Architecture Meets Java EE: A Work in Progress (Part 1 of 2)

Service Component Architecture Meets Java EE: A Work in Progress (Part 1 of 2)

The Application Server team at SAP has been thinking hard about the best way to use Service Component Architecture (SCA) in a Java EE context. Our current thinking on this project is detailed in the white paper titled SCA & Java EE Integration.

In this two-part blog I’m going to give an overview of this integration model from both a design time and run time perspective. First I’m going to explain how SCA provides a way to extend the model of Java EE applications, thereby reducing the impact on your applications from the introduction of new, and possibly yet unknown, component technologies. Then, in part 2, I’ll give a step-by-step example of how application assembly (e.g. composition) using SCA works in a Java EE context.

Let’s start with some background, from the OASIS Open Composite Services Architecture Member Section:

SCA is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture (SOA). SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

The goal of integrating SCA with Java EE is to preserve the Java EE investment for developers and vendors, while giving them a framework which can be adapted to new component models going forward. In order to do that, we want to create an evolutionary model for SCA that makes Java EE more SOA ready by extending the Java EE application model to new implementation technologies (such as BPEL), new protocol bindings and new assembly models. The 1.0 spec of SCA is nearly final, and is now a part of the Open Composite Services Architecture working group, and SAP is actively taking part in this collaboration.

The best way to understand the changes taking place is to look at them from the Java EE perspective. What we see today is that vendors have provided lots of different frameworks to enrich their platforms with additional implementation capabilities and bridge Enterprise Service Bus (ESB) capabilities. BPEL Run Time is one example. And there are the usual ESB suspects, like mapping, routing, and protocol translations. And we see people providing this in alternate runtimes. We also see Web services being used by ESB and Business Process Modeling Notation (BPMN) technologies.

What SCA offers is an assembly concept that provides, first on an abstract level, an integration of all these technologies and ESB capabilities. Specifically, a Java EE developer can start, for example, using BPEL markup to describe a BPEL process, and this BPEL process can perform a local invocation of your applications and expose services and references globally to one unique SCA-described interface. A consumer would not be able to tell whether it’s BPEL or Java or something else. That’s the encapsulation and integration value, in a nutshell.

By mapping Java EE to SCA, there were several integration scenarios we wanted to support. So what would we expect to see when trying to integrate Java EE with SCA? We want to consume SCA exposed service wherever we are in Java EE. We want to have first class integration with Session Beans (including the ability to expose SCA services as Session Beans, use Session Beans as service component implementations and expose enterprise applications into an SCA domain). And finally we want to have extended cross-application assembly capabilities.

In order to achieve these goals, we have to support some implementation types: Session Beans: Session Beans are a natural choice for service component implementations, and we assume they can be used with SCA annotations.

Web Components, Message-Driven Beans: While Web components do not offer services, we would still like to use SCA annotations to declare consumption of SCA services. The way we can provide this capability is to model them as service component implementations that simply do not offer services.

On the binding side we have new things in store as well: JMS EJB Session Beans (local consumption and exposure, co-located and remote consumption and exposure) JCA/EIS (binding spec work in progress)

So, how do we handle packaging and deployment of this? Java EE packaging suggests the right contribution packaging: Enterprise Application Packages (.ear) and single modules (.war, .jar, .rar).

Those packages can be enriched with SCA metadata (i.e. SCDL artifacts) for internal assembly and domain assembly similarly to deployment descriptors.

By keeping them separate from Java EE deployment descriptors, just like vendor-specific deployment descriptors, SCA metadata may be applied over existing packages!

All of this has been achieved and is ready for implementation. In part 2 of this blog I will show a simple example that will make these concepts even clearer.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.