Distributed Computing with Object Protocols

loyalsockvillemobΔίκτυα και Επικοινωνίες

27 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

88 εμφανίσεις



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
1

of
15



Distributed Computing with Object Protocols



What is an Object Request Broker?


The use of Object Request Brokers (ORBs) is a means of creating distributed computing environments.
One
-
way in which to implement these ORBs is through the Object Managemen
t Group’s (OMG)
Distributed Object Model (DOM). MTS/COM/DCOM, CORBA and EJB/JavaRMI are all examples of this
implementation and function through a client
-
server model as seen in Figure 1.














In each case there are two significant components th
at make the model possible, the Interface Definition
Language (IDL) and the Internet Inter
-
ORB Protocol (IIOP). When a component is created, it places its
public interfaces in the interface repository via a "stub". EJB supports passing entire Java object
s in this
way. An application object (client) requesting a service, submits its request to the ORB, which, in turn,
searches the interface repository for an object (server) that can provide the requested data. The IIOP
provides the mechanism for ORBs to
communicate server requests across the Internet in a platform
independent manner.


The following table, compiled from [1] contains a comparison of the attributes of the three major DOMs.


Evaluati on
criteria

MTS/COM/DCOM

CORBA

EJB/JavaRMI

Application
area

Desktop applications.

Enterprise applications.

Evolving.

Platform

Windows, Unix and Linux and
MacOs

Platform independent

Platform independent

Programming

languages

Language independent

Language independent

Tied to Java

Objects
services

Object services
are implemented
quite extensively by Windows
NT.

Many, not all supported
by providers.

Developing rapidly, not yet
as mature as those of COM

Security
aspects

Active X security systems rely on
human judgment.

Many CORBASEC
implementations.

Java security re
lies entirely
on software technology.

Exchanged
data type

Complex types that will cross
interface boundaries must be
declared in the IDL.

Complex types that will
cross interface
boundaries must be
declared in the IDL.

Any serializable Java object
can be p
assed as a
parameter across processes.

Limited State
and
Persistence
Management.

Does not support a distinction
between transient and persistent
object, automatically flushes all
object states at the end of every
CORBA specifies a

Persistence Service that
provides means for
retaining and managing
EJB technology supports
stateless and stateful
transient and persistent
objects.

Figure
1

-

DOM



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
2

of
15

transaction. Developers must
manage all co
nversational states.

the persistent state of
objects.

Transaction

management

COM componen
ts must still
implement some transactions
code within the application logic.
MTS applications don't have
much flexibility to override the
automatic transaction services.

CORBA specifies a

Transaction Service that
supports multiple
transaction services.

No
transaction code within
the application logic
required, Enterprise Bean
can completely control its
transaction behavior

Garbage
collection

Attempts to perform distributed
garbage collection on the wire by
pinging.

Does not attempt to
perform general
-
purpo
se
distributed garbage
collection.

Attempts using JVM
mechanisms.

Table
1

-

DOM Evaluati on Criteria


This paper will discuss in light detail the background and operation of each of these three distributed object
models. The first
to be covered will be the Distributed Component Object Model, followed by the
Common Object Request Broker, and finally the Simple Object Access Protocol.


DCOM


The Distributed Component Object Model (DCOM) originally created by Microsoft is one of distri
buted
computing’s popular distributed object models. A distributed extension of the Component Object Model
(COM), and often referred to as ‘Com on the wire”, it adds an object remote procedure call (ORPC) layer
on top of the DCE Remote Procedure Call (RPC
) layer of COM. By interacting with COM’s run time
services, DCOM provides the system a means by which to support remote objects. By allowing
communications between computers in Local Area Networks (LANs), Wide Area Networks (WANs) and
even on the Intern
et, DCOM provides a means through which developers can fully utilize the distributed
environments of modern computing. Though originally developed for Windows by Microsoft, DCOM is
also available for other operating systems, including UNIX and Linux. DCO
M has a draft standard
currently being reviewed by the Internet Engineering Task Force (IETF).


Objects in a DCOM system function in a client
-
server type relationship when they communicate. When
requesting service, the client will invoke a method that is
used by the remote object, which then becomes
the server in the client
-
server model being used. All activities associated with the server object are handled
through “interfaces” to the object. The Interface Definition Language (IDL) packaged with the DCO
M
system describes these “interfaces”. DCOM differs in this way from CORBA. Where CORBA uses
multiple inheritance at the IDL level, DCOM, instead, allows objects to have multiple interfaces and thus
achieves the same goals as CORBA’s multiple inheritance
. The interfaces that are defined by the IDL, in
the form of a configuration file, become the contract between the server and all of its clients.


The actual communications between the client and server objects in a DCOM system are implemented
through an
object oriented Remote Procedure Call (RPC) communications set up.


Looking at the diagram following this paragraph, when a client wants to call a function from a remote
object, it must first make a call to the client stub. The stub then puts the paramete
rs of the procedure call in
to a request message that is sent across the network through the wire protocol for the actual hardware being
used by the network. Once received by the server and its wire protocol has handed the request message to
the server st
ub, the massage is stripped and the packed parameters are used to call the function originally
requested. In DCOM terminology the client stub is referred to as the proxy and the server stub is simply
referred to as the stub.







Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
3

of
15



Figure: RPC Diagram



T
he following diagram shows a high level depiction of the DCOM architecture as used on Microsoft’s own
website for the DCOM object model [8].
















Figure: DCOM Architecture


At this point we will mention that DCOM supports both
Transport Control
Protocol/Internet Protocol
(
TCP/IP) and Hyper Test Transfer Protocol (HTTP) communications for its network communications,
making it usable on most network hardware configurations. Other protocols supported include UDP/IP,
IPX/SPX and Appletalk. Also of
immense interest to developers of distributed applications and systems is
the fact the COM, and DCOM, are language independent. This means that component of a DCOM system
can be written in any number of different programming languages like C++, Java, Obje
ct Pascal (Delphi),
Visual Basic and even COBOL.


Since DCOM is simply an extension to COM for the wired world, we must understand how COM works
first. From there DCOM simply packs and prepared object requests for transfer across distinct systems.


At a m
ost basic level we have an application running in a COM system. We also have a COM object that
the application needs in order to continue its activities. Each of these objects has a set of interfaces, which
act as the only means of contact between itself

and the outside world. As long as the client application has
a means to access one of the interfaces, then it may use the object and its procedures. The next figure
provides a description of this system.




Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
4

of
15


Figure: Application/Object Interface


Every COM object runs inside of a server. A single server can support multiple COM objects. As shown in
the following figure, there are three ways in which a client ca
n access COM objects provided by a server:

1.

In
-
process server: The client can link directly to a library containing the server. The client and
server execute in the same process. Communication is accomplished through function calls.

2.

Local Object Proxy: The

client can access a server running in a different process but on the same
machine through an inter
-
process communication mechanism. This mechanism is actually a
lightweight Remote Procedure Call (RPC).

3.

Remote Object Proxy: The client can access a remote
server running on another machine. The
network communication between client and server is accomplished through DCE RPC. The
mechanism supporting access to remote servers is called DCOM. [7], [8]




Figure: COM Object Access Methods


If the client and server are in the same process, the sharing of data between the two is simple. Some
alterations must be made, however, when the server and client processes are se
parated. COM/DCOM must
format and bundle the data in order to share it across the system. The process of preparing the data for
transmitting is called marshalling (unmarshalling would be the process of removing the necessary data
from the packet in which

it was sent). The proxy and stub objects, mentioned earlier, are responsible for
the cross process communications details for all interfaces, and are, therefore, responsible also for the
marshalling of all requests whose destination reside on another pro
cessor. The next figure depicts the
system.



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
5

of
15



Figure: Cross
-
Process Communication


The client calls the interfaces of the server through the proxy, which mar
shals the parameters and passes
them to the server stub. The stub unmarshals the parameters and makes the actual call inside the server
object. When the call completes, the stub marshals return values and passes them to the proxy, which in
turn returns the
m to the client. The same proxy/stub mechanism is used when the client and server are on
different machines. However, the internal implementation of marshalling and unmarshalling differs
depending on whether the client and server operate on the same machin
e (COM) or on different machines
(DCOM). Given an IDL file, the Microsoft IDL compiler can create default proxy and stub code that
performs all necessary marshalling and unmarshalling. [7], [9]

Now that we have a basic understanding of how COM and DCOM wor
k, we will now discuss some of the
weaknesses of COM/DCOM. Although one of the more popular distributed object models in use these
days, it does suffer from some drawbacks and weaknesses. This includes the difficulty in using COM and
DCOM. The developer

is required to have a strong knowledge of COM specification in order to properly
use the system. Also, COM is not considered robust enough for “enterprise deployment” [9]. This second
problem, however, was fixed in DCOM and is discussed next.

Some other

issues to consider when discussing COM/DCOM are platform support and security. Although
COM and DCOM are best supported on Windows 95 and NT, Microsoft has released a version of
COM/DCOM for MacOS that supports OLE
-
style compound documents and the creati
on of ActiveX
controls. Software AG, a Microsoft partner, has released DCOM for some UNIX operating systems,
concretely OS/390, HP
-
UX 11.0, SUN Solaris, AIX 4.2, 4.3, Tru64 Unix 4.0 and Linux. However, DCOM
over non
-
Windows platforms has few supporters. Un
til DCOM for alternate platforms has solidified, the
technology is best applied in environments that are primarily Windows
-
based [8]. As for security, since
COM/DCOM components have access to a version of the Microsoft Windows API, "bad actors" can
potent
ially damage the user's computing environment. In order to address this problem, Microsoft employs
"Authenticode" which uses public key encryption to digitally sign components. Independent certification


Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
6

of
15

authorities such as VeriSign issue digital certificat
es to verify the identity of the source of the component.
However, even certified code can contain instructions that accidentally, or even maliciously, compromise
the user's environment [8].



CORBA

Extending ORBs for Real
-
Time


The following table was co
mpiled from [2] and summarizes the attributes of a real
-
time processing that our
ORB
-
based distributing architecture must support.


Configurability

Small, sometimes static, implementations facilitating efficient use of scare
computing resources and proof o
f correctness.

Predictability

Time and resources for transactions and system services known, again
sometimes leading to static system configuration.

High Performance

Embedded real
-
time will often trade
-
off features for performance. Also, a
bound on reco
very time from faults is needed.

Assurance of Correctness

Support formal verification or redundancy

Resource Management

Asynchronous requests, pre
-
allocation and knowledge of all possible sources
of unbounded blocking.

Prioritization Issues

Thread
-
safe,

priority inversion limiting with priority based dispatching and
queuing.

Table
2

-

Real
-
Time Criteria

Minimal CORBA and the RT
-
CORBA specification address these issues and have provided a framework
upon which embedded, real
-
time s
ystems can be developed in CORBA. Figure 2, from [3], illustrates the
components of a real
-
time CORBA system depending upon a real
-
time ORB core and services (providing
thread and priority control, messaging, etc.) in line with the above
-
mentioned specific
ations. Also needed,
is an OS Kernel that provides real
-
time scheduling, etc. such as the services provided in real
-
time, COTS
operating systems (e.g. VxWorks).


The primary extension to the DOM architecture for real
-
time is the concept of Thread Pools.
Thread pools bound the
amount of memory resources, such as stack space, they
consume and can be optionally configured to buffer or not
buffer requests.
A statically configured thread pool can
provide deterministic behavior and resource usage and leads
to e
asier proof of correct operation. A global scheduling
service is also typically added to support the thread pools.


Explicit binding in the communication resources is also
typically added. This allows a channel of communication to
be opened with statical
ly determined objects, which again
can provide determinism in calculating the response time of
server to client.





Extending ORBs for Fault Tolerance


Fault
-
Tolerance involves replication and redundancy. In this domain, that involves replicating the ob
jects
(and possibly the clients) that provide services to the system and providing a network that supports loss of
communication over a given link. The replication of objects can be done either with active replication
Figure
2

-

Real
-
Time CORBA Architecture



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
7

of
15

(more than one node performing the ca
lculations) or passive replication (where the state at a checkpoint is
sent to all nodes as computed by only one). The network fault tolerance can be done within the network
link (as with MIL
-
STD
-
1553) or explicitly with multiple network links and a fault
-
tolerant protocol.


Two possible implementations in CORBA, which use unmodified ORBs are interceptor and service
providers. The Fault Tolerant CORBA (FT
-
CORBA) specification (discussed in [4]) contains both of these
strategies. FT
-
CORBA uses interopera
ble group references (IOGR) to refer a service request to a grouped
set of replicated objects. Also specified are Replication Managers which manage passive and active groups
and the Fault Detectors/Notifiers which use a specified pull or push based monito
ring scheme to detect
object failure and notify the Replication Manager of a failure. A Logging and Recovery mechanism is also
specified which records the GIOP traffic and plays it back to the (new) primary objects during recovery.


CORBA Implementation E
xamples

Eternal

The design goals of the Eternal project are grand [5]: To “provide fault tolerance transparently to the
application using CORBA without modifying the ORB.” Eternal achieves this by adding a “Totem” or
multicast group communication layer an
d the “Eternal” or replication/resource/interceptor layer between
the ORB and the operating system/platform layer as shown in
Figure
3
. Eternal’s Replication Manager
allows for active and passive replication model
s and performs the functions of filtering out duplicate
operations in the active model and state consistency management for the passive case.



Figure
3

-

Eternal Architecture

Eternal provides a mechanism called Object Groups (as
illustrated in
Figu
re
4
) that combine tightly coupled
application objects together. One such grouping is replicated objects used for fault tolerance. This appears
to provide an interesting option to the system de
signer in the form of object groupings that could be
logically mapped to the physical processor boxes in a system. In this way, the tightly coupled processors in
a unit could be looked upon as providing a “service group” to the rest of the system.




Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
8

of
15


Figu
re
4

-

Eternal Object Groups

Because Eternal is designed to be used with an unmodified CORBA ORB, the designers have been working
concurrently with RT
-
CORBA ORB vendors (such as TAO) to develop a fault
-
tolerant real
-
time
architectu
re. The thrust of that research and development is to get performance and predictability into the
Totem layer, Replication Manager and Logger and to provide guidance on application development
practices that help to insure real
-
time performance. The auth
ors talk about the need to sanitize sources of
non
-
determinism in the application code, such as removal of system calls and poorly controlled direct
hardware access to insure deterministic performance of the system.

DOORS

Distributed Object
-
Oriented Reliab
le Service (DOORS) [4] has been modified to support a (or more
accurately it helped drive the standard of) FT
-
CORBA service type implementation with an eye towards
real
-
time performance as well.
Figure
5

illustrat
es the components of the DOORS architecture, of
particular interest is the implementation of local Fault Detectors (object groups) and system/host level
Super Fault Detectors which monitor the system via heartbeats. This implementation is also interesting

in
terms of processor boxes as it enforces a hierarchical fault detection and recovery scheme.



Figure
5

-

DOORS Architecture

DOORS has also looked to TAO to provide a real
-
time (or more weakly called High Performance) ORB for
t
heir implementation. They discuss in [4] the requirements for efficient IOGR parsing and reliable and


Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
9

of
15

efficient retry IOGR requests that must be implemented by the ORB to make it suitable in this domain.
The DOORS group also discusses wrangling with th
e issues of FT
-
CORBA service overhead, the trade
-
off
of desiring shorter polling intervals (to reduce failure detection time) verses end
-
to
-
end message latency
and the trade
-
off of passive schemes in reducing needed computer resources verses obtaining quic
k and
bounded recovery times in the passive case. With strong attention to these details, a reasonable real
-
time,
fault
-
tolerant CORBA implementation can be had with DOORS.

Distributed Component Architecture (DCA)

Distributed Component Architecture [6] ex
tends the CORBA environment with a real
-
time interface and
fault
-
tolerant interface implemented in IDL. A shown in
Figure
6
, DCA provides an API, which interacts
with a supplementary real
-
time invocation monitor a
nd scheduler to provide deterministic application
behavior.


Figure
6

-

DCA Interface

Replicated components (fault tolerant applications) are realized with specialized group adapters which
handle routing requests to the primary o
bject, broadcasting the state of the replicated objects and the
handling of negotiation for new prime objects based on fault exceptions. The Integration Tool (interacting
with the IDL defined interfaces), a compile
-
time tool suite as shown in
Figure
7
, is used to generate the
glue code necessary to realize components with real
-
time or replicable services attached and then generate
the adapters necessary to interface to the CORBA layer.




Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
10

of
15


Figure
7

-

DCA Integration

The DCA approach is implemented on Solaris and NT and so unfortunately considers “real
-
time” as the
barely sub
-
second domain. With a port to a real
-
time O/S however, DCA could provide all of the hooks
needed to fulfill our requir
ements.



SOAP


Simple Object Access Protocol


Introduction


As the Internet has flourished and computing has moved away from closed, tightly coupled systems to
more open, distributed environments, the need for a platform
-
independent method of data exchan
ge has
emerged. At the same time, XML has exploded onto the scene, providing the perfect vehicle for a new
paradigm for object and service access. XML, coupled with the many Internet communication standards
such as HTTP, is the perfect solution for providi
ng truly decentralized, platform
-
independent information
exchange. The bridge between numerous different systems running different software under different
network conditions can easily be bridged with this technology. Microsoft has developed a standard th
at
makes use of XML to represent data and messages, and HTTP as a transport mechanism. This standard is
known as SOAP


Simple Object Access Protocol. The goal of SOAP is to provide a lightweight protocol
for remote object access with an eye on extensibili
ty and simplicity.


SOAP Structure


The basic protocol for SOAP is that the sender generates an XML document known as a SOAP envelope,
and it is delivered to the receiver over HTTP. It should also be noted that SOAP may use other transport
protocols such a
s SMTP or FTP, but the focus has been on HTTP, and this is the typical transport. One
advantage of using HTTP is nodes that are hidden behind firewalls are typically able to send and receive
HTTP messages safely and securely. HTTP is also a highly mature a
nd reliable protocol that virtually any
computer can use, which eliminates the need for a custom communication protocol to be developed for
SOAP.


A SOAP transaction begins by the sender sending the SOAP envelope to the remote node using an HTTP
POST oper
ation. The recipient will then analyze the contents of the envelope and perform some action. The
reply is sent back to the sender as a normal HTTP response, in which is embedded another SOAP envelope.
This will contain the response information, or any erro
r messages if pertinent.



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
11

of
15


The following is an example SOAP request, and the resultant SOAP reply.


Example SOAP Request


POST /StockQuote HTTP/1.1

Host:

www.stockquoteserver.com

Content
-
Type: text/xml;

charset="utf
-
8"

Content
-
Length: nnnn

SOAPAction:

"
Some
-
URI"


<SOAP
-
ENV:Envelope


xmlns:SOAP
-
ENV="http://schemas.xmlsoap.org/soap/envelope/"


SOAP
-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">


<SOAP
-
ENV:Body>


<m:GetLastTradePrice xmlns:m="Some
-
URI">


<symbol>DIS</symb
ol>


</m:GetLastTradePrice>


</SOAP
-
ENV:Body>

</SOAP
-
ENV:Envelope>


Example SOAP Reply


HTTP/1.1 200 OK

Content
-
Type: text/xml;

charset="utf
-
8"

Content
-
Length:

nnnn


<SOAP
-
ENV:Envelope


xmlns:SOAP
-
ENV="http://schemas.xmlsoap.org/soap/envelope/"


SOAP
-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


<SOAP
-
ENV:Body>


<m:GetLastTradePriceResponse xmlns:m="Some
-
URI">


<Price>34.5</Price>


</m:GetLastTradePriceResponse>


</SOAP
-
ENV:Body>

</SOAP
-
ENV:Envelope>



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
12

of
15


A SOAP message is structured in the following manner. On the “outside” is the SOAP envelope. This is the
wrapper around all the SOAP data. Any other XML content outside the SOAP envelope is ignored during
SOAP processing. Within the envelope are the head
er and the body. The header is actually a series of
headers that provide processing instructions to the nodes that receive a SOAP envelope. An interesting
feature of SOAP is the ability for there to be SOAP Intermediaries which are nodes that receive and p
rocess
SOAP messages, but are not the final destination of the message. The headers can be used to supply
instructions to these intermediaries as how to process and/or route a particular SOAP message. One of the
extensible features of SOAP is the ability f
or application
-
specific headers to be inserted in a SOAP
message. These could be used for processes such as authentication or transaction management. Following
the header(s) is the SOAP Body. The Body contains the actual XML payload that is delivered to th
e final
destination. Since SOAP is designed as an object access framework, the Body is typically some sort of
remote procedure call (or a reply to an RPC call). The only Body content defined by SOAP itself is a Soap
Fault. A receiver may reply with a SOAP
Fault (within a SOAP envelope) for errors such as an invalid
object request or a version mismatch or any number of application
-
specific errors. By encoding all faults
within a SOAP Fault message, error reporting and processing is simplified.


RPC Requests
in SOAP


One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and
flexibility of XML. Therefore, SOAP provides a predefined encoding style for encoding data types.
However, the user is not required to adhere to t
his encoding style, and may use one of his or her own
creation. The default SOAP encoding style is very powerful and allows for XML representation of simple
types, enumerations, byte arrays (using BASE64), structs, arrays of structs, partial arrays, sparse

arrays,
compound types and even polymorphism.


The process of issuing an RPC request via SOAP requires the following: the URI of the target object, a
method name, an optional method signature, the parameters to the method, and optional header data. As
men
tioned before, using SOAP for RPC is orthogonal to the SOAP protocol binding. In the case of using
HTTP as the protocol binding, an RPC call maps naturally to an HTTP request and an RPC response maps
to an HTTP response. However, using SOAP for RPC is not
limited to the HTTP protocol binding. The
only caveat with other protocol bindings is that SOAP relies on it to provide a mechanism for carrying the
URI. Again, HTTP provides a logical protocol binding since URI for the resource that the invocation is
bein
g made against is simply the HTTP request URI.


Once the RPC request has been received and processed by the destination, it will issue the RPC response in
the form of a SOAP envelope, which is in return issued back to the originator using an HTTP response.

Again, the return value from the method is encoded using the same encoding scheme as the request. If the
method fails, a SOAP Fault is returned, as discussed earlier.


In the following section we explore an important technology that is built upon SOAP in
an effort to achieve
the goal of platform
-
independent distributed computing.


WSDL


Web Service Description Language


In order to utilize a service on a remote server using SOAP, one needs to understand what the remote
service is capable of. A technology
built on SOAP, WSDL provides a language for querying entities to
learn about their capabilities, as well as the ways in which they represent data types and commands. WSDL
is essentially an XML grammar. It is very similar in concept as IDL (interface defini
tion language), except
that IDL is platform specific, while WSDL is platform independent. In more technical terms, WSDL is an
XML format for describing network services as a set of endpoints operating on messages containing either
document
-
oriented or proc
edure
-
oriented information. The operations and messages are described
abstractly, and then bound to a concrete network protocol and message format to define an endpoint.
Related concrete endpoints are combined into abstract endpoints (services).




Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
13

of
15

The simpl
est way to think of WSDL is to picture a remote object that has some distinct functionality that
may be accessed via various methods. To access this object, one must know how to call its methods, as
well as what parameters (and their types) are required. I
f the object were to publish this functionality in a
standardized format, then one would know how to use the object and the services it provides. WSDL is the
standardized language in which objects can accomplish this. An example WSDL document follows.


<?
xml version="1.0"?>

<definitions name="EndorsementSearch"


targetNamespace="http://namespaces.snowboard
-
info.com"


xmlns:es="http://www.snowboard
-
info.com/EndorsementSearch.wsdl"


xmlns:esxsd="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"


x
mlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"


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



<message name="GetEndorsingBoarderRequest">


<part name="body" element="esxsd:GetEndorsingBoarder"/>


</message>



<message name="GetEndorsingBoarderRespo
nse">


<part name="body" element="esxsd:GetEndorsingBoarderResponse"/>


</message>



<portType name="GetEndorsingBoarderPortType">


<operation name="GetEndorsingBoarder">


<input message="es:GetEndorsingBoarderRequest"/>


<output message=
"es:GetEndorsingBoarderResponse"/>


<fault message="es:GetEndorsingBoarderFault"/>


</operation>


</portType>



<binding name="EndorsementSearchSoapBinding"


type="es:GetEndorsingBoarderPortType">


<soap:binding style="document" tra
nsport="http://schemas.xmlsoap.org/soap/http"/>


<operation name="GetEndorsingBoarder">


<soap:operation


soapAction="http://www.snowboard
-
info.com/EndorsementSearch"/>


<input>


<soap:body use="literal"


namespace="http://schema
s.snowboard
-
info.com/EndorsementSearch.xsd"/>


</input>


<output>


<soap:body use="literal"



namespace="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"/>


</output>


<fault>


<soap:body use="literal"


nam
espace="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"/>


</fault>


</operation>


</binding>



<service name="EndorsementSearchService">



Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
14

of
15


<documentation>snowboarding
-
info.com Endorsement Service</documentation>


<port name="GetEn
dorsingBoarderPort"


binding="es:EndorsementSearchSoapBinding">


<soap:address

location="http://www.snowboard
-
info.com/EndorsementSearch"/>


</port>

</service>


While it may be fairly verbose, the document simply defines the service that t
his object provides
(EndorsementSearchService), as well as the various messages and method calls that it will respond to.
Using this information, an application/user could access the object by calling its methods using SOAP
messages. Without this WSDL spec
ification, the remote object would have to explicitly tell the user
beforehand about its services and methods. Since WSDL allows this information to be published publicly
for anyone to read, this also allows the object to be accessed by anyone who seeks th
e functionality it
provides.


This is the core idea behind UDDI
-

Universal Description, Discovery and Integration. The goal of UDDI is
to set up a distributed directory of web services which anyone may search to find a service provider.
Service providers
may register and publish their services (using WSDL). A user, upon searching and
finding a provider for the service required, may read that provider’s WSDL document and then begin
transacting with it using SOAP. This is a truly global, industry
-
wide initia
tive that standardizes how
business can publish information about their services and products, as well as how businesses may integrate
into each other’s systems and processes. This streamlines the process of seeking out a service provider, and
actually con
ducting the service transaction. All of this is done on the core technologies of SOAP, HTTP,
WSDL and XML


all of which are platform independent. Both WSDL and UDDI are backed by such
important companies as Ariba, Microsoft and IBM.


Summary


The Future
of Distributed Computing?


With the advance of technologies such as XML, SOAP and WSDL, it is possible to imagine a distributed
computing environment that is truly platform
-
independent and non
-
vendor specific. SOAP, WSDL and
XML applications are simple to
write, and can be written in virtually any language. No matter what
language is used or on what platform they are based, these applications will still be interoperable. These
simple yet robust solutions provide a powerful, extensible framework for distribu
ted computing that can be
standardized globally. Undoubtedly these technologies will grow and evolve rapidly as they are still in their
infancy. As time passes and they solidify, they could very well form the foundation of the future of
distributed computi
ng.







Group A1: Crabtree,
MacFarlane & Williamson

CSE 8343
-

Advanced Operating Systems

Object
Request Brokers

10/29/01

Page
15

of
15


References


[1]

"GNOSIS


The Virtual Factory, Deliverable DT2.1a, INTEGRATION PLATFORM
TECHNICAL ISSUES", The GNOSIS
-
VF Consortium, April 2001.


[2]

Samson, J.R., Jr.; Markiewicz, C., "Adaptive resource management (ARM) middleware
-
the path
for u
sing COTS in space", in Aerospace Conference Proceedings, 2000 IEEE


[3]

Christopher D. Gill, Fred Kuhns, David L. Levine, and Douglas C. Schmidt, "Applying Adaptive
Real
-
time Middleware to Address Grand Challenges of COTS
-
based Mission
-
Critical Real
-
Time

Systems"
presented at the 1st International Workshop on Real
-
Time Mission
-
Critical Systems: Grand Challenge
Problems, November 30, 1999; Phoenix, Arizona USA.


[4]

Natarajan, B.; Gokhale, A.; Yajnik, S.; Schmidt, D.C., “DOORS: towards high
-
performance fau
lt
tolerant CORBA", in Distributed Objects and Applications, 2000. Proceedings.


[5]

P. Narasimhan, L. E. Moser, P. M. Melliar
-
Smith, “Exploiting the Internet Inter
-
ORB Protocol
Interface to Provide CORBA with Fault Tolerance”,
Proceedings of the
USENIX

1997

Third USENIX Conference on Object
-
Oriented Technologies (COOTS)


[6]

Yau, S.S.; Bing Xia, "An approach to distributed component
-
based real
-
time application software
development"
, in
Object
-
Oriented Real
-
time Distributed Computing, 1998. (ISORC 98) Proceedings.


[7] Microsoft Corporation.
The Component Object Model Specification
, Version 0.9, October 24, 1995
[online].

[8] Microsoft Corporation.
Distributed Component Object Model
Protocol
-
DCOM/1.0, draft, November
1996 [online].

[9] Foody, M.A. "OLE and COM vs. CORBA."
UNIX Review 14
, 4. (April 1996): 43
-
45.

[10] Microsoft home page [online].