6. The grid-COMPUTING OGSA and WSRF

GRID COMPUTING
OGSA and WSRF
Sandeep Kumar Poonia
Head Of Dept. CS/IT, Jagan Nath University, Jaipur
B.E., M.Tech., UGC-NET
LM-IAENG, LM-IACSIT,LM-CSTA, LM-AIRCC, LM-SCIEI, AM-UACEE

What is OGSA, and what role it will play with the Grid?
What is the Open Grid Services Infrastructure (OGSI)?
What are Web services technologies?
Traditional paradigms for constructing Client/Server
applications.
What is WSRF and what impact will WSRF have on
OGSA andOGSI?
Outline

The Grid couples disparate and distributed heterogeneous
software and hardware resources to provide a uniform
computing environment for scientists and engineers to solve
data and computation-intensive problems. Because of the
heterogeneity of the Grid, the Global Grid Forum (GGF) [1] has
been organized as a working body for designing standards for
the Grid. Globus Toolkit 2 (GT2) and earlier versions have been
widely used for building pre-OGSA oriented Grid systems.
Introduction

TRADITIONAL PARADIGMS FOR
DISTRIBUTED COMPUTING
Traditional paradigms for distributed computing

Sockets provide a low-level API for writing distributed
client/server applications. Before a client communicates with a
server, a socket endpoint needs to be created.
The transport protocol chosen for communications can be either
TCP or UDP in the TCP/IP protocol stack.
The client also needs to specify the hostname and port number
that the server process is listening on.
1. Socket programming

The standard socket API is well-defined, however the
implementation is language dependant.
So, this means socket-based programs can be written in
any language, but the socket APIs will vary with each
language use.
Typically, the socket client and server will be
implemented in the same language and use the same
socket package, but can run on different operating
systems (i.e. in the Java case).
Socket programming

socket programming is a low-level communication technique,
but has the advantage of a low latency and high-bandwidth
mechanism for transferring large amount of data compared with
other paradigms.
However, sockets are designed for the client/server paradigm,
and today many applications have multiple components
interacting in complex ways, which means that application
development can be an onerous and time-consuming task.
This is due to the need for the developer to explicitly create,
maintain, manipulate and close multiple sockets.
Socket programming

RPC is another mechanism that can be used to construct
distributed client/server applications.
RPC can use either TCP or UDP for its transport protocol.
RPC relies heavily on an Interface Definition Language (IDL)
interface to describe the remote procedures executing on the
server-side.
From an RPC IDL interface, an RPC compiler can automatically
generate a client-side stub and a server-side skeleton.
2. RPC

With the help of the stub and skeleton, RPC hides the low-
level communication and provides a high- level
communication abstraction for a client to directly call a
remote procedure as if the procedure were local.
RPC itself is a specification and implementations such as
Open Network Computing (ONC) RPC from Sun Microsystems
and Distributed Computing Environment(DCE)RPC from the
Open Software Foundation (OSF) can be used directly for
implementing RPC-based client/server applications.
RPC

RPC
The steps to implement and run a client/server application
with RPC are:
•Write an RPC interface in RPC IDL;
•Use an RPC compiler to compile the interface to generate a
client-side stub and a server-side skeleton;
•Implement the server;
•Implement the client;
•Compile all the code with a RPC library;
•Start the server;
•Start the client with the IP address of the server.

The Java RMI is an object-oriented mechanism from Sun
Microsystems for building distributed client/server
applications.
Java RMI is an RPC implementation in Java.
Similar to RPC, Java RMI hides the low-level
communications between client and server by using a client-
side stub and a server-side skeleton (which is not needed in
Java 1.2 or later) that are automatically generated from a
class that extends java.rmi.UnicastRemoteObject and
implements an RMI Remote interface.
3 Java RMI

3 Java RMI
At run time there are three interacting entities involved in an
RMI application. These are:
1. A client that invokes a method on a remote object.
2. A server that runs the remote object which is an ordinary
object in the address space of the server process.
3. The object registry (rmiregistry), which is a name server
that relates objects with names. Remote objects need to
be registered with the registry. Once an object has been
registered, the registry can be used to obtain access to a
remote object using the name of that object.

3 Java RMI
The steps to implement and run a Java RMI client/server app are:
• Write an RMI interface;
• Write an RMI object to implement the interface;
• Use RMI compiler (rmic) to compile the RMI object to generate a
client-side stub and an server-side skeleton;
• Write an RMI server to register the RMI object;
• Write an RMI client;
• Use Java compiler (javac) to compile all the Java source codes;
• Start the RMI name server (rmiregistry);
• Start the RMI server; • Start the RMI client.

The Component Object Model (COM) is a binary standard for
building Microsoft-based component applications, which is
independent of the implementation language.
DCOM is an extension to COM for distributed client/server
applications.
Similar to RPC, DCOM hides the low-level communication by
automatically generating a client-side stub (called proxy in DCOM)
and a server-side skeleton (called stub in DCOM) using Microsoft’s
Interface Definition Language (MIDL) interface.
DCOM uses a protocol called the Object Remote Procedure Call
(ORPC) to invoke remote COM components.
4 DCOM

4 DCOM
DCOM is language independent;
clients and DCOM components can be implemented in
different languages.
Although DCOM is available on non-Microsoft platforms, it
has only achieved broad popularity on Windows.
Another drawback of DCOM is that it only supports
synchronous communications.

4 DCOM
The steps to implement and run a DCOM client/server
application are:
• Write an MIDL interface;
• Use an interface compiler (midl) to compile the interface to
generate a client-side stub and a server-side skeleton;
• Write the COM component to implement the interface;
• Write a DCOM client; • Compile all the codes;
• Register the COM component with a DCOM server;
• Start the DCOM server; • Start the DCOM client.

CORBA is an object-oriented middleware infrastructure from
Object Management Group (OMG) for building distributed
client/server applications.
Similar to Java RMI and DCOM, CORBA hides the low-level
communication between the client and server by automatically
generating a client-side stub and a server-side skeleton through
an Interface Definition Language (IDL) interface.
CORBA uses Internet-Inter ORB Protocol (IIOP) to invoke remote
CORBA objects.
5 CORBA

5 CORBA
The Object Request Broker (ORB) is the core of CORBA; it
performs data marshaling and unmarshalling between CORBA
clients and objects. Compared with Java RMI and DCOM, CORBA
is independent of location, a particular platform or programming
language.
CORBA supports both synchronous and asynchronous
communications.
CORBA has an advanced directory service called COSNaming,
which provides the mechanisms to allow the transparent location
of objects. However, CORBA itself is only an OMG specification.

5 CORBA
The steps to implement and run a CORBA client/server
application are:
• Write a CORBA IDL interface;
• Use an IDL compiler to compile the interface to generate a
client side stub and a server-side skeleton;
• Write a CORBA object to implement the interface;
• Write a CORBA server to register the CORBA object;
• Write a CORBA client; • Compile all the source codes;
• Start a CORBA name server; • Start the CORBA server;
• Start the CORBA client.

Web services are emerging as a promising infrastructure for
building distributed applications.
Web services are based on a Service- Oriented Architecture
(SOA) in which clients are service requestors and servers are
service providers.
Web services differ from other approaches such as Java RMI,
CORBA and DCOM in their focus on simple open standards such as
XML and HTTP, which have wide industry support and a chance of
becoming truly ubiquitous.
Web services provide a stratum on top of other mechanisms.
WEB SERVICES

WEB SERVICES
We define a Web service as given below.
Essentially, a Web service is a loosely coupled,
encapsulated, platform and programming language
neutral, composable server-side component that can be
described, published, discovered and invoked over an
internal network or on the Internet.

WEB SERVICES
 Loosely coupled: A Web service implementation is free to
change without unduly impacting the service client as long as
the service interface remains the same.
 Encapsulated: The implementation of a Web service is
completely invisible to the client of a service.
 Platform and programming language neutral: A Web
service can be implemented in any language and deployed on
any platform.

WEB SERVICES
Composable: A Web service can be composed from a number
of deployed services.
Server-side component: A Web service can range in scope from
a complete application to a subroutine that runs on a server.
Described: An XML-based interface is used to describe the
functionality and capabilities that a Web service can provide.
Published: A Web service can be registered with a service
registry that can be accessed on an intranet or on the Internet.

WEB SERVICES
Discovered: A Web service client can discover a service by
searching a service registry and match their service
requirements.
Invoked: A Web service can be bound to by a service client
via standard transport protocols such as HTTP or FTP.
Internal network or the Internet: A Web service can be
made available strictly within an organization or it can be
offered across the firewall, available to any consumer
connected to the Internet.

WEB SERVICES
The core standards of Web services, as defined by W3C
consortium, are SOAP , Web Services Description Language
(WSDL) and the Universal Description, Discovery and
Integration (UDDI).
Another standard for service discovery is the Web Services
Inspection (WS-Inspection) specification defined by IBM and
Microsoft.
The specification defines WS-Inspection Language (WSIL) for
service description and discovery.

SOAP
SOAP is a simple and lightweight communication protocol for
clients and servers to exchange messages in an XML format
over a transport-level protocol, which is normally HTTP.
SOAP message is encapsulated in an envelope that consists of
the following four parts:
• Various namespaces are used by the SOAP message, typically
these include xmlns:SOAP-ENV (SOAP Envelope), xmlns:xsi
(XML Schema for Instance) and xmlns:xsd (XML Schema
Definition).

WEB SERVICES
A set of encoding rules for expressing instances of
application defined data types.
 An optional header for carrying auxiliary information for
authentication, transactions and payments.
 The Body is the main payload of the message. When an
RPC call is used in the SOAP message, the Body has a single
element that contains the method name, arguments and a
Uniform Resource Identifier (URI) of the service target
address. In addition, the fault entry can be used to explain a
failure.

SOAP is independent of the underlying transport
protocol, so SOAP messages can be carried over many
transport-level protocols such as HTTP, FTP, SMTP or
more sophisticated protocols such as Java RMI JRMP
or CORBA IIOP.
HTTP is the most commonly used protocol because
it can normally pass firewalls.
Since XML is a universal standard, clients and
servers built on different platforms can communicate
with SOAP.

 WSDL is an XML-based specification that is used to
completely describe a Web service, e.g. what a service can
do, where it resides and how to invoke it.
 A WSDL interface is similar to a CORBA IDL or a DCOM
MIDL interface, but with richer semantics to describe a
service.
 WSDL defines services as a set of network endpoints or
ports using an RPC-based mechanism or a document
oriented message exchange for the communication
between a service requestor and provider.
WSDL

WSDL
An RPC-oriented operation is one in which the SOAP
messages contain parameters and return values, and
a document-oriented operation is one in which the
SOAP messages contain XML documents.
The communication in RPC-based message
exchanging is synchronous, but the communication in
Document-oriented message exchanging is often
asynchronous.

WSDL
The common elements in WSDL, as shown in Figure , are
explained below.
Data types
The data types part encloses data type definitions that are
relevant for message exchanging. For maximum interoperability
and platform neutrality, WSDL uses XML XSD as the default data
type. This part is extensible, meaning that it can contain arbitrary
subsidiary elements to allow general data types to be
constructed.

WSDL
<message>
The <message> element defines the data elements of an operation
in a service. Each message can consist of one or more parts. The
parts are similar to the parameters of a function or method call in a
traditional programming language.
<portType>
<portType> is the core part of a WSDL document. Similar to a Java
interface or a C++ class, it defines a set of abstract operations
provided by a service. Each operation uses messages defined in the
<message> element to describe its inputs and outputs.

<binding>
<binding> identifies a concrete protocol and data format for the
operations and messages defined by a particular <portType>.
There may be an arbitrary number of bindings for a given
portType, i.e. a binding can be document-oriented or use RPC.
SOAP over HTTP is the most commonly used mechanism for
transmitting messages between a service client and a service itself.
<port>
A <port> defines an individual service endpoint by specifying a
single address for a binding.

<service>
A <service> is a set of related ports. Ports within a service have
the following relationship:
• None of the ports communicate with each other.
• If a service has several ports that share a <portType>, but
employ different bindings or addresses, these are alternative
ports where the port provides semantically equivalent
behaviour. This allows a consumer of a WSDL document to
choose particular port(s) to communicate with, based on some
criteria (such as a protocol or distance).

UDDI
The UDDI is an industry standard for service registration (publication)
and discovery.
A service provider uses UDDI to advertise the services that it is making
available.
A client uses UDDI to find the appropriate service(s) for its purposes.
A UDDI registry is similar to a CORBA trader service, or it can be
thought of as a Domain Name Server (DNS) service for business
applications.
A UDDI registry has two kinds of players: businesses that want to
publish a service, and clients who want to obtain services of a certain
kind, and then use them via some binding process.

Data in UDDI can be organized in the following ways:
• White pages: This includes general information about a service
provider, such as its name, contact information and other identifiers.
• Yellow pages: This information describes a Web service using
different categorizations (taxonomies) and allows others to discover
a Web service based on its categorization (such as car manufacturing
or car sales business).
• Green pages: Green pages have technical information about a
Web service, usually with a reference to an external WSDL
document of the service, enabling the client to know how to interact
with the service.

WS-Inspection
WS-Inspection is similar in scope to UDDI; it is a
complementary rather than a competitive technology.
It allows service description information to be distributed to
any location using a simple extensible XML document format.
WS-Inspection does not concern itself with business entity
information (whereas UDDI does).
It works under the assumption that a service client is aware of
the services provided by the service provider.

The WS-Inspection specification mainly provides the
following two functions:
It defines an XML format for listing references to existing
service descriptions.
It defines a set of conventions so that it is easy to locate
WS-Inspection documents.

WS-Inspection and UDDI
The UDDI and WSInspection specifications address different sets
of issues with service registration and discovery, which are
characterized by different trade-offs.
UDDI provides a high degree of functionality, but it comes at the
cost of increased complexity.
The WS-Inspection specification provides less functionality in
order to maintain a low overhead. With this in mind, the two
specifications should be viewed as complementary technologies,
to be used either together or separately depending upon the
situation.

Service discovery with UDDI and WS-
Inspection

6. The grid-COMPUTING OGSA and WSRF

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 6. The grid-COMPUTING OGSA and WSRF

Similar to 6. The grid-COMPUTING OGSA and WSRF (20)

More from Dr Sandeep Kumar Poonia

More from Dr Sandeep Kumar Poonia (20)

Recently uploaded

Recently uploaded (20)

6. The grid-COMPUTING OGSA and WSRF