OGSA Evolving Jeff Nick IBM Fellow, VP On Demand Architecture

What we announced in January Proposals to extend to Web services Driven by requirements from: Grid computing Systems Management Business computing Key to infrastructure for IBMs On Demand Initiative Grid Computing Systems Management Web Services business on demand Business Computing

Grid and Web Services: Convergence? OGSI GT2 GT1 Started far apart in applications & technology Have been converging ? Web HTTP WSDL, WS-* WSDL 2, WSDM However, despite enthusiasm for OGSI, adoption within Web services community turned out to be problematic

Grid and Web Services: Convergence? OGSI GT2 GT1 Started far apart in applications & technology Have been converging WSRF Web HTTP WSDL, WS-* WSDL 2, WSDM The definition of WSRF means that Grid and Web communities can move forward on a common base

Address Web Services Concerns about OGSI Too much stuff in one specification WSRF partitions OGSI v1.0 functionality into a family of composable (i.e. mix and match) specifications Does not work well with existing Web services tooling WSRF tones down the usage of XML Schema Too object oriented WSRF makes an explicit distinction between the “service” and the stateful “resources” acted upon by that service

What we announced in January Why we developed these proposals To have an architecture that is more clearly aligned with the general evolution of Web services To provide a collection of related specifications that can be used either individually or in combinations… …. and will integrate more effectively with other Web services standards To more closely align with existing language and platform programming models and application development tools

What we announced in January A family of Web services specification proposals Introduces a design pattern to specify how to use Web services to access “stateful” components Introduce message based publish-subscribe to Web services Introduced in January WS-Notification WS-Resource Properties WS-Resource Lifetime Modeling Stateful Resources with Web Services WS-Service Group WS-Base Faults To be developed WS-Renewable References

Evolution of the specifications WS-Base Notification Notification Re-factored WS-Brokered Notification WS-Topics Publish-Subscribe Notification for Web services WS-Resource Properties WS-Resource Lifetime Modeling Stateful Resources with Web Services WS-Base Faults WS-Service Groups References WS-Renewable Still to be published This is an open process of evolution

Evolution of WS-Resource Framework Authors Review Meeting held Public Review Meeting held Changes made include cleanup of terminology WS-Resource, Context, Identity Changes to Resource Properties Set operation OASIS TC charter submitted and accepted Revised and Re-published on 3/5/04 Specifications WS-ResourceProperties WS-Resource Lifetime White Paper Modeling Stateful Resources with Web services Interoperability Workshop scheduled 4/20 (Invitations Sent) On Schedule for OASIS Submission 4/28/04

Evolution of WS-Notification Authors Review Meeting held Public Review Meeting held Feedback suggested need to Break up into smaller, more incremental specs (Incremental Mix-in of Notification function) WS-Notification Refactored and Published on 3/5/04 Specs: WS-BaseNotification WS-BrokeredNotification WS-Topics White Paper (New) Publish-Subscribe Notification for Web services OASIS TC charter submitted and accepted Interoperability Workshop scheduled 4/21 (Invitations Sent) On Schedule for OASIS Submission 4/28/04

Publish-Subscribe Notification for How these proposals relate to OGSA WS-Resource Framework & WS-Notification are an evolution of OGSI Lets build up a taxonomy of the components of OGSA. There are four main layers which comprise the OGSA architectural view. (CLICK) The lowest layer is comprised of the basic IT resources such as processors, storage systems, and network subsystems and the hardware specific support software in operating systems, subsystems and components that control them. For the most part these resources are made “visible” to the OGSA structure by adding function to that software to “virtualize or abstract” the hardware and system resources as “services”. (CLICK) Just above these is a layer of function like file systems, databases, messaging software, directories, etc. which are typically implemented as general purpose middleware. This middleware generally exploits the lower layer of physical resource and also provides function that can be “abstracted” and “virtualized” as services in OGSA. (CLICK) As a “Service Oriented Architecture” OGSA is Fundamentally an extension of the existing Web Services infrastructure defined by standards like XML, WSDL, SOAP, etc. OGSA takes advantage of middleware application servers that provide programming support and hosting for web services implementations. (CLICK) OSGA Then “sits” on top of this support for web services. (CLICK) And Grid Applications in turn exploit the services that OGSA defines to manage and exploit the distributed resources of the grid. OGSA Services can be defined and implemented as Web services OGSA can take advantage of other Web services standards OGSA can be implemented using standard Web services development tools Grid applications will NOT require special Web services infrastructure Applications WS-Base Faults References WS-Renewable WS-Resource Properties Modeling Stateful Resources with Web Services Publish-Subscribe Notification for Web services Groups WS-Service WS-Topics Notification Lifetime WS-Brokered OGSA Architected Services Web Services Web Services OGSI – Open Grid Services Infrastructure Security OGSA Enabled Workflow OGSA Enabled Database OGSA Enabled File Systems OGSA Enabled Directory OGSA Enabled Messaging OGSA Enabled Servers OGSA Enabled Storage OGSA Enabled Network OGSA Enabled

OGSI to WSRF: Re-factoring & Evolution WS-Resource framework (WSRF) Grid Service Reference WS-Addressing Endpoint Reference Grid Service Handle WS-Addressing Endpoint Reference HandleResolver portType WS-RenewableReferences Service data definition & access WS-ResourceProperties GridService lifetime mgmt WS-ResourceLifeCycle Notification portTypes WS-Base Notification WS-Brokered Notification WS-Topics Factory portType Treated as a pattern ServiceGroup portTypes WS-ServiceGroup Base fault type WS-BaseFaults

Very Important !! WS-Resource Framework and Notification is mainly a terminology adjustment and refactoring of OGSI Preserves almost all of the concepts, features and function of OGSI Is relatively easily mapped-to from existing OGSI implementations OGSI Grid-services are easily converted to Web services based on WS-Resource Framework The resource pattern described by WS-Resource Framework is fundamentally the same as how OGSI modelled managed resources !!

Additional Documents Published on 03/05/04 WS-ResourceFramework White Paper: Overall Context for all WS-RF specifications From Open Grid Services Infrastructure (OGSI) to WS-Resource Framework: Refactoring & Evolution White Paper: Describes the OGSI relationship, evolution, and migration to WSRF and Notification specifications http://www-106.ibm.com/ developerworks/webservices/library/ws-resource/

Web Services Foundation Management Enterprise Application Integration Business To Management Policies for Web Services Web Services Description Common Web Services

Service Taxonomy Management Enterprise Application Integration Business To Utility Business Services Service Level Managers Management Services Manageable Resources Manageability Capabilities Descriptions Resource Models Policies for Web Services Web Services Description Common Web Services

Standards Bodies Cooperation Management Enterprise Application Integration Business To Utility Business Services Service Level Managers GGF Working Groups Management Common Web Services Other Management Services GGF OGSA Architected Services Manageable Resources GGF Working Groups DMTF Manageability Capabilities Descriptions CIM Model Other Resource Models OASIS (WSDM) DMTF Policies for Web Services Web Services Description Common Web Services OASIS OASIS W3C OASIS

Policy Enforcement Point Use Cases Motivate Taxonomy Management Utility Business Services Rating uses Service Level Managers Job / Scheduling Management Services Metering Metric Mediation Policy Decision Point uses uses Manageable Resources Job Manageable Resource Manageability Capabilities Descriptions Resource Models This is a 'specification stack‘. The 'stacking' does not indicate required-ness, its more an indication of what needs to be defined first and what can be built on the others. The layering indicates discrete specs, and does imply some 'based on' architecture and order in which they need to be develope,ed, but they do not imply any flow The CRM specs in bright green The dark green is ALL the portTypes to be created based on the CIM model along with other models. Those models are out of scope, so its gray. Resource port types are composed from the normalized (granular) elements in CIM, SNMP, RMC, composed, etc The light blue is the management 'OF' WS work Notice that the WS management is just like other Resources and based on the same foundation The manageable infrastructure is the standard portTypes we need to be able to actually DO the management once we have the resource portTypes. Registry for one (which is now service group i think but i'm not completely sure) and an event target of some sort. Generic manageability porttypes are those you're identifying to enable the manageability that ALL resources will implement, i.e. notificationSource, serviceData, lifeCycle, etc.. The generic layer is the collection of WHICH port types need to be defined, not necessary implemented by all resources/services. Which generics are actually mandated by which Base Resource or Resource would need to be dealt with as they are defined. The generic layer is the set of port types that have wide applicability and need to be defined, but are not required to be used by resource port type and base resource port types are what I think of as port types for virtualized resources (such as those defined in CIM) and should be used by resource port types; A virtualized resource is an abstracted resource can have many implementations, such as OS devices, other systems Base type are like cim base classes: service, system, device, etc. Resource PortTypes don't HAVE to inherit from Base Resource PortTYpes either Agreements - agreement descriptions are really SLA descriptions. Other agreements may emerge, i.e. like business agreement, offer/negotiation descriptions The manager porttypes on top are porttypes to manager functions...like inventory systems, monitoring systems.It is just another set of port types, but the manager application may actually use both, either implicitly or explicitly? Metrics Reserve/Allocate Policy Enforcement Point uses Common Web Services Policies for Web Services Policy Server Agreement Mediation Notification MetaData Exch Collection Coordination Transaction Service Agreements Web Services Description Interface Policy Reliable Msg Agreement Property Endpoint Service Security Process Addressing

OGSI is NOT GONE. It has evolved and become part of core web services Summary OGSI is NOT GONE. It has evolved and become part of core web services Provides a well integrated foundation for Grid, On Demand and Utility infrastructure Supports interoperability, composability and a sound basis for building service oriented components The important task for 2004 is to build a well structured taxonomy of services Based on cooperation among standards organizations Motivated by concrete use cases and scenarios Begin to build-out service components

OGSA Evolving Questions ?

OGSA Evolving Jeff Nick IBM Fellow, VP On Demand Architecture