Transcript Document 7136914

Middleware, Service-Oriented
Architectures and Grid Computing
CSE
300
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
† Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig
and Prior CSE333 students for providing portions of this material.
MW+SOA-1
What is a Distributed Application?

CSE
300


Distributed Computing/Applications are …
 Systems of Systems
 Interoperation of New & Existing Applications
 Legacy, Databases, COTS, New Clients, etc.
 Network Centric Environment
Distributed Computing Applications must …
 Manage, Control, Access, and Modify Data
 Allow Humans to Interact with Data
 Provide High-Availability and Performance
 Evolvable Over Time
Present & Future Army Systems Exhibit All of
These Characteristics and More!
MW+SOA-2
What is a Distributed Application?
CSE
300
System of Systems
Heterogeneity
Hardware
OS, PLs
Network Centric Environment
DB Client
Legacy
Client
Legacy
Database
COTS
Dynamic
Environment
High-Availability
Performance
Java
Client
Server
Server
Legacy
Java
Client
Database
COTS
COTS
Client
Increase Productivity
New/Innovative
Transparent Interoperation
Information Use
MW+SOA-3
Another View – Today’s Reality

CSE
300



Premise: Artifacts - set of
 DB, Legacy, COTS,
GOTS, Each w/ API
Premise: Users
 New and Existing
 Utilize Artifact APIs
Distributed Application, DA
 Artifacts + Users
What are the Issues?
 How Do they Interact?
 Heterogeneity
 Security Concerns
 Different Programmatic
Models
 Etc. Etc. Etc.
Database
COTS
Legacy
Legacy
Client
Java
Client
GOTS
NETWORK
GOTS
Client
Legacy
Database
Database
Client
COTS
Client
MW+SOA-4
Why is Distributed Computing Needed?

CSE
300


Today’s Environments Contain Applications …
 Created with Multiple Prog. Languages
 Executing on Heterogeneous Platforms
 Locally and Geographically Distributed
Distributed Computing Applications Must …
 Allow Seamless and Transparent Interoperation
 Provide Tools for Engineers and Users
Result: Inter-Operating Environment
 Utilize Information in New/Innovative Ways
 Leveraged to Increase Productivity
 Support Diverse User Activities
 Dynamically Respond to Changes
MW+SOA-5
Striving for New Techniques/Technologies

CSE
300

We Must Diverge from Business as Usual
 C Programming with RPC
 Customized Development without Reuse
 Solutions that Aren’t Extensible and Evolvable
 Cobbling Together Solutions w/o Method or
Reason is Unacceptable and Doomed to Fail!
We Must Face Today’s Realities
 Legacy Code is Fact of Life
 New Technologies Offer New Challenges
 Adopt to Leverage Their Benefits
 We Must Draw Careful Balance to Opt for
Mature Technologies While Targeting
Emerging Technologies with Potential!
MW+SOA-6
Who are the Players?

CSE
300


Stakeholders
 Software Architects (Requirements)
 System Designers (Solutions)
 Application Builders (Implementation)
Stakeholders Striving to Provide …
 System Interaction and Information Exchange
 Utilization of Existing Applications in New and
Innovative Ways
End-Users at Various Skill Levels and with Specific
and Limited Access Requirements
 Novice vs. Adept vs. Expert
 Who Uses What When and for How Long?
MW+SOA-7
Why a Distributed Application?

CSE
300

Reasons:
 Data used is Distributed
 Computation is Distributed
 Application Users are
Distributed
2 Key Issues for Solution:
 Platform-Independent
Models and Abstraction
Techniques
 Hide Low-Level Details
 Provide a Well-Performing
Solution
 Works Today and
Tomorrow!
Shared Objects
• Easy to Re-use
• Easy to distribute
• Easy to maintain
MW+SOA-8
Distributed Systems
Fundamental Realities of Distributed Systems
CSE
300
Co-located
Distributed
Fast
Slower
Failures
Objects fail together
Objects fail
separately, Network
can partition
Concurrent Access
Only with multiple
threads
Yes
Yes
Not Inherently
Often Add-On
Capability
Communication
Secure
MW+SOA-9
Service Oriented Architecture
& Grid Computing
Marc Brooks, The MITRE Corporation
The author's affiliation with The MITRE Corporation is provided
for identification purposes only, and is not intended to convey or
imply MITRE's concurrence with, or support for, the positions,
opinions or viewpoints expressed by the author.
http://colab.cim3.net/file/work/EmergingTechnology_Conference/2004-06-03_MITRE/Brooks_2004_03_24.ppt
What is Service Oriented Architecture (SOA)?
An SOA application
is a composition of
services
Service
Registry
 A “service” is the
atomic unit of an
Find
Register
SOA
 Services encapsulate
Service
Service
Bind,
a business process Consumer Execute Provider
 Service Providers
Register themselves
 Service use involves:
Find, Bind, Execute

Service
Registry
SOA Actors
Find
Service
Consumer

Register
Bind,
Execute
Service Provider
 Provides
a stateless, location transparent business
service

Service Registry
 Allows
service consumers to locate service providers
that meet required criteria

Service Consumer
 Uses
service providers to complete business
processes
Service
Provider
SOA Benefits
Service
Registry
Find
Service
Consumer
Business Benefits
 Focus on Business Domain solutions
 Leverage Existing Infrastructure
 Agility
Technical Benefits
 Loose Coupling
 Autonomous Service
 Location Transparency
 Late Binding
Register
Bind,
Execute
Service
Provider
What is a Service Oriented Architecture?

CSE
300



Solutions that Focus on Services that Need to be
Available to Meet Need of Users (Entities)
Users are Assumed to be Interacting via Client
Applications (Browser or Standalone)
 Interactions with Services Transparent to Users
(Integrated into Software)
Interactions Between Entities Occur via a Message
Exchange - Conceptual
 Resources are Software Artifact Accessible via
API Consisting of Services
 Services are Logical Grouping of Methods
(Functions) that are Available for Use
 Services are Utilized When Messages are Invoked
Against Them by Outside Users
Both Web-Based and Middleware Settings
MW+SOA-14
Middleware-Based SOA

CSE
300

Distributed Object Computing Platforms are Well
Established in the Field - Historically
 DCE (Distributed Computing Environment)
 COM/OLE (Component Object Model/Object
Linking and Embedding)
Modern Middleware (JINI, CORBA, .NET):
 CORBA –Standards Committee (OMG) Controls
Technology – Many Programming Languages
 JINI – Sun-Based Product – The Poor Mans
CORBA – Java
 .NET – Microsoft’s Forward into the Modern
Market – C#
MW+SOA-15
What Must All SOA Provide?

CSE
300
Both Middleware & Web-Based SOAs Must Provide
 Middle Layer Infrastructure that Provides Bridge
Between Software Artifacts
 Clients and Resources in Middlware Setting
 Clients (Browsers) and Resources in Web Setting
Allow Software Artifacts (Resources) to
Register/Publish their APIs (Services and
Methods) for use by Clients/Other Resources
Lookup Service: Middleware for Artifacts (Resources
and/or Clients and/or Other Resources) to Interact
 Support Dynamic Discovery – Find Services
Based on Attributes and Values
 Location Transparency to Service Requestors
 Found Service Sets up Binding Between Service
Consumer and Service Provider


MW+SOA-16
SOA Akin to CBD
CSE
300
MW+SOA-17
Supplier /Consumer Model
CSE
300
SUPPLY
Build New
Wrap Existing
Buy
CONSUME
Assemble
Applications
MANAGE
Publish
Subscribe
Catalog
Browse
MW+SOA-18
Objectives of SOA

CSE
300






Can SOAs Support Highly-Available Distributed
Applications?
Can Replicated Services be Registered and Available
for Use by Clients?
Can SOAs Support a Network-Centric Environment
with Dynamic Clients and Services?
Will Clients Continue to Operate Effectively if a
Replicated Service Fails?
Can SOAs be Utilized to Maintain Data Consistency
of Replicas?
Are SOAs Easy to Learn and Use?
What is Maturity Level of SOAs Technology?
MW+SOA-19
Overview of Presentation

CSE
300



Objective is to Explore CORBA, JINI, and .NET
Various Aspects of Three Technologies
 Overall Architecture
 Interoperability Capabilities
 Access and Usage
Exploration of Web Service-Oriented Architectures
 What are they?
 How do they Work?
 WSOAs + Middleware
Transition to Grid Computing
 What is the Grid?
 What is its Purpose and Role
 Grid + SOA + Middleware
MW+SOA-20
What is CORBA?

CSE
300


Common Object Request Broker Architecture
Architecture to Allow:
 Existing COTS, GOTS, Legacy, DB, etc. to
Interact with One Another
 Integrate These with New Clients/Servers/Etc.
Consists of Following Major Components
 Object Request Broker (ORB):
 Arbitrate and Interact
 Role of Lookup for Service Discovery

Interface Definition Language (IDL):
 Common Definitional Format
 Means for Different “Software” written in Different
Languages to Interact with One Another
MW+SOA-21
What is CORBA?

CSE
300


CORBA is a
Specification for
Interoperability
OMG (Object
Management
Group) Supplies a
Set of Flexible
Abstraction and
Concrete Services
Vendors Must
Follow Standard
CORBA Language Mappings
Ada
C and C++
COBOL
Java to IDL
Lisp
CORBA Scripting
Language
Smalltalk
Others
Perl
Haskell
Python
Eiffel
PHP/ORBit
MW+SOA-22
What is CORBA?

CSE
300

Differs from Typical Programming Languages
Objects can be …
 Located Throughout Network
 Interoperate with Objects on other Platforms
 Written in Ant PLs for which there is mapping
from IDL to that Language
Application
Interfaces
Domain Interfaces
Object Request Broker
Object Services
MW+SOA-23
What is CORBA?

CSE
300
CORBA Provides a Robust set of Services (COS)
 Services to Support Integration and Interoperation of
Distributed Objects
 Services Defined on top of ORB as standard CORBA
Objects with IDL interfaces
 Vendors Must Implement CORBA Services (COS)
Factory
Naming
Context
Object Request Broker
Event
Channel
Object Life
Cycle
Naming
Events
Relationships
Externalization
Transactions
Trader
Query
Property
MW+SOA-24
What is CORBA?

CSE
300

Allow Interactions from Client to Server CORBA
Installed on All Participating Machines
Client Application
Static
Stub
DII
Server Application
ORB
Interface
ORB
Interface
Skel
eton
DSI
Object Adapter
Client ORB Core
Network
IDL - Independent
Same for all
applications
Server ORB Core
There may be multiple
object adapters
MW+SOA-25
CORBA: Architectural Goals

CSE
300











Simplicity
Consistency
Scalability
Usability for End Users
Usability for Administrators
Usability for Implementers
Flexibility of Security Policy
Independence of Security Technology
Application Portability
Interoperability
Performance
Object Orientation
MW+SOA-26
Role of an Object Request Broker (ORB)

CSE
300



ORB Provides the Underlying Infrastructure for
Supporting Interoperating Software Systems
(Applications) Composed of Distributed Objects
 ORB Provides the Basic Request Delivery
 ORB Provides Interface Definitions
Location is Transparent to the Caller and Object
Implementation
Caller and the Object Implementation Can be in the
Same Process thru Opposite Sides of the World
ORB Manages Local Location and Optimization
ORB
Clie nt
Obje ct
Application
Imple me ntation
MW+SOA-27
Interface Definition Language, IDL

CSE
300



Key Component of CORBA Is the Interface
Definition Language, IDL
 Mapping is Available in C, C++, Java, Ada, Etc.
 IDL Is Independent of Any Language/Compiler
 Multiple Inheritance
 Public Interface Oriented
 Not for Implementation
Primary Support for Interoperability Between Static
and Dynamic Request Mechanisms
Advantage: Modification of Client Code without
Impacting of Server Code, and vice-versa
Disadvantage:
 A complete new language with C++ like Syntax
 Programmers Must Prepare IDL Modules
MW+SOA-28
ORB and High Level View of Requests

CSE
300
The Request Consists of
 Target Object
 Operation (Method)
 Parameters
 Request Context (Optional)
Client
Application
Object
Implementation
Object Call
IDL Boundary
Object reference
Methods and D ata
ORB
Request
IDL Boundary
Object dispatcher
MW+SOA-29
CORBA Components and Interfaces
CSE
300





Client Stub: Client Invokes a Particular Object Op.
Dynamic Invocation: Run-Time-Construction of
Operation Invocations
Implementation Skeleton: Interface Through Which a
Method Receives a Request
Object Adapter: Provides (De)activation, Object
Creation/Reference Mgmt. for Implementations
ORB Interface: Common ORB Operations
Client
Dynamic
Invoke
Client
Stubs
Object Implementation
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
One interface
One interface per object adaptor
One interface per object operation
ORB internal interface
MW+SOA-30
Interfaces

CSE
300


Objects are Defined in IDL via Interfaces
Object Definitions (Interfaces) are Manifested as
Objects in the Interface Repository, as Client Stubs,
and as Implementation Skeletons
Descriptions of Object Implementations are
Maintained as Objects in the Impl. Repository
IDL Interface
Definitions
Interface
Repository
Access
Client
Stubs
Includes
Client
Implementation
Installation
Implementation
Skeletons
Includes
Implementation
Repository
Describes
Object Implementation
MW+SOA-31
CORBA: Repositories

CSE
300
Interface Repository




Client access to
definitions
Type checking for
signatures
Traversal of
inheritance graphs
Implementation Repository





IDL Interface
Definitions
Interface
Repository
Location of
implementation
Activation information
Administration control
Security
Resource allocation
Implementation
Installation
Client
Stubs
Implementation
Skeletons
Implementation
Repository
Access
Includes
Client
Describes
Includes
Object Implementation
MW+SOA-32
Client Side

CSE
300


Clients Perform Requests Using Object References
Clients Issue Requests through Object Interface Stubs
(Static) or DII (Dynamic Invocation Inter.)
Clients May Access General ORB Services:
 Interface Repository (IR)
 Context Management
 Request Management
Client
Object
Repository
Object Implementation
Dynamic
Invoke
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
MW+SOA-33
Object Implementation Side

CSE
300


Implementations Receive Requests Thru Skeletons
Object Adapter Adapts to Specifics of Object
Implementation Schemes
Basic Object Adapter (BOA) Provides:
 Management of References
 Method Invocation
 Authentication
 Implementation Registration
 Activation / Deactivation
Object Implementation
Client
Dynamic
Invoke
Client
Stubs
ORB
Interface
ORB Core
Implem.
Skeletons
Implementation
Repository
Object Adapter
MW+SOA-34
CORBA

CSE
300

Basic Object Adapter (BOA)
 Provides Basic Services to Allow Variety Of
CORBA Objects to be Created – Ambiguous
Portable Object Adapter (POA)
 Allow Developers yo Construct Object
Implementations that are Portable Between ORBs
 Mediator Between ORB And Server
Server Applications
Servants
Client
ORB
POA
Incoming Request
MW+SOA-35
CORBA: POA Policies

CSE
300


Provided to Programmer for Control Over an Object’s
Identity, State, Storage and Life-cycle
7 Different Policies
 Thread Policy
 Life-Span Policy
 Object ID Uniqueness Policy
 ID Assignment Policy
 Servant Retention Policy
 Request Processing Policy
 Implicit Activation Policy
We Briefly Review each in Turn
MW+SOA-36
CORBA: POA Policies

CSE
300
Thread Policy - Depends on Number of Objects the
Application Will Have
 Depends on Operating System
 Expected Load on System



ORB_CTRL_MODEL/SINGLE_THREAD_MODEL
Life Span Policy - Transient object cannot live
beyond the process which created it
 Persistent object can live beyond the process
which created it
 TRANSIENT / PERSISTENT
Object ID Uniqueness Policy
 UNIQUE_ID / MULTIPLE_ID
MW+SOA-37
CORBA: POA Policies

CSE
300



ID Assignment Policy - To specify whether Object ID
was generated by the application or ORB
 USER_ID / SYSTEM_ID
Servant Retention Policy: States if POA retains active
servants in object map
 RETAIN / NON_RETAIN
Request Processing Policy: States how request
processed by the POA
 USE_ACTIVE_OBJECT_MAP_ONLY /
USE_DEFAULT_SERVANT /
USE_SERVANT_MANAGER
Implicit Activation Policy: Indicates if Implicit
activation of servants is supported by POA
 IMPLICIT_ACTIVATION /
NO_IMPLICIT_ACTIVATION
MW+SOA-38
Dynamic Invocation Interface (DII)

CSE
300

DII Allows Clients to Dynamically:
 Discover Objects
 Discover Objects’ Interfaces
 Create Requests
 Invoke Requests (-> Methods)
 Receive Responses
Major DII Features:
 Requests Appear as Objects
 Requests are Reusable
 Invocation May be Synchronous or Asynchronous
 Requests Can be Generated Dynamically,
Statically or Using Both Approaches
MW+SOA-39
Request Components

CSE
300






Object Reference -- Identifies the Target Object
Operation -- Identifies Which Operation to Invoke
(Which Method Will Be Executed)
Parameters -- Input, Output or Inout Method Arg-s
Context Object -- the Context Within Which the
Request Is to Be Performed
Results -- the Result Value(s) Returned
Environment -- the Exec-n Env-t and Exception Info.
Request Handle -- the Id. For This Request Instance
MW+SOA-40
Repositories: Interface and Implementation

CSE
300

Interface Repository
 Dynamic Client Access to Interface Definitions to
Construct a Request
 Dynamic Type Checking of Request Signatures
 Traversal of Inheritance Graphs
Implementation Repository
 Location of Implementations and Methods
 Activation Information
 Administration Control
 Resource Allocation
 Security
MW+SOA-41
Three Types of ORBs

Single Process Library Resident
CSE
300
Client
ORB

Object
ORB and implementations
implemented as libraries
(routines) resident in
the client.
Request
Client and Implementation Resident
Client
ORB
Object
ORB implemented as
libraries (routines) resident
in the clients and in the
implementations.
Request
MW+SOA-42
Three Types of ORBs

Server or Operating System Based
CSE
300
Client
ORB
Object
Request
ORB is implemented as
a server (separate process)
which brokers requests
between client and
implementation processes.
ORB is part of the
operating system.
MW+SOA-43
Three Types of Implementations
CSE
300

Single Process “one shot” Object
Object Implementation
Single Process
Single
method
invocation

Implementation is a single
process that is activated
upon the request delivery
Multi-Threaded “resident” Object
Object Implementation
Single Process
Implementation is a permanent
or resident multi-threaded
process
Method C
Method B
Method A
MW+SOA-44
Three Types of Implementations
CSE
300

Multi-Process Object
Object Implementation
Process 1
Method A
Process 2
Method B
Implementation is a set
of processes dedicated to
a particular (group of)
method(s)
Process 3
Method C
Processes can be distributed
MW+SOA-45
Interface Definition Language, IDL

CSE
300




Language used to describe the interfaces that client
objects call and object implementations provide.
Obeys the same lexical rules as C++, but introduces
some new keywords.
Supports standard C++ preprocessing features.
Interfaces can have operations and attributes.
 Operation declaration consists of a return type, an
identifier, a parameter list, and an optional raises
expression (exceptions).
 Attribute declaration is logically equivalent to
declaring a pair of accessor operations. May be
declared as readonly.
Interface specifications are placed in a source file
having the extension “.idl”
MW+SOA-46
IDL: Modules and Interfaces

CSE
300

Module: Used to scope IDL identifiers.
 Mapped to C++ namespace with the same
name. Mapped to a C++ class if the namespace
construct is not supported.
 Mapped to Java package with the same name.
 IDL declarations not enclosed in any module have
global scope when mapped.
Interface: Description of set of operations that a
client may request of an object.
 Multiple inheritance supported
 Interface body may contain the following kinds of
declarations: constant, type, attribute, and
operation.
MW+SOA-47
IDL: Basic Types
CSE
300
Type
Range
short
-215 .. 215-1 (16-bit)
unsigned short
0 .. 216-1 (16-bit)
long
-231 .. 231-1 (32-bit)
unsigned long
0 .. 216-1 (32-bit)
float
IEEE single-precision floating point
double
IEEE double-precision floating point
char
8-bit quantity
boolean
TRUE or FALSE
octet
8-bit (guaranteed during transmission)
any
values that can express any IDL type
MW+SOA-48
IDL: Complex Types

CSE
300


Structures:
 struct FixedLengthStruct {
long
field1; // 32-bit
short
field2; // 16-bit
};
 struct VariableLengthStruct {
long
field1; // 32-bit
string
field2;
};
Discriminated Unions: Cross between the C union
and switch statements.
Enumerations: Ordered list of identifiers.
 enum quality_t {
Poor, Fair, Good, Excellent};
MW+SOA-49
IDL: Complex Types (cont.)

CSE
300


Sequences: One-dimensional array with maximum
size (fixed at compile time) and length (set at run
time).
 Unbounded Sequence:
typdef sequence<long> longSeq;
 Bounded Sequence:
sequence<long,10> fieldname;
Strings: Declared using keyword string. May be
bounded or unbounded.
 string name<32>; //bounded
Arrays: Multidimensional, fixed-size arrays of any
IDL data type.
MW+SOA-50
IDL Example: GUI
CSE
300
/*
* File Name:
*/
GUI.idl
#ifndef GUI_IDL
#define GUI_IDL
module GUI {
struct timespec_t {
long tv_sec;
long tv_nsec;
};
interface Dialog1 {
void update(in Dialog1Data_t val);
};
interface Dialog2 {
void update(in Dialog2Data_t val);
};
};
#endif
// GUI_IDL
struct Dialog1Data_t {
timespec_t
DataTime;
float
val;
};
struct Dialog2Data_t {
timespec_t
DataTime;
long
val;
};
interface MainWindow {
void logEvent(in timespec_t timestamp,
in string val);
};
MW+SOA-51
IDL Example: Server
CSE
300
/*
* File Name:
*/
Server.idl
#ifndef SERVER_IDL
#define SERVER_IDL
#include "GUI.idl"
interface Server {
enum reason_t {
NotInitialized,
ErrorDetected
};
exception NotAvailable {
reason_t reason;
};
exception OperationTimeout {};
void registerMainWindow(
in GUI::MainWindow val,
in boolean flag)
raises (OperationTimeout);
void setMainWindowEnabled(
in boolean flag)
raises (OperationTimeout);
void registerDialog1(
in GUI::Dialog1 val,
in boolean flag)
raises (OperationTimeout);
void setDialog1Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog1Data_t getDialog1Data()
raises (OperationTimeout,
NotAvailable);
void registerDialog2(
in GUI::Dialog2 val,
in boolean flag)
raises (OperationTimeout);
void setDialog2Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog2Data_t getDialog2Data()
raises (OperationTimeout,
NotAvailable);
};
#endif
// SERVER_IDL
MW+SOA-52
What is JINI?

CSE
300

An Infrastructure for Network Centric Applications in
Spontaneous Environment
 Clients Enter/Leave Network Unpredictably
 Resources and Services Enter/Leave due to
Failure, Redundancy, Topology Change
 Both Typify Present/Future Army Systems
Goals of JINI
 Plug-and-Play of Clients and Services
 Erasing Hardware/Software Distinction:
Everything is a Service
 Enable Spontaneous Network Applications
 Architecture where Services Define Function
 Strive for Easy to Use/Understand Technology
MW+SOA-53
Sun’s JINI Technology

CSE
300



JINI is a Sophisticated Java API
Construct Distributed Applications Using JINI by
 Federating Groups of Users
 Resources Provide Services (Database Access,
Printing, Real-Time Sensor) for Users
JINI and Stakeholders
 Core of Technologies to Architect, Design,
Implement, and Test Distributed Applications
 Construct Software “Resistant” to Failure
JINI and Users
 High Availability Through Redundancy
 Dynamic Responses to User Requests
Regardless of Network & Resource Changes
MW+SOA-54
Java Computing Architecture and JINI
CSE
300
MW+SOA-55
JINI Components and Dependencies
CSE
300
Base
Java
Infrastructure
Programming
Model
Services
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java +
JINI
Discovery/Join
Leasing
Distributed
Security
Lookup
Transactions
Transaction
Manager
JavaSpaces
Events
Lookup service
MW+SOA-56
How Does JINI Work?

CSE
300



Distributed Application Constructed Using One or
More Lookup Services
Lookup Service Support Interactions by
 Resources: “Advertise” Services
Discover, Register Services, Renew Lease
 Client: “Locate/Utilize” Services
Discover, Search for Services, Invocation
Multiple Lookup Services
 Resources Responsible for Registering All
 Clients Interact with Multiple Lookups
 Stakeholders Must Write “Apropos” Code
Discovery Initiates Process for Client or Resource
MW+SOA-57
Discovery by Resource & Client
CSE
300
JINI
Lookup
Service
Discovery to
Locate Services
JINI
Lookup
Service
Discovery to
Register Services
Resource
Client
Service Object
Service Attributes
MW+SOA-58
Basic JINI Concepts

CSE
300




JINI Lookup Service Maintains Registry for Available
Services of Distributed Application
Resources Provide Services that Register and Join
with JINI Lookup Service
Clients Discover and Utilize Services Based on
Interface of Services
 Ask Lookup for RegisterForCourse(CSE900)
 Return Proxy for Execution of Service
 Location of Service Transparent to Client
Locations of Clients, Services, Lookup Service, etc.,
can Change over Time
Conceptually, JINI Similar to Distributed OS with
Dynamically Definable/Changeable Resources
MW+SOA-59
Basic JINI Concepts

CSE
300

A Resource Provides a Set of Services for Use by
Clients (Users) and Other Resources (Services)
A Service is Similar to a Public Method
 Exportable - Analogous to API
 Any Entity Utilized by Person or Program
 Samples Include:
 Computation, Persistent Store, Printer, Sensor
 Software Filter, Real-Time Data Source
 Anything that is Relevant for Your Domain!
Services: Concrete Interfaces of Components
Services Register with Lookup Service
 Clearinghouse for Resources to Register Services
and Clients to Locate Services


MW+SOA-60
JINI Resources & Services
CSE
300
JINI
Lookup
Service


Register
Services
Printer Resource
Service Object
Service Attributes
Sun’s Initial Perspective
 JINI for Hardware
Class and
Methods
 Printers, Digital
Define
Cameras, etc.
Services
 Plug-and-Play on
to be
Network
PrinterActions Class Defines Registered
the “Component” that is
Registered with JINI
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
MW+SOA-61
Objectives and Utility of JINI

CSE
300

For Users, JINI Offers
 Sharing of Resources (Services) over Network
 Location Transparency of Users and Services
 Both Critical for “Moving” Personnel
For Stakeholders, JINI Provides
 Infrastructure for Federating Services in
Distributed Setting
 Programming Model to Register & Discover
Services
 Availability of Services Throughout Distributed
Setting
Leading to Ease in Constructing, Maintaining, and
Evolving Network Centric Applications
MW+SOA-62
How Does JINI Work?

CSE
300


Resources Discover and Join Lookup Service
When Resources Leave or Fail to Renew Leases
 Lookup Service Must Adjust Registry
 Time Lag Between Departure and Removal of
Services from Registry
 What Happens When Client Receives Service
Just Prior to Failure?
 Utilization of Java Exception Handling
 Client Code Written to Dynamically Adapt
Resource Register
 Services on Class-by-Class Basis
 Service Object (Java API - Method Signatures)
 Optional Descriptive Service Attributes
MW+SOA-63
JINI Concepts and Terms

CSE
300


Registration of Services via Leasing Mechanism
 Resource Leases Services to Lookup Service
 Resources Renew Services Prior to Expiration
 If not, Services Become Unavailable
 Lookup Service Maintains Registry
 Limit Availability of Services Based on Time,
Workload, User Requirements, etc.
 Services as Available “Components”
Leasing Supports High-Availability
 Registration and Renewal Process
 Upon Failure, Services Removed from Registry
Clients, Resources, Lookup Can Occupy Same or
Different Computing Nodes
MW+SOA-64
Registration & Leasing

CSE
300


FOREVER or EXPIRATION DATE (millisecs)
Renewal Must Occur Prior to Expiration
JINI Provides Lease Renewal Manager to Allow
Resource to Delegate Renewal Responsibility
JINI
Lookup
Service
Leasing/Lease Renewal
Lease for 5 minutes (3000000 msec)
Must Renew Before 5 Minutes Expire
If Not Renewed, Lookup Removes
If Failure, Lookup May Still Supply
Service Until Expiration (5 mins)
Client MUST be SMART!
Printer Resource
Service Object
Service Attributes
Class and
Methods
Define
Services
to be
Registered
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
MW+SOA-65
JINI Support for Distributed Computing
CSE
300
Clients
Using
Services
JINI Lookup
Service
Redundant
Lookups
Java
Client
Database
Legacy
Resources
Provide
Services
COTS
Java
Client
Legacy
Legacy
Client
COTS
Database
Client
COTS
Client
Database
JINI Lookup
Service
Legacy
COTS
MW+SOA-66
Component Perspective and JINI

CSE
300
Resources as Components
 Resources Provide Services
 What Service Provides: Component Interface
 Clients, Servers, Resources, Use Component
Interface to Design/Construct Functionality
Java
Client
Constructed via Services of
Legacy, COTS, Database, etc.
Lookup Registered Services
Functionality via Service Reuse
Services as Component APIs
Legacy
COTS
JINI
Lookup
Service
Database
Legacy
COTS
MW+SOA-67
Two Example Resources

CSE
300


University Application
 Students can Register/Drop Courses and Check
the Schedule/Catalog
 Faculty can Alter Course DB and Check the
Schedule/Catalog
Military Application - Database of Parts
 Ability to Requisition/Add/Delete Parts
 Different User Authority Based on Rank
For Both:
 Client to JINI to Discover Services
 Client to Resource for Method Invocation
(Resembles RMI)
MW+SOA-68
What Does an Actual System Look Like?
CSE
300
Java
GUI
UDB Client
UDBServer Service
GetClasses();
PreReqCourse();
GetVacantClasses();
EnrollCourse();
AddCourse();
RemoveCourse();
Java
GUI
MDB Client
JINI
Lookup
Service
MDBServer
GetParts
GetRequisition
GetReqParts
WriteParts
WriteRequisition
DeletePart
DeleteRequisition
AddParts
RemovePart
AddRequisition
University DB
Resource (UDB)
Military
Requisition
DB
Resource
MW+SOA-69
Join, Lookup, and Service Invocation
CSE
300
Request
Service
AddCourse(CSE900)
Lookup Service
Registry of Entries
Return
Service
Proxy to
AddCourse( )
Client
Service Object
Service Attributes
J Register & Lease Services
CourseDB Class
o
i Contains Method
AddCourse ( )
n
Service Invocation via Proxy
by Transparent RMI Call
Resource
Service Object
Service Attributes
1. Client Invokes AddCourse(CSE900) on Resource
2. Resource Returns Status of Invocation
MW+SOA-70
Services of Military Application

CSE
300




Query Service:
 GetParts: Queries DB for Parts
 GetRequisition: Queries DB for Requisition
 GetReqParts: All Requisition Details for a
Particular Part
Update Service:
 WriteParts: Store Part to DB
 WriteRequisition: Requisition Changes to DB
 DeletePart: Deletes Part from DB
 DeleteRequisition: Deletes Requisition from DB
Other Services/Methods Omitted
Notice: These are Just Public Methods Organized into
Logical Groupings
JINI Allows Searching of Groupings by Service
MW+SOA-71
Execution Process of Client using JINI
CSE
300
1 Register_Client(Harris,Security Off., Military)
Military
Client
4 Return Result,Create_Token(Security Off., Token)
2 Verify_UR(Harris, Security Off.)
5. Discover/Lookup(MilitaryDb,Modification,
CreateRequisition) Returns Proxy to Military Client
6 CreateRequisition(Token, Tank Details, Harris)
11 Return Result,CreateRequisition(…)
Lookup
Service
Security
Registration
Services
3 Client OK?
USR
Security
Authorization
Services
7 IsClient_Registered(Token)
9 Check_Privileges(Token, MilitaryDb, Modification,
CreateRequisition, [Tank Details, Harris])
MilitaryDB
Resource
8 Return Result of IsClient_Registered(…)
Security
Policy
Services
10 Return Result of Check_Privileges(…)
MW+SOA-72
Services Console
CSE
300
MW+SOA-73
Services GUI
CSE
300
MW+SOA-74
What is .NET?

CSE
300



.NET is Microsoft’s Solution to Enterprise Computing
and Interoperability
Aimed to Compete with Java/J2EE
Interoperability: Old (CORBA, COM) & New (RMI)
Provides Uniform Programming Environment via
Extension of C - C#
MW+SOA-75
.NET Architecture and Usage
Three Level Architecture
XML and DataSet as Objects of Interaction

CSE
300

Presentation Tier
Windows Forms
MyApp.Exe
DataSet
Business Tier
Internet
Intranet
Web Forms
Data Tier
Data Object (Class)
IE
Data Adapter
DataSet
XML
DataSet
Data Adapter
Business to Business
(BizTalk, for example)
MW+SOA-76
What are .Net Components?

CSE
300

CTS (Common Type System)
 Defines Common Standard for Languages
CLR (Common Language Runtime)
 Manages the Execution of a .Net Application
 Provides Cross Platform Support By Ensuring
 Type Safety, Code Verification, Exception Handling
 Garbage Collection and Memory Management
 Note: Akin to Java Runtime Environment

ASP.NET
 This Component Provides a Layer of Classes for
Web Services
MW+SOA-77
What are .Net Components?

CSE
300


Windows Forms
 Provides A Layer Of Classes For The Windows
User Interface
ADO.NET
 Provides Classes for Data Access Including
Database and XML
Base Class Library
 Low Level Classes Capture Core .Net
Functionality
 Provides Infrastructure for Construction of
Remaining .net Framework Classes
MW+SOA-78
Remoting in .Net

CSE
300


Remoting Makes an Object in One Process Available
to an Application in Another Process (Akin to RMI)
Marshalling Enables a Controlled Data
Communication Between the 2 Processes
Marshalling an Object Can Occur in 2 Ways
 Marshall By Value:
 Server Creates a Copy of the Object and Passes the
Copy to the Client

Marshall By Reference:
 Server Creates a Reference of the Object and Sends
this Reference to the Client
MW+SOA-79
Remoting in .NET
CSE
300
When a client calls an object marshalled by reference
of the object in the client’s application domain and the
client uses that proxy to access that original object on
the server
MW+SOA-80
Remoting in .NET
CSE
300
When a client calls an object marshaled by value the
server creates and exact copy and sends that copy
to the client. The client then uses the data of the
object and executes the required functionality
directly within the client’s own process without
making any additional calls to the server
MW+SOA-81
Recall Similarity to RMI in Java

CSE
300

Java Objects in JVMs (on Different Computers)
Transparently Invoke Each Other's Methods
RMI Enables Distributed Object Computing
Client
Server
Hello
HelloImpl
HelloApplet
rmic HelloImpl.java
5
Stub
Unmarshall
3
1
2
Stub
Skel
Marshall
Unmarshall
Marshall
NDR
NDR
Skel
RMI Layer
NDR
NDR
Transport
Transport
Start rmiregistery
Transport
Transport
4
MW+SOA-82
Web Services ASP.NET

CSE
300

Communication Based on Open Protocols
 Data via XML
 Schema via XSD
Other Supported Protocols Inlcude:
 UDDI
 DISCO
 WSDL
 SOAP
MW+SOA-83
ADO.NET Architecture
CSE
300
MW+SOA-84
CORBA vs. JINI vs. .NET

CSE
300



Important to Differentiate Between
 Standard (CORBA) – Vendors Implement
 Technologies (JINI, .NET)
Many Different Pros and Cons w.r.t. Infrastructure,
Usage, Environment, Interoperability, Ease of Use,
Programming Requirements, etc. etc. etc.
Many Different Perspectives to Compare Capabilities
and Functionalities of Technologies
What about Other Approaches?
 Terrific Presentation by D. Schmidt
 Combines Patterns and Middleware
 http://www.cs.wustl.edu/~schmidt/patternsframeworks-middleware.ppt
MW+SOA-85
Brief Comparison…

CSE
300




Database Connectivity
 Java uses JDBC and .Net uses Ado.net or
ODBC.NET
Cross platform interoperability
 J2EE and CORBA Easily Supports Interoperation
.Net Focuses on Windows Platform
Programming Languages
 .Net and CORBA Support Multiple Languages
J2EE Focuses on Java (with Links to IDL)
Cross Vendor Interoperability
 J2EE and CORBA Guaranteed by Specifications
Microsoft is the only vendor for .Net
Remoting: Strong Similarities Across All Three
MW+SOA-86
Web Service Oriented Architectures (WSOA)

CSE
300


An SOA is often Cast in a Web-Based Setting
Possible Services include:
 Data Transfer (e.g. FTP) or Storage Service
 Troubleshooting Service
Service Operations (Messages) are Encapsulated
Behind a Message-Oriented Service Interface
 Hides Details of Service Implementation/Location
 Assumes an Architecture for Access
 Provides a Logical View that is Message-Oriented
 Available Service/Messages are Descriptively
Supplied for Purpose of Discovery/Lookup
 Network-Oriented
 Scalable – Add New Services/Extend Existing
Services for New/Improved Functionality
MW+SOA-87
WSOA in Practice

CSE
300
From Web Services Architecture, W3C
A Web service is a software system designed to
support interoperable machine-to-machine interaction
over a network. It has an interface described in a
machine processable format (specifically WSDL).
Other systems interact with the Web service in a
manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Webrelated standards.
MW+SOA-88
Web Services Architecture from W3C

CSE
300

Complex
Architecture with
Many Different
Capabilities and
Features
 Open Ended
(Like Web)
 Target Multiple
Domains/Usages
Current Web and
Future (Emerging?)
Semantic Web
MW+SOA-89
Another WSOA Example
CSE
300
From: http://www.service-architecture.com/
MW+SOA-90
Another WSOA Example
CSE
300
From: http://www.service-architecture.com/
MW+SOA-91
Service Oriented Architecture
Reference Model
An informal SOA Ontology
http://ontolog.cim3.net/file/resource/workshop/jul-2006/soa2006-07.ppt
Reference Model
• An abstract framework for
understanding significant relationships
among the entities of some
environment.
• Consists of a minimal set of unifying
concepts, axioms and relationships
within a particular problem domain.
• Is independent of specific standards,
technologies, implementations, or other
Reference Model
Service Oriented Architecture
• Service Oriented Architecture is a
paradigm for organizing and utilizing
distributed capabilities that may be
under the control of different ownership
domains.
• Goal of this reference model is to define
the essence of Service Oriented
Architecture
Why Service Oriented
Architecture?
• Drivers:
• Large scale Enterprise systems
• Internet scale provisioning of services
• Reduce the cost of doing business
• Benefits
• Build scalable, evolvable systems
• Scalable because minimizes assumptions
• Manage complex systems
• Encourage re-use of business function
Why is it different?
• SOA reflects the reality of ownership
boundaries
• CORBA, RMI, COM, DCOM, etc. all try to
implement transparent distributed systems
• Ownership is of the essence in SOA
• SOA is task oriented
• Services are organized by function
• Getting something done
• SOA is inspired by human organizations
• It worked for us, it should work for machines
What is not in the RM
• Service composition
• Choreography, orchestration
• Process Oriented Architecture
• Organizational framework
• Who is doing what to whom
• Specific technologies
• not even specific architectures
Key concepts
Service
• A mechanism to enable access to
one or more capabilities
• using a prescribed interface
• consistent with constraints and
policies as specified by the service
description.
Visibility
Visibility is the relationship
between service participants that is
satisfied when they are able to
interact with each other
• Awareness
• Service description
• Discovery
• Willingness
• Policy & contract
• Reachability
• Communication
Interaction
Interacting with a service involves performing actions against the service
The extent to which one system can
effectively interpret information from
another system is governed by the
semantic engagement of the
various systems.
The semantic engagement of a
system is a relationship between the
system and information it may
encounter.
Real World Effect
The purpose of using a capability is to realize one or more real world effects.
At its core, an interaction is “an act” as opposed to “an object” and the
result of an interaction is an effect (or a set/series of effects).
The real world effect is couched
in terms of changes to the state shared by
the participants and stakeholders in
a service interaction
About Services
Conditions and Expectations
• Policy
• Constraint representing the
intention of a participant in a
service
• Contract
• Constraint representing an
agreement between two or
more participants.
Description
The service description
represents the information
needed in order to use,
manage or provide a
service.
• Service reachability
• Service Functionality
• Service Policies
• Service Interface
Execution Context
The execution context is the set of infrastructure elements,
process entities, policy assertions and agreements that are
identified as part of an instantiated service interaction,
and thus forms a path between those with needs and those
with capabilities
Is a Reference Model an
Ontology?
• Establishing a vocabulary
• A lot of definitions
• The RM glossary has 28 entries
• Formality was considered
• Audience is not formal
• Mechanical processing of RM not expected
What about UML
• UML obvious choice for an architecture
spec
• But,
• Inheritance (is-a) relationship almost never
used
• Extraneous precision
• E.g. we tried to define Service, not count the
number of service providers
• It’s so ugly <duck/>
An early concept map
Concepts Maps
Concepts maps
were excellent
graphical
indices
to
text
Concepts, and
relationships.
All we needed
On the cutting-room floor…
Where we are
• Committee Specification published
• Reference Architecture effort started
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Comments on WSOA

CSE
300



Wealth of Information on WSOA Available on-Line
Let’s Review Four Other Presentations Briefly
 http://download.microsoft.com/download/b/d/b/bd
b24175-50bc-4e74-8df9835cef6521cb/ConnectedSystems.ppt
 http://www.cs.queensu.ca/home/cords/soa.ppt
 http://www.rgoarchitects.com/Files/SOA.ppt
 http://www.wsmo.org/TR/d17/resources/200605OASIS/SemanticServiceOrientedArchitectureTuto
rial.ppt
All Links on Course Web Page
Last Presentation Transitions from SOA to Semantic
Web
MW+SOA-114
Service Oriented Architecture
& Grid Computing
Marc Brooks, The MITRE Corporation
The author's affiliation with The MITRE Corporation is provided
for identification purposes only, and is not intended to convey or
imply MITRE's concurrence with, or support for, the positions,
opinions or viewpoints expressed by the author.
What is Grid Computing?
“A computational grid is a hardware and software infrastructure
that provides dependable, consistent, pervasive, and
inexpensive access to high-end computational capabilities.”
-”The Grid: Blueprint for a New Computing Infrastructure”, Kesselman & Foster
Criteria for a Grid*:
1. Coordinates resources that are not subject
to centralized control.
2. Uses standard, open, general-purpose
protocols and interfaces.
3. Delivers nontrivial qualities of service
Source: “What is the Grid? A Three Point Checklist”, Ian Foster, Argonne National Laboratory & University of Chicago
Grid Computing Benefits

Exploit Underutilized resources

CPU Scavenging, Hotspot leveling
Resource Balancing
 Virtualize resources across an enterprise



Data Grids, Compute Grids
Enable collaboration for virtual
organizations
Two Key Grid Computing Groups
The Globus Alliance (www.globus.org)
 Composed of people from:
Argonne National Labs, University of Chicago, University of Southern
California Information Sciences Institute, University of Edinburgh and
others.

OGSA/I standards initially proposed by the Globus Group

Based off papers “Anatomy of the Grid” & “Physiology of the Grid”
The Global Grid Forum (www.ggf.org)
 History


Heavy involvement of Academic Groups and Industry


First meeting in June of 1999, Based off the IETF charter
(e.g. IBM Grid Computing, HP, United Devices, Oracle, UK e-Science
Programme, US DOE, US NSF, Indiana University, and many others)
Process

Meets three times annually
 Solicits involvement from industry, research groups, and academics
Companies involved in Grid Computing













Avaki
Axceleon
CapCal
Centrata
DataSynapse
Distributed Science
Elepar
Entropia.com
Grid Frastructure
GridSystems
Groove Networks
IBM
Intel











Jivalti
Mithral
Mind Electric
Mojo Nation
NewsToYou.com
NICE, Italy
Noemix, Inc.
Oracle
Parabon
Platform Computing
Popular Power
Source: http://www.gridcomputing.com/










Powerllel
ProcessTree
Sharman Networks Kazza
Sun Gridware
Sysnet Solutions
Tsunami Research
Ubero
United Devices
Veritas
Xcomp
Standards involved with SOA & Grid Computing
SOA Standards
 WSDL
 UDDI
 BPEL
 WS-Profile
 WS-Security
 WS-Choreography
And many others…
Grid Standards
 OGSI
 Extension
to WSDL
 WS-Resource
 WS-ResourceLifetime
 WS-
ResourceProperties
 WSRenewableReferences
 WS-ServiceGroup
 WS-BaseFaults
Grid and Web Services Standards
Started far
apart in
applications
&
technology
Have been
converging
WSRF
WS-I Compliant
Technology
Stack
Convergence of Core Technology Standards allows
Common base for Business and Technology Services
Service Oriented Architecture
“What is Service-Oriented Architecture?”. Hao He.
http://webservices.xml.com/lpt/a/ws/2003/09/30/soa.html
“Service-Oriented Architecture: A Primer”. Michael S. Pallos.
http://www.bijonline.com/PDF/SOAPallos.pdf
“The Benefits of a Service-Oriented Architecture”. Michael Stevens.
http://www.developer.com/design/article.php/1041191
Web Services Specifications - http://www.w3.org/2002/ws/
Grid Computing
Global Grid Forum (http://www.ggf.org)
The Globus Alliance ( http://www.globus.org)
“The Physiology of the Grid”. Ian Foster, Carl Kesselman, Jeffrey M.
Nick, Steven Tuecke. http://www.globus.org/research/papers/ogsa.pdf
“The Anatomy of the Grid”. Ian Foster, Carl Kesselman, Steven Tuecke.
http://www.globus.org/research/papers/anatomy.pdf
Web Services Resource Framework - http://www.globus.org/wsrf/
What is the Grid?
• The World Wide Web provides seamless access to information that
is stored in many millions of different geographical locations
• In contrast, the Grid is an emerging infrastructure that provides
seamless access to computing power and data storage capacity
distributed over the globe.
From: http://gridcafe.web.cern.ch/gridcafe/demos/Grid-beginners.ppt
What is the Grid?
• The term Grid was coined by Ian Foster and Carl
Kesselman (Grid bible “The Grid: blueprint for a new
computing infrastructure”).
• The name Grid is chosen by analogy with the
electric power grid: plug-in to computing power
without worrying where it comes from, like a toaster.
• The idea has been around under other names for a
while (distributed computing, metacomputing, …).
•This time, technology is in place to realise the
dream on a global scale.
How will it work?
• The Grid relies on advanced software, called middleware, which
ensures seamless communication between different computers and
different parts of the world
• The Grid search engine will not only find the
data the scientist needs, but also the data
processing techniques and the computing
power to carry them out
• It will distribute the
computing task to
wherever in the world
there is spare
capacity, and send the
result to the scientist
How will it work?
The GRID middleware:
• Finds convenient places for the scientists “job” (computing task) to be run
• Optimises use of the widely dispersed resources
• Organises efficient access to scientific data
• Deals with authentication to the different sites that the scientists will be
using
• Interfaces to local site authorisation
and resource allocation policies
• Runs the jobs
• Monitors progress
• Recovers from problems
… and ….
Tells you when the work is complete and transfers the result back!
What are the challenges?
Must share data between thousands of scientists with multiple
interests
Must link major computer centres, not just PCs
Must ensure all data accessible anywhere, anytime
Must grow rapidly, yet remain reliable for more than a decade
Must cope with different management policies of different centres
Must ensure data security: more is at stake than just money!
Must be up and running by 2007
Benefits for Science
• More effective and seamless collaboration of dispersed
communities, both scientific and commercial
• Ability to run large-scale applications comprising thousands of
computers, for wide range of applications
• Transparent access to distributed resources from your desktop,
or even your mobile phone
• The term “e-Science” has been coined to express these
benefits
Grid projects in the world
•UK e-Science Grid
•Netherlands – VLAM, PolderGrid
•Germany – UNICORE, Grid proposal
•France – Grid funding approved
•Italy – INFN Grid
•Eire – Grid proposals
•Switzerland - Network/Grid proposal
•Hungary – DemoGrid, Grid proposal
•Norway, Sweden - NorduGrid
•NASA Information Power Grid
•DOE Science Grid
•NSF National Virtual Observatory
•NSF GriPhyN
•DOE Particle Physics Data Grid
•NSF TeraGrid
•DOE ASCI Grid
•DataGrid (CERN, ...)
•DOE Earth Systems Grid
•EuroGrid (Unicore)
•DARPA CoABS Grid
•DataTag (CERN,…)
•NEESGrid
•Astrophysical Virtual Observatory
•DOH BIRN
•GRIP (Globus/Unicore)
•NSF iVDGL
•GRIA (Industrial applications)
•GridLab (Cactus Toolkit)
•CrossGrid (Infrastructure Components)
•EGSO (Solar Physics)
Grid Applications for Science
• Medical/Healthcare (imaging, diagnosis and
treatment )
• Bioinformatics (study of the human genome and
proteome to understand genetic diseases)
• Nanotechnology (design of new materials from the
molecular scale)
• Engineering (design optimization, simulation, failure
analysis and remote Instrument access and
control)
• Natural Resources and the Environment
(weather forecasting, earth observation, modeling
and prediction of complex systems)
Medical/Healthcare Applications
• Digital image archives
• Collaborative virtual environments
• On-line clinical conferences
“The Grid will enable a
standardized, distributed digital
mammography resource for
improving diagnostic
confidence"
“The Grid makes it possible to use
large collections of images in new,
dynamic ways, including medical
diagnosis.”
“The ability to visualise 3D
medical images is key to
the diagnosis of
pathologies and presurgical planning”
Quotes from: http://gridoutreach.org.uk
Bioinformatics
• Capturing the complex and evolving patterns of genetic
information, determining the development of an embryo
• Understanding the genetic interactions that underlie the processes
of life-form development, disease and evolution.
“Every time a new genome
is sequenced the result is
compared in a variety of
ways with other genomes.
Each code is made of 3.5
billion pairs of chemicals…”
Nanotechnology
• New and 'better' materials
• Benefits in pharmaceuticals, agrochemicals, food production,
electronics manufacture from the faster, cheaper discovery of new
catalysts, metals, polymers, organic and inorganic materials
“The Grid has the potential
to store and analyze data on
a scale that will support
faster, cheaper synthesis of
a whole range of new
materials.”
Quotes from: http://gridoutreach.org.uk
Natural Resources/Environment
• Modeling and prediction of earthquakes
• Climate change studies and weather forecast
• Pollution control
• Socio-economic growth planning, financial modeling and
performance optimization
“Federations of
heterogeneous databases
can be exploited through
the Grid to solve complex
questions about global
issues such as
biodiversity.”
Quotes from: http://gridoutreach.org.uk
Precursors of the Grid
• SETI@home: sharing of spare PC processing power to analyze
radio signals
• Napster: sharing of data (music) between computers
• Entropia DCGrid: commercial solution for sharing workstations
within a company
The difference:
The Grid CERN is developing will combine resources at major
computer centers, and require dedicated equipment and
sophisticated middleware to monitor and allocate resources
SETI@home: a grassroots Grid
>1 million years of computer processing time
>3.5 million have downloaded the screensaver
>30 Teraflops rating (ASCI White = 12 Teraflops)
Spinoff from SETI@home
Spawned a cottage industry
Xpulsar@home, Genome@home, Folding@home,
evolutionary@home, FightAIDS@home, SARS@home...
Spawned a real industry
Entropia, United Devices, Popular Power...
Major limitations:
Only suitable for “embarrasingly parallel” problems
Cycle scavenging relies on goodwill
Who will use Grids?
• Computational scientists & engineers: large scale
modeling of complex structures
• Experimental scientists: storing and analyzing large
data sets
• Collaborations: large scale multi-institutional projects
• Corporations: global enterprises and industrial
partnership
• Environmentalists: climate monitoring and modeling
• Training & education: virtual learning rooms and
laboratories
Comments on Grid Computing

CSE
300


What is Applicability of Grid Computing to the
Medical Domain and its Applications?
Let’s Review Three Other Presentations Briefly
 http://www.aciagir.org/publis/posterAgirParistic2006.PPT
 http://bmi.osu.edu/resources/presentations/BISR_o
verview_poster.ppt
 http://www.dma.unina.it/~murli/ISSGC06/session31.5/ISSGC06%20Experience%20with%20biome
d%20applications%20v1.ppt
All Links on Course Web Page
MW+SOA-139
Final Comments

CSE
300

Three Converging Technologies:
 Classic (CORBA) and Emerging (Jini, .NET)
Middleware
 Web-Based Service Oriented Architectures and
Computing
 Grid Computing
Think back to “Macro Architectures”
 Systems of Systems
 Old + New
 Centralized + Distributed
 Solving “Huge” Problems
 Facilitating Access (Services)
MW+SOA-140