Transcript From Objects to Components

1
From Objects to Components
joint lecture
by
Prof. Judith Bishop, University of Pretoria, South Africa
Stephan Herrmann, TU Berlin
Pretoria
2
Distributed Objects
Need a connection between processes
 e.g. sockets
Need memory independent object identifiers
 e.g. #1, #2, #3
Need remote method calls
 send (“#4 print_yourself”)
Need to encode parameters (and return value..)
Need to receive return value
 result = read ()
Implement all this for every single method call??
3
Encapsulate Communication
class AccountImpl
implements Account
extends RemoteObject {
private String id;
public int deposit(int amount) {
String amount_str = encode_int(amount);
send(id + “ deposit ” + amount_str);
String new_balance = readString();
return decode_int(new_balance);
}
public int get_balance () { ... }
}
Account a = new AccountImpl(“#15”);
int nb = a.deposit(1000000);
4
Proxy Pattern
Client
Account
AccountImpl
RemoteObject
AccountProxy
Client does not see difference between `real impl´ and proxy
Superclass RemoteObject provides basic functions for
 socket handling
 value conversion
(includes creation of proxies for referenced objects)
Handcode proxies??
What about the receiving side??
 decode messages
 assign object IDs
5
Java Remote Interface Example
Package name
6
Interface name
Declare it as remote
package soccer;
interface Team extends Remote {
public:
String name() throws RemoteException;
Trainer[] coached_by() throws RemoteException;
Club belongs_to() throws RemoteException;
Players[] players() throws RemoteException;
void bookGoalies(Date d) throws RemoteException;
void print() throws RemoteException;
};
Remote operations
Wolfgang Emmerich 2000©
7
Architecture
Client
Stub
Server
Registry
Interfaces
Skeleton
Activation
Interfaces
RMI Runtime (rmid,rmiregistry)
Wolfgang Emmerich 2000©
8
Activation in Java
Java VM1
Stub
Faulting
Reference
2: create object
in VM
Live Activaref tion ID
Java VM2
3: pass
object ref
AG1
AG2
Activator
1: activate
4: update
live ref
Client Host
Activation Descriptors:
ActGroup ClassName URL
Init
AG1
Team
www.bvb.de/…
AG2
Player
www.bvb.de/…
AG2
Player
www.bvb.de/…
AG2
Player
www.bvb.de/…
Host www.bvb.de
Wolfgang Emmerich 2000©
Java Interfaces and Remote
Objects






9
Java already includes the concept of interfaces
RMI does not have a separate interface definition language
Pre-defined interface Remote
Remote interfaces extend Remote
Remote classes implement remote interfaces
Remote objects are instances of remote classes
Wolfgang Emmerich 2000©
10
Goals of RMI
 In Java 1.0 object communication confined to objects in one
Virtual Machine
 Remote Method Invocation (RMI) supports communication
between different VMs, potentially across the network
 Provide tight integration with Java
 Minimize changes to Java language/VM
 Work in homogeneous environment
Wolfgang Emmerich 2000©
Programming Languages
 RMI is fine for Java, but
 What if I want to implement my objects
in different programming languages?
11
12
OMG Interface Definition Language
 Language for expressing all concepts of the CORBA object
model
 OMG/IDL is
programming-language independent
orientated towards C++
not computationally complete
 Different programming language bindings are available
 Explanation of Model and Language by Example
Wolfgang Emmerich 2000©
Object Model and Interface
Definition








13
Objects
Types
Modules
Attributes
Operations
Requests
Exceptions
Subtypes
Wolfgang Emmerich 2000©
CORBA Object Model: Objects




14
Each object has one identifier that is unique within an ORB
Multiple references to objects
References support location transparency
Object references are persistent
Wolfgang Emmerich 2000©
CORBA Object Model: Subtypes
15
Implicit supertype:
Object
Inherited by Club
interface Organization {
readonly attribute string name;
Supertype
};
interface Club : Organization {
exception NotInClub{};
readonly attribute short noOfMembers;
readonly attribute Address location;
attribute TeamList teams;
attribute TrainerList trainers;
void transfer(in Player p) raises NotInClub;
};
Wolfgang Emmerich 2000©
16
Architecture
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
One standardised interface
One interface per object operation
One interface per object adapter
ORB-dependent interface
Wolfgang Emmerich 2000©
17
Goal of CORBA
 Support distributed and heterogeneous object request in a
way transparent to users and application programmers
 Facilitate the integration of new components with legacy
components
 Open standard that can be used free of charge
 Based on wide industry consensus
Wolfgang Emmerich 2000©
18
Key Points
 CORBA, RMI and other middleware (like COM)
– enable objects to request operation execution from
server objects on remote hosts
– identify server objects by object references
– distinguish between interface and implementation
– treat attributes as operations
– provide mechanisms to deal with failures
– have statically typed object models
– compile stubs from their IDLs
– support on-demand activation
Wolfgang Emmerich 2000©
Wait?
 This int deposit(int) method was silly.
 Why should I wait for a result??
19
Request Synchronization
20
OO-Middleware: synchronous requests.
:Client
Op()
:Server
 Synchronous requests might block clients unnecessarily.
Examples:
User Interface Components
Concurrent Requests from different servers
Wolfgang Emmerich 2000©
21
Oneway Requests
 Return control to client as soon as request has been taken
by middleware
 Client and server are not synchronized
 Use if
Server does not produce a result
Failures of operation can be ignored by client
:Client
:Server
oneway()
Wolfgang Emmerich 2000©
Oneway using Java Threads
22
class PrintSquad {
static void main(String[] args) {
Team team;
Date date;
// initializations of team and date omitted ...
OnewayReqPrintSquad a=new OnewayReqPrintSquad(team,date);
a.start();
// continue to do work while request thread is blocked...
}
}
// thread that invokes remote method
class OnewayReqPrintSquad extends Thread {
Team team;
Date date;
OnewayReqPrintSquad(Team t, Date d) {
team=t; date=d;
}
public void run() {
team.print(date); // call remote method and then die
}
}
Wolfgang Emmerich 2000©
Oneway requests in CORBA
23
 Declared statically in the interface definition of the server
object
 IDL compiler validates that
operation has a void return type
does not have any out or inout parameters
does not raise type specific exceptions
 Example:
interface Team {
oneway void mail_timetable(in string tt);
};
Wolfgang Emmerich 2000©
Oneway requests in CORBA
24
 If oneway declarations cannot be used: Use dynamic
invocation interface
:Client
:Server
r=create_request()
r:Request
send()
Op()
delete()
Wolfgang Emmerich 2000©
Deferred Synchronous Requests
25
 Return control to client as soon as request has been taken
by middleware
 Client initiates synchronization
 Use if
Requests take long time
Client should not be blocked
Clients can bear overhead of synchronization
:Client
send()
:Request
op()
:Server
get_result()
Wolfgang Emmerich 2000©
26
Deferred Synchronous Requests with Threads
class PrintSquad {
public void print(Team t, Date d) {
DefSyncReqPrintSquad a=new DefSyncReqPrintSquad(t,d);
// do something else here.
a.join(this); // wait for request thread to die.
System.out.println(a.getResult()); //get result and print
}
}
// thread that invokes remote method
class DefSyncReqPrintSquad extends Thread {
String s;
Team team;
Date date;
DefSyncReqPrintSquad(Team t, Date d) {team=t; date=d;}
public String getResult() {return s;}
public void run() {
String s;
s=team.asString(date);// call remote method and die
}
}
Wolfgang Emmerich 2000©
CORBA Deferred Synchronous Requests27
 Determined at run-time with using DII
 By invoking send() from a Request object
 And using get_response() to obtain result
:Client
r=create_request(“op”)
send()
:Server
r:Request
op()
get_response()
Wolfgang Emmerich 2000©
Asynchronous Requests
28
 Return control to client as soon as request has been taken
by middleware
 Server initiates synchronization
 Use if
Requests take long time
Client should not be blocked
Server can bear overhead of synchronization
:Client
op()
:Server
Wolfgang Emmerich 2000©
Asynchronous Requests with Threads29






Client has interface for callback
Perform request in a newly created thread
Client continues in main thread
New thread is blocked
Requested operation invokes callback to pass result
New thread dies when request is complete
Wolfgang Emmerich 2000©
Asynchronous Requests with Threads30
interface Callback {
public void result(String s);
}
class PrintSquad implements Callback {
public void Print(Team team, Date date){
A=new AsyncReqPrintSquad(team,date,this);
A.start(); // and then do something else
}
public void result(String s){
System.out.print(s);
}
}
class AsyncReqPrintSquad extends Thread {
Team team; Date date; Callback call;
AsyncReqPrintSquad(Team t, Date d, Callback c)
{
team=t;date=d;call=c;
}
public void run() {
String s=team.AsString(date);
call.result(s);
}
}
Wolfgang Emmerich 2000©
Asynchronous Requests using Message Queues
31
 Messaging is starting to be provided by object-oriented
middleware
Microsoft Message Queue
CORBA Notification Service
Java Messaging Service
 Request and reply explicitly as messages
 Using two message queues
 Asynchronous requests can be achieved
Wolfgang Emmerich 2000©
Asynchronous Requests using Message Queues
enter
32
remove
Request Queue
Client
Server
remove
enter
Reply Queue
Wolfgang Emmerich 2000©
Difference between Thread and
MQs
Threads
 Communication is immediate
 Do not achieve guaranteed
delivery of request
 Can be achieved using
language/OS primitives
33
Message Queues
 Buffer Request and Reply
messages
 Persistent storage may
achieve guaranteed delivery
 Imply additional licensing
costs for Messaging
Wolfgang Emmerich 2000©
Request Multiplicity
34
 OO Middleware: unicast requests
Two components: client and server
One operation execution
Non-anonymous
 Other forms: multicast requests
More than two components (group requests)
More than one operation (multiple requests)
Wolfgang Emmerich 2000©
Group Requests
35
 Example: Stock Exchange Ticker
:Trader
:Channel
:Ticker
:Ticker :Ticker
connect()
connect()
push()
push()
push()
push()
disconnect()
connect()
push()
push()
Wolfgang Emmerich 2000©
Group Communication Principles
36
 Group communication informs a group of components about a
particular event.
 Two roles:
Event producer
Event consumer
 Producers and consumers do not know each other.
 Two forms of request:
push-type: producer initiates communication
pull-type: consumer initiates communication
Wolfgang Emmerich 2000©
Some Architecture
 Can’t we use some style of Model-View-Control
for distributed applications?
client
business logic
client
view&control
e.g. as applet
connected via http
pure model
e.g. as servlet
within a web server
... and we need a DB for
persistency
 Wow, just invented a 3-tier-architecture!
37
EJB Roles and Deployment
38
Developer Roles
EJB Technology divides naturally into five developer roles:





server provider,
container provider,
Enterprise Beans (component!!) provider,
application assemblers, and
deployers.
39
Enterprise JavaBeans Components














Application Servers (42)
Authoring Tools (5)
Charts&Graphs (4)
Database Connectivity (21)
Database Servers (6)
Development Tools (47)
EJB Components (34)
EJB-based Applications (49)
Electronic Commerce (38)
Electronic Publishing (5)
Entertainment (1)
Financial Services (20)
Legacy Support (10)
Manufacturing (4)
 Multimedia (3)
 Network Administration (1)
 Object Transaction Monitors
(1)
 Productivity/Groupware (18)
 Report Generation (5)
 Retail (6)
 System Administration (4)
 Telecommunications (15)
 Transaction Servers (5)
 UI Elements (1)
 Utilities&Services (13)
 Web Servers (9)
 Workflow (6)
40
What is a component?
"Reusable software components are self contained, clearly
identifiable pieces that describe and/or perform specific
functions, have clear interfaces, appropriate documentation
and a defined reuse status".
41
Cross platform
 An Enterprise Bean executes in a container
 An EJB can be taken from one environment to another
without recoding.
 Communication via RMI as default
 EJBs can also be accessed via Corba-IIOP
 Corba details are hidden from the EJB developer
42
Writing an EJB
 The bean provider adheres to two contracts:
– the client’s view, and
– the component’s view as seen from the container.
 The bean provider therefore produces:
– EJB remote interface class file
– EJB home interface class file
– EJB class file
 An EJB can be developed provide the EJB and JNDI classes
are installed.
 JNDI stands for Java Naming Directory Interface
43
Naming and Trading
 Know the instance?
Object ID
(exact reference)
 Know the provider (who)? Naming
(white pages)
 Know the service (what)? Trading
(yellow pages)
based on the declaration of properties like:
fee, bandwidth, availability ...
“Quality of Service” (QoS)
 When talking about components, attention to
don’t only say “functionality” but pay for properties like
persistence
performance
security
availability
portability
...
 Some of these are implemented e.g. as CORBA services
44
Provide, deploy and use
 Provide
– the remote interface for all the visible business
methods of the bean
– the home interface to install instances of a bean on a
client
– the bean class with the implementation of the business
methods
 EJB provider tool will set up a descriptor and details of EJB
deployment to a runtime container.
 Package it all up in an ejb-jar file
 Set up RMI in client to use the new service
45
Packaging
46
A Component can be more than just compiled binary code:
 Help files
 Images

 Prototypes (Design Pattern Prototype)
 use cloning for creation
(cf. prototype based languages) 
 provide pre-configured values.
 Localisation
 etc.
todays lesson:
 Dispite differences of
size
function
services
style
 ... component development through all phases is the future.
47
References
 Wolfgang Emmerich: „Engineering Distributed Objects“
Wileys, 2001
www.distributed-objects.com
 www.javasoft.com
 Clemens Szyperski: „Component Software - Beyond ObjectOriented Programming“
Addison Wesley, 1998
 See also
http://www.cms.dmu.ac.uk/
nmsampat/research/subject/reuse/components/index.htm
48