Getting Agile

On Tuesday, I had the pleasure of presenting on Jini at the Seattle Java Users Group meeting. During the presentation I found myself speaking about the importance of mobile code in developing an SOA solution. Attempting to define SOA in an explicit way seems to be a daunting challenge. Most of the definitions that I come across tend to include web services as the building block of choice. I do agree that the use of web services at the edge of our LAN makes sense. When two entities have interest in sharing data between themselves, WSDL lends itself well to defining service contracts between those entities. Also, vendor and community support of web service standards increases it‘s value for such usage.

Inside the LAN, there are many other alternatives to web services which may improve our service-oriented environments. They can do this by increasing network performance through creation of smaller data sets to transfer, decreasing computational power needed to unmarshall the data sets, and mobile code in their support of mobile agents and smart proxies. There are many technology platforms which pose a viable alternative to web services on the LAN and meet some or all of the improvements mentioned. One of those technology platforms is Jini.

Jini by itself does not solve the problem but containers built on top of the Jini platform do. Containers remove some of the Jini programming complexity by handling codebase downloading and service deployment. Here are a few example containers:

• Rio - A dynamic services platform which involves a federation of container nodes onto which services are deployed. Upon deployment of a service, the platform identifies nodes which meet the service level agreement (SLA) declared in the Rio deployment descriptor called an operational string.
• Harvester - A container environment for Jini services and clients. A particularly interesting feature of Harvester is it's ability to load services and clients written in the Python language.
• Neon - An agent framework and application grid fabric which allows your Jini services to be deployed without writing all of the associated plumbing code. An good introduction to Neon's capabilities may be found here.

Mobile code is an important reason why Jini is a good alternative to web services on the LAN. Many Java developers are aware of RMI (remote method invocation) but have not heard of the Jini RMI impelementation called JERI (Jini extensible remote invocation). JERI provides important features over it‘s older counterpart: a pluggable transport layer with security support, an extensible marshalling layer, and runtime configuration. JERI provides the ability to export your service proxy for use by a remote service consumer. Your proxy class may be a “smart” proxy which means that some, if not all, invocation processing is performed using the consumer‘s resources.

A basic case for using a smart proxy is the calculation of tax versus gratuity. The process of calculating tax for an electronic order may include identification of local tax codes. The order itself may contain items with different tax calculations. Calculating the tax on an order lends itself better to server side processing. Gratuity, on the other hand, is based on a particular percentage of the order. At some restaurants I have seen a 15% gratuity either added to the bill because I was part of a large party or printed so that I don‘t have to calculate it myself. Calculating 15% on your order is quite simple and could easily be done on the client side. Here is some example code of what the service proxy may look like:

import java.rmi.Remote;
public class OrderProcessor implements IOrderProcessor {
private Remote remoteService = null;
public OrderProcessor(Remote remoteService) {
this.remoteService = remoteService;
}
public Money calculateTax(Order order) {
this.remoteService.calculateTax(order.getSubTotal());
}
public Money calculateGratuity(Order order) {
return new Money(order.getSubTotal() * 0.15f);
}
}

As you can see, only the calculateTax(Order) method invokes a remote service call. Not everyone will have this particular use case but I am sure that if we take another look at our service calls we will see similar scenarios. For instance, validation of input is another potential candidate for smart proxies. Before making the remote call you can validate that the data created by a user is correct. Some web application developers use a similar method by validating input using JavaScript in the client‘s web browser.

In conclusion, a strict definition of SOA as web services and XML messaging may blind us to supporting technologies. As we consume SODA (Service-Oriented Development of Applications) into our software development conscience we should keep in mind that service implementations may be achieved by other supportive technologies. Jini services may be exposed at the edge of the LAN through web services. For that matter, a web service may be exposed which could interact with multiple Jini services depending upon it's need. As Dan Creswell wrote in a comment on one of my previous posts:

Possibly the biggest thing that these companies have done is accept that one technology doesn‘t address all problems thus they‘ve stopped relying just on app servers and RDBMS or WebServices or JINI/JavaSpaces. Rather they knit them all together with well separated roles and responsibilities and keep everything behind interfaces…