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

Goal: Clarify Infrastructure so we can focus on e-Science Container System Services and Features Handlers like WS-RM, Security, Programming Models like BPEL or Registries like UDDI Generally Useful Services and Features Such as “Access a Database” or “Submit a Job” or “Manage Cluster” or “Support a Portal” or “Collaborative Visualization” Application Specific Services such as “Run BLAST” or “Look at Houses for sale” Clarify these areas So we can focus here

Two Core Grid Service Structure Container Application Specific Services Generally Useful Services Other System Services WS-I++ Based CoreWSRF Based Core Core System Services Partial Interoperability Layer ?? SSG/P 1 SSG/P 4 SSG/P 2 SSG/P 5 SSG/P 1 SSG/P 3

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 ….?

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 2 60 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

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 term Islands

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.)

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

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 Container System Services and Features Handlers like WS-RM, Security, Programming Models like BPEL or Registries like UDDI Generally Useful Services and Features Such as “Access a Database” or “Submit a Job” or “Manage Cluster” or “Support a Portal” or “Collaborative Visualization” Application Specific Services such as “Run BLAST” or “Look at Houses for sale” Sensitive to lower level details Insensitive to lower level details

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 ……

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”