 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 193: Client Side Container (CSC)
This JSR has been Withdrawn
Identification |
Request |
Contributions |
Additional Information
Original Summary: This spec describes a client side container architecture, which provides the common client infrastructure like: logging, security, internationalization, configuration, lifecycle management etc. It provides an architecture for developing API neutral clients (Swing, AWT, Command Line). The access to J2EE-components will be also fully abstracted and encapsulated. Section 1. Identification Submitting Member: Adam Bien Name of Contact Person: Adam Bien E-Mail Address: abien@adam-bien.com Telephone Number: +49 89 909 69004 Fax Number: +49 89 909 69027 Specification Lead: Adam Bien E-Mail Address: abien@adam-bien.com Telephone Number: +49 89 909 69004 Fax Number: +49 89 909 69027 Initial Expert Group Membership: Adam Bien Supporting this JSR: No official supporters Section 2: Request
2.1 Please describe the proposed Specification:Client Side Container (CSC) simplifies the development of clientside applications (also invisible ones like e.g. searchengines) and abstracts the common api's like Webstart, JAAS
It abstracts the J2SE API's and provides a common framework for applications on the client. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE Desktop, personal, embedded, card (could be used also on the server - but we have already J2EE), residential gateways 2.3 What need of the Java community will be addressed by the proposed specification?All J2SE-APIs are really low level. What the community needs is an abstraction layer and architecture guideline to develop clientside applications. This not addressed by existing specifications, because all what we have are the API's or drivers. CSC is a platform upon this APIs. With CSC the development time could be really shortened and also unexperienced developers were able to develop an application on it. So we get the same benefits, as with J2EE but on the clientside. Also the problems how to access J2EE-componets are solved by my CSC, because the access to the business-tier could be fully abstracted. 2.4 Why isn't this need met by existing specifications?Other API's provide just special, independent services. This API provides common architecture with some best practises for java-apps. In my last projects, every time we have to build a common infrastructure for the clients. Otherwise we were extremely tight coupled to existing APIs and the developers had to learn the full blown APIs. 2.5 Please give a short description of the underlying technology or technologies:The idea is to provide a common framework for client side applications. Especially the communication,configuration,lifecycle-management between the applications will be managed by the framework. My testapplication runs on J2SE 1.4.X without any additional API's or libraries. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.client, javax.csc, 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?Common frameworks like JAAS etc. coult be plugged as a "SPI" into my model. All isues can be addressed. 2.9 Are there any internationalization or localization issues?Yes. Every application is able to use the "internationalization service" which uses the i18n components for now. Every I18N-API could be plugged into "my" framework. 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 existing specs will be deprecated. 2.11 Please describe the anticipated schedule for the development of this specification.I think in a year this spec should be "ready to deploy". 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.EMail: abien@adam-bien.com, face-to-face meetings, tele con mtgs, chat rooms,conferences (JavaONE). 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.Existing Framework with (was implementing by me)
- API I will publish or submit this documents after this JSR was approved. My book (Enterprise Java Frameworks, Adam Bien, Addison Wesley ...it was only published in german language) describes a similar (serverside) architecture. 3.2 Explanation of how these items might be used as a starting point for the work.We could use the RI and already existing API as a starting point of our work. The already existing source code, UML-diagrams are only an initial point. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.www.adam-bien.com (my homepage). In the last Swing-Project (I think the biggest in Germany or Europe - about 500 panels) we had big problems with "memory leaks", logging, configuration etc. The idea for this api was born. I think with this JSR our project could be earlier in production and the migration from JDK 1.1 to JDK 1.2 and JDK 1.3 could be simplified. Further not so skilled developers would gain a general architecture for developing clienside java applications. This specification is really lightweight, so it is possible to run it on mobile (or micro) clients. |
