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

Physical Application Presentation Session Transport Network Data link ISO/OSI Reference Model Middleware Specific Middleware Specific

Physical Application Presentation Session Transport Network Data link 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 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

Application Presentation Session Transport Application Presentation Session Transport Input Stream Output Stream Requests Results ClientServer TCP for Request Implementation

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)

Result Datagrams Application Presentation Session Transport Application Presentation Session Transport Request Datagrams ClientServer UDP for Request Implementation

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 public class HelloWorldBasic { public static void main(String[] args) { System.out.println("HelloWorld!"); } HelloWorld – can it be more simple? public class HelloWorldOO { public HelloWorldOO() { } public void sayHelloWorld() { return “HelloWorld"; } public static void main(String[] args) { HelloWorldOO helloWorldOO = new HelloWorldOO(); System.out.println(helloWorldOO.sayHelloWorld()); } To OO:

First Issue: Making the Object Distributed - The Proxy Stub and MarshallingCalledCalled Stub CallerCalledCalledCaller Caller 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); …CalledCalled 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; … Stub Caller

Achieving Access Transparency package chapter1; public class HelloWorldClient { public static void main(String[] args) { System.out.println("Recieved from Server: " + new HelloWorldProxy().sayHelloWorld()); } … 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. Stub Caller

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 object- oriented 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 ; }; program PLAYERPROG { version PLAYERVERSION { void PRINT(Player)=0; int STORE(Player)=1; Player LOAD(int)=2; }= 0; } = ;

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); }; 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

Object References HostsProcessesObjects Session Layer Implementation - Mapping of Object references to hosts -Activation & deactivion of objects -Invocation of requested operation -Synchronization of client & server (state) - Mapping of Object references to hosts -Activation & deactivion of objects -Invocation of requested operation -Synchronization of client & server (state)

Developing with Object-Oriented Middleware

Interface Definition Design Server Stub Generation Client Stub Generation Server Coding Client Coding Server Registration Development Steps

Team.idl included in generates reads IDL-Compiler Teamcl.hh Teamcl.cc Teamsv.cc Teamsv.hh Stub Generation Team.wsdl Team.java Team.midl

C++ Compiler, Linker Server Client.cc Server.cc C++ Compiler, Linker Client Team.idl included in generates reads IDL-Compiler Teamcl.hh Teamcl.cc Teamsv.cc Teamsv.hh Client and Server Implementation