Validating Distributed Object & Component Designs

1. Validating Distributed Object & Component Designs Wolfgang Emmerich and Nima Kaveh London Software Systems University College London http://www.cs.ucl.ac.uk/lss {n.kaveh|w.emmerich}@cs.ucl.ac.uk

2. Outline • Distributed Systems • Middleware • Advanced Communication in Object and Component Middleware • Design Issues for Distributed Objects and Components • Design Validation using Model Checking • Conclusions

3. Distributed System Example

4. Hostn-1 Component1 Componentn Host2 Component1 Componentn Middleware Middleware Network Operating System Network Operating System Hardware Hardware Host1 Component1 Componentn Hostn Component1 Componentn Middleware Middleware Network Operating System Network Operating System Hardware Network Hardware What is a Distributed System?

5. What is a Distributed System? • A distributed systemis a collection of autonomous hosts that that are connected through a computer network. Each host executes components and operates a distribution middleware, which enables the components to coordinate their activities in such a way that users perceive the system as a single, integrated computing facility.

6. Abstraction from network protocols Network protocols do not provide right abstractions for building distributed systems: • Packet forwarding vs. procedure call • Mapping of request parameters to byte streams • Resolution of data heterogeneity • Identification of components • Implementation of component activation • Type safety • Synchronization of interaction between distributed components • Quality of service guarantees

7. Outline • Distributed Systems • Middleware • Advanced Communication in Object and Component Middleware • Design Issues for Distributed Objects and Components • Design Validation using Model Checking • Conclusions

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

9. ISO/OSI Reference Model Application Presentation Middleware Session Transport Network Operating System Network Data link Physical

10. Transaction-Oriented IBM CICS BEA Tuxedo Encina Message-Oriented IBM MQSeries DEC Message Queue NCR TopEnd RPC Systems ANSA Sun ONC OSF/DCE Object-Oriented OMG/CORBA DCOM Java/RMI Distributed-Components J2EE .NET CCM Forms of Middleware

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

12. Called Caller Caller Called Stub Local vs. Remote Procedure Call Caller Stub Transport Layer (e.g. TCP or UDP)

13. IDL Example (Unix RPCs) const NL=64; struct Customer { struct DoB {int day; int month; int year;} string name<NL>; }; program TRADERPROG { version TRADERVERSION { void PRINT(Customer)=0; int STORE(Customer)=1; Customer LOAD(int)=2; }= 0; } = 105040;

14. Presentation Layer • Resolve data heterogeneity • Common data representation • Transmission of data declaration • Map complex data structures to network transport • Static marshalling/unmarshalling • Dynamic marshalling/unmarshalling

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

16. Stubs • Creating code for marshalling and unmarshalling is tedious and error-prone. • Code can be generated fully automatically from interface definition. • Code is embedded in stubs for client and server. • Client stub represents server for client, Server stub represents client for serve. • Stubs achieve type safety. • Stubs also perform synchronization.

17. Type Safety • 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 an agreed language.

18. Facilitating Type Safety Interface Definition Server Request Client Reply

19. What should client do while server executes Wait? Not care? Proceed concurrently and re-synchronise later? What should server do if clients request operations concurrently Process them sequentially? Process them concurrently? Each of these reasonable Most supported by middleware primitives Synchronization

20. Outline • Distributed Systems • Middleware • Advanced Communication in Object and Component Middleware • Design Issues for Distributed Objects and Components • Design Validation using Model Checking • Related Work • Conclusions

21. Policies & Primitives • Mainstream object middleware provides few primitives and policies • Threading Policies (Server-side): • Single Threaded • Multi Threaded • Synchronization Primitives (Client-side): • Synchronous Requests • Deferred Synchronous Requests • One-way Requests • Asynchronous Requests

22. Server-side threading policies • Multiple client objects can request operations from servers concurrently • What to do? • Options: • Queue requests and process them sequentially • Start new concurrent threads for every request • Use a thread-pool and assign a thread to each new request • To relieve programmer of server object: • Server-side threading implemented in object adapters • POA in CORBA • SCM in COM • EJB Container in J2EE

23. Object Implementation Client Implementation Skeletons POA Dynamic Invocation ORB Interface Client Stubs ORB Core One standardised interface One interface per object operation One interface per object adapter ORB-dependent interface CORBA Architecture

24. POA Threading Policies • Single-threaded: • Use when object implementations are not thread safe • Default threading policy in CORBA • ORB-controlled: • Threads to execute object implementations are started, managed and stopped by the ORB • Programmer has to be aware that implementations will be called concurrently and make them thread safe (e.g. for stateful objects) • Unspecified how ORB implements thread management.

25. Client-side Synchronisation Primitives Overview • Synchronous (Rendevous): Client-blocked until server finished execution of requested operation • Oneway: Client continues after request taken by middleware, no synchronisation happens at all • Deferred synchronous: Client continues after request taken by middleware, client polls for result • Asynchronous: Client continues after request taken by middleware and server informs about the result

26. :Client :Server Op() Request Synchronization • OO-Middleware default: synchronous requests. • Synchronous requests might block clients unnecessarily. Examples: • User Interface Components • Concurrent Requests from different servers

27. :Server :Client Oneway Requests • Return control to client as soon as request has been taken by middleware • Client and server are not synchronized • Use if • Server does not produce a result • Failures of operation can be ignored by client oneway()

28. Oneway using Java Threads class PrintSquad { static void main(String[] args) { Team team; Date date; // initializations of team and date omitted ... OnewayReqPrintSquad a=new OnewayReqPrintSquad(team,date); a.start(); // continue to do work while request thread is blocked... } } // thread that invokes remote method class OnewayReqPrintSquad extends Thread { Team team; Date date; OnewayReqPrintSquad(Team t, Date d) { team=t; date=d; } public void run() { team.print(date); // call remote method and then die } }

29. Oneway requests in CORBA • Declared statically in the interface definition of the server object • IDL compiler validates that • operation has a void return type • does not have any out or inout parameters • does not raise type specific exceptions • Example: interface Team { oneway void mail_timetable(in string tt); };

30. :Client :Server r=create_request() r:Request send() Op() delete() Oneway requests in CORBA • If oneway declarations cannot be used: Use dynamic invocation interface

31. :Client :Request :Server send() op() get_result() Deferred Synchronous Requests • Return control to client as soon as request has been taken by middleware • Client initiates synchronization • Use if • Requests take long time • Client should not be blocked • Clients can bear overhead of synchronization

32. Deferred Synchronous Requests with Threads class PrintSquad { public void print(Team t, Date d) { DefSyncReqPrintSquad a=new DefSyncReqPrintSquad(t,d); // do something else here. a.join(this); // wait for request thread to die. System.out.println(a.getResult()); //get result and print } } // thread that invokes remote method class DefSyncReqPrintSquad extends Thread { String s; Team team; Date date; DefSyncReqPrintSquad(Team t, Date d) {team=t; date=d;} public String getResult() {return s;} public void run() { String s; s=team.asString(date);// call remote method and die } }

33. :Client :Server r=create_request(“op”) r:Request send() op() get_response() CORBA Deferred Synchronous Requests • Determined at run-time with using DII • By invoking send() from a Request object • And using get_response() to obtain result

34. Asynchronous Requests • Return control to client as soon as request has been taken by middleware • Server initiates synchronization • Use if • Requests take long time • Client should not be blocked • Server can bear overhead of synchronization :Client :Server op()

35. Asynchronous Requests with Threads • Client has interface for callback • Perform request in a newly created thread • Client continues in main thread • New thread is blocked • Requested operation invokes callback to pass result • New thread dies when request is complete

36. interface Callback { public void result(String s); } class PrintSquad implements Callback { public void Print(Team team, Date date){ A=new AsyncReqPrintSquad(team,date,this); A.start(); // and then do something else } public void result(String s){ System.out.print(s); } } class AsyncReqPrintSquad extends Thread { Team team; Date date; Callback call; AsyncReqPrintSquad(Team t, Date d, Callback c) { team=t;date=d;call=c; } public void run() { String s=team.AsString(date); call.result(s); } } Asynchronous Requests with Threads

37. Asynchronous Requests using Message Passing • Message passing is starting to be provided by object- and component-oriented middleware • Microsoft Message Queue • CORBA Notification Service • Java Messaging Service • Request and reply explicitly as messages • Asynchronous requests can be achieved using two message queues

38. Request Queue Reply Queue Asynchronous Requests using Message Queues enter remove Client Server remove enter

39. Threads Communication is immediate Do not achieve guaranteed delivery of request Can be achieved using language/OS primitives Message Queues Buffer Request and Reply messages Persistent storage may achieve guaranteed delivery Imply additional licensing costs for Messaging Difference between Threading and MQs

40. Outline • Distributed Systems • Middleware • Advanced Communication in Object and Component Middleware • Design Problems for Distributed Objects and Components • Design Validation using Model Checking • Related Work • Conclusions

41. Design Problems • Client and server objects execute concurrently (or even in parallel when residing on different machines) • This concurrency gives raise to the usual problems: • Deadlocks • Safety Property violations • Liveness

42. Deadlock Example

43. Safety Properties • Notifications of new price are sent only in response to trade update • Only traders that have subscribed for notifications will receive them • Equity server cannot accept new trade unless notification of previous trade is complete

44. Liveness Properties • It is always the case that the EquityServer will eventually be able to accept a trade • Traders will always be able to eventually enter a new trade

45. Outline • Distributed Systems • Middleware • Advanced Communication in Object and Component Middleware • Design Issues for Distributed Objects and Components • Design Validation using Model Checking • Related Work • Conclusions

46. Motivations & Challenges • Confront complexities by offering developers design aid • Complement existing Software Engineering validation and verification techniques • Only expose designers to the UML notation they are likely to be familiar with • Solution not dependent on any specific semantic notation • Build on existing tools and notations

47. Approach • Exploit the fact that object and component middleware provide only few primitives for synchronization of distributed objects • Representation of these primitives as stereotypes in UML models • Formal specification of stereotype semantics • Model checking of UML models against given safety and liveness properties

48. Stereotype UML Class & Statechart diagrams + props. Process Algebra Generation Approach Overview Results – UML Sequence diagrams Model Checking Design Domain Verification Domain

49. Policies & Primitives • Mainstream object middleware provides few primitives and policies • Synchronization Primitives (Client-side): • Synchronous Requests • Deferred Synchronous Requests • One-way Requests • Asynchronous Requests • Threading Policies (Server-side): • Single Threaded • Multi Threaded

50. Process Algebra Generation Approach Overview Stereotype UML Class & Statechart diagrams + props Results – UML Sequence diagrams Model Checking Developer Domain Verification Domain