1.What is Web Service?
2.What is WSDL?
3.What is WSDL and DISCO file?
4.What are ends, contract, address, and bindings?
5.What is the Difference between abstract and concrete WSDL?
9.What is the difference between Async and Sync activity on wsdl level?
10.What is the significance of target Namespace in a wsdl?
11.Why do we need to have messages in WSDL, aren't operations and types enough to describe the parameters for a web service?
12.What is the difference between RPC and Document Type?
Web service is a piece of code which is available on web (internet). That code of piece can be developed in any language (java, .net etc). A client invokes the web service by sending xml message and it wait for xml response (synchronously or asynchronously).
The Web Services Description Language (WSDL) is an XML-based grammar that defines the operations that a web service offers and the format of the request and response messages that the client sends to and receives from the operations. The request and response messages define the names and types of the data that the client exchanges with the operation. You can build a web service client on any platform and in any language that supports web services.
WSDL: Files with the WSDL extension contain web service interfaces expressed in the Web Service Description Language (WSDL). WSDL is a standard XML document type specified by the World Wide Web Consortium.WSDL files are used to communicate interface information between web service producers and consumers. A WSDL description allows a client to utilize a web service capabilities without knowledge of the implementation details of the web service.
Disco: It is a Microsoft technology for publishing and discovering Web Services. DISCO can define a document format along with an interrogation algorithm, making it possible to discover the Web Services exposed on a given server. DISCO makes it possible to discover the capabilities of each Web Service (via documentation) and how to interact with it. To publish a deployed Web Service using DISCO, you simply need to create a .disco file and place it in the vroot along with the other service-related configuration.
Disco: It is a Microsoft technology for publishing and discovering Web Services. DISCO can define a document format along with an interrogation algorithm, making it possible to discover the Web Services exposed on a given server. DISCO makes it possible to discover the capabilities of each Web Service (via documentation) and how to interact with it. To publish a deployed Web Service using DISCO, you simply need to create a .disco file and place it in the vroot along with the other service-related configuration.
These three terminologies on which SOA service stands. Every service must expose one or more ends by which the service can be available to the client. End consists of three important things where, what and how:-
- Contract (What) : Contract is an agreement between two or more parties. It defines the protocol how client should communicate with your service. Technically, it describes parameters and return values for a method
- Address (Where) : An Address indicates where we can find this service. Address is a URL, which points to the location of the service.
- Binding (How) : Bindings determine how this end can be accessed. It determines how communications is done. For instance, you expose your service, which can be accessed using SOAP over HTTP or BINARY over TCP. So for each of these communications medium two bindings will be created.
Below figure, show the three main components of end. You can see the stock ticker is the service class, which has an end hosted on www.soa.com with HTTP and TCP binding support and using Stock Ticker interface type.
Figure: - Endpoint Architecture
Note: You can also remember the end point by ABC where A stands for Address, B for bindings and C for Contract.
An abstract WSDL document describes what the web service does, but not how it does it or how to contact it. The abstract WSDL document contains the types, the message, and the portType elements. It describes the service's interface and the messages exchanged by the service. Within the types element, XML Schema is used to define the structure of the data that makes up the messages. A number of message elements are used to define the structure of the messages used by the service. The portType element contains one or more operation elements that define the messages sent by the operations exposed by the service.
The concrete WSDL document contains the binding and the service elements. It describes how an endpoint that implements the service connects to the outside world. The binding elements describe how the data units described by the message elements are mapped into a concrete, on-the-wire data format, such as SOAP. The service elements contain one or more port elements which define the endpoints implementing the service.
The concrete WSDL document contains the binding and the service elements. It describes how an endpoint that implements the service connects to the outside world. The binding elements describe how the data units described by the message elements are mapped into a concrete, on-the-wire data format, such as SOAP. The service elements contain one or more port elements which define the endpoints implementing the service.
Figure: - WSDL
6.What are the WSDL Document Elements?
A WSDL document is made up of the following elements:
- definitions: The root element of a WSDL document. The attributes of this element specify the name of the WSDL document, the document's target namespace, and the shorthand definitions for the namespaces referenced in the WSDL document
- types: The XML Schema definitions for the data units that form the building blocks of the messages used by a service.
- message: The description of the messages exchanged during invocation of a services operations. These elements define the arguments of the operations making up your service.
- operation: An abstract description of the action supported by the service.
- portType: An abstract set of operations supported by one or more endpoints.
- binding: Describes how the operation is invoked by specifying concrete protocol and data format specifications for the operations and messages.
- service: Specifies the port address(es) of the binding. The service is a collection of network endpoints or ports.
- port: Specifies a single endpoint as an address for the binding, thus defining a single communication endpoint.
WSDL 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.
Concrete wsdl is the client side rather run time wsdl which has the information like binding,endpoint where as abstract wsdl is the design wsdl. client wsdl is sufficient to proceed with the build since it removes the dependency that the service should be deployed and ready before starting the build. Also same abstract can be used for multiply binding with different concrete wsdl this removes the code redundancy. Also in SOA perspective, abstract wsdl should be used rather than the concrete since when the process loads there will dependency across the calling services if the callee service didn't load before the caller service then the service state will be unknown in SOA. To avoid this if we use abstract wsdl all the process loads normally and the concrete binding will be used only when it starts receiving the request.
Async wsdl - It has only input messages for the operation and it has 2 operations one for sending the request and other for call back.Sync wsdl - It has 2 messages input and output messages for the wsdl operation.
It is the one which uniquely identifies the WSDL and when the WSDL is used it should be identified using its Target Namespace.
Messages consist of one or more logical parts. Each part is associated with a type from some type system using a message-typing attribute. The set of message-typing attributes is extensible. The element describes the data being exchanged between the Web service providers and consumers. Each Web Service has two messages: input and output. The input describes the parameters for the Web Service and the output describes the return data from the Web Service. Each message contains zero or more parameters, one for each parameter of the Web Service's function. Each parameter associates with a concrete type defined in the container element. So describing the parameters cannot performed by operations and types this is the main need of Messages.
A web service is usually described by a WSDL (Web Services Description Language) document. In this document, the supported web service operations and messages are described abstractly and then bound to a concrete network protocol and message format. A typical WSDL document consists of the following elements: "types," "message," and "portType" for the abstract definitions; "binding" and "service" for the concrete specification. All of these elements are wrapped inside a "definitions" element.
In the context of RPC and document style, it is the binding element that we need to take a closer look at. A WSDL binding describes how the service is bound to a messaging protocol, either HTTP GET/POST, MIME, or SOAP. In practice, SOAP is the most universally used protocol; it is SOAP that the RPC/document distinction refers to. Usually HTTP(S) is used as transport protocol for the SOAP message - "SOAP over HTTP(S)."
The <wsdl:binding> element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal). See how style and use are defined in the WSDL fragment below:
In the context of RPC and document style, it is the binding element that we need to take a closer look at. A WSDL binding describes how the service is bound to a messaging protocol, either HTTP GET/POST, MIME, or SOAP. In practice, SOAP is the most universally used protocol; it is SOAP that the RPC/document distinction refers to. Usually HTTP(S) is used as transport protocol for the SOAP message - "SOAP over HTTP(S)."
The <wsdl:binding> element of the WSDL contains a pair of parameters that influence the form of the resulting SOAP messages: binding style (RPC or document) and use (encoded or literal). See how style and use are defined in the WSDL fragment below:
01. <wsdl:binding name="Config1Binding" type="prt0:CreditLimitLocalWebServiceVi_Document"> 02. <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> 03. <wsdl:operation name="creditLimitCheck"> 04. <soap:operation soapAction="" /> 05. <wsdl:input > 06. <soap:body use="literal" use="parameters"/> 07. </wsdl:input > 08. <wsdl:output > 09. <soap:body use="literal" /> 10. </wsdl:output > 11. </wsdl:operation > 12.</wsdl:binding >
The "Style" Attribute
WSDL 1.1 specifies the style of the binding as either RPC or document. This choice corresponds to how the SOAP payload - i.e., how the contents of the <soap:Body> element - can be structured. Here are some details of how each style affects the contents of <soap:Body>:
WSDL 1.1 specifies the style of the binding as either RPC or document. This choice corresponds to how the SOAP payload - i.e., how the contents of the <soap:Body> element - can be structured. Here are some details of how each style affects the contents of <soap:Body>:
- Document: the content of <soap:Body> is specified by XML Schema defined in the <wsdl:type> section. It does not need to follow specific SOAP conventions. In short, the SOAP message is sent as one "document" in the <soap:Body> element without additional formatting rules having to be considered. Document style is the default choice.
- RPC: The structure of an RPC style <soap:Body> element needs to comply with the rules specified in detail in Section 7 of the SOAP 1.1 specification. According to these rules, <soap:Body> may contain only one element that is named after the operation, and all parameters must be represented as sub-elements of this wrapper element.
As a consequence of the freedom of choice that the document style offers, the SOAP messages conforming to a document style WSDL may look exactly the same as the RPC equivalent. The decisive question now is: What are the consequences of choosing one option or another? Why choose RPC over document, or document over RPC? In many cases, the SOAP messages generated from either RPC or document style WSDLs look exactly the same - so why offer the choice at all? The reason may be found in the history of the SOAP standard.
SOAP has its roots in synchronous remote procedure calls over HTTP and the appearance of the document accordingly followed these conventions. Later, it was seen as a simplification to use arbitrary XML in the SOAP body without adhering to conventions. This preference is reflected in the document style WSDL documents. So far, both options are represented in the WSDL specification and the choice of one or the other is mainly a question of personal taste since most SOAP clients today accept both versions.
The "Use" Attribute
The use attribute specifies the encoding rules of the SOAP message. This is also done within the <wsdl:binding> element, as seen in the example above. The value can be encoded or literal. It refers to the serialization rules followed by the SOAP client and the SOAP server to interpret the contents of the <Body> element in the SOAP payload.
SOAP has its roots in synchronous remote procedure calls over HTTP and the appearance of the document accordingly followed these conventions. Later, it was seen as a simplification to use arbitrary XML in the SOAP body without adhering to conventions. This preference is reflected in the document style WSDL documents. So far, both options are represented in the WSDL specification and the choice of one or the other is mainly a question of personal taste since most SOAP clients today accept both versions.
The "Use" Attribute
The use attribute specifies the encoding rules of the SOAP message. This is also done within the <wsdl:binding> element, as seen in the example above. The value can be encoded or literal. It refers to the serialization rules followed by the SOAP client and the SOAP server to interpret the contents of the <Body> element in the SOAP payload.
- use="literal" means that the type definitions literally follow an XML schema definition.
- use="encoded" refers to the representation of application data in XML, usually according to the SOAP encoding rules of the SOAP 1.1 specification. The rules to encode and interpret a SOAP body are in a URL specified by the encodingStyle attribute. Encoded is the appropriate choice where non-treelike structures are concerned, because all others can be perfectly described in XML Schema.
The combination of the style and use attributes leads to four possible style/use pairs:
- RPC/encoded
- RPC/literal
- document/encoded
- document/literal
Some of these combinations are rarely used in practice, such as document/encoded. In general, the literal use is gaining importance, and as far as RPC/encoded is concerned, the Web Services Interoperability Organization (WS-I) in its Basic Profile Version 1.0a of August 2003 ruled out the use of SOAP encoding with web services. Document/literal and RPC/literal will be the only allowed style/use combinations in the future.
No comments:
Post a Comment