1. OGSA Evolving
Jeff Nick
IBM Fellow,
VP On Demand Architecture

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

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

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

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

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

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

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

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

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

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

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

13. 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 !!

14. 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
developerworks/webservices/library/ws-resource/

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

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

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

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

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

20. OGSA Evolving
Questions ?

21. OGSA Evolving
Jeff Nick
IBM Fellow,
VP On Demand Architecture