Possible Architectural Principles for OGSAUK and other Grids

1
Possible Architectural Principles for OGSA-UK and
other Grids

• UK e-Science Core Programme Town Meeting
• London Monday 31st January 2005
• Defining the next Level of Services for
  e-Science
• Geoffrey Fox
• Community Grids Lab
• Indiana University
• gcf_at_indiana.edu

2
Goal Clarify Infrastructure sowe can focus on
e-Science
So wecan focushere
Clarify these areas
3
Two Core Grid Service Structure
Application Specific Services

SSG/P 4
Generally Useful Services
SSG/P 5
SSG/P 2
Other System Services
SSG/P 1
SSG/P 1
SSG/P 3
Partial Interoperability Layer ??
WS-I Based Core
WSRF Based Core
Core System Services
Container
4
What are the two Cores?

• WS-I Core is WS-I (XML, WSDL, SOAP, WS-Security
  (partial as WS-Security is work in progress),
  UDDI), WS-Addressing, WS-RM, BPEL
• Assume this gets updated every now and then as
  specifications and best practice evolve
• WS-I Core adds WS-Eventing as this comes from
  IBM and Microsoft and similar to
  WS-BaseNotification
• WSRF Core perhaps includes XML, WSDL, SOAP,
  WS-Security (same caveats as above),
  WS-Addressing, WSRF, WSDM, GSI .?

5
Why are there two Cores?

• As there is no clear Web Services standards, it
  is hard to generate interoperability among
  different Web Service-based Grids under
  development around the world
• WS-I only selects 4.5 (.5 from Security) out of
  60 WS- specifications generated over last 1-5
  years
• One core would be best perhaps but two is less
  than 260 potentially possible
• The two cores are not easy to reconcile for both
  technical and political reasons
• Both cores can be expected to be technically
  strong over next two years
• Existing successes show that both cores satisfy
  current Grid application requirements

6
Filling the void with islands of agreement

• SSG/P are Standard Service Groups or Profiles
  which are functionalities supported by agreed
  groups of services and features
• Can be specific to one or other core
• Can be independent of core or easily adapted to
  either core
• Service Interaction and Management
• Portals
• Database Access
• Job Submission

Possible near termIslands
7
Characteristics of the Two Cores

• The two cores have somewhat different design
  philosophies
• WS-I core approaches complexities of
  distributed systems by set of broad minimal
  specifications that are aimed at easy scalability
  of common infrastructure and are agreed by broad
  community (including IBM and Microsoft)
• WSRF core is more prescriptive and so enhances
  potential interoperability between different
  complex Grid services
• Remember MPI PVM dominated for several years
  only 6 of 128 MPI functions used by real people
• But we are at the beginning and so I would say
  they are different as opposed to better or
  simpler or ..
• We can expect experience to suggest a common core
  merging these ideas but this is years away?
• Useful to study a possible interoperability
  framework
• Either in terms of best practice for building
  services that work with either or
• By building filters that map SOAP messages
  between specifications (WSDM to and from
  WS-Management etc.)

8
Some near term Possible Actions

• Get community organizations to clarify two cores
  and their process for evolution
• Certainly should involve WS-I and GGF W3C EGA
  etc. also could be important
• OGSA-UK and OMII could decide to follow one other
  core or to be interoperable with both
• Suggest other large Grids align themselves with
  one or other (or both) tracks
• Start thinking about new islands of agreement
  between two cores or within a particular core
• Just as WS-Eventing close to WS-BaseNotification,
  perhaps could define WS-BaseDM close to WS-Man
• Example of activities helping core
  interoperability

9
Interoperability Principles I

• Can we draw a line in sand defining where
  dependencies on core and lower level services and
  features ends
• JSDL (for jobs), CIM (for devices), GML and some
  OGC services (for geography), VOTable (astronomy)
  are above the line
• Easiest for properties but services also needed

10
Interoperability Principles II

• We should try to develop interoperability
  principles that help define the line in the
  sand
• Should be quite easy to separate application
  properties from any system issues below the line
• Application services are harder as they can
  involve system services (e.g. OGC services
  involve discovery and metadata)
• WSDM illustrates possible difficulties as it
  appears to mix service interaction and properties
• Good for building integrated systems doubtful
  for interoperability
• On other hand, WS-Management, Transfer,
  Enumeration, and Eventing define service
  interaction profiles that appear largely
  independent of resource properties
• Good for defining a clear line in the sand
• Doubt if these are a complete set of interaction
  profiles it would be useful to address this
• Can Semantic Web technologies be used to support
  separation of service interactions and
  meta-data (which is roughly data)
• Of course WSDM is an open standard and all the
  others are not considered as such yet

11
Possible near term Islands of Agreement

• Portal Profile common for both cores
• WSRP and JSR168 (generalized to WS168)
• Database Access separately for each core
• OGSA-DAI and WS-DAI
• Management and Service Interaction for WS-I
• WS-Management, Enumeration, Transfer, Eventing
• and perhaps some guidelines for use of CIM
• Job Submission for both cores
• JSDL
• Grids need islands in area of high performance
  data transport and advanced security