BANNARI AMMAN INSTITUTE OF TECHNOLOGY SATHYAMANGALAM

Department of Information Technology

Class IV IT A&B

Subject Code 11I010

Subject GRID COMPUTING

Prepared By Arun Shalin L.V & Aiswarya Devi VJ

Time: 75 mins

Unit No. &

Lesson. No

(4/4)

1.

Content List: OGSA Implementation

2.

Skills Addressed:

Reading, Questioning, Drawing mind map, Summarizing, Discussion, Drawing Diagrams,

Expressing orally and in writing.

3. Objectives:

1. To gain basic knowledge of OGSA Services

2. To gain the knowledge about Service models and Fault Handling of OGSA

4. Lesson Links:

Concepts/ ideas/ formulae /definition/laws etc

5. Alpha Breathing : (1 Min)

The three steps for alpha breathing are

Breathe in

Breathe out

Hold

(Repeat the three steps for 8 times)

6. Evocation and In-depth teaching:( 35-40 mins)

A grid service is a stateful Web service. Because of this architecture model design fact,

theservice data concept requires the OGSI to identify a common mechanism to expose the

state dataof the service instance to the service requestor of the query, the update action

itself, and finallyenable the change notification to occur. In this case, the OGSI utilized the

"service datadeclaration" as a mechanism for publicly expressing the available state

information of a service.This concept, however, is not limited to grid services.

The service data concept can be extended to any stateful Web service for declaring its

publicly available state information through the service data concepts. Therefore,

developers that were exposed to some of the more traditional distributed technologies, and

their interface declaration (IDL) approaches, will be familiar with this somewhat similar

concept. Some of the object-oriented distributed language interfaces use attributes

declaration to indicate the exposed state/properties of the services they describe .The

following describes the service data concepts introduced by the OGSI specification:

Service data declaration (SDD) is a mechanism to expose a publicly available state of a

service.

Service data elements (SDE) are accessible through the common grid service

interfaces("findServiceData" and "setServiceData").

The internal state of a service should not be a part of the service data declaration.Provided

that we have now discussed the usability of service data, let us now explore theconcepts,

semantics, and usage model of service data in the context of a grid service.

Types of Service Data Elements and Service Data Values

Every service instance has a collection of service data elements it exposes through

publicinterfaces. These service data elements can be classified into two types of attributes,

based uponthe creation semantics. These are:1.

Static. Declared as part of the service's interface definition (GWSDL portTypedefinition).2.

Dynamic. Added to a service instance dynamically. This behavior is

implementationspecific. The client may know the semantics (type and meaning) of the

service data, orcan acquire that information from somewhere (service or third party)

through meta-dataexchange.For example, in order to process the dynamic SDE values, you

may need to get the schema typeinformation for the SDE values from a remote location.

Grid Service: Naming and Change Management Recommendations

This is a critical area in distributed systems where a service may undergo changes,

including thepublicly available interface and/or implementation, over some specified period

of time. Let usnow explore how these changes are handled in OGSI Grid services, and what

best practices oneshould adhere to when dealing with such dynamics.One should contend

with the semantics of grid services as follows:

The semantic of a grid service instance must be well defined by its interface definition;

acombination of portTypes, operations, messages, types, and service data declarations.

The implementation semantics must be consistent with the interface semantics;otherwise, it

may confuse the client and may result in wayward behavior.Based on the previous

observations, here are some important best practices to consider:

Service interfaces and implementations should agree on the semantics of the service.

If there is a change to the interface (e.g., syntax and/or semantics) it is recommended

toprovide a new interface to the client, as opposed to changing the existing interface.

All the elements of a grid service element must be immutable. This means that the QName

of the portType, operation, message, service data declaration, and associated types are

immutable. Any changes in any of these should result in a new interface port Type.

New interfaces should always be created using a new portType QName (i.e., a local name

and a namespace combination).

Grid Service Instance Handles, References, and Usage Models

Every grid service implemented utilizing the OGSI specification should adhere to certain

practices, which are important to the overall integrity of the service. One or more GSHs

must be unique. This is key due to the fact that these handles uniquely identify a grid

service instance that is valid for the entire life of a service. However, handles do not carry

enough information to allow a client to communicate directly with the service instance. The

service's GSH is based on a URI scheme

(e.g., http://) and the specific information (e.g,abc.com/myInstance).Some examples of

these binding formats include the following:

Interoperable object reference (IOR) for clients utilizing the Remote

MethodInvocation/Internet Inter-ORB Protocol (RMI/IIOP)

WSDL for clients utilizing the SOAP protocol

.NET remoting referenceA grid service instance may have one or more GSRs available to

it. The GSRs are associatedwith a lifecycle that is different from the service lifecycle.

ervice Lifecycle Management Using a Soft-State Approach

The soft-state lifetime management approach is a recommended method in the grid

servicelifecycle management process.This soft-state lifecycle is controlled by appropriate

security andpolicy decisions of the service, and the service has the authority to control this

behavior. Forexample, a service can arbitrarily terminate a service, or a service can extend

its terminationtime, even while the client holds a service reference. grid service can send

lifetime eventnotifications using the standard grid service notification process.

A grid service's support for the lifetime is implementation dependent, and one mustconsult

the service documentation for the details on this behavior.

A Client with proper authority can request for an early termination of a grid service.

A grid service can extend the service termination time, or terminate itself, at any

timeduring its lifecycle.

Service Operation Extensibility Features of Grid Services

Another interesting feature introduced by the specification is the concept of extensible

operationsthrough the use of untyped parameters using the XML schema xsd:any construct.

This featureallows grid service operations maximum flexibility by allowing "any"

parameters (i.e., XMLfragments) for that operation. However, this feature introduces

confusion on the client sideregarding the kind of parameters it can pass to the service. To

avoid that confusion, the

specification provides the client base with a mechanism (i.e., query capabilities) to ask

theservice about the supported extensible parameter and its type (XML schema)

information.

Service Fault Handling in OGSI

A <wsdl:operation> can define a fault message in the case of an operation failure. In many

cases,a service developer decides on the message format and the contents. The OGSI

defines acommon fault message type to simplify the problem of different fault message

types beingdefined. The OGSI defines a base XSD fault type (ogsi:faultType) that every

grid service mustreturn.

7. Brain Activation: (2 mins)

Any one of the following activities like

Right brain activities

Solving puzzles

Brain GYM

Optical Illusions

Perpetual calendar recalling

8 Survey and Reading by students (18 mins.)

Textbook

Joshy Joseph and Craig Fallenstein, Grid Computing, Pearson Education, New Delhi, 2004

Open Grid Services Infrastructure OGSI 133

A HighLevel Introduction to OGSI 136

Technical Details of OGSI Specification 138

Significance of Transforming GWSDL to WSDL Definition 142

9.

Discussion: ( 9 mins)

The students will be asked to discuss the relevant topic among their team/other

team/Faculty. The students those who have not taken part will be noted and kindle them to

do.

10. Mind Map: (8 mins)

11. Gazing/Rote memory: (1 mins)

A long and fixed look at the Mind map by the students before doing the presentation.

12. Summary: (9 mins)

We understand the roles of grid computing and Organizations developing Grid

standards and the Global Grid Forum in this chapter

Open Grid Services Infrastructure OGSI

A HighLevel Introduction to OGSI

Technical Details of OGSI Specification

Significance of Transforming GWSDL to WSDL Definition

13. Assessment: (5-10 mins)

1. A grid service is a stateful ___.

a) business b) applications c) system d) Web service

2. the service data concepts introduced by the _________

a) OGSI b) OGSA c) OGSQ d) none

3. ______ is a mechanism to expose a publicly available state of a service.

a) SDD b) SDE c) SDA d) SDQ

4. A Client with proper authority can request for an early termination of a ________

a) grid service b) Grid Design

c) Grid Collaboration d) all the above

5. The OGSI defines a base XSD _____

a) flexibility b) expand c) fault type d) none

1. What are the functional requirements of COMMERCIAL GRID on CGSA?

2. What are the layers available in the OGSA architectural organization?

3. What are the OGSA basic services?

4. What are the two dimensions of stateful nature of web service

14. Learning outcomes:

The Students can gain knowledge about the Basic service models of OGSA and fault

handling mechanisms.