Assignment 3 - Variant A

This is one of the possible choices for assignment 3.

The goal of this assignment is an exercise of implementing the Broker pattern in order to understand the role of Middleware for distributed object-oriented applications.

Deadlines: This assignment puts together 3 lab sessions (corresponding weeks 7,8 and 9). Results should be presented no later than week 10. Delays bring a penalty of 1 point for each weeek of delay after the deadline. Optional parts have an extended deadline - week 11. Extensions of this deadline only by individual request.

General grading policy: Grades reflect your individual knowledge and contribution. Each student must complete and present their own solutions. The solutions developed "in group" or copied will be assigned 0(zero) points. Not presenting the assignment is assigned 4 points.

Problem description

ToyOrb supports the development of distributed object oriented applications.

In the simplified ToyOrb model, the remote objects have operations with parameters and return types only int, float and String (no other objects). Also, it is outside the scope of this assignment to handle concurrent accesses to a remote object.

In order to show that your ToyORB implementation is working, develop with its help two different applications - InfoServer and MathServer. InfoServer offers operations get_road_info(int road_ID) and get_temp(string city). MathServer offers operations such as do_add(float a, float b) which returns the computed sum and do_sqr(float a) which returns the square root.

Detailed discussion of ToyORB: lecture notes of week 7 !

Support for network communication

You can use the code provided for transmitting bytes over a network connection. ( ByteCommunication.zip ). You can use this code as it is or freely modify it. Description of the ByteSender/ByteReceiver, ByteRequester/ByteReplyer APIs and examples of using them can be found at link with examples with ByteCommunication.

When you implement ToyORB you do not use other Middleware technologies for remote method invocation! (these are your ToyOrb's competitors ;-)

In order to see how the "competition" works, you can look at some small examples:

• a small example with JavaRMI link with JavaRMI example.
• a small example with WCF link with WCF example

The bibliography is mainly in Lecture notes of week 6 and week 7 see course web page. Additional reading: The Broker Revisited. link

Incremental requirements

Standard requirements and grading milestones

1. Minimal requirements (grade 5): Write a simple InfoClient - InfoServer application, directly over ByteSender-ByteReceiver or over Requestor/Replyer, using message communication between client and server. You can use the code given in Byte6Communication.zip
2. Client-Dispatcher-Server (grade 6): For the InfoClient-InfoServer above, add a NamingService (Dispatcher) which is able to locate a server by its name. The NamingService (Dispatcher) will be implemented as a server with a unique fixed address which is known to all participating clients and servers.
3. Writing clientside and serverside proxies (grade 8): for the InfoClient-InfoServer application developed as before, add clientside and serverside proxies. Proxies are implemented directly, you write their code.
4. Complete standard broker but with directly implemented proxies (grade 10): You implement the library providing the broker API to clients and servers. Make sure that your broker library does not depend on any application-speciffic code. Demonstrate the capabilities of your broker implementing a second application (MathServer-MathClient). You still may have the application developer implementing the proxies.

Advanced optional features (Bonus points)

• Solve the problem of proxies( 1 bonus point ): The application developer should not need to directly implement proxies. Only now ToyORB becomes a usable middleware for remote method invocation. You can choose any strategy to solve this:
  1. Proxy generator tool: Implement a proxy generator, which generates the source code of the proxy classes. The proxy generator talkes as input the interface of the remote server object, given either as source codeor as compiled code.
  2. Generic proxy on serverside: (partial solution only for serverside, combine with another method for clientside): use reflection to implement a serverside proxy whicj is a generic one workig for any type of server object.
  3. Dynamic generation of proxies: you can use mechanisms such as Dynamic Proxy in Java or emit in .NET
• Add a Server Activator ( 1 bonus point ): server objects get activated (start their serverside proxies) only when there is a client request, otherwise they are not active. The server object should not consume resources unless it is actively used by clients. The Activator acts similar with rmid from JavaRMI. More bibliography on Activator pattern: link Doug Schmidt Activator pattern lecture, link Activator article
• Implement in ToyORB support for a second programming language ( 2 bonus points ). You must be able to develop client-server applications using the second language, or applications where the client and the server are implemented in different languages. In order to achieve this, you will have to implement the ToyORB library in another language. Make sure that you implement the same protocol for data transmission at socket level. In this way you achieve interoperability with the first broker implementation. The NameServer will be able to be used by both broker implementations. Maybe you will need to define a neutral language (an Interface Description language) to describe remote server object interfaces, and then the proxies will be generated by IDLtoLanguageX tools. Similar with CORBA IDL and Android IDL.