Middleware, Service-Oriented
Architectures and Grid Computing
CSE
5810
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
steve@engr.uconn.edu
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
5810


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 Health IT Systems and Health
Information Exchange Exhibit All of These
Characteristics and More!
MW+SOA-2
What is a Distributed Application?
CSE
5810
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
5810



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
5810


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
5810

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
5810


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
5810

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
5810
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
5810



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
5810

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# (we will skip)
MW+SOA-15
What Must All SOA Provide?

CSE
5810
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
5810
MW+SOA-17
Supplier /Consumer Model
CSE
5810
SUPPLY
Build New
Wrap Existing
Buy
CONSUME
Assemble
Applications
MANAGE
Publish
Subscribe
Catalog
Browse
MW+SOA-18
Objectives of SOA

CSE
5810







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?
How can SOA be Leverage for HIE/HIT?
MW+SOA-19
Overview of Presentation

CSE
5810




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
Where does Cloud Computing Fit?
MW+SOA-20
What is CORBA?

CSE
5810


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
5810


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
5810

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
5810
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
5810

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
5810











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
5810



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
5810



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
5810
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
5810





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
5810


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
5810
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
5810


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
5810


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
Repositories: Interface and Implementation

CSE
5810

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-35
Three Types of ORBs

Single Process Library Resident
CSE
5810
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-36
Three Types of ORBs

Server or Operating System Based
CSE
5810
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-37
Three Types of Implementations
CSE
5810

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-38
Three Types of Implementations
CSE
5810

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-39
Interface Definition Language, IDL

CSE
5810




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-40
IDL: Modules and Interfaces

CSE
5810

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-41
IDL: Basic Types
CSE
5810
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-42
IDL: Complex Types

CSE
5810


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-43
IDL: Complex Types (cont.)

CSE
5810


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-44
IDL Example: GUI
CSE
5810
/*
* 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-45
IDL Example: Server
CSE
5810
/*
* 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-46
A Comparison of
Jini and CORBA
Andrew See
Liyuan Yu
Zhongying Wang
Michael Collins
What is CORBA?



Common Object Request Broker Architecture
(CORBA) specification defines a framework for
object-oriented distributed applications..
It is an open standard for heterogeneous
computing.
Allows distributed programs in different
languages and different platforms to interact as
though they were in a single programming
language on one computer
Object Request Broker (ORB)

A software component that mediates transfer of
messages from a program to an object located
on a remote host.
0. Invocation ( with an
Client
ORB
Network
ORB
Server
object reference)
1.
Locate CORBA objects
and marshal parameters
invocation
0
1
CORBA Object
2.
Network Delay
3.
Unmarshal parameters
4.
Method Execution
5.
Result marshal
6.
Network Delay
7.
Result unmarshal
2
3
5
4
execution
6
7
CORBA Objects and IDL

Each CORBA object has a clearly defined interface
specified in CORBA interface definition language
(IDL).


Distributed objects are identified by object references,
which are typed by the IDL interfaces.
The interface definition specifies the member functions
available to the client without any assumption about the
implementation of the object.
Example of IDL
stockMarket.idl
module stockMarket{
interface StockServer {
float getStockValue (in string stockName);
void setStockValue (in string stockName, in long value);
}
…………..
}
No Implementation details in IDL
Stub and Skeleton

“Glue” that connects language-independent IDL interface
specifications to language –specific implementation
Client
Object
Object
Stub
Client
Stub
ORB

Automatically generated by IDL compiler
Design of the Game Project with CORBA

Centralized Version:
locate service
return server reference
locate service
Naming Service
return server reference
Player1
Player2
play
register Service
play
play
Game Server
Two Games:

Guess Game:
Two Games (Cont.)

HangMan:
Design Details--IDL
module GameApp{
interface Player
{
void displayMessage(in string m);
string getPlayerID();
};
interface GuessPlayer: Player
{
};
interface HangmanPlayer: Player
{
void drawMan(in long numWrong);
};
interface Server
{
void addPlayer(in Player p);
void removePlayer(in string playerID);
void startGame(in string playerID);
void QuitGame(in string playerID);
void takeTurn(in string playerID);
};
interface GuessServer: Server
{
void takeTurn(in long number, in string
playerID);
};
interface HangmanServer: Server
{
void takeTurn(in char w,in string word,
in string playerID);
};
};
Design Details--UML
<<interface>>
GuessPlayer
<<interface>>
HangmanPlayer
<<interface>>
GuessServer
<<interface>>
HangmanServer
+takeTurn()
+takeTurn()
<<interface>>
Interface1
<<interface>>
Player
+addPlayer()
+removePlayer()
+StartGame()
+QuitGame()
+takeTurn()
+getPlayerID()
+displayMessage()
implements
Automatically generated
by IDLtoJAVA compiler
implements
Java Implementation
GameServerImpl
PlayerImpl
+addPlayer()
+removePlayer()
+StartGame()
+QuitGame()
+takeTurn()
+getPlayerID()
+DisplayMessage()
GuessPlayer
HangmanPlayer
GuessServerImpl
HangmanServerImpl
+DrawMan()
+takeTurn()
+takeTurn()
Design of the Game Project with
CORBA

Decentralized Version
play
Player1
return server info
locate service
return server info
Naming Service
Player2
locate service
register Service
Return partner info
Create playerlist
Game Server
Return partner info
Design Details-IDL
module GameApp
{
interface Player
{
void receiveMessage(in string m);
string getPlayerID();
void startGame(in string data);
void startNewGame(in string data);
void QuitGame();
void response(string number, in string data);
void takeTurn();
};
interface Server
{
string addPlayer(in string p, in string ncRef);
};
};
Design Details- UML
Interface generated
By IDL Compile
Implement by
programmer
What is JINI?

CSE
5810

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-61
Sun’s JINI Technology

CSE
5810



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-62
Current Status of JINI

CSE
5810


Now an Apache Project
 https://river.apache.org/about.html
 https://river.apache.org/
 https://river.apache.org/doc/specs/html/jinispec.html
Continued Further Development and Advancement of
JINI
Apache River 2.2.3 Released - February 21, 2016
MW+SOA-63
Java Computing Architecture and JINI
CSE
5810
MW+SOA-64
JINI Components and Dependencies
CSE
5810
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-65
How Does JINI Work?

CSE
5810



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-66
Discovery by Resource & Client
CSE
5810
JINI
Lookup
Service
Discovery to
Locate Services
JINI
Lookup
Service
Discovery to
Register Services
Resource
Client
Service Object
Service Attributes
MW+SOA-67
Basic JINI Concepts

CSE
5810




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-68
Basic JINI Concepts

CSE
5810

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-69
JINI Resources & Services
CSE
5810
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-70
Objectives and Utility of JINI

CSE
5810

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-71
How Does JINI Work?

CSE
5810


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-72
JINI Concepts and Terms

CSE
5810


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-73
Registration & Leasing

CSE
5810


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-74
JINI Support for Distributed Computing
CSE
5810
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-75
Component Perspective and JINI

CSE
5810
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-76
Two Example Resources

CSE
5810



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)
How Would Health Care Application Define
Resources?
MW+SOA-77
What Does an Actual System Look Like?
CSE
5810
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-78
Join, Lookup, and Service Invocation
CSE
5810
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-79
Services of Military Application

CSE
5810




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-80
Execution Process of Client using JINI
CSE
5810
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-81
Services Console
CSE
5810
MW+SOA-82
Services GUI
CSE
5810
MW+SOA-83
Jini
Jini Background
Embedded hardware is network-centric,
not disk-centric
 Networks are dynamic; so is Jini
 Object interface; not network protocol
 Service: A network-accessible device that
provides a useful function
 Client: Any user who requests services

Runtime Architecture

Federation of services
 No

central authority
Lookup Service
 Directory
of currently available services
 Services can be searched by clients
 Execution of services is independent of Jini
 As backup, Jini also allows network protocol
How Jini Works
Separation of Interface &
Implementation

Services may grant varying access to
clients
 Entire
service is downloaded and run locally
 Service object is a proxy to remote server

Methods are remote calls to service, which actually
does the work
 Both
local and remote objects share work
Separation of Interface &
Implementation


Client is not required to know network protocol
between proxy & service
Service responsible for service object; may
communicate using RMI, CORBA, DCOM, etc.
Jini Program Design

Player
 One

player for all Games
Games
 Separate
communication from game specific
rules
 Generalize common game tasks
Add/remove a player
 Take a turn
 Update Player state

Design – Games
Interface
GameProxy
Interface
Game
Interface
RemoteGame
BasicGameProxy
AbstractGame
TurnBasedGame
HangmanProxy BlackjackProxy
GuessingGame
Hangman
Blackjack
Design – Players
Interface
Player
PlayerImpl
(terminal based)
GuiPlayer
(GUI based)
Terminal and GUI
based clients have
same functionality.
Implementation
Lease
Jini
name service
Register
GameProxy
GameProxy
Lookup
Server
Remote Game
Player
addPlayer,
TakeTurn
addPlayer,
GameProxy TakeTurn
(local processing)
Implementation – Code samples
 Creating the server-side object:
Game impl = new GuessingGame();
RemoteGame implProxy =
(RemoteGame)exporter.export(impl);
 Creating the proxy:
smartProxy = new BasicGameProxy(implProxy);
 Registering the proxy:
ServiceItem item = new ServiceItem(null, smartProxy,
attrs);
…
reg = registrar.register(item, Lease.FOREVER);
Implementation – Code samples
(cont.)

Player taking a turn:
Player:
protected void takeTurn(String action){
game.takeTurn(action,id); }
 GameProxy – this version just forwards to remote
implementation:
public void takeTurn(String action, Object id)
throws RemoteException {
impl.takeTurn(action,id); }
…
player.setGameData(data);


The rules for the game could be in the RemoteGame
implementation, or the Game Proxy, or split between
them.
Web Service Oriented Architectures (WSOA)

CSE
5810


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-97
WSOA in Practice

CSE
5810
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 Web-related standards.
MW+SOA-98
Web Services Architecture from W3C

CSE
5810

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-99
Another WSOA Example
CSE
5810
From: http://www.service-architecture.com/
MW+SOA-100
Another WSOA Example
CSE
5810
From: http://www.service-architecture.com/
MW+SOA-101
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/session
31.5/ISSGC06%20Experience%20with%20biome
d%20applications%20v1.ppt
All Links on Course Web Page
MW+SOA-126
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)
How Does Cloud Computing Fit In?
MW+SOA-127