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