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 G lue all R esources into a cyber I nfrastructure for D istributed 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/middleware independently –There is no standard protocols –When two entities want to connect their 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 the grids –But the big number of adapters is not good at the standardization, performance and efficiency

My opinion We should start with the 3rd way (case-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)