GRID COMPUTINGOGSA and WSRF

Sandeep Kumar PooniaHead 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 FORDISTRIBUTED 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

RPCThe 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 RMIAt 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

3 Java RMIThe 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

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 CORBAThe 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.

5 CORBA

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

WSDLThe 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