1. Web Services Technology Stack (WSDL and UDDI)
Shahram Esmaeilsabzali

2. What we will cover WSDL and its elements UDDI registries and APIs
A Web service using ASP.NET and C#

3. Web services conceptual stack
Common Internet Protocols (TCP/IP, HTTP, … )
Extensible Markup Language (XML)
Simple Object Access Protocol (SOAP)
Web Services Description Language (WDSL)
Universal Description, Discovery and Integration (UDDI)
Web Services Flow Language (WSFL, XLANG and … )
Other business rules
Core
Emerging

4. WSDL Defined in a joint effort by Ariba, IBM and Microsoft
An XML format for describing Web Services interfaces as collection of ports
WSDL = IDL + Binding + Service location
IDL: types and operations
Binding: how to access via protocol (E.g. SOAP, HTTP POST or HTTP GET)
Location: Where to connect to the Web service
WSDL works over multiple protocols and technologies using extensibility elements

5. WSDL Elements Abstract Elements: Concrete Elements:
Types: Data type Definition
Messages: Format of Data being communicated
Operations: Description of an action
Port types: set of operations
Concrete Elements:
Bindings: a concrete protocol and data format specification for a particular port type
Ports: a single endpoint defined as combination of Binding+ Network address
Services: a collection of related ports (endpoints)

6. WSDL Elements Relationship
Abstract Reusable Elements
Concrete Elements

7. Types
Encloses data type definitions that are building blocks of exchanged messages
W3C XML Schema as canonical type system
Also allows type systems other than XML Schema to be added via extensibility elements

8. Messages Messages consist of one or more logical parts
part name is a unique name among all other parts of a message
Each part is associated with a type or Element
Parts are a flexible mechanism for describing the logical abstract content of a message
Using XML Schema as type system, WSDL uses:
Element: Refers to an XML Schema element
Type: Refers to an XML Schema simple or complex type

9. Example
“ExchangeRate” C# class is exposed as an ASP.NET Web Service by simply Placing the below C# code in a .asmx file. This file is then put in a directory of an ASP.NET web application (Simple scenario)

10. Example

11. PortType Port Types are set of operations and the messages involved
WSDL has four transmission primitives (operations):
One-way
Request-response
Solicit-response
Notification

12. One-way Operation The endpoint receives a message
They are the simplest mechanism, and it is supported only by MIME protocol (HTTP based protocols are two-way)

13. Request-response
The endpoint receives a message, and sends a correlated message
input element: abstract request message
output element: abstract response message
fault element: optional abstract error message

14. Solicit-response operation
The endpoint sends a message, and receives a correlated message
Output: Abstract solicit request message
Input: Abstract response message
fault element: optional abstract error message

15. Notification Operation
The endpoint receives a message

16. WSDL Elements Relationship
Abstract Reusable Elements
Concrete Elements

17. Binding
A binding defines message format and protocol details for operations and messages defined by a particular portType

18. Ports
A port defines an individual endpoint by specifying a single address for a binding.
Ports are building blocks of Web services
Within a Service they have the following relationships:
None of ports communicate with each other (WSDL specification requirement)
Several ports could implement a single portType
ports can be examined by consumer for checking their desired operations

19. Service
A service groups a set of related ports together

20. Example

21. Import element
Import element allows the separation of elements in a WSDL document
It is a good practice to have at least two separate WSDL documents: “Service interface definition” and “Service implementation definition”
Using Import, introduces features for reusability and abstract interface definitions like object oriented programming
Multiple businesses may implement and advertise the same WSDL interface and service requesters could effectively search for their desired service

22. Web services conceptual stack
Common Internet Protocols (TCP/IP, HTTP, … )
Extensible Markup Language (XML)
Simple Object Access Protocol (SOAP)
Web Services Description Language (WDSL)
Universal Description, Discovery and Integration (UDDI)
Web Services Flow Language (WSFL, XLANG and … )
Other business rules
Core
Emerging

23. What is UDDI?
UDDI defines a set of services supporting the description and discovery of:
Businesses, organizations, and other Web services providers (White Pages)
Web services which businesses make available (Yellow Pages)
Technical interfaces which may be used to access those Web services (Green Pages)
UDDI is based on a set of web standards including HTTP, XML, XML Schema, WSDL and SOAP, and is supported by many companies (HP, IBM, Microsoft and …)

24. What is UDDI?
UDDI specification provides a platform- independent way of describing, discovering and integrating Web services using Internet
UDDI Infrastructure is appropriate for both public and private Web Services-based environments
UDDI data is hosted by nodes which could be collected, using replication mechanism, to form UDDI registries
UDDI provides a set of APIs for inquiring and manipulating UDDI elements

25. UDDI core data structures
All Data structures are XML based
Many UDDI data structures including the four core data structures are accessed via unique identifiers that are either generated by registries or by the publisher itself
UDDI core data structures support mechanisms for electronic signatures ( XML-Signature syntax )

26. UDDI tModel
Technical models or tModels are essential UDDI elements used to represent unique concepts, constructs or metadata
tModels are represented by their unique keys
tModels are extensibility means for UDDI
tModels are reusable entities which can be referenced by other entities like bindingTemplates
The bindingTemplates referencing the same tModels are said to have the same “technical fingerprints”
Their typical applications are in WSDL definition, dynamic categorization and search systems (identifierBags and CategoryBags)
tModels can be used to extend existing categorization and search systems for entities

27. UDDI businessEntity structure
Each businessEntity contains descriptive information about a business or organization and, through its contained businessService entities, information about the services that it offers.
identifierBag element allows businessEntity structures to be identified according to published identifier systems (E.g. DUNS numbers), the systems themselves are registered tModels elements
The categoryBag contains a predefined list of business categorization that each describes a specific business aspect of the businessEntity. Examples of categories are industry, product category or geographic regions

28. UDDI businessServices structure
The businessService structure represents a logical service and contains descriptive information in business terms A businessService is the logical child of a single businessEntity
A businessService may be projected to other businessEntities by reference instead of containment Projections to the same service can be made in any number of business entities.
bindingTemplates is a list of technical descriptions for the Web services.

29. UDDI bindingTemplate Structure
Technical descriptions of Web services are provided by bindingTemplate entities.
The accessPoint element is an URI, typically a URL, representing the network address of the Web service being described. There are four types of accesspoints:
endpoint (Network address of Web service)
bindingTemplate
hostingDirector
WSDL Deployment
tModelInstanceDetails element contains the “technical fingerprint” of the Web service During an inquiry, interested parties can use this information to look for bindingTemplate entities that contain a specific fingerprint or partial fingerprint.

30. UDDI APIs
UDDI APIs are programmatic tools for querying and manipulating UDDI registry data
UDDI APIs are exposed as SOAP messages over HTTP or HTTPS
UDDI APIs are categorized to six groups:
Inquiry APIs: Locates and obtains details of UDDI data
Publishing APIs: Publishes and updates UDDI data
Security APIs: Requests and discards authentication data
Custody transfer APIs: Transfers ownership of elements
Subscription APIs: provides clients with information about changes in UDDI data
Value set APIs: Checks the validity of referenced tModels

31. Some UDDI APIs Inquiry API Publishers API Find things
find_business
find_service
find_binding
find_tModel
find_relatedBusinesses
Get Details about things
get_businessDetail
get_serviceDetail
get_bindingDetail
get_tModelDetail
get_operationalInfo
Publishers API
Save things
add_publisherAssertions
set_publisherAssertions
save_business
save_service
save_binding
save_tModel
Delete things
delete_business
delete_service
delete_binding
delete_tModel
delete_publisherAssertion
Query things
get_assertionStatusReport
get_publisherAssertions
get_registeredInfo

32. Example

33. How does it work? Service Provider Service UDDI Requester
(0) Create the Web Service
(5) Execute Service (SOAP)
(1) Publish (WSDL)
(3) Retrieve Service Description (WSDL)
Service
Requester
UDDI
(2) Find Service and
Retrieve its address (UDDI)
(4) Create Proxy class

34. Web services and Proxy classes
Proxy classes are generated according to WSDL information to call the Web services on behalf of the service requesters
Proxy classes hide the complexity of dealing with SOAP, XML and network protocols
Once Proxy classes are generated, they are compiled (in this case to a .NET DLL file) and can be used by other programs
Some proxy classes settings can be modified at run-time; so for example, if the location of a Web service is changed proxy class is not required to be regenerated

35. Accessing a Web Service with ASP.NET page

36. Web Services future Core Emerging
While Web services have focused on technological foundations for implementing simple Web services, they are not sufficient for using Web services in critical business application, the following are important areas of research in Web services :
Web Services Composition
mechanisms for Web Services work flow and coordination
comprehensive security solutions
Web services transactions
Common Internet Protocols (TCP/IP, HTTP, … )
Extensible Markup Language (XML)
Simple Object Access Protocol (SOAP)
Web Services Description Language (WDSL)
Universal Description, Discovery and Integration (UDDI)
Web Services Flow Language (WSFL, XLANG and …)
Other business rules
Core
Emerging

37. A comparison CBD technologies WS technologies
No standard format for data exchange and encoding
RPC mechanisms
IDL
Registry information
Partly platform independent and usually extremely tightly-coupled
Complex transfer and conversation protocols
CDB paradigm Provides solutions for wide area of applications
Uniform encoding mechanism XML
SOAP
WSDL
UDDI
Platform neutral, highly loose-coupled and cross- platform technology
Using easy open-standard protocols
Existing WS technology is suitable for rather simple applications