Web Services Overview
Peter Komisar ©   Conestoga College      v.1.0 / 2005

references: 'Developing Java Web Services' Nagappan , Skoczylas & Sriganesh,
'Professional Web Services', M. Hendricks et al., 'Building Web Services with Java',
S.Graham et. al.  XML & Web Services Unleashed , R.Schmeizer et.al, 'RFC 1050'
'RFC 1831'.

 
Forward

Today a terrific number of new information technologies are appearing and all
are asking for our attention. A few years ago there were a few key streams that
we needed to follow. We might master Java, VB, C, C++ or C#. Alternatively
we might have focused on Perl or PHP.  We might have learned SQL to help
us store our data. We might have also invested some time learning mark-up
languages to assist in presenting our information. In the simplest case we
learned HTML. For dynamic responses we may have invested time into learning
Servlets, JSPs, ASPs or Cold Fusion.  We may have also studied different
distributed computing solutions such as RMI, DCOM or CORBA.  So why
wasn't this enough?

Apparently, the current situation speaks for itself. These solutions in of
themselves have not satisfied the requirements of modern commercial
organizations. Subsequently, industry has spent something in the order of
billions of dollars investigating and implementing other forms of distributed
computing architectures, namely Web Services. Some of the reasons why
this is the case we hope to make clear in this note.

One particular technology that was quietly being nurtured first in the form of
SGML and later reincarnated in a 'redux' version is 'XML' or Extensible Markup
Language. 'XML' has played an important role in changing the landscape of IT
technology.  It is in fact XML in combination with more basic technologies that
has played a key role in creating the very large number of new technologies
that have flooded the IT environment.

In terms of Java they include APIs such as classic SAX and DOM and newer
APIs such as JAXM, SAAJ and JAX-RPC.  Struts and Java Server Faces are
a merger of XML with Server Page technology. XML adds to the 'stew', a number
of it's own native technologies, such as XSL (XML Style Sheet Language) 
XPath XLink and XML Schema. Fortunately, many of these are used directly
both in related Java APIs and in the context of Web Service Applications.

Then there are the many XML dialects that are under development for use in
XML Web Services. These are the core technologies like SOAP, WSDL and
UDDI. Many less known XML web service dialects include abbreviations for
technologies used in security like XLANG BTP, XML ENC and XKMS.

Keeping up with so many new abbreviations, never mind the technologies that
they represent is a daunting task. We might take solace in the fact, however, 
that most of the new activity in IT technology, are applications that are straight
XML applications or are a hybrid of  XML melded with older root IT technologies.

Early into this note you will note we discuss various distributed computing
applications. This is because Web Services are another form of distributed
computing that shares many features with it's predecessors. Surveying these
different architectures enables us to anticipate what the Web Services model
will work like. Limitations inherent in the early distributed computing models
also enable us to illuminate aspects that the Web Services distributed computing
model aims to resolve.

The first few paragraphs are designed to supply a 'light landing' into the subject
area. They can be safely skipped.

The Computer, the Internet & Distributed Computing

The Computer 

Babbage and Turing aside, the first electronic computer was built by Tommy Flowers in
1943, a British postal worker, who built his machine using vacuum tubes. The computer
was called 'Colossus'. A dozen of the machines were built and used by British Intelligence
to decrypt encoded messages that were being sent by the German military command
during the Second World War. The Americans who buy this stage in the war were
cooperating with British Intelligence built their version of Colossus and named it ENIAC.
ENIAC has taken credit for being the first computer but Tommy Flowers machine was
first and remain a secret until the archives were opened and revealed it's existence
decades later.

The advent of the IC or Integrated circuit allows IBM to create the first desktop
PCs in 1982. By the turn of the century, hand held devices contain the processing
power of computers that once filled rooms.

We now have millions of computers.

The Computer Connected

One milestone to note, in 1965 a computer in California was connected to another in
Massachusetts over a low speed telephone line, in effect creating the first wide area
network. The Internet's birth year is often set to the year 1969 when four university
computers were interconnected as nodes of what was then called the ARPANET.
Throughout the 70 and 80 the Internet grew steadily. In the early 90s, Tim Berners-Lees
invention of 'the Web', interconnected by hyperlinks led to the astounding growth rate
that characterizes the Internet today. Today, we have millions of computers connected
on the web.

Once connected it was inevitable that computers would be allowed to 'communicate'
and computing would also become a distributed process.

Distributed Computing

Distributed Computing has evolved loosely along a number of different tracks. First
there is the widely known Internet which is an inadvertent but spectacular example
of distributed computing. Then there is the less known but still massive world of
B2B or Business-2-Business where technologies such as EDI and it's descendants
are used. Also, there are well known architectures such as CORBA, DCOM and
RMI that seen use primarily inside the LANs and WANs of large corporations.
There is also a lot of work and research done on distributed computing at institutions
of higher learning.

The World Wide Web: A Document Centric Distributed Application

The point of connecting computers in large networks is to exchange information.
When we make use of our browsers to view HTML pages that are transported
over wire via HTTP over TCP/IP, we are really exercising a form of distributed
computing. Distributed computing is the process of spreading the different
components and functions of an application over a set of connected computers
in such a way that the group acts as a single system. In the case of HTTP,
which is a superb example of distributed computing, we enter a request for a
page, different computers on the net resolve which server will answer the request.
That server responds by sending back over the wire the file that represents our
requested page. The browser includes an interpreter that processes the markup
language associated with the page information so that it is rendered as the familiar
web page we know. On the Internet we have millions of machines cooperating
as a repository of astounding volumes of information.


The RPC or Remote Procedure Call Model of Distributed Computing

While serving document files is a good use of a typical request response model,
big corporations are focused on more elaborate sorts of computer interactions where
functions, procedures or services can be identified on remote computers and be
invoked to provide processing capabilities. Generally speaking, a procedure is
called on one machine and the arguments are passed off to a remote machine
on which that procedure is executed. The results of the request are returned to
the requester. This Remote Procedure Call or RPC model has evolved in different
ways, influenced by commercial interests as well as by what problems that
technology is focusing on solving.


Informal Forms of Distributed Computing

CGI or Common Gateway Interface enabled an escape from the static world of
HTTP where a document was the only response possible for a given request.
CGI used low level operating system IO to stream a request to an application
that could interpret a request and supply a dynamic response. Later, servlets,
JSPs and ASPs became very popular and enabled elaborate dynamic responses
to client requests. Servers running CGI or other related technologies in creating
a response, could reference other machines, one perhaps running authentication
software and another supplying database information.  Clearly these forms of
network application meet the criteria of being distributed computing application.


Commercial Distributed Computing Forms

Still, in the applied world of commerce, when we talk about distributed computing,
we tend to think of commercial implementations such CORBA, RMI or DCOM.

RFC 1050,  'RPC: Remote Procedure Call Specification'

Without getting bogged down in details consider the classic prototype of modern
RPC systems. The RFC 1050 was submitted in 1988 by the Network Working
Group in association with Sun Microsystems. The RFC was called 'RPC: Remote
Procedure Call Protocol Specification'. The paper is was later revised in in 1995
by Sun author R. Srinivasan and was entitled  'The RPC Remote Procedure Call
Protocol Specification Version 2'.

The paper states that 'XDR' or 'eXternal data representation' language is used as the
conduit for the messaging format. Characteristic of all distributed systems is a coding
syntax used to communicate data between clients and servers. We will see that XML
is now serving this role in Web Services.

The author of RFC 1831 describes a process where " One thread of control logically
winds through two processes: the caller's process, and a servers process. The caller
process first sends a call message to the server process and waits (blocks) for a reply
message. The call message includes the procedures parameters, and the reply message
includes the procedures results. Once the reply message is received, the results of the
procedure are extracted and the callers execution is resumed."

The following examples give us a glimpse into the mechanics of the RPC system
described in RFC 1831. The examples show that the messaging system is described
in a 'C' like language and that constants are defined to describe the flag work needed
to communicate over the network 'wire'. The examples also show that the payload for
the RPC is delivered using a 'struct' data structure that houses the reply to the procedure
invocation.

You can skip looking at the following section if you are satisfied with the notion
that different numbers are communicated to flag different meanings in the
communication protocol. If authentication and verification goes smoothly then
parameters are sent and results are returned, carried inside their appropriate
data structure.

Section 8 of RFC 1050 is quoted below.

8. THE RPC MESSAGE PROTOCOL
   This section defines the RPC message protocol in the XDR data
   description language.  The message is defined in a top-down style.
       enum msg_type {
          CALL  = 0,
          REPLY = 1
       };
       /*
        * A reply to a call message can take on two forms:
        * The message was either accepted or rejected.
        */
       enum reply_stat {
          MSG_ACCEPTED = 0,
          MSG_DENIED   = 1
       };
       /*
        * Given that a call message was accepted, the following is the
        * status of an attempt to call a remote procedure.
        */
       enum accept_stat {
          SUCCESS       = 0, /* RPC executed successfully       */
          PROG_UNAVAIL  = 1, /* remote hasn't exported program  */
          PROG_MISMATCH = 2, /* remote can't support version #  */
          PROC_UNAVAIL  = 3, /* program can't support procedure */
          GARBAGE_ARGS  = 4  /* procedure can't decode params   */
       };
       /*
        * Reasons why a call message was rejected:
        */
       enum reject_stat {
          RPC_MISMATCH = 0, /* RPC version number != 2          */
          AUTH_ERROR = 1    /* remote can't authenticate caller */
       };
       /*
        * Why authentication failed:
        */
       enum auth_stat {
          AUTH_BADCRED      = 1,  /* bad credentials (seal broken) */
          AUTH_REJECTEDCRED = 2,  /* client must begin new session */
          AUTH_BADVERF      = 3,  /* bad verifier (seal broken)    */
          AUTH_REJECTEDVERF = 4,  /* verifier expired or replayed  */
          AUTH_TOOWEAK      = 5   /* rejected for security reasons */
       };
       /*
        * The  RPC  message:
        * All messages start with a transaction identifier, xid,
        * followed by a two-armed discriminated union.  The union's
        * discriminant is a msg_type which switches to one of the two
        * types of the message.  The xid of a REPLY message always
        * matches that of the initiating CALL message.  NB: The xid
        * field is only used for clients  matching reply messages with
        * call messages or for servers detecting retransmissions; the
        * service side cannot treat this id as any type of sequence
        * number.
        */
       struct rpc_msg {
          unsigned int xid;
          union switch (msg_type mtype) {
          case CALL:
             call_body cbody;
          case REPLY:
             reply_body rbody;
          } body;
       };
       /*
        * Body of an RPC request call:
        * In version 2 of the RPC protocol specification, rpcvers must
        * be equal to 2.  The fields prog, vers, and proc specify the
        * remote program, its version number, and the procedure within
        * the remote program to be called.  After these fields are two
        * authentication parameters: cred (authentication credentials)
        * and verf (authentication verifier).  The two authentication
        * parameters are followed by the parameters to the remote
        * procedure, which are specified by the specific program
        * protocol.
        */
       struct call_body {
          unsigned int rpcvers;          /* must be equal to two (2) */
          unsigned int prog;
          unsigned int vers;
          unsigned int proc;
          opaque_auth cred;
          opaque_auth verf;
          /* procedure specific parameters start here */
       };
       /*
        * Body of a reply to an RPC request:
        * The call message was either accepted or rejected.
        */
       union reply_body switch (reply_stat stat) {
       case MSG_ACCEPTED:
          accepted_reply areply;
       case MSG_DENIED:
          rejected_reply rreply;
       } reply;
       /*
        * Reply to an RPC request that was accepted by the server:
        * there could be an error even though the request was accepted.
        * The first field is an authentication verifier that the server
        * generates in order to validate itself to the caller.  It is
        * followed by a union whose discriminant is an enum
        * accept_stat.  The SUCCESS arm of the union is protocol
        * specific.  The PROG_UNAVAIL, PROC_UNAVAIL, and GARBAGE_ARGS
        * arms of the union are void.  The PROG_MISMATCH arm specifies
        * the lowest and highest version numbers of the remote program
        * supported by the server.
        */
       struct accepted_reply {
          opaque_auth verf;
          union switch (accept_stat stat) {
          case SUCCESS:
             opaque results[0];
             /*
              * procedure-specific results start here
              */
           case PROG_MISMATCH:
              struct {
                 unsigned int low;
                 unsigned int high;
              } mismatch_info;
           default:
              /*
               * Void.  Cases include PROG_UNAVAIL, PROC_UNAVAIL,
               * and GARBAGE_ARGS.
               */
              void;
           } reply_data;
       };
       /*
        * Reply to an RPC request that was rejected by the server:
        * The request can be rejected for two reasons:  either the
        * server is not running a compatible version of the RPC
        * protocol (RPC_MISMATCH), or the server refuses to
        * authenticate the caller (AUTH_ERROR).  In case of an RPC
        * version mismatch, the server returns the lowest and highest
        * supported RPC version numbers.  In case of refused
        * authentication, failure status is returned.
        */
       union rejected_reply switch (reject_stat stat) {
       case RPC_MISMATCH:
          struct {
             unsigned int low;
             unsigned int high;
          } mismatch_info;
       case AUTH_ERROR:
          auth_stat stat;
       };

If all this 'C' code is making you nervous, relax there won't be anymore of it. We just 
want to display this primordial RFC model to show the sort of thing that is used at the 
heart of all the different distributed computing models, including the Web Services 
distributed computing model. In the case of Web Services though, instead of binary
coded C structures, text-based XML documents are exchanged. 

All RPC systems use some kind of socket connection to pass parameters of a method
invocations over a wire so that they can be processed on a remotely located computer.
They differ only in the particulars of their architectural design.

As a final note on RFC 1831, Srinivasan points out that there is little logical difference
between making procedure calls between processes both running on a local machine
as compared to making remote procedure calls on remote computers. We take advantage
of this fact when we use "localhost" to run client and server on a single machine.

Well Known Distributed Computing Applications

Over time different distributed computing systems have evolved to meet different
needs.

The Open Group & DCE

The Open Group was originally called the Open Systems Foundation. It was
merged into the X/Open group in 1996 and are famous for the database
connectivity standard that is used by both Sun's JDBC and Microsoft's
ODBC. (The Open Group can be found at www.osf.org.) The X in X/Open
seems to have been dropped sometime after 1997.  The Open Group is
arguably not as well known as the Object Management Group. It is still a
very important consortium dedicated to supporting technology neutral solutions
and improving the efficiency of information systems. The Open Group provides
testing and certification services, advanced research and support for various
standards. The Open Group has major companies as sponsors including Compaq,
IBM, Hewlett-Packard, Sun, Fujitsu, Siemens, and Motorola. The Open Group
support an API for allowing distributed programs to communicate across
heterogeneous platforms called DCE or Distributed Computing Environment.

//  big industrial consortium sponsored by companies like Compaq,
// IBM, Hewlett-Packard, Sun, Fujitsu, Siemens, and Motorola

DCE is a suite of technologies. Many major vendors provide DCE systems.
Just to select a few names from a long list of users, DCE systems are used by
Barclays Bank, Bell Atlantic Network Services,  Bell Northern Research,
Caterpillar, Citibank, The Jet Propulsion Laboratory, LEXIS-NEXIS, NASA
Hughes Technology Systems and the United States Army.

// deployed in big business and Government institutions

DCE software services are designed to operate independently of the operating
system and networking technology that applications use. As a result, it enables
interaction between clients and servers in just about any type of environment an
organization may have in place. DCE is a set of C interfaces that base  their
operations in the distributed environment on Remote Procedure Calls. DCE
services include Security, Directory, Time, Thread and Distributed File Services.

DCOM

Microsoft provides DCOM, a windows only version of DCE. DCOM or Distributed
Common Object Model is an extension of Microsoft's COM or Component Object
Model System. It supplies a distributed computing solution for the Microsoft platform.
DCOM is based on a the RPC model. Like, RMI, DCOM uses a 'skeleton' and a 'stub'
to encapsulate socket connections and allow a local object to call a method on a
remote object. On the client, the stub acts as a 'proxy' for the server side object.

Diagram of Microsoft's DCOM Architecture  // adapted from 'Developing Java Web Services" p. 14


Client   <--->                                                                                   <--> Server Object
           COM Runtime   <-->                                                  <--> COM Runtime
                                   RPC   <-->                        <-->   RPC
                                                   DCOM Protocol 

Although we offer no details of the Microsoft system, one can see that an object
on the client can call a server method mediated by a set of layers that encapsulate
a network connection.


RMI

While Microsoft's DCOM restricts to a platform, RMI or Remote Method Invocation, is
a platform independent distributed computing solution. The catch of course is that it
restricts to a specific programming language, Java. RMI takes advantage of the fact
that 'Java Virtual Machines'  or 'JVMs' are able to communicate with each other
speaking in their native Java.  Because Sun was the originator of the RPC, it was
natural for them to incorporate RPCs into their Java platform.

// interpretive compilers allow over a hundred different languages to run on the JVM including
// COBOL and Fortran so one could argue RMI is not restricted to the Java language

In a networked Java environment, Java objects can exchange arguments and return
values over the 'wire' utilizing RMI's JRMP or Java Remote Method protocol. JRMP
is a communication protocol designed for RMI which works over standard TCP/IP
connections. Java uses it's object 'serialization' process to transform objects into
serial streams that can be carried over network wire.

A dedicated RMI compiler, called 'rmic' generates Stub and Skeleton objects which
encapsulate and hide away the details of creating TCP/IP sockets to connect over
the network. This gives the illusion that calls are made on remote objects 'transparently',
as if they were present in the local environment.  An additional Remote Reference layer
coordinates data transfers between the transport layer and the stub.

The architecture of RMI is diagrammed below.

Diagram of the RMI Architectural Layers

 Client                                        Server
   |                                               |
  Stub   <-- not seen in code -->  Skeleton*
   |                                              |
 Remote                                     Remote
 Reference                                 Reference
 Layer                                        Layer
   |                                             |
Transport <-----   JRMP  ----->  Transport

* Skeletons not part of newer RMI versions

One other component that is used in RMI, a naming registry has
parallel counterparts in modern Web Service applications.
 

CORBA & The Classic Interoperability Problem

The Problem of Integrating Heterogeneous Platforms

'The Java Developer's Handbook' by Heller & Robert's describes a scenario that
many major companies found themselves in. CORBA was invented to provide a
solution to this problem. The story basically goes like this. By the mid seventies
many companies had mainframes they used for various business support chores
such as creating graphics to generate artwork used for branding and advertisement.
The mainframe would also be used for doing trend analysis and keeping track of
inventory. At the early 80s relatively cheap PCs became available and started to
proliferate in the companies various departments. The engineering department
might have acquired Unix based workstations while the art department might have
collected Apple computers. The business divisions would be adding IBM PCs
to the office. When networking became a possibility, the idea of the company
connecting all the disparate computers into a grand inter-communicating system
became very alluring. What the firms found though was the many different machines
had not been conceived or designed with intercommunication in mind. Making
many machines, with programs written in different programming languages,
resting on different operating systems and hardware communicate with each
other turned out to be a very difficult and expensive proposition.
 

The Object Management Group, OMG

This is the problem the Object Management Group was formed to address.
Initially the OMG was just a group of engineers. As time went on OMG grew
to a large consortium with over 800 member companies. The Object Management
Group came up with CORBA, the Common Object Request Broker Architecture
that allowed different types of computer platforms to intercommunicate. Besides
CORBA, the OMG are also the official custodians for other world standards.
They now oversee UML, the Unified Modeling Language, which is platform and
language neutral, object-oriented visual modeling language. They also overlook
the ODMG, which stands for Object Data Standard. ODMG provides an object-
oriented way to manage databases.
 

What is CORBA?

CORBA is described as a distributed objects framework became it is an object-
oriented distributed computing architecture. CORBA allows programs that are
written in different computer languages running on different operating systems and
hardware to communicate each other using a language neutral interface language
called IDL or Interface Definition Language. CORBA uses a ORBs or Object
Request Brokers to broker method invocations between objects running on
different machines. The secret to making the system work is that the individual
ORBs take care of translating the platform specific aspects of requests and
responses into the language neutral layer of CORBA. The OMG only maintains
the CORBA specification. It leaves commercial implementation of the standard
to ORB vendors. You can see a list of companies that have developed CORBA
solutions at www. corba.org . More famous producer's are Borland who make
Visibroker and IONA that make Orbix. As well, IBMs 'Websphere' comes with
an ORB implementation.

// IDL or Interface Definition Language , provides a neutral interface language for
// the CORBA system. Here again, a comparison can be made to Web Services where
// XML provides the neutral intermediary carrier.

The ORB      // The Object Request Broker

The ORB is the Object Request Broker. The ORB takes messages from the client,
translates them into CORBA's language neutral protocol, and transmits the message
to the target ORB that is representing the server which will respond to the request
message. The ORB on the server translates the language-neutral message back into
the native language of the server and the server provides a response to the request.
The response, in like fashion is returned back into the CORBA system and is
returned to the client.

A Detailed Description of a Client Object Interaction in CORBA

Here is a simplification of the description provided by David Chizmadia, in the table
above. The stub routine makes a native call on the ORB. The ORB transforms the native
call into a GIOP Request which contains a CDR or Common Data Representation. The
CDR can represent all the IDL types in seven basic formats that can cover every possible
interaction. The GIOP also carries an IOR or Inter-operable Object Reference that allows
the CORBA object that represents a service to publish where client ORBs can find it.
The GIOP is then passed to the transport layer. The message that is sent over IIOP or
Internet Inter-ORB Protocol for transmission over the Internet is called the transport
message.

// In detail the carrier's role is described. The Common Data Representation CDR can
// represent all the IDL types in seven basic formats that can cover every possible interaction.
// The CDR acts as a carrier for IDL types. One might think of SOAP acting as the carrier
// for SOAP types, really XML Schema types. Where CORBA sends over IIOP, Web
// Services are typically sent over HTTP over TCP/IP.

At the server the process is reversed except the parameters have to be extracted and
applied to a call on the method(s) of the CORBA objects stored on the Server. This
management of the CORBA object can be thought of as being the action of the
Skeleton, Object Adapter or a combination of both. The call on the Server objects
will be native so the return values will need to be retranslated into the neutral dialect
of CORBA and sent back to the client.

Key Points From Detailed Description of the CORBA Transaction

CORBA is similar in function to RMI but more complicated having added the extra
IDL layer to translate the differences between languages, operating systems, and
hardware. Because of the similarities, little modification of the CORBA system is
required to to support RMI over IIOP and there is a strong movement to bridge
the use of RMI with CORBA in an API called RMI-IIOP.

MOM, Message-Oriented Middleware

There is another important form of distributed computing commonly called MOM or
Message-Oriented Middleware. It is similar to the forms we spoke about earlier except
that it adds a queue to the mix to store messages so they don't require an immediate
response. This changes the system from a tightly-coupled RPC model to a loosely
coupled queued-message system. This enables nodes to communicate asynchronously.

// we will see web services offers document-centric and RPC type systems, of both
// the tightly-coupled and loosely coupled variety

MOM systems use adapters that enable one application to communicate with another.
Adding a database to supply persistence enables MOM systems to supply reliable
messaging as well. Wiley's 'Developing Java Web Services' lists SunOneMessage
Queue, IBM MQSeries, TIBCO, SonicMQ, and Microsoft Messaging Queue or MSMQ
as being popular examples of MOM type systems.


Diagram of the MOM Architectural Model

Application 1 <-->                                                               <--> Application 2   
                         Adapter <-->                            <--> Adapter
                                           MOM Infrastructure

Java supplies JMS or Java Messaging Service in the Java Enterprise Edition for
creating MOM type applications. The XML Web Services API is JAXM or Java API
for XML Messaging.


General Limitations of Current Distributed Computing Models
// outlined in Developing Java Web Services

DCOM as well as MOM systems are highly proprietary and require a certain degree
vendor lock-in. The proprietary nature of these systems have limited their the extent
to which they can communicate with each other.

There is a general inability for systems to communicate easily, e.g. for a DCOM system
to interact with an RMI based system.

Maintenance of Clients and Services in an environment that supports many different
operating systems is very complex.

These applications are designed to run on their own network ports which is not a problem
on an LAN. However, communicating across the open network brings them into conflict
with general firewall policies which typically limit open access to ports for protocols such
as HTTP, SMTP and FTP. 

Tuning such systems to provide scalability and performance consumes a great deal
of development effort.

The Biggest Problem?

The authors of "Developing Java Web Services" conclude that each of the major
distributed systems, CORBA, RMI and DCOM as well as the MOM systems all
represent large commercial development communities whose interests are strongly
tied their perspective platforms. There is not the will to make all the systems work
well together.

There is some willingness to consider a distributed computing model that may be
able to share a neutral territory. That is where XML and Web Services comes in.



Electronic Data Interchange

There is another track that has lent great impetus to the movement to Web Services.

In the very early days of the Internet, in the early 1970s, a committee called the
TDCC or Transportation Data Coordinating Committee created an electronic
communication format called the Electronic Data Interchange format. Large carriers
and shipping companies used the system to replace their large, paper-based tracking
systems. it should be noted that well known file system formats were non-existent
at this point of time. The companies would deploy their own VANs or private 'Value
Added Networks' used to exchange messages securely and without error. The
system would generate electronic receipts when a message was received. 

// EDI in the early 70s were the first B2B electronic communication system

EDI was standardized on two tracks. The North American standard was established
by the American National Standards Institute, or ANSI, under the moniker, ANSI X.12.
The United Nations supervisory body called  EDIFACT focused on supplying a global
standard.

EDI was very successful was in the health care industry. 'Health Level 7' or HL7 is
still in use by a majority of hospitals and insurance companies. Other industries have
made much use of EDI as well.

Today there is a large movement to adapt EDI for use over the Internet and XML is
being used to modernize EDI to take advantage of existing EDI infrastructure. These
large organizations with long legacies in EDI are strong supporters of the movement
to XML based Web Services.  


B2B, A2A, B2C  & SOA   // abbreviations continue to be available in limitless supply

The combined influences of these mega-organizations, have also given rise to support
for XML based loosely-coupled communication systems in other Internet based domains.
Business to Business Applications, Application to Application, and Business to Consumer
are all areas that are served well by web-based, loosely coupled distributed applications.

Loosely-coupled, web-based web services have given rise to 'SOA' or Service Oriented
Architecture which conceptualizes the various functionalities that can be made available
via distributed applications as services. Web Services are described as the loosely-
coupled services that SOA provides.

The Web Services Distributed Model

General Form of the Web Services Model   // provider, broker, and requestor

The simple description of the Web Service Model is based on three key roles,
the Service Requestor, the Service Provider and the Service Broker. The 'provider'
develops and deploys the Web service. The 'broker' (a.k.a. the registry) lists service
types, their descriptions and where they can be found. The 'requestor' invokes the
service perhaps having consulted the broker to find and subscribe to a given service.

Diagram of Basic Web Services Model


                            Service Broker
                               /              \
                            /                   \
  Service Requestor     < ---- >     Service Provider


What Distiguishes the Web Service Model From Class Distributed Systems?

Following is a summary of features that distinguish Web services from other distributed
computing models.  // summarized from 'Developing Java Web Services'

• XML is used to represent data exchanged between client and server

• Web services are Internet based and therefore should be platform agnostic

• Web services are not dependent on a particular programming language // save XML!

• Web services are XML / data-centric // not HTML / presentation-centric

• loosely-coupled web services expose application components as 'services'

• Web services will predominantly use common Internet protocols like HTTP

 
'Developing Java Web Services also mentions, that Web services will be used by
multiple client types, transactions may vary in complexity, and services will be
dynamically called using public and private registries based on industry accepted
standards. The summary also notes that J2EE, CORBA and Microsoft.NET all
are providing extensive support for web service creation and deployment.

Finally the text supplies the following compelling reasons for adopting Web services.

• Web Services RPCs easily penetrate firewalls

• Web Services are platform and language independent // again excepting XML!

• Web Services will allow heterogeneous applications to communicate

// Web services promise to facilitate changing application functions application partners


Where from here?

Before we proceed to describing the Web Services Stack, which is all written in XML
we will dedicate two classes to surveying XML and XML Schema in as much detail
as time permits. Then we will be look at Web Services Architecture in detail first focusing
on SOAP or Simple Object Access Protocol.

Exercise

// does not need to handed in but you are strongly encouraged
// to follow imitate the formula and run this client server program

In Java Web Services the key players are XML and XML Web Services dialects
that work in tandem with the different Java APIs that are used to drive the processes.
By reviewing the different distributed systems, we sought some insight into how
remote procedure calls work. We will see that the same sort of system under-pins
the Web services model.

At this time we are going to review the steps in creating a simple RMI program.
This has several important benefits. First it should provide a practical introduction
to creating a RPC application, helping us to understand the underpinnings of RMI,
and subsequently Web Services programs. Second it will refresh our use of Java
if it isn't something we are using all the time. As well, RMI is at the heart of Enterprise
Java Beans used in J2EE, the enterprise edition of Java and is a good API to be
familiar with. Finally it will come in handy when we look at Java's JAX-RPC which
uses RMI formulas to create RPC style Web Services applications.

Following is an practical explanation of RMI which can be used to create a simple
RMI program. You have two suggested options. Do one or both.

1) Compile and run the program as is.

2) Modify the program, creating a few methods of your own.
    Follow the procedure and run your RMI program.


 

Hello RMI!

Here we provide a wide angle overview of the process involved in using RMI.

The RMI Remote Interface

The process begins by creating an RMI 'remote' interface that defines the
method or methods that will be provided by the remote service. This interface
has to be compiled to generate the equivalent class object.
 

Example of an RMI interface

public interface InCoExchange extends java.rmi.Remote{
   public double lowest_asking( ) throws java.rmi.RemoteException;
   public double highest_bid( ) throws java.rmi.RemoteException;
   }

Once the interface has been compiled, an implementation of the interface has
to be generated. There are two components to providing a remote RMI service.
First there is a server component whose main job is to instantiate the 'remote'
implementation object and to 'bind' the object with a name, via a naming service.

The second part of the remote service is to provide an implementation of the
'remote' interface we defined above. This allows for two commonly taken approaches.
First, a class can be created that implements the remote interface. This class is
then instantiated inside a separate server class. The second approach combines
the server and implementation by creating an RMI server that is also the
implementation class.

Approach 1   a) Implementation implements Remote interface { }
                   b) Implementation class is instantiated inside a server class

Approach 2  a) The server class is the implementation class and implements
                      the Remote interface{ }

In this example we'll demonstrate approach 2.

Which method is better depends on what is being done. If a server's role is
to provide a set of services that may be changed over time, for instance a
set of financial or math functions, creating implementation classes that are
instantiated inside the server might be the best way to go. On the other hand,
if the service will be dedicated to a single task, it might as well be integrated
as a method of the Server class code. The example that follows shows a
Server that is also the implementation class.

The RMI Server

Observe in the following code that the java.rmi packages are imported. Also
note there are two things the server class does to allow it to qualify as a RMI
remote object. First it extends the RMI parent UnicastRemoteObject. This is
not the only way to become an RMI remote object but it probably is the
commonest. Second the class implements the remote interface we created
earlier.

In this example the server is instantiated in main( ) and this is where
the service is bound to a name. The server implements the remote interface
'InCoExchange' so has the role also of being the remote implementation.
Accordingly, it supplies the implementations for both methods that were
defined in the remote interface.
 

Example of an RMI Server also Acting as the Remote Implementation

import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.RMISecurityManager;

public class InCoServer extends UnicastRemoteObject implements InCoExchange{
 public InCoServer() throws java.rmi.RemoteException {
   super( );
   }

// Implementations of the methods of the interface InCoExchange

/*1*/
public double lowest_asking() throws java.rmi.RemoteException{
 // getLowestAsking() returns 9.50 from somewhere and is assigned to asking
    double asking;
    asking=9.50;
    return asking;
    }

/*2*/
public double highest_bid() throws java.rmi.RemoteException{
   // getHighestBid() returns 7.50 from somewhere and is assigned to bid
      double bid;
      bid=7.50;
      return bid;
      }
//If you are getting a binding exception comment out the call to setSecurityManager( )

public static void main(String[] args){
 // System.setSecurityManager(new RMISecurityManager( ));
    try{
       InCoServer inco=new InCoServer();
       Naming.rebind("InCoServer",inco);
       }
       catch(Exception e){
       System.out.println
       ("Exception: instantiating & binding the remote");
       }
    }
 }
 
 

The RMI Client

Now a client needs to be created to take advantage of the remote service. The
key aspect of the client to note, is the code that the client uses to look up the
remote service. The client also needs to be compiled.

RMI Client Code

import java.rmi.*;

public class ExCheckClient{
public static void main(String[] args){
  try{
     Remote remote_object=Naming.lookup("//localhost/InCoServer");
     InCoExchange exchange=(InCoExchange)remote_object;

     double lowest_asking=exchange.lowest_asking( );
     double highest_bid=exchange.highest_bid( );
     System.out.println("The lowest asking price for in-company stock is "
     + "$" + lowest_asking);
     System.out.println("The highest bid for in-company stock is "
     + "$" + highest_bid);
     }
     catch(Exception e){
     System.out.println
     ("Exception: looking up and accessing the remote");
     }
   }
 }

The client and the server both need to be compiled just like any other Java classes.

// Compile client and server
 

The RMI Compiler

Having compiled the implementation class in the conventional 'Java' sense,
the  rmi compiler, 'rmic', is used to generate the stub and skeleton classes.
The tool is run against the name of the compiled implementation class as is
shown in the following example.
 

The RMI Compiler Example

 C:\> rmic  InCoServer

After running the RMI compiler a check of the directory will show the
following stub an skeleton classes will have been generated.
 

Stub & Skeleton Examples

InCoServer_Stub.class
InCoServer_Skel.class
 

The RMI Registry

RMI like CORBA uses a name service to locate RMI remote services. RMI can
work with JNDI, the Java Naming & Directory Interface we mentioned in JDBC.
It also supplies a light weight registry called the RMI registry. This registry needs
to run in it's own process.

c:\> rmiregistry          // running on it's default port, 1099

Running the RMI System

This bring us to the point where the system can be run in the local environment
of the machine that is being used to develop this code. If using Windows three
DOS sessions need to be opened. First the naming registry has to be started
as is shown in the next example.

Example  C:\> rmiregistry

In another DOS window go to the directory you have been using and start the
Server as in the following.

Example  C:\> java InCoServer

Finally the Client can be run in it's separate console window.

Example  java ExCheckClient

Without any hitches, the result should be the return of the following information
to the client.

Example of Client Output

C:\> The lowest asking price for in-company stock is $9.5
The highest bid for in-company stock is $7.5