Session I Part II: WS Standards Umesh Bellur IIT Bombay umesh[at]it.iitb.ac.in.

Slides:



Advertisements
Similar presentations
18 Copyright © 2005, Oracle. All rights reserved. Distributing Modular Applications: Introduction to Web Services.
Advertisements

Web Service Architecture
Siebel Web Services Siebel Web Services March, From
31242/32549 Advanced Internet Programming Advanced Java Programming
Web Service Ahmed Gamal Ahmed Nile University Bioinformatics Group
UDDI v3.0 (Universal Description, Discovery and Integration)
General introduction to Web services and an implementation example
SOAP.
SOAP. Service Broker Basic SOAP Message Exchange Service Consumer Service Provider http transport SOAP message WSDL describing service SOAP message http.
1 Understanding Web Services Presented By: Woodas Lai.
Web Services Darshan R. Kapadia Gregor von Laszewski 1http://grid.rit.edu.
Web Services Nasrullah. Motivation about web service There are number of programms over the internet that need to communicate with other programms over.
SOAP Quang Vinh Pham Simon De Baets Université Libre de Bruxelles1.
Web Services Technology Stack (WSDL and UDDI)
Presentation 7 part 2: SOAP & WSDL. Ingeniørhøjskolen i Århus Slide 2 Outline Building blocks in Web Services SOA SOAP WSDL (UDDI)
XML Technologies and Applications Rajshekhar Sunderraman Department of Computer Science Georgia State University Atlanta, GA 30302
UDDI Ashish Jain University of Colorado 3 October, 2001.
Web Services Seppo Heikkinen MITA seminar/TUT
WSDL Web Services Description Language Neet Wadhwani University of Colorado 3 rd October, 2001.
CS 415 N-Tier Application Development By Umair Ashraf July 6,2013 National University of Computer and Emerging Sciences Lecture # 9 Introduction to Web.
Processing of structured documents Spring 2003, Part 6 Helena Ahonen-Myka.
SOAP, WSDL, UDDI. Service Broker Basic SOAP Message Exchange Service Consumer Service Provider http transport SOAP message WSDL describing service SOAP.
In Introduction to Web Services
Introduction to UDDI From: OASIS, Introduction to UDDI: Important Features and Functional Concepts.
SOAP Simple Object Access Protocol by Vinubalaji Gopal (Vinu)
T Network Application Frameworks and XML Web Services and WSDL Sasu Tarkoma Based on slides by Pekka Nikander.
Cambridge, March 23 rd 2004 MobileMAN Project MobileMAN Project Web Service in Ad Hoc Network Veronica Vanni NETikos S.p.A.
Web Service Addressing CS409 Application Services Even Semester 2007.
Web Services (SOAP, WSDL, and UDDI)
James Holladay, Mario Sweeney, Vu Tran. Web Services Presentation Web Services Theory James Holladay Tools – Visual Studio Vu Tran Tools – Net Beans Mario.
Lecture 15 Introduction to Web Services Web Service Applications.
Web Services Description Language CS409 Application Services Even Semester 2007.
1 Universal Description, Discovery, and Integration (UDDI) 大葉大學資工系.
UDDI Jianguo Lu University of Windsor What is UDDI?  Universal Description, Discovery, and Integration  A project to encourage interoperability.
1 UDDI (Universal Description, Discovery, and Integration) An Overview – part II Version : Date : Pages Responsible Author : Co-Authors : Status : Confidentiality.
Web Services Based on SOA: Concepts, Technology, Design by Thomas Erl MIS 181.9: Service Oriented Architecture 2 nd Semester,
XML Web Services Architecture Siddharth Ruchandani CS 6362 – SW Architecture & Design Summer /11/05.
Web Services. ASP.NET Web Services  Goals of ASP.NET Web services:  To enable cross-platform, cross- business computing  Great for “service” based.
INFOSYS 290, Section 3, Fall 2005, Web Services: Concepts, Design and Implementation Adam Blum Lecture 2: Describe and Invoke - SOAP and.
 Contains services or interfaces that can be accessed over Internet.  Provides certain functionalities and attributes for other applications.  Application.
WebService. Outline Overview of Web Services SOAP (messaging) WSDL (service description) UDDI (registry)
Web Services Registries and UDDI INFOSYS290-3 Web Services: Concepts, Design and Implementation.
Helsinki, June 7 th 2004 IAB Meeting MobileMAN Project Web Service in Ad Hoc Network Veronica Vanni NETikos S.p.A.
Copyright © 2013 Curt Hill SOAP Protocol for exchanging data and Enabling Web Services.
1 Web Services Web and Database Management System.
Service provider service requestor application object (client) application object (service provider) SOAP-based middleware SOAP messages exchanged on top.
XML and Web Services (II/2546)
S imple O bject A ccess P rotocol Karthikeyan Chandrasekaran & Nandakumar Padmanabhan.
Kemal Baykal Rasim Ismayilov
CP3024 Lecture 10 Web Services. What are Web Services?  “encapsulated, loosely coupled, contracted software objects offered via standard protocols” ZapThink.
Web Services Part 1 -- Qinwei Zhu Part 2 – Yongqun He.
1 G52IWS: Web Services Chris Greenhalgh. 2 Contents The World Wide Web Web Services example scenario Motivations Basic Operational Model Supporting standards.
REST By: Vishwanath Vineet.
Introduction to Web Services Presented by Sarath Chandra Dorbala.
Lecture VI: SOAP-based Web Service CS 4593 Cloud-Oriented Big Data and Software Engineering.
1 G52IWS: Web Services Description Language (WSDL) Chris Greenhalgh
1 G52IWS: Universal Description, Discovery and Integration (UDDI)‏ Chris Greenhalgh
SOAP, Web Service, WSDL Week 14 Web site:
Jackson, Web Technologies: A Computer Science Perspective, © 2007 Prentice-Hall, Inc. All rights reserved Chapter 9 Web Services: JAX-RPC,
Service Discovery: UDDI COMP6017 Topics on Web Services Dr Nicholas Gibbins –
INFS3204/ M51 INFS 3204/7204 Service-Oriented Architecture Dr Heng Tao SHEN ITEE, UQ Semester 2, M5: Web Service basics.
Sabri Kızanlık Ural Emekçi
WEB SERVICES From Chapter 19 of Distributed Systems Concepts and Design,4th Edition, By G. Coulouris, J. Dollimore and T. Kindberg Published by Addison.
Implementing a service-oriented architecture using SOAP
WEB SERVICES From Chapter 19, Distributed Systems
Presentation transcript:

Session I Part II: WS Standards Umesh Bellur IIT Bombay umesh[at]it.iitb.ac.in

Session II: Contents XML Basics WS Core Standards: –WSDL –SOAP –UDDI

Basic SOAP Message Exchange Consuming Program Service Requestor Exposing Program Service Provider http transport SOAP message WSDL describing service Service Registry UDDI discover services WSDLs describing services SOAP message http transport

SOAP Message

Sample SOAP Message T14:00:00-05:00 Pick up Mary at school at 2pm

Conversational Message Exchange buyer seller message broker RFQ QuoteResponse Award

Conversational SOAP Message Exchange: A Request SanDisk SecureDigital memory 1GB 100

Conversational Exchange: A Response env:mustUnderstand=“true”> KingMax SecureDigital memory 1GB 9000KB/s Memories Unlimited KM-SD

Conversational Exchange: Completion KM-SD

Remote Procedure Calls To invoke RPC –Address of target SOAP node –Method name –Identities and values of arguments –Separation of arguments identifying target of RPC versus data Plus values of properties for binding (e.g. GET, POST) –Optional header data

RPC Invocation 5 ing

Body g

RPC Result 5 <s:shipOrderResponse env:encodingStyle=“ xmlns:rpc=“ xmlns:s=“ s:status confirmed $20.00

SOAP Faults Place faults inside env:Body elements In single env:Fault env:Node identifies node which generated fault –Absence indicates “ultimate recipient” env:Code –env:Value –env:Subcode env:Reason –env:Text env:Detail –Application specific

SOAP Fault Example env:Sender rpc:BadArguments Processing error Chyba zpracování Unknown destination 999

SOAP Faults on MustUnderstand env:MustUnderstand Header not understood En-tête non compris

SOAP Processing Model SOAP messages are sent from one sender node passing through zero or more intermediaries Three roles –next: each SOAP intermediary or end destination must act in this role –none: SOAP nodes must not act in this role –ultimateReceiver: destination acts in this role Header blocks targeted to specific roles using Role attribute If mustUnderstand=“true” SOAP receiver must understand or generate SOAP fault Header blocks processed by intermediaries are generally removed before forwarding –Override with relay attribute –Allows targeting of headers to specific intermediaries (but mustUnderstand would then generally be turned off)

SOAP Extensibility in Practice dhw6weiurU982ndya73jdVBGt d79HID7ghd652ad

SOAP Processing: Header Blocks, MustUnderstand and Relay

SOAP Bindings specify how SOAP messages may be passed from one SOAP node to another using an underlying protocol provides a serialized representation of the message provides a mechanism to support features needed by SOAP applications (security, reliability, etc...) describes the features it provides

SOAP HTTP Binding Example POST /Reservations HTTP/1.1 Host: marketplace.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: nnnn –

SOAP SMTP Binding Example From: To: Subject: RFQ: Memory purchase Date: Thursday, September Message-Id: Content-Type: application/soap+xml

SOAP Remoting Architecture Server object implementation application level Client application code Server skeleton XML unmarshaller Client stub XML marshaller TCP/IP socket remoting architecture level wire protocol level http protocol http server http server body envelope header

So what’s different? Open format usable from any platform Easy to understand and debug Stable supported interfaces Standards enable “expose service once” and have multiple consumers –versus typical point to point integration efforts Easy for intermediaries to process messages and add value –Routing and delivery –security –management and monitoring –schema and service design – acceleration Easy to extend with additional semantics

CORBA Server object implementation application level Client application code Server skeleton Corba runtime Implementation repository Client stub Corba runtime Implementation repository ORB TCP/IP socket

CORBA Dynamic Invocation Server object implementation application level Client application code Server skeleton Corba runtime Implementation repository Client stub Corba runtime Implementation repository ORB TCP/IP socket binding method Remoting architecture level Wire protocol level

CORBA Scalability –Stateful programming model - –Shared activation + Performance –CORBA is only intermediary until object obtained (allowing direct client- server interaction) + –Binary transport + Activation –Sophisticated four policy activation methods + State Management –Provides state management with a connection-oriented protocol + Garbage Collection –Implemented on per ORB vendor basis –No concept of distributed memory management Security –Just uses SSL -

DCOM and DCE RPC Server object implementation application level Client application- code Server stub COM runtime Client proxy COM runtime SCM RPC channel binding method Remoting architecture level Wire protocol level registry OXID Resolver Ping client/server

DCOM Object Creation Server object implementation application level Client application- code Server stub COM runtime Client proxy COM runtime SCM RPC channel binding method Remoting architecture level Wire protocol level registry OXID Resolver Ping client/server

DCOM Object Invocation Server object implementation application level Client application- code Server stub COM runtime Client proxy COM runtime SCM RPC channel binding method Remoting architecture level Wire protocol level registry OXID Resolver Ping client/server

DCOM Comparison Scalability –Not scalable due to garbage collection and connection overhead –All clients involved in call required to send pings to servers at two minute intervals Performance –Many roundtrips to activate and use remote object Activation –Client obtains reference to remote object’s class object through local SCM from remote SCM –Client creates instances of remote objects through its proxy State Management –DCOM goal: location transparency –Makes it very difficult to have a stateless model User interface IFaces Iteration IFaces Garbage Collection –After three ping fails, server cleans up resources for objects owned by remote client Security –Provides authentication, authorization and identity –Many authentication methods

Java RMI Server object implementation application level Client application- code Server skeleton Remote Reference Layer Client stub Remote Reference Layer Transport Layer binding method remoting architecture level wire protocol level Transport Layer TCP/IP Socket RMI Registry

JRMP signature (JRMI) version protocol SingleOpProtocol StreamProtocol MultiplexProtocol Message (serialized arguments based On Java’s Object Serialization Protocol)

RMI Comparison Scalabilitiy –Good overall –Registry could be bottleneck Performance –Fairly high –Use from Java applets in browser cause conversion to http –expensive Activation –Stub can be download over the network –Lazy activation and selection of specific server instances –Allows automatic instantiation of objects based on methods faulting and the fault resolution process instantiating the remote object State Management –Provides both connection-oriented and connectionless protocols (good!) Garbage Collection –Distributed reference counting (like CORBA, DCOM) –Reference to remote objects is considered lease on object, which must be periodically renewed Security –Strong security –Must have security credentials to perform dynamic class loading

SOAP Comparison Scalability –Very scaleable especially over http if request/response model is maintained Performance –Degraded by XML overhead –But if you’re interoping between architectures anyway that overhead isn’t unreasonable Activation –Beyond SOAP’s scope State Management –Stateless if over http Garbage Collection –Beyond scope

Soap Comparison (2) Security –https/SSL - not ideal for routability of course –WS-Security Other Disadvantages –No true standard serialization method –Multiple copies of objects transported Other Advantages –Encouragement of loose coupling (both physical and interface) –Protection of apps from changes in standards –Truly vendor-agnostic

Web Services Description Language (WSDL)

Web Services Description Language Provides a model and an XML format for the “contract” of a web service Separates abstract service description from both concrete network protocol and message format Describes data types used in messages Messages are defined as aggregation of typed parts Operations are message exchange patterns supported by the web service PortTypes are named collections of operations

WSDL Components Types– a container for data type definitions using some type system (such as XSD). Message– an abstract, typed definition of the data being communicated. Operation– an abstract description of an action supported by the service. Port Type–an abstract set of operations supported by one or more endpoints. Binding– a concrete protocol and data format specification for a particular port type Port– a single endpoint defined as a combination of a binding and a network address. Service– a collection of related endpoints.

WSDL Specification types message operation porttype operation binding service port

An Example - WSDL Types

WSDL Operations

WSDL Bindings, Services, Ports

My first service

Import for Types

WSDL Binding maps the abstract service functionality to a specific network protocol and message format defines: –the communication protocol to use –how service interactions are accomplished using this protocol –the address to communicate with Three bindings are defined in the WSDL spec: –SOAP binding – HTTP binding – SMTP binding

WSDL Binding Example: One-way Over SMTP

Request-Response RPC Over HTTP – – – > My first service

Web Services Survey Public APIs –Google –Amazon Business APIs –SalesForce –Siebel CRM OnDemand

Google’s WSDL Messages

Google’s PortTYPE

Google Bindings and Endpoint <soap:body use="encoded" namespace="urn:GoogleSearch" encodingStyle=" g/" /

Google Search Request XXrPsWdQFHKLrnHP5BRLENvY9mRSoAsI Java SOAP 0 10 false false

Search Response

URL xsi:type="xsd:string"> 106.ibm.com/developerworks/xml/library/x- soapcl/ This article describes a simple, general purpose SOAP client in Java that uses no specialized SOAP libraries.... A general- purpose Java SOAP client... A simple SOAP client

Web Services Registries and UDDI

Why Do We Need a Web Services Registry Web services are valuable because of standardized payloads and transport definitions –The value is creating a web service that is used by many clients Can’t happen unless the services are advertised to multiple consumers

What Does UDDI Contain? Businesses and other service providers Services they expose Bindings (locations) of those services Interfaces supported by those services

UDDI Entities businessEntity – provider of service businessService – collection of related services bindingTemplate - information necessary to use tModel - “reusable concept” such as –Interface –Protocol used by web services –Category publisherAssertion - relationship that business entity has with another businessEntity Subscription – request to be informed of particular changes

Core UDDI Entities businessService Interface tModel bindingTemplate businessEntity bindingTemplate Interface tModel

Design Principles Keys as unique identifiers –Publisher assigned (new in V3) –Or generated by registry Containment and references –Keys inside elements are either contained entities or references to other entities Collections –Simple structure (e.g. name) just listed multiple times –Complex structure has container element (e.g. contacts on business Optional attributes –Empty not omitted –<keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:iso3166” keyName=”” – keyValue=”US-CA”/>

businessEntity Structure

businessEntity Identifying Elements Uniquely identified by businessKey attribute discoveryURLs – y:sales:53 Returns XML document of type businessEntity – name –Multiple names to do languages or abbreviations – – – 日本生花店 – ニッポンセイカテン – NIPPON FLOWERS – NF –..... – description –Multiple descriptions potentially in multiple languages with xml:lang

businessEntity contacts <

businessEntity Identifiers and Categories Optional IdentifierBag – <keyedReference tModelKey=”uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s” keyName=”SAP AG” keyValue=” ” /> – Optional CategoryBag – <keyedReference tModelKey=”uddi:uddi.org:ubr:categorization:iso316 6” keyName=”California, USA” – keyValue=”US-CA” /> –

UDDI Keyed References tModelKey – –Required reference to tModel representing the identifier system (e.g. company identifier codes, geographical categories) keyName –Optional description of the identifier keyValue –Required identifier within the overall system

Keyed Reference Groups <keyedReference tModelKey=”uddi:uddi.org:ubr:categoriz ation:wgs84:latitude” keyName=”WGS 84 Latitude” keyValue=” ” /> <keyedReference tModelKey=”uddi:uddi.org:ubr:categori zation:wgs84:longitude” keyName=”WGS 84 Longitude” keyValue=” ” />

businessService

Uniquely identified by optional serviceKey attribute –Supplied by UDDI if not supplied by publisher Optional descriptions Optional categorizations in categoryBag One or more bindingTemplates Optional digital signature

bindingTemplates

bindingTemplate Uniquely identified by optional bindingKey attribute Optional serviceKey identifies service that contains this bindingTemplate descriptions accessPoint - network address (URL) hostingRedirector – deprecated categoryBag – e.g. can indicate that given template if status of “test” or production” tModelInstanceDetails -

tModelInstance Details

overviewDoc

tModels The “technical fingerprint” –tModel’s define unique identifiers for interfaces and interface specifications –Once tModel is published service advertises compliance with the spec represented by including the correct tModelKey Value sets –Categorization hierarchies –E.g. categoryBag and identifierBag have references to tModels with the system of values Find qualifiers –find_business uddi:uddi.org:findqualifier:sortbydateasc

tModel Structure

Exactly one non-empty name Zero or more descriptions Zero or more overviewDocs –useType=text –useType=wsdlInterface identifierBag –Contains tModelKey which uniquely identifies tModel (inconsistent?) –Other logical identifiers categoryBag –list of categories that describe specific aspects of the tModel

UDDI Keys Domain keys –uddi:acmewidgets.com UUID keys –uddi:4CD7E4BC-648B-426D EAAC8AE23 Derived keys –uddi:tempuri.com:fish:buyingservice Key generator keys –Uddi:acmewidgets.com:keygenerator

UDDI Standard APIs

UDDI APIs Inquiry Publication Subscription Security Custody Transfer Replication

Inquiry API Patterns Browse –find_xx Drill-down –Use browse then drill-down –get_xx Invocation –Use browse and drilldown and get bindingTemplate –Invoke from bindingTemplate

Inquiry API Functions find_binding find_business find_relatedBusinesses find_service find_tModel get_bindingDetail get_businessDetail get_operationalInfo get_serviceDetail get_tModelDetail

find_binding

find_business

Find_business example uddi:uddi.org:findqualifier:approximatematch uddi:uddi.org:findqualifier:combinecategoryb ags

find_service

find_tModel

find_tModel Example uddi:uddi.org:findqualifier:caseinsensitivematch uddi:uddi.org:findqualifier:approximatematch rosetta%

Combined Searches uddi:uddi.org:findqualifier:sortbynameasc uddi:uddi.org:sortorder:uts-10 uddi:uddi.org:findqualifier:orallkeys uddi:some.specific.example:tmodelkey uddi:uddi.org:findqualifier:approximatematch uddi:uddi.org:findqualifier:caseinsensitivematch uddi:uddi.org:sortorder:uts-10 Rosetta%

Publication API save_binding save_business save_service save_tModel Delete_xx Xx_publisherAssertions

Mapping WSDL to UDDI UDDI technote (V2.0 in August 2003) regarding –How to take about WSDL objects and store them in UDDI equivalents –Enables queries on WSDL constituents (portTypes, operations, ports)

Overview

Wsdl:portType->uddi:tModel WSDLUDDI portTypetModel (categorized as portType) Namespace of portTypekeyedReference in categoryBag Local name of portTypetModel Name Location of WSDL Document overviewURL

portType->tModel StockQuotePortType <keyedReference tModelKey="uuid:d01987d1-ab2e be2-2a66eb99d824" keyName="portType namespace" keyValue=" /> <keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7- 1ca18373f457" keyName="WSDL type" keyValue="portType" />

WSDL Binding to UDDI tModel WSDLUDDI bindingtModel (categorized as binding and wsdlSpec) Namespace of bindingkeyedReference in categoryBag Local name of bindingtModel Name Location of WSDL DocumentoverviewURL portType reference and protocol references keyedReferences in category bag

StockQuoteSoapBinding <keyedReference tModelKey="uuid:d01987d1-ab2e be2-2a66eb99d824" keyName="binding namespace" keyValue=" /> <keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457" keyName="WSDL type" keyValue="binding" /> <keyedReference tModelKey="uuid:082b d8-303c-b332-f24a6d53e38e" keyName="portType reference" keyValue="uuid:e8cf b35-865f-94a7322e40c3" /> <keyedReference tModelKey="uuid:4dc d9-aecd-33c57dc3a865" keyName="SOAP protocol" keyValue= "uuid:aa de df3-a5c075d64a0e" /> <keyedReference tModelKey="uuid:e5c e4-37bf d04b35c0099" keyName="HTTP transport" keyValue=" uuid:68DE9E80-AD09-469D-8A BFBC36" /> <keyedReference tModelKey="uuid:c1acf26d d70-39b756e62ab4" keyName="uddi-org:types" keyValue="wsdlSpec" />

WSDL Service to UDDI Business Service WSDLUDDI ServicebusinessService (categorized as service) Namespace of ServicekeyedReference in categoryBag Local Name of ServicekeyedReference in categoryBag; optionally also the name of the service

WSDL Port to UDDI bindingTemplate WSDLUDDI portbindingTemplate Namespace Captured in keyedReference of the containing businessService Local name of port instanceParms of the tModelInstanceInfo relating to the tModel for the binding Binding implemented by port tModelInstanceInfo with tModelKey of the tModel corresponding to the binding portType implemented by port tModelInstanceInfo with tModelKey of the tModel corresponding to the portType

Business Service and Binding Templates <businessService serviceKey="102b114a-52e0-4af4-a da543d4" businessKey="1e65ea29-4e0f d352d7b10368"> Stock Quote Service <bindingTemplate bindingKey="f793c521-0daf-434c e32da232e74" serviceKey="102b114a-52e0-4af4-a da543d4"> <tModelInstanceInfo tModelKey="uuid: f4a5-4ba5-b8d0-32ab388dadda"> The wsdl:binding that this wsdl:port implements. The instanceParms specifies the port local name. StockQuotePort <tModelInstanceInfo tModelKey="uuid:e8cf b35-865f-94a7322e40c3"> The wsdl:portType that this wsdl:port implements.

… and category bags for same <keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457" keyName="WSDL type" keyValue="service" /> <keyedReference tModelKey="uuid:d01987d1-ab2e be2-2a66eb99d824" keyName="service namespace" keyValue=" /> <keyedReference tModelKey="uuid:2ec bec-c9dbefcaccf6" keyName="service local name" keyValue="StockQuoteService" />

Extending the Registry Categorization of tModels can be used to provide –Versioning of interfaces –QoS information on bindingTemplates

Versioning of tModels StockQuotePortType <keyedReference tModelKey="uddi:uddi.org:versioning:minor-version" keyName="Minor Version" keyValue="1"/>

QoS Information on BindingTemplates Stock Quote Service This is the reference to the tModel that will have all of the QOS related categories attached. This points to the tModel that has the reference to the web service endpoint that allows detailed retrieval of information

The tModel with the QoS Information – QoS Information for Stock Quote Service – – 10Mbps" />

Specs “Using WSDL in a UDDI Registry, Version 2.0.2” – open.org/committees/uddi- spec/doc/tn/uddi-spec-tc-tn-wsdl-v htm

Articles.NET UDDI –Web Services Journal, “Microsoft UDDI SDK 2.0”, con.com/webservices/article.cfm?id=544 –MSDN, “Using UDDI at Run Time, Part I”, us/dnuddi/html/runtimeuddi1.asp - uses UDDI to query for other services for redundancy us/dnuddi/html/runtimeuddi1.asp –MSDN, “Using UDDI and Run Time, Part II”, us/dnuddi/html/runtimeuddi2.asp - uses UDDI to register service and then to query for instances of services supporting given tModel us/dnuddi/html/runtimeuddi2.asp Extending UDDI –UDDI as an Extended Web Services Registry: Versioning, quality of service, and more”, Blum Web Services Journal, June 2004, – “Extending UDDI with robust Web services information”, Blum