|
A Web service is an application stored on a machine that can be accessible
through another machine over Internet or LAN. Even before introduction of
Web services we were able to access applications or business logics across
the net. Therefore, before starting with Web Services we must know the
need that gave rise to Web services.
To begin with we would discuss the four Ps that are
important in doing business using computers.
-
Partners:
Every business needs partners and that is how they make enormous
amount of profit.
-
Profit: No business can run without making
profits. Profit must increase every year to make the business
successful.
-
Productivity: Computer as its very nature
can be used to improve productivity of a business and hence the
profit.
-
Programming should be cheap: If computer is
to improve productivity of the business programming and maintenance
cost should decrease.
Let us now understand the current
business scenario. We would take an example of an airlines company. The
customers of the airlines company may access the company through personal
computers, PDAs or simple phones. The airlines company may communicate
with partners such as a food company or the bank. Partners and clients
would still be there but the way they would interact would be different.
The airlines company would have a web server to which clients would send
requests for ASP or HTML pages. The request would be in form of HTTP
request. The Web Server would communicate with the business logic in the
application server and use the data bases to store the data. The Web
Server would respond by sending HTML back to the clients. The food company
and bank organization would have application servers running business
logic in the form of components. They would also have data base servers
for secured and efficient data storage. If airlines company is to access
the business logic exposed by application servers of food company and bank
it would do so through Remote Procedure Calls. Also the food company and
bank may also be interacting with each other.
Different client organizations would use various
software and programming model. Even the Operating Systems installed on
the client devices would be different. The client would like to interact
with the Web Server using these devices. The Web Server of the Airline
company may either have IIS, JWS or Apache server running appropriate
sever side scripts. The food company may have COM+ model on their
Application servers with business logic implemented as COM components and
MS-SQL database. The bank organization may have J2EE model with business
logic implemented as EJB components running on their Application Servers
and data base in Oracle.
In a distributed computing architecture the clients
form the Presentation layer and the DCOM components, EJB components, CORBA
components and DCOM components form the Business layer. The clients has to
cross the firewalls to access components. Firewalls ensure that
communication is done through a specified port and data format. The
external applications, databases and legacy system form the Data layer. In
our Airline example, the main reason of conflict is that all the three
interacting companies (airlines company, food company and bank) have
different standards. The airlines company has CORBA components installed.
The food company has DCOM components and Bank has EJB components. The
problems faced in developing these components are as follows:
-
Language: DCOM components could be written
only in VC++ or VB, whereas, EJB components could be written only in
Java.
-
Infrastructure: CORBA components need ORB
libraries and services. DCOM components need COM libraries and
services, and EJB components need J2EE Services.
-
Layout of Objects: Layout of CORBA
components differ from DCOM components which in turn differs from EJB
components.
-
Description: CORBA components are defined
using CORBA Interface Description Language, DCOM components are
defined using Microsoft Interface definition languages and EJB
components are exposed as interfaces.
-
Discovery Standards: CORBA components are
discovered using the CORBA registry, DCOM using the Registry and EJB
using the Java Native Directory Interface.
The conflict between these models occur mainly due to
the Wire Protocol and Data Standard. This was different for each of the
infrastructure. CORBA uses IIOP (Inter Internet Object Protocol), DCOM
uses RPC (Remote Procedure Calls) and EJB uses RMI (Remote Method
Invocation) / IIOP. All these protocols are non-standard protocols and
hence are not followed by all companies.
These existing Distributed Computing solutions suffer
from various problems. For example, DCOM is a proprietary protocol. It
does not support interoperability and it has firewall problems because
DCOM transfers data in binary format and it uses many ports to call remote
functions. CORBA uses IIOP protocol, which is non-internet friendly. EJB
requires very costly infrastructure. Moreover all these object models
require their client to use the same libraries as that used on server.
This makes a very tight coupling between client and the component. If
component is changed and written using new object model the client will
also have to change.
To address these needs, XML Web services came into
existence and were introduced as part of ASP.NET, which is part of the
.NET Framework. Web services are based on open Industry standards, such as
HTTP, XML, and SOAP. Using these open standards, Web services deliver
application functionality across the Web to any type of client, on any
platform.
XML Web services are based on open Web standards that
are broadly supported and are used for communication and data formats. XML
Web services provide the ability to expose application logic as
URI-addressable resources, available to any client in a
platform-independent way. Web services are self-describing. Any clients
incorporating open Web standards for communication and data formatting
(HTTP and XML) can query dynamically for Web service information and
retrieve an XML document describing the location and interfaces supported
by a particular XML Web service. These open standards make Web services
indifferent to the operating system, object model, and programming
language used. Web services are accessible to disparate systems,
supporting application interoperability to an unprecedented level thanks
to the ubiquity of HTTP and XML.
Instead of communicating in binary formats between
applications, Web services use XML-encoded messages. Because XML-based
messaging is used for the data interchange, a high level of abstraction
exists between a Web service implementation and the client. This frees the
client from needing to know anything about a Web service except for its
location, method signatures, and return values. Additionally, most Web
services are exposed and accessed via HTTP, virtually eliminating firewall
issues.
We would see more about Web services, the protocols
they use and the way they are discovered in the next article.
To be continued...
|