Brief discussion on Server-side developmet-Part01


In this blog I'm going to discuss about web services, WSDL and SOAP.

 Web Applications VS Web Services

 First let's move in to Web services.
Web services are server-side application components.A Web service involves a service provider and a service requester (client). Because Web services feature language transparency, it doesn’t matter whether the underlying system that provides the service is written in Java while the client is written in Perl, Python or Ruby. For example, through Web services a Windows server can interact with a Linux server or serve an application to computer desktops, laptops or smart phones and other mobile devices over the WWW.

 SOAP, UDDI, WSDL are the main components of web services.

 Web Application

A Web Application or Web App is Software that runs on a Web Server. Unlike traditional desktop applications, which are launched by a Web Browser.
In order to access/use any Software Application (Desktop or Web Application) Operating System is required/mandatory.
If it is Desktop Application like Notepad or Acrobat Reader we can launch those applications from the Operating System, just switch on the Computer, and after booting the System we can operate Desktop Applications. If it is Web Application Boot the System, launch a Browser and navigate to Web Application by typing the URL of the Web Application in the Browser Address bar, then access the Application, at end close the browser.
Here are difference between them.



WSDL

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port typeswhich are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:
  • 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.
These elements are described in detail in Section 2. It is important to observe that WSDL does not introduce a new type definition language. WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) as its canonical type system. However, since it is unreasonable to expect a single type system grammar to be used to describe all message formats present and future, WSDL allows using other type definition languages via extensibility.
In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.
In addition to the core service definition framework, this specification introduces specific binding extensions for the following protocols and message formats:
  • SOAP
  • HTTP GET / POST
  • MIME
Although defined within this document, the above language extensions are layered on top of the core service definition framework. Nothing precludes the use of other binding extensions with WSDL.


WSDL Document Structure

A WSDL document is simply a set of definitions. There is a definitions element at the root, and definitions inside. The grammar is as follows:

<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>

    <import namespace="uri" location="uri"/>*

    <wsdl:documentation .... /> ?

    <wsdl:types> ?
        <wsdl:documentation .... />?
        <xsd:schema .... />*
        <-- extensibility element --> *
    </wsdl:types>

    <wsdl:message name="nmtoken"> *
        <wsdl:documentation .... />?
        <part name="nmtoken" element="qname"? type="qname"?/> *
    </wsdl:message>

    <wsdl:portType name="nmtoken">*
        <wsdl:documentation .... />?
        <wsdl:operation name="nmtoken">*
           <wsdl:documentation .... /> ?
           <wsdl:input name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:input>
           <wsdl:output name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:output>
           <wsdl:fault name="nmtoken" message="qname"> *
               <wsdl:documentation .... /> ?
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="nmtoken" type="qname">*
        <wsdl:documentation .... />?
        <-- extensibility element --> *
        <wsdl:operation name="nmtoken">*
           <wsdl:documentation .... /> ?
           <-- extensibility element --> *
           <wsdl:input> ?
               <wsdl:documentation .... /> ?
               <-- extensibility element -->
           </wsdl:input>
           <wsdl:output> ?
               <wsdl:documentation .... /> ?
               <-- extensibility element --> *
           </wsdl:output>
           <wsdl:fault name="nmtoken"> *
               <wsdl:documentation .... /> ?
               <-- extensibility element --> *
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="nmtoken"> *
        <wsdl:documentation .... />?
        <wsdl:port name="nmtoken" binding="qname"> *
           <wsdl:documentation .... /> ?
           <-- extensibility element -->
        </wsdl:port>
        <-- extensibility element -->
    </wsdl:service>

    <-- extensibility element --> *

</wsdl:definitions>



Services are defined using six major elements:
  • types, which provides data type definitions used to describe the messages exchanged.
  • message, which represents an abstract definition of the data being transmitted. A message consists of logical parts, each of which is associated with a definition within some type system.
  • portType, which is a set of abstract operations. Each operation refers to an input message and output messages.
  • binding, which specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType.
  • port, which specifies an address for a binding, thus defining a single communication endpoint.
  • service, which is used to aggregate a set of related ports.

We describe the rules introduced by WSDL for naming documents, referencing document definitions, using language extensions and adding contextual documentation.

PortType vs operation elements in WSDL

First let's talk about porttype element.

The <portType> element combines multiple message elements to form a complete one-way or round-trip operation.
For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.
Let us take an Example;
<portType name = "Hello_PortType">
   <operation name = "sayHello">
      <input message = "tns:SayHelloRequest"/>
      <output message = "tns:SayHelloResponse"/>
   </operation>
</portType>
  • The portType element defines a single operation, called sayHello.
  • The operation consists of a single input message SayHelloRequest 
  • output message SayHelloResponse.

Operation element
 

Binding element and service element in WSDL

The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.
  • The bindings can be made available via multiple transports including HTTP GET, HTTP POST, or SOAP.
  • The bindings provide concrete information on what protocol is being used to transfer portType operations.
  • The bindings provide information where the service is located.
  • For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.
  • You can specify multiple bindings for a single portType.
The binding element has two attributes : name and type attribute.
<binding name = "Hello_Binding" type = "tns:Hello_PortType">
The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this case the "tns:Hello_PortType" port.

The <service> element defines the ports supported by the web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.
    1. Web service clients can learn the following from the service element :
      •     where to access the service,
      •     through which port to access the web service, and
      •     how the communication messages are defined.
    2.  The service element includes a documentation element to provide human-readable documentation.
Here is an Example 
<service name = "Hello_Service">
   <documentation>WSDL File for HelloService</documentation>
   <port binding = "tns:Hello_Binding" name = "Hello_Port">
      <soap:address
         location = "http://www.examples.com/SayHello/">
   </port>
</service>
The binding attributes of port element associate the address of the service with a binding element defined in the web service. In this example, this is Hello_Binding
<binding name =" Hello_Binding" type = "tns:Hello_PortType">
   <soap:binding style = "rpc"
      transport = "http://schemas.xmlsoap.org/soap/http"/>
   <operation name = "sayHello">
      <soap:operation soapAction = "sayHello"/>
		
      <input>
         <soap:body
            encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
            namespace = "urn:examples:helloservice" use = "encoded"/>
      </input>
			
      <output>
         <soap:body
            encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
            namespace = "urn:examples:helloservice" use = "encoded"/>
      </output>
   </operation>
</binding>

 

SOAP


SOAP is an acronym for Simple Object Access Protocol. It is an XML-based messaging protocol for exchanging information among computers. SOAP is an application of the XML specification.
  • SOAP is a communication protocol designed to communicate via Internet.
  • SOAP can extend HTTP for XML messaging.
  • SOAP provides data transport for Web services.
  • SOAP can exchange complete documents or call a remote procedure.
  • SOAP can be used for broadcasting a message.
  • SOAP is platform- and language-independent.
  • SOAP is the XML way of defining what information is sent and how.
  • SOAP enables client applications to easily connect to remote services and invoke remote methods.
Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.
Other frameworks including CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.


A SOAP based web service message is a hierarchical XML packet, consisting of up to four parts.
  1. Envelope
  2. Header
  3. Body
  4. Fault
SOAP Message Structure:

Soap Envelope

The root element of the XML packet is called the envelope. An envelope is a mandatory element in a SOAP Message. It defines a namespace ending with soap dash envelope. And associates it with a namespace prefix. The prefix can be anything. In some examples, we have seen it named soap, in other others soapenv, or as in this example, just env. What’s important, is that it points to the correct namespace, that identifies the version of SOAP that’s being used.

SOAP message Header

The XML envelope, defines two child elements named header and body. When we look at the schema [http://schemas.xmlsoap.org/soap/envelope/], We’ll see that there is an attribute called minoccurs, that indicates whether each is required. Zero would mean optional, meaning there is no minimum, and one means required. So, in a SOAP envelope, the header element is optional, but the body is required. If the message contains a header, it shows up as the first child element of the Envelope.
The header contains metadata, It can contain documentation about the particular soap message and any other elements a developer might like to include. Some common uses of the soap header, include API keys, or log-in credentials to validate requests, or timestamps in responses indicating when data was created, or how long it’s good for.
SOAP message Body
The body element is required in both the request and the response envelope And it contains the actual content of either the request or the response. A request message typically defines a namespace that’s again unique to the web service being called.
The child element in the body, getStockPrice, is the name of a remote procedure that’s defined by the service. And the operation then has child elements, representing parameters that are being passed in. This operation, or procedure, has a single parameter, arg0, set to the value Google. The names of the web services procedures, and the names and data types of each procedure’s parameters, are defined in the service’s WSDL document.
The response message also has a route envelope element. Like the request, it declares a namespace indicating the SOAP version and the body has a namespace that’s unique to the web service. These should always match the namespaces in the request. If the call to the remote operation succeeds, the response message can be as simple as an envelope that contains a body. And then resulting data within the body.
In this example, the response is an element named getStockPriceResponse. That element contains a child element named return, which contains the resulting numeric value. As with the request, the data type of that value, whether it’s a string, integer, float or other. Is defined in the service’s WSDL document.
SOAP message fault
If the request fails for any reason, the server sends back a response containing a Fault element which is a child element of the body. The body typically contains either valid response data or a fault, but not both.
In SOAP, the Fault element has a number of child elements with fixed names, including Code, Reason, Role, and Detail. These are the names of the elements in SOAP 1.2. In SOAP 1.1, they’re somewhat different. The Code value can be one of a number of fixed values. In SOAP 1.2, the value sender means that the client sent a malformed request message, that had an error, such an unrecognized operation name, or incorrect data types. But it can also be receiver.

SOAP Advantages and Disadvantages

SOAP is an integral part of the service-oriented architecture (SOA) and the Wen services specifications associated with SOA. Because it allows the sender to create a message route based on the logical services that have to be applied to the message on the way to its destination, it lends itself to providing secure and compliant connections, controlling access, offering reliable delivery and failure recovery, and supporting dynamic service discovery. SOA without SOAP is difficult to imagine.
SOAP’s messages are defined at a high level in XML, but most SOAP applications use Web Services Definition Language (WSDL), which is authored in XML.  The XML structure of SOAP makes it handy for applications that expect their information to be provided in XML form, and the fact that SOAP can ride on a variety of network protocols, including HTTP, means it’s easily passed through firewalls, where other protocols might require special accommodation.
The data structure of SOAP is based on XML, which is similar in many ways to the HTML used to define web pages. Like HTML, XLM is largely human-readable, which makes it fairly easy to understand a SOAP message, but also makes the messages relatively large in comparison to the Common Object Request Broker Architecture (COBRA) and its Remote Procedure Call (RPC) protocol that will accommodate binary data.
The biggest disadvantage of SOAP (and SOA overall) is that it’s a heavyweight protocol for a heavyweight architecture.  The notion of a message passing through a string of nodes to be processed by each seems to mix protocols and service bus architectural models for software, and neither of those two are considered optimal for microservice-based development as popularly used today.

Frameworks for SOAP web service development



Annotations in JAX-WS

  1. @WebService:
  2. @SOAPBinding
  3. @WebMethod
  4. @WebResult
  5. @WebServiceClient
  6. @RequestWrapper
  7. @ResponceWrapper
  8. @Oneway
  9. @HandlerChain

REFERENCES


https://examples.javacodegeeks.com/enterprise-java/jws/jax-ws-annotations-example/
https://en.wikipedia.org/wiki/List_of_web_service_frameworks
https://searchmicroservices.techtarget.com/definition/SOAP-Simple-Object-Access-Protocol
https://www.tutorialspoint.com/wsdl/
https://www.w3.org/TR/2001/NOTE-wsdl-20010315
https://www.quora.com/What-is-web-application
 https://www.techopedia.com/definition/25301/web-service 






Comments

Post a Comment

Popular posts from this blog

How to run multiple Transformations from one Job in Pentaho

Image
In this article I am going to talk about how to run multiple transformations from one job using Pentaho. I hope you'll know about pentaho, transformations and jobs. This article include two ways of doing the same process. one method is simple, easy but not much efficient way. However, the second method is more efficient and success way. First,let's talk about the easy method, This is the the most common method that you can find from the internet. And also, this is very easy method that fulfill the requirement of running multiple transformations from one job.  Let me share an example of this approach and discuss how we are going create this job and the drawbacks of this method. Fig 01: Easy method for run multiple transformations at once As you can see in above image, There are 4 transformations connected with the start and when run the   above job all of the execute and run sequentially. If you need to run all of the together in parallel, you can change the settings ...
Read more

Data Analytics

Image
                        What is Data Analytics? As the process of analyzing raw data to find trends and answer questions, the definition of data analytics captures its broad scope of the field. However, it includes many techniques with many different goals. The data analytics process has some key components that are needed for any initiative. By combining these components, a successful data analytics initiative will provide a clear picture of where you are, where you have been and where you should go. Generally, this process begins with  descriptive analytics . This is the process of describing historical trends in data. Descriptive analytics aims to answer the question “what happened?” This often involves measuring traditional indicators such as return on investment (ROI). The indicators used will be different for each industry. Descriptive analytics does not make predictions or directly inform decisions. It...
Read more

Distributed Systems

Image
Difference between distributed systems and distributed computing Distributed systems and distributed computing are looks like same. But they slightly different from each other. So let’s talk about them. In Distributed- computing there are multiple computing units connected to achieve a common task. When considering a single unit, larger computing power enables lot of tasks to be perform. And also searches can be coordinated for efficiency, Successes usually give the finder credit. Distributed computing projects include hunting large prime number, and analysing DNA codes. A Distributed system includes a collection of autonomous computers, connected through a network and distribution middleware, which enables computers to coordinate their activities and to share the resources of the system, so that users perceive the system as a single, integrated computing facility. So hope you can now understand the differences. Standalone system VS Distributed system ...
Read more