There used to be public registries at SAP, Microsoft, and IBM. Early in the first decade of this millennium, these companies and others had a vision for something called UBR, or Universal Business Registry. The idea was not dissimilar to the original intent of EJBs. Remember how the vision for EJBs was that developers would make components, then make them publicly available “off the shelf” for others to purchase and consume.
We were meant to make a Cart EJB and sell it, allowing frontend developers to easily use our component that “just works” in their Java application. The vision for the UBR was much like this. SAP, Microsoft, and IBM all offered public registries where devel-opers could create a service, upload it with the WSDL and some documentation, and then frontend developers or integrators would be able to browse and shop these reg-istries for the services they wanted. You could pick up a Cart web service from one developer, a Tax Calculator web service from someone else, and a Shipping Calculator service from another party. Then you’d just generate the client-side code to invoke the services, and, presto, you’re in the e-commerce business.
Somehow it didn’t quite work out that way. Microsoft and IBM have removed their public UDDI (Universal Description, Discovery, and Integration) registries altogether.
SAP’s registry, shown in Figure 4-4, remains, limping along on an apparently neglected server, a vestigial reminder of the glorious business vision of a honey-bee-like dedication to global commerce that never was to be.
What happened to these registries? In short, there was no one watching the hen house.
Well-intentioned developers uploaded their newly minted web services to these public registries, mostly in order to test their use of JAX-R, (the Java API for XML Registries).
This API lets you publish a web service, or browse web services available in a UDDI or ebXML registry. The registries became cluttered with hundreds of services called
“test2” by [email protected]. Not surprisingly, interest waned. It also became appa-rent that certain proclivities within the UDDI spec made it difficult for businesses to justify much automation of the “service discovery” process. While services are still selected at runtime, this is typically based on a set from private registries that have already been vetted. So these public registries ended up suffering a fate similar to the one-time dream of an off-the-shelf EJB-mart.
Eventually, businesses got more sophisticated about setting up their own registries for internal use, and publishing their own services within the firewall for their own teams or selected business partners to browse and consume. This is largely how registries are used today within an SOA.
However, companies like Amazon, Google, and eBay are providing a robust set of services as part of their platform, including functionality that is not only core to their business, but that represents an exposure of their business platforms. Perhaps this model is something we’ll see more of in the future.
Figure 4-4. SAP Public UDDI 3 Registry
As discussed earlier, publicly available web services that are free to use can be really good for developers who are just getting started with web services. Also, keep in mind that in some cases you actually can purchase the services for real business use, such as with the services from StrikeIron, Amazon, Google, and eBay. Not only that but, these companies are pioneers in the web services space. These two factors can add up to some fairly complex and lengthy WSDLs. If you’re still at the Hello World stage, using these services with their wide variety of options and authentication schemes can be over-whelming. Starting with something from XMethods may be a little easier, but many of those services have been developed by well-intentioned people who may be using older
versions of their services platform, and you may run into services that don’t truly meet your spec or that are just not interoperable. So, if you find yourself banging your head against the wall for a really long time, it may not be you.
4.2 Installing Metro
Problem
You want to use the latest Java APIs available to make it easier to develop interoperable web services.
Solution
Install Metro. Metro is hosted at https://metro.dev.java.net as a free and open source project.
Discussion
Metro 1.0.1 is included with Glassfish 9.1 update 1. The JAX-WS Reference Imple-mentation, available within Java SE 6 and Glassfish, provides a rich set of APIs for producing and consuming web services, including WS-Addressing and MTOM capa-bilities. Metro extends the capabilities of this basic platform but without vendor lock-in.
WSIT, or Web Services Interoperability Technology, is what ensures that JAX-WS applications interoperate with web services and clients from other platforms that conform to the Basic Profile 1.1. WSIT is bundled with JAX-WS 2.1, as included in Glassfish. The WSIT technology is not based on any JSR, and as such is not available as a plug-in for other application servers. Other vendors, such as Oracle WebLogic 10.3, offer roughly equivalent technology, however. In fact, Oracle’s WebLogic implementation uses considerable code from the Glassfish and Metro open source projects.
Think of Metro as two basic layers. The core layer gives you the JAX-WS RI, and im-plementations of key web services specifications to promote interoperability: WS-I Ba-sic Profile, WS-I Attachments Profile, and WS-Addressing. WS-IT, or Web Services Interoperability Technology, provides interoperability with the .NET 3.0 and 3.5 web services platform on Windows. If you download only Glassfish and not the separate Metro 1.1, you get these features.