jor: a java object router

JOR: A JAVA OBJECT ROUTER* Nader Mohamed, Amy Davis, Xin Liu, and Byrav Ramamurthy Department of Computer Science and Engineering University of Nebraska – Lincoln Lincoln, NE 68588-0115 {nmohamed|amydavis|xliu|byrav}@cse.unl.edu

Abstract Content-based routing has emerged as a new routing paradigm, allowing messages to be routed based on defined fields within the message. Content-based routers generally employ XML. Each message is translated into XML when sent, and translated out of XML when received. Further, XML limits the objects sent to documents and messages. We introduce here a contentbased router that goes beyond messages to routing entire Java objects. The Java Object Router (JOR) separates routing mechanisms from routing policies, making it easy to use in a variety of applications.

Key Words: Content-based router, object oriented systems, distributed workflow, middleware.

1 Introduction Content-Based routing has proven to be not merely an interesting research topic, but a useful business paradigm. Countless implementations of XML routers have appeared in the past several years. This new class of addressing messages for transport has proven a challenge for network designers and given rise to a new class of software – middleware. To date, most middleware has been concerned with the routing of messages. Contentbased routing has gained strong ground by allowing documents to be communicated between computers – even with disparate software. Additionally, mobile objects have used systems of messages to route one document through several destinations. Here, we extend the idea of routing messages transparently between computers to routing entire objects transparently. We provide a Java implementation, the Java Object Router (JOR), as a proof of concept for content-based routing of objects, separation of mechanism and policy, and routing transparency at the application level.

*

This work was supported in part by NSF grant EPS-0091900.

JOR is an application-level router that will route Java objects from one Java application to another over a TCP/IP network. Because JOR is flexible and robust, it allows users to route objects based on header fields (like source and destination IP addresses, or a label), or on content (like type of object being sent or some property of the object). JOR separates the routing mechanism from routing policy, allowing the user to implement a variety of policies without changing JOR itself by using a configuration class. Inside JOR resides Weighted Fair Queuing (WFQ) scheduling, which allows the user to make tight guarantees on the Quality of Service (QoS) that JOR will provide. Finally, JOR works with any Java client-server program by allowing any type of Java object to be transmitted. This paper first discusses the related work and motivation in Section 2. Section 3 then describes the design and implementation of JOR. An application for JOR is described in Section 4 to demonstrate its ease of use, followed by a simple demonstration of the performance of JOR in Section 5. Finally, Section 6 discusses our results and conclusions.

2 Related Work Applications that take advantage of content-based addressing and routing are many. We will discuss here two of the most prominent – namely, event notification services and mobile objects. Examples of event notification services include Elvin [1], iBus [2], SIENA [3][4], DVE [5], TIB/Rendezvous [6], Xblaster [7] as well as implementations of specifications such as the CORBA Event Service [8], the CORBA Notification Service [9], and the Java Distributed Event Specification [10]. XML has arisen as a popular method for routing messages – the messages are coded into XML, and routed via an XML content-based router. In such systems, both the router and the end user, or server program, understand the XML tags. They must not only behave correctly based

on the XML tags, but must know how to write the XML tags that will convey the proper message to the recipient. By coding an XML router, the processes of sending and receiving can be made slightly more transparent to the end user. In particular, with the proper set of tags, an XML router can send a document to any number of different places depending on various properties in the message – not just the specified destination address. Such a service provides the groundwork for content based routing, and can be implemented in a number of ways (as we see from the variety of implementations above). A second application becoming more popular for contentbased routing is that of mobile objects. These mobile objects are often used for business document transfer, and business communication. Microsoft's BizTalk [11] leads the show here by providing a pre-defined and domain specific set of XML tags for various sets of documents. Both the client and the server translate their documents into this XML for sending, and back from the XML for receiving. Like CORBA, these business applications allow translation between formats and machines. Because of this, every language must conform to the particular XML tags before sending data. JOR avoids this pitfall while maintaining portability by using Java for implementation, which can run on any Java Virtual Machine. Using JOR, business applications could easily be written to contain the proper documents, and be encoded and decoded between any number of individuals and companies for review and approval. Sundsted [12] demonstrated how to modify the Java Messaging Service (JMS) to support routing of Java Objects by properties other than the address – that is, by content. It uses an XML message format to encode messages so that a router written in Java can parse those same messages to determine the proper destination of the message. Inside the router are coded rules that specify where particular information must go. A router rule is composed of XML tags to look for, and a destination specifying where the document goes depending on the tags found. Because both the object sent and the router are written in Java, the conversion to and parsing from XML is an added step. While the purpose of the JMS [12] is to route messages, we note that if the conversion to XML were avoided, entire objects could be received, and sent on by the router. Thus, the router is extended from routing messages to routing objects, and improved by avoiding the conversion to and from XML. Finally, using very similar code rules, we have the same (and greater) ability to route based on the content of an object. In particular, we have the ability to execute code in the object at any router, creating a mobile code environment. This is similar to the functionality of Java RMI [13], which was introduced in Java to hide the communication details and provide the developer with a remote method

invocation interface. RMI allows applications to locate and to communicate with remote objects, and to load class bytecodes for objects that are passed around. Some available RMI systems can be adapted to handle Java objects, but they do not provide seamless integration with the Java system. One of the central and unique features of RMI is its ability to download the bytecodes of an object's class if the class is not defined in the receiver's virtual machine. RMI passes objects by their true type, so the behavior of those objects is not changed when they are sent to another virtual machine. This allows new types to be introduced into a remote virtual machine, thus extending the behavior of an application dynamically. RMI was built to support distributed applications, but it does not provide a routing mechanism. We extend the concept of content-based routing to include any Java object seamlessly, and the ability to route based on any method or field in that Java object. Additionally, we provide a generic routing tool that contains all mechanisms necessary to route any Java object based on any property of that object. Because we provide the underlying routing mechanism, declaration of a routing policy becomes a simple and straightforward exercise. Therefore, we provide flexibility in JOR to support a number of different applications with minimal changes to the actual code. Unlike other content-based routers, all objects that enter JOR need not be defined. “Default” and “specific” type handlers can obviously be defined and applied. We present a technique for separating the mechanisms that actually perform the routing of an object and the routing policies for any application. JOR provides routing for any type of Java object, performing the many steps involved in Java RMI. Depending on the configuration class, JOR has the capability to route based on address, priority, content, or any other property of a Java object. Therefore, this tool is flexible enough for any application, and easily configurable by Java users.

3 Design and Implementation The design goal of JOR is to provide a flexible tool to separate the mechanism of object routing from policies of that routing. JOR supplies the mechanism to route objects and a configuration class that allows the user to implement policies specific to their needs. The general functionality of JOR is merely to accept objects, perhaps operate on them, or invoke a function from them, and send them out to the appropriate destination. Therefore, it sports a very simple architecture, as shown in Figure 1. JOR is implemented as a set of modular components (classes), which provide interfaces to the other components. The components will be briefly discussed below, with implications for the programmer using JOR.

3.3 Configuration

Config

Receive

Queue

Dispatch

Figure 1: Architecture of JOR.

3.1 JOR Receiver and Sender The JOR receiver and sender components behave as follows. Like any XML router, JOR can receive messages, and send them to the appropriate destination(s). Unlike any XML router, JOR permits any Java object, not just documents, to be routed. In order to send an object to JOR, the sending application uses Java serialization to transform the object into a bit stream, and sends it to the JOR router. It is only required that the sending application know the address of the JOR router – the router can be configured to detect the proper destination based on the object itself. JOR can be set up to allow an arbitrary number of incoming and outgoing threads. Each object, when entering the JOR router, is wrapped in an objectPacket (alternatively, the sending application may pre-wrap an object in the objectPacket for JOR). This objectPacket includes fields for the source and destination addresses, labels, priorities, and information on the enclosed object (its type and length, for example). Specific methods to execute at the arrival or departure of any message can also be defined by using inMethod and outMethod routines (see Section 3.3).

3.2 JOR Queue The JOR queue enqueues objects based on their destination class and on their priority. The destination class dictates to which queue the object goes, and the priority dictates where in the queue the object goes. Weighted Fair Queuing is employed, with the specific configuration supplied by the configuration class. Each queue is statically created at start time (unlike standard WFQ), and assigned a weight w, where w specifies the portion of the total bandwidth allotted to this queue. All queues in JOR are maintained in a sorted order, so that the packet at the head of the queue is the packet with the highest priority. While this is a deviation from standard WFQ, it allows JOR to give higher priority to some objects based on the configuration class. If all objects have the same priority, the queue is FIFO. The dispatcher calls an object from the queue with a dequeue method, and performs any exiting routines before sending the object to its destination.

Because JOR separates the routing mechanism from routing policies, it is completely customizable and configurable by the user. This configuration is performed in a configuration class (called CFG). This class can contain anything from the simplest logic (defining defaults), to complex functions and method invocation. Table 1 shows the possible areas to customize. Each of the error handlers and default functions come preconfigured in JOR, but any user may define their own, overriding default behaviors. Additionally, each running instance of JOR may be associated with specific configuration classes, allowing different JOR programs, performing different tasks, to run simultaneously. Through use of this configuration class, users have no reason to care about the actual implementation or mechanics of sending objects – they merely define the policies they wish to apply, and JOR does the rest. event Initialization

Object entrance

Object exit

Exception handlers fullBuffer noDestinationIP deliveryError default

customizable actions number of listening and sending threads listening ports number of queues max number of delivery attempts default inMethod default priority default destination IP address object specific inMethod source IP specific inMethod label specific inMethod label specific outMethod destination IP specific outMethod object specific outMethod default outgoing priority default outMethod

default = taildrop default = drop default = retry maxAttempts times, then drop configure to handle other exceptions

Table 1: Configurable features of JOR.

4 Applications The JOR router can either reside on one of the machines executing the distributed application or on a dedicated machine. Distributed applications can use one JOR or a network of JORs for their object routing needs (see Figure 2). The strength of JOR lies in the many applications that can use it. Because JOR is modular, it is capable of providing a variety of distinct services to the user based on the logic stored in the configuration class. Therefore, any user of this product can implement their application policies with limited programming. In Section 4.1, we discuss a simple example application, and in Section 4.2 we discuss an extended application. We show the performance of JOR in Section 5.

Application 1

Application 2 JOR1

JOR2 Application 3

Application 4

Figure 2: Network of JORs.

4.1 A Simple application: Fault-tolerant server pool The configuration of JOR to provide load balancing or fault tolerance is discussed below. For example, JOR can be configured to maintain a server pool. Each time a user object arrives, JOR gets a server from the server scheduler and forwards the object to that server. When a new server starts, it sends JOR a “newserver” object packet. Then JOR invokes a registration handler to add a server entry into the server pool. If the server is unable to receive the packet, it removes the corresponding server entry. This application is shown conceptually in Figure 3. In the configuration file, the user needs to use the routing mechanism provided by JOR to implement the routing policy as well as implement logic for both registration handler and server scheduler. Since all routing mechanisms are provided by JOR, the user can concentrate on implementing the logic and policy of routing objects for the network applications.

provided by the student (see Figure 4). This object needs to be transferred among Java applications belonging to different departments within the university during the application process. A graduate application needs to be checked and approved by many departments (such as graduate studies office, international affairs, and academic departments). Additionally, some information may be requested of the student during the admission process. The application needs to pass through approval steps starting from graduate office initial checking, academic department acceptance, and finally international affairs office for financial checking and approval for international student applications (see Figure 5). // Graduate Application Class class GraduateApplication implements Serializable { // form fields String socialSecurity; String birthdate; String lastName; . . . . // internal use fields boolean newApplication = true boolean submittedCompletePapers = false; boolean departmentReview = false; // messages between departments and student String messageFromDepartment; String messageFromGraduateStudent …….. }

Figure 4: Graduate Admission Application Class.

Server registration Configuration registration handler

Email Requesting More Info.

Student Application

server 1

Graduate On-line Application Servlet

Accept/Reject Letter

E-mail Gateway

Application Object server 2

JOR

server scheduler server 3

Graduate Study System

International Affairs System

JOR

error handler Deliver user packet

Figure 3: Using JOR for load balancing and fault tolerance.

CS Department

Math Department

…

EE Department

Figure 5: JOR routes Java objects among distributed Java applications.

4.2 Graduate student application process: A mobile objects application

There are two ways to implement the communication and routing processes for the application object among different systems:

To demonstrate the flexibility, scalability, and ease-of-use of the JOR system, an example is given here regarding graduate student admission process. Students can apply on-line for graduate studies through the web. The web application form contains a servlet that creates a graduate admission Java object that contains all information

1. Let the distributed applications communicate directly and implement the routing policy within all applications. 2. Use a content-based routing such as JOR to implement routing policies (see Figure 6).

The advantage of the first solution is avoiding a singlepoint of failure. However, there are many disadvantages such as: 1. It is difficult to add QoS policies. 2. Routing policies are scattered among different applications; therefore, managing and maintaining these policies is a complex task. 3. Changing the routing policies may involve changing one or more distributed applications, which may require access to the source code for the applications. Receive Graduate Application Object

Yes

No Send the object to graduate studies

No

No

New application?

Grad. Office accepted the application?

Send the object to email gateway to send reject e-mail

Yes

Some paper needed?

Yes

No

Send the object to international affairs

No

Send the object to proper department Yes

International student?

No

Yes Send the object to graduate studies

International affairs checked the application? No

Send the object to email gateway

Department reviewed the application?

Department accepted the application?

Send the object to graduate studies to issue rejected letter

Yes

Yes

Send the object to graduate studies to issue accepting letter

Figure 6: Routing Policy for a Graduate Admission Application Object. .

The advantages of using the second solution are: 1.

There is a well-defined separation between the routing policies and the routing mechanism. As a result, changing the routing policies is an easy task. All changes can be done in JOR setup only.

2. 3.

4.

It is easy to add QoS to the routing policies. There is no need for having or changing the source codes of the distributed applications to change the routing policies. It is easy to add new functions to the distributed application because JOR can be used as a class format converter between distributed applications.

Using JOR, the routing policies of the graduate admission application are easily defined. The JOR setup (defined in Figure 7) implements the routing policies of the object among distributed applications. The user can easily define destination address based on the object contents. In addition, other setup can be defined, such as object processing priority and error handlers.

/Graduate Admission Application Routing Policy class setup extends CFG { public static void setup() { setPort(8000); // set JOR port //set number and priority of receiver threads receiverThreads(2,10); //set number and priority of dispatcher threads dispatcherThreads(2,10); } // graduate application object routing policy public static void in_GraduateApplication(objectPacket op) { GraduateApplication ga; ga=(GraduateApplication)op.userObject; If( ga.newApplication ) op.setAddress(GradOfficeIP,GradOfficePort ); else if( !ga.submittedCompletePapers ) op.setAddress(EmailGateIP,EmailGatePort); else if( !ga.GradOfficeAcceptance ) op.setAddress(EmailGateIP,EmailGatePort); else if( !ga.departmentReview ) {switch( ga.degreeMajorSoughtCode ) { case 1: op.setAddress(CSEDIP,CSEDPort); case 2: op.setAddress(MATHIP,MATHDPort); …

Figure 7: Part of Graduate admission application object routing policy setup.

5 Performance Three small benchmark programs were written to evaluate the performance of JOR. The experiments were conducted on two Dual 1.2 GHz AMD-processor machines, with 256 KB cache per processor and 1 GB RAM per node. The nodes were connected via a 100 Mbps Ethernet. For these experiments, the standard JVM version SDK 1.4 was used. To measure the JOR performance, the client and server ran on the same machine while JOR ran on another machine. The experiments were designed to measure JOR routing delay with different types and sizes

of objects. Three different types of object have been used, as shown in Table 2. In general, this overhead is acceptable given the high benefit of using JOR to facilitate routing among distributed applications. Object Type

Size (bytes)

84 739

Total transport time (ms) 1 2

Routing overhead time (ms)