Presentation 4: Principles of Object-Oriented Middleware

1. Presentation 4:Principles ofObject-Oriented Middleware

2. Types of Middleware- and why to use …

3. Rolling your own distributed object • 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 • Let us take a look at how this may be done

4. 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() { } public void sayHelloWorld() { return “HelloWorld"; } public static void main(String[] args) { HelloWorldOO helloWorldOO = new HelloWorldOO(); System.out.println(helloWorldOO.sayHelloWorld()); } } To OO:

5. Called Caller Caller Called Stub First Issue: Making the Object Distributed- Method Call vs. Object Request Caller Stub Transport Layer (e.g. TCP or UDP)

6. Repetition Group Work • You already know how to do this from Dist • 10 Minutes group work – followed by discussion • On paper – using pseudo code – describe what to code in order to make HelloWorldOO distributed depending solely on the datagram API (UDP) technology • Optimize the code for access transparency • Consider introducing location transparency • Consider introducing scalability transparency • Change the interface to allow for returning a HelloWorldData object with: • Name • Greetings Text • java.util.Data object • Consider how to allow a C++ client to access the code • Consider the problems of your design – what might fail?

7. 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

8. = 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

9. 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 (SOAP) RPC Systems Suited for Access transparency etc ANSA Sun ONC OSF/DCE (SOAP) Object-Oriented OMG/CORBA DCOM Java/RMI/EJB .NET Remoting (SOAP) First look at RPCs to understand origin of object-oriented middleware Types of Middleware

10. Remote Procedure Calls • Enable procedure calls across host boundaries • Call interfaces are defined using an Interface Definition Language (IDL) • RPC compiler generatespresentation and session layer implementation from IDL • RPC is the “legacy” of oo middleware

11. 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

12. 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;

13. Marshalling: Disassemble data structures into transmittable form Unmarshalling: Reassemble the complex data structure RPC Marshalling and Unmarshalling 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); };

14. 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

15. Object-Oriented Middleware

16. Interface Definition Language • Every object-oriented middleware has an interface definition language (IDL) • Beyond RPCs, object-oriented IDLs supportobject types as parameters, failurehandling (exceptions) and inheritance • Object-oriented middleware provide IDLcompilers that create client and server stubs to implement session and presentation layer

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

18. Presentation Layer Implementation • Ensuring compatible encoding across platforms • In addition to RPC presentation layer implementation, object-oriented middlewareneeds to • define a transport representation for object references • deal with exceptions • need to marshal inherited attributes

19. 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

20. Developing with Object-Oriented Middleware

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

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

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