Printed: Oct 4, 2024
From: http://www.jcp.org/en/jsr/detail?id=208

Standard Format

Community
Expert Group

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 208: JavaTM Business Integration (JBI)

Stage Access Start Finish
Final Release Download page 25 Aug, 2005  
Final Approval Ballot View results 07 Jun, 2005 20 Jun, 2005
Proposed Final Draft 2 Download page 31 May, 2005  
Proposed Final Draft Download page 03 May, 2005  
Public Review Ballot View results 29 Mar, 2005 04 Apr, 2005
Public Review Download page 04 Mar, 2005 04 Apr, 2005
Early Draft Review Download page 08 Oct, 2004 22 Nov, 2004
Expert Group Formation   18 Mar, 2003 09 Feb, 2004
JSR Review Ballot View results 04 Mar, 2003 17 Mar, 2003
Status: Final
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0


Description:
This JSR extends J2EETM and J2SETM with business integration SPIs.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Ron Ten-Hove Sun Microsystems, Inc.
  Peter Walker Sun Microsystems, Inc.
Expert Group
  Apache Software Foundation Askary, Sid Borland Software Corporation
  Capgemini Collaxa DPWN SOP Group
  Fujitsu Limited Intalio, Inc. IOPSIS Software Inc.
  Liu, Jie Nokia Corporation Novell, Inc.
  Oak Grove Systems Oracle Potter, Timothy
  Progress Software Red Hat Research In Motion, LTD (RIM)
  SAP SE SeeBeyond Technology Corp. Sonic Software
  Sun Microsystems, Inc. Sybase TIBCO Software Inc.
  TmaxSoft, Inc. Vignette WebMethods Corporation

Updates to the Original Java Specification Request (JSR)

The following changes have been made to the original JSR:

Specification Leads: Ronald Ten-Hove, Peter Walker

E-Mail Address: ronald.ten-hove@sun.com, peter.walker@sun.com

Telephone Number: +1 510 574 5565, +1 408 276 7321

Fax Number: -,+1 408 276 7191

2.1 Please describe the proposed Specification:

Java Business Integration JSR (JBI) extends J2EE and J2SE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.

The industry is currently on the path to define standards for business integration that form a new layer of standard metadata in the web services stack. While this work is not complete as yet, the general shape of this standard metadata can be seen in the WSCI and BPEL4WS proposals. The industry needs a standard in this space and we look to the recently chartered W3C Choreography Working Group to drive the convergence of these and other related efforts. The JBI SPIs will reflect the industry consensus that emerges from this work.

This JSR uses the following terms to further classify this standard business integration metadata. The term 'business protocol' is an umbrella term for the metadata used to describe the interaction between a set of business processes that implement the roles of partners within a larger service composition. The term 'abstract business process' is the metadata that describes how a business process, within a business protocol, choreographs its role in a service composition so that its partner processes understand how to interact with it. It should be noted that the term 'business process' in this context means any actor that participates in the business protocol. In finer grained situations, a 'business process' could be something as simple as a data transformation table or a few business rules.

JBI employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI Components. JBI Components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI JSR itself does not define how developers code Components. Both standard and proprietary ways of coding Components may exist. A specific class of Component may provide rich business process functionality while another class of Component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding.

A JBI Application is composed of one or more JBI Components and service assemblies.

JBI divides the task of supporting JBI Components into three roles - the JBI Environment, the JBI Machine and the JBI Binding. The focus of the JBI JSR is the role of the Environment and its support for Machines and Bindings. It treats both Machines and Bindings as black boxes that interact with it via Environment SPIs.

The Environment defines a standard internal representation for business protocol messages based on standard business protocol metadata. This representation is an important element of the Environment SPI that links Environments, Machines and Bindings.

JBI Machines are responsible for supporting the lifecycle of a particular class of JBI Components. For instance, if a JSR defines a standard way of coding a Component, then the existence of a Machine supporting this Component model would allow the Environment to add support this Component model. Likewise, a vendor could produce a Machine that supports its proprietary Component model and this Machine could be deployed on the Environment. The Environment provides the base business protocol communication infrastructure that allows Components (through their Machines) to communicate with each other and with external services. The Environment also defines a standard Machine packaging model and a standard Machine deployment and instantiation lifecycle.

JBI Bindings are used by the Environment to communicate with external services via specific business protocol bindings. The role of a Binding is to implement a specific communications binding for the Environment's standard internal representation of business protocol messages. The Environment also defines a standard Binding packaging model and a standard Binding deployment and instantiation lifecycle.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2EE 1.4 and J2SE 1.4

2.3 What need of the Java community will be addressed by the proposed specification?

Developers will be building services that interact via business protocols. Java platforms can be augmented with a business protocol infrastructure to support the range of integration component models and the range of bindings these services will require.

2.4 Why isn't this need met by existing specifications?

Java does not currently adequately support service-oriented integration technologies.

2.9 Are there any internationalization or localization issues?

JBI's internationalization and localization will be handled by a combination of the functionality provided by the platform and web services standards.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Edwin Julson

E-Mail Address: ed.julson@sun.com

Telephone Number: +1 408 276 7151

Fax Number: +1 408 276 7191


Specification Lead: Mark Hapner

E-Mail Address: mark.hapner@sun.com

Telephone Number: +1 408 276 7105

Fax Number: +1 408 276 7191

NOTE this information has been updated from the original JSR.

Initial Expert Group Membership:

BEA Systems
Sun Microsystems

Supporting this JSR:

BEA Systems
SeeBeyond
Sybase



Section 2: Request

2.1 Please describe the proposed Specification:

NOTE that this section has been updated from this original request.

Java Business Integration JSR (JBI) extends J2EE with business integration SPIs. These SPIs enable the creation of a Java business integration environment for specifications such as WSCI, BPEL4WS and the W3C Choreography Working Group.

The industry is currently on the path to define standards for business integration that form a new layer of standard metadata in the web services stack. While this work is not complete as yet, the general shape of this standard metadata can be seen in the WSCI and BPEL4WS proposals. The industry needs a standard in this space and we look to the recently chartered W3C Choreography Working Group to drive the convergence of these and other related efforts. The JBI SPIs will reflect the industry consensus that emerges from this work.

This JSR uses the following terms to further classify this standard business integration metadata. The term 'business protocol' is an umbrella term for the metadata used to describe the interaction between a set of business processes that implement the roles of partners within a larger service composition. The term 'abstract business process' is the metadata that describes how a business process, within a business protocol, choreographs its role in a service composition so that its partner processes understand how to interact with it. It should be noted that the term 'business process' in this context means any actor that participates in the business protocol. In finer grained situations, a 'business process' could be something as simple as a data transformation table or a few business rules.

JBI extends the J2EE application packaging and deployment functionality to include JBI Components. JBI Components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI JSR itself does not define how developers code Components. Both standard and proprietary ways of coding Components may exist. A specific class of Component may provide rich business process functionality while another class of Component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding.

A JBI Application is composed of one or more JBI Components. It may also include J2EE modules as defined by the J2EE Platform.

JBI divides the task of supporting JBI Components into three roles - the JBI Environment, the JBI Machine and the JBI Binding. The focus of the JBI JSR is the role of the Environment and its support for Machines and Bindings. It treats both Machines and Bindings as black boxes that interact with it via Environment SPIs.

The Environment defines a standard internal representation for business protocol messages based on standard business protocol metadata. This representation is an important element of the Environment SPI that links Environments, Machines and Bindings.

JBI Machines are responsible for supporting the lifecycle of a particular class of JBI Components. For instance, if a JSR defines a standard way of coding a Component, then the existence of a Machine supporting this Component model would allow the Environment to add support this Component model. Likewise, a vendor could produce a Machine that supports its proprietary Component model and this Machine could be deployed on the Environment. The Environment provides the base business protocol communication infrastructure that allows Components (through their Machines) to communicate with each other and with external services. The Environment also defines a standard Machine packaging model and a standard Machine deployment and instantiation lifecycle.

JBI Bindings are used by the Environment to communicate with external services via specific business protocol bindings. The role of a Binding is to implement a specific communications binding for the Environment's standard internal representation of business protocol messages. The Environment also defines a standard Binding packaging model and a standard Binding deployment and instantiation lifecycle.

NOTE that this section has been updated from this original request.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

NOTE that this section has been updated from this original request.

J2EE 1.4

2.3 What need of the Java community will be addressed by the proposed specification?

NOTE that this section has been updated from this original request.

J2EE developers will be building services that interact via business protocols. J2EE needs a business protocol infrastructure to support the range of integration component models and the range of bindings these services will require.

2.4 Why isn't this need met by existing specifications?

NOTE that this section has been updated from this original request.

The J2EE Platform does not currently provide the full infrastructure needed to support business protocols.

2.5 Please give a short description of the underlying technology or technologies:

See Section 2.1

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The proposed package name is 'javax.jbi'.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

There are no such dependencies.

2.8 Are there any security issues that cannot be addressed by the current security model?

The majority of a JBI application's security requirements at the business protocol layer will be handled by JBI Bindings. A Binding will use a combination of web service standards and Java security standards to satisfy its security needs.

2.9 Are there any internationalization or localization issues?

NOTE that this section has been updated from this original request.

JBI's internationalization and localization will be handled by a combination of the functionality provided by the J2EE Platform and web services standards.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

There are none.

2.11 Please describe the anticipated schedule for the development of this specification.

Expert Group Formation - April 2003
Community Review - December 2003
Public Review - February 2004
Final Draft - December 2004

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Sun will deliver a standalone Reference Implementation (RI) and Technology Compatibility Kit (TCK).

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Pursuant to Section 2.2.1 of the Java Community Process version 2.5, the following is a summary of Sun's anticipated principal license terms and conditions for the Java Business Integration, version 1.0.

Non-Commercial Use
The Java Business Integration 1.0 Technology Compatibility Kit (TCK) will be licensed at no charge, without support, to qualified not-for-profit entities (including not-for-profit academic institutions and individuals) who are engaged in efforts to create compatible implementations of the Specification.

Commercial Use
The Reference implementation (RI) and TCK will be separately licensable.
Any use of the Specification that doesn't fall under Non-Commercial Use (above) will require a fee-based TCK license from Sun Microsystems Inc. The RI will be available to Commercial Use TCK licensees for use in their efforts to create compatible implementations of the Specification.

Support
A Technology Compatibility Kit Support contract is required for Commercial Use.





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

  1. JCP Specification “The J2EE 1.4 Platform Specification”
  2. W3C Recommendation “ The XML Specification”
  3. W3C Recommendation “XML Schema Part 1: Structures”
  4. W3C Recommendation “XML Schema Part 2: Datatypes”
  5. W3C Note “Simple Object Access Protocol (SOAP) 1.1”
  6. W3C Note “Web Services Definition Language (WSDL) 1.1”
  7. W3C Note “Web Service Choreography Interface (WSCI) 1.0”
  8. W3C Choreography Working Group
  9. IBM, Microsoft and BEA Document “Business Process Execution Language for Web Services (BPEL4WS), Version 1.0”
  10. The BEA Process Definition for Java JSR

3.2 Explanation of how these items might be used as a starting point for the work.

JBI extends J2EE 1.4 with SPIs to support business integration. The W3C specifications are building blocks for JBI business protocol metadata. The WSCI and BPEL4WS documents are potential starting points for the W3C Choreography Working Group and therefore indirectly influence JBI.

The BEA Process Definition for Java JSR defines the Java APIs and JSR 175 Annotations a Java developer uses to implement a business process. Support for the BEA JSR can be added to the JBI Environment by providing a JBI Machine that supports it. This illustrates the complementary nature of the JBI SPIs and the BEA JSR APIs.