Transcript Object Models for Distributed Systems

Presentation 4:
Principles of
Object-Oriented Middleware
Outline
• Students are assumed to be knowledgeable about
Computer Networks – including the OSI model and
the TCP, UDP protocols. If not … please read ; )
• Types of Middleware
• Transaction-Oriented Middleware
• Message-Oriented Middleware
• Remote Procedure Calls
• Object-Oriented Middleware
• Developing with Object-Oriented Middleware
Computer Networks
- an ultra short introduction
ISO/OSI Reference Model
Application
Middleware
Specific
Presentation
Session
Transport
Network
Data link
Physical
Transport Layer
•Level 4 of ISO/OSI
reference model.
•Concerned with the
transport of information
through a network.
•Two facets in
UNIX/Windows networks:
•TCP and
•UDP
•TCP & UDP do not follow
the OSI model
•TCP/IP model
Application
Presentation
Session
Transport
Network
Data link
Physical
What can you say about the workings of TCP/UDP?
Which is better suited for which tasks?
Transmission Control Protocol (TCP)
• Provides bi-directional stream of bytes between two
distributed components.
• Reliable but slow protocol.
• Buffering at both sides de-couples computation
speeds.
• Best at fairly unreliable Networks (as the Internet)
• Very practical
• As the WWW uses the TCP/IP protocol family
• And most Networking Operating Systems as well
TCP for Request Implementation
Client
Server
Application
Application
Presentation
Presentation
Session
Transport
Session
Requests
Input Stream
Transport
Output Stream
Results
User Datagram Protocol (UDP)
• Enables a component to pass a message containing
a sequence of bytes to another component.
• Other component is identified within message.
• Unreliable but very fast protocol.
• Restricted message length.
• Queuing at receiver
• Best at highly reliable networks (as a LAN)
UDP for Request Implementation
Client
Server
Application
Application
Presentation
Presentation
Session
Request Datagrams
Transport
Session
Transport
Result Datagrams
Types of Middleware
- and why to use …
Rolling your own Distributed Objects
• We may build directly on the TCP or UDP protocols to
build a distributed system
• In Java: quite easy – thanks to the java.net package –
which contains a complete network API incl. socket
support for TCP/UDP
• BUT: if we want to ensure OO – more complex
• Lets take a look at how this may be done
The Basic Class to OO Class
HelloWorld – can
it be more simple?
public class HelloWorldBasic {
public static void main(String[] args) {
System.out.println("HelloWorld!");
}
}
public class HelloWorldOO {
public HelloWorldOO() {
}
To OO:
public void sayHelloWorld() {
return “HelloWorld";
}
public static void main(String[] args) {
HelloWorldOO helloWorldOO = new HelloWorldOO();
System.out.println(helloWorldOO.sayHelloWorld());
}
}
First Issue: Making the Object Distributed
- The Proxy Stub and Marshalling
Caller
Caller
Caller
Called
Stub
Called
Stub
Transport Layer (e.g. TCP or UDP)
What Objects do we
need to Implement This?
• Discussion: think 2 minutes:
• We strive for Access Transparency
• What objects do we need?
• What responsibilities should they have?
Server Class
– The Skeleton / Stub
…
public class HelloWorldServerThread extends Thread {
protected DatagramSocket socket = null;
public HelloWorldServerThread() throws IOException {
super();
socket = new DatagramSocket(4450);
}
public void run() {
while (true) {
…
if (request.startsWith("sayHelloWorld")) {
new String(packet.getData());
// figure out response
String response = null;
//Call the HelloWorldOO method & place it in response
HelloWorldOO helloWorldOO = new HelloWorldOO();
response = helloWorldOO.sayHelloWorld();
buf = response.getBytes();
…
socket.send(packet);
…
Called
Stub
The Client Stub
- HelloWorldProxy
public class HelloWorldProxy {
public HelloWorldProxy() {
}
public String sayHelloWorld() {
…
// get a datagram socket
socket = new DatagramSocket();
// send the request
byte[] buf = new byte[256];
buf = methodCalled.getBytes();
InetAddress address = InetAddress.getByName("localhost");
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, 4450);
socket.send(packet);
// get a response
packet = new DatagramPacket(buf, buf.length);
socket.receive(packet);
response = new String(packet.getData());
}
catch (Exception e) {
e.printStackTrace();
}
socket.close();
return response;
…
Caller
Stub
Achieving Access Transparency
package chapter1;
public class HelloWorldClient {
public static void main(String[] args) {
System.out.println("Recieved from Server: " +
new HelloWorldProxy().sayHelloWorld());
}
}
Caller
Stub
… and thus we have achieved access transparency
using rather simple constructs (the Proxy pattern).
We could have achieved an even higher degree of
transparency by using an interface definition – and thus a
contract between Client & Server.
Direct Use of
Network Protocols implies
• Manual mapping of complex request parameters to byte streams
or datagrams – is complex & error prone
• Manual resolution of data heterogeneity
• encoding differs on NT & UNIX (what is the format of an
Integer?)
• Manual identification of components
• References must be established manually (host add., port nr.
etc.)
• Manual implementation of component activation
• No guarantees for type safety
• Manual synchronization of interaction between distributed
components
• Developers need to handle TCP/UDP output
stream/responses
• No quality of service guarantees
• Transactions, Security, Concurrency, Scalability, Reliability
• Extremely difficult to achieve “Full Access Transparency”
= Reason for Using Middleware
• Layered between Application and OS/Network
• Makes distribution transparent
• Resolves heterogeneity of
•
•
•
•
Hardware
Operating Systems
Networks
Programming Languages
• Provides development and run-time environment for
distributed systems
• “Gets you of the hook” – concerning the nasty stuff in
network programming
Types of Middleware
•Transaction-Oriented
•Suited for Database Applications
•IBM CICS
•BEA Tuxedo
•Encina
•Message-Oriented
•Suited for Asynchronous (EDI,Batch)
•IBM MQSeries
•DEC Message Queue
•NCR TopEnd
•WCF
•(SOAP)
•RPC Systems
•Suited for Access transparency etc
•ANSA
•Sun ONC
•OSF/DCE
•(SOAP)
•Object-Oriented
•OMG/CORBA
•DCOM
•Java/RMI
•WCF
•.NET Remoting
•(SOAP)
•First look at RPCs to
understand origin of objectoriented middleware
Remote Procedure Calls
• Enable procedure calls across host boundaries
• Call interfaces are defined using an Interface
Definition Language (IDL)
• RPC compiler generates presentation and session
layer implementation from IDL
• RPC is the “legacy” of oo middleware
Type Safety and Heterogenity
• How can we make sure that
• servers are able to perform
operations requested by clients?
• actual parameters provided by
clients match the expected
parameters of the server?
• results provided by the server
match the expectations of client?
• Middleware acts as mediator
between client and server to ensure
type safety.
• Achieved by interface definition in a
mutually agreed upon language
• Supports Heterogenity
IDL Example (Unix RPCs)
const NL=64;
struct Player {
struct DoB {int day; int month; int year;}
string name<NL>;
};
program PLAYERPROG {
version PLAYERVERSION {
void PRINT(Player)=0;
int STORE(Player)=1;
Player LOAD(int)=2;
}= 0;
} = 105040;
Flashback to HelloWorld Example
• How to map complex types?
• e.g. returning a struct (in C, C++) or an object (in C++,
Java, C#, etc.)?
• How would you do it?
• Use 5 minutes to discuss this with your neighbor
•
•
•
•
•
•
What are the issues?
Which technology might help us?
How would you do this in Java?
How would you do it in C#?
How would you do it in C++?
How would you get them all to work together?
RPC Marshalling and Unmarshalling
Marshalling: Disassemble
data structures into
transmittable form
Unmarshalling:
Reassemble the complex
data structure
char * marshal() {
char * msg;
msg=new char[4*(sizeof(int)+1) +
strlen(name)+1];
sprintf(msg,"%d %d %d %d %s",
dob.day,dob.month,dob.year,
strlen(name),name);
return(msg);
};
void unmarshal(char * msg) {
int name_len;
sscanf(msg,"%d %d %d %d ",
&dob.day,&dob.month,
&dob.year,&name_len);
name = new char[name_len+1];
sscanf(msg,"%d %d %d %d %s",
&dob.day,&dob.month,
&dob.year,&name_len,name);
};
RPC Stubs
• Creating code for marshalling and unmarshalling is tedious and
error-prone.
• Code can be generated fully automatically from interface
definition.
• Code is embedded (hidden away – de-coupled) in stubs for client
and server.
• Client stub represents server for client, Server stub represents
client for server.
• Stubs achieve type safety.
• Stubs also perform synchronization.
• NOT object-oriented, no support for exceptions or advanced
error handling
Synchronization
• Goal: achieve similar synchronization to local method
invocation
• Achieved by stubs:
• Client stub sends request and waits until server finishes
• Server stub waits for requests and calls server when
request arrives
Object-Oriented Middleware
Interface Definition Language
• Every object-oriented middleware has an interface
definition language (IDL)
• Beyond RPCs, object-oriented IDLs support object
types as parameters, failure handling and inheritance
• Object-oriented middleware provide IDL compilers
that create client and server stubs to implement
session and presentation layer
IDL Example
interface Player : Object {
typedef struct _Date {
short day; short month; short year;
} Date;
attribute string name;
readonly attribute Date DoB;
};
interface PlayerStore : Object {
exception IDNotFound{};
short save (in Player p);
Player load(in short id) raises(IDNotFound);
void print(in Player p);
};
Presentation Layer
Implementation
• The way data is represented
• Ensuring compatible encoding across platforms
• In addition to RPC presentation layer implementation,
object-oriented middleware needs to
• define a transport representation for object references
• deal with exceptions
• need to marshal inherited attributes
Session Layer Implementation
- Mapping of Object references to hosts
-Activation & deactivion of objects
-Invocation of requested operation
-Synchronization of client & server (state)
Object
References
Hosts
Processes
Objects
Developing with
Object-Oriented Middleware
Development Steps
Design
Interface
Definition
Server Stub
Generation
Client Stub
Generation
Server
Coding
Client
Coding
Server
Registration
Stub Generation
Team.midl
Team.idl
Team.java
Team.wsdl
IDL-Compiler
Teamcl.hh
Teamsv.hh
Teamcl.cc
Teamsv.cc
included in
generates
reads
Client and Server Implementation
Team.idl
Client.cc
Server.cc
IDL-Compiler
Teamcl.hh
Teamsv.hh
Teamcl.cc
C++ Compiler, Linker
Client
Teamsv.cc
C++ Compiler, Linker
included in
generates
reads
Server