 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 159: JavaTM Process Component API (JPC)
This JSR has been Withdrawn
Identification |
Request |
Contributions
Original Summary: JPC will define a loosely coupled, event based process component model that will simplify the development of composable, customizable services. It is envisioned that JPC would become part of the J2EE Platform; however, the realization of this goal is beyond the scope of this JSR. Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Mark Hapner E-Mail Address: mark.hapner@sun.com Telephone Number: +1 408 276 7105 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 Initial Expert Group Membership: BEA Supporting this JSR: BEA Section 2: Request
2.1 Please describe the proposed Specification:Overview: The Java Process Component (JPC) model will allow developers to directly represent a component as a service process that interacts via XML schema based events, produced and consumed through its typed ports. It will provide a facility for combining a group of process components into a collaboration that defines the linkage between their ports and their content types. It will also define a conversation mechanism that allows a developer to specify a stateful interaction sequence between ports. JPCs will allow developers to directly model event based services as individual components and collaborations. JPC will define both synchronous and asynchronous interaction modes. The JPC container will provide the infrastructure for life cycle management, transactions, security, content flow and content transformation. In addition, JPC containers will provide facilities for exposing JPCs and JPC collaborations as a web service and support the use of a web service within a JPC collaboration. An important goal of JPC is to enable visual tool based customization and composition of process components. Details: The goal of JPC is to provide J2EE developers with the ability to compose an application out of service level components (where service in this context means a loosely coupled, event based process). Today, J2EE developers build applications that implement a service; however, there is no formal way to describe the full semantics of a service to the J2EE container. There is no formal concept of a service as a J2EE component nor is there a formal concept of service composition. For some time, the computing industry has struggled to find a component abstraction that balanced the need for type safety with the need for loosely coupled, event based composition. The most recent and most promising solution to this problem is the EDOC Component Collaboration Architecture. In addition to standing alone as a service component architecture, CCA is closely related to the WSDL model for web services. Both are loosely coupled, port based models of service integration; however, the CCA goes much further to explicitly define a rich collaboration model. Their similarities make it practical to view WSDL as a web service adjunct to CCA rather than a different, competing technology. Rather than inventing yet another service component model, JPC will be based on the existing EDOC Component Collaboration Architecture. While JPC will draw on EDOC concepts and design, EDOC neither constrains nor defines requirements for JPC. JPC will define a programming model for process components composed of developer APIs; deployment descriptors and container contracts. The JPC model will be fully recursive. That is, a collaboration of JPCs will appear externally as a JPC and can itself be used as an element of a further collaboration. The scope of a collaboration will likely be limited to JPCs within a JPC container plus some form of proxy JPC that is a local proxy for a web service. Since the JPC container will have significantly less control over JPC web service proxies than over its local JPCs, collaboration with them will be more restricted than collaboration between local JPCs. JPC web service proxies may be generated automatically by JPC container tools or they may be developed manually using J2EE web service client facilities. The JPC container will provide facilities for exposing a JPC as a web service. Specifically, JAX-RPC and JAXM will be supported as producers and consumers of JPC events. In some cases, a developer may choose to expose a JPC's ports directly as web service ports. In other cases, a JPC port may be exposed indirectly via a JPC port adapter. The web service model will be the distributed view of a JPC. JPC will be well poised to take advantage of distribution optimizations of this model as they are defined by the web service community. J2EE may also define optimizations that apply only within the J2EE community. Both forms of optimization will be transparent to JPC's. JPCs will not obsolete the existing J2EE component models - JSPs, Servlets and EJBs. These models will continue to be the basic building blocks of J2EE applications. The JPC component model will provide a mechanism for layering a process level abstraction over these components. In effect, it will be a way to aggregate a combination of JSPs, Servlets and EJBs to form a process level component. This means that JPC will introduce a minimum of new programming concepts and will focus primarily on the 'binding' of a process definition to its implementation as J2EE components. It is a primary goal of JPC to simplify the development of web services. It is also a primary goal to provide enhanced collaboration of service components when they are used locally within a JPC container. In order to achieve both goals, the JPC web service binding must be a first class element of the JPC model and it must be clear to developers how to maximize both the web service level collaboration potential and the JPC collaboration potential of their components. The goal is to define the JPC model as the 'future' of web services and to incrementally to expose more of it as web services evolve to support a richer collaboration architecture. The JPC model is based on an event driven service concept. A JPC defines its function in terms of input and output ports and the content that flows through them. This model simplifies adapting a JPC to fulfill multiple roles. The JPC container enables this style of development by injecting the plumbing for composing JPCs as opposed to building plumbing dependencies into a JPC. For instance, the JPC container will provide a reliable handoff between asychronously coupled JPCs without exposing the mechanism this requires. This injected plumbing simplifies creating a JPC and makes it easier to customize/compose its function. The JPC model will close part of the gap between existing J2EE components and workflow/business process functionality; however, JPCs will not, on their own, provide such functionality. The JPC collaboration mechanism is focused primarily on constructing a service within an atomic transaction. It will also provide basic support for longer running conversations between services but these will be focused more on the mechanics of a conversation and less on the larger issues of enterprise wide choreography of business processes. It is expected that many workflow/business process products will provide orchestration facilities for JPCs, either as extended functionality of the JPC container itself or by orchestrating JPCs that are made available as web services. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2EE 2.3 What need of the Java community will be addressed by the proposed specification?IThe JPC model will allow J2EE developers to formally model and implement a service level abstraction as a J2EE component. This enhances the J2EE platform because it allows the platform to directly capture the semantics of the services that are the goal of the J2EE developer. This gives the J2EE container significantly more leverage to simplify the implementation, assembly, deployment and execution of a service. 2.4 Why isn't this need met by existing specifications?No current J2EE specification defines a process component model. 2.5 Please give a short description of the underlying technology or technologies:This JSR builds on the facilities provided by the J2EE 1.4 Platform JSR and is intended to be included in a future version of the J2EE Platform. It will utilize the existing component models defined in J2EE. See section 2.1 for more information. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.jpc.* 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 2.8 Are there any security issues that cannot be addressed by the current security model?No, although applications built with this JSR may also depend on the facilities defined by JSRs 105, 106 and 155. 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.11 Please describe the anticipated schedule for the development of this specification.Public Draft - October 2002 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Kickoff meeting with Experts as the first step after the Expert Group is formed. Email list for distribution of specification and open discussion among experts. One-on-one meetings per expert company request. Expert Group conference calls as needed. F2F meetings as needed. 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.- XML Schema Specification (w3c Recommendation 2 May 2001) 3.2 Explanation of how these items might be used as a starting point for the work.XML Schema definition will be used to describe JPC event types. J2EE APIs provide the platform definition on which JPC will add functionality. EDOC CCA defines the conceptual model for process components and collaborations. This model will be a primary input to the JPC work; however, it neither constrains nor defines requirements for JPC. WSDL is the current standard for describing a web service. JAXP and JAXB provide the functionality that JPCs use to work with the event content they produce and consume. XPath and XSLT may be used in a JPC collaboration to provide the content transformation needed to integrate content exchange between components. JAX-RPC, JAXM and JAXR will be used to both to expose JPCs as a web service and to create the JPC proxies needed to include a web service within a JPC collaboration. JSR 109 will define J2EE web service bindings and packaging. Tools support for JPC is critical and the JMI API for the MOF metadata facility is technology that will help speed the development of JPC tools. JPC components may need to exchange security assertions between themselves and with the outside world of web services, if so, JSR 155 will define that exchange. |
