Broker in practice Middleware Tool for generating the

Broker in practice: Middleware Tool for generating the Proxies Library(API)+ Executable Application Developer

Exercise • Implement a very simple Toy-Object. Request. Broker – We provide implementations of Byte. Sender/Receiver and Requester/Replyer) • Download Byte. Communication. zip from the course webpage and try out the examples ! – Example 1: Server. With. SR, Client. With. SR – Example 2: Server. With. RR, Client. With. RR – Your implementation must not use other middleware technologies (they are your competitors ) – See Assignment 3 lab: http: //staff. cs. upt. ro/~ioana/arhit/2017/t 3. html

Toy. ORB - Requirements • The goal of Toy. ORB is to support the developers of distributed applications (similar with his real-world “competitors” such as Java RMI) • Toy. ORB will come as: – A library for the application developer, that will be used by the client and server of the application (similar java. Remote) – A daemon executable, the Naming Service, needed to deploy and run applications developed over Toy. ORB (similar rmiregistry). It can be implemented using the communication mechanisms provided in Byte. Communication – Optional, it includes tools or implements other methods such that the proxies are not written by the application developer

Using Toy. ORB for developing distributed applications 1. Define interface of remote object INTERFACE Stock. Market 5. Implement Client float get_price(Company) 2. Implement object 4. Implement Server Stock. Market. Client 3. Generate Proxy / Write it “by hand” Stock. Market Client. Side PROXY Stock. Market. Impl 6. Run application Broker 3. Generate Proxy/ write it “by hand” in the simple ve Stock. Market Server. Side PROXY

Toy. ORB - Requirements(2) • Toy. ORB will be used to develop distributed applications such as the Stock. Market application • The source code of Stock. Market developed over Toy. ORB, contains: – – – Interface of remote object, Stock. Market. java Implementation of remote object, Stock. Market. Impl. java Implementation of the client program, Stock. Market. Client, java Implementation of the server program, Stock. Market. Server. java Implementation of Stock. Market. Client. Side. Proxy. java (* in the standard requirements, this class is written by hand; in the optional version, you have to do something such that it is not written by hand any more) – Implementation of Stock. Market. Server. Side. Proxy. java (* in the standard requirements, this class is written by hand; in the optional version, you have to do something such that it is not written by hand any more)

Toy. ORB - Step 1. Define interface • Define interface Stock. Market, as a normal interface • This exports the operation get_price: public interface Stock. Market { float get_price (String Company) } – Parameter: the name of the company – Result: price File Stock. Market. java

Toy. ORB - Step 2. Implement Object • Implement class Stock. Market. Impl (a plain old java class) • It contains the implementation of operation get_price public class Stock. Market. Impl implements Stock. Market { public Stock. Market. Impl() {} public float get_price(String company) { float price=12345; return price; } } File Stock. Market. Impl. java

Toy. ORB - Step 4. Implement Server • Implement the program Stock. Market. Server, which creates the remote object Stock. Market • The createde object is registred with name “NASDAQ” import toy. ORB. *; public class Stock. Market. Server { public static void main(String[] args) { Stock. Market. Impl stock. Market. Impl = new Stock. Market. Impl(); Specific Toy. ORB: • Toy. ORB. register: • The Stock. Market object is registered with the Naming Service under name “Nasdaq”, • Assigns a port number for the server to listen • Creates the serverside proxy instance and invokes its start method • Toy. ORB. register("NASDAQ", stock. Market. Impl ); }} }} File Stock. Market. Server. java

Toy. ORB - Step 5. Implement Client • Implement the program Stock. Market. Client, which accesses the remote object Stock. Market, and invokes the operation get_price for a company name companie • Prin intermediul Broker se Specific Toy. ORB: localizeaza obiectul cu numele • Toy. ORB. get. Object. Reference “NASDAQ” • Interrogates the Naming service for the server address • Returns a reference (an instance of client side proxy) to the server object that has been registered as “Nasdaq” import toy. ORB. *; public class Stock. Market. Client { public static void main(String[] args) { Stock. Market market= (Stock. Market) Toy. ORB. get. Object. Ref("NASDAQ"); float price=market. get_price("ABC SRL"); System. out. println("Price is "+price); } File Stock. Market. Client. java

Toy. ORB - Step 3. Version 0: Writing the proxies by hand The standard requirements: write the classes: Stock. Market. Client. Side. Proxy. java Stock. Market. SErver. Side. Proxy. java The implementation can use the support provided in Byte. Communication (Requester-Replyer)

Toy. ORB – To Do Checklist for the Stock. Market application: • Source code to be written by the application developer Stockmarket: – Stock. Market. java, Stock. Market. Impl. java, Stock. Market. Server. java, Stock. Market. Client. java – (**) Stock. Market. Client. Side. Proxy. java, Stock. Market. Server. Side. Proxy. java • Deployment Server: • Stock. Market. class, Stock. Market. Impl. class, Stock. Market. Server. Side. Proxy. class, Stock. Market. Server. class • Deployment Client: • Stock. Market. class, Stock. Market. Client. Side. Proxy. class, Stock. Market. Client. class

Toy. ORB - Step 6. Run the application > start Toy. ORBNaming. Service > start java Stock. Market. Server > java Stock. Market. Client

Toy. ORB: Variant using Forwarder-Receiver 2 different communication channels, one for transmitting requests parameters, and one for receiving the result deliver ( marshal ( “ABC SRL” ) unmarshal ) receive Stock. Market Client. Proxy F R R receive ( unmarshal ( 1234. 5 ) marshal ) deliver Disadvantage The F-R pattern assumes that the participants are equal peers => clients must register as well) Toy. ORB Naming. Service Config. db “Stock. Market. Client”: IP, Port “NASDAQ”: IP, Port F Stock. Market Server. Proxy

Toy. ORB: Variant using Requester-Replyer Stock. Market Client. Proxy Marshaller Stock. Market Server. Proxy Marshaller deliver_and_wait_feedback Requester receive_transform_and_send_feedback Replyer Toy. ORB Naming. Service deliver_and_wait_feedback: delivers the request followed by receiving the result over the same communication channel (socket) Config. db “NASDAQ”: IP, Port receive_transform_and_ send_feedback: receives the request followed by sending the result over the same communication channel

Toy. ORB: Implementation of Proxies send_request Stock. Market. Client. Side. Proxy: • • • Uses a Requestor r Uses a Marshaller m Operation get_price: pack_data – By using m – marshal, transforms the input parameters (company name) in a sequence of bytes forward_ – By using r deliver_and_wait_feedback, transmits request to Server. Side. Proxy the sequence of bytes representing the request and receives a sequence of bytes representing the result unpack_data – By usingi m - unmarshal, transforms the received sequence of bytes into the value of the result (the price) red italics text identifies the operations with their names in the Broker pattern descr. call_service Stock. Market. Server. Side. Proxy: Uses a Replyer r • Has a reference to Stock. Market. Impl s • Uses a Transformer t : receives a sequence of bytes and returns the transformed sequence of bytes • Operation get_price : While (true) r. receive_transform_and_send_feedback(t(s)); – Receives a sequence of bytes representing the request and parameters, t(s) transforms forward_ it into a sequence of bytes containing the response result, that will be sent back to the client. Server. Transformer: • • Uses a Marshaller m In order to do the transformation: – By using m – unmarshal, extracts the input unpack_data parameters (company name) – Calls operation on Stock. Market. Impl s and obtains the result run_service – By using m - marshal, transforms the result pack_data (price) in sequence of bytes

Toy. ORB: support for more complex servers • • A remote interface could be more complex (contain several operations). Example: public interface Complex. Stock. Market { float get_price (String Company); String whois_highest_today(); String whois_lowest_today(); } Example client code: Complex. Stock. Market obj. Ref=(Complex. Stock. Market) Toy. ORB. get. Object. Reference(“NASDAQ”); float price=obj. Ref. get_price(“ABC SRL”); String junk=obj. Ref. whois_lowest_today(); The Client. Side. Proxy tmust marshal alsp some information describing which operation has been requested s-a cerut. The Server. Side. Proxy will unmarshall also the operation name

Toy. ORB: Must not depend on applications ! • Toy. ORB should be used to develop any type of application (Stock. Market, Complex. Stock. Market, Info. Server, Math. Server, etc ) • Types of applications are unknown when developing Toy. Orb ! • Toy. ORB must be totally independent of anything application specific ! – Marshaller: must be able to transform any combination of parameters – Toy. ORB. get. Object. Reference(String Server. Name) must be able to instantiate and return a client side proxy object for any application (Stock. Market. Client. Side. Proxy, Math. Server. Client. Side. Proxy, Info. Server. Client. Side. Proxy, etc), but without depending on these applications ! • Possible solution: use Reflection to instantiate proxy object

Scenario for locating servers Toy. ORB. get. Object. Reference(“NASDAQ”); Stock. Market. Impl NASDAQ Stock. Market. Client 1 Stock. Market. Client 2 Stock. Market. Impl NIKKEI Toy. ORB. get. Object. Reference(Stock. Market); Toy. ORB. get. Object. Reference(“Timis. Info”) Info. Client 1 Info. Server. Impl Timis. Info

Scenario for locating servers Stock. Market. Impl NASDAQ Stock. Market. Client 1 Stock. Market. Impl NIKKEI Stock. Market. Client 2 Info. Client 1 Naming. Service Address 127. 0. 0. 1, 1111 Naming. Service NASDAQ, Stock. Market, 127. 0. 0. 1, 1112 NIKKEI, Stock. Market, 127. 0. 0. 1, 1113 Timis. Info, Info. Server, 127. 001, 1114 Info. Server. Impl Timis. Info

Usage scenario: Register Server Stock. Market. Impl NASDAQ Toy. ORB. register t Requester arke k. M c to S pe 2 y Naming. Service Address t of , 111 127. 0. 0. 1, 1111 AQ. 0. 1 D AS 27. 0 N er ss 1 t s gi dre e r Replyer ad t A Naming. Service NASDAQ, Stock. Market, 127. 0. 0. 1, 1112

Usage scenario: Server ready Stock. Market. Impl NASDAQ Stock. Market. Client 1 Stock. Market. Server. Proxy Replyer Naming. Service Address 127. 0. 0. 1, 1111 Replyer Naming. Service NASDAQ, Stock. Market, 127. 0. 0. 1, 1112

Usage scenario: get. Object. Reference Stock. Market. Impl NASDAQ Stock. Market. Client 1 Stock. Market. Server. Proxy Replyer Toy. ORB. get. Object. Ref Requester Adr esa 111 2 NA SD AQ ? Naming. Service Address 127. 0. 0. 1, 1111 Replyer Naming. Service NASDAQ, Stock. Market, 127. 0. 0. 1, 1112

Usage scenario: reference obtained Stock. Market. Impl NASDAQ Stock. Market. Client 1 Stock. Market. Server. Proxy Stock. Market. Client. Proxy Replyer Requester Naming. Service Address 127. 0. 0. 1, 1111 Replyer Naming. Service NASDAQ, Stock. Market, 127. 0. 0. 1, 1112

Toy. ORB: Implement Naming. Service • Naming. Service with complex functionality(Trader): – Locates remote object after its name (“NASDAQ”) – Locates remote object after the description of the service (Stock. Market) -> retrieves a reference to one of the remote objects implementing this service • Implementation of Naming. Service: as a server listening at an address which is known by Toy. ORB – Toy. ORB: get. Object. Reference – Toy. ORB: register Interactions with the Naming. Service using Requester-Replyer

Making Toy. ORB more realistic • An Object Request Broker is an infrastructure for distributed applications • It must be usable in many different applications which are totally unknown to the developer of the broker infrastructure ! • Consequences: – It is essential that the ORB has no dependencies to any application specific code – To have a real “usability”, the Broker should support the application developer with generating the code of the proxies • Tools for the automatic generation of proxies

Toy. ORB: Automatic generation of proxies • Starting point: write manually the proxies for 2 different applications in order to identify their common “template”

Toy. ORB: Implementation of Proxies send_request Stock. Market. Client. Side. Proxy: • • • Uses a Requestor r Uses a Marshaller m Operation get_price: pack_data – By using m – marshal, transforms the input parameters (company name) in a sequence of bytes forward_ – By using r deliver_and_wait_feedback, transmits request to Server. Side. Proxy the sequence of bytes representing the request and receives a sequence of bytes representing the result unpack_data – By usingi m - unmarshal, transforms the received sequence of bytes into the value of the result (the price) call_service Stock. Market. Server. Side. Proxy: Uses a Replyer r • Has a reference to Stock. Market. Impl s • Uses a Transformer t : receives a sequence of bytes and returns the transformed sequence of bytes • Operation get_price : While (true) r. receive_transform_and_send_feedback(t(s)); – Receives a sequence of bytes representing the request and parameters, t(s) transforms forward_ it into a sequence of bytes containing the response result, that will be sent back to the client. Server. Transformer: • • Uses a Marshaller m In order to do the transformation: – By using m – unmarshal, extracts the input unpack_data parameters (company name) – Calls operation on Stock. Market. Impl s and obtains the result run_service – By using m - marshal, transforms the result pack_data (price) in sequence of bytes

Toy. ORB: implementation template for Client Side Proxy • Let be a remote server with interface Service. X • Service. XClient. Side. Proxy: – Class Service. XClient. Side. Proxy implements Service. X – Each operation defined in interface Service. X is implemented in following way: • Create message (marshal): operation name, (number and types of paramers), parameter values • Deliver_and_wait_feedback • Extracts from the received message the value of the result (unmarshall) and returns it

Toy. ORB: Generate Client Side Proxy – Service. XClient. Side. Proxy is a class implementing interface Service. X, thus it depends on the application! – In order to generate the Client Side Proxy: • Possibility 1 (general applicable): the type Service. X is known at design time, the code for Service. XClient. Side. Proxy is generated at application design time with help of a tool and is installed at the client side (Example: CORBA, RMI in java < 1. 5) – The generation tool takes as input the description of interface Service. X and generates source code that must be compiled • Possibility 2 (for technologies that support runtime code generation dynamic proxy): the code of the class Service. XClient. Side. Proxy is automatically generated at runtime (no tools that must be used by the developer at design time), (Example: RMI in java >1. 5 and. NET Remoting)

Toy. ORB: Template for Server Side Proxy • Suppose a remote server with interface Service. X • Service. XServer. Side. Proxy: – Class Service. XServer. Side. Proxy: • Has a reference to original server object Server. XImpl • Contains the “server-loop” (while (true) receive_transform_sendfeedback) – Class Service. XServer. Transformer implements Server. Transformer • Gets reference to original server object Server. XImpl • Extracts from the message (unmarshals) the name of the operation and parameter values • Invokes the operation on the original server object – Possibility 1: code contains a “switch-case” (Java 1. 1, CORBA) – Possibility 2: uses Reflection -> eliminates dependency on Service. X -> becomes a generic Server. Side. Proxy (Java 1. 2, . NET) • Creates the answer message(marshal) containing the result