Page 1
© City University London, Dept. of Computing Distributed Systems / 2 - 1
Distributed Systems
Session 2: Distributed Software Engineering
Christos KloukinasDept. of Computing
City University LondonSoftware Engineering: the study of techniques used to produce high-quality software
Page 2
© City University London, Dept. of Computing Distributed Systems / 2 - 2
Outline
0 LAST Session Summary + additional material.
1 Motivation
2 The CORBA Object Model
3 The OMG Interface Definition Language (IDL)
4 Other Approaches
5 Summary
Page 3
© City University London, Dept. of Computing Distributed Systems / 2 - 3
Summary & Key Points of Lecture 1
What is a Distributed System? Adoption of DS is driven by Non-Functional
Requirements Distribution needs to be transparent to users
and application designers Transparency has several dimensions Transparency dimensions depend on each
other
Page 4
© City University London, Dept. of Computing Distributed Systems / 2 - 4
Definition
A distributed system consists of a collection of autonomous computers, connected through a network and distributed operating system software, which enables computers to coordinate their activities and to share the resources of the system, so that users perceive the system as a single, integrated computing facility.
Certain common characteristics can be used to assess distributed systems: Resource Sharing, Openness, Concurrency, Scalability, Fault Tolerance, and Transparency
Page 5
© City University London, Dept. of Computing Distributed Systems / 2 - 5
Distributed System Types (Enslow 1978)
Fully Distributed
Data
Processors
Control
Fully replicated
Not fully replicated master directory
Local data, local directory
Master-slave
Autonomous transaction based
Autonomous fully cooperative
Homog. specialpurpose
Heterog.specialpurpose
Homog.generalpurpose
Heterog.generalpurpose
Page 6
© City University London, Dept. of Computing Distributed Systems / 2 - 6
Dimensions Of Transparency
Scalability Transparency
Migration Transparency
Access Transparency
Performance Transparency
Replication Transparency
Location Transparency
Failure Transparency
Concurrency Transparency
Page 7
© City University London, Dept. of Computing Distributed Systems / 2 - 7
1.3 Model of a Distributed System
Component 1 Component n
Middleware
Network Operating System
Hardware
Host 1
Component 1 Component n
Middleware
Network Operating System
Hardware
Host n
..
..
………...
Network
Page 8
© City University London, Dept. of Computing Distributed Systems / 2 - 8
Middleware Examples
Transaction-oriented» IBM CICS
» BEA Tuxedo
» IBM Encina
» MS Transaction Server
Message-oriented» MS Message Queue
» NCR TopEnd
» IBM MQSeries
» Sun Tooltalk
» Sun JavaSpaces
Procedural» Sun ONC
» Linux RPCs
» OSF DCE
Object-oriented» OMG CORBA
» Sun Java/RMI
» Microsoft COM
» Sun Enterprise Java Beans
Page 9
© City University London, Dept. of Computing Distributed Systems / 2 - 9
0.3 Client-Server Computing(O’Leary 2000)
A client is defined as a requester of services A server is defined as a provider of services A single machine can be both a client and a
server depending on the software configuration
Page 10
© City University London, Dept. of Computing Distributed Systems / 2 - 10
0.4 Client-Server (O’Leary 2000)
Processing can be improved because client and server share processing loads
» Client/server computing considers that the client has computing power that is not being used
» Fundamental idea is to break apart an application into components that can run on different platforms
Thin vs. Fat Clients: » a thin client has most of the functionality with server;
» a fat client has most of the functionality with the client.
Page 11
© City University London, Dept. of Computing Distributed Systems / 2 - 11
0.5 Two tier architectures
The user system interface is usually located in the user's desktop environment.
Database management services are usually in a server that is a more powerful machine that services many clients.
Processing management is split between the user system interface environment and the database management server environment.
The database management server provides stored procedures and triggers.
Good for LAN with work group users < 100
Page 12
© City University London, Dept. of Computing Distributed Systems / 2 - 12
0.6 Three-Tiered Architecture
Three Tiered Architecture is an information model with distinct pieces -- client, applications services and data sources -- that can be distributed across a network.
Client Tier -- The user component displays information, processes, graphics, communications, keyboard input and local applications.
Applications Service Tier -- A set of sharable multitasking components that interact with clients and the data tier. It provides the controlled view of the underlying data sources.
Data Source Tier -- One or more sources of data such as mainframes, servers, databases, data warehouses, legacy applications etc.
Page 13
© City University London, Dept. of Computing Distributed Systems / 2 - 13
0.7 Examples of three tier architectures
Three tier architecture with transaction processing monitor technology
Three tier with message server Three tier with an application server Three tier with an ORB architecture( e.g CORBA) Distributed/collaborative enterprise architecture.
Page 14
© City University London, Dept. of Computing Distributed Systems / 2 - 14
ORB
CORBA IIOPO
RB
ORB
ORB
ORB
DBMS
Lotus Notes
TP Monitors
Tier 2Server Objects
Tier 1View Objects Legacy Applications
Tier 3
Business Objects
0.8 Three Tier Client/Server Object Style
Page 15
© City University London, Dept. of Computing Distributed Systems / 2 - 15
1 CORBA – Motivation & Overview
Distributed Systems consist of multiple components.
Components are heterogeneous. Components still have to be interoperable. There has to be a common model for
components, which expresses» component states,
» component services, and
» interaction of components with other components.
Page 16
© City University London, Dept. of Computing Distributed Systems / 2 - 16
1.1 Example1: Java Object Model & Java Language
Object»Runtime entity instance of class
Interface»declare a set of methods for a Java object
without implementation Method Invocation
»primitive type passed by value»object references passed by value
Page 17
© City University London, Dept. of Computing Distributed Systems / 2 - 17
1.2 Ex 2: Distributed Object Model (Wolrath et al)
Remote object» object whose methods can be accessed from another address space
Remote interface» an interface that declares the methods of a remote object
throws Remote Exception to deal with different failure models
RMI» non-remote object passed by value
» remote object passed by remote reference
Page 18
© City University London, Dept. of Computing Distributed Systems / 2 - 18
1.3 CORBA Object Model & OMG IDL
Model describes components, states, interactions and other concepts
OMG/IDL is a language for expressing all concepts of the CORBA object model.» separation of interface from implementation
» Enables interoperability and transparency
» IDL compiles into client stubs and server skeletons
» Stubs and skeletons serve as proxies for clients and servers, respectively
Page 19
© City University London, Dept. of Computing Distributed Systems / 2 - 19
1.4 CORBAClient
Object Request Broker
Client StubClient Stub
Request
CORBA Object Implementations
CORBA ServicesCORBA Services
C++ Ada Cobol SmalltalkJavaC
Server SkeletonServer Skeleton
IDLIDL IDLIDL IDLIDL IDLIDL IDLIDL IDLIDL
C++ Ada Cobol SmalltalkJavaC
Page 20
© City University London, Dept. of Computing Distributed Systems / 2 - 20
1.5 Example1: StockQuoter IDL Interface
module Quoter {//stock quoter server, some interface to query the prices of
stock exception Invalid_Stock_Symbol {};
interface Stock; interface Stock_Factory { Stock get_stock (in string stock_symbol) raises (Invalid_Stock_Symbol);
}; interface Stock {
readonly attribute string symbol; // Get the stock symbol. readonly attribute string full_name; // Get the name. double price (); // Get the price }; };
Page 21
© City University London, Dept. of Computing Distributed Systems / 2 - 21
2.3 Example 2: ATM Controller
Page 22
© City University London, Dept. of Computing Distributed Systems / 2 - 22
Teller Controller IDL Definition
interface ATM;
interface TellerCtrl {
typedef sequence<ATM> ATMList;
exception InvalidPIN;
exception NotEnoughMoneyInAccount {...};
readonly attribute ATMList ATMs;
readonly attribute BankList banks;
void accept_request(in Requester req,
in short amount)
raises(InvalidPIN,NotEnoughMoneyInAccount);
};
Page 23
© City University London, Dept. of Computing Distributed Systems / 2 - 23
2 The CORBA Object Model
Components objects. Component state object attributes.
Usable component services object operations.
Component interactions operation execution requests.
Component service failures exceptions.
Page 24
© City University London, Dept. of Computing Distributed Systems / 2 - 24
3 The OMG Interface Definition Language OMG/IDL is a language for expressing all concepts of the CORBA
object model.
IDL is a 'contractual' language that lets you specify a component's (object's) boundaries and its interfaces with potential clients
CORBA IDL is language neutral and totally declarative, i.e., it does not define implementations details
Provides operating system and programming language independent interfaces to all services and objects that reside on the CORBA bus.
Different programming language bindings are available. (We’ll
work with Java)
Page 25
© City University London, Dept. of Computing Distributed Systems / 2 - 25
2.1 Types of Distributed Objects
Attributes and operations and exceptions are properties defined in object types.
Object types are those properties that are shared by similar objects. Only their identity and values of their attributes differ.
Objects may export these properties to other objects.
Objects are instances of types.
Object types are specified through interfaces that determine the operations that clients can request, that is, they define a contract that binds the interaction between client and sever objects.
Page 26
© City University London, Dept. of Computing Distributed Systems / 2 - 26
3.1 Types
A type is one of the following: Atomic types
(void, boolean, short, long, float, char, string), Object types (interface), Constructed types:
» Records (struct),
» Variants (union), and
» Lists (sequence), or Named types – aliases (typedef).
Page 27
© City University London, Dept. of Computing Distributed Systems / 2 - 27
3.1 Types (Examples)
struct Requester {
int PIN;
string AccountNo;
string Bank; };
typedef sequence<ATM> ATMList;
Page 28
© City University London, Dept. of Computing Distributed Systems / 2 - 28
2.2 Attributes
Attributes have a (unique) name and a type Type can be an object type or a non-object type
(e.g., Boolean values, characters or numbers). Attributes are readable by other components Attributes may or may not be modifiable by other
components (readonly). Attributes correspond to one or two operations
(get/set). Attributes are declared within an interface. Attribute name must be unique within interface.
Page 29
© City University London, Dept. of Computing Distributed Systems / 2 - 29
2.2 Attributes (Examples)
readonly attribute ATMList ATMs;
readonly attribute BankList banks;
readonly attribute string symbol; readonly attribute string full_name;
Page 30
© City University London, Dept. of Computing Distributed Systems / 2 - 30
2.3 Operations
Operations modify the state of an object or just compute functions
Used for service requests Operations have a signature that consists of
» a name,
» a list of in, out, or inout parameters,
» a return value type (result) or void if none, and
» a list of exceptions that the operation can raise.
Page 31
© City University London, Dept. of Computing Distributed Systems / 2 - 31
2.3 Operations (Examples)
void accept_request(in Requester req,
in short amount)
raises(InvalidPIN,
NotEnoughMoneyInAccount);
short money_in_dispenser(in ATM dispenser)
raises(InvalidATM);
Page 32
© City University London, Dept. of Computing Distributed Systems / 2 - 32
2.4 Operation Execution Requests
A client object can request an operation execution from a server object.
Operation request is expressed by sending a message (operation name) to server object.
Conceptually, an object request is a triple consisting of an object reference, the name of an operation and a list of actual parameters.
Parameters are marshaled (packaged and transmitted, e.g., serialisation )
Client have to react to exceptions that the operation may raise.
Page 33
© City University London, Dept. of Computing Distributed Systems / 2 - 33
2.5 Exceptions Service requests may not be executed properly. Exceptions have a unique name. Exceptions may declare additional data structures. Exceptions are used to explain (and locate) the reason
of failure to the requester of the operation Operation execution failures may be
» generic (system), raised by the middleware, e.g., an unreachable server object; or
» specific, raised by the server object, when the execution of a request would violate the object’s integrity, e.g., not enough money in a bank account.
Page 34
© City University London, Dept. of Computing Distributed Systems / 2 - 34
2.5 Exceptions cont…
exception InvalidPIN;
exception InvalidATM;
exception NotEnoughMoneyInAccount {
short available;
};
Specific Failures may be explained by specific exceptionsExample
Page 35
© City University London, Dept. of Computing Distributed Systems / 2 - 35
3.5 Interfaces
In distributed systems, services are syntactically specified through interfaces that capture the names of the functions available together with types of the parameters, return values, possible exceptions, etc.
There is no legal way a process can access or manipulate the state of an object other than invoking methods made available to it through an object’s interface.
Page 36
© City University London, Dept. of Computing Distributed Systems / 2 - 36
3.5 Interfaces
Attributes, exceptions and operations are defined in interfaces.
Interfaces have an identifier, which denotes the object type associated with the interface.
Interfaces must be declared before they can be used.
Interfaces can be declared in a forward manner
Page 37
© City University London, Dept. of Computing Distributed Systems / 2 - 37
3.5 Interfaces (Example)
interface ATM; /* forward declaration! */
interface TellerCtrl {
typedef sequence<ATM> ATMList;
exception InvalidATM; exception InvalidPIN;
exception NotEnoughMoneyInAccount
{short available;};
readonly attribute ATMList ATMs;
readonly attribute BankList banks;
void accept_request(in Requester req,
in short amount)
raises(InvalidPIN,NotEnoughMoneyInAccount);
};
Page 38
© City University London, Dept. of Computing Distributed Systems / 2 - 38
3.6 Modules
A single global name space for all identifiers is unreasonable.
IDL includes Modules to restrict visibility of identifiers.
Access to identifiers from other modules by qualification with module identifier:
moduleName::identifierName
Page 39
© City University London, Dept. of Computing Distributed Systems / 2 - 39
3.6 Modules (Example)
module Bank {
interface AccountDB {};
};
module ATMNetwork {
typedef sequence<Bank::AccountDB> BankList;
exception InvalidPIN;
interface ATM;
interface TellerCtrl {...};
};
Page 40
© City University London, Dept. of Computing Distributed Systems / 2 - 40
2.6 Sub-typing/Inheritance
Object types are organised in a type hierarchy. Subtypes inherit attributes, exceptions and operations from
their supertypes. Subtypes can add more specific properties. Subtypes can redefine inherited properties. Advantages:
» Reuse
» Changes are easier to manage
» Abstraction makes designing DS elegant and easier to understand
» Enables polymorphism (an attribute or parameter can refer to instances of different types).
Page 41
© City University London, Dept. of Computing Distributed Systems / 2 - 41
3.7 Inheritance
Notation to define object type hierarchy.
Type hierarchy has to form an acyclic graph.
Type hierarchy graph has one root called (Object).
Subtypes inherit the attributes, exceptions and operations of all super-types.
Page 42
© City University London, Dept. of Computing Distributed Systems / 2 - 42
3.7 Inheritance (Examples)
interface Controllee;
interface Ctrl {
typedef sequence<Controllee> CtrleeList;
readonly attribute CtrleeList controls;
void add(in Controllee new_controllee);
void discard(in Controllee old_controllee);
};
interface ATM : Controllee {...};
interface TellerCtrl : Ctrl {...};
Page 43
© City University London, Dept. of Computing Distributed Systems / 2 - 43
3.7 Multiple Inheritance
An object type can inherit from more than one super-type. May cause name clashes if different super-types export the
same identifier. Example:
interface Set {
void add(in Element new_elem);
};
interface TellerCtrl:Set, Ctrl { ... }; Name clashes are not allowed!
Page 44
© City University London, Dept. of Computing Distributed Systems / 2 - 44
3.8 Redefinition
Behaviour of an operation as defined in a super-type may not be appropriate for a subtype.
Operation can be re-defined in the subtype. Binding messages to operations is dynamic. Operation signature must not be changed. Operations in (abstract) super-types are not
implemented.
Page 45
© City University London, Dept. of Computing Distributed Systems / 2 - 45
3.8 Redefinition (Example)
interface Ctrl {
void add(in Controllee new_controllee);
};
interface TellerCtrl : Ctrl {
void add(in ATM new_controllee);
};
TellerCtrl cannot redefine add’s interface – only its behaviour!
It cannot overload it either!
Page 46
© City University London, Dept. of Computing Distributed Systems / 2 - 46
3.9 Polymorphism
Objects can be assigned to an attribute or passed as a parameter, even though they are instances of subtypes of the attribute’s/parameter’s respective type.
Attributes, parameters and operations are polymorph.
Example:Using Polymorphism, instances of type ATM can be inserted into attribute controls that Ctrl has inherited from Ctrl.
Page 47
© City University London, Dept. of Computing Distributed Systems / 2 - 47
2.7 Problems of the Model
Interactions between components are not defined in the model.
No concept for abstract or deferred types. Model does not include primitives for the
behavioural specification of operations. Semantics of the model is only defined
informally.
Page 48
© City University London, Dept. of Computing Distributed Systems / 2 - 48
4 Other Approaches: (D)COM
(D)COM is Microsoft’s Distributed Component Object Model (http://microsoft.com/com/).
Evolved from OLE/COM. Weaker than CORBA object model since it
» does not support inheritance,
» does not have a strong type system and
» does not support exceptions.
Page 49
© City University London, Dept. of Computing Distributed Systems / 2 - 49
4. Other Approaches: Darwin
Experimental language developed at Imperial Collegehttp://www-dse.doc.ic.ac.uk/Research/Darwin
Supports dynamic configuration of distributed components.
Graphical and textual notation. Components provide and require services. Primitive for binding service requester to service
provider. Formal semantics based on Milner’s -calculus.
Page 50
© City University London, Dept. of Computing Distributed Systems / 2 - 50
5 Summary
Client-Server vs n-Tier Architecture Why do we need a component model? What are the primitives of the CORBA object
model? What is OMG/IDL? What are the strengths and weaknesses of the
CORBA approach?
Page 51
© City University London, Dept. of Computing Distributed Systems / 2 - 51
EXTRA MATERIAL
(Not to be examined)
Page 52
© City University London, Dept. of Computing Distributed Systems / 2 - 52
0.2 Further Examples:Computational Grids
Inspired by the electrical power grid’s pervasiveness, reliability and easy to use, computer scientists in the mid-90s began exploring the design and development of an analogous infrastructure called the
computational power Grid
Page 53
© City University London, Dept. of Computing Distributed Systems / 2 - 53
Vision
To build an environment that enables
» sharing, » selection,» aggregation of a wide variety of
geographically distributed resources including» supercomputers, » storage systems, data sources, and » specialised devices owned by different organisations for
solving large-scale resource intensive problems in science, engineering, and commerce (Buyya, 2002).
Page 54
© City University London, Dept. of Computing Distributed Systems / 2 - 54
0.2 Computational Grid
Motivation: Small computing resources such as PCs have the potential to provide vast computing power when connected. And yet…
Many of these resources lie idle most of the time. Millions of online-PCs are only involved in tasks like word processing or browsing the Internet. The computing resources of many organisations are often severely under-utilised, specially outside of peak business hours.
At the same time, there are many individuals and organisations that have intensive computations to perform but only have limited access to resources that are available
to execute them.
Page 55
© City University London, Dept. of Computing Distributed Systems / 2 - 55
Possible exploitation (Source: IBM)
Analyze the value of an investment portfolio in minutes rather than hours?
Unite research teams with others around the world to take advantage of the most up-to-date knowledge?
Significantly accelerate the drug discovery process? Scale your business to meet cyclical demand? Cut the design time of your products in half while reducing the
instances of defects?
Source: http://www-1.ibm.com/grid/about_grid/index.shtml
Page 56
© City University London, Dept. of Computing Distributed Systems / 2 - 56DOE X-ray grand challenge: ANL, USC/ISI, NIST, U.Chicago
tomographic reconstruction
real-timecollection
wide-areadissemination
desktop & VR clients with shared controls
Advanced Photon Source
Online Access to Scientific Instruments
archival storage
Page 57
© City University London, Dept. of Computing Distributed Systems / 2 - 57Image courtesy Harvey Newman, Caltech
Data Grids forHigh Energy Physics
Tier2 Centre ~1 TIPS
Online System
Offline Processor Farm
~20 TIPS
CERN Computer Centre
FermiLab ~4 TIPSFrance Regional Centre
Italy Regional Centre
Germany Regional Centre
InstituteInstituteInstituteInstitute ~0.25TIPS
Physicist workstations
~100 MBytes/sec
~100 MBytes/sec
~622 Mbits/sec
~1 MBytes/sec
There is a “bunch crossing” every 25 nsecs.
There are 100 “triggers” per second
Each triggered event is ~1 MByte in size
Physicists work on analysis “channels”.
Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server
Physics data cache
~PBytes/sec
~622 Mbits/sec or Air Freight (deprecated)
Tier2 Centre ~1 TIPS
Tier2 Centre ~1 TIPS
Tier2 Centre ~1 TIPS
Caltech ~1 TIPS
~622 Mbits/sec
Tier 0Tier 0
Tier 1Tier 1
Tier 2Tier 2
Tier 4Tier 4
1 TIPS is approximately 25,000
SpecInt95 equivalents
Page 58
© City University London, Dept. of Computing Distributed Systems / 2 - 58
Network for EarthquakeEngineering Simulation
NEESgrid: national infrastructure to couple earthquake engineers with experimental facilities, databases, computers, & each other
On-demand access to experiments, data streams, computing, archives, collaboration
NEESgrid: Argonne, Michigan, NCSA, UIUC, USC
Page 59
© City University London, Dept. of Computing Distributed Systems / 2 - 59
Community =» 1000s of home computer
users
» Philanthropic computing vendor (Entropia)
» Research group (Scripps)
Common goal= advance AIDS research
Home ComputersEvaluate AIDS Drugs
Page 60
© City University London, Dept. of Computing Distributed Systems / 2 - 60
Computational Grids Resourses
Global Grid Forum (http://www.gridforum.org/): community-initiated forum of 5000+ individual researchers and practitioners working on distributed computing, or "grid" technologies
GridComputing (http://www.gridcomputing.com/) myGrid (http://www.mygrid.org.uk/), an EPSRC project Platforms:
» Globus (http://www.globus.org/)» Unicore (http://www.unicore.org/)» Load Sharing Facility (http://www.platform.com/)