Document 7136914
Download
Report
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