1. Trang chủ
  2. » Công Nghệ Thông Tin

Xml programming bible phần 8 ppt

99 273 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 99
Dung lượng 1,98 MB

Nội dung

653 Chapter 25 ✦ WSDL Figure 25-2: An example of a WSDL editor Because WSDL is good old XML (can “old” be associated with XML yet?), you can also create your own WSDL editor. It could be fun. Summary In this chapter, we have dissected a WSDL file. We saw how the file is structured and what information is included therein. We discovered what the elements of WSDL mean and how they are used by the calling application to determine a Web service’s behaviors and characteristics. WSDL is arguably the de facto standard on the Internet for making known to consuming client applications what a Web service does. We also learned about how to dynamically create a Web service proxy class at runtime based on WSDL that is not known at design time. Finally, we learned that there are some WSDL editors out there and that one can be created from scratch if desired. ✦✦✦ k538292 ch25.qxd 8/18/03 8:45 AM Page 653 k538292 ch25.qxd 8/18/03 8:45 AM Page 654 UDDI W eb services can be used for interaction between remote systems within a single organization. However, one of the most promising aspects of Web services is that they can be used business-to-business integration. For example, one company might expose an invoicing Web service that the company’s suppliers use to send their own internal invoices. Similarly, a company might expose a Web service for placing orders electronically, using special schemas that the customers can use internally for their own purchasing pro- cess. Now, if one company wanted to purchase goods from a vendor using a service of this kind, how would it find it? Let’s say the company wants to begin ordering office supplies from a John’s International Office Supplies (an idea waiting to hap- pen) it would need to search for all vendors who sell office supplies over the Internet and then find ones that sell goods using a Web service. To do this, the customer needs a directory, a sort of yellow pages-type directory of all businesses that expose Web ser- vices. This directory is called Universal Description, Discovery, and Integration or UDDI. UDDI is an industry effort started in September of 2000 by Ariba, IBM, Microsoft, and 33 other com- panies. Today, UDDI has over 200 community members. This chapter describes UDDI, the final piece of the Web Service puzzle, in greater detail. It explains how UDDI links together consumers of Web services with providers and how it works. We also learn who is backing the UDDI effort and what UDDI means to the future of Web services. We learn how UDDI works and what it means with respect to the technology of Web services. UDDI Structure UDDI is a platform-independent framework for describing ser- vices, businesses, and integrating business services. While the UDDI project is not part of a regular standards body like the W3C or the IETF, the structure of UDDI is based on Web 26 26 CHAPTER ✦✦✦✦ In This Chapter UDDI architecture UDDI today Information model Businesses Services Bindings Tmodels ✦✦✦✦ k538292 ch26.qxd 8/18/03 8:45 AM Page 655 656 Part V ✦ Introducing Web Services service standards, which means that UDDI registries are theoretically accessible through the same means as all other Web services. In short, UDDI is a directory for Web services, and it is a Web service. Currently IBM, Microsoft, SAP, and NTT Telecom host public versions of the UDDI directory, which are kept in sync via a form of replication. URLs for registry sites as well as the latest version of the UDDI specification can be found at http://uddi.org/. Like a typical yellow pages directory, UDDI provides an indexed database of businesses searchable by the type of business. Finding Web services with UDDI Each of the four public UDDI Registries (IBM, Microsoft, SAP, and NTT) has its own interface and UI to access its registry via the Web. You typically search using busi- ness taxonomy such as the North American Industry Classification System (NAICS) or the Standard Industrial Classification (SIC). You could also search by business name or geographical location. Regardless of the interface provided, the UI is noto- riously hard to navigate for Web developers that are used to more user-friendly HTML search sites. However, like WSDL, the main users of the UDDI registries are intended to be Web services rather than developers. As a testament and/or a response to this, Microsoft, IBM, and a few smaller players have released UDDI SDKs, which make developing Web Service front-ends to UDDI registries more accessible to anything on the other end of the SDK, be it human or machine. Microsoft SDKs can be downloaded at http://uddi.microsoft.com/, and the IBM UDDI4J can be downloaded as part of the IBM Web Services toolkit from http://alphaworks.ibm.com/tech/webservicestoolkit. These tools, and a few others, can also be used to set up private UDDI servers for use within an organization or via VPN, for groups that want to have the full benefits of a complete set of Web Services technologies, but don’t want to share their Web Services with the world on one of the public sites. Going back to our example of office supplies, a company could search UDDI for NAICS code 422120, which corresponds to providers of office supplies and paper goods. This search would return a list of such companies that are registered with UDDI. At this stage of Web service adoption, it is not uncommon to find no Web ser- vices for categories you search in UDDI. This does not mean, however, that no Web services exist for that category of business. It only means that none is registered using UDDI. In searching, the consumer will need to know which of the office sup- plies vendors exposes Web services that are compatible with the systems used within the company. For example, if our company supports a specific purchase order process that uses SOAP-based Web services for acquiring office supplies it would need to know which vendors have a Web service that is compatible. k538292 ch26.qxd 8/18/03 8:45 AM Page 656 657 Chapter 26 ✦ UDDI This brings us to the taxonomic conventions of UDDI. There are a number of differ- ent types used in the UDDI model to identify a service or collection of services. These five types are shown in Figure 26-1. Figure 26-1: The types used in the UDDI taxonomy publisherAssertion To understand how they work together, let’s look at UDDI from the perspective of an organization that wants to publish its services in the UDDI registry. In this case, we will imagine a company that has many subdivisions within its organization. The recommended practice for a business of this type that wants to register in a UDDI registry is for each division to register as a separate businessEntity. For example Microsoft may have a separate businessEntity entry for the Windows OS, Office divisions, and gaming division. Thus, rather than provide a single businessEntity entry in the UDDI registry which attempts to describe all the services Microsoft provides, it makes more sense to have each division submit a separate businessEntity that the division can support and maintain. However, it would be advantageous if the relationship between the different services offered by Microsoft’s different businessEntity entries could be made known in UDDI. This is done through what is known as a publisherAssertion structure, which allows busi- nesses to publish relationships between businessEntities. To prevent one publisher from claiming a relationship to another that is not reciprocated, both publishers must publish identical assertions for the relationship to become known. The allowed relationships are peer-to-peer. A peer-to-peer relationship is one where the two businessEntity structures are related as peers, and a parent-child relationship is hierarchical. Next, let’s look at the businessEntity. businessEntity businessService tModel publisherAssertion bindingTemplate k538292 ch26.qxd 8/18/03 8:45 AM Page 657 658 Part V ✦ Introducing Web Services businessEntity A businessEntity is simply the provider of a service, a businessService. There is not a lot to the structure of a businessEntity. Primarily, it contains: ✦ Name of the provider ✦ Description of the businessEntity ✦ Contact information, such as name, phone, fax, e-mail, and so on ✦ Identifiers: Classifiers for the business using specifications like DUNS, NAICS, or SIC As mentioned before, a businessEntity may not necessarily be a separate business or organization. There is nothing in the specification to prevent a large business (or small one for that matter) from having divisions register services with UDDI using separate businessEntity entries. A businessEntity is described using a well-formed XML document and is created by someone who represents the provider of the ser- vice. UDDI specifies a schema for structuring the information in the businessEntity entry. In short, the businessEntity describes who is providing a businessService. businessService This data structure is used to describe each offered service in business terms. You have to specify at least a name and one binding template. A single businessService may contain more than one binding template, but it must contain at least one. Listing 26-1 shows some of the XML content of a businessService entry. Listing 26-1: A View of Some of the Elements in a businessService Entry <businessService serviceKey=” ”> <name> SymbolService </name> <description>Description of the service here</description> <bindingTemplates> <bindingTemplate> <accessPoint urlType=”http”> http://mycompany.com/myservice </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey=”12345678”/> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> k538292 ch26.qxd 8/18/03 8:45 AM Page 658 659 Chapter 26 ✦ UDDI As you can see here, the core of the businessService entry is the binding template. A binding templates structure serves as a container for one or more binding tem- plate structures. A binding template structure describes how to get access to a ser- vice. They contain what are known as access points, which are usually just URLs. Valid values for an accessPoint element are: ✦ mailto ✦ http ✦ https ✦ ftp ✦ fax ✦ phone ✦ other Another attribute called a hostingRedirector can be used if the binding template refers to another one that has already been specified. In this case, the access point need not be specified a second time. Another element called tModelInstanceDetails holds information for a particular tModel, which is referenced by its key. tModels Each business registered with UDDI lists all its services and gives each of these ser- vices a type. This service type has a unique identifier (GUID-style number) and comes from a group of well-known service types that are registered with UDDI. These service types are called tModels (technology models). Let’s recall that the two primary goals of UDDI are to: ✦ Make it possible to describe a Web service, and make that description mean- ingful for searches ✦ Provide a way to make these descriptions useful enough so consumers can interact with a service without needing to know its inner workings This being so, we need a way to tag the service so others can easily know its behav- iors, the standards with which it is compliant, and so forth. All of the other types we have seen up to this point (publisherAssertion and so on) relate to who owns, publishes, describes, and maintains the Web service. A tModel is concerned with the service itself. A tModel makes it possible to describe compliance with a specifi- cation, concept, standard, or a collectively shared design. The first goal is met by using tModel as a namespace or categorization, while the second goal is met by its usage as a tag that is technically recognizable. k538292 ch26.qxd 8/18/03 8:45 AM Page 659 660 Part V ✦ Introducing Web Services Each tModel has a name, description, and the unique identifier. This unique identifier is a UUID and is called the tModelKey. For example, the tModelKey uuid:d819efe0-4471-11d6-9b35-000c0e00acdd identifies the tModel called uddi- org:http, which has the description “An HTTP or Web browser-based Web service.” By having a pool of well-known service types, UDDI makes it possible to find out how to do electronic business with a company. This is the primary advantage UDDI has compared to other Web-based business directories. As part of the registration process, registrants can use an existing tModel or they can create their own. It might make sense for an organization or a group of organi- zations to develop their own tModels to classify a service they all offer (competi- tively even), but that would make it easier for potential consumers of the service to find the group of vendors who offer a certain type of service. For example, package delivery companies (UPS, FedEx, Airborne Express, USPS, and so on) may decide to agree upon a mutual standard tModel for package tracking. This tModel would behave in the same way for all shippers, the same method names with the same parameters. tModels store information that includes: ✦ The name of the model ✦ The publisher of the model ✦ The categories that describe the service type ✦ Pointers to related technical specifications, interface definitions, message for- mats, message protocols, security protocols, and other details that would help a potential consumer of the service be able to use it Listing 26-2 shows an example of a tModel fully exposed. Notice how it uses the reference to a WSDL document as an identifier for what the service does (see Chapter 25 for more on WSDL). Listing 26-2: An Example of a tModel <tModel authorizedName=” ” operator=” ” tModelKey=”UUID:12345678> <name>Our special service</name> <description xml:lan=”en”> WSDL description of our service </description> <overviewDoc> <description xml:lang=”en”>WSDL source document. </description> <overviewURL> k538292 ch26.qxd 8/18/03 8:45 AM Page 660 661 Chapter 26 ✦ UDDI http://mycompany/ourservice/service1.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey=”UUID:987654” keyName=”uddi-org:types” keyValue=”wsdlSpec”/> </categoryBag> </tModel> Fortunately, there are already a host of categories defined as tModels within the UDDI world. If you visit a UDDI site such as http://uddi.microsoft.com, you will see that there are business classification code models for SIC (Standard Industrial Classification) and NAICS (North American Industry Classification System), in addi- tion to other categorization standards. More information on UDDI and links to public servers and tModels can be found at http://uddi.org/. As of this writing, the current public servers include: ✦ uddi.microsoft.com – Microsoft’s UDDI Business Registry Node ✦ uddi.ibm.com – IBM’s UDDI Business Registry Node ✦ uddi.sap.com – SAP’s UDDI Business Registry Node ✦ www.ntt.com/uddi – NTT Com’s UDDI Business Registry Node UDDI APIs To ensure most platforms can access UDDI’s services, the UDDI directory exposes a bunch of APIs in the form of a SOAP-based Web service. There are currently two main nodes that expose the UDDI Web service: http://uddi.microsoft.com/inquire and http://www-3.ibm.com/services/uddi/inquiryapi. The API is con- cerned with registering and discovering Web services. You can download the API specification from the following link: http://www.uddi. org/pubs/ProgrammersAPI-V1.01-Open-20010327_2.pdf The APIs are accessed only through SOAP messages with the appropriate body con- tent. For example, to search for a company called XYZ Industries you would send the XML in the body of a SOAP message as shown in Listing 26-3. Note Note k538292 ch26.qxd 8/18/03 8:45 AM Page 661 662 Part V ✦ Introducing Web Services Listing 26-3: Finding a Business Using UDDI <find_business generic=”1.0” xmlns=”urn:uddi-org:api”> <categoryBag> <keyedReference tModelKey= “uuid:70a80f61-77bc-4821-a5e2-2a406acc35dd” keyName=”Advertising” keyValue=”7310” /> </categoryBag> </find_business> The SOAP response that comes back from UDDI contains all businesses that match your search criteria and the registered services for each business. This information comes back as an XML data structure, of course. These structures are called businessInfos. The UDDI APIs accept and return several data structures, and these are all spelled out in the documentation of the API. Remember that the UDDI API, as an API, is not concerned with it is actually accessed. Any vendor can create class libraries that call the API to interact with UDDI. Listing 26-4 shows how the response is received from the previous inquiry using the tModel in Listing 26-3. Notice how the request and the response are all in SOAP, the bedrock dependency of anything related to UDDI. Listing 26-4: The SOAP Response from a UDDI Request <?xml version=”1.0” encoding=”utf-8”?> <soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <soap:Body> <serviceList generic=”1.0” operator=”Microsoft Corporation” truncated=”false” xmlns=”urn:uddi-org:api”> <serviceInfos> <serviceInfo serviceKey= “d5b180a0-4342-11d5-bd6c-002035229c64” businessKey=”ba744ed0-3aaf-11d5-80dc-002035229c64”> <name>XMethods Barnes and Noble Quote</name> </serviceInfo> </serviceInfos> </serviceList> </soap:Body> </soap:Envelope> k538292 ch26.qxd 8/18/03 8:45 AM Page 662 [...]... QuotesService Web Service < ?xml version=’1.0’ encoding=’UTF -8 ?> The only modification here is the addition of the “ :80 80” to the end of the server name In a production scenario, the server name would normally not be here and would be instead replaced by a DNS name... client-side WSDL is modified, we need to start up the Trace Utility and get it to intercept all requests made to the port we have added, 80 80 Which port you choose is up to you, but it is probably not a good idea to use other well-known ports, like 21 or 443 Usually 80 80 will work for you without any hassles With the Trace Utility running, go to the File | New | Formatted Trace menu, and you will see... After you have selected the Web service you want to use, just click Add to make it part of your project This creates the wrapper class for you Figure 27 -8 shows how this class is located in the VBA project 677 6 78 Part V ✦ Introducing Web Services Figure 27 -8: The resulting wrapper class in a VBA project after referencing a Web service Let’s take a quick peek at what is inside the wrapper class First, the... if you are programming with the SDK in C++ ✦ Lib: A C++ inline file containing definitions of inline functions, as well as template function definitions As discussed in Chapter 24, SOAP is an XML- based standard for describing objects that are used to make calls and responses in Web Services over HTTP In the end, SOAP is just the grammar for describing remote component calls Fortunately, XML is syntactical... structured and passed between the client and the Web service) it must have the ability to understand XML and communicate over some transport protocol (normally HTTP) Because XML is used to package messages between the client and Web service, both parties in the relationship must package the messages in XML using a certain structure, and some mechanism must be able to both do the packaging and process... verbose In addition to seeing the XML representation of the messages, you can also look at the SOAP headers and look at the encoded representations of the messages The Trace Utility can be helpful in creating and troubleshooting Web services, and you should become familiar with its operations to save yourself time and agony as you create and deploy Web services 681 682 Part V ✦ Introducing Web Services... Java, XML, and Web service applications The J2EE platform is also the foundation technology of Sun’s Open Network Environment (ONE) platform and Web services strategy However, core J2EE classes, methods, and properties have absolutely nothing to do with XML or Web services Fortunately for J2EE developers, J2EE classes do contain robust and flexible support for text, and Web services are based on XML, ... separate portal server Portals act as a smart client proxy to manage information and tasks on behalf of a user In a J2EE Web service architecture, the portal interacts with the J2EE application server to 687 688 Part V ✦ Introducing Web Services process Web services (For more information on portals, and how they can be useful for Web Service architectures, see the “About portals” section earlier in this chapter.)... original port number (usually 80 ) so that the Web service is none the wiser The response is then routed back to the Trace Utility, which then in turns sends the information back to the client that made the original request The client does not know that there is a listener involved, nor does the Web service All the client knows is that instead of making requests to port 80 , it will make them to a different . there and that one can be created from scratch if desired. ✦✦✦ k5 382 92 ch25.qxd 8/ 18/ 03 8: 45 AM Page 653 k5 382 92 ch25.qxd 8/ 18/ 03 8: 45 AM Page 654 UDDI W eb services can be used for interaction. Request < ?xml version=”1.0” encoding=”utf -8 ?> <soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> <soap:Body> <serviceList. tModelKey=”123456 78 /> </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> k5 382 92 ch26.qxd 8/ 18/ 03 8: 45 AM Page 6 58 659 Chapter 26 ✦

Ngày đăng: 09/08/2014, 18:22

TỪ KHÓA LIÊN QUAN