 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 149: Work Area Service for J2EE
This JSR has been Withdrawn Note that the following information has been updated from the original JSR.
Specification Lead: Heath Thomann E-Mail Address: hthomann Telephone Number: +1 507 253 8752 Fax Number: +1 507 253 3495 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Note that this section has been updated from this original information. Submitting Member: IBM Name of Contact Person: Logan Colby E-Mail Address: lcolby Telephone Number: +1 507 253 8741 Fax Number: +1 507 253 3495 Specification Lead: Logan Colby E-Mail Address: lcolby Telephone Number: +1 507 253 8741 Fax Number: +1 507 253 3495 Initial Expert Group Membership: IBM Section 2: Request
2.1 Please describe the proposed Specification:The Work Area Service specification will describe a mechanism to allow developers of Java 2 Enterprise Edition applications to define properties as application context; that context will implicitly flow across remote requests and allow downstream components to work in the context of a specific invoking client. This specification will leverage the functionality of the proposed Activity Service for Extended Transactions (http://www.jcp.org/jsr/detail/95.jsp) to define a system of programmatically demarcated contextual boundaries that will define the availability of properties significant to the application. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java 2 Enterprise Edition 2.3 What need of the Java community will be addressed by the proposed specification?The Java 2 Enterprise Edition provides a framework for the development of multi-tier distributed applications, supported by standard services like security and transactions to protect and coordinate server-side resource utilization. Developers are leveraging the Java 2 Enterprise Edition specification to develop increasingly complex applications that include components developed in-house, components developed by third-parties, and legacy applications. However, many developers are discovering that the integration of the pieces that make up their application requires access to data that cannot be realistically declared as parameters on every method for every component. Security context and transactional context make important pieces of the metadata that describes a request and allows the server infrastructure to process a request; however, developers require the ability to extend the metadata associated with requests in order to reflect context particular to their application. Specific scenarios from the real world include developers who need to:
extend the identity of a user to a structure that includes data like workstation ID, branch number, etc. Developers today have only limited mechanisms available to try to accommodate such requirements. One is to add parameters to every interface in the system. This is impossible in many scenarios, however, where the designer of the distributed application doesn't have the ability to influence or change interfaces from other vendors or legacy application; even where possible, the resulting code becomes extremely difficult to maintain. Another mechanism is to invent a system where information is stored in naming and looked up by some key like the security principal. This solution has serious performance penalties, however, and a security principal does not communicate the correct thread-scoping. Finally, sophisticated developers can implement their own solution leveraging the support provided by the OMG's Portable Interceptor specification. However, many Java 2 Enterprise Edition vendors reasonably discourage or prevent access to interceptor registration, and this solution would not support propagation into and across components deployed on different vendor's application servers. This JSR addresses the issues identified above by providing a standardized mechanism that allows J2EE components to set and retrieve properties into and from a distributed context defined by a particular application and associated with a particular request. 2.4 Why isn't this need met by existing specifications?As noted in section 2.3, the context that is associated with a request and available to developers within a J2EE runtime is limited to transactional status and the security principal. The J2EE specification currently provides no other mechanism for developers to define extended context to be associated with a request. 2.5 Please give a short description of the underlying technology or technologies:The J2EE Work Area Service is based upon the technologies both proposed and already standardized as part of the Java 2 platform, Enterprise Edition. Specifically, the Work Area service leverages concepts and mechanisms defined by the Activity Service for Extended Transactions (JSR 95) and the Enterprise JavaBeans (EJB) specifications. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Not yet decided. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No 2.9 Are there any internationalization or localization issues?The internationalization support already provided by the Java 2 platform resolves Work Area service internationalization issues. 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.Anticipated to be available 3Q2002. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.The working model should follow the process described in the JCP2 process document. 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.A high-level description of how this functionality has already been implemented for the WebSphere Enterprise platform at
http://www-4.ibm.com/software/webservers/appserv/whitepapers/j2ee_enterprise.pdf (page 11). 3.2 Explanation of how these items might be used as a starting point for the work.Because the Activity Service is a prerequisite for the Work Area Service functionality, either the Activity Service JSR or the Activity Service specification for the OMG should be read first. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.None at this time. |
