A UDDI registry basically answers the following questions:
The API affords clients a number of search methods :
The UDDI API utilizes certain data "structures," although they are not programming data structures like those you would use in Java. Rather, they are units of structured XML data used in the UDDI API SOAP messages and responses. The main structures include the following (this list is not exhaustive):
Refer to the UDDI Data Structures specification for more information; it is available at http://www.uddi.org/pubs/DataStructure_v2.pdf. UDDI Usage PatternsTo understand the intended UDDI interaction paradigm, you need to look at three query patterns:
A Sample Use CaseSuppose you heard about a company called WeatherCentral that offers a weather report service, and you need to find out where that service is located and how to invoke it. You can use a combination of the Browse and Drill-down patterns by starting a white pages search for the business entity by name. Then you can find the appropriate service category, from which you can examine the service's possible bindings (HTTP-based or SMTP-based and so on) and its tModel . From there, you should have all the information you need to invoke the weather Web service. The Inquiry APIThe Inquiry API messages are for browsing or searching the UDDI registry, and because these functions are strictly read-only, no authentication is required to invoke them. Table 31.1 lists the two groups of inquiry messages: the Find group, which returns overview information, and the Obtain Details group , which returns all information about an item. These are the main Inquiry API calls; this list is not exhaustive. (The response message type is shown in parentheses.) Table 31.1. Main Inquiry API Messages
The Publish APIThe Publish API messages are for publishing your business, service, binding, or tModel to the UDDI registry. Because these functions alter the registry, authentication is required for invoking these calls. An opaque token must first be obtained from the target UDDI operator by invoking the get_authToken call, which returns an authentication token that is valid for use only with publishing to that particular UDDI operator. That is, opaque tokens are not portable. Note When you are done publishing with that UDDI operator, you should send it a discard_authToken message. Table 31.2 lists the main publish API messages (this list is not exhaustive). Table 31.2. Main Publish API Calls
What a UDDI SOAP Call Looks LikeIt's time to see exactly what SOAP messages are being sent and returned when a UDDI API call is made. Here, you will look at the find_service invocation, which searches a given businessEntity (identified by the businessKey attribute) for certain services based on matching criteria: in this case, that the service name matches Authorize Payment . Listing 31.1 shows the UDDI SOAP request. Listing 31.1 SOAP Request for the find_service UDDI Invocation<Envelope xmlns=... > <Body> <find_service businessKey="D8J4D980-78W7-33L4-98745DRF9909" generic="1.0" xmlns="urn:uddiorg:api"> <name>Authorize Payment</name> </find_service> </Body> </Envelope> Listing 31.2 shows the UDDI SOAP response. Listing 31.2 SOAP Response from the find_service UDDI Call<Envelope xmlns=...> <Body> <serviceList generic="1.0" operator="UDDIOperator" truncated="false" xmlns="urn:uddi-org:api"> <serviceInfos> <serviceInfo businessKey="D8J4D980-78W7-33L4-98745DRF9909" serviceKey="BGRG3457-7D2G-44K6-9YU5-G0L4488K893E"> <name>Authorize Payment</name> </serviceInfos> </serviceList> </Body> </Envelope> In any of the find_ xxx calls, you can also specify a service classification by using categoryBag and/or identifierBag as a search parameter. |