Possible Architectural Principles for OGSA-UK 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@indiana.edu

2. Application Specific Services such as “Run BLAST” or “Look at Houses for sale” Generally Useful Services and Features Such as “Access a Database” or “Submit a Job” or “ManageCluster” or “Support a Portal” or “Collaborative Visualization” System Services and Features Handlers like WS-RM, Security, Programming Models like BPELor Registries like UDDI Container 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 SSG/P 5 Generally Useful Services 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 than260 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. Application Specific Services such as “Run BLAST” or “Look at Houses for sale” Insensitive tolower level details Generally Useful Services and Features Such as “Access a Database” or “Submit a Job” or “ManageCluster” or “Support a Portal” or “Collaborative Visualization” Sensitive tolower level details System Services and Features Handlers like WS-RM, Security, Programming Models like BPEL or Registries like UDDI Container 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”