Overloading Java Interface Callback Protocol User Command Handler Concurrent Thread

Transcription

1 Overloading Java Interface Callback Protocol User Command Handler Concurrent Thread 1

2 Code refactoring is the process of changing a computer program s internal structure without modifying its external functional behavior or existing functionality, in order to improve internal non-functional properties of the software. For example, refactoring is done to improve: Code readability Code structure Change code to adhere to a given programming paradigm Improve maintainability Improve performance Improve extensibility. 2

3 Current Server Basic Multi-threaded Version << TCP/IP network, Data >> Client << TCP/IP network, Connection Request >> * ClientConnection UserCommandHandler myui myserver execute StandardIO mycommmandhandler ServerTest Server Server startserver stopserver listen setdolisten stoplistening setport getport sendmessagetoui run ClientConnection getclientsocket sendmessagetoclient disconnectclient stopthisthread run ClientCommandHandler setcommandhandler getuserinput display run execute 3

4 Refactoring: ClientConnection Currently, the run() method in the ClientConnection object receives two types of messages: 1. Commands from the Client, requesting a service of the Server 2. Exceptional events, such as unexpected TCP disconnection or unexpected client disconnection. while (stopthisthread == false) { try { msg = (byte) input.read(); thestring = bytetostring(msg); myclientcommandhandler.execute(this, thestring); } catch (IOException e) { myserver.sendmessagetoui( Unexpected disconnection; stopping thread and disconnecting client: "+ clientsocket.getremotesocketaddress()); disconnectclient(); stopthisthread = true; } } 4

5 Refactoring: ClientConnection Currently, the run method sends client command messages to the ClientCommandHandler class, and exceptional event messages to the Server class. A better object oriented design would be that if both types of messages were sent to the same destination, namely, the ClientCommandHandler class. It would be better OO design because the handler should decide and handle what to do with any kind of message received from the client. Better yet, the ClientCommandHandler class should be named ClientMessageHandler to indicate that it can receive any type of message from a client, i.e., both client commands and exceptional events associated with the client. The run method should send both types of messages to the ClientMessageHandler, but to different methods, one method for receiving client commands and a different method for receiving exceptional events associated with the client. This can be done by overloading a method in the ClientMessageHandler class. 5

6 Refactoring: Changing Name (1) Refactor: change the name of the clientcommandhandler package to clientmessagehandler 6

7 Refactoring: Changing Name (2) Refactor: change the name of the ClientCommandHandler.java to ClientMessageHandler.java ClientMessageHandler 7

8 Refactoring: Changing Name (3) Refactor: change the name of handleclientcommand to handleclientmessage 8

9 Refactoring: Changing Name (4) Refactor: change the name of theclientcommand to theclientmessage.java 9

10 Overloading means that the same method name can be defined with more than one signature the list of formal parameters (and their types). In Java, overloading means that there can be different versions of a function and the compiler can tell which one is intended by looking at the types of parameters in a call to the function (method). 10

11 Overloaded Method in ClientMessageHandler public void handleclientmessage(clientconnection.clientconnection myclientconnection, String thecommand) { if (thecommand.equals("d")) { myserver.sendmessagetoui("disconnect command received from client + myclientconnection.getclientsocket().getremotesocketaddress()); myclientconnection.clientdisconnect(); myserver.sendmessagetoui("\tdisconnect successful. "); } else if (thecommand.equals("q")) { This processes This processes } an exceptional a client } event command public void handleclientmessage(string theexceptionalevent) { myserver.sendmessagetoui(theexceptionalevent); } 11

12 Refactoring: ClientConnection Now, after refactoring, the run method calls one of two overloaded methods to handle the different types of client messages: while (stopthisthread == false) { try { msg = (byte) input.read(); theclientmessage = bytetostring(msg); myclientcommandhandler.handleclientmessage(this, theclientmessage); } catch (IOException e) { myclientcommandhandler.handleclientmessage("ioexception: " +e.tostring() + ". Stopping thread and disconnecting client: " +clientsocket.getremotesocketaddress()); disconnectclient(); stopthisthread = true; } } 12

13 UML Class Diagram of Server With Overloaded Method in ClientMessageHandler << TCP/IP network, Data >> Client << TCP/IP network, Connection Request >> UserCommandHandler myui myserver execute StandardIO mycommmandhandler setcommand getuserinput display run ServerTest Server Server startserver stopserver listen setdolisten stoplistening setport getport sendmessagetoui run * ClientConnection ClientConnection getclientsocket sendmessagetoclient disconnectclient stopthisthread run ClientMessageHandler handleclientmessage(clientconnection, String) handleclientmessage(string) 13

14 Next Topic: Adding a Java Interface 14

15 Modeling Server User Messages Notice that, currently, all messages to be sent to the server-user are sent to the Server object s sendmessagetoui() method: public void sendmessagetoui(string thestring) { myui.display(thestring); } Is myui.display(thestring)the best way to send messages to the server-user? However, the method should NOT Assume a particular user interface, such as standard IO or a custom graphical user interface. Configure, manipulate, or modify the message as may be required by the specific interface. Send a configured message to a particular interface. Why? Because, if the user interface changes, then sendmessagetoui would have to change, as well. The method sendmessagetoui should not have any application specific code in it, because, in that case, the Server class would be difficult to reuse in a different application that uses different user interfaces or does not have a user interface. 15

16 Modeling Server User Messages Current way would require changing the myuserinterface field when the user interface is changed. Specifically, the Server would need to be recompiled, since the type of the reference variable would need to be changed. Under some circumstances, recompiling the Server is acceptable, but in others it is not. For example, the reusable Server software may be provided only in *.class files, or as a library, in which case recompiling is not an option. Server User <<receives messages>> Plugin User Interface StandardIO console getuserinput display run Server userinterface.standardio myui sendmessagetoui Server User <<receives messages>> Plugin User Interface GUI getuserinput display run Server userinterface.gui myui sendmessagetoui 16

17 Current Server Code for Standard IO User Interface 17

18 Change Needed for Graphical User Interface 18

19 A better way is to use the Java Interface type The server would declare a Java interface type as the reference variable to reference the user interface. Should the user interface change, the Server code does not change since the user interface reference variable refers to the Java interface type and not to the actual user interface object. The server would send a generic String message to the Java interface type. The UserInterface object would implement the Java interface and input the generic String message and configure or manipulate it to fit the specific type of user interface that it handles. The Server will not know, and does not need to know, what particular user interface is being used. It just sends the message to the <<interface>> object. In this case, if the user interface changes in the future, then the UserInterface object changes of course, but the <<interface>> type would not change, and the link that the Server object uses to reference the <<interface>> would not change as well. 19

20 The Server method invokes myuserinterface.update(message) to send a message to the server user. The StandardIO object handles the message, since it is required to implement the interface. The update method of the object inputs the string and configures or manipulates it to fit the specific type of user interface that it handles., i.e., it sends the string to the monitor, with no manipulation, in this case. If the user interface changes in the future, then The Server object does not change at all (specifically, the myuserinterface type does not change) The UserInterface <<interface>> does not change. The only change that is made is the UserInterface object. Server User <<receives messages>> Plugin User Interface StandardIO console getuserinput update display run <<interface>> UserInterface update(string) Server myuserinterface sendmessagetoui 20

21 The Server method invokes myuserinterface.update(message) to send a message to the server user. The GUI object handles the message, since it is required to implement the interface. The update method of the object inputs the string and configures or manipulates it to fit the specific type of user interface that it handles., i.e., it manipulates the String to display in the TextBox. If the user interface changes in the future, then The Server object does not change at all (specifically, the myuserinterface type does not change) The UserInterface <<interface>> does not change. The only change that is made is the UserInterface object. Server User <<receives messages>> Plugin User Interface GUI mytextbox setcommand update run <<interface>> UserInterface update(string) Server myuserinterface sendmessagetoui 21

22 Interface: Step 1 Rename the userinterface package to standardiouserinterface 22

23 Interface: Step 2 Create a new package named: userinterface Create a new Java Interface type in the package: name it UserInterface. Create a new abstract method in UserInterface: name it update(). 23

24 Interface: Step 3 Make StandardIO.java implement UserInterface. 24

25 Interface: Step 4 Change types in Server, and invoke update in sendmessagetoui(). Generic user interface type 25

26 Interface: Step 5 Change types in UserCommandHandler, and invoke update. 26

27 Server Application Class Diagram After Adding User Interface <<Interface>> << TCP/IP network, Data >> Client << TCP/IP network, Connection Request >> ServerTest UserCommandHandler myui myserver handleusercommand Server Server startserver stopserver listen setdolisten stoplistening setport getport sendmessagetoui run * ClientConnection ClientConnection getclientsocket sendmessagetoclient disconnectclient stopthisthread run StandardIO mycommmandhandler setcommand getuserinput update run <<interface>> UserInterface update(string) ClientMessageHandler handleclientmessage(clientconnection, String) handleclientmessage(string) 27

28 Client Application Class Diagram After Adding User Interface <<Interface>> << TCP/IP network, Data >> Server << TCP/IP network, Connection Request >> ClientTest UserCommandHandler myui myclient handleusercommand Client Client connecttoserver disconnectfromserver sendmessagetoserver isconnected stopthread setport getport sendmessagetoui run Client User <<use cases>> GUI myusercommandhandler setcommandhandler update run <<interface>> UserInterface update(string) ServerMessageHandler handleservermessage() 28

29 Next Topic: Callback 29

30 A Callback method/function can be explained using a telephone system analogy. Bob calls Alice on a telephone, and asks her a question. Alice knows she needs to do a lot of research to find an answer and asks Bob if he can give her a callback number to call once she has found the answer to his question. The telephone call is then terminated. At some time later, when Alice has found an answer to Bob s question, she calls Bob s callback number and provides him with the answer to his question. In Java, Your code calls one of your methods Method A, which in turn calls some other heavy-weight code Method B to perform a task that may take a relatively long time to complete. Instead of waiting until the heavy-weight work has been completed, Method B is made to run as a concurrent thread, control is returned back to Method A immediately. Your code then continues with other tasks, with the understanding that when the heavy-weight work has been completed, the heavy-weight thread will call the callback method Method C to inform your code of its completion. 30

31 Example: The connectionestablished Callback Add a connectionestablished callback method to the Server class. Initially, the server software calls the startlisten method to allow client connections. The server software would also like to know if and when a client connects. Instead of waiting for a client connection, like we did in the single threaded server application, we arranged that the startlisten code starts a thread to listen for client connections, and returns immediately without any notification of a client connection request, and the server software proceeded to do other things, like interacting with the server user. Now, at some time later, a client may make a connection request, and the listen thread will accept it and then invoke the callback method to notify the server software that a client has connected. 31

32 Refactoring: adding the connectionestablished callback in Server Currently, the run method in the Server calls the sendmessagetoui method when a client makes a connection request: try { clientsocket = serversocket.accept(); sendmessagetoui("client connected: +clientinfo); It would be better object oriented design if the code invoked a specific callback method associated with the event: try { clientsocket = serversocket.accept(); connectionestablished(clientinfo); We would define the callback method, also contained in the server class to do the following: public void connectionestablished(clientinfo(string clientinfo) { sendmessagetoui( Client has connected: + clientinfo); } 32

33 Possible Server Callbacks serversocketstarted connectionestablished clientdisconnected clientexception serverstopped listeningexception serverstopped 33

34 Next Topic: Java Server Protocol The current protocol is too simple and not robust enough. For example, it is not clear when a command or message ends, i.e., there is no termination code. This limits to the commands communicated between the client and server to be each one byte long. In the future, there may be a need to have commands longer than one byte, and the current design would make adding longer commands not possible. For Instance: if (thecommand.equals("d")) { } else if (thecommand.equals("q")) { } else if (thecommand.equals("t")) { } 34

35 One solution is to terminate each message, either sent by the client or the server, with a termination code, which is not used in any message, like 0xFF. 0xFF is not a well used ASCII code, so it may be used in this application. Other termination code are possible, such as: 0x04, which is the ASCII code for end of transmission 35

36 Client Command String Sent to Server (each terminated by 0xFF) Server Interprets the Command as: Server Sends the Client the Ack/Response String (each terminated by 0xFF) q Quit Quit: /IP Address:port d Disconnect From Server Disconnect: /IP Address:port t Request the time The time is: HOUR:MIN:SEC L1on Switch LED1 ON L1on L2on Switch LED2 ON L2on L3on Switch LED3 ON L3on L4on Switch LED4 ON L4on L1off Switch LED1 OFF L1off L2off Switch LED2 OFF L2off L3off Switch LED3 OFF L3off L4off Switch LED4 OFF L4off gpb1 Return the state of PB 1 PB1<Down, Up> gpb2 Return the state of PB 2 PB2<Down, Up> 36

37 Client Disconnects from Server ServerUser Server Client ClientUser d d 0xFF Client Disconnected Disconnect Client Disconnect 0xFF Disconnect From Server Server Ack 37

38 Client Command: LED 1 On ServerUser Server Client ClientUser L1on L1on 0xFF Switch LED 1 On Led 1 On L1on 0xFF Server Ack 38

39 Client Command: PB1? ServerUser Server Client ClientUser gpb1 gpb1 0xFF Get Push Button State Push Button 1 Requested PB1<Down, Up> 0xFF Push Button 1 is Down/Up 39

40 Next Topic: Adding a User Command Concurrent Thread. First, Demonstrating the Problem (Example, StartServer): Getting Input From The User userinput = console.readline(); <<Command>> <<startserversocket>> User Currently, the time taken to process a server-user command may be relatively a long time: the user might notice and complain that the interface seems sluggish. For example, consider a server user selecting the Start Server command on the StandardIO interface. In response the software will temporarily stop getting input from the user and execute the command, through a sequence of method invocations, called a method trace. mycommandhandler.handleusercommand() Integer.parseInt(theCommand) myserver.startserver() myclient.clientsocket = new Socket() myui.update() Getting Input From The User userinput = console.readline(); User 40

41 Measuring actual time for the initial start Server Socket command was 20 ms on my desktop computer. 41

42 the Solution: Introduce a User Command Handler Concurrent Thread User Getting Input From the User Resume Getting Input From the User <<Command>> <<startserversocket>> mycommandhandler.handleusercommand() Start User Command Handler Thread(Command) User Start Thread A solution is to process the command in a different concurrent thread. In this way, the user interaction thread returns to interacting with the user sooner. User Command Handler Thread: Example start server socket Integer.parseInt(theCommand) myserver.startserver() myclient.clientsocket = new Socket() myui.update() Exit Thread 42

43 First modify the UserCommandHandler class to implement Runnable and add a run method to the class. Put the actual processing of the user command in the run method. Make a String usermessage instance variable. When invoked, the handleusercommand method sets the usermessage instance variable to the message string it receives as a parameter (i.e., the user command), and then it starts the executecommand thread. The handleusercommand method then returns to interacting with the user. Meanwhile, when run, the concurrent thread in the UserCommandHandler class (i.e., the run method) reads the string instance variable, and then processes the command as before. 43

44 Modified User Command Handler Class 44

45 the Problem Solved Measuring actual time for the initial start Server Socket command was now 0 ms on my desktop computer, compared to 20 ms without the concurrent thread. 45

46 Server Application Class Diagram After Adding User Command Handler Thread << TCP/IP network, Data >> Client << TCP/IP network, Connection Request >> ServerTest StandardIO UserCommandHandler myui myserver thecommand handleusercommand run Server Server startserver stopserver listen setdolisten stoplistening setport getport sendmessagetoui run * ClientConnection ClientConnection getclientsocket sendmessagetoclient disconnectclient stopthisthread run mycommmandhandler setcommand getuserinput update run <<interface>> UserInterface update(string) ClientMessageHandler handleclientmessage(clientconnection, String) handleclientmessage(string) 46

47 Client Application Class Diagram After Adding User Command Handler Thread << TCP/IP network, Data >> Server << TCP/IP network, Connection Request >> ClientTest UserCommandHandler myui myclient thecommand handleusercommand run Client Client connecttoserver disconnectfromserver sendmessagetoserver isconnected stopthread setport getport sendmessagetoui run Client User <<use cases>> GUI myusercommandhandler setcommandhandler update run <<interface>> UserInterface update(string) ServerMessageHandler handleservermessage() 47