The increasing popularity of XML and SOAP opens the way for business-to-business communication applications to interoperate. XML and SOAP provide a foundation, but they are not enough—standardization in the XML formats, in the communication process, and in the availability of information about a business are all key elements of a real-world solution.
Among the standards proposed to overcome this situation, the most notable are Universal Description, Discovery, and Integration (UDDI, www.uddi.org) and Electronic Business using eXtensible Markup Language (ebXML, www.ebxml.org). These two solutions partially overlap and partially diverge and are now being further worked on by the OASIS consortium (Organization for the Advancement of Structured Information Standards, www.oasis-open.org). I won't get into the problems with business processes; instead I'll only discuss some of the technical elements of UDDI, because it is specifically supported by Delphi 7.
The Universal Description, Discovery, and Integration (UDDI) specification is an effort to create a catalog of web services offered by companies throughout the world. The goal of this initiative is to build an open, global, platform-independent framework to let business entities find each other, define how they interact with the Internet network, and share a global business registry. Of course, the idea is to speed up the adoption of e-commerce, in the form of B2B applications.
UDDI is basically a global business registry. Companies can register themselves on the system, describing their organization and the web services they offer (in UDDI the term web services is used in a very wide sense, including e-mail addresses and websites). The information in the UDDI registry for each company is divided into three areas:
White Pages Include contact information, addresses, and the like.
Yellow Pages Register the company in one or more taxonomies, including industrial categories, products sold by the company, geographical information, and other (possibly customizable) taxonomies.
Green Pages List the web services offered by the company. Each service is listed under a service type (called a tModel), which can be predefined or a type specifically described by the company (for example, in terms of WSDL).
Technically, the UDDI registry should be perceived like today's DNS, and should have a similar distributed nature: multiple servers, mirrored and caching data. Clients can cache data following given rules.
UDDI defines specific data models for a business entity, a business service, and a binding template. The BusinessEntity type includes core information about the business, such as its name, the category it belongs to, and contact information. It supports the taxonomies of the yellow pages, with industry information, product types, and geographic details.
The BusinessService type includes descriptions of web services (used for the green pages). The main type is only a container for the related services. The services can be bound to a taxonomy (geographical area, product, and so on). Every BusinessService structure includes one or more BindingTemplates (the reference to the service).
The BindingTemplate has a tModel. The tModel includes information about formats, protocols, and security, and references to technical specifications (possibly using the WSDL format). If multiple companies share a tModel, a program can interact with all of them with the same code. A given business program, for example, can offer a tModel for other software programs to interact with it, regardless of the company that has adopted the software.
The UDDI API is based on SOAP. Using SOAP, you can both register data and query a registry. Microsoft also offers a COM-based SDK, and IBM has a Java Open Source toolkit for UDDI. UDDI APIs include inquiry (find_xx and get_xx) and publishing (save_xx and delete_xx) on each of the four core data structures (businessEntity, businessService, bindingTemplate, and tModel).
Delphi 7 includes a UDDI browser you can use to find a web service while importing a WSDL file. The UDDI browser, shown in Figure 23.8, is activated by the WSDL Import Wizard. This browser uses only UDDI version 1 servers (a newer interface is available, but it isn't supported) and has a few predefined UDDI registries. You can add predefined settings in the UDDIBrow.ini file in the Delphi bin folder.
This is a handy way to access web services information, but it is not all that Delphi provides. Although the UDDI Browser is not available as a stand-alone application, the UDDI interface units are available (and they are not trivial to import). So, you can write your own UDDI browser.
I'll sketch a simple solution, which is a starting point for a full-blown UDDI browser. The UddiInquiry example, shown in action in Figure 23.9, has a number of features, but not all of them work smoothly (particularly the category search features). The reason lies in the fact that using UDDI implies navigating complex data structures, which are not always mapped in the most obvious way by the WSDL importer. This makes the example code fairly involved; so, I'll show you only the code for a plain search, and not even all of it (another reason is that some readers may not be particularly interested in UDDI).
As the program starts, it binds the HTTPRIO component it hosts with the InquireSoap UDDI interface, defined in the inquire_v1 unit provided with Delphi 7:
procedure TForm1.FormCreate(Sender: TObject); begin httprio1.Url := comboRegistry.Text; inftInquire := httprio1 as InquireSoap; end;
Clicking the Search button makes the program call the find_business UDDI API. Because most UDDI functions require many parameters, it has been imported using a single record-based parameter of type FindBusiness; it returns a businessList2 object:
procedure TForm1.btnSearchClick(Sender: TObject); var findBusinessData: Findbusiness; businessListData: businessList2; begin httprio1.Url := comboRegistry.Text; findBusinessData := FindBusiness.Create; findBusinessData.name := edSearch.Text; findBusinessData.generic := '1.0'; findBusinessData.maxRows := 20; businessListData := inftInquire.find_business(findBusinessData); BusinessListToListView (businessListData); findBusinessData.Free; end;
The businessList2 object is a list that is processed by the businessListToListView method of the program's main form, showing the most relevant details in a list view component:
procedure TForm1.businessListToListView(businessList: businessList2); var i: Integer; begin ListView1.Clear; for i := 0 to businessList.businessInfos.Len do begin with ListView1.Items.Add do begin Caption := businessList.businessInfos [i].name; SubItems.Add (businessList.businessInfos [i].description); SubItems.Add (businessList.businessInfos [i].businessKey); end; end; end;
By double-clicking on a list view item you can further explore its details, although the program shows the resulting XML information in a plain textual format (or a TWebBrowser-based XML view) and doesn't further process it. As mentioned, I don't want to get into technical details; if you're interested, you can find them by looking at the source code.