Sun has submitted JSR-312, Java Business Integration 2.0 (JBI 2.0), to the Java Community Process. According to the JSR,
Java Business Integration JSR (JBI) extends Java EE and Java SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for the creation of Composite Applications involving such technologies as BPEL, Rules, XSLT and existing Java implementations to name just a few. The purpose of the JBI 2.0 specification is to address a number of open areas in the JBI 1.0 specification and then augment it to address several new requirements of the community as described below.
Composing applications within a Service-oriented architecture (SOA) such as JBI 1.0-compliant systems presents a unique set of challenges. This becomes even more demanding when separate processes must be coordinated, across separate services. The complexity of defining and executing such applications rises even further when distributed services (including processes) are involved, such as found in an Enterprise Service Bus (ESB). The complexity rises even further with the application is distributed across different domains of control. JBI 1.0 defines a static model of services; there is no indication about sequencing, timing, or conditions to be placed on the use of services, or the interactions of two or more components acting as consumers and providers.
The areas we intend to address include, but are not limited to, the following:
- Enhancements to facilitate the use of JBI in clustered or distributed environments, principally with respect to administration rather than the clustering/distribution mechanism itself.
- Enhancements to clarify and enhance the use of JBI in a SOA-based approach to the creation, deployment and runtime support of Composite Applications.
- Enhancements to support requirements stemming from WS-Policy.
- Enhancement to support Web 2.0 technologies and usage models.
- Introduction of a Message Exchange handler/interceptor model.
- Enhancements to facilitate performance optimizations by component and container implementers.
- Improved alignment with Java EE (e.g. use of transactions).
- Recoverability of Message Exchanges.
- Improved readability of the specification to clarify the needs of container, component and application developers.
- Alignment with the Service Component Architecture (SCA) specifications (see www.osoa.org) with the goal of making JBI 2.0 a standard Java runtime for SCA .
- Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.
- Technical issues stemming from implementation experience using the JBI 1.0 specification (e.g. life-cycle of components, error handling, interop profiles, examination of the utility of WSDL definitions for non-Web Services deployed components, component attributes, threading, NIO use, classpath or endpoint activation)
In addition, standards such as WS-CDL provide a normative vocabulary for expressing the dynamic aspects of service use and interaction that is lacking in JBI 1.0. This type of description is useful for designing (composing) applications, modifying (recomposing) them, and permitting run-time discovery and enforcement of dynamic interaction rules. The Expert Group will investigate use cases stemming from the use of other collaboration models such as this to see whether enhancements are needed.
The goal of the JBI 2.0 Expert Group will be to investigate these directions and identify and pursue others through which the JBI architecture can be kept simple but new component (bindings and services) functionality enhanced for various usage audiences. A further goal of is to deliver these new features into the JBI specification in a timely manner.