Re: Simple Object Access Protocol (fwd)

[Vardan Gyurjyan <gurjyan@jlab.org>]

Elton Smith wrote:

> ---------- Forwarded message ----------
> Date: Tue, 22 May 2001 10:15:02 EDT
> From: heddle@jdhtech.com
> To: marki@jlab.org, dennisl@csit.fsu.edu, wolin@jlab.org, elton@jlab.org
> Subject: Simple Object Access Protocol
>
> Guys,
>
> Are you looking into Simple Object Access Protocol (SOAP) for Hall B/D applications? It is very cool. And it is an approved standard.
>
> dph

Hi,
Following the forwarded mail from Elton (original author Dave Heddle) I tried
to learn and understand what SOAP (Simple Object Access Protocol) is.
Now days it is virtually impossible to pick up an technology related magazine
and not hear the glories of SOAP.
So, what is SOAP?
SOAP is a protocol for developing distributed applications.
It will be more helpful to understand advantages and disadvantages of the
SOAP, by reviewing the current (relatively well known) options for developing
distributed applications: CORBA and RMI. I will skip Microsoft DCOM for
obvious reasons (at least for us, physicists :)).

CORBA ( Common Object Request Broker Architecture) is a industry-standard
distributed application development model. CORBA defines its own generic
communication protocol, called GIOP (Generic Inter Object Request Broker
Protocol), with specific versions mapped to underlying internet protocols
(For example,GIOP protocol version based on TCP/IP is called IIOP).
ORB's (Object Request Brokers) are available on a variety of platforms and
operating systems. CORBA uses a predefined series of GIOP messages passed
between ORB's to establish communication between the calling system and an
object on the called system. Once the calling system obtained a reference to
a remote object, it can begin manipulating the object created by the called
system. CORBA model is state-full, since the calling system "holds on" to the
object created for him on the called system. Due to this intrinsic state
maintenance CORBA systems are less scalable.

RMI (Remote Method Invocation) is a simple and elegant model for
communication between distributed Java objects. RMI is also based on TCP/IP
sockets, but unlike CORBA, the remote object's method definitions are
dynamically downloaded to the client once the local Java client identifies the
location of the remote object whose methods it will invoke (from the network
accessible RMI registry).RMI supports both state-full and stateless
programming. It also has special features that make it ideal for the
development of lightweight objects that can be invoked by web browser clients.
Disadvantage here is that Java runtime environment must be installed in both
communicated systems.Even though Sun provide Java runtimes for most common
systems free, this also requires the development on both systems to be done
using Java language  (personally for me this is an advantage :), however this
will become an real issue in case we wont to reuse old software components
developed in C, or Fortran).

How SOAP is different?
Implementing RMI or CORBA models requires a locally installed runtime
environment on both systems, participating in conversation. And if the
systems willing to communicate aren't local (one of our international
collaborators want to access online system), then fire-walls have to be
configured to allow open ports required by each of parties in the
communication to pass information beyond the firewall.
SOAP, on the other hand, requires only that the systems have an XML parser
and support a common protocol (typically HTTP).One thing we have to remember
that SOAP is NOT a runtime environment, but a well defined wire-level
protocol.
So, all the sophisticated environment managements, provided by RMI and CORBA,
here are missing. For example, each of these technologies has a mechanism
for handling unused objects (garbage collection), various level of
implementation specific security, etc. SOAP has no predefined security and
actually passes data between systems in clear text. And by its stateless
nature, SOAP doesn't support any call-back mechanism. SOAP developers must
 implement functionality not included in the SOAP specification in their own
distributed architecture.
Fortunately, Sun, IBM, and Microsoft are all implementing much of this
functionality, using SOAP as their core wire protocol, in the next
generation development environments. For example, IBM is extending their
WebSphere platform to be major player in the SOAP systems development arena.
SOAP sounds very promising, and we should clearly pay serious attention on
this product and start experimenting with the next generation distributed
applications developed using SOAP. Taking in to account the simplicity of
the SOAP envelops ( XML) and communication protocol (HTTP), it will be not
a problem to develop proprietary public-subscribe or multicast message passing
 systems, as well as distributed applications, which can be used ( why not?)
as a media for grids.

Regards,
       Vardan G.