1. SuperComputing 2003 “The Great Academia / Industry Grid Debate” ?
Jay Unger
Distinguished Engineer
IBM Grid Computing

2. Questions ?
What will make Grids a Reality (with a big "G") ? If it requires "deploying core services with tolerable reliability in enough places", what does the this mean really mean and how do we get there?
What grid products would users really like to see from vendors that would make their grid efforts easier? (What commercial-off-the-shelf grid products could you piggy-back on?)
What does industry really need to see standardized (specifics beyond just simply OGSA) in order to build grid products that can brought to market?
What has to happen to make grid systems easier to install and use (e.g., "Grids for Dummies")?
What is the real scalability and performance of grid information systems? Is it good enough and scalable enough?
How will licensing issues affect how commercial vendors can deploy grid products ?

3. Motivations for Grid Computing
Academic & Scientific
Are we motivated to develop
grids for the same reasons ?
Business & Industry

4. Motivations for Grid Computing
Increase Capacity
Improve
Efficiency
Reduce
Costs
Provide
Reliability
& Availability
Support Heterogeneous Systems
Enable
Collaboration
Reduce
Time to
Results

5. Grid Technical Imperatives:
Security and
Trust Management
Heterogeneous Workload Management
Governance & Policy Standards
Open Standards &
Interoperability
Transactional
Workloads
Reliability
Autonomic Functionality
End-to-End Systems Management
Accounting &
Service Level Agreements
Scalable Implementations

6. Open Architecture OGSA – Open Grid Services Architecture
Applications & systems
built on standards
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.
Applications
OGSA Architected Services
Open and value-added
vendor implementations
Open Grid Services Architecture (OSGA)
Domain Specific Services
Grid Program Execution Services
Grid Core Services
Grid Data Services
Open architecture for
interoperability
Web Services
OGSI – Open Grid Services Infrastructure
Support for web services on a
variety of platforms, languages and protocols
Enabled “general
purpose” middleware
Security
OGSA Enabled
Workflow
OGSA Enabled
Database
OGSA Enabled
File Systems
OGSA Enabled
Directory
OGSA Enabled
Messaging
OGSA Enabled
Enabled Hardware and
Operating System Platforms
Servers
OGSA Enabled
Storage
OGSA Enabled
Network
OGSA Enabled

7. Open Architecture OGSA – Open Grid Services Architecture
Applications & systems
built on standards
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.
Applications
OGSA Architected Services
Open and value-added
vendor implementations
Open Grid Services Architecture (OSGA)
Domain Specific Services
Grid Program Execution Services
Grid Core Services
Grid Data Services
Open architecture for
interoperability
Web Services
OGSI – Open Grid Services Infrastructure
Web Services Evolution
Support for web services on a
variety of platforms, languages and protocols
WS-Addressing
WS-Trust
WS-Notification
WS-Transaction
WS-Security
Enabled “general
purpose” middleware
Security
OGSA Enabled
Workflow
OGSA Enabled
Database
OGSA Enabled
File Systems
OGSA Enabled
Directory
OGSA Enabled
Messaging
OGSA Enabled
Enabled Hardware and
Operating System Platforms
Servers
OGSA Enabled
Storage
OGSA Enabled
Network
OGSA Enabled

8. Cooperation
Microsystems

9. Grid Architecture / Technology Issues
What keeps me awake at night ?
Performance / Scalability
Performance of “base” technologies like web services, XML, X.509, HTTPS etc.
Granularity of architected components
Interoperability
Platform, language, and protocol neutrality
Paying for grids
Metering, billing, accounting, settlement
New licensing models for software
Standards progress
Many players = many agendas: industrial, academic, government, standards organizations