Web Services. Lecture II. Valdas Rapševičius Vilnius University Faculty of Mathematics and Informatics

Transcription

1 Web Services Lecture II Valdas Rapševičius Vilnius University Faculty of Mathematics and Informatics

2 Outline Understand the concept of WS-* SOAP WSDL UDDI Examples Trends Valdas Rapševičius. Web Services 2

3 Web Services (1) Web Services are self-contained, modular applications that can be described, published, located and invoked over a network, generally the World Wide Web. (IBM, September 2000) Bottom-up view: Web services allow remote procedure calls through firewalls Top-down view: Web services provide the means for application integration, especially between business partners Historical view: Internet: network of computers World Wide Web: network of documents Web services: network of applications Valdas Rapševičius. Web Services 3

4 Web Services (2) A Web Service is an application programming service that can be accessed remotely via standard Internet protocols using XML as the data format. Key elements in this definition: A Web service is a programming service, not an end user service A Web service is designed to be used remotely. A Web service is accessible via standard Internet protocols, ex. HTTP. A Web service communicates data in XML format. Benefits of using Web services: Easier to integrate applications together. Services re-usable. Making application flexible to meeting constantly changing business needs Valdas Rapševičius. Web Services 4

5 Service Oriented Architecture Valdas Rapševičius. Web Services 5

6 SOA with WS-* Valdas Rapševičius. Web Services 6

7 Key Technologies XML (extensible Markup Language) - A markup language used to organize information in clear text format. HTTP (Hyper-Text Transport Protocol) - An Internet communication protocol used by the World Wild Web system. HTTP are used to deliver Web service requests and responses. SOAP (Simple Object Access Protocol) - An XML based protocol used to define requests and responses for a Web service. WSDL (Web Services Description Language) - An XML based language to describe a Web service. UDDI (Universal Description, Discovery and Integration) - A server acting like a Web service directory. Web services can be registered and discovered on a UDDI server Valdas Rapševičius. Web Services 7

8 Web Services Stack Valdas Rapševičius. Web Services 8

9 Web Service Architecture Web services use standardized protocols and data formats (e.g. HTTP, XML, SOAP) The access of a web service is independent of its implementation and deployment platform The service description provides all the details necessary to invoke a web service Valdas Rapševičius. Web Services 9

10 Web Service Model The endpoint interface defines the operations of a web service A binding maps the endpoint interface to a protocol stack A port defines the endpoint address that a client can use to access the web service Valdas Rapševičius. Web Services 10

11 Standards W3C ( XML and XML Schema Simple Object Access Protocol (SOAP) Web Services Definition Language (WSDL) OASIS ( Universal Description, Discovery and Integration (UDDI) Electronic Business using XML (ebxml) Web Services Security (WSS) WS-I ( Web Services Interoperability Profile BEA, IBM, Microsoft, SAP Business Process Execution Language for Web Services (BPEL4WS) Valdas Rapševičius. Web Services 11

12 SOAP Simple Object Access Protocol 1998 at Microsoft SOAP is an XML-based communication protocol that defines the structure of messages (envelope) bindings to transport protocols (e.g. HTTP) encoding rules for data types conventions for remote procedure calls a mechanism for error handling SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation-specific semantics Valdas Rapševičius. Web Services 12

13 SOAP 1.2 specification Key concepts (part 1) SOAP Message Construct - How a SOAP message should be constructed. SOAP Protocol Binding Framework - How a SOAP message should be bound a communication protocol to carry it from the sender to the receiver. SOAP Processing Model - How a SOAP message should be processed by SOAP receivers. SOAP Extensibility Model - How SOAP can be extended to add SOAP features and SOAP modules. Adjuncts (part 2): SOAP Data Model - How data structures and values should be represented as a graph of nodes. SOAP Encoding - How data presented in SOAP Data Model should be encoded as XML data. SOAP RPC Presentation - How Remote Procedure Call (RPC) should be modelled with SOAP. SOAP Convention for Describing Features and Bindings - How SOAP Features and Bindings should be described. SOAP Supplied Features - Commonly used SOAP extensions. SOAP HTTP Binding - How a SOAP message is bound to HTTP Valdas Rapševičius. Web Services 13

14 SOAP Message The envelope is the message container The optional header may contain processing or routing information The body contains arbitrary XML data or a SOAP fault Valdas Rapševičius. Web Services 14

15 SOAP Message Examples (1) POST /stocks/services/stockquoterservice HTTP/1.1 Content-Type: text/xml; charset="utf-8" Content-Length: 338 Host: distsys.ch SOAPAction: "" <env:envelope xmlns:env=" > <env:body> <getquote xmlns=" <symbol>abbn</symbol> </getquote> </env:body> </env:envelope> Valdas Rapševičius. Web Services 15

16 SOAP Message Examples (2) From: To: Subject: Greeting <env:envelope xmlns:env=" <env:header> <h:control xmlns:h=" <h:sender>herong</h:sender> </h:control> </env:header> <env:body> <b:greeting xmlns:b=" <b:msg>hello there!</b:msg> </b:greeting> </env:body> </env:envelope> Valdas Rapševičius. Web Services 16

17 SOAP Message w/attachment SOAP Part Attachment Parts Attachments may contain any non-xml data Valdas Rapševičius. Web Services 17

18 SOAP Headers SOAP Headers are not standardized and may contain additional information such as authentication and authorization transaction management tracing and auditing payment information etc Valdas Rapševičius. Web Services 18

19 SOAP Nodes A SOAP node must act in one or more SOAP roles. A SOAP header block can be specified to target at one particular SOAP role. A SOAP header block can be specified to require a SOAP node who is acting in the specified role "must understand". In this case, this SOAP node must process this header block. A SOAP ultimate node must process the body element. Any SOAP node can process any header blocks and/or the body element in any order. After processing the message, any SOAP node may generate a SOAP fault message in case of process error, or terminate the entire processing if needed. After processing the message, a SOAP intermediate node may relay the message to the next node, if needed Valdas Rapševičius. Web Services 19

20 SOAP intermediaries It must remove all processed header blocks. But it can reinsert them back into the message. It must remove all not-processed header blocks that specified as non-relayable. But it can reinsert them back into the message. It must retain all not-processed header block that specified as relayable. It may insert new header blocks. It may alter almost everything in the header element. It may not alter anything in the body element Valdas Rapševičius. Web Services 20

21 SOAP Message Example (1) <env:envelope xmlns:env=" <env:header> <authentication xmlns=" env:actor="urn:security" env:mustunderstand="1"> <user>jws</user> <password>jws</password> </authentication> </env:header> <env:body> <getquote xmlns=" <symbol>abbn</symbol> </getquote> </env:body> </env:envelope> Valdas Rapševičius. Web Services 21

22 SOAP Message Example (2) <?xml version="1.0"?> <env:envelope xmlns:env=" <env:header> <m:reservation xmlns:m=" env:role=" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q345-73pqff98fe8j7d</m:reference> <m:dateandtime> t13:20: :00</m:dateandtime> </m:reservation> <n:passenger xmlns:n=" env:role=" env:mustunderstand="true"> <n:name>herong Yang</n:name> </n:passenger> </env:header> <env:body> <p:itinerary xmlns:p=" <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate> </p:departuredate> <p:departuretime>late afternoon</p:departuretime> <p:seatpreference>aisle</p:seatpreference> </p:departure> </p:itinerary> <q:lodging xmlns:q=" <q:preference>none</q:preference> </q:lodging> </env:body> </env:envelope> Valdas Rapševičius. Web Services 22

23 Fault Messages Processing errors of a request are reported through SOAP faults in the body of the response message Default codes are VersionMismatch, MustUnderstand, Client Server Description of the error Causer of the error (optional) Error details (optional) Valdas Rapševičius. Web Services 23

24 SOAP Fault Example (1) <env:envelope xmlns:env=" <env:body> <env:fault> <faultcode>env:server</faultcode> <faultstring> NotFoundException: Symbol XXX not found </faultstring> <detail>...</detail> </env:fault> </env:body> </env:envelope> Valdas Rapševičius. Web Services 24

25 SOAP Fault Example (2) <?xml version='1.0'?> <env:envelope xmlns:env=" xmlns:rpc=' <env:body> <env:fault> <env:code> <env:value>env:sender</env:value> <env:subcode> <env:value>rpc:badarguments</env:value> </env:subcode> </env:code> <env:reason> <env:text xml:lang="en-us">processing error</env:text> <env:text xml:lang="fr-ca">error</env:text> </env:reason> <env:detail> <e:myfaultdetails xmlns:e=" <e:message>name does not match card number</e:message> <e:errorcode>999</e:errorcode> </e:myfaultdetails> </env:detail> </env:fault> </env:body> </env:envelope> Valdas Rapševičius. Web Services 25

26 Patterns: RPC vs Messaging Web services support the remote procedure call and the messaging paradigm Remote procedure call: invocation of remote code through specific interfaces synchronous request-response calls passing of application-level data structures Messaging: exchange of data or documents through generic interfaces asynchronous one-way communication queuing of messages Valdas Rapševičius. Web Services 26

27 WSDL Web Service Description Language Since 2000 by Microsoft, IBM and others Since 2003 as W3C spec Version 2.0 from 2007 WSDL is n XML language that is used to describe the interface of a web service WSDL is platform, protocol and programming language independent The WSDL document of a web service is published at a well-known URL or in a registry Provider tools can parse WSDL and generate the code necessary to implement or to access a web service Valdas Rapševičius. Web Services 27

28 WSDL Structure A WSDL document describes a web service in terms of the operations that the web service provides the data types that each operation requires by its input and output messages the binding that maps the input and output messages onto a protocol the address at which the service can be accessed Valdas Rapševičius. Web Services 28

29 WSDL 2.0 structure Valdas Rapševičius. Web Services 29

30 WSDL Example <description xmlns=" > <!-- Abstract type --> <types> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" </xs:schema> </types> <!-- Abstract interfaces --> <interface name="ifacename"> </interface> <!-- Concrete Binding --> <binding name="restfulinterfacesoapbinding" interface="tns:restfulinterface"> </binding> <!-- Web Service offering endpoints--> <service name="restfulservice" interface="tns:restfulinterface"> </service> </description> Valdas Rapševičius. Web Services 30

31 WSDL <description/> The <description> element is the root element of a WSDL document The name given to the web service is for documentation purpose only The target namespace determines to which namespace the elements belong used to describe the web service <description xmlns=" xmlns:tns=" xmlns:whttp=" xmlns:wsoap=" targetnamespace=" </description> Valdas Rapševičius. Web Services 31

32 WSDL: <import/> WSDL 1.1 allows flexible authoring styles via a single <wsdl:import> construct, which enables importing WSDL definitions defined in separate files with the same or different namespaces. In WSDL 2.0, following the XML schema model, in particular its visibility rules for <xsd:import> and <xs:include>, WSDL 2.0 defines two constructs: <wsdl:import>, for WSDL definitions with a different namespace, and <wsdl:include>, for WSDL definitions with the same namespace Valdas Rapševičius. Web Services 32

33 WSDL: <types/> The <types> element defines the data types that are used in the messages of the web service The data types should be defined using the XML schema language (either as abstract types or as elements) <types> <schema targetnamespace=" xmlns=" <complextype name="stockinfo"> <sequence> <element name="company" type="string"/> <element name="industry" type="string"/> <element name="valor" type="string"/> </sequence> </complextype>... </schema> </types> Valdas Rapševičius. Web Services 33

34 WSDL 1.1: <message/> The <message> elements define the messages used by the operations of the web service Each message may contain any number of part elements that represent an item of data The data type of a message part is declared by an element or a type attribute referencing a standard type or a userdefined type <message name="getquoterequest"> <part name="symbol" type="xsd:string"/> </message> <message name="getquoteresponse"> <part name="return" type="xsd:double"/> </message> <message name="notfoundexception"> <part name="fault" element="tns:notfoundexception"/> </message> Valdas Rapševičius. Web Services 34

35 WSDL 1.1: <porttype/> The <porttype> element defines the operations of a web service Each operation can have an input, an output and any number of fault messages <porttype name="stockquoter"> <operation name="getquote" parameterorder="symbol"> <input message="tns:getquoterequest"/> <output message="tns:getquoteresponse"/> <fault name="notfoundexception message="tns:notfoundexception"/> </operation>... </porttype> Valdas Rapševičius. Web Services 35

36 WSDL 2.0: <interface/> The abstract interface construct has been renamed from wsdl11:porttype to wsdl20:interface. Redesigned message definition mechanism. wsdl11:message and wsdl11:part constructs are completely removed. All messages are defined directly using a type language, such as XML Schema. Message definitions are referenced by operation input/output constructs directly. RPC style becomes a set of rules for abstract message definition. For easy mapping to a RPC signature, messages intended for use with RPC must be designed based on these rules. Added interface inheritance support. One interface can be derived from another interface. Faults are hoisted to be child of interface and made reusable by multiple operations. <interface name="restfulinterface"> <fault name="clienterror" element="tns:response"/> <fault name="servererror" element="tns:response"/> <fault name="redirection" element="tns:response"/> <operation name="get" pattern=" <input messagelabel="in" element="tns:request"/> <output messagelabel="out" element="tns:response"/> </operation> </interface> Valdas Rapševičius. Web Services 36

37 WSDL 1.1: MEPs The appearance and order of the input and output messages determine the type of an operation WSDL 1.1 has four transmission primitives that an endpoint can support: One-way. The endpoint receives a message. Request-response. The endpoint receives a message, and sends a correlated message. Solicit-response. The endpoint sends a message, and receives a correlated message. Notification. The endpoint sends a message Valdas Rapševičius. Web Services 37

38 WSDL 2.0: MEPs In-bound MEPs: In-Only This pattern consists of exactly one message received by a service from some other node. No fault may be generated. Robust In-Only This pattern can be considered as a variation of In-Only. It also consists of exactly one message received by a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. In-Out This pattern consists of exactly two messages: a message received by a service from some other node, followed by a message sent to the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. In-Optional-Out This pattern consists of one or two messages: a message received by a service from some other node, optionally followed by a message sent to the other node from the service. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model. Out-bound MEPs: Out-Only This pattern consists of exactly one message sent to some other node from a service. No fault may be generated. Robust Out-Only This pattern can be considered as a variation of Out-Only. It also consists of exactly one message sent to some other node from a service, but in this case faults can be triggered by the message as specified in the "Message Triggers Fault" model. Out-In This pattern consists of exactly two messages: a message sent to some other node from a service, followed by a message received by the service from the other node. The second message may be replaced by a fault as specified in the "Fault Replace Message" model. Out-Optional-In This pattern consists of one or two messages: a message sent to some other node from a service, optionally followed by a message received by the service from the other node. Each message may trigger a fault in response as specified in the "Message Triggers Faults" model Valdas Rapševičius. Web Services 38

39 WSDL: <binding/> The <binding> elements define for each port type how the input and output messages of its operations are mapped to concrete protocol messages The additional elements necessary for a concrete binding are defined by individual protocol specifications <binding name="restfulinterfacesoapbinding" interface="tns:restfulinterface" type=" wsoap:protocol=" wsoap:mepdefault=" <operation ref="tns:get" /> <operation ref="tns:post" /> <operation ref="tns:put" /> <operation ref="tns:delete" /> </binding> Valdas Rapševičius. Web Services 39

40 WSDL 1.1 SOAP binding: styles & uses A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This gives you four (5!) style/use models: RPC/encoded RPC/literal Document/encoded (nobody follows this style) Document/literal Document/literal wrapped Valdas Rapševičius. Web Services 40

41 WSDL 1.1 SOAP binding: Operation Styles The style of an operation determines how the SOAP messages are constructed from the WSDL description Document: the body contains one or more child elements that correspond to the parts of the corresponding message the part elements in the WSDL document point to schema elements, therefore the content of the message body can easily be validated RPC: the body consists of a single (wrapper) element named for the operation being invoked the wrapper element contains a child element for each parameter defined by the parts of the corresponding message Valdas Rapševičius. Web Services 41

42 WSDL 1.1 SOAP binding: Message Encoding The encoding rules of a message determines the serialization format of the message parts Encoded: data is serialized according to some encoding rules usually the SOAP section 5 rules the elements in the SOAP message carry explicit type qualification Literal: data is serialized according to a schema definition usually expressed in the XML schema language the types of the elements in the SOAP message implicitly rely on the schema Valdas Rapševičius. Web Services 42

43 WSDL 1.1 SOAP binding: Example <message name="mymethodrequest"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:float"/> </message> <message name="empty"/> <porttype name="pt"> <operation name="mymethod"> <input message="mymethodrequest"/> <output message="empty"/> </operation> </porttype> <binding> <soap:binding style="rpc document" transport=" <operation name="mymethod"> <soap:operation soapaction=""/> <input><soap:body use="encoded literal"/></input> <output><soap:body use="encoded literal"/></output> </operation> </binding> Valdas Rapševičius. Web Services 43

44 WSDL 1.1 SOAP binding: RPC/encoded <soap:envelope> <soap:body> <mymethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </mymethod> </soap:body> </soap:envelope> Strengths The WSDL is about as straightforward as it's possible for WSDL to be. The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation. Weaknesses The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance. You cannot easily validate this message since only the <x...>5</x> and <y...>5.0</y> lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions. Although it is legal WSDL, RPC/encoded is not WS-I compliant Valdas Rapševičius. Web Services 44

45 WSDL 1.1 SOAP binding: RPC/literal <soap:envelope> <soap:body> <mymethod> <x>5</x> <y>5.0</y> </mymethod> </soap:body> </soap:envelope> Strengths The WSDL is still about as straightforward as it is possible for WSDL to be. The operation name still appears in the message. The type encoding info is eliminated. RPC/literal is WS-I compliant. Weaknesses You still cannot easily validate this message since only the <x...>5</x> and <y...>5.0</y> lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions Valdas Rapševičius. Web Services 45

46 WSDL 1.1 SOAP binding: Document/literal <soap:envelope> <soap:body> <xelement>5</xelement> <yelement>5.0</yelement> </soap:body> </soap:envelope> <types> <schema> <element name="xelement" type="xsd:int"/> <element name="yelement" type="xsd:float"/> </schema> </types> <message name="mymethodrequest"> <part name="x" element="xelement"/> <part name="y" element="yelement"/> </message> Strengths There is no type encoding info. You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema. Document/literal is WS-I compliant, but with restrictions (see below). Weaknesses The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans. The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible. WS-I only allows one child of the soap:body in a SOAP message. As you can see in Listing 7, this example's soap:body has two children Valdas Rapševičius. Web Services 46

47 WSDL 1.1 SOAP binding: Document/literal wrapped <soap:envelope> <soap:body> <mymethod> <x>5</x> <y>5.0</y> </mymethod> </soap:body> </soap:envelope> Strengths <types> <schema> <element name="mymethod"> <complextype> <sequence> <element name="x" type="xsd:int"/> <element name="y" type="xsd:float"/> </sequence> </complextype> </element> <element name="mymethodresponse"> <complextype/> </element> </schema> </types> <message name="mymethodrequest"> <part name="parameters" element="mymethod"/> </message> <message name="empty"> <part name="parameters" element="mymethodresponse"/> </message> There is no type encoding info. Everything that appears in the soap:body is defined by the schema, so you can easily validate this message. Once again, you have the method name in the SOAP message. Document/literal is WS-I compliant, and the wrapped pattern meets the WS-I restriction that the SOAP message's soap:body has only one child. Weaknesses The WSDL is even more complicated Valdas Rapševičius. Web Services 47

48 WSDL 1.1 & 2.0 SOAP binding: Style & Use WSDL 1.1 RPC/encoded The standard way to send data graphs by using the href tag Document/literal wrapped Under most other situations WSDL 2.0 Everything is document/literal! Valdas Rapševičius. Web Services 48

49 WSDL 2.0 Nominal bindings SOAP binding Supports both SOAP 1.1 and SOAP 1.2. It has removed the confusing choice of Literal vs. Encoded and RPC vs. Document. Everything is document/literal in WSDL 2.0. Note that RPC community is not left alone. WSDL2.0 defines a set of rules for designing messages suitable for RPC calls. In addition, it provides a facility in the interface level to indicate that RPCfriendly message is in use by an operation. HTTP binding WSDL 2.0 HTTP binding supports any HTTP version and all HTTP method Note that WSDL 1.1 only support HTTP 1.1 GET and POST Valdas Rapševičius. Web Services 49

50 WSDL 2.0 HTTP binding <binding name="restfulinterfacehttpbinding" interface="tns:restfulinterface" type=" <operation ref="tns:get" whttp:method="get"/> <operation ref="tns:post" whttp:method="post" whttp:inputserialization="application/x-www-form-urlencoded"/> <operation ref="tns:put" whttp:method="put" whttp:inputserialization="application/x-www-form-urlencoded"/> <operation ref="tns:delete" whttp:method="delete"/> </binding> Valdas Rapševičius. Web Services 50

51 WSDL: <service/> A <port> (1.1) and <endpoint> (2.0) element maps a binding of a port type to a URI which can be used to access it A <service> element groups together a set of related ports <service name="restfulservice" interface="tns:restfulinterface"> <endpoint name="restfulservicehttpendpoint" binding="tns:restfulinterfacehttpbinding" address=" <endpoint name="restfulservicesoapendpoint" binding="tns:restfulinterfacesoapbinding" address=" </service> Valdas Rapševičius. Web Services 51

52 UDDI Universal Description, Discovery and Integration (UDDI) Since 2000 by OASIS A registry contains information that allows businesses to discover the web services of potential partners A provider company submits an entry to the registry and categorizes it by including links to technical specifications or marketing information An inquiring company searches the registry for information using various criteria like: White Pages address, contact, and known identifiers; Yellow Pages industrial categorizations based on standard taxonomies; Green Pages technical information about services exposed by the business Valdas Rapševičius. Web Services 52

53 Use Cases Business analysts use a marketplace or search portal to browse the businesses and services referenced by various registries Software developers use the registry's programming interface to publish or to discover services Valdas Rapševičius. Web Services 53

54 UBR The UDDI Business Registry (UBR) is a registry system built from multiple nodes that have their data synchronized through replication Content inserted into the UBR is done at a single node which becomes the master owner of that content Valdas Rapševičius. Web Services 54

55 UDDI Specifications UDDI defines the following set of specifications: UDDI Replication describes the data replication process and interfaces to which a registry operator must conform UDDI Operators outlines the behavior and operational parameters required by a node operator (e.g. data persistence, completeness and integrity) UDDI Programmer's API defines a set of functions for publishing and inquiring information about services hosted by the registry UDDI Data Structures covers the XML structures contained within the SOAP messages defined by the programmer's API Valdas Rapševičius. Web Services 55

56 UDDI Programmers API The UDDI programmer's specification describes two APIs which are accessed using the same techniques but different XML documents: Inquiry API locates information about a business, the services a business offers and the specifications of those services Publishing API is used to create, store or update information about a business and requires an authentication of the client usually accessed over HTTPS with a different URL than the inquiry API Valdas Rapševičius. Web Services 56

57 State of UDDI UDDI version 3 dates from htm OASIS committee that defined it has been disbanded. Registries: Microsoft, IBM and SAP shut down their public UDDI back in 2007 Software JUDDI: Last touched Nov, 2010 as Release Valdas Rapševičius. Web Services 57

58 Modern Registries Valdas Rapševičius. Web Services 58

59 Conclusions SOAP is very popular SOA Enterprise-level applications WSDL Metadata Most valuable spec along with SOAP UDDI is dead (?) just as ebxml (last news from 24 April 2006) Valdas Rapševičius. Web Services 59