Siemens AG has submitted JSR 266, Unified Message Box Access API (UMBA-API), to the Java Community Process. According to the JSR,
Mobile devices collect input and output messages into so called "input- and output-boxes". The realization of these "boxes" is indeed implementation dependent, but they are found in all mobile devices. The word message here stands for short messages (SMS), multimedia messages (MMS), email, ring tones, bitmaps, Vcards, etc. These messages enter and leave the "boxes" via voice and data connections (GSM, GPSR, WLAN, BT, etc ).
Although some J2ME optional packages define APIs to send and transmit certain types of messages (SMS in JSR120) and (MMS via JSR205), there is no way to access and manage the message boxes, and their content from a Java application.
The JSR API will include methods for:
- Management of message boxes. (query of info, rename, copy, delete?)
- Read, write, copy, move and delete contents.
- Access the attributes of a message. (read/unread status, sender/recipient address)
- Registering listeners to be notified about modifications to the
- message box. (message sent, message received, message attribute changed)
It is expected, that not all implementations will provide full access, to actively manipulate the message box contents via this API. Some applications will benefit only from a passive, read only access to the message box.
This API will be agnostic to the type of message box and the content of the message box; it will allow to access every kind of entry that is available in the device's message boxes. These are typically short messages (SMS), multimedia messages (MMS), email, ring tones, calendar entries, address book entries, bitmaps and also future message contents and formats.
This API focuses on the message box access only; transmission, content interpretation and processing are not in the scope of this JSR.
SAP AG has submitted JSR 265, API for Utilizing Web Services Policy, to the Java Community Process. According to the JSR,
This specification aims to standardize a basic framework in Java for utilizing the Web services constraints and capabilities. It enables other Java technologies for Web services to utilize policies in a uniform manner thereby strengthening Java as a competitive Web services platform.
Business Case for the proposed JSR
Today, users of Java platform are faced with the challenge of supporting Web Services that have specific behavior, constraints and capabilities (hereafter referred to as policies for brevity) whose description goes beyond the core WSDL functionality. In addition to the use of WSDL for the description of the abstract and technical interfaces of a Service, it is often times the case that additional policy metadata is associated with the several WSDL components, for example, particular QoS requirements of a Web Service. Client systems consuming such Web Services need to obtain the policies in effect for the service. In some cases, it may be useful for a service to be able to obtain its own policy set for a given interaction. Once obtained, the effective policy set is typically presented for ensuring compliant behavior of the interactions. Java specifications that target Web Service development, such as JAXRPC and JBI, currently do not address the needs of obtaining and presenting the Web Service policies, either at configuration or at runtime. This JSR aims to standardize certain basic support in the Java platform to satisfy the client and service provider system requirements for obtaining and presenting the Web Services policies.