Understanding to InterGrid and WAG

Dr. ZhenChun Huang

Tsinghua Univ.

NRSCC/RSGS/SIG Team

Sep, 2006

GRID???

• What should GRID seem like? a isolated system or an infrastructure?

• What is GRID sharing? Systems/computers or resources/functions?

• Should resources in GRID be virtualized to its functions and interfaces or be bound to its physical beings?

• What is the goal of GRID? To build a system or to provide an environment for distributed, dynamic and virtualized application development/execution?

GRID: my view

• Glue all Resources into a cyber Infrastructure for Distributed environment

• Similar to Internet (which is sharing data), but shares resource instead of data/information

• Applications, especially web based applications will be built on GRID, and be used as same as applications today.

• Resource must be virtualized in a grid.• Virtual organization should be supported for a read grid.

It will be very important is a grid.• Should be regarded as a cyber infrastructure for sharing

resources rather than a isolated system

GRID: my view (cont.)

• But, most of the grids today are only distributed computing systems based on SOA. To share resources among entities/organizations/agencies is still very difficult.

• Something must be done --- a REAL GRID! (Inter-Grid/WAG)

• It will be much easier for implementing a REAL GRID in the spatial information domain then a general one. This is WGISS’es duty.

Goal: what we want?

• For the exist “grid” systems, connect the “grid” systems based on different platforms and middlewares, make them inter-operable and co-work-able.

• For a new project, create a new system based on grid architecture and middleware to support resource sharing among entities.

• We need share resources and functions (NOT systems or computers) among entities. Then, the resources and functions can be used distributedly, dynamically and virtually.

Functions needed

• Functions needed for resource sharing and co-working among exist spatial information grids and among entities– First, the resource must be found: Resource (data,

computer, software…) locating and matching– Second, the resource must be accessed: Resource

sharing (by service invoking)– Third, all resources should be composed: Workflow

and business logic description– And, a user interface is needed to interact with users

and show results: Visualization and UI support– ……

Protocols for the functions• Resource locating and matching

– Resource locating and mapping– Resource classes and properties– Resource registering and matching– ……– Standard, semantic and ontology will be important

• Resource invoking– Parameter defining and data transferring– Security framework and authorization policy– ……– It is not only a technology problem.– Flexibility should be the key

Protocols for functions (cont.)

• Workflow and business logic description– Workflow model and workflow language definition– Trust policy between agencies– Roles mapping– ……– Should not be one way only, it should be multiplex

• Visualization and UI support– Inter-agencies distributed visualization– User interface for a wide-area, inter-agencies application– …– Existing protocols such as WMS may low down the workload

• …

Who are absent?• We can’t find resource because of the different description

rules.• We can’t invoke service because of the different parameter

definition and security policy• We can’t generate a business flow across the gap among

today’s “grids” because there is no trust policy, no role mapping, no universal flow description …

• We can’t present the result and difficult to create a inter-organization application because of the absent of inter-agencies distributed visualization and user interface support for wide-area, inter-agencies applications

• …

Possible ways to bridge the gap(1)

• Same platform/middleware– All entities take the same choice on

middleware and platform– There will be no problem in connecting

the resources and inter-operating among them.

– But it will be difficult to reach a consensus on which platform should be chosen, especially among the entities who is running a grid system already.

– Today, it likes a dream more, I think

Possible ways to bridge the gap(2)

• Same protocol, different platforms– A set of protocols is created for the

connection and inter-operation among grids/entities

– Each entity choose the platform and middleware independently

– If an entity want to connect with others, an adapter must be developed to implement the protocols.

– Because of the disagreement among entities, it will be very difficult to create the protocols, I think.

Possible ways to bridge the gap(3)

• Different protocols and platforms/middlewares, glue by adapters case-by-case.– Each entity choose the platform/mi

ddleware independently– There is no standard protocols– When two entities want to connect t

heir grids, they found the inter-operation protocols themselves

– Adapters will be developed to connect resources between entities when needed.

Comparison among the ways• Same platform/middleware

– For a new project, it is advisable– If there are a lot of grid systems based on different platforms

exist, it is not a good choice• Same protocol, different platforms

– It may be a good choice technically, but the protocols is not easy to get because of non-technical reasons

• Different protocols and platforms/middlewares, glue by adapters case-by-case.– It is easy to reach and acceptable for the entities who control t

he grids– But the big number of adapters is not good at the standardizat

ion, performance and efficiency

My opinion• We should start with the 3rd way (cas

e-by-case), because it is easiest to achieve.

• When grids are connected, inter-operation protocols and adapters will be accumulated.

• Time, the best judge, will select a set of protocols for us as defacto-standards.

• Then, we got the 2nd way — same protocol, different platforms

• Maybe, at that time, an excellent middleware will be the choice of all entities… ??

Step by step

• Due to the different difficulty of co-operation levels, we can get the grids connected step by step:

• We may start by sharing data among exist grids and interested entities (only a suggestion)

Connect case-by-case

Select the protocols

time

Re-factor by these protocols

Resource matching & invoking

Connect case-by-case

Select the protocolsWorkflow

Connect case-by-case

Select the protocols

Co-operation applications

Re-factor by these protocols

Re-factor by these protocols

……