 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 208: JavaTM Business Integration (JBI)
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 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 Telephone Number: +1 408 276 7151 Fax Number: +1 408 276 7191 Specification Lead: Mark Hapner E-Mail Address: mark.hapner 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 Supporting this JSR: BEA Systems 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 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 Commercial Use Support 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.
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. |
