shahram esmaeilsabzali...
TRANSCRIPT
What we will cover
• WSDL and its elements
• UDDI registries and APIs
• A Web service using ASP.NET and C#
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
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
WSDL Elements
• Abstract 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)
WSDL Elements RelationshipAbstract Reusable Elements Concrete Elements
Types
<wsdl:types> ?<wsdl:documentation .... />?<xsd:schema .... />* <-- extensibility element --> *
</wsdl: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
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
<wsdl:message name="nmtoken"> * <wsdl:documentation .... />? <part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>
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)<%@ WebService Language="C#" Class="ExchangeRate" %>using systemusing system.web.services[WebService(Namespace=”http://www.example.com/services”)]public class ExchangeRate{ [WebMethod] public float ExchangeRateRequest (string SourceCurrencySymbol,
string TargetCurrencySymbol) {
return 0.7;// real application makes a database call to retrieve exchange rate
}}
Example<types> <schema targetNamespace= "http://example.com/exchangerate.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="ExchangeRateRequest"> <complexType> <sequence> <element name="SourceCurrencySymbol" type="string"/> <element name="TargetCurrencySymbol" type="string"/> </sequence> </complexType> </element> <element name="ExchangeRateRequestResponse"> <complexType> <all> <element name="ExchangeRateRequestResult" type="float"/> </all> </complexType> </element> </schema></types>
<message name="ExchangeRateRequestSoapIn"> <part name="body" element="ExchangeRateRequest"/></message>
<message name="ExchangeRateRequestSoapOut"> <part name="body" element= "ExchangeRateRequestResponse"/></message>
PortType
• Port Types are set of operations and the messages involved
• WSDL has four transmission primitives (operations):– One-way
– Request-response
– Solicit-response
– Notification
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)
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType ></wsdl:definitions>
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
<wsdl:portType name="nmtoken"> <wsdl:operation name="nmtoken" .... /> *
</wsdl:portType>
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType ></wsdl:definitions>
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
<wsdl:portType name="nmtoken"> <wsdl:operation name="nmtoken" .... /> *
</wsdl:portType>
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType ></wsdl:definitions>
Notification Operation
• The endpoint receives a message
<wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:portType ></wsdl:definitions>
WSDL Elements RelationshipAbstract Reusable Elements Concrete Elements
Binding– A binding defines message format and protocol
details for operations and messages defined by a particular portType
<wsdl:definitions .... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? > ? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? > ? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding></wsdl:definitions>
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
<wsdl:port name="nmtoken" binding="qname">*<wsdl:documentation .... /> ? <-- extensibility element -->
</wsdl:port>
Service
• A service groups a set of related ports together
<wsdl:service name="nmtoken"> *<wsdl:documentation .... />? <wsdl:port name="nmtoken" binding="qname"> *
<wsdl:documentation .... /> ?<-- extensibility element -->
</wsdl:port> <-- extensibility element -->
</wsdl:service>
<portType name="ExchangeRateSoapPort"><operation name="ExchangeRateRequest">
<input message="ExchangeRateRequestSoapIn"/><output message="ExchangeRateRequestSoapOut"/>
</operation> </portType><binding name="ExchangeRateSoapBinding" type="ExchangeRateSoapPort">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="ExchangeRateRequest"> <soap:operation soapAction="http://example.com/services/ExchangeRateRequest"/>
<input> <soap:body use="literal"/>
</input> <output>
<soap:body use="literal"/> </output>
</operation> </binding><service name="ExchangeRate">
<port name="ExchangeRateSoap" binding="ExchangeRateSoapBinding"> <soap:address location="http://example.com/services/exchangerate.asmx"/>
</port></service>
Example
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
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
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 …)
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
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 )
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
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
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.
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.
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
Some UDDI APIs• Inquiry 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
Example<businessServicebusinessKey="uddi:example.com:ExchangeRateCo"serviceKey="uddi:example.com:service"> <name>ExchangeRate </name> <description> This Service Exchanges rates </description> <bindingTemplates>
<bindingTemplate servicekey=”uddi:example.com:service” bindingKey="uddi:example.com:binding"> <description xml:lang="en"> This is a Binding for ExchangeRateService </description> <accessPoint useType=”wsdlDeployment”> http://www.example.com/services/exchangerate.wsdl
</accessPoint> <tModelnstanceDetails>
<tModelnstanceInfo tModelKey="uddi:example.com:serviceInterface">
</tModelnstanceInfo> </tModelnstanceDetails>
</bindingTemplate> </bindingTemplates></businessService>
How does it work?
Service Requester
Service Provider
(1) Publish (WSDL)
(5) Execute Service (SOAP)
(2) Find Service and Retrieve its address (UDDI)
UDDI
(3) Retrieve Service Description (WSDL)
(4) Create Proxy class
(0) Create the Web Service
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
Accessing a Web Service with ASP.NET page
<%@ Page Language = “C#” Debug=”true” %><%@ Import namespace = “CurrencyExchange” %>
<script Language=”C#” runat=”server”>
void GetExchangeRate (System.Object sender, System.EventArgs e){ ExchangeRate ws = new ExchangeRate(); lbvalue.Text = ws.ExchangeRateRequest (txtsource.Text, txtdest.Text);}</script>
<html> <body> <form id=’Form1” method=”post” runat=”server”> <strong> Enter the source and destination currency symbols</strong> <br />
<asp:TextBox id = “txtsource” runat=”server”> </asp:TextBox> <br /> <asp:TextBox id = “txtdest” runat=”server”> </asp:TextBox> <br /> <asp:Button id= “Button1”
runat=”server” Text=”Submit” onClick=”GetExchangeRate” > <br />
....</html>
Web Services future
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
• 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
A comparison
• 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
CBD technologies WS technologies