Nokia and Sun have submitted JSR-279: Service Connection API for Java ME to the Java Community Process (JCP). According to the JSR: >
This JSR proposes a general-purpose high-level Service Connection API for JavaTM ME for mobile devices. The API is intended to support writing mobile clients for identity-based Web services, service-oriented architectures (SOA), and other similar network service application models involving service discovery, authentication and identity. Existing Web services APIs tend to focus on support for low-level protocols, such as SOAP and Web Services Security. However, high-value Web services for mobile devices may be quite complex, requiring identity- based discovery and authentication, multiple service providers, and invocation of device-hosted services. These may require extensive protocol exchanges, complex state machines and other logic. To provide portability and interoperability such applications need to be based on frameworks that specify how multiple protocols and services can work together in a standard way. An example of such a standard framework that is currently being deployed is the Liberty Identity Based Web Services Framework (IDWSF), specified by the Liberty Alliance. Other frameworks with similar goals are also being specified and deployed, including for example the not yet standardized WS* specification suite or UPnP. The supported model is general enough that it could also be extended to non-Web services frameworks.
While it is theoretically possible to write such a framework-based application using only low-level Web services protocol APIs, the programming required would be very complex and would require implementing high-level protocols and other logic already well-specified by the framework. It makes much more sense to provide developers with a standard API to wrap framework behavior so that they can concentrate on service and application specific logic only.
The proposed JSR will specify a high-level Service Connection API for JavaTM ME that supports a simple GCF-like model for application interaction with services. The API will also cover the configuration needed to bootstrap interaction with service frameworks.
Reading between the lines, what this says is that SOAP/WSDL/etc. are still too complicated even when they hide the XML behind APIs like JAX-RPC so they need yet another layer separating the average developer from the XML. While I don't deny that SOAP, WSDL, etc. are quite complex, maybe the problem is not the APIs? Maybe the problem is that the underlying specs are too complex and too poorly designed and no API is ever going to be able to hide that fundamental complexity? Maybe the solution should be to stop building systems on top of such baroque, rigid and brittle foundations and instead build on top of simple, flexible systems like HTTP that bend instead of breaking? Just a thought. :-) Comments are due by August 1.