InfoQ

News

Strengthening the Alliance Between Java EE and SCA

Posted by Boris Lublinsky on Apr 03, 2008 09:00 AM

Community
SOA
Topics
SOA Platforms ,
WS Standards ,
SOA Appliance
Tags
Service Component Architecture ,
Java EE

The Open SOA collaboration has just published a 0.9 draft of the SCA Java EE Integration specification. This specification defines the integration of SCA and Java EE within the context of a Java EE application, the use of Java EE components as service component implementations, and the deployment of Java EE archives either within or as SCA contributions. It defines a model of using SCA assembly in the context of a Java EE runtime that enables integration with Java EE technologies on a fine-grained component level as well as use of Java EE applications and modules in a coarse-grained large system approach.

The specification defines support for the following scenarios of Java EE and SCA integration:

  • Consumption of SCA-exposed services from Java EE components. The specification defines how a web component (a servlet or a JSP) can consume a service implemented by a SCA service component.
  • Usage of Session Beans as Service Component Implementations. The specification defines how to use a session bean as service component implementations. Using RMI, JMS and web services traffic.
  • Exposure of Enterprise Applications into an SCA domain. The specification defines relationships between SCA and Java EE Assembly models and describes a deployment model for SCA contributions that provides cross-enterprise application assembly capabilities when layered over Java EE.
  • Usage of Recursive SCA Assembly in Enterprise Applications. The specification describes how SCA Assembly can be used to provide means for defining sophisticated application assembly for enterprise applications.
  • Deployment of SCA Components as a Part of a Java EE application. The specification defines a deployment model for components implemented in “foreign” technologies (for example BPEL) as part of a Java EE application, taking advantage of whatever tooling and infrastructure support exists for the deployment and life cycle management of Java EE applications.
  • Usage of Java EE Archives as Service Component Implementation. The specification defines creation of high level SCA applications that contain multiple Java EE archives, through wiring of Java EE archives to each other and to components implemented using other technologies. This use-case requires a high-level view of the Java EE application as a single SCA component, providing services and consuming references as a single component.

Additionally, support for SCA annotations in EJB classes or session bean interfaces is defined.

This specification aims to further strengthen relationships between Java EE and SCA, putting SCA in a better position for becoming a prevalent technology for SOA implementation in Java EE. One of the major motivations for doing so is that currently, the Java community is still split between SCA and JBI.  The JSR 316: Java Platform, Enterprise Edition 6 (Java EE 6) Specification is still considering both, but has not made a definite decision which way to go.While the majority of vendor’s application servers support SCA, open source implementation are still mostly based on JBI.

The standardization process for SCA is currently driven by OASIS and OSOA and still lacks full support by Java.

It's not JBI versus SCA by Peter Walker Posted Apr 4, 2008 11:43 AM
TLA-itis by Jim Leonardo Posted Apr 4, 2008 4:56 PM
  1. Back to top

    It's not JBI versus SCA

    Apr 4, 2008 11:43 AM by Peter Walker

    This misrepresents the technical reality. There's really very little overlap between JBI and SCA and as described for example at the OSOA site here. The two can be complementary. An SCA system can be built atop a Java EE platform augmented by JBI. JBI is all about pluggability in the infrastructure not directly the creation of service networks. Peter.

  2. Back to top

    TLA-itis

    Apr 4, 2008 4:56 PM by Jim Leonardo

    Just a general comment... SCA is probably not in quite common enough use yet to throw in a headline without defining in the body of the article. SCA: Society for Creative Anachronism? Scottish Canoe Association? Software Communications Architecture? Service Component Architecture?

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.