Scour the Net with SOAP

The Dot Net framework talks of interoperability and flexibility between Web
sites. But, how does it plan to achieve this? XML and SOAP seem to be the answer
to this. Simple Object Access Protocol or SOAP and XML enable computers running
on different platforms to exchange data, and a Web service to detect which type
of device it is talking to. SOAP along with XML describes what data means,
enabling data to maintain its integrity when transmitted and handled by multiple
Web sites and users. The result is that Web sites become flexible services that
can interact, and exchange and leverage each other’s data.

The Internet has become one of the most effective and efficient ways of
accessing information. Several protocols are used to transfer information over
the Internet, the most common ones being HTTP and FTP. Hypertext Transfer
Protocol (HTTP) can be used to transfer text, graphics, Web pages and other
information effectively while File Transfer Protocol (FTP) is a way to exchange,
upload or download files on the Internet. Although HTTP is quite flexible, it
was not designed as a protocol for invoking remote procedures. There is growing
realization for the need to communicate with remote applications over the
Internet.

There are several distributed object protocols like Distributed Component
Object Model (DCOM) and Internet Inter-ORB Protocol (IIOP) which allow
interaction with remote applications, known as remote procedure call or RPC.
These protocols allow a client to issue a RPC to a server and then receive a
response. Another example is Sun Microsystems’ Remote Method Invocation for a
client/server inter-program protocol for programs written in JAVA. The problem
with distributed object protocols is that they use dynamically assigned ports
i.e. at runtime an arbitrary port is assigned to the executable process. Unlike
HTTP, which uses port 80 and FTP port 21, they don’t have a single, well-known
port number assigned to them. For example, DCOM is free to use any port between
1024 and 65535 while selecting a port for an application. Therein lies the
problem.

Due to security concerns most organizations add a firewall between their Web
servers and those accessing information from these servers. While firewalls on
one hand provide the necessary security, they make the efficient use of
distributed object protocols very difficult. From the security point of view,
firewalls are usually configured to allow traffic on port 80 for HTTP requests
to get through while blocking traffic on the other ports. Therefore, when a
distributed object protocol uses a dynamically assigned port, the request is
automatically blocked by the firewall. But there is a way around this too.
Firewalls can be configured to pass traffic on ports that lie within a specific
range. Now, if the distributed object protocol uses ports within this range,
client requests will be allowed through. But here again security concerns could
arise; as opening arbitrary set of ports is not be feasible.

SOAP, the acronym for simple object access protocol developed by Microsoft,
DevelopMentor and UserLand Software, is a way around this problem. Programs
running in one kind of operating system can now communicate with programs in the
same or different kind of operating system without being blocked by firewalls.
It is a distributed object protocol but is not hindered by the presence of
firewalls and can be used with any component technology. SOAP uses HTTP and XML
to provide an open and extensible way for applications to communicate. Here, a
distributed object protocol is sent over an HTTP protocol using XML to define
the format of request and response messages. Since it uses HTTP, all requests
pass through port 80. Thus firewalls no longer pose a problem.

But by bypassing firewalls one might ask if SOAP itself would pose a security
problem? The answer would be no, as firewalls can be configured to selectively
block out SOAP requests. SOAP is just a payload carried over HTTP, so the
problems faced in this case would be similar to those faced due to HTTP.
Firewalls can also be configured to filter out SOAP requests based on the
information supplied in the HTTP header.

The SOAP protocol essentially consists of three parts: firstly the envelope,
which specifies the framework for expressing what is in the message, who should
deal with it and whether it is optional or compulsory. Secondly, the encoding
rules and thirdly the SOAP RPC representation which is a convention for
representing remote procedure calls and responses.

There are also certain drawbacks in that it does not say much about
bi-directional communication and as of now it addresses only how SOAP requests
can be sent via HTTP but not other protocols. Neither does it address higher
level issues such as object activation or lifetime management. Nevertheless,
SOAP facilitates interoperability and platform independence. It is a simple
protocol and is easy to implement with the existing Internet infrastructure and
achieving this is no a small thing. There is also the advantage that it is not
tied to any particular object model. All in all, it provides an easy to
implement solution that allows software objects developed using different
languages to communicate with each other.