1. 1 From Objects to Components joint lecture by Prof. Judith Bishop, University of Pretoria, South Africa Stephan Herrmann, TU Berlin

2. 2 Pretoria

3. 3 Distributed Objects Need a connection between processes  e.g. sockets Need memory independent object identifiers  e.g. #1, #2, #3 Need remote method calls  send (“#4 print_yourself”) Need to encode parameters (and return value..) Need to receive return value  result = read () Implement all this for every single method call??

4. 4 Encapsulate Communication class AccountImpl implements Account extends RemoteObject { private String id; public int deposit(int amount) { String amount_str = encode_int(amount); send(id + “ deposit ” + amount_str); String new_balance = readString(); return decode_int(new_balance); } public int get_balance () {... } } Account a = new AccountImpl(“#15”); int nb = a.deposit(1000000);

5. 5 Proxy Pattern Client does not see difference between `real impl´ and proxy Superclass RemoteObject provides basic functions for  socket handling  value conversion (includes creation of proxies for referenced objects) Handcode proxies?? What about the receiving side??  decode messages  assign object IDs Client AccountProxyAccountImpl AccountRemoteObject

6. 6 Java Remote Interface Example package soccer; interface Team extends Remote { public: String name() throws RemoteException; Trainer[] coached_by() throws RemoteException; Club belongs_to() throws RemoteException; Players[] players() throws RemoteException; void bookGoalies(Date d) throws RemoteException; void print() throws RemoteException; }; package soccer; interface Team extends Remote { public: String name() throws RemoteException; Trainer[] coached_by() throws RemoteException; Club belongs_to() throws RemoteException; Players[] players() throws RemoteException; void bookGoalies(Date d) throws RemoteException; void print() throws RemoteException; }; Remote operations Interface name Declare it as remote Package name Wolfgang Emmerich 2000©

7. 7 Architecture Server Client Stub Registry Interfaces Skeleton Activation Interfaces RMI Runtime ( rmid,rmiregistry ) ) Wolfgang Emmerich 2000©

8. 8 Activation in Java Client Host Stub Faulting Reference Live ref Hostwww.bvb.de Activa- tion ID Activator Activation Descriptors: ActGroup ClassName URL Init AG 1 Teamwww.bvb.de/… AG 2 Playerwww.bvb.de/… AG 2 Playerwww.bvb.de/… AG 2 Playerwww.bvb.de/… Java VM 1 2 AG 1 2 1: activate 2: create object in VM 3: pass object ref 4: update live ref Wolfgang Emmerich 2000©

9. 9 Java Interfaces and Remote Objects  Java already includes the concept of interfaces  RMI does not have a separate interface definition language  Pre-defined interface Remote  Remote interfaces extend Remote  Remote classes implement remote interfaces  Remote objects are instances of remote classes Wolfgang Emmerich 2000©

10. 10 Goals of RMI  In Java 1.0 object communication confined to objects in one Virtual Machine  Remote Method Invocation (RMI) supports communication between different VMs, potentially across the network  Provide tight integration with Java  Minimize changes to Java language/VM  Work in homogeneous environment Wolfgang Emmerich 2000©

11. 11 Programming Languages RMI is fine for Java, but  What if I want to implement my objects in different programming languages?

12. 12 OMG Interface Definition Language  Language for expressing all concepts of the CORBA object model  OMG/IDL is programming-language independent orientated towards C++ not computationally complete  Different programming language bindings are available  Explanation of Model and Language by Example Wolfgang Emmerich 2000©

13. 13 Object Model and Interface Definition  Objects  Types  Modules  Attributes  Operations  Requests  Exceptions  Subtypes Wolfgang Emmerich 2000©

14. 14 CORBA Object Model: Objects  Each object has one identifier that is unique within an ORB  Multiple references to objects  References support location transparency  Object references are persistent Wolfgang Emmerich 2000©

15. 15 CORBA Object Model: Subtypes interface Organization { readonly attribute string name; }; interface Club : Organization { exception NotInClub{}; readonly attribute short noOfMembers; readonly attribute Address location; attribute TeamList teams; attribute TrainerList trainers; void transfer(in Player p) raises NotInClub; }; interface Organization { readonly attribute string name; }; interface Club : Organization { exception NotInClub{}; readonly attribute short noOfMembers; readonly attribute Address location; attribute TeamList teams; attribute TrainerList trainers; void transfer(in Player p) raises NotInClub; }; Inherited by Club Supertype Implicit supertype: Object Implicit supertype: Object Wolfgang Emmerich 2000©

16. 16 One standardised interface One interface per object operation ORB-dependent interface One interface per object adapter Dynamic Invocation Dynamic Invocation Client Stubs Client Stubs ORB Interface ORB Interface Implementation Skeletons Implementation Skeletons Client Object Implementation ORB Core Object Adapter Object Adapter Architecture Wolfgang Emmerich 2000©

17. 17 Goal of CORBA  Support distributed and heterogeneous object request in a way transparent to users and application programmers  Facilitate the integration of new components with legacy components  Open standard that can be used free of charge  Based on wide industry consensus Wolfgang Emmerich 2000©

18. 18 Key Points  CORBA, RMI and other middleware (like COM) –enable objects to request operation execution from server objects on remote hosts –identify server objects by object references –distinguish between interface and implementation –treat attributes as operations –provide mechanisms to deal with failures –have statically typed object models –compile stubs from their IDLs –support on-demand activation Wolfgang Emmerich 2000©

19. 19 Wait?  This int deposit(int) method was silly.  Why should I wait for a result??

20. 20 Request Synchronization  Synchronous requests might block clients unnecessarily. Examples: User Interface Components Concurrent Requests from different servers OO-Middleware: synchronous requests. :Server:Server :Client:Client Op() Wolfgang Emmerich 2000©

21. 21 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 :Server:Server :Client:Client oneway() Wolfgang Emmerich 2000©

22. 22 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 } Wolfgang Emmerich 2000©

23. 23 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); }; Wolfgang Emmerich 2000©

24. 24 r:Request :Server :Client send() r=create_request() delete() Oneway requests in CORBA  If oneway declarations cannot be used: Use dynamic invocation interface Op() Wolfgang Emmerich 2000©

25. 25 :Server:Server:Client:Client:Request:Request 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 send() op() get_result() Wolfgang Emmerich 2000©

26. 26 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 } Wolfgang Emmerich 2000©

27. 27 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 :Server:Server:Client:Client r:Requestr:Request op() get_response() r=create_request(“op”) send() Wolfgang Emmerich 2000©

28. 28 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 :Server:Server :Client:Client op() Wolfgang Emmerich 2000©

29. 29 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 Wolfgang Emmerich 2000©

30. 30 Asynchronous Requests with Threads 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); } Wolfgang Emmerich 2000©

31. 31 Asynchronous Requests using Message Queues  Messaging is starting to be provided by object-oriented middleware Microsoft Message Queue CORBA Notification Service Java Messaging Service  Request and reply explicitly as messages  Using two message queues  Asynchronous requests can be achieved Wolfgang Emmerich 2000©

32. 32 Asynchronous Requests using Message Queues Client Server Request Queue Reply Queue enter remove enter Wolfgang Emmerich 2000©

33. 33 Difference between Thread and MQs 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 Wolfgang Emmerich 2000©

34. 34 Request Multiplicity  OO Middleware: unicast requests Two components: client and server One operation execution Non-anonymous  Other forms: multicast requests More than two components (group requests) More than one operation (multiple requests) Wolfgang Emmerich 2000©

35. 35:Trader:Trader:Channel:Channel:Ticker:Ticker:Ticker:Ticker:Ticker:Ticker Group Requests  Example: Stock Exchange Ticker connect() push() disconnect() connect() push() Wolfgang Emmerich 2000©

36. 36 Group Communication Principles  Group communication informs a group of components about a particular event.  Two roles: Event producer Event consumer  Producers and consumers do not know each other.  Two forms of request: push-type: producer initiates communication pull-type: consumer initiates communication Wolfgang Emmerich 2000©

37. 37 Some Architecture  Can’t we use some style of Model-View-Control for distributed applications? business logic client pure model view&control e.g. as servlet e.g. as applet... and we need a DB for connected via http within a web server persistency  Wow, just invented a 3-tier-architecture!

38. 38 EJB Roles and Deployment

39. 39 Developer Roles EJB Technology divides naturally into five developer roles:  server provider,  container provider,  Enterprise Beans (component!!) provider,  application assemblers, and  deployers.

40. 40 Enterprise JavaBeans Components  Application Servers (42)  Authoring Tools (5)  Charts&Graphs (4)  Database Connectivity (21)  Database Servers (6)  Development Tools (47)  EJB Components (34)  EJB-based Applications (49)  Electronic Commerce (38)  Electronic Publishing (5)  Entertainment (1)  Financial Services (20)  Legacy Support (10)  Manufacturing (4)  Multimedia (3)  Network Administration (1)  Object Transaction Monitors (1)  Productivity/Groupware (18)  Report Generation (5)  Retail (6)  System Administration (4)  Telecommunications (15)  Transaction Servers (5)  UI Elements (1)  Utilities&Services (13)  Web Servers (9)  Workflow (6)

41. 41 What is a component? "Reusable software components are self contained, clearly identifiable pieces that describe and/or perform specific functions, have clear interfaces, appropriate documentation and a defined reuse status".

42. 42 Cross platform  An Enterprise Bean executes in a container  An EJB can be taken from one environment to another without recoding.  Communication via RMI as default  EJBs can also be accessed via Corba-IIOP  Corba details are hidden from the EJB developer

43. 43 Writing an EJB  The bean provider adheres to two contracts: –the client’s view, and –the component’s view as seen from the container.  The bean provider therefore produces: –EJB remote interface class file –EJB home interface class file –EJB class file  An EJB can be developed provide the EJB and JNDI classes are installed.  JNDI stands for Java Naming Directory Interface

44. 44  When talking about components, don’t only say “functionality” but pay for properties like  persistence  performance  security  availability  portability ... Naming and Trading  Know the instance? Object ID (exact reference)  Know the provider (who)?Naming (white pages)  Know the service (what)?Trading (yellow pages) based on the declaration of properties like: fee, bandwidth, availability... “Quality of Service” (QoS) attention to  Some of these are implemented e.g. as CORBA services

45. 45 Provide, deploy and use  Provide –the remote interface for all the visible business methods of the bean –the home interface to install instances of a bean on a client –the bean class with the implementation of the business methods  EJB provider tool will set up a descriptor and details of EJB deployment to a runtime container.  Package it all up in an ejb-jar file  Set up RMI in client to use the new service

46. 46 Packaging A Component can be more than just compiled binary code:  Help files  Images  Prototypes (Design Pattern Prototype) (cf. prototype based languages)  provide pre-configured values.  Localisation  etc.  use cloning for creation 

47. 47 todays lesson:  Dispite differences of size function services style ... component development through all phases is the future.

48. 48 References  Wolfgang Emmerich: „Engineering Distributed Objects“ Wileys, 2001 www.distributed-objects.com  www.javasoft.com  Clemens Szyperski: „Component Software - Beyond Object- Oriented Programming“ Addison Wesley, 1998  See also http://www.cms.dmu.ac.uk/ nmsampat/research/subject/reuse/components/index.htm