Let us observe the electronic collaboration between Austinkayaks and MoneyBroker according to Figure 2. Access the Austinkayaks URL in using the browser work, and then ask for a kayaking when the electronic collaboration begins. Request as an HTTP request (2) Transfer by Internet. The Austinkayaks representation layer (3) receives the request, which issues a request to the business layer through any local protocol (4) used by the site. If AUSTINKAYAKS is a Microsoft site, the local protocol may be (but not necessarily) DCOM.
The Austinkayaks Business Layer now recognizes that you need to pay for the MoneyBroker business logic. This request is made in the local (processing) SOAP agent (5). The SOAP agent packages the payment request as a SOAP request, then uses http (6), send it to the MoneyBroker site via the Internet, and receives a SOAP receiver (7) on the MoneyBroker representation by the MoneyBroker site.
The unique purpose of the SOAP receiver (7) is to translate SOAP requests to a local request, transferred to the MoneyBroker Business Layer (9) through the local protocol (8), and requests the payment. Then, the result is returned from the MoneyBroker business layer to the Austinkayaks representation, which can be translated into the content of the browser that is suitable for the Austinkayaks client.
SOAP is technology neutral. Austinkayaks and MoneyBroker do not need to use the technology construction site in use, as long as their respective technical support SOAP technology can be used interoperability.
For the use of MoneyBroker services, SOAP is not available, but only when Austinkayaks already knows 4 things: MoneyBroker exists; you can find MoneyBroker's URL;, MoneyBroker can accept SOAP requests Exact format. If AUSTINKAYAKS don't know how? If AUSTINKAYAKS only knows it requires bill payment services, but don't know where they are, and how to use them, how will it?
This is why use UDDI. UDDI defines the standards that allow electronic collaboration to find each other. All contents describing the UDDI standard have exceeded the scope of this white paper.
This is where UDDI works. UDDI defines the standard for potential electronic collaborators to find each other. Describe all UDDI standards (these information can be obtained from the Internet "has exceeded the scope of this white paper, but we will discuss as follows:
The URL of the registration device includes information about the industry standard interface, such as bill payment service. It has been committed to supporting specific companies that support industrial standard interfaces (such as MoneyBroker). To the SOAP interface of these devices, potential collaborators can program to use these interfaces to find each other.
A technical neutral language for describing the standard SOAP interface.
Between the UDDI functional standards (HTTP, XML, SOAP) and UDDi Electronic Collaboration Standards, we have a technological neutral architecture to work together.
The .NET platform already includes XML and SOAP technology. Microsoft is one of the three leaders of the UDDI program (other two for Ariba and IBM), so it is very clear that these three standards are mature, we can see they will be merged into the .NET platform.
We have a special group to describe the business logic that SOAP can pay at any time, the group's site three uses the appropriate UDDI standard to make SOAP services can be widely used. We call such business logic as a web service. .NET platform: combine everything together
Figure 3 shows how all parts of the .NET platform are combined. The figure should be compared to the general form of a general form that shows this architecture.
[1] For example, you can refer to UDDI Executive White Paper (UDDI Execute White Paper) or UDDI Technical White Pape (UDDi Technology White Paper), these two white papers can be obtained at http://www.uddi.org/WhitePapers.html.
