MPWide: A light-weight communication library for wide area message passing and code coupling
Interprocess Communication - Philadelphia University · – Inter process communication (IPC)...
Transcript of Interprocess Communication - Philadelphia University · – Inter process communication (IPC)...
4 - 1 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
1. Foundations and Architecture
distributed system architechtures; network interface
2. Time and Global States
clocks and concepts of time; event ordering; synchronization; global states
3. Coordination
distributed mutual exclusion; multicast; group communication, byzantineproblems (consensus)
4. Inter Process Communication and Middleware
inter process communication; middleware; distributed object models; remote invocation; CORBA; .net; name and directory services
5. Security
cryptographic algorithms; signatures and certificates; authentication
6. Advanced Topics
fault-tolerance; specification and verification
4 - 2 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Distributed Systems
8 rely on exchanging data and achieving synchronization amongst autonomous distributed processes
– Inter process communication (IPC)
ishared variables
imessage passing
– message passing in concurrent programming languages
ilanguage extensions
iAPI calls
♦ Principles of IPC
(see also [Andrews and Schneider 83] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March 1983)
8Concurrent programs: collections of two or more sequential programsexecuting concurrently
8Concurrent processes: collection of two or more sequential programsin operation, executing concurrently
4 - 3 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Synchronization8concurrent processes on different computers execute at different
speeds8need for one process to influence computation in another process
– specify constraints on the ordering of events in concurrent processes
– message passingisend message happens before receive message
♦ Message Passing Primitives8send expression_list to destination_designator
– evaluates expression_list– adds a new message instance to channel destination_designator
8receive variable_list from source_designator– assignes received values to variables in variable_list– destroys received message
♦ Central questions8how are destination designators specified?8how is communication synchronized?
4 - 4 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Destination Designation
8direct naming: source and destination process names serve as designators (a pair of source and destination designators defines a channel)
send cur_status to monitor ormonitor!cur_status
receive message from handler orhandler?message
– easy to implement and use
– allows a process easy control when to receive which messagefrom which other process
– used to implement client/server applications
iwell suited to implement client/server paradigm if there is one client and one server
iotherwise: server should be capable of accepting invocations from any client at any time, and a client should be allowed to invoke many services at a time if more than one server available
4 - 5 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Destination Designation8global names or mailboxes: process name-independent destination
designator shared by many processes– messages sent to a mailbox can be received by any process that
executes a receive referring to that mailbox name– to implement Client/Server applicationsiclients send requests to mailbox, an available server picks
them up – drawback: costly implementationimessage sent to mailboxirelayed to all other sites that could potentially receive from
that mailboxiif one site decides to receive, inform all other sites that
message is no longer available for receiptimutual exclusion for concurrent access
4 - 6 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Destination Designation8ports: mailbox, but only one process is permitted to receive from that
mailbox– easy to implement: receives can occur in only one process, no
distribution and coordination necessary– suitable for multiple clients / single server applications
8Message destinations in Internet programming– hybrid direct naming/port scheme
(Internet_address, port_number)
– port corresponds to many sender/one receiver concept
4 - 7 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Channel Naming
8static (at compile time)
– impossible for a program to communicate along a channel not known at compile time
– inflexibility: if a process might ever need to communicate with a recipient, that channel must be available throughout the entire runtime of the sending programme
8dynamic (at runtime)
– administrative overhead at runtime
– more flexible allocation of communication resources
4 - 8 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Semantics of message passing primitives8Blocking
– non-blocking: the execution will never delay the invoking process – blocking: otherwise
8Synchronization– asynchronous message passing: message passing using buffers
with unbounded capacityisender may race ahead an unbounded number of stepsisender never blocksireceiver blocks on empty queue
– synchronous message passing: no buffering between sender and receiverisender blocks until receiver ready to receiveireceiver blocks until sender ready to send
– buffered message passing: buffers with bounded, finite capacityisender may race ahead a finite, bounded number of stepsisender blocks on full bufferireceiver blocks on empty buffer
4 - 9 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Non-blocking primitives for asynchronous or buffered message
passing
8 receive
– background variant: process continues, receives interrupt upon arrival
ioverhead for implementation
– ignoring variant: programme polls for availability
8send
– sending process waits for empty buffer or drops message to be sent
4 - 10 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication
♦ Distributed Applications
8availability of a set of pre-implemented application services, like email, ftp, http, etc.
8what if you want to build your own, customized Internet application?
8access to Transport Layer services
♦ Services provided by Internet Transport Layer
8UDP: message passing (datagram)
8TCP: data stream
L7 Application
L6 Presentation
L5 Session
L4 Transport
L3 Network
L2 Data Link Control
L1 Physical
smtpftp
telnethttp
TCP
IPLAN
(M)WANproprietary netwoks
OSI-BRM Internet
© Pearson Education 2001
4 - 11 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication
♦ Sockets8 Internet IPC mechanism of Unix and other operating systems (BSD
Unix, Solaris, Linux, Windows NT, Macintosh OS)8processes in these OS can send and receive messages via a socket8sockets are duplex8sockets need to be bound to a port number and an internet address
in order to be useable for sending and receiving messages8each socket has a transport protocol attribute (TCP or UDP)8messages sent to some internet address and port number can only
be received by a process using a socket that is bound to this address and port number
8UDP socket can be connected to a remote IP address and port number
8processes cannot share ports (exception: TCP multicast)
© Pearson Education 2001
4 - 12 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ IPC based on UDP datagrams8UDP datagram properties: no guarantee of order preservation,
message loss and duplications are possible8necessary steps
– create socket– bind socket to a port and local Internet addressiclient: arbitrary free portiserver: server port
8 receive method: returns Internet address and port of sender, plus message
8message size: IP allows for messages of up to 216 bytes– most implementations restrict this to around 8 kbytes– larger application messages: application’s responsibility to
perform fragmentation/reassembling– if arriving message is too big for array allocated to receive
message content, truncation occurs
4 - 13 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ IPC based on UDP datagrams8send: non-blocking
– blocks only until message given to UDP/IP– upon arrival placed in per-port queue
8 receive: blocking– pre-emption by timeout possible– if process wishes to continue while waiting for packet, use
separate thread
4 - 14 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Java API for UDP datagrams8Classes
– DatagramPacket constructor generating message for sending from array of bytesimessage content (byte array)ilength of messageiInternet address and port number (destination)
– similar constructor for receiving a message– DatagramSocket class for sending and receiving of UDP
datagramsione constructor with port number as argument, another
withoutino-argument constructor to use free local portimethods
* send and receive* setSoTimeout
* connect for connecting a socket to a particular remote Internet address and port
4 - 15 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Java API for UDP datagrams8Example
– process creates socket, sends message to server at port 6789, and waits to receive reply
import java.net.*;import java.io.*;public class UDPClient{
public static void main(String args[]){ // args give message contents and destination hostnametry {
DatagramSocket aSocket = new DatagramSocket(); // create socketbyte [] m = args[0].getBytes();InetAddress aHost = InetAddress.getByName(args[1]); // DNS lookupint serverPort = 6789;DatagramPacket request =
new DatagramPacket(m, args[0].length(), aHost, serverPort);aSocket.send(request); //send nessagebyte[] buffer = new byte[1000];DatagramPacket reply = new DatagramPacket(buffer, buffer.length);aSocket.receive(reply); //wait for replySystem.out.println("Reply: " + new String(reply.getData()));aSocket.close();
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());}catch (IOException e){System.out.println("IO: " + e.getMessage());}} // can be caused by send
}
4 - 16 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ IPC based on TCP streams
8abstract service: stream of bytes to be written to or received from
8 features
– message size: no constraint, TCP decides when to send a transport layer message consisting of multiple application messages, immediate transmission can be forced
– connection oriented
– retransmission to recover from message lost (timeout-bounded)
– queue at destination socket
– blocked on receive
– flow control to block sender when overflow might occur
– need to agree on data sent and received
– server generates new thread for new connection
4 - 17 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ API for streams
8connection establishment using client/server approach, afterwards peer communication
– client: issue connect requests
– server: has listening port to receive connect request messages
– accept of a connection: create new stream socket for new connection
♦ Java API for TCP streams
8Classes
– ServerSocket class: create socket at server side to listen for connect requests
– Socket class: for processes with connections
iconstructor to create a socket and connect it to remote host and port of a server
imethods for accessing input and output stream
4 - 18 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Example
8TCP-based server for stream communication
import java.net.*;import java.io.*;public class TCPServer {
public static void main (String args[]) {try{
int serverPort = 7896; // the server portServerSocket listenSocket = new ServerSocket(serverPort);
// new server port generatedwhile(true) {
Socket clientSocket = listenSocket.accept();// listen for new connection
Connection c = new Connection(clientSocket);// launch new thread
}} catch(IOException e) {System.out.println("Listen socket:"+e.getMessage());}}
}
4 - 19 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Example
8TCP-based server for stream communicationclass Connection extends Thread {
DataInputStream in;DataOutputStream out;Socket clientSocket;public Connection (Socket aClientSocket) {
try {clientSocket = aClientSocket;in = new DataInputStream( clientSocket.getInputStream());out =new DataOutputStream( clientSocket.getOutputStream());this.start();
} catch(IOException e){System.out.println("Connection:"+e.getMessage());}}public void run(){
try { // an echo serverString data = in.readUTF();
// read a line of data from the streamout.writeUTF(data);
// write a line to the streamclientSocket.close();
} catch (EOFException e){System.out.println("EOF:"+e.getMessage());} catch (IOException e) {System.out.println("readline:"+e.getMessage());}
}}
4 - 20 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Data Representation8data representation problem
– use agreed external representation, two conversions necessary– use sender’s or receiver’s format and convert at the other end
8 transmission of structured data types– data types may not change during transmission– usage of a commonly understood “flattened” transfer format
(structured types are reduced to their primitive components)8data representation formats
– SUN Microsystems XDR– CORBA CDR– ASN.1 (OSI layer 6)
8marshalling/unmarshalling– marshalling: assembling a collection of data items in a form
suitable for transmission– unmarshalling: disassembling and recovery of original data items– usually performed automatically by middleware layerihand-programming error-proneiuse of compilers for programs working directly at transport
API
4 - 21 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ CORBA Common Data Represenation (CDR)
8CORBA: Common Object Request Broker Architecture
– middleware architecture standardized by the Object Management Group
– see www.omg.org
8CORBA CDR
– supports types allowed in CORBA remote object invocations
– primitive types
ilittle/big endian according to sender’s representation format
iprimitive values start at indexed byte positions (multiples of 1, 2, 4 or 8)
ifloating point according to IEEE standard
icharacters using an agreed character set
4 - 22 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ CORBA Common Data Represenation (CDR)8structured types
– definitions
– example: struct with value {‘Smith’, ‘London’, 1934}© Pearson Education 2001
© Pearson Education 2001
4 - 23 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ CORBA Common Data Represenation (CDR)
8CORBA marshalling/unmarshalling
– CORBA Interface Definition Language (IDL)
– IDL compilers will generate marshalling and unmarshallingoperations (“stubs”) that transforms data objects into CDR format
4 - 24 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Remote Object References8needed when a client invokes an object that is located on a remote
server8 reference needed that is unique over space and time
– space: where is the object located– time: correct version of an undeleted object
8a generic format proposal
– internet address/port number: process which created object– time: creation time– object number: local counter, incremented each time an object is
created in the creating process– interface: how to access the remote object (if object reference is
passed from one client to another)8extension: object references that are location transparent
© Pearson Education 2001
4 - 25 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication8often built over UDP datagrams
– client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary
– avoidance of connection establishment overhead– no need for flow control due to small amounts of data tranfered
8generic protocol example (for RPC or RMI communication):
© Pearson Education 2001
4 - 26 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication
8 format of protocol messages
– message type (request/reply)
– request ID
isending process identifier (e.g., IP address/port number)
iinteger sequence number incremented by sender with every request
– object reference
– method ID and arguments
4 - 27 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication
8 if implemented over UDP: failure recovery
– omission failures
iuse timeout and resend request when timeout expires and reply hasn’t arrived
iserver receives repeated request
* idempotent operations: same result obtained on every invocation
* non-idempotent operations: re-send result stored from previous request, requires maintenance of a history of replies
iloss of replies: request - reply - ack reply protocol
– message duplication: return request ID with reply
4 - 28 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication8example: Hypertext Transfer Protocol (HTTP)
– lightweight request - reply protocol for the exchange of network resources between web clients and web servers
– protocol stepsiconnection establishment between client and server (likely
TCP, but any reliable transport protocol is acceptable)iclient sends requestiserver sends replyiconnection closure
– inefficient scheme, therefore HTTP 1.1 allows “persistent transport connections” (remains open for successive request/reply pairs)
– Resources can have mime-type data types, e.g.itext/plainitext/htmliimage/jpeg
– data is marshalled into ASCII transfer syntax
4 - 29 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication
8example: Hypertext Transfer Protocol (HTTP)
– request
iGET: request of resource, identified by URL, may refer to
* data: server returns data
* program: server runs program and returns output data
iHEAD: request similar like GET, but only meta data on resource is returned (like date of last modification)
iPOST: specifies resource (for instance, a server program) that can deal with the client data provided with previous request
iPUT: supplied data to be stored in given URL
iDELETE: delete an identified resource on server
© Pearson Education 2001
4 - 30 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Interprocess Communication♦ Client-Server Communication
8example: Hypertext Transfer Protocol (HTTP)
– reply
© Pearson Education 2001
4 - 31 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Middleware
♦ Functionality in Middleware (Upper Sublayer)
8Remote Procedure Call (RPC)
– client calls a procedure implemented and executing on a remote computer
– call as if it was a local procedure
8Remote Method Invocation (RMI)
– local object invoking methods of an object residing on a remote computer
– invocation as if it was a local method call
8Event-based Distributed Programming
– objects receive asynchronous notifications of events happening on remote computers/processes
Applications
MiddlewarelayersRequest reply protocol
External data representation
Operating System
RMI, RPC and events
© Addison-Wesley Publishers 2000
4 - 32 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Middleware
♦ Transparency Features of Middleware (Upper Sublayer)
8 location transparency:
– RMI and RPCs invoked without knowledge of the location of invoked method/procedure
8 transport protocol transparency:
– e.g., request/reply protocol used to implement RPC can use either transport protocol
8 transparency of computer hardware and operating system
– e.g., use of external data representations
8 transparency of programming language used
– e.g., by use of programming language independent Interface Definition Languages, such as CORBA IDL
Applications
MiddlewarelayersRequest reply protocol
External data representation
Operating System
RMI, RPC and events
© Addison-Wesley Publishers 2000
4 - 33 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Middleware♦ Interfaces for RMI and RPC
8 interface defined for each module/object
8provides signatures for a set of methods
8hides all implementation details
8accesses can only occur through methods specified in interface
8specifics for interfaces in distributed systems
– no direct access to remote variables possible
iuse message passing mechanism to transmit data objects and variables
* request-reply protocols
– local parameter passing mechanisms (by value, by reference) not applicable to remote invocations
ispecify input, output as attribute to parameters
* input: transmitted with request message
* output: transmitted with reply message
– pointers are not valid in remote address spaces
icannot be passed as argument along interface
4 - 34 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Middleware♦ Interfaces for RMI and RPC
8RPC and RMI interfaces are often seen as a client/server system
– service interface (in client server model)
ispecification of procedures and methods offered by a server
– remote interface (in RMI model)
ispecification of methods of an object that can be invoked by objects in other processes
4 - 35 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Middleware♦ Interfaces for RMI and RPC8 Interface Definition Languages
– impossible to specify direct access to variables in remote classes– hence, access only through specified interface– desirable to have language-independent IDL that compiles into
access methods in application programming language– example: CORBA IDL
// In file Person.idlstruct Person {
string name; string place;long year;
} ;interface PersonList {
readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);long number();
};© Addison-Wesley Publishers 2000
4 - 36 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Distributed Objects♦ Components of an object model
8object references
– refer to objects of a class
– can be assigned, queried
8 interfaces
8actions
– initiated by an object invoking a method in another object
– possible effects
istate of method invocation receiver may change
ican cause further method invocation
8exceptions
– system as well as programmer-defined reactions on unexpected or error situations
8garbage collection
– disposal of resources (memory) that are occupied by objects thatare no longer referenced and will not be needed any more in the future
4 - 37 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Distributed Objects♦ Distributed Object Model
8adoption of client-server model
– servers maintain objects and allow remote objects to access the methods of those objects that are specified for remote use in the interface definition
– clients invoke the methods offered by servers using remote method invocation (RMI)
8RMI implemented using a request/reply protocol
– request carries remote method reference and remote object’s in parameters to server
– reply returns out parameters (results of RMI) to client
invocation invocationremote
invocationremote
locallocal
localinvocation
invocationA B
C
D
E
F
request
reply
© Addison-Wesley Publishers 2000
4 - 38 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Remote Object
8object capable of receiving RMIs (in example at least B and F)
♦ Remote Object Reference
8needed by an object performing a RMI
8 refers to server of RMI
8 typical format
8can be passed as parameter or result
invocation invocationremote
invocationremote
local
local
local
invocation
invocation
A B
C
D
E
F
© Addison-Wesley Publishers 2000
© Addison-Wesley Publishers 2000
4 - 39 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Remote Interface
8specifies which methods can be invoked remotely
interface
remote
m1m2m3
m4m5m6
Data
implementation
remote object
{ of methods
© Addison-Wesley Publishers 2000
4 - 40 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation♦ Actions8caused by method invocations8 if boundary of one process or computer is crossed through
invocation, then RMI will be used to cause the action♦ Garbage Collection8garbage collection for remote objects8determine whether there are remaining references to an object in the
system♦ Exceptions8 recovery from error situations as in non-distributed case8specific problems due to distributed environment
– server may have crashed– server may be too busy to reply within reasonable time bounds
8specific exceptions– timeouts – specific exceptions due to underlying distributed infrastructure
8CORBA IDL– application level exceptions– system generates distribution-specific exceptions
4 - 41 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation♦ RMI usually implemented via request/reply protocol
8 if implemented over UDP, then the following failures may occur
– message omission
– messages not delivered in send order
– message duplication
8additionally, process failures are possible (crash or arbitrary)
8consequence: cannot be guaranteed, that remote operations are executed exactly once (as it can be guaranteed for local operations)
© Addison-Wesley Publishers 2000
4 - 42 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Invocation Semantics
8choices in the implementation
– retransmit request message until reply or server presumed failed
– filtering of duplicates at server if retransmit is used
– when retransmitted request arrives:
iresult retransmission if retransmitted request arrives (requires keeping of history at server) or
irepeated execution of procedure
8 leads to different invocation semantics
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-once
At-least-once
Maybe
© Addison-Wesley Publishers 2000
4 - 43 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Invocation Semantics
8maybe
– invoker knows nothing about whether operation is executed
iany type of communication or process failure may have happened
– no fault tolerance mechanisms used
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-once
At-least-once
Maybe
© Addison-Wesley Publishers 2000
4 - 44 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Invocation Semantics8at-least-once
– invoker receivesiresult, oriexception, if no result was received
– if result was received, invoker knows that operation was executed at least once, but knows nothing if exception occurs
– achieved through retransmissions of requests and re-executions – remaining failure modesicrash failure of server (when no fairness for this component)iarbitrary failures caused through re-execution of non-
indempotent operation on server
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-onceAt-least-once
Maybe
© Addison-Wesley Publishers 2000
4 - 45 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Invocation Semantics8at-most-once
– invoker receives iresult, in which case s/he knows that operation was executed
exactly once, oriexception informing that no result was received, in which
case the operation was performed either once, or not at all– requires usage of all fault tolerance measures
8examples– Java RMI and CORBA use at-most-once– CORBA allows maybe semantics for RMIs that do not return
results
Fault tolerance measures Invocation semantics
Retransmit request message
Duplicate filtering
Re-execute procedure or retransmit reply
No
Yes
Yes
Not applicable
No
Yes
Not applicable
Re-execute procedure
Retransmit reply At-most-onceAt-least-once
Maybe
© Addison-Wesley Publishers 2000
4 - 46 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Implementation of RMI
8communication module
– request/reply messages
– uses message type, requestID and remote object reference
– in server
iselect dispatcher for the class of the object to be invoked
iobtains local reference from remote reference module by providing remote object identifier delivered with request message
ipasses on the local reference to scheduler
object A object BskeletonRequest
proxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
© Addison-Wesley Publishers 2000
4 - 47 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Implementation of RMI
8 remote reference module
– translation between local and remote object references using remote object tableicontains entries for all remote objects maintained by the
server
iand for all proxies (explained later)
– used when marshalling and unmarshalling remote object references
object A object BskeletonRequest
proxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
© Addison-Wesley Publishers 2000
4 - 48 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Implementation of RMI8 the RMI sublayer of the middleware architecture consists of
– proxies (in client): local placeholders for remote objects– dispatcher (in server): receives request and uses methodID to
select appropriate message in skeleton– skeleton (in server): implements methods in the remote interfaceiunmarshaling argumentsiinvokes corresponding method in remote objectiwaits for completion of invocationimarshals results, possibly exceptions, and returns them in a
reply to invoking method of proxy
object A object BskeletonRequest
proxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
© Addison-Wesley Publishers 2000
4 - 49 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation
♦ Implementation of RMI
8 implementation of RMI layer (proxies, skeletons and dispatchers)
– in some systems they can be automatically compiled, e.g.
iOrbix CORBA, uses IDL descriptions of remote interfaces to compile RMI layer, generates C++ code
iJava RMI
* proxy, skeleton and dispatcher classes are generated from the class of the remote object
object A object BskeletonRequest
proxy for B
Reply
CommunicationRemote Remote referenceCommunicationmodulemodulereference module module
for B’s class& dispatcher
remoteclient server
© Addison-Wesley Publishers 2000
4 - 50 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation♦ Some more RMI components
8 factory methods
– remote object interfaces cannot include constructors
– factory methods replace constructors to create remote objects
8binders
– service maintaining mappings from textual object names to remote object references
8 threads in server
– every remote method invocation is usually given an own thread toexecute
iadvantages, if RMI invokes other local or remote methods that cause wait times
4 - 51 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation♦ Distributed Garbage Collection
8 free resources occupied by objects that have no more reference to it in the system
8Java Distributed Garbage Collection algorithm:
– each server maintains a list of processes that hold remote object references for each of its remote objects
– when client receives a remote reference to particular remote object X, issuing a addRef(X) to the server, server adds X to the list
– when client’s garbage collector notices that a proxy for a remote object X is no longer referenced, it sends removeRef(X) to server, which deletes X from list
– when list is empty, and there are no local references to X, collect resources held by X through server’s local garbage collector
4 - 52 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Remote Method Invocation♦ Distributed Garbage Collection
8 fault tolerance of Java Distributed Garbage Collection
– supported by request/reply protocol with at-most-once semantics
– toleration of communication failures
iaddRef and removeRef are indempotent
iif addRef(X) returns exception, then client will not instantiate proxy but will send removeRef(X)
ieffect of removeRef(X) is correct no matter whether addRef(X) succeeded or not
ifailure of removeRef(X) is masked by the use of leases
– leases
iservers lease their objects to clients for limited periods of time, starting with addRef
ihelps tolerate failures of removeRef as well as client failures
iavoids problem of having to maintain lists of remote object references if all object references are handled through leases
4 - 53 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
SUN Remote Procedure Call
♦ SUN RPC
8developed by SUN Microsystems to support client-server communication for use in SUN’s NFS
8very similar in concept to RMI
8any of the delivery semantics of RMI can be implemented
8only addresses procedure calls
– no object references
8client stub procedure corresponds to proxy
8server stub procedure similar to skeleton
client
Request
Reply
CommunicationCommunicationmodulemodule dispatcher
service
client stub server stubprocedure procedure
client process server process
procedureprogram
© Addison-Wesley Publishers 2000
4 - 54 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Event Based Distributed Programming♦ Event Based Distributed Programming
8event typically caused by method invocation or message delivery
8event changes state of object
8multiple objects at different locations are informed of the occurrence of an event at a particular object, for example:
– in a spontaneous computing environment, that a person’s PDA has entered a hotel room
– a client has entered participation in a collaborative work environment
– an electronic document has been modified
4 - 55 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Event Based Distributed Programming♦ Event Based Distributed Programming
8publish-subscribe paradigm
– object generating events publishes list of events for which other objects can receive notifications
– object requiring notifications subscribes to the notification service at an object offering notification for this particular event through its publication list
8characteristics of event based systems
– heterogeneity of hard- and software
– asynchronicityisynchronous notification would be highly inefficient at client
as well as at server endiclient-polling also rather inefficient
4 - 56 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Event Based Distributed Programming
♦ Architecture8event service
– maintains database of published events and registered subscriptions
– event service is notified of events at objects of interest– subscribers subscribe for notifications at event service– after occurrence of event, notification is sent to all subscribers
8delivery semantics is implementation dependent– e.g., notifications by IP multicast do not guarantee that any
notification will ever get delivered to subscriber
subscriberobserverobject of interest
Event service
object of interest
object of interest observer
subscriber
subscriber
3.
1.
2. notification
notification
notification
notification
© Addison-Wesley Publishers 2000
4 - 57 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Event Based Distributed Programming
♦ Architecture8observer objects: decoupling of an object of interest from subscriber
– responsible for all subscribers to events in some object– subscribers and the types of events they are interested in may be
rather heterogeneous - hence, better to have observer deal with this (separation of concerns!)
8 three cases– in case 3, the object of interest is outside event service, hence,
the observer needs to poll the object of interest for event occurrences
subscriberobserverobject of interest
Event service
object of interest
object of interest observer
subscriber
subscriber
3.
1.
2. notification
notification
notification
notification
© Addison-Wesley Publishers 2000
4 - 58 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Extension of Java object model8allows for invocation of methods on remote objects8single language system8RMI syntactically identical to local method invocations
– should RMI calls be syntactically transparent, or not?ipro: hiding of the implementation of the method invocationicon: the semantics of local and remote invocation differ, and
this should be made explicit in the language8however, object making a remote invocation needs to be able to
handle RemoteExceptions that are thrown in the event of communication subsystem failures
8 remote object must implement Remote interface8example used
– shared whiteboardishared use of drawing surface containing graphical objectsiserver maintains current shape of drawingiclients can poll server about latest shape of a drawingiserver attaches version numbers to new arriving shapes
4 - 59 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Remote Interface
8GraphicalObject: class representing state of drawing objects
– should implement Serializable - why?
import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {
int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException; 1
}public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;
}
© Addison-Wesley Publishers 2000
4 - 60 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Remote Interface
8Ordinary and remote objects can appear as input and output arguments
– remote objects: passed by (object) referencei2: newShape returns object with remote interface, i.e., remote
object, as resultiwhen remote object reference is received, an RMI can be
issued on the object refered to by this reference– ordinary objects: passed by valueinew object created locally, with state differing from original
object
import java.rmi.*;import java.util.Vector;public interface Shape extends Remote {
int getVersion() throws RemoteException;GraphicalObject getAllState() throws RemoteException; 1
}public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException; 2Vector allShapes() throws RemoteException;int getVersion() throws RemoteException;
}
© Addison-Wesley Publishers 2000
4 - 61 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Insert: Processes and Threads♦ Process
8software in execution
8unit of resource management for operating system
– execution environment
iaddress space
ithread synchronization and communication resources (e.g., semaphores, sockets)
icomputing resources (file systems, windows, etc.)
– threads
ischedulable activities attached to processes
iarise from the need for concurrent activities sharing resources within one process
* concurrent input/output with problem computation
* servers: concurrent processing of client requests, each request handled by one thread
4 - 62 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Insert: Processes and Threads♦ Process
8processes vs. threads
– threads are “lightweight” processes
iprocesses expensive to create, threads easier to create and destroy
8process instantiation
– one thread will be instantiated as well, may instantiate offsprings
4 - 63 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Thread(ThreadGroup group, Runnable target, String name) Creates a new thread in the SUSPENDED state, which will belong to group and be identified as name; the thread will execute the run() method of target.
setPriority(int newPriority), getPriority()Set and return the thread’s priority.
run()A thread executes the run() method of its target object, if it has one, and otherwise its own run() method (Thread implements Runnable).
start()Change the state of the thread from SUSPENDED to RUNNABLE.
sleep(int millisecs)Cause the thread to enter the SUSPENDED state for the specified time.
yield()Enter the READY state and invoke the scheduler.
destroy()Destroy the thread.
Processes and Threads♦ Java Thread class
© Addison-Wesley Publishers 2000
4 - 64 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Processes and Threads♦ Thread Groups
8every thread belongs to one group, assigned at thread creation time
8 thread groups useful to shield various applications running in parallel on one Java Virtual machine
– thread in one group may not interrupt thread in another group
ie.g., an application may not interrupt the windowing (AWT) thread
4 - 65 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Processes and Threads♦ Java Thread Synchronization
8each thread’s local variables and methods are private to it
– thread has own stack
8 thread does not have private copies of static (class) variables or object instance variables
8mutual exclusion via monitor concept
– abstract data type first implemented in Ada– in Java: synchronized keyword
iany object can only be accessed through one invocation of any of its synchronized methods
ian object can have synchronized and non-synchronized methods
– exampleisynchronized addTo() and removeFrom() methods to
serialize requests in worker pool example
4 - 66 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Processes and Threads♦ Java Thread Synchronization8 threads can be blocked and woken up
– thread awaiting a certain condition calls an object’s wait()method
– other thread calls notify() or notifyAll() to awake one or all blocked threads
8example– worker thread discovers no requests to be processedicalls wait() on instance of Queue
– when IO thread adds request to queueicalls notify() method of queue to wake up worker
thread.join(int millisecs)Blocks the calling thread for up to the specified time until thread has terminated.
thread.interrupt()Interrupts thread: causes it to return from a blocking method call such as sleep().
object.wait(long millisecs, int nanosecs)Blocks the calling thread until a call made to notify() or notifyAll() on object wakes the thread, or the thread is interrupted, or the specified time has elapsed.
object.notify(), object.notifyAll()Wakes, respectively, one or all of any threads that have called wait() on object.
© Addison-Wesley Publishers 2000
4 - 67 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Downloading of Classes
8classes can be transferred from one Java VM to another
8passing of local or remote object references
– if recipient does not yet possess class of object passed by value, or proxy to handle remote object reference, the respective code is transferred automatically from the VM where these are implemented
♦ RMI Registry: binder for Java RMI
8 runs of every server of remote objects
8maps local object names of the form //computerName:port/objNameto object references
8not a global service - clients need to query a particular host to get reference
4 - 68 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Server with main method
♦ Security Manager
8 implements various security policies for client accesses
♦ Main method
81: create instance of ShapeListServant82: binds name "ShapeList" to newly created instance in RMIRegistry
import java.rmi.*;public class ShapeListServer{
public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());try{
ShapeList aShapeList = new ShapeListServant(); 1Naming.rebind("Shape List", aShapeList ); 2
System.out.println("ShapeList server ready");}catch(Exception e) {System.out.println("ShapeList server main " + e.getMessage());}
}}
© Addison-Wesley Publishers 2000
4 - 69 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ ShapeListServant implements ShapeList
81: UnicastRemoteObject - objects that live only as long as creating process
82: factory method - client can request creation of a new object
import java.rmi.*;import java.rmi.server.UnicastRemoteObject;import java.util.Vector;public class ShapeListServant extends UnicastRemoteObject implements ShapeList {
private Vector theList; // contains the list of Shapes 1private int version;
public ShapeListServant()throws RemoteException{...}public Shape newShape(GraphicalObject g) throws RemoteException { 2
version++;Shape s = new ShapeServant( g, version); 3
theList.addElement(s); return s;}
public Vector allShapes()throws RemoteException{...}public int getVersion() throws RemoteException { ... }}
© Addison-Wesley Publishers 2000
4 - 70 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Client program
8polling loop:
– 1: look up remote reference
– 2: invoke allShapes() in remote object
import java.rmi.*;import java.rmi.server.*;import java.util.Vector;public class ShapeListClient{
public static void main(String args[]){System.setSecurityManager(new RMISecurityManager());ShapeList aShapeList = null;try{
aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ; 1Vector sList = aShapeList.allShapes(); 2
} catch(RemoteException e) {System.out.println(e.getMessage());}catch(Exception e) {System.out.println("Client: " + e.getMessage());}}}
© Addison-Wesley Publishers 2000
4 - 71 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Java RMI♦ Callbacks
8avoid polling: server informs clients whenever an event occurs
– client creates remote object and provides method for server to call
– server allows clients to inform it of remote object references for their callback methods
– server calls clients using these methods whenever an event of interest occurs
8problems
– clients may not revoke the callback requests before they exit, hence the list to be maintained in server may be inaccurate
iuse leases instead
– need to make a series of synchronous RMI invocations for every event of interest may block server progress for some time
4 - 72 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Common Object Request Broker Architecture (CORBA)8standardized by the Object Management Group (OMG)
– www.omg.org8specifications of interfaces for “open distributed object systems”
– heterogeneous ihardwareinetwork infrastructureioperating systemsiprogramming languages
* multi-language system* definition of an Interface Definition Language that will be
compiled into application programming language
4 - 73 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Common Object Request Broker Architecture (CORBA)8object request broker (ORB): support for transparent object
invocation, similar to Java RMIs– locate object– activate object– communicate request– returning reply
8 important: clients and servants do not need to be objects, i.e.,CORBA also works for non-OO languages like C, Cobol, etc.
8numerous commercial and public domain implementations are available
8 remote object is called “CORBA object”
4 - 74 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Common Object Request Broker Architecture (CORBA)
8static invocation: remote interface of the CORBA object is known at compile time
– code can be used to generate client stubs (proxies) and server skeletons
8dynamic invocation: remote interface not known at compile time
– when a client without necessary proxy needs to invoke a CORBA object
– example
iclient wishes to display information about all known CORBA objects in all servers
ican’t be expected that client has proxies for all object, since they are dynamically generated and deleted
– note: CORBA does not allow dynamic loading of proxies as Java RMI would
4 - 75 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture
8ORB core
– communications module
– allows ORB to be started and stopped
– remote object references to string conversion, and vice versa
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 76 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture
8Object adapter
– mediates between CORBA objects with IDL interfaces and the programming language interfaces
icreates remote object references for CORBA objects
idispatches RMIs via skeleton to servant class
iactivates objects
– maintains object names
igenerated at object activation, automatically or specified by user
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 77 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture
8Skeletons
– generated by IDL compiler
– scheduling
– marshaling/unmarshaling of arguments and exceptions
8Client stubs/proxies
– in application language
– generated by IDL compiler from IDL interface definition
– marshaling/unmarshaling of arguments and exceptions
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 78 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture
8 Implementation repository
– activation of registered servers on demand
– locating of servers currently running
– maintains object adapter names and locations for every CORBA object
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 79 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture
8 Interface Repository
– provide information about registered IDL interfaces to clients
inames of methods
inames and types of method arguments
– can be used to emulate JAVA-type reflection
iuseful if a client has no proxy for a remote reference it receives
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 80 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture - Remote Object References8 Interoperable Object References (IOR)
– IDL Interface Type Nameiname stored in Interface Repository, can be used at runtime
to retrieve IDL definition of interface– protocol and address specificsiInternet Inter-Orb Protocol (IIOP) uses TCP/IP
– Object Identification8Transient IORs
– persist only as long as hosting process – contains address details of server hosting object
8Persistent IORs– survive inactivation periods of CORBA objects– contains address details of implementation repository
IOR format
IDL interface type name Protocol and address details Object key
interface repositoryidentifier
IIOP host domainname
port number adapter name object name
© Addison-Wesley Publishers 2000
4 - 81 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture - Remote Object References8Usage of IOR to locate servant representing CORBA object
– transient IORsiserver ORB core receives request containing adapter nameiuses adapter name to locate adapteriadapter uses object name to locate servant
© Addison-Wesley Publishers 2000
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 82 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA
♦ CORBA Architecture - Remote Object References8Usage of IOR to locate servant representing CORBA object
– persistent IORsiImlementation Repository receives request and extracts
object adapter nameiif necessary, activates object at specified hostiIR returns address details (including object adapter name and
object name) to the client ORB, which uses them for the RMI request messagesiserver ORB core locates object adapter, adapter uses object
name to locate servant
© Addison-Wesley Publishers 2000
client server
proxy
or dynamic invocation
implementationrepository object
adapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interfacerepository
Request
Reply corecorefor AServant
A
© Addison-Wesley Publishers 2000
4 - 83 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA Object Model
8object model similar to the generic distributed object model discussed earlier
8CORBA object (remote object)
– implements IDL interface
– has remote object reference
– capable of responding to remote invocations
8CORBA does not know the concepts of object and class
– implementation languages can be non-OO
– impossible to define classes in CORBA IDLiuse of structs instead
* components similar to instance variables of a class
* does not have methods
– impossible to pass classes as arguments or results
4 - 84 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA IDL8 interface specifies names and methods that clients can use (invoke)8extended subset of C++ syntax8 IDL modules
– logical grouping of interface and type definitions– defines naming scope
8 IDL interface– methods that are available in CORBA objects implementing the
interface8 IDL methods
– specify signatures– parameters are labeled as in, out and inoutiin passed with request message from client to serveriout passed with reply message from server to client
– oneway indicates that client will not be blocked when invoking this methodithese methods use maybe invocation semantics
– raises: user-defined exceptions
4 - 85 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA IDL
8 IDL types
– always passed by value
Type Examples Use
sequence typedef sequence <Shape, 100> All;typedef sequence <Shape> Allbounded and unbounded sequencesof Shapes
Defines a type for a variable-lengthsequence of elements of a specifiedIDL type. An upper bound on thelength may be specified.
string String name; typedef string<8> SmallString; unbounded and boundedsequences of characters
Defines a sequences of characters,terminated by the null character. Anupper bound on the length may bespecified.
array typedef octet uniqueId[12];
typedef GraphicalObject GO[10][8]
Defines a type for a multi-dimensionalfixed-length sequence of elements of aspecified IDL type.
continued...
© Addison-Wesley Publishers 2000
4 - 86 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA IDL
8 IDL types
8special type Object– values are remote object references
Type Examples Use
record struct GraphicalObject {string type;Rectangle enclosing;boolean isFilled;
};
Defines a type for a record containing agroup of related entities. Structs arepassed by value in arguments andresults.
enumerated enum Rand(Exp, Number, Name);
The enumerated type in IDL maps atype name onto a small set of integervalues.
union union Exp switch (Rand) {case Exp: string vote;
case Number: long n;case Name: string s;
The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header isparameterized by an enum, whichspecifies which member is in use.};
© Addison-Wesley Publishers 2000
4 - 87 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA IDL
8 IDL attributes
– like public class fields in Java
– may be defined as readonly– for each attribute declared, a couple of access methods is
automatically generated by IDL compiler (get/put methods)
8 IDL interface inheritance
– one interface may be the refinement of another interface
8 IDL type names generated by compiler
– IDL prefix
– type name
– prefix number
4 - 88 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList
81, 2: parameter types as structs
– GraphicalObject was class in Java RMI example
83: use of GraphicalObject as a result type
84: definition of a sequence type to store object shapes, used in 8
struct Rectangle{ 1long width; long height;long x;long y;
} ;
struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;
};
interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject
};
typedef sequence <Shape, 100> All; 4interface ShapeList { 5
exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;
};© Addison-Wesley Publishers 2000
4 - 89 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example: IDL definitions for Interfaces Shape and ShapeList
8parameter passing– parameters whose type is specified as an IDL interface refer to a
CORBA object, and remote object reference is passed– primitive and constructed types are copied and passed by value– 8: return value is an array of object referencesiarray passed by valueicontents of array defined as interface (Shape), hence object
references will be passed
struct Rectangle{ 1long width; long height;long x;long y;
} ;
struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;
};
interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject
};
typedef sequence <Shape, 100> All; 4interface ShapeList { 5
exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;
}; © Addison-Wesley Publishers 2000
4 - 90 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example
8 idltojava: compiles Java code from CORBA definitions
– equivalent Java interfaces
iexample: Java interface for ShapeList
– skeletons for each IDL interface
– proxy classes/client stubs for each IDL interface
public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();
}
© Addison-Wesley Publishers 2000
4 - 91 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example: Server
8CORBA objects implemented as servant classes– above: ShapeList servant classi1: newShape is factory method i2: use connect to register an object with the ORB (render it a
CORBA object)
import org.omg.CORBA.*;class ShapeListServant extends _ShapeListImplBase {
ORB theOrb;private Shape theList[];private int version;private static int n=0;public ShapeListServant(ORB orb){
theOrb = orb;// initialize the other instance variables
}public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { 1
version++;Shape s = new ShapeServant( g, version);if(n >=100) throw new ShapeListPackage.FullException();theList[n++] = s; 2theOrb.connect(s);return s;
}public Shape[] allShapes(){ ... }public int getVersion() { ... }
}
© Addison-Wesley Publishers 2000
4 - 92 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example: Server
8server class - main method– 1: initializes ORB– 2, 3: initialize ShapeListServant and register with ORB– 4, 5, 6, 7: generate a name and register with CORBA naming
service– 8: wait for invocations
import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListServer {
public static void main(String args[]) {try{
ORB orb = ORB.init(args, null); 1ShapeListServant shapeRef = new ShapeListServant(orb); 2orb.connect(shapeRef); 3 org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService"); 4NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", ""); 5NameComponent path[] = {nc}; 6ncRef.rebind(path, shapeRef); 7java.lang.Object sync = new java.lang.Object();synchronized (sync) { sync.wait();} 8
} catch (Exception e) { ... }}
} © Addison-Wesley Publishers 2000
4 - 93 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ Example: client
81: initialize ORB
82: get reference to remote ShapeList object using CORBA naming service
83, 4: invoke remote operations
8note in 4: class GraphicalObject as a return type?
– while CORBA does not know classes, the implementation languages may well interpret the CORBA structs as classes
import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListClient{
public static void main(String args[]) {try{
ORB orb = ORB.init(args, null); 1org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", "");NameComponent path [] = { nc };ShapeList shapeListRef =
ShapeListHelper.narrow(ncRef.resolve(path)); 2Shape[] sList = shapeListRef.allShapes(); 3GraphicalObject g = sList[0].getAllState(); 4
} catch(org.omg.CORBA.SystemException e) {...}} © Addison-Wesley Publishers 2000
4 - 94 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
CORBA♦ CORBA services8services specified by CORBA standard that might be helpful to
distributed objects8examples
– Naming Serviceiimplements function of a binder
– Event and Notification servicesisupport event based programming
– Security Serviceiauthentication, access control, and non-repudiation
– Trading Serviceidirectory service that allows objects to be identified by value
of some attribute– Transaction and Concurrency Control Serviceisupport for distributed, concurrent database transactions
– Persistent Object Serviceiimplement persistent objects that can be activated and
deactivated
4 - 95 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ .NET
8a Microsoft component-based solution to distributed applications, a middleware platform integrated with other Microsoft development environments
– Microsoft proprietary
8not a typical open environment for distributed applications, e.g.
– does not always rely on interface definitions (metadata)
– may even modify remote objects directly, no need to obtain remote object references if client and remote object reside in the same machine
8open to other technologies and platforms
– communication through HTTP, SOAP, WSDL
– .NET can be built upon Microsoft Windows or Linux (Mono Project)
– applications written in different programming languages: C#, VC++, VB, Microsoft Java, SmallTalk, COBOL, Phyton, TCL/TK, Perl....
4 - 96 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ .NET
8history:
– a Mircosoft strategic change from product-oriented desktop applications to service-oriented component applications,
– goal: compete with prospering SUN J2EE with Java RMI dominating the middleware market.
– an evolution from previous component-based Microsoft technologies:
iCOM DCOM MTS COM+ .NET
4 - 97 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ .NET Framework
Operating System
COM+ Enterprise Server
.NET Framework (Core)
Class Library
CLR (Runtime Environment)
4 - 98 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ COM (Component Object Model)
8Component
– reusable encapsulated object
8Assembly: logical encapsulation of all the information about several components.
– modules: specification and implementation of a component.
imetadata (specification)
icode (implementation) in Microsoft Intermediate Language (MSIL)
– manifest: assembly version, security, relation among encapsulated components.
iSecurity: digital signature.
4 - 99 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ COM (Component Object Model)8MSIL
– plays the same role as Java bytecode.– programs in high-level language, such as VC++ or C#, will all be
compiled into MSILiCPU-independent set of instructions that can be efficiently
converted to native code iinstructions for loading, storing, initializing, and calling
methods on objects – not a high-level language: binary (unlike bytecode)– but also not a machine language: type system, object-oriented– not executable, needs to be compiled into machine language (not
interpreted as bytecode in Java)
4 - 100 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ COM (Component Object Model)
8Common Type System (CTS)
– type abstractions without syntax and semantics
– every language maps a subset of CTS types to its own types
iexample * VB type char* as CTS type System.string
* VC type CString as CTS type System.string
* System.string then used in MSIL for compilation of executable code
– CTS is an object-oriented type system
ican define classes, encapsulation
4 - 101 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ COM (Component Object Model)
8 Interfaces
– written in Microsoft Interface Definition Language (MIDL), similar to CORBA IDL.
– a component can have more than one interface, each having a unique ID.
– each component must have an “IUNKNOWN” interface maintaining references to the component itself:iMethod QueryInterface()
* Querys a component for an specific interface and gets a reference if the interface exists.
iMethod AddRef()
* Increments the reference counter.iMethod Release()
* Decrements the reference counter.
4 - 102 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ COM (Component Object Model)
8 Interfaces
8Global Unique Identifier (GUID)
– each component is identified with a GUID.
– 128 bits, registered at the residing system.
interface hello
{
void HelloProc([in, string] const unsigned char *pszString);
void Shutdown(void);
}
4 - 103 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ CLR (Common Language Runtime)
8provides similar service as Java environment
– compiles from high level language to MSIL
– high-level language to MSIL compiler produces metadata
itypes in source code, including the definition of each type, thesignatures of each type's members, the members that the source code references, and other data that the runtime uses at execution time.
– CLR brings MSIL code to execution on the target machine
ino interpretation.
ijust-in-time compilation: compile at run time
ipre-compilation at installation time
4 - 104 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ CLR (Common Language Runtime)
8Component Server
– accomodates components
– provides registration service
– provides factory service: generate dynamically components
– component management, such as garbage collection and handling exceptions
4 - 105 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ .NET Framework
8 .NET Remoting Framework
– locate object
– activate object
– send/forward request
– return/forward reply
8amongst others, .NET targets web services
– Web Services Description Language (WSDL)
ian XML format for describing network services
imore recent version: BPEL4WS
– Simple Object Access Protocol (SOAP)
ia lightweight protocol intended for exchanging structured information in a distributed environment
ibuilt on the HTTP protocol
4 - 106 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Inter-Process Communication
8ASP.NET
– adaption from ASP to be integrated with .NET
– ASP is a dynamic website development technique, like JSP in Java
iinefficient
iuntyped
– only supports HTTP, SOAP, WSDL
8 .NET Remoting
– more versatile and extensible using more protocols than just HTTP, SOAP, WSDL, even custom protocols
4 - 107 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET
♦ .NET Remoting Architecture
8Remote Object
– Client-activated objects
iUnder the control of lease-based lifetime manager
iClient can renew the lease
– Server-activated objects
iSingle-call objects
iSingleton objects: service all clients who share the same data.
Client Server
Clientprogram
TransparentProxy for A
SerializationFormatter
SerializationFormatter
CommunicationChannel
Real ProxyFor A
Remote ObjectA
LeaseManager
4 - 108 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NETClient Server
Clientprogram
TransparentProxy for A
SerializationFormatter
SerializationFormatter
CommunicationChannel
Real ProxyFor A
Remote ObjectA
LeaseManager
♦ .NET Remoting Architecture8Proxy Objects: dynamically generated when a client activates the
remote object – Transparent Proxy: run at client side as a representativeiProvides same interface as remote objectiIntercepts all remote call from the clientiForwards each invocation as a message to real proxyiHandels return message
– Real Proxy: run at server sideiHidden from clientiForwards invocation message to remote object
4 - 109 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NETClient Server
Clientprogram
TransparentProxy for A
SerializationFormatter
SerializationFormatter
CommunicationChannel
Real ProxyFor A
Remote ObjectA
LeaseManager
♦ .NET Remoting Architecture
8Proxy Objects: dynamically generated when a client activates theremote object
– Compiled dynamically from the metadata
– Unlike CORBA architecture where proxies are compiled statically from the interface (for static invocation)
– reminder: Java RMI does not support dynamic generation of proxies
4 - 110 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NETClient Server
Clientprogram
TransparentProxy for A
SerializationFormatter
SerializationFormatter
CommunicationChannel
Real ProxyFor A
Remote ObjectA
LeaseManager
♦ .NET Remoting Architecture
8Serialization Formatter
– marshalls a message into a stream at client side
– Two default formats
iBinary
iSoap/XML
– unmarshalls
4 - 111 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Dynamic Invocation
8Type Library-driven Marshalling
– A general real proxy does not contain information about a specific component. Instead, it marshalls a component at run time by getting information from type library.
8Example in C#
Using System;Using System.Reflection;
Assembly *a = Assembly.LoadFrom(“C:/Program Files/…../Something.exe”);
Type[] types = a.GetTypes();Type thistype = types[0];MethodInfo[] methods = thistype.GetMethods();MethodInfo thismethod = methods[0];
…
Thismethod.invoke(this, par1, par2, …, parn);
4 - 112 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Asynchronous Method Invocation8Delegate
– Object that contains the reference to a remote object and one ofits methods
– Gets a worker thread from the thread pool to invoke the method– Stores result of the method
8Asynchronous Method Invocation– Caller thread generates a delegate d– d.beginInvoke(…) gets a worker thread and returns– d.endInvoke(…) to harvest the result
Caller Delegate d Worker
creates
beginInvoke()obtains
returnsInvokesmethod
Methodreturnsstores result
endInvoke()
returns
4 - 113 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Remoting Example Using a TCP Channel
8Remote Object
Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;
namespace RemotingSamples {public class HelloServer : marshalByRefObject { 1
public HelloServer() {Console.WriteLine(“HelloServer activated”);
}
public String HelloMethod(String name) {Console.WriteLine(“Hello.HelloMethod : {0}”, name);return “Hi there” + name;
}}
}
© Microsoft Corporation 2001
1. Any remote object is derived from marshalByRefObject
4 - 114 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Remoting Example Using a TCP Channel
8Server
Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;
namespace RemotingSamples {public class Sample {
public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (8085); 1ChannelServices.RegisterChannel(chan); 2RemotingConfiguration.RegisterWellKnownServiceType 3
(Type.GetType(“RemotingSamples.HelloServer”),“SayHello”, WellKnownObjectMode.SingleCall);
System.Console.WriteLine(“Hit <enter> to exit…”);System.Console.ReadLine();return 0;
}}
}© Microsoft Corporation 2000
1. Creates a new TCP channel that listens on the port 80852. Register the channel for the object3. Register the object as a single-call-object, which serves only one request and dies
4 - 115 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Remoting Example Using a TCP Channel
8Client
Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;
namespace RemotingSamples {public class Client {
public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (); ChannelServices.RegisterChannel(chan);HelloServer obj =
(HelloServer) Activator.GetObject( 1typeof(RemotingSamples.HelloServer),“tcp://localhost:8085/SayHello”); 2
if (obj == null)System.Console.WriteLine(“Could not locate server”);
elsepublic delegate string MethodDelegate(String st); 3MethodDelegate myDelegate = new MethodDelegate(obj.HelloMethod); 4IAsyncResult ar = myDelegate.BeginInvoke(“Wei Wei”, null, null); 5while (!ar.IsCompleted) …Console.WriteLine(myDelegate.EndInvoke(null)); 6
return 0;}
}}
© Microsoft Corporation 2001
1. Activates a remote object of type “HelloServer”2. Specifies the URL of the remote object that is configured in the configuration file
4 - 116 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Remoting Example Using a TCP Channel
8Client
Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;
namespace RemotingSamples {public class Client {
public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (); ChannelServices.RegisterChannel(chan);HelloServer obj =
(HelloServer) Activator.GetObject( 1typeof(RemotingSamples.HelloServer),“tcp://localhost:8085/SayHello”); 2
if (obj == null)System.Console.WriteLine(“Could not locate server”);
elsepublic delegate string MethodDelegate(String st); 3MethodDelegate myDelegate = new MethodDelegate(obj.HelloMethod); 4IAsyncResult ar = myDelegate.BeginInvoke(“Wei Wei”, null, null); 5while (!ar.IsCompleted) …Console.WriteLine(myDelegate.EndInvoke(null)); 6
return 0;}
}}
© Microsoft Corporation 2001
3. Creates a new delegate type that has the same parameter types as the remote method.4. Creates the delegate for the remote method.
4 - 117 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Remoting Example Using a TCP Channel
8Client
Using System;Using System.Runtime.Remoting;Using System.Runtime.Remoting.Channels;Using System Runtime.Remoting.Channels.Tcp;
namespace RemotingSamples {public class Client {
public static int Main (String [] arg) {TcpChannel chan = new TcpChannel (); ChannelServices.RegisterChannel(chan);HelloServer obj =
(HelloServer) Activator.GetObject( 1typeof(RemotingSamples.HelloServer),“tcp://localhost:8085/SayHello”); 2
if (obj == null)System.Console.WriteLine(“Could not locate server”);
elsepublic delegate string MethodDelegate(String st); 3MethodDelegate myDelegate = new MethodDelegate(obj.HelloMethod); 4IAsyncResult ar = myDelegate.BeginInvoke(“Wei Wei”, null, null); 5while (!ar.IsCompleted) …Console.WriteLine(myDelegate.EndInvoke(null)); 6
return 0;}
}}
© Microsoft Corporation 2001
5. Invokes the method asynchronously through the delegate6. Harvests the result after being assured of the completion of the remote method
4 - 118 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Comparison between .NET , Java RMI and CORBA
8With .NET you may modify a remote object directly without need of going through function calls if that remote object is resided in a .NET component server.
– CORBA only generates interfaces, while .NET also generates binaries in common intermediate language.
8Java RMI only supports Java, while CORBA and .NET is cross-language.
8Using .NET good development environments are provided.
8MIDL supports object-oriented interface in contrast to CORBA IDL.
8 .NET and Java RMI support multiple interfaces of an object, while CORBA does not.
4 - 119 © Stefan Leue 2005Distributed Software Systems - Winter 2004/2005
Microsoft .NET♦ Comparison between .NET , Java RMI and CORBA
8CORBA and .NET support both static and dynamic invocations.
– .NET uses type library-driven marshalling and reflection.
– CORBA uses dynamic invocation interfaces.
– The reflection in Java is not integrated into Java RMI.