Overview
The Universal Discovery Description and Integration (UDDI) specifications define a way to publish and discover information about Web Services. The term “web service” describes specific business functionality exposed by a company, usually through an Internet connection, for the purpose of providing a way for another company or software program to use the service.
Web Services are becoming the programmatic backbone for electronic commerce. For example, one company calls another’s service to send a purchase order directly via an Internet connection. Another example is a service that calculates the cost of shipping a package of a certain size or weight, so many miles via a specific carrier.
At first glance, it would seem simple to manage the process of Web Service discovery. After all, if a known business partner has a known electronic commerce gateway, what’s left to discover? The tacit assumption, however, is that all of the information is already known. When you want to find out which business partners have which services, the ability to discover the answers can quickly become difficult. One option is to call each partner on the phone, and then try to find the right person to talk with. For a business that is exposing Web Services, having to staff enough highly technical people to satisfy random discovery demand is difficult to justify.
Another way to solve this problem is through an approach that uses a Web Services description file on each company’s web site. After all, web crawlers work by accessing a registered URL and are able to discover and index text found on nests of web pages. The “robots.txt” approach, however, is dependent on the ability for a crawler to locate each web site and the location of the service description file on that website. This distributed approach is potentially scalable but lacks a mechanism to insure consistency in service description formats and for the easy tracking of changes as they occur.
UDDI takes an approach that relies upon a distributed registry of businesses and their service descriptions implemented in a common XML format.
UDDI Business Registrations and the UDDI Business Registry
The core component of the UDDI project is the UDDI business registration, an XML file used to describe a business entity and its Web Services. Conceptually, the information provided in a UDDI business registration consists of three components: “white pages” including address, contact, and known identifiers; “yellow pages” including industrial categorizations based on standard taxonomies; and “green pages”, the technical information about services that are exposed by the business. Green pages include references to specifications for Web Services, as well as support for pointers to various file and URL based discovery mechanisms if required.
Using UDDI
UDDI includes the shared operation of a business registry on the Web. For the most part, programs and programmers use the UDDI Business Registry to locate information about services and, in the case of programmers, to prepare systems that are compatible with advertised Web Services or to describe their own Web Services for others to call. The UDDI Business Registry can be used at a business level to check whether a given partner has particular Web Service interfaces, to find companies in a given industry with a given type of service, and to locate information about how a partner or intended partner has exposed a Web Service in order to learn the technical details required to interact with that service.
After reading this paper, the reader will have a clearer understanding of the capabilities defined in the UDDI specifications and have a clearer understanding of the role of Web Service registries that implement these specifications.
Background
The number of ways that companies are using the World Wide Web varies considerably. Many companies are starting to define ways to allow their internal applications to interact with the business systems at other companies using the emerging Web infrastructure. Left alone, each company invents a unique approach based on the experiences of designers, available technologies, and project budgets. The proliferation of integration approaches and unique solutions have spawned an entire sub-industry focused on bridging incompatible service layers within and across company boundaries.
Recent work within the W3C starts to raise hopes that Extensible Markup Language (XML) will play a role in simplifying the exchange of business data between companies. Further, collaboration between computer industry giants and small companies alike have outlined a framework called SOAP that allows one program to invoke service interfaces across the Internet, without the need to share a common programming language or distributed object infrastructure. All of this is good news for companies feeling the cost pressures associated with electronic commerce because the foundations for common interoperability standards are being laid. Because of these foundation technologies and emerging standards, some of the intractable problems of the past are becoming easier to approach.
From XML and SOAP, one can observe that the integration and interoperability problem has been simplified in layers. XML provides a cross-platform approach to data encoding and formatting. SOAP, which is built on XML, defines a simple way to package information for exchange across system boundaries. SOAP bindings for HTTP are built on this packaging protocol and define a way to make remote procedure calls between systems in a manner that is independent of the programming language or operating system choices made by individual companies. Prior approaches involved complex distributed object standards or technology bridging software. Neither of these approaches has proven to be cost effective in the long run. Using XML and SOAP, this cross-language, cross-platform approach simplifies the problem of making systems at two companies compatible with each other.
Even when one considers XML and SOAP, though, there are still vast gaps through which any two companies can fall in implementing a communications infrastructure. As any industry pundit will tell you: “What is required is a full end-to-end solution, based on standards that are universally supported on every computing platform.” Clearly, there is more work to do to achieve this goal. The UDDI specifications borrow the lesson learned from XML and SOAP to define a next-layer-up that lets two companies share a way to query each other’s capabilities and to describe their own capabilities.
The Universal Discovery Description and Integration (UDDI) specifications define a way to publish and discover information about Web Services. The term “web service” describes specific business functionality exposed by a company, usually through an Internet connection, for the purpose of providing a way for another company or software program to use the service.
Web Services are becoming the programmatic backbone for electronic commerce. For example, one company calls another’s service to send a purchase order directly via an Internet connection. Another example is a service that calculates the cost of shipping a package of a certain size or weight, so many miles via a specific carrier.
At first glance, it would seem simple to manage the process of Web Service discovery. After all, if a known business partner has a known electronic commerce gateway, what’s left to discover? The tacit assumption, however, is that all of the information is already known. When you want to find out which business partners have which services, the ability to discover the answers can quickly become difficult. One option is to call each partner on the phone, and then try to find the right person to talk with. For a business that is exposing Web Services, having to staff enough highly technical people to satisfy random discovery demand is difficult to justify.
Another way to solve this problem is through an approach that uses a Web Services description file on each company’s web site. After all, web crawlers work by accessing a registered URL and are able to discover and index text found on nests of web pages. The “robots.txt” approach, however, is dependent on the ability for a crawler to locate each web site and the location of the service description file on that website. This distributed approach is potentially scalable but lacks a mechanism to insure consistency in service description formats and for the easy tracking of changes as they occur.
UDDI takes an approach that relies upon a distributed registry of businesses and their service descriptions implemented in a common XML format.
UDDI Business Registrations and the UDDI Business Registry
The core component of the UDDI project is the UDDI business registration, an XML file used to describe a business entity and its Web Services. Conceptually, the information provided in a UDDI business registration consists of three components: “white pages” including address, contact, and known identifiers; “yellow pages” including industrial categorizations based on standard taxonomies; and “green pages”, the technical information about services that are exposed by the business. Green pages include references to specifications for Web Services, as well as support for pointers to various file and URL based discovery mechanisms if required.
Using UDDI
UDDI includes the shared operation of a business registry on the Web. For the most part, programs and programmers use the UDDI Business Registry to locate information about services and, in the case of programmers, to prepare systems that are compatible with advertised Web Services or to describe their own Web Services for others to call. The UDDI Business Registry can be used at a business level to check whether a given partner has particular Web Service interfaces, to find companies in a given industry with a given type of service, and to locate information about how a partner or intended partner has exposed a Web Service in order to learn the technical details required to interact with that service.
After reading this paper, the reader will have a clearer understanding of the capabilities defined in the UDDI specifications and have a clearer understanding of the role of Web Service registries that implement these specifications.
Background
The number of ways that companies are using the World Wide Web varies considerably. Many companies are starting to define ways to allow their internal applications to interact with the business systems at other companies using the emerging Web infrastructure. Left alone, each company invents a unique approach based on the experiences of designers, available technologies, and project budgets. The proliferation of integration approaches and unique solutions have spawned an entire sub-industry focused on bridging incompatible service layers within and across company boundaries.
Recent work within the W3C starts to raise hopes that Extensible Markup Language (XML) will play a role in simplifying the exchange of business data between companies. Further, collaboration between computer industry giants and small companies alike have outlined a framework called SOAP that allows one program to invoke service interfaces across the Internet, without the need to share a common programming language or distributed object infrastructure. All of this is good news for companies feeling the cost pressures associated with electronic commerce because the foundations for common interoperability standards are being laid. Because of these foundation technologies and emerging standards, some of the intractable problems of the past are becoming easier to approach.
From XML and SOAP, one can observe that the integration and interoperability problem has been simplified in layers. XML provides a cross-platform approach to data encoding and formatting. SOAP, which is built on XML, defines a simple way to package information for exchange across system boundaries. SOAP bindings for HTTP are built on this packaging protocol and define a way to make remote procedure calls between systems in a manner that is independent of the programming language or operating system choices made by individual companies. Prior approaches involved complex distributed object standards or technology bridging software. Neither of these approaches has proven to be cost effective in the long run. Using XML and SOAP, this cross-language, cross-platform approach simplifies the problem of making systems at two companies compatible with each other.
Even when one considers XML and SOAP, though, there are still vast gaps through which any two companies can fall in implementing a communications infrastructure. As any industry pundit will tell you: “What is required is a full end-to-end solution, based on standards that are universally supported on every computing platform.” Clearly, there is more work to do to achieve this goal. The UDDI specifications borrow the lesson learned from XML and SOAP to define a next-layer-up that lets two companies share a way to query each other’s capabilities and to describe their own capabilities.
댓글 없음:
댓글 쓰기