Service Discovery: Perspectives on the Past, Present, & Future @ JDJ

<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 160x600, 创建于 08-4-23MSDN */google_ad_slot = "4367022601";google_ad_width = 160;google_ad_height = 600;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

 

  Service Discovery and identification is a critical piece of the overall Web Services puzzle. Existing Service architectures, such as CORBA, JINI, and ebXML, have all devoted significant effort towards making Service Discovery available and comprehensive. If Web Services is to become a ubiquitous platform for Service oriented computing, then the industry will need to create standards and products that enable sophisticated Discovery, identification, and composition of Web Services.

  This month, Radovan Janecek and Peter Alesso join Web Services Journal in exploring the state of Service Discovery today. Radovan leads development at Systinet, creating industry-leading implementations of Web Services standards (UDDI, SOAP, WSDL) as part of an overall Web Services platform. Peter joins us from WebIQ and Lawrence Livermore National Laboratory. He is currently engaged in a broad range of research related to software Services, wireless computing, and artificial intelligence. (As a brief aside, I'd like to recommend Peter's book, the Intelligent Wireless Web, to all those interested in a broad and integrative view of these topics.) With both academic and commercial experts as guides, let's take a brief look at the Past, Present, and Future of Web Services and Discovery.

  To give us a baseline, could you both define Service Discovery and its major components?

  Radovan: I view Service Discovery as the ability to provide a Service identifier according to some specified metadata. What are the major components? It's hard to say since it always depends on Discovery usage. My vote is that Service Discovery is composed of a semantic processor, a registry, a query processor, and a Service locator. Additionally, I believe that Future Discovery Services will provide semantics-based Discovery.

  Peter: Currently there are several methods of discovering Web Services - from manual to automated. At the manual end of the spectrum, techniques include e-mail, Web browsing, phone calls, and word-of-mouth. Next, consider publishing Services and Service descriptions on various Web sites via formatted files, such as Microsoft's DISCO and IBM's ADS. these can be used to create standardized file formats and look up definitions.

  A more sophisticated approach to Discovery is that of Web Services brokers (SalCentral, XMethods, and Silicon Hills Group) who actively manage Services for Service providers by providing a means to publish, promote, sell, test, and support their Web Services. the final approach to Web Service Discovery is automated and dynamic Service registries, such as UDDI. Like Service brokers, the UDDI registry provides a Web page interface. But UDDI registries also provide application programming interfaces (APIs) for publishing, finding, and binding Services. This makes UDDI registries more dynamic and complex than any other type of Web Service Discovery method.

  Please describe your academic, research, and/or commercial history as it relates to Web Services.

  Radovan: I have been leading development of WASP UDDI at Systinet for two years. From the beginning we had our own vision of UDDI called the "UDDI Grid" - a federated registry of UDDI nodes with much better security support than the UDDI standard requires. As a vendor of a general Web Services infrastructure, we always paid a lot of attention to the integration of UDDI with Web Services. This led to the publishing of a technical paper on how to publish WSDL to UDDI.

  During my Ph.D. studies, I was a member of CORBA and Distributed Systems Research Group (http://nenya.ms.mff.cuni.cz), where I worked on dynamic updates of distributed components. Discovery was also an important part of that research.

  Peter: As a software researcher at www.Web-iq.com and Lawrence Livermore National Laboratory, I have been investigating Web Service applications for the next generation Web architecture - the Semantic Web. This has involved three main functions: Service Discovery, execution, and composition and interoperation. Also, wireless Semantic Web Services are of particular interest to me.

  I'd like to get your 50,000-foot overview of the state of

  Service Discovery today.

  Radovan: Today many Discovery Services are in fact only location Services. one system to study is the ebXML Registry/Repository that is a part of ebXML technology and is designed to be used for miscellaneous Discovery purposes. It has a generic data model and multiple APIs allowing both queries and storage of the data. UDDI, on the other hand, is a global lightweight registry used as Discovery Service with a strictly defined data model and API. In many cases, people are satisfied by more simple solutions based on DISCO or WS-Inspection. A critical problem of Discovery Services is how to register with them. Possibly the main reason that powerful Discovery Services are not widely used is the difficulty of the registration process.

  Peter: UDDI is not the Service registry itself. Instead, it provides a standard mechanism for publishing and discovering Services within the registry. It is not currently an official standard, but a specification involving a collaboration of over 300 companies who formed to become the UDDI project. This project is responsible for running a UDDI business registry, which for UDDI Version 1.0 actually consists of two separate registries. Each UDDI registry has a business as an operator, which is similar to the companies that operate the Service repositories for Service brokerages. Currently, the two UDDI Version 1.0 registry operators are IBM and Microsoft. the agreement is that any information entered in one registry becomes replicated in all other registries as well. Version 2.0 of UDDI has recently been released. From a technical standpoint, UDDI provides structured data and a defined way of integrating with the structured data. the UDDI project's stated intent is to have the registry support Services integrate with a wide set of existing core Internet technologies, such as Java, Jini, CORBA, ebXML, RMI, and HTML.

  In your opinion, what is the most advanced Service Discovery system in place today? Please feel free to use any example that comes to mind and don't limit your answer to

  traditional software systems.

  Radovan: Certainly Google! (Laughs) Practically speaking, more Services are discovered this way than any other method.

  Peter: UDDI 2.0. the UDDI 2.0 specifications were published on Monday June 18, 2002, at uddi.org, a major version update for the Universal Description, Discovery and Integration protocol.

  What are the strengths and weaknesses of UDDI? And, is it the right platform for a long-term Service Discovery strategy?

  Radovan: I see the main strengths of UDDI as its broad vendor support and its simplicity. the weakest point of UDDI is the lack of repository abstraction - UDDI is an index only. Another weakness of UDDI is that it has no explicit support for Web Services. Long term, I wouldn't be surprised to see UDDI merge into the ebXML registry. Overall, I have very high hopes for the Future of UDDI under OASIS stewardship.

  Peter: If you're asking if UDDI will succeed as the Web Service description and Discovery standard, I can only say that since Web Services infrastructure is in its infancy, this question is at the very heart of the success of this new technology.

  So far, business adoption of UDDI 1.0 has been tentative and has not yet fulfilled its potential. UDDI 2.0 seems about to reinforce UDDI's position as a global yellow pages, rather than upgrading its capabilities as a Web Services directory.

  However, the UDDI 2.0 registry operators will share data and synchronize their databases. This trend toward broader cooperation and building a Future infrastructure of many UDDI registries is positive.

  Why do you believe that the usage of Service Discovery, specifically with Web Services, has been anemic to date?

  Radovan: I wouldn't say anemic, but it depends on exactly what you are asking. I agree that the originally intended use of public UDDI is anemic. on the other hand, I see lots of activity with hundreds of companies using and testing UDDI in a private capacity. As for the public use of UDDI, I think the reason it is lagging is exactly the same as in the case of the CORBA Trading Service in the CORBA world: low demand.

  In both cases, there is nearly nothing to discover. If you look at the biggest public registry of Web Services, XMethods, you will find up to 300 Services. You really don't need UDDI for such an amount of mostly anonymous and unreliable Web Services. But any large company, such as a JP Morgan or General Motors, has thousands of Services internally and they are usually disorganized. there is the potential for UDDI to make a difference and solve problems.

  Peter: I'm unable to provide a clear commercial picture of the current state of usage of either Service Discovery, in general, or UDDI in particular. Both are the focus of serious growth and ongoing development, but at this early stage, difficulties in implementing and validating new Services, as well as limitations due to competitive tradeoffs, make the situation somewhat difficult. Software architects will still have to spend considerable time evaluating and validating tradeoffs before making commitments to Web Service vendors.

  What will the next generation of Discovery Services look like and what are the biggest challenges to solve to make them work?

  Radovan: the next generation will center on semantic-based Discovery as a backbone for Service management systems as well as Services runtimes. Balancing reasonable registration processes against creating powerful semantics will be difficult.

  Peter: the successful development of Web Services will greatly depend on the ability to automate as much of the Web Services process as possible under interoperable standards. Matchmaking, or Service Discovery, is one important aspect of Web Services' e-commerce interactions and advanced matchmaking Services require rich and flexible metadata that are not supported by current industry standards, such as UDDI and ebXML.

  the most advanced vision for the next generation of Web Services is the development of Web Services over Semantic Web architecture. the Semantic Web initiative at W3C is generating technologies and tools that could fulfill the requirement for advanced matchmaking Services. Support of Semantic Web- related technologies includes tools such as RDF (Resource Description Framework) and DAML-S.

  This provides support for automated Web Service composition and interoperability. Integral to this effort will be three main functions: Service Discovery, execution, and composition and interoperation. Of these three tasks, none is entirely realizable with today's Web, primarily because of the lack of a suitable markup language. Academic research on Web Service Discovery is growing out of agent matchmaking research. Recent industrial efforts have focused primarily on improving Web Service Discovery and aspects of Service execution through initiatives, such as UDDI and ebXML.

  And finally, put on your oracle hat and list three standards that you believe are the most critical to the advancement of Web Services and Discovery.

  Radovan: Well, I'd say: a) RDF or a similar semantics-supporting standard and a corresponding query language; b) REST as a means for resources location and modification; and c) security, security, and more security.

  Peter: the success of Web Services depends on the ongoing development of open standards that ensure interoperability between different implementations. the standardization efforts for the technologies that underlie Web Services include SOAP, WSDL, UDDI, ebXML, RosettaNet, BTP, and S2ML.

  Our Web Services Experts

  Internet innovator, engineer, and author, H. Peter Alesso has led successful research and development programs at Lawrence Livermore National Laboratory (LLNL) for over 20 years. At LLNL, he led a team of computational physicists and engineers in a wide range of successful multimillion-dollar software development research projects ranging from software applications for robotics to parallel processing of supercomputers and clustered networks. Peter holds an M.S. and advanced engineering degree from MIT, and has published over 30 journal and conference papers, as well as two books: e-Video: Producing Internet Video as Broadband Technologies Converge (Addison-Wesley, 2000); and the Intelligent Wireless Web (Addison-Wesley, 2001).

  Radovan Janecek is the VP of Engineering at Systinet. Prior to joining Systinet in 2000, he worked for the IBM T.J. Watson Research Institute, where his research and development focused on software-based speech processing engines, and multimodal control of software applications. He also worked for Borland/Inprise as a CORBA and Java consultant. Radovan was a Ph.D. candidate and served on the faculty of Mathematics and Physics at Charles University in Prague, where he was a member of the CORBA and Distributed Systems Research Group. He holds a master's degree in mathematics and informatics from Palacky University in Olomouc, Czech Republic.

<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 728x15, 创建于 08-4-23MSDN */google_ad_slot = "3624277373";google_ad_width = 728;google_ad_height = 15;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

<script type="text/javascript"><!--google_ad_client = "pub-2947489232296736";/* 160x600, 创建于 08-4-23MSDN */google_ad_slot = "4367022601";google_ad_width = 160;google_ad_height = 600;//--></script><script type="text/javascript"src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>