 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 150: Internationalization Service for J2EE
This JSR has been Withdrawn The following information has been updated from the original request.
2006.02.22: 2.11 Please describe the anticipated schedule for the development of this specification.Community Review: Nov. 21, 2005 - Dec. 21, 2005 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: IBM Name of Contact Person: David Zavala E-Mail Address: dzavala@us.ibm.com Telephone Number: +1 507 253 5628 Fax Number: +1 507 253 3495 Specification Lead: Debasish Banerjee E-Mail Address: debasish@us.ibm.com Telephone Number: +1 507 253 5732 Fax Number: +1 507 253 4456 Initial Expert Group Membership: IBM Section 2: Request
2.1 Please describe the proposed Specification:The Internationalization service is an infrastructure that transparently propagates and manages localization information within distributed J2EE applications. 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?In a distributed environment application processes may run on different machines configured to operate under different cultural conventions and be located across geographical boundaries, conditions which generally manifest as a mismatch in locale and time zone, respectively, between client-side and server-side components. Such mismatches entail that an application perform localizations to ensure usability and correctness. Without systematic internationalization support the conventional solution to the locale and time zone mismatch problems is to pass additional parameter(s) on all methods necessary for propagating client-side localization information (i.e., locale or time zone) to corresponding server-side implementations sensitive to this information. Though outwardly simple, this technique has serious limitations that may render it impractical within distributed enterprise applications. Adding parameters to propagate localization information is intrusive, necessitating that one or more parameters be added to all methods in the call chain to a locale- or time zone-sensitive method. Consider also that, although some methods are intrinsically sensitive to localization information, all business methods are potentially sensitive as they can throw exceptions whose text should be formatted according to the cultural expectations of the caller environment. So, this solution is implicitly pervasive and susceptible to error, due to its manual nature. Internationalizing applications in this ad-hoc manner is costly, too, because propagating localization information via additional parameters entails interface revisions within exiting applications. Within a distributed enterprise application revising the interface of a server-side component, such as an EJB, entails redeploying that component plus all dependent components - a time consuming task at best. Hence, a new challenge exists regarding the internationalization of distributed enterprise applications: To architect an infrastructure that addresses localization problems in a standard, prescribed manner while alleviating limitations inherent to conventional solutions by simplifying internationalization support and shielding developers from costly programming practices. 2.4 Why isn't this need met by existing specifications?Internationalization support supplied in J2EE (i.e., J2SE Internationalization facilities) lacks the infrastructure necessary to support localization within applications distributed across multiple JVMs. To maintain a managed run-time environment for application components, Internationalization support within J2EE should provide facilities to transparently propagate localization information throughout an enterprise application; further, these facilities should allow the end-user to both programmatically and declaratively manage localization information within relevant application components. This quality of Internationalization support has yet to be addressed by prominent distributed application framework architectures, including J2EE. 2.5 Please give a short description of the underlying technology or technologies:The Internationalization Service utilizes and augments the existing Internationalization support supplied in J2SE. To serve localization information within enterprise applications, the Internationalization Service will require support from J2EE architectural elements and middleware, including the J2EE server, the EJB and Web Containers, rudimentary support from the Application Client Container (as Application clients are essentially non-managed,) and the RMI-IIOP ORB. Localization information should also propagate to back-end resource managers in order that the corresponding Enterprise Information Systems (EIS), including database management systems, can properly localize relevant computations. This will necessitate lightweight extensions to the existing J2EE Connector Architecture and JDBC specifications. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)To be determined. 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?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.NOTE that this information has been updated from this original request.A first draft of the specification, only, can be submitted within 8 weeks from the date on which this proposal is accepted. The final specification, reference implementation and technology compatibility kit for the J2EE Internationalization Service can be available 4Q2002. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.As 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.At present, the J2EE Internationalization Service design will refer to the following documents. J2EE 1.3 Platform specification draft 4.0: http://java.sun.com/j2ee/download.html Enterprise Java Beans specification 2.0: http://java.sun.com/products/ejb/docs.html Java Servlet specification 2.3: http://jcp.org/aboutJava/communityprocess/first/jsr053/ JavaServer Pages specification 1.2: http://jcp.org/aboutJava/communityprocess/first/jsr053/ Java Naming and Directory Interface specification 1.2.1: http://java.sun.com/products/jndi/1.2/javadoc/ J2SE 1.3 Platform and SDK API documentation set: http://java.sun.com/j2se/1.3/docs/ OMG CORBA specification 2.4.2: http://www.omg.org/technology/documents/formal/corba_2.htm W3C HTTP specification 1.1: http://www.w3.org/Protocols/rfc2616/rfc2616.html 3.2 Explanation of how these items might be used as a starting point for the work.To date no explicit documents exist regarding internationalization support within distributed J2EE applications; however, the EJB specification contains chapters describing support for transactions and security -- services that manage application contexts. The Internationalization Service performs a similar function in that it will transparently propagate and manage localization context. The Internationalization Service API will be accessible via JNDI operations, which are described in the Java Naming and Directory Interface specification. The Internationalization Service will utilize types Locale, TimeZone, and SimpleTimeZone; all of which are described in the J2SE SDK API documentation. The HTTP specification defines language tag information contained within HTTP requests originating from Web browsers. Support for importing this information into server-side Web application components appears within the Servlet specification. The OMG CORBA specification describes RMI-IIOP inter-process communication between J2EE Java client programs and EJBs. RMI-IIOP support is also described in the J2SE documentation set. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.IBM intends to expand the scope of the Internationalization Service specification to eventually include WebServices and J2EE Connectors to back-end resources, making the following documents relevant. Although specific versions are indicated, these documents require revision to support the Internationalization service. JSR109 and dependent specifications: http://www.jcp.org/jsr/detail/109.jsp J2EE Connector specification: http://java.sun.com/j2ee/download.html Java Database Connectivity specification: http://java.sun.com/products/jdbc/download.html |
