- Registry World—UDDI versus ebXML
- ebXML
- UDDI
- JAXR Design Challenge
- JAXR Architecture
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
JAXR Design Challenge
For the Java developer looking to deliver Web Services, the world of registries is a critical yet moving target. UDDI and ebXML registries are important here and now, yet future registries loom on the horizon as Web Services matures and evolves. For the designers of JAXR, the challenge was to deliver an API that was both extensible and flexible, but also included support for the two dominant registry specifications: UDDI and ebXML. This tension between current practice and future developments may be seen in the somewhat incompatible goals of JAXR:
Define a general-purpose Java API for accessing business registries.
Support a union of the best features of dominant registry specifications rather than an intersection of features. The objective here was not to produce a least-common-denominator.
Ensure support for the dominant registry specifications, namely UDDI and ebXML, while maintaining flexibility to support other registries not yet defined.
To accomplish these objectives, the designers of the JAXR API came up with an interesting twist on the usual design strategy of moving common functionality to abstract superclasses and/or interfaces. Instead of defining subclasses that map to specific implementations, the JAXR defines capability profiles to which registries can declare conformance. In JAXR, capability profiles apply to individual methods in the classes and interfaces that make up the API, not to the classes and interfaces themselves.
Currently, there are two capability profiles set up in the JAXR: level 0 and level 1. Connection to either UDDI or ebXML occurs through these capability levels. A JAXR provider that supports the UDDI registry specification must be level 0-compliant, whereas an ebXML registry must be level 1-compliant. These capability levels make it easier to add and remove functionality without changing class structures because the capability profiles are based on industry agreement, not tied to checks make by the Java compiler or runtime. JAXR providers publish the capability level of their implementation, and must agree not to offer any capabilities that exceed their capability level so that portability can be ensured.