• Provides functional description of network services:

  • Idl description (Interface Definition Language - мова визначення інтерфейсу)

  • Protocol and deployment details

  • Platform independent description.

Extensible language

• portType

  • Abstract definition of a service (set of operations)

• Multiple bindings per portType:

  • How to access it

  • SOAP, JMS, direct call

• Ports

  • Where to access it

General structure of WSDL 1.1 and 2.0 files

WSDL files describe services from the bottom up. That is, they start with the data types used and end with the location (address) of the service. In addition, they have three layers of description:

• The first layer describes the interface of a service. This interface (called the “port type” in WSDL 1.1) can consist of one or more operations with input and output parameters that use types specified in the first section of the WSDL file. In WSDL 1.1 the service parameters were defined in <message> sections, while in WSDL 2.0 they are defined just like any other type in the <types> section.

• The second layer defines the “binding” of a Web Service; that is, the protocol and format for which the Web Service operations are provided.

• The third layer defines the physical location (address, URL) where the Web Service is available.

Let’s look at a simple example of a WSDL file. This WSDL file defines a service called CustomerService, which provides one operation called getCustomerAddress( ). Its input parameter is a customer ID of type long, and the output is a structure of three string attributes: the street, the city, and the zip code.

Here is the WSDL 1.1 version:

1 <?xml version="1.0" encoding="utf-8" ?>

2 <definitions name="CustomerService"

targetNamespace="http://soa-in-practice.com/wsdl"

4 xmlns:tns="http://soa-in-practice.com/wsdl"

5 xmlns:xsd1="http://soa-in-practice.com/xsd"

6 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

7 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

8 xmlns="http://schemas.xmlsoap.org/wsdl/">

9

10 <types>

11 <xsd:schema

12 targetNamespace="http://soa-in-practice.com/xsd"

13 xmlns="http://soa-in-practice.com/xsd">

14

15 <xsd:element name="getCustomerAddress">

16 <xsd:complexType>

17 <xsd:sequence>

18 <xsd:element name="customerID" type="xsd:long"/>

19 </xsd:sequence>

20 </xsd:complexType>

21 </xsd:element>

22

23 <xsd:element name="getCustomerAddressResponse" type="Address"/>

24 <xsd:complexType name="Address">

25 <xsd:sequence>

26 <xsd:element name="street" type="xsd:string"/>

27 <xsd:element name="city" type="xsd:string"/>

28 <xsd:element name="zipCode" type="xsd:string"/>

29 </xsd:sequence>

30 </xsd:complexType>

31

32 </xsd:schema>

33 </types>

34

35 <message name="getCustomerAddressInput">

36 <part name="params" element="xsd1:getCustomerAddress"/>

37 </message>

38 <message name="getCustomerAddressOutput">

39 <part name="params" element="xsd1:getCustomerAddressResponse"/>

40 </message>

41

42 <portType name="CustomerInterface" >

43 <operation name="getCustomerAddress">

44 <input message="tns:getCustomerAddressInput" />

45 <output message="tns:getCustomerAddressOutput" />

46 </operation>

47 </portType>

48

49 <binding name="CustomerSOAPBinding"

50 type="tns:CustomerInterface" >

51 <soap:binding style="document"

52 transport="http://schemas.xmlsoap.org/soap/http" />

53 <operation name="getCustomerAddress">

54 <soap:operation

55 soapAction="http://soa-in-practice.com/getCustomerAddress" />

56 <input>

57 <soap:body use="literal" />

58 </input>

59 <output>

60 <soap:body use="literal" />

61 </output>

62 </operation>

63 </binding>

64

65 <service name="CustomerService" >

66 <port name="CustomerPort"

67 binding="tns:CustomerSOAPBinding">

68 <soap:address

69 location="http://soa-in-practice.com/customer11"/>

70 </port>

71 </service>

72

73 </definitions>

Let’s go through it from the bottom up:

• The <service> section at the end defines a service named CustomerService, available at the URL http://soa-in-practice.com/customer11, which is provided with a binding called CustomerSOAPBinding. The prefix tns: is the namespace where we can find details about this identifier. It is defined at the beginning of the document and is the same as the target namespace, which is the namespace all identifiers identified in this file belong to (see lines 3 and 4). That means CustomerSOAPBinding is an identifier defined in this file.

• The <binding> section defines the protocol and format that are used to provide the service. Here, we see the definition of the CustomerSOAPBinding. It starts by specifying which interface type this binding is for (CustomerInterface). Without going into details, the binding specified here is a SOAP binding based on the low-level protocol HTTP (see lines 51 and 52). This section also defines which style of SOAP is used (yes, more than one SOAP binding is possible!).

• The <portType> section defines the interface, CustomerInterface. It consists of one operation, called getCustomerAddress, and specifies the messages that will be sent over the service bus when this operation is called. This service sends a request and gets a response (see Chapter 10 for a discussion of message exchange patterns), which is defined by specifying an input message (getCustomerAddressInput) and an output message (getCustomerAddressOutput). Other messages could be error messages.

• The <message> sections define the individual messages, using the identifiers referred to in the <portType> section. Both getCustomerAddressInput and getCustomerAddressOutput use a data type defined in the <types> section.

• The <types> section defines the data types used: in this case, the input parameter

customerID of type long and the output parameter address, which is a structure/record of three string attributes. All types have their own namespace, xsd1.

The <binding> section states that the SOAP style used here is document/literal, which is a combination of the style attribute in line 51 and the body definitions in lines 57 and 60. In fact the style is document/literal wrapped, because it uses some additional conventions (the input message has a single part that refers to an element; this element has the same name as the operation, and the element’s complex type has no attributes). Over the years, this has evolved as the prevalent SOAP binding.

Here is the corresponding WSDL file for version 2.0 (using SOAP 1.2):

1 <?xml version="1.0" encoding="utf-8" ?>

2 <description

3 targetNamespace="http://soa-in-practice.com/wsdl"

4 xmlns:tns="http://soa-in-practice.com/wsdl"

5 xmlns:xsd1="http://soa-in-practice.com/xsd"

6 xmlns:xsd="http://www.w3.org/2001/XMLSchema"

7 xmlns:wsoap="http://www.w3.org/2006/01/wsdl/soap"

8 xmlns:wsdlx="http://www.w3.org/2006/01/wsdl-extensions"

9 xmlns="http://www.w3.org/2006/01/wsdl">

10

11 <types>

12 <xsd:schema

13 targetNamespace="http://soa-in-practice.com/xsd"

14 xmlns="http://soa-in-practice.com/xsd">

15

16 <xsd:element name="getCustomerAddress">

17 <xsd:complexType>

18 <xsd:sequence>

19 <xsd:element name="customerID" type="xsd:long"/>

20 </xsd:sequence>

21 </xsd:complexType>

22 </xsd:element>

23

24 <xsd:element name="getCustomerAddressResponse" type="Address"/>

25 <xsd:complexType name="Address">

26 <xsd:sequence>

27 <xsd:element name="street" type="xsd:string"/>

28 <xsd:element name="city" type="xsd:string"/>

29 <xsd:element name="zipCode" type="xsd:string"/>

30 </xsd:sequence>

31 </xsd:complexType>

32

33 </xsd:schema>

34 </types>

35

36 <interface name = "CustomerInterface" >

37

38 <operation name="getCustomerAddress"

39 pattern="http://www.w3.org/2006/01/wsdl/in-out"

40 style="http://www.w3.org/2006/01/wsdl/style/iri"

41 wsdlx:safe = "true">

42 <input messageLabel="In"

43 element="xsd1:getCustomerAddress" />

44 <output messageLabel="Out"

45 element="xsd1:getCustomerAddressResponse" />

46 </operation>

47

48 </interface>

49

50 <binding name="CustomerSOAPBinding"

51 interface="tns:CustomerInterface"

52 type="http://www.w3.org/2006/01/wsdl/soap"

53 wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">

54

55 <operation ref="tns:getCustomerAddress"

56 wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>

57

58 </binding>

59

60 <service name="CustomerService"

61 interface="tns:CustomerInterface">

62

63 <endpoint name="CustomerEndpoint"

64 binding="tns:CustomerSOAPBinding"

65 address="http://soa-in-practice.com/customer20"/>

66

67 </service>

68

69 </description>

The major differences are:

• The root XML element is named <description> instead of <definitions>.

• The <service> section uses “endpoint” instead of “port.”

• Inside the <binding> section, lines 52, 53, and 56 define the specific protocol (SOAP 1.2, based on HTTP, using HTTP GET).

• The <portType> section is replaced by an <interface> section. It uses more specific message exchange patterns, which define the low-level ordering of messages (see Chapter 10).

• The <message> section is not available anymore. Instead, the operations directly refer to data types (defined in the <types> section). Which messages are sent follow from the MEP and the types specified in the <interface> section.

• Different namespaces are used to identify WSDL 2.0 and SOAP 1.2.

For details, see [WSDL 2.0].

Note again that the first layer (types, messages, and portTypes for WSDL 1.1 and types and interfaces for WSDL 2.0) is the syntactic interface of the Web Service, specifying the signature of the service. The other layers define technical details, such as the binding and the location of the service.

Note also that these examples skip error handling (which is usually done by providing fault messages similar to input and output messages).

UDDI

UDDI – проект направленный на интеграцию веб-служб. Обеспечивает клиентам механизм динамического поиска веб-служб в Интернете. Ядром является бизнес регистрация – xml-файл, используемый для описания бизнес объекта и его служб. UDDI можно рассматривать как службу DNS для веб-приложений.

• UDDI defines the operation of a service registry:

  • Data structures for registering

    • Businesses

    • Technical specifications: tModel is a keyed reference to a technical specification.

    • Service and service endpoints: referencing the supported tModels

  • SOAP Access API

  • Rules for the operation of a global registry

    • “private” UDDI nodes are likely to appear, though.

When the server sees the request it starts the program named in the request

and passes it the parameter values. At that point, the program simply does its work and generally returns the results in the form of a document that is sent back to the user's browser to be displayed.

Проблемы, которые способна решить спецификация UDDI:

• Становится возможным обнаружить нужного предпринимателя из миллионов уже находящихся в сети

• Определение способов сотрудничества с найденным предприниматилем

• Поиск новых заказчиков и упрощение доступа к уже существующим

• Расширение предложений и увеличение рыночной досягаемости

• Решение проблемы возникающих барьеров при участии в глобальной экономике Internet

• Описание сервисов и деловых процессов программно в единой, открытой и преспективной среде

UDDI используется при создании различных платформ и програмных продуктов, таких фирм как Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP и Sun. Он также с успехом используется операторами рынка и e-busness лидерами.

UDDI specification defines services that support the description and discovery of (1) businesses, organizations, and other Web services providers, (2) the Web services they make available, and (3) the technical interfaces which may be used to access and manage those services.

The core information model used by a UDDI registry is defined in several XML

schemas. XML was chosen because it offers a platform-neutral view of data and allows hierarchical relationships to be described in a natural way. XSD was chosen because of its support for rich data types and its ability to easily describe and validate information based on information models represented in schemas.

The UDDI XSD define several core types of information that provide the kinds of

information that that users and applications would need to know in order to use a

particular Web service. Together, these form a base information model and

interaction framework of UDDI registries.

■ A description of a service’s business function (called the businessService)

■ Information about the organization that published the service (businessEntity),

■ The service’s technical details (bindingTemplate), including a reference to the

service’s programmatic interface or API, and

■ Various other attributes or metadata such as taxonomy, transports, digital signatures and etc(tModel).

UDDI versions 2 and 3 each add an additional data type to facilitate registry affiliation. Respectively, these are:

■ Relationships among entities in the registry (publisherAssertion) and

■ Standing requests to track changes to a list of entities (subscription).

These, like all UDDI data types, are expressed in XML and are stored persistently by a UDDI registry. Within a UDDI registry, each core data structure is assigned a unique identifier according to a standard scheme. This identifier is referred to as a UDDI key.

http://www.codeproject.com/KB/cpp/uddiexplorer.aspx?msg=2266705

http://msdn.microsoft.com/en-us/library/ms950813.aspx\

http://www.xmethods.net/ve2/Directory.po - http://www.soapclient.com/uddiadv.html - Поисковик uddi служб.

http://70.32.81.92/discover.php

http://www.developer.com/net/net/article.php/3107951/Enterprise-UDDI-Services.htm - Windows Server 2003 ships with Enterprise UDDI Services, a dynamic and flexible infrastructure for discovering and integrating Web services within your application.

http://www.xmethods.net/ve2/Directory.po

http://www.uddi.org/pubs/uddi_v3.htm

Web-служби .NET

Реалізація web-служб .NET здійснюється досягається за рахунок застосування інструментів, що надаються системою .NET Framework, які дозволяють створити повноцінну web-службу, не вникаючи в деталі роботи таких стандартів, як SOAP і WSDL. Порядок дій при цьому подібний приведеному нижче (етапи 1, 3, 5 і 8 виконуються вручну).

1. Розробляється web-служба як .NET-клас з атрибутами, які ідентифікують його як web-службу з деякими функціями.

2. У середовищі .NET автоматично створюється документ WSDL, де описується, як клієнт повинен взаємодіяти з web-службою.

3. Споживач знаходить web-службу і, вирішивши скористатися нею, додає відповідне web-посилання в проект Visual Studio .NET (або запускає утиліту wsdl.exe).

4. У середовищі .NET здійснюється автоматична перевірка документа WSDL і генерується проксі-клас, який дозволяє споживачу взаємодіяти з web-службою.

5. Споживач викликає один з методів класу web-служби. Із його точки зору цей виклик не відрізняється від виклику методу будь-якого іншого класу, але насправді споживач взаємодіє з проксі-класом, а не з web-службою.

6. Проксі-клас перетворить передані параметри в повідомлення SOAP і відправляє його web-службі.

7. Незабаром проксі-клас одержує SOAP-відповідь, перетворить її у відповідний тип даних і повертає його як звичний тип даних .NET.

8. Споживач використовує повернену йому інформацію.

При роботі web-служб .NET використовується технологія ASP .NET, що є частиною системи .NET Framework. Вона також вимагає підтримки з боку серверу Microsoft IIS (Internet Information Server). Середовище Visual Studio .NET забезпечує велику кількість інструментів, які допомагають полегшити рішення задач, пов'язаних з отриманням і виконанням web-служби.