Unit V: Web Services - Web Technologies II - BCA Notes (Pokhara University)

Introduction to Web Services:

Web services are XML-based information exchange systems that use the Internet for direct application-to-application interaction. These systems can include programs, objects, messages, or documents.

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet is similar to inter-process communication on a single computer. This interoperability (e.g. between Java and Python, or Windows and Linux applications) is due to the use of open standards.

A web service enables communication among various applications by using open standards such as HTML, XML, WSDL, and SOAP. A web service takes the help of XML to tag the data, SOAP to transfer a message, WSDL to describe the availability of service. We can build a Java-based web service on Solaris that is accessible from our Visual Basic program that runs on Windows. We can also use C# to build new web services on Windows that can be invoked from our web application that is based on JavaServer Pages (JSP) and runs on Linux.

Web Service Features:

1. XML-Based:

Web services use XML at data description and data transportation layers. Using XML exclude any networking, operating system, or platform binding. Web services-based operation is extremely interoperable at their core level.

2. Loosely Coupled:

A client of a web service is not fixed to the web service directly. The web service interface can support innovation over time without negotiating the client's ability to communicate with the service. A tightly coupled system means that the client and server logic are closely tied to one another, indicating that if one interface changes, then another must be updated. Accepting a loosely coupled architecture tends to make software systems more manageable and allows more straightforward integration between various systems.

3. Coarse-Grained:

Object-oriented technologies such as Java expose their functions through individual methods. A specific process is too fine an operation to provide any suitable capability at a corporate level. Building a Java program from scratch needed the creation of various fine-grained functions that are then collected into a coarse-grained role that is consumed by either a client or another service.

Businesses and the interfaces that they prove should be coarse-grained. Web services technology implement a natural method of defining coarse-grained services that approach the right amount of business logic.

4. Ability To Be Synchronous or Asynchronous:

Synchronicity specifies the binding of the client to the execution of the function. In synchronous invocations, the client blocks and delays in completing its service before continuing. Asynchronous operations grant a client to invoke a task and then execute other functions.

Asynchronous clients fetch their result at a later point in time, while synchronous clients receive their effect when the service has completed. Asynchronous capability is an essential method in enabling loosely coupled systems.

5. Supports Remote Procedure Calls (RPCs):

Web services allow consumers to invoke procedures, functions, and methods on remote objects using an XML-based protocol. Remote systems expose input and output framework that a web service must support.

Component development through Enterprise JavaBeans (EJBs) and .NET Components has more become a part of architectures and enterprise deployments over a previous couple of years. Both technologies are assigned and accessible through a variety of RPC mechanisms.

A web function supports RPC by providing services of it's own, equivalent to those of a traditional role, or by translating incoming invocations into an invocation of an EJB or a .NET component.

6. Supports Document Exchange:

One of the essential benefits of XML is its generic way of representing not only data but also complex documents. These documents can be as simple as describing a current address, or they can be as involved as defining an entire book or Request for Quotation (RFQ). Web services support the transparent transfer of documents to facilitate business integration.

Web Service Architecture:

Every framework needs some sort of architecture to make sure the entire framework works as desired. Similarly, in web services, there is an architecture which consists of three distinct roles as given below:

1. Provider:

The provider creates the web service and makes it available to client application who want to use it.

2. Requestor:

A requestor is nothing but the client application that needs to contact a web service. The client application can be a .Net, Java, or any other language-based application which looks for some sort of functionality via a web service.

3. Broker:

The broker is nothing but the application which provides access to the UDDI. The UDDI, as discussed in the earlier topic enables the client application to locate the web service.

The diagram below showcases how the Service provider, the Service requestor and Service registry interact with each other.

1. Publish:

A provider informs the broker (service registry) about the existence of the web service by using the broker's publish interface to make the service accessible to clients.

2. Find:

The requestor consults the broker to locate a published web service.

3. Bind:

With the information, it gained from the broker (service registry) about the web service, the requestor is able to bind, or invoke the web service.

Advantages of Web Services:

1. Exposing The Existing Function On The Network:

A web service is a unit of managed code that can be remotely invoked using HTTP, that is, it can be activated using HTTP requests. Web services allow us to expose the functionality of our existing code over the network. Once it is exposed to the network, other application can use the functionality of our program.

2. Interoperability:

Web services allow various applications to talk to each other and share data and services among themselves. Other applications can also use web services. For example, a VB or .NET application can talk to Java web services and vice versa. Web services are used to make the application platform and technology independent.

3. Standardized Protocol:

Web services use a standardized industry-standard protocol for communication. All four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack. This standardization of protocol stack gives the business many advantages such as a wide range of choices, reduction in the cost due to competition, and an increase in the quality.

4. Low-Cost Communication:

Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services. This solution is much less costly compared to proprietary solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented on other reliable transport mechanisms like FTP.

Service-Oriented Architecture:

Service-Oriented Architecture (SOA) is an architectural approach in which applications make use of services available in the network. In this architecture, services are provided to form applications, through a communication call over the internet.

1. SOA allows users to combine a large number of facilities from existing services to form applications.

2. SOA encompasses a set of design principles that structure system development and provide means for integrating components into a coherent and decentralized system.

3. SOA based computing packages functionalities into a set of interoperable services, which can be integrated into different software systems belonging to separate business domains.

There are Two Major Roles within Service-oriented Architecture:

1. Service Provider:

The service provider is the maintainer of the service and the organization that makes available one or more services for others to use. To advertise services, the provider can publish them in a registry, together with a service contract that specifies the nature of the service, how to use it, the requirements for the service, and the fees charged.

2. Service Consumer:

The service consumer can locate the service metadata in the registry and develop the required client components to bind and use the service.

Services might aggregate information and data retrieved from other services or create workflows of services to satisfy the request of a given service consumer. This practice is known as service orchestration another important interaction pattern is service choreography, which is the coordinated interaction of services without a single point of control.

Components of SOA:

1. Services:

Services are the one thing every customer already has, although they may not know it. Existing applications provide the raw material from which services are created. Some applications already expose a service interface, others need one crafting either through an off the shelf adapter or through a direct file, queue or database access. We will return to this topic in another entry.

2. Orchestration or Process Layer:

Orchestration is crucial to SOA and allows the composition of new services (composite services) and new applications (composite applications) by threading existing services together in new forms. The process layer allows us to automate the business processes that thread together with the services into a manageable business process.

3. Access Framework:

When creating new composite applications they will need a user interface and possibly some additional business logic. These applications may be written within J2EE or .Net technologies and will take advantage of existing services. The use of existing services and loose coupling between the front end and these services makes it feasible to rapidly develop new composite applications, one of the supposed benefits of SOA.

4. Business Activity Monitoring:

The orchestration layer allows us to monitor the state of individual processes, where they are and what they are doing. However, it is not a good tool for seeing what is happening across multiple instances of a business process, for that we need Business Activity Monitoring to tell us things about sets of processes. This information may provide the basis for dashboard reports and alerts for the business. This type of visibility can add real value to the business and is a great way for IT to sell the business on the benefits of moving down an SOA path.

5. Operational Data Store:

Access services could get all their reference data such as customer lists, product lists from individual back end services, but this is not a natural way to retrieve data and the tools to support this are weak compared to the tools for querying a database. An Operational Data Store (ODS) may be used to provide a real-time synchronised view of data from multiple services. This data needs to be cleansed and any changes need to be bi-directionally synced with every instance of the data in the back end services. Use of an ODS decouples our access layer from the services providing the data and allows migration of services from one provider to another.

6. Business Intelligence:

Moving to SOA carries with it the threat of fragmented data architecture. This probably has to be accepted but the consequences of such architecture do not have to be accepted. The need for a reporting capability does not go away with SOA but there is now the question of what do we report against. This is where the value of an ODS can come in for reporting on cross-service data. Business Intelligence provides traditional and end-user reporting capabilities against historical data in contrast to BAM which provides real-time event-driven reporting.

7. Security:

Moving to SOA makes security even harder because of breaking the link between the service requestor (ultimately an end-user usually) and the service being requested. We need to propagate security contexts across multiple services to ensure access controls are honoured and an audit trail back to the request initiator is in place.

8. Management:

The most functional IT systems are useless if they are not available or performing poorly. The loose coupling of SOA makes management more complicated and at the same time more essential. Operators should be able to monitor end to end system status and performance and be warned of potential problems such as capacity crunches before they occur.

9. Partners:

Not all clients of service are within the enterprise, and not all services are provided by the enterprise. All the requirements above apply equally to partners, suppliers and customers. It is necessary to enforce security constraints whilst allowing efficient access to and from partner systems. This provides yet another challenge in our SOA.

Guiding Principles of SOA:

1. Standardized Service Contract:

Services adhere to a service description. A service must have some sort of description which describes what the service is about. This makes it easier for client applications to understand what the service does.

2. Loose Coupling:

Less dependency on each other. This is one of the main characteristics of web services which just states that there should be as less dependency as possible between the web services and the client invoking the web service. So if the service functionality changes at any point in time, it should not break the client application or stop it from working.

3. Service Abstraction:

Services hide the logic they encapsulate from the outside world. The service should not expose how it executes its functionality; it should just tell the client application on what it does and not on how it does it.

4. Service Reusability:

Logic is divided into services with the intent of maximizing reuse. In any development, company re-usability is a big topic because obviously, one wouldn't want to spend time and effort building the same code again and again across multiple applications which require them. Hence, once the code for a web service is written it should have the ability to work with various application types.

5. Service Autonomy:

Services should have control over the logic they encapsulate. The service knows everything on what functionality it offers and hence should also have complete control over the code it contains.

6. Service Statelessness:

Ideally, services should be stateless. This means that services should not withhold information from one state to the other. This would need to be done from either the client application. An example can be an order placed on a shopping site. Now we can have a web service which gives us the price of a particular item. But if the items are added to a shopping cart and the web page navigates to the page where we do the payment, the responsibility of the price of the item to be transferred to the payment page should not be done by the web service. Instead, it needs to be done by the web application.

7. Service Discoverability:

Services can be discovered (usually in a service registry). We have already seen this in the concept of the UDDI, which performs a registry which can hold information about the web service.

8. Service Composability:

Services break big problems into little problems. One should never embed all functionality of an application into one single service but instead, break the service down into modules each with separate business functionality.

9. Service Interoperability:

Services should use standards that allow diverse subscribers to use the service. In web services, standards as XML and communication over HTTP is used to ensure it conforms to this principle.

Advantages of SOA:

1. Service Reusability: In SOA, applications are made from existing services. Thus, services can be reused to make many applications.

2. Easy Maintenance: As services are independent of each other they can be updated and modified easily without affecting other services.

3. Platform Independent: SOA allows making a complex application by combining services picked from different sources, independent of the platform.

4. Availability: SOA facilities are easily available to anyone on request.

5. Reliability: SOA applications are more reliable because it is easy to debug small services rather than huge codes.

6. Scalability: Services can run on different servers within an environment, this increases scalability.

Disadvantages of SOA:

1. High overhead: A validation of input parameters of services is done whenever services interact this decreases performance as it increases load and response time.

2. High investment: A huge initial investment is required for SOA.

3. Complex service management: When services interact they exchange messages to tasks. The number of messages may go in millions. It becomes a cumbersome task to handle a large number of messages.

Practical Applications of SOA:

SOA is used in many ways around us whether it is mentioned or not.

1. SOA infrastructure is used by many armies and air force to deploy situational awareness systems.

2. SOA is used to improve healthcare delivery.

3. Nowadays many apps are games and they use inbuilt functions to run. For example, an app might need GPS so it uses inbuilt GPS functions of the device. This is SOA in mobile solutions.

4. SOA helps maintain museums a virtualized storage pool for their information and content.

Web Service Components:

SOAP (Simple Object Access Protocol):

In today's world, there is a huge number of applications which are built on different programming languages. For example, there could be a web application designed in Java, another in .Net and another in PHP.

Exchanging data between applications is crucial in today's networked world. But data exchange between these heterogeneous applications would be complex. So will be the complexity of the code to accomplish this data exchange.

One of the methods used to combat this complexity is to use XML (Extensible Markup Language) as the intermediate language for exchanging data between applications.

Every programming language can understand the XML markup language. Hence, XML was used as the underlying medium for data exchange. But there are no standard specifications on use of XML across all programming languages for data exchange. That is where SOAP comes in.

SOAP was designed to work with XML over HTTP and have some sort of specification which could be used across all applications.

Elements of SOAP:

A SOAP message is an ordinary XML document containing the following elements:

1. Envelope: Defines the start and the end of the message. It is a mandatory element.

2. Header: Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end-point. It is an optional element.

3. Body: Contains the XML data comprising the message being sent. It is a mandatory element.

4. Fault: An optional Fault element that provides information about errors that occur while processing the message.

1. As seen from the above SOAP message, the first part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message.
2. The next element is the SOAP body which contains the details of the actual message.
3. Our message contains a web service which has the name of "Guru99WebService".
4. The "Guru99Webservice" accepts a parameter of the type 'int' and has the name of TutorialID.

Now, the above SOAP message will be passed between the web service and the client application.

We can see how useful the above information is to the client application. The SOAP message tells the client application what is the name of the Web service, and also what parameters it expects and also what is the type of each parameter which is taken by the web service.

Remote Procedure Calls (RPC) Representation:

Remote Procedure Calls in SOAP are essentially client-server interactions over HTTP where the request and response comply with SOAP encoding rules. The Request-URI (Universal Resource Identifier) in HTTP is typically used at the server end to map to a class or an object, but this is not mandated by SOAP. Additionally, the HTTP header SOAP Action specifies the interface name (a URI) and the name of the method to be called on the server.

The SOAP message is an XML document whose root element, the Envelope, specifies the overall structure of the message, its intended recipient, and other attributes of the message. SOAP specifies a remote procedure call convention, which includes the representation and format to be used for calls and responses. A method call is modelled as a compound data element consisting of a sequence of fields (accessors), one for each parameter. A return structure consists of the return value as well as the out and in/out parameters. SOAP encoding rules specify the serialization for primitive and application-defined data types.

Example of a SOAP Request Sent via HTTP:

Example of a SOAP Response Received via HTTP:

SOAP allows hierarchically structured queries and responses, and specifies serialization of primitive string, numeric and date <data types>, and aggregates like arrays and vectors. Sparse arrays and protocols for sending parts of them are also supported. New types may be defined using the <complexType> construct inside a schema definition.

Overall, SOAP provides many advantages. Unfortunately, its universality comes with a performance penalty: XML messages are textual and so the sizes of its messages are significantly larger than protocols which send binary data. Since a distinguishing characteristic of scientific computation is the need to handle large data sets, the performance of SOAP relative to specialized protocols that can use binary representations is an important issue. The next section tests SOAP performance relative to other communication protocols.

SOAP Encoding Structure Data:

The following block depicts the general structure of a SOAP message:

<?xml version = "1.0"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"

SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

<SOAP-ENV:Header>

...

</SOAP-ENV:Header>

<SOAP-ENV:Body>

...

<SOAP-ENV:Fault>

...

</SOAP-ENV:Fault>

...

</SOAP-ENV:Body>

</SOAP_ENV:Envelope>

Example:

<?xml version = '1.0' encoding = 'UTF-8'?>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"

xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body>

<ns1:getProductResponse

xmlns:ns1 = "urn:examples:productservice"

SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

<name xsi:type = "xsd:string">Red Hat Linux</name>

Red Hat Linux Operating System

</description>

</return>

</ns1:getProductResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

WSDL (Web Services Description Language):

WSDL is an XML-based file which basically tells the client application what the web service does. It is known as the Web Services Description Language (WSDL).

The WSDL file is used to describe in a nutshell what the web service does and gives the client all the information required to connect to the web service and use all the functionality provided by the web service.

Structure of a WSDL Document:

A WSDL document is used to describe a web service. This description is required, so that client applications can understand what the web service actually does.

1. The WSDL file contains the location of the web service and

2. The methods which are exposed by the web service.

The WSDL file itself can look very complex to any user, but it contains all the necessary information that any client application would require to use the relevant web service.

Below Is The General Structure Of a WSDL File:

a. Definition

b. TargetNamespace

c. DataTypes

d. Messages

e. Port type

f. Bindings

g. Service

One key thing to note here is that definition of messages, which is what is passed by the SOAP protocol is actually defined in the WSDL document.

The WSDL document actually tells a client application what are the types of SOAP messages which are sent and accepted by the Web service.

In other words, the WSDL is just like a postcard which has the address of a particular location. The address provides the details of the person who delivered the postcard. Hence, in the same way, the WSDL file is the postcard, which has the address of the web service which can deliver all the functionality that the client wants.

<definitions

name="Guru99Service"

targetNamespace=http://example.org/math/

xmlns=http://schemas.xmlsoap.org/wsdl/>

<types> ...

<message> ...

<portType> ...

<binding> ...

<service> ...

</definition>

WSDL Elements:

The WSDL file contains the following main parts:

1. Type:

The <types> tag is used to define all the complex data types, which will be used in the message exchange between the client application and the web service. This is an important aspect of the client application, because if the web service works with a complex data type, then the client application should know how to process the complex data type. Data types such as float, numbers, and strings are all simple data types, but there could be structured data types which may be provided by the web service.

For example, there could be a data type called EmployeeDataType which could have 2 elements called "EmployeeName" of type string and "EmployeeID" of type number or integer. Together they form a data structure which then becomes a complex data type.

2. Messages:

The <messages> tag is used to define the message which is exchanged between the client application and the webserver. These messages will explain the input and output operations which can be performed by the web service. An example of a message can be a message which accepts the EmployeeID of an employee, and the output message can be the name of the employee based on the EmpoyeeID provided.

3. Port Type:

The <portType> tag is used to encapsulate every input and output message into one logical operation. So there could be an operation called "GetEmployee" which combines the input message of accepting the EmployeeID from a client application and then sending the EmployeeName as the output message.

4. Binding:

The <binding> tag is used to bind the operation to the particular port type. This is so that when the client application calls the relevant port type, it will then be able to access the operations which are bound to this port type. Port types are just like interfaces. So if a client application needs to use a web service they need to use the binding information to ensure that they can connect to the interface provided by that web service.

5. Service:

The <service> tag is a name given to the web service itself. Initially, when a client application makes a call to the web service, it will do by calling the name of the web service. For example, a web service can be located at an address such as http://localhost/bcanotespu/Tutorial.asmx . The service tag will actually have the URL defined as http://localhost/bcanotespu/Tutorial.asmx, which will actually tell the client application that there is a web service available at this location.

Concept of UDDI:

UDDI (Universal Description, Discovery, and Integration) is an XML-based registry for businesses worldwide to list themselves on the Internet. Its ultimate goal is to streamline online transactions by enabling companies to find one another on the Web and make their systems interoperable for e-commerce. UDDI is often compared to a telephone book's white, yellow, and green pages. The project allows businesses to list themselves by name, product, location, or the Web services they offer.

Microsoft, IBM, and Ariba spearheaded UDDI. The project now includes 130 companies, including some of the biggest names in the corporate world. Compaq, American Express, SAP AG, and Ford Motor Company are all committed to UDDI, as is Hewlett-Packard, whose own XML-based directory approach, called e-speak, is now being integrated with UDDI.

While the group does not refer to itself as a standards body, it does offer a framework for Web services integration. The UDDI specification utilizes World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) standards such as XML, HTTP, and Domain Name System (DNS) protocols. It has also adopted early versions of the proposed Simple Object Access Protocol (SOAP) messaging guidelines for cross-platform programming.

In November 2000, UDDI entered its public beta-testing phase. Each of its three founders - Microsoft, IBM, and Ariba - now operates a registry server that is interoperable with servers from other members. As information goes into a registry server, it is shared by servers in the other businesses. The UDDI beta is scheduled to end in the first quarter of 2001. In the future, other companies will act as operators of the UDDI Business Registry. UDDI registration is open to companies worldwide, regardless of their size.

UDDI Has Two Sections:

1. A registry of all web service's metadata, including a pointer to the WSDL description of a service.

2. A set of WSDL port type definitions for manipulating and searching that registry.

RESTFul Web Services:

REST is used to build Web services that are lightweight, maintainable, and scalable in nature. A service which is built on the REST architecture is called a RESTful service. The underlying protocol for REST is HTTP, which is the basic web protocol. REST stands for REpresentational State Transfer.

A RESTful web service usually defines a URI (Uniform Resource Identifier), which is a service that provides resource representation such as JSON and a set of HTTP Methods.

RESTful Key Elements:

1. Resources:

The first key element is the resource itself. Let assume that a web application on a server has records of several employees. Let's assume the URL of the web application is http://demo.bcanotespu.com. Now, to access an employee record resource via REST, one can issue the command http://demo. bcanotespu.com/employee/1. This command tells the webserver to please provide the details of the employee whose employee number is 1.

2. Request Verbs:

These describe what you want to do with the resource. A browser issues a GET verb to instruct the endpoint it wants to get data. However, there are many other verbs available including things like POST, PUT, and DELETE. So in the case of the example http://demo. bcanotespu.com/employee/1, the web browser is actually issuing a GET Verb because it wants to get the details of the employee record.

3. Request Headers:

These are additional instructions sent with the request. These might define the type of response required or the authorization details.

4. Request Body:

Data is sent with the request. Data is normally sent in the request when a POST request is made to the REST web service. In a POST call, the client actually tells the web service that it wants to add a resource to the server. Hence, the request body would have the details of the resource which is required to be added to the server.

5. Response Body:

This is the main body of the response. So in our example, if we were to query the web server via the request http://demo. bcanotespu.com/employee/1, the webserver might return an XML document with all the details of the employee in the Response Body.

6. Response Status Codes:

These codes are the general codes which are returned along with the response from the webserver. An example is the code 200 which is normally returned if there is no error when returning a response to the client.

Restful Methods:

The below diagram shows mostly all the verbs (POST, GET, PUT, and DELETE) and an example of what they would mean.

Let's assume that we have a RESTful web service is defined at the location. http://demo.bcanotespu.com/employee. When the client makes any request to this web service, it can specify any of the normal HTTP verbs of GET, POST, DELETE and PUT.

Below Is What Would Happen If The Respective Verbs Were Sent By The Client.

1. POST: This would be used to create a new employee using the RESTful web service

2. GET: This would be used to get a list of all employee using the RESTful web service

3. PUT: This would be used to update all employee using the RESTful web service

4. DELETE: This would be used to delete all employee using the RESTful web service

Let's take a look from a perspective of just a single record. Let's say there was an employee record with the employee number of 1.

The Following Actions Would Have Their Respective Meanings.

1. POST: This would not be applicable since we are fetching data of employee 1 which is already created.

2. GET: This would be used to get the details of the employee with Employee no as 1 using the RESTful web service.

3. PUT: This would be used to update the details of the employee with Employee no as 1 using the RESTful web service.

4. DELETE: This is used to delete the details of the employee with Employee no as 1.

Advantages of RESTful Web Services:

1. Fast: RESTful Web Services are fast because there is no strict specification like SOAP. It consumes less bandwidth and resource.

2. Language and Platform independent: RESTful web services can be written in any programming language and executed in any platform.

3. Can use SOAP: RESTful web services can use SOAP web services as the implementation.

4. Permits different data format: RESTful web service permits different data format such as Plain Text, HTML, XML and JSON.

Difference Between SOAP and REST:

S.No.	SOAP	REST
1	SOAP is a protocol.	REST is an architectural style.
2	SOAP stands for Simple Object Access Protocol.	REST stands for REpresentational State Transfer.
3	SOAP can't use REST because it is a protocol.	REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
4	SOAP uses services interfaces to expose the business logic.	REST uses URI to expose business logic.
5	JAX-WS is the java API for SOAP web services.	JAX-RS is the Java API for RESTful web services.
6	SOAP defines standards to be strictly followed.	REST does not define too many standards like SOAP.
7	SOAP requires more bandwidth and resource than REST.	REST requires less bandwidth and resource than SOAP.
8	SOAP defines its own security.	RESTful web services inherit security measures from the underlying transport.
9	SOAP permits XML data format only.	REST permits different data format such as Plain text, HTML, XML, JSON etc.
10	SOAP is less preferred than REST.	REST more preferred than SOAP.

Breaking

Friday, August 16, 2019

Unit V: Web Services - Web Technologies II