click below
click below
Normal Size Small Size show me how
3) WSDL & UUID
WSDL & UUID
Question | Answer |
---|---|
Why a Service Description is Needed? | Service description + SOAP infrastructure isolates all technical details, e.g., machine- and implementation language-specific elements, away from the service requestor’s application and the service provider’s Web service. |
WSDL | The web services description language (WSDL) is the XML-based service representation language used to describe the details of the complete interfaces exposed by Web services and thus is the means to accessing a Web service. |
Structure of WSDL documents | 1) service-interface definition 2) service implementation part |
Service-Interface Definition | (abstract interface) describes the general Web service interface structure. This contains all the operations supported by the service, the operation parameters, and abstract data types. |
Service Implementation Part | (concrete endpoint) binds the abstract interface to a concrete network address, to a specific protocol, and to concrete data structures. |
Abstract (interface) definitions | – <types> data type definitions – <message> operation parameters – <operation> abstract description of service actions – <portType> set of operation definitions |
Concrete (implementation) definitions | – <binding> operation bindings – <port> association of an endpoint with a binding – <service> location/address for each binding |
WSDL <types> element | serves as a container that contains all abstract data types that define a Web service interface. A <type> element in WSDL is comparable to a data type in Java or C++. |
<message> | The <message> element describes the payload of a message used by a web service. A message consists of <part> elements, which are linked to <types> elements. |
(Data) Types | The types element describes all the data types used between the client and the server.If the service uses only XML Schema built-in simple types, such as strings and integers, then types element is not required. |
Message | It is an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation of the data being communicated. |
Operation | It is the abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message. |
Port Type | It is an abstract set of operations mapped to one or more end-points, defining the collection of operations for a binding; the collection of operations, as it is abstract, can be mapped to multiple transports through various bindings. |
Definition | It is the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document, and contains all the service elements described here. |
Binding | element provides specific details on how a portType operation will actually be transmitted over the wire. - can be made available via multiple transports including HTTP GET, HTTP POST, or SOAP. |
Port | It is a combination of a binding and a network address, providing the target address of the service communication. -element defines an individual endpoint. The name attribute provides a unique name among all ports. |
Service | It is a collection of related end-points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions. The <service> element defines the ports supported by the web service. |
Documentation | This element is used to provide human-readable documentation and can be included inside any other WSDL element. |
Import | This element is used to import other WSDL documents or XML Schemas. |
targetNamespace | specifies a targetNamespace attribute. The targetNamespace is a convention of XML Schema that enables the WSDL document to refer to itself. |
default nameSpace | specifies a default namespace: xmlns= All elements without a namespace prefix are therefore assumed to be a part of the default WSDL namespace. |
Part | Each message contains zero or more <part> parameters, one for each parameter of the web service function. Each <part> parameter associates with a concrete type defined in the <types> container element. |
WSDL Patterns of Operation | 1) One-way 2) Request - Response 3) Solicit - response 4) Notification |
soap:binding | indicates binding available via SOAP. A style value of rpc specifies an RPC format. The transport attribute indicates the transport of the SOAP messages. The value indicates the SOAP HTTP transport(or SMTP) |
soap:operation | This element indicates the binding of a specific operation to a specific SOAP implementation. The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the service. |
soap:body | This element enables you to specify the details of the input and output messages. The body element specifies the SOAP encoding style and the namespace URN associated with the specified service. |
UDDI | UDDI is an XML-based standard for describing, publishing, and finding Web services. not restricted to describing SOAP. Rather, UDDI can be used to describe any service, from a single webpage or email address all the way up to SOAP, CORBA, and Java RMI |
SOAP | SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP. |
Service registry | 1) The document-based registry 2) meta-data-based service registry |
The document-based registry | enables its clients to publish information, by storing XML-based service documents such as business profiles or technical specifications (including WSDL descriptions of the service). |
The meta-data-based service registry | captures the essence of the submitted document. |
Types of service discovery | 1) Static 2) Dynamic |
Static Registry | The service implementation details (network location and protocol) are bound at design time, performed on a service registry. The results of the retrieval operation are examined usually by a human designer, incorporated into the application logic. |
Dynamic Registry | Based on application logic quality of service considerations such as best price, performance, security certificates, and so on, the application chooses the most appropriate service, binds to it, and invokes it. |
UDDI: white pages | address, contact, and other key points of contact |
UDDI: yellow pages | classification info. based on standard industry taxonomies; and |
UDDI: green pages | the technical capabilities and information about services. |