Nakina Systems has submitted Java Specification Request (JSR) 254, OSS Discovery API, to the Java Community Process (JCP). According to the JSR,
The Discovery APIs are suitable for use by applications that perform discovery of physical network devices and their data. The APIs provide an access point for configuration and management of discovery applications providing the means for the production of discovery files and discovery events related to the discovery job lifecycle.
Some examples of areas of concern for the Discovery APIs are discovery seed data, discovery agents, concurrency control, discovered data events, device connection management and policy, and device security credentials. The artefacts produced by these areas of concern are expected to manifest themselves in the form of an OSS Discovery object model that will extend the OSS/J CBE wherever possible (see JSR 144). The object model will also include OSS Discovery events. The existing CBE packages already provide many of the required methods for manipulating objects that extend the CBE.
Siemens AG has posted the public review draft of JSR 229, Payment API (PAPI). According to the draft,
The scope of this JSR is to define the following:
- A generic optional API to initiate payment transactions and,
- The syntax for the description of the associated provisioning data, enabling API implementers to support different payment instruments (or adapters).
Both will allow 3rd party developers to build applications with control of features and services that are chargeable. The JSR API may include methods for:
- Requesting a payment transaction,
- Requesting feature and service price management
- Payment service availability
The definition for provisioning data makes sure that service providers and payment service providers can select a suitable set of payment adapters provisioned for applications during the application deployment time. Primarily payment adapters addressed will be:
- Operator charging
- 3rd party payment service providers
This JSR enables application developers to initiate mobile payment transactions from J2ME applications. It is an optional package for the J2ME CLDC configuration and targeted for MIDP and IMP devices. Scope of this JSR is to provide a generic payment initiation mechanism, which hides the actual payment architecture and complexity from the developers. This JSR does not define and imply any concrete payment implementation and mechanism but is generic enough to support different implementations. It is up to the implementing party to realize the API based on one or more technical solutions enabling the application initiated payment. The JSR also does not define any user behaviour or user interface but leaves them to be defined by the actual implementation of the API.
Comments are due by November 15.
Mort Bay Consulting has released Jetty 5.0, an open source servlet engine that supports version 2.4 of the java Servlet specification. "Jetty is a 100% Java HTTP Server and Servlet Container. This means that you do not need to configure and run a separate web server (like Apache) in order to use java, servlets and JSPs to generate dynamic content. Jetty is a fully featured web server for static and dynamic content. Unlike separate server/container solutions, this means that your web server and web application run in the same process, without interconnection overheads and complications. Furthermore, as a pure java component, Jetty can be simply included in your application for demonstration, distribution or deployment." Jetty is published under the Apache 2.0 license.
The Jakarta Apache Project has posted Tomcat 4.1.31, an open source servlet container for the Apache web server and the official reference implementation of the Java Servlet API and Java Server Pages (JSP). This implements version 2.3 of the Java Servlet API and version 1.2 of Java Server Pages. 4.1.31 upgrades several supporting APIs inlcuding JavaMail to 1.3.1, JAF to 1.0.2, and JTA to 1.0.1b. It also adds support "for optionally passing the shell environment variables to the CGI script." Various bugs are fixed as well. Personally I prefer Tomcat 5. It's a quite a bit easier to set up and manage than Tomcat 4 was, but if you're still on Tomcat 4 you should probably upgrade.