What’s the current version of the UDDI Business Registry? What are the shortcomings/outlook of next version?
von Riegen: The UDDI Business Registry, now jointly operated by IBM, Microsoft, NTT and SAP, is based on UDDI Version 2 and is in production since July 2002. While there are different implementations of the specification, they remarkably all completed to work through an extensive test suite. That is, users of the UDDI Business Registry find the very same programmatic behavior at all nodes of the registry and are assured that data is seamlessly replicated to all other nodes.
As far as UDDI Version 3 is concerned, the most compelling new features include enhanced registrations across multiple registries, and the ability to digitally sign published entities in order to guarantee data authenticity, a feature that was often requested by users. The UDDI Business Registry operators currently schedule the implementation of Version 3 and will provide first implementations later this year.
Could you elaborate on the strategy behind forming the UDDI Specification Technical Committee within OASIS to advance the spec?
Clement: Providing a forum in which UDDI can continue to flourish is extremely important to the UDDI Specification Technical Committee. UDDI also complements OASIS other Web services efforts.
Who will assume responsibility for the UDDI project and continued technical work on the spec? Will OASIS continue to gear UDDI for internal deployments behind the firewall, rather than as public registries that would act as a sort of Yellow Pages for Web services?
Clement: Technical activities are being led by the UDDI Specification Technical Committee (http://oasis-open.org/committees/uddi-spec/). The original members of UDDI Working Group remain active in this effort. UDDI is designed for applications both inside and outside organizations and UDDI version 2 offerings support both today.
Bellwood: The OASIS UDDI Specification Technical Committee is responsible for continued technical work on the specification. The UDDI specification does not focus on any one particular installation environment. Version 3 of the specification added significant features, which greatly increase the utility of UDDI installed in both public and private environments. With the addition of XML digital signatures, one can now establish the veracity of data in the registry. In version 3, the entity keying and subscription features also promote ease of data sharing between UDDI registries, both public and private. It is also the intention of the TC to continue to work on insuring compatibility with other specifications.
In opening up registries more widely to publishers, subscribers and peers, the question of authorizing access to records becomes an important issue. How does the UDDI spec address this?
Bellwood: Authorization and authentication models for publishers has so far been considered outside of the scope of the UDDI specification, particularly since there are numerous such schemes, and implementations are thus free to employ their preferred solution. While version 3 of the UDDI specification did add the ability for implementations to require authentication even for inquiry functions, if desired, UDDI remains neutral with respect to the mechanisms used to perform this function.
How do SAP and the founding members of UDDI hope to extend the reach of the technology by teaming up with OASIS?
von Riegen: OASIS is the ideal platform to get international and cross-industry participation in order to extend the UDDI specification with best practices for different communities. The close coordination with relevant groups from W3C and WS-I enables UDDI to be tightly integrated in the overall Web services infrastructure.
In addition to accelerating the adoption of UDDI, what does the standards body hope to achieve by serving as the steward for the UDDI project?
Clement: Having expanded the participation in UDDI beyond the founders, also the UDDI Specification TC and the OASIS Member Section look to increase the reach and adoption of UDDI through the publishing of Best Practices (http://www.oasis-open.org/committees/uddi-spec/bps.shtml) ) and TechnicalNotes (http://www.oasis-open.org/committees/uddi-spec/tns.shtml, ), andalso through partnership with key Web services components such asWS-Security.
Bellwood: Moving UDDI into OASIS also increases its credibility and stability.
Wider participation by the industry is certainly a healthy thing. Being in
OASIS also makes it somewhat easier to keep UDDI current with the latest
What are your thoughts on when UDDI will make an impact with customers?
Bellwood: UDDI is already having an impact. In only a couple of short years, it has become an important infrastructure component in Web services architectures and in the tooling provided by major vendors. UDDI is just one piece of the puzzle though. Many others are also being put into place to support the growth of Web services, such as WS-Security, etc. As these continue to mature, adoption will become more pervasive and mainstream. I’d look for this to occur over the next one to two years
von Riegen: Some customers already use internal UDDI registries to organize the Web services that are deployed in their heterogeneous system landscape. Others are prototyping UDDI in a semi-private environment, for example, for company-internal purposes or for a private community of business partners. The flexibility of UDDI allows its customization to a community’s needs so that it can provide real value by effectively reducing the integration costs. Personally, I expect that the next year will show us some best practices and give us more experience from actual implementations in different industries. Customers should not wait until their competitors gained practical experience.
SAP’s view on UDDI’s future
What is the strategy of SAP concerning UDDI?
von Riegen: Since UDDI represents a cornerstone of the overall Web services architecture, it is quite natural that UDDI is natively supported by SAP NetWeaver. This will help SAP customers to seamlessly connect to any UDDI registry in order to publish Web services that are developed with SAP Web Application Server and to integrate externally discovered Web services. The SAP Web Application Server can also be used to deploy a full-blown UDDI registry.
What’s the role of UDDI with respect to mySAP Business Suite and, particularly, Web services delivered by SAP?
von Riegen: SAP has an extensive experience in developing collaborative business scenarios and application interfaces that technically enable these scenarios. It was quite natural to make these interfaces available as Web services, based on known Internet standards such as SOAP and HTTP. The integration of SAP solutions such as mySAP CRM and mySAP SRM with UDDI registries will enable SAP customers to more seamlessly deploy their collaborative business scenarios, based on the registration and subsequent discovery of Web services delivered by SAP.
How do the more than 200 members of the former UDDI.org project intend to help standardize UDDI capabilities in the growing number of software tools and applications?
von Riegen: Many tools and applications available today already contain some kind of registry. Some need a trading partner directory, some need more details about their “e-capabilities”. UDDI’s approach to combine information about Web services and their characteristics with information about their providers, all accessible through open Internet standards, is already adopted by many software vendors and is going to be the industry’s common mechanism for Web service registrations. It is not the question if UDDI will succeed, but how to adopt it in different industries.
By embracing UDDI, how will SAP guarantee the transition from integration technologies to the joint business-to-business processes that run on them?
von Riegen: The two main requirements for the development of SAP NetWeaver were the provision of a native Web service infrastructure and the protection of our customers’ investments in existing SAP integration technologies. By making SAP standard interfaces such as EJBs, BAPIs and IDocs available as Web services, even our installed base can start Web service projects today.
Since company’s business relationships are highly customized, and as a result, the integration infrastructure significantly decentralized, how do you expect to gain the cooperation of all parties involved?
von Riegen: This is an excellent question that directly leads us to UDDI’s role in heterogeneous landscapes of business partners and their systems. In my opinion, two things are important for UDDI’s success.
First, the market of tools and technology for system integration must agree on UDDI for the exchange of metadata about Web services and their providers. This does not mean that every tool has to be a full-fledged UDDI registry, supporting every single API. Existing tools can be UDDI-enabled by adding another layer above their existing APIs.
Second, since the interfaces that are deployed in today’s company system landscapes aren’t only Web services, UDDI must be able to describe other services, also. Fortunately, UDDI’s data structures and extensibility meet these requirements. For example, you can describe and publish CORBA-based remote objects or EDI-based transaction sets, if necessary.