Network speed has improved tremendously over the years and has revolutionized enterprise computing, but even with today's network infrastructure sending messages across a network is of several orders slower than sending messages locally. The latency caused by the network is a function of the size of the messages and the number of round trips. The delay due to message size is more or less constant as long as the data size stays within the size of the buffer transmission but cutting down the network crossings could have a more significant and direct impact. In light of these considerations, this article proposes the design and implementation of a framework, using core Java principles like Reflection, Dynamic Proxies, Byte Code Engineering, Java Beans, and Thread Local, to club multiple network calls and have them execute at the server in one go.

Objective
In an Enterprise Computing model multiple users access applications and data stored on servers scattered across many locations. The applications offer low-level data in the form of services. But often, the user really needs a more consolidated and unified view rather than the low-level view these services offer. The Session Façade pattern helps by logically grouping services keeping in mind the business needs of the user. In doing so the façade serves two other purposes:

• It precludes the clients from having to access the fine-grained remote interfaces thus reducing network traffic and latency.
• It also decouples lower-level business components from one another allowing them to be conceived and built independently, making designs more flexible and comprehensible.

Thus the façade helps in getting over some of the limitations of network speed but, since it's tied to the user's requirements, as more and more users start using the applications, more and more facades have to be added. While this may sound simple, it often runs into the following impediments:

• Maintainability issues due to uncontrolled growth in the number of views
• Delays and disruptions of service for existing clients while incorporating new changes
• Departmental politics may lead to some facades being preferred over others

In such a scenario it would be useful to have a framework that would help clients define, develop, and deploy their facades and have them execute on the server.

Approach
The semantics of the Java language don't support clubbing network calls into batches so we are proposing a framework that imposes certain minimal but non-intrusive changes in the regular style of programming to help overcome the limitation.

The basic idea includes:

• Demarcating batch (façade) boundaries through a start and end call
• Objects used in the façade need to be batch-aware, i.e., object behavior is dependent on whether or not it's executing in a batch
• Delaying object state changes by postponing the execution of the code till the end of the batch
• A new framework bean to comprehend and service such requests is needed

Implementation
Overview

1. The client signals the start of the batch process by a call to begin the method of BatchContext. The call changes the state of the current thread by binding the BatchContext to a ThreadLocal variable.
2. Objects modulate their behavior based on the availability/unavailability of the BatchContext in the current thread context. Unavailability triggers the usual behavior as programmed. On the other hand, availability results in:
   a.  An addition to the Participating-Objects list - All the objects created in the batch boundary are added to the list of participating objects and indexed (indexing helps reduce the final cost of serialization). Similarly, calls to methods with a non-void return type results in instantiation and initialization of the returned object by a no-argument constructor. The returned object is added to this participating objects list. The call execution doesn't result in any state changes.
   b.  The serialization of invocation - The serialized instruction is stacked in the InvocationHistory object bound to the BatchContext. Different types of invocation objects exist for the lookup instruction (LookupHomeInvocation), remote object creation (CreateRemoteInvocation), remote method invocation (RemoteMethodInvocation), instance method invocations (MethodInvocation), and constructor invocations (ConstructorInvocation). The invocation object maintains a reference, via an index, to the object invoked, the arguments passed, and the object returned besides information about the method invoked, i.e., method name.
3. Use of ServiceLocator pattern for looking up the EJBs. The ServiceLocator acts as a batch-aware class; it registers the client's intent to do a lookup while the actual lookup happens later along with other network calls. The ServiceLocator is described in greater detail in the following sections.
4. The client then signals the end of the batch process. This is done by a call to the end method of the BatchContext class. The call results in the entire list of objects and the instructions being submitted to the server. The results of the entire sequence are processed and returned together as one call.

Details
The following section describes in detail the internals of a batch call.

1. Batch begin - The events accompanying a batch begin call are shown in Figure 1.
2. Initialization of a Data Object in the batch call - The object is simply added to the list of Participating Objects. The conditional behavior of the service class's construction isn't the default behavior as programmed by the developer; instead it's injected post-build time through bytecode manipulation and is discussed in the components section later.
3. Looking up an EJB using the modified ServiceLocator - In the batch mode the ServiceLocator would add a LookupHomeInvocation instruction and return a DynamicProxy implementation of the EJBHome and Home Interface as the home proxy. Returning a proxy implementation helps us trap and handle invocations to the home and remote interfaces.
4. Calls on the Home interface - The home proxy (through it handler, EJBHomeHandler) in turn, on a create call on home proxy, adds a CreateRemoteInvocation instruction and returns a DynamicProxy implementation of the EJBObject and the Remote Interface as the remote proxy.
5. Calls on the Remote interface - Calls on the remote proxy (through its handler, EJBRemoteHandler) translate to a RemoteMethodInvocation instruction and the return of a dummy instance of the relevant return type.
6. Call to the end method of the BatchContext class - This call results in the entire list of objects and the instructions being submitted to the server. The server runs through the instructions sequentially and executes them. In the process it alters the state of the objects participating in the batch. The altered state is returned to the client where the original references are used to modify the client-side object states using accessor methods to reflect the new states. The lack of pointers restricts the return types to mutable types. Apache Commons BeanUtils libraries are used to facilitate copying the states.

• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Source Code