Web Services Terminology

***service-oriented architecture***

A set of components which can be invoked, and whose interface descriptions

can be published and discovered.

Service-Oriented Architecture (SOA) is a set of principles and methodologies for

designing and developing software in the form of interoperable services.

These services are well-defined business functionalities that are built as

software components (discrete pieces of code and/or data structures) that can be

reused for different purposes. SOA design principles are used during the phases

of systems development and integration.

The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the

right sending a service request message to a service provider at the left. The service provider returns a

response message to the service consumer. The request and subsequent response connections are

defined in some way that is understandable to both the service consumer and service provider.

Web-based VS Web Services

  
Web ServicesComponents

1) XML
2) XSD
3) WSDL
4)SOAP
5)UDDI

The steps involved in providing and consuming a web service are:
A service provider describes its service using WSDL. This definition is published to a
directory of services. The directory could use Universal Description, Discovery, and Integration
(UDDI). Other forms of directories can also be used.
A service consumer issues one or more queries to the directory to locate a service and determine how to
communicate with that service.
Part of the WSDL provided by the service provider is passed to the service consumer. This tells the
service consumer what the requests and responses are for the service provider.
The service consumer uses the WSDL to send a request to the service provider.
The service provider provides the expected response to the service consumer.

Typical Web service Flow

Why SOA?

*Reusability : - 

 Developers within an enterprise and across enterprises (particularly, in business partnerships) can take the code developed for existing business applications, expose it as web services, and then reuse it to meet new business requirements.

*Interoperability : -

The objective is for clients and services to communicate and understand each other no matter what platform they run on.

*Scalability : - 

 Because services in an SOA are loosely coupled, applications that use these services tend to scale easily -- certainly
more easily than applications in a more tightly-coupled environment. That's because there are few dependencies between the requesting application and the services it uses

*Flexibility : - 

 Loosely-coupled services are typically more flexible than more tightly-coupled applications. In a tightly-coupled
architecture, the different components of an application are tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application to keep up with changing business requirements. The loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.

*Cost Efficiency : - 

 Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and
department-specific solutions are expensive because they tend to tie these components together in a customized way. Customized solutions are costly to build because they require extensive analysis, development
time, and effort. They're also costly to maintain and extend because they're typically tightly-coupled, so that changes in one component of the integrated solution require changes in other components. A standards-based approach such as a web services-based SOA should result in less costly solutions because the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because services in an SOA are
loosely-coupled, applications that use these services should be less costly to maintain and easier to extend than customized solutions.

***Web Service***

A Web service is a method of communication between two electronic devices over the web (internet).It's and implementation of SOA Architecture. We can identify two major classes of Web services.

*REST -compliant Web services
*SOAP - WS compliant Web services

*Endpoint : -

 An association between a binding and a network address, specified by a URI, that may be used to communicate with an instance of a service. An end point indicates a specific location for accessing a service using a specific protocol and data format.

An endpoint is the entry point for such a SOA implementation. The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet
protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available.

Web services instead share business logic, data and processes through a programmatic interface across a network.

Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system
or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.

Web services do not require the use of browsers or HTML.Web services are sometimes called application services.

***Styles of use***

Web services are a set of tools that can be used in a number of ways. The three most common styles of use are RPC, SOA and REST. 
 

 ***Remote procedure calls***

The basic unit of RPC Web services is the WSDL operation. The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticized for not being loosely coupled, because it was often implemented by mapping services directly to language-specific functions or method calls.

 ***Service-oriented architecture***

Web services can also be used to implement an architecture according to service-oriented architecture (SOA) concepts, where the basic unit of communication is a message, rather than an operation. This is often referred to as "message-oriented" services.

***Representational state transfer (REST)***

 REST attempts to describe architectures that use HTTP or similar protocols by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP). Here, the focus is on interacting with stateless resources, rather than messages or operations. Clean URLs are tightly associated with the REST concept.
 

 ***SOAP***

SOAP is an XML-based protocol for exchanging information in a distributed environment. SOAP provides a common message format for exchanging data between clients and services. The basic item of transmission in SOAP is a SOAP message, which consists of a mandatory SOAP envelope, an optional SOAP header, and a
mandatory SOAP body. The envelope specifies two things: an XML namespace and an encoding style. The XML namespace specifies the names that can be used in the SOAP message. Namespaces are designed to avoid name clashes -- the same name can be used for different items, provided that the names are in different namespaces. The encoding style identifies the data types recognized by the SOAP message. If a header is provided, it extends the SOAP message in a modular way. It's important to understand that as a SOAP message travels from a client to a service, it can pass through a set of intermediate nodes along the message path. Each node is an application that can receive and forward SOAP messages. An intermediate node can provide additional services such as transform the data in the
message or perform security-related operations. The SOAP header can be used to indicate some additional processing at an intermediate node, that is, processing independent of the processing done at the final destination. Typically, the SOAP header is used to convey security-related information to be processed by runtime components. The body contains the main part of the SOAP message, that is, the part intended for the final recipient of the SOAP message.

SOAP Messages

Sample SOAP Request

<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"

                xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

                <SOAP-ENV:Body>

                                <EmployeeRequest xmlns="http://employee.com/schema">

                                                <Employee>

                                                                <employeeId>1234</employeeId>

                                                </Employee>

                                </EmployeeRequest>

                </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Sample SOAP Response

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Body>
        <sch:EmployeeResponse xmlns:sch="http://employee.com/schema">
            <sch:EmployeeDetails>
                <sch:name>Balaji</sch:name>
                <sch:salary>5000</sch:salary>
                <sch:dept>HR</sch:dept>
                <sch:designation>SE</sch:designation>
            </sch:EmployeeDetails>
        </sch:EmployeeResponse>
    </soapenv:Body>
</soapenv:Envelope>

***WSDL***

How does a client know what format to use in making a request to a service? For that matter, how do the client and the service know what the request means? The answers to these questions are provided by information in an XML document, called a WSDL document, that contains a description of the web service's interface. A WSDL document contains information specified in Web Service Description Language (WSDL), as defined in the WSDL specification. WSDL defines an XML schema for describing a web service. To uncover the description for a Web service, a client needs to find the service's WSDL
document.

A WSDL document describes a web service as a collection of abstract items called "ports" or "endpoints." A WSDL document also defines the actions performed by a web service and the data transmitted to these
actions in an abstract way. Actions are represented by "operations," and data is represented by "messages." A collection of related operations is known as a "port type." A port type constitutes the collection of actions offered by a web service. What turns a WSDL description from abstract to concrete is a "binding." A binding specifies the network protocol and message format specifications for a particular port type. A port is defined by associating a network address with a binding. If a client locates a WSDL document and finds
the binding and network address for each port, it can call the service's operations according to the specified protocol and message format.

*Note - WSDL service: A collection of end points.

WSDL Elements:-

***UDDI***

An SOA can also include a service that provides a directory or registry of services. The Universal Description, Discovery, and Integration (UDDI) specifications define how to publish and discover information about services in a UDDI-conforming registry. More specifically, the specifications define a UDDI schema and a UDDI API. The UDDI schema identifies the types of XML data structures
that comprise an entry in the registry for a service. A UDDI registry provides information about a service such as the name of the service, a brief description of what it does, an address where the service can be accessed, and a description of the interface for accessing the service.

What is UDDI?

*UDDI is built into the Microsoft .NET platform

*UDDI stands for Universal Description, Discovery and Integration

*UDDI is a platform-independent framework for describing services, discovering businesses,
  and integrating business services by using the Internet.

*UDDI is a directory for storing information about web services

***RPC vs document styles***

The body of an RPC (remote procedure call) style SOAP message is constructed on the basis of defined soap standard. RPC style is tightly coupled with the application code which is it's main disadvantage.This means that if we are changing the order of the parmeters or the types of those parameters, this will affect the definition of the web service itself.

A RPC-style request:     

<soap:envelope>
              <soap:body>
                     <multiply> <!-- web method name -->
                         <a>5.0</a> <!-- first parameter -->
                         <b>9</b> <!-- second parameter -->
                     </multiply>
             </soap:body>
     </soap:envelope>
On the other hand, a document style web service contains no restrictions for the creation/construction of SOAP body. It allows to include any XML data which we want and also to include a schema for this XML. As document style web-services are loosely coupled with the application code. So they do not have any restrictions or issues to follow any rule.But the application must handle the marshalling and unmarshalling of the XML data separately.

 
A document-style request:
  
<soap:envelope>
            <soap:body>
                <!-- arbitrary XML -->
                    <movies xmlns="http://www.hollywoodmovies.com">
                         <movie>
                               <title>2010: The Expandables</title>
                              <released>2010</released>
                         </movie>
                         <movie>
                              <title>The Expandables 2</title>
                              <released>2012</released>
                        </movie>
                   </movies>
           </soap:body>
</soap:envelope>

We have below four Soap Buiding Styles.

RPC/encoded

RPC/literal

document/encoded

document/literal

Diff :- Encoded vs literal encodings

*Literal means the SOAP body follows an XML schema, which is included in the web service's WSDL document.As long as the client has access to the WSDL, it knows exactly how each message is formatted.

*On the other hand, encoded means that the SOAP body doesn't follow a schema, but follows a specific format.

document/literal wrapped

: - In this binding style each operation name is treated as element name,then if we have overloaded functions then the same element name will come more than once which is not supported by XML.

document/literal nonwrapped

: - This is the Best binding style to use.

Benefits of Document Binding Style: -

Document style is better suited for asynchronous processing

Document style makes object exchange more flexible

Note:-

Payload is nothing but the message which is commonly found to be in XML form.

Other SOA concepts

Architectures can operate independently of specific technologies. Designers can implement SOA using a wide range of technologies, including:

SOAP, RPC

REST

DCOM

CORBA

Web Services

DDS

WCF (Microsoft's implementation of web services now forms a part of WCF)

What is a REST Web Service?

(REST stands for REpresentation State Transfer)

The acronym REST stands for Representational State Transfer, this basically means that each unique

URL is a representation of some object. You can get the contents of that object using an HTTP GET,

you then might use a POST, PUT, or DELETE to modify the object.

Who's using REST?

All of Yahoo's web services use REST, including Flickr and Amazon have web services for both REST

and SOAP.

Who's using SOAP?

Google seams to be consistent in implementing their web services to use SOAP, with the exception of

Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as

well.

Note:-

Almost all popular frameworks like Apache CXF support both Rest and Soap.

Difference between Rest and Soap web services :-

*REST has no WSDL interface definition.

*

REST is over HTTP, but SOAP can be over any transport protocols such HTTP, FTP,STMP, JMS etc.

*SOAP is using soap envelope, but REST is just XML.

*REST is an architecture. REST will give Human Readable Results.

*REST is stateless. REST services are easily cacheable.

RESTful Support in JAX-WS

The Java API for XML Web Services (JAX-WS) provides full support for building

and deploying RESTful web services. It is tightly integrated with the Java Architecture

for XML Binding (JAXB) for binding XML to Java technology data

About REST HTTP Methods : -

With RESTFul web services, there is a natural mapping between the HTTP methods and most CRUD-like business operations that many services expose.

* GET is used to retrieve data or perform a query on a resource. The data returned from the web service is a representation of the requested resource.

POST is used to create a new resource. The web service may respond with data or status indicating success or failure.

PUT is used to update existing resources or data.

DELETE is used to remove a resource or data.