A recent client runs a large distributed system that processes global data in near real-time. Because of high data volumes, the architecture requires that each host (physical or virtual) be allocated to one or more geographic regions. Geographic data is maintained in memory and this architecture allows the system to easily scale without exceeding the physical memory of each host. I was asked to prototype a light weight services framework that would route each service request to an appropriate host. In this case, the client was also interested in using plain old RMI for remote invocation.

The general approach is to assign servers based on some domain-specific criteria. For example, if geographic data can be associated to a Region ID, then we can assign hosts to Regions. This is generally a many-to-many relationship as each host can service multiple regions (presumably a small subset) and a region may be serviced by multiple hosts (to support dynamic scaling). Given a service method invocation, the region ID may be derived from examining the input parameters. In the simplest case, one of the parameters contains a value for the Region ID. The general problem is more complex involving some complex data mapping involving business rules, etc. For the prototype, I used an annotation @Locator to mark the parameter (or field) containing the Region ID.

Once we have a strategy for determining the Region ID for each service invocation, we can implement a Service Locator to resolve the physical host address and port and route the request to that endpoint. Besides partitioning by geographic region, it’s easy to see how this concept could be applied to an domain based affinity scheme.

Design Considerations

The high level design goals include:

• Utilize lightweight remoting with support for multiple protocols (e.g. http, RMI)
• Centralize configuration of host to endpoint mapping. The assignment of hosts to regions is expected to be very dynamic and controlled by the operations team
• Centralize the service locator. Given the potential complexity of service location rules and data dependencies, the Service Locator should be a centralized resource
• Allow for simple configuration. It should be easy to add new services
• Provide service versioning. Allow for the availability of different versions and allow clients to specify compatible version(s)

Spring Remoting comes immediately to mind but does not meet the design goals. It is fairly simple to extend Spring’s RmiProxyFactoryBean to inject different endpoints at runtime. A Service Locator implementation can be injected into the extended proxy to provide a URL for each invocation. This approach requires a proxy to be configured for each service type and, on the server side, A corresponding Service Exporter. This violates the simple configuration goal. In addition, accessing a central Service Locator requires an extra round trip on the network for each service request. There is a possibility to use caching, but this quickly leads to unnecessary complexity.

An alternative, is to go the ESB route and use content based routing. I initially considered Mule, but apparently Mule does not provide an inbound RMI adapter. I envisioned a similar approach: basically the client invokes a server side proxy that routes each service request to a target endpoint. Using Spring Remoting alone would require configuring a separate endpoint for each Interface type. This would eventually become unmanageable.

In the end, Spring Integration (SI) provided an interesting solution.

Implementation

SI provides a GatewayProxyFactoryBean commonly used to transform a method invocation on any interface to a Message. A SimpleMessagingGateway is used to send a message with a payload containing the method parameters over a request channel and send the return value as a response message over a reply channel. SI also provides messaging over RMI using RmiOutboundGateway and RmiInboundGateway. These components were the basic building blocks for the solution.

What I was going for is an RPC based approach in which the server and client side share a common interface. It is important to note that SI in general, and the GatewayProxyFactoryBean in particular is not designed for this purpose. Spring Remoting already provides an RPC-like implementation. SI is an implementation of Gregor Hohpe’s Enterprise Integration Patterns which is based on message based communications. As previously mentioned, I discarded Spring Remoting because the configuration would be complex and hard to manage.

A better approach is to convert each service invocation to a Message. In SI, a Message is an abstraction that contains Headers and a Payload. The message headers are represented as a Map and the Payload can be any object. Once the service invocation is transformed to a message, it is possible to process service request messages using a common endpoint and message handlers to do perform the remote invocations and routing. Once the message is routed to the correct host, an operation on the service implementation, a POJO, is invoked and the result is returned via the reply channels.

At first, the GatewayProxyFactoryBean (GPFB) appeared to be very close to what I wanted, but not quite. I needed the identical message payloads to what GPFB provides (the method arguments in the request message and the return value in the reply message) but I needed to enrich the message header with the service interface class name, the method name and the requested service version range. It turns out that the GPFB does set the method name in the message history headers, but it is very difficult to determine the service interface.

The latter is a characteristic of dynamic proxies in general. In Spring the Proxy Factory Bean’s getObject() method returns the proxy. The name of the proxy class is something like $Proxy1 so you can’t get the type directly by calling getClass().getName() (there is a way to discover the class name using reflection but it is much more involved). Also, it is difficult to get a reference to the actual Spring factory bean and query it’s interface property (where are the leaky abstractions when you need them?). Any attempt to extend the GPFB to provide the interface type proved futile. So that is clearly the wrong approach. But it gave me an idea…

I implemented my own Proxy Factory Bean (using the GPFB source as a template). This creates a dynamic proxy for the service interface. When a method is invoked on the proxy, it can create a message with the required attributes in the message header and the set the message payload to the method parameters and send that message to an inbound gateway. As it turns out, I did not even need to create a message. The GPFB does all this for you. Internally, GPFB uses a SimpleMessagingGateway injected with an InboundMessageMapper and an OutboundMessageMapper. The inbound message mapper is very smart. For example if your payload (method parameters) consists of a Map followed by an object that is not a Map and you annotate the Map with @Headers (an SI annotation) then it will create the message for you, adding the map entries to the message header. I created the following interface:

And used the GPFB to wire it into an SI messaging gateway and injected that into my proxy factory bean, GatewayAdapterProxyFactoryBean.

The Spring configuration for this looks like (click to enlarge):

The message gets sent via RMI (RmiOutboundGateway) to determine the service endpoint and add the service URL to the message header. For the prototype, I wrote a AnnotationAwareServiceLocator to determine the endpoint URL and a ServiceURLHeaderEnricher and an AnnotationAwareServiceLocatorMessageProcessor to process the message.

The SI configuration for this is:

The must now be routed to the service host via RMI. The RmiOutboundGateway can do this however, out of the box I would have to statically configure an outbound RMI channel for every service endpoint. Instead, I opted to write a DynamicRmiOutboundGateway. This is a simple wrapper around the RmiOutboundGateway to configure it programmatically from the message header attributes. The prototype implementation creates a new instance of RmiOutboundGateway for each request and would benefit from caching them.

At the service host the message is received over an RmiInboundGateway (These all run in one JVM and are configured with different ports) and handled by a Service Activator which also implements the GatewayAdapter interface to extract the message payload and header. At this point, we need to obtain an instance of the service class from the application context and invoke the named method. The ServiceGatewayAdapter uses reflection to do this (Sorry about the crappy layout. Any WordPress tips are appreciated).

You can download the source code, build it with maven (or m2eclipse) and run the GatewayProxyTest.

In the late 1950s, when computing was in its infancy, DSLs were actually state of the art. In 1957, my father, the late William Joseph Turanski and his colleage, Anatol W. Holt, were employed at the Univac Applications Research Center of the Remington Rand Univac division of the Sperry Rand Corporation (now Unisys). Their primary focus was the development of a Generalized Programming (GP) system (renamed FLEXIMATIC by the marketing dudes). This was basically the first general high level language compiler. Being a completely new field, computer scientists were still trying to devise basic “naming aids” such as symbolic addressing, mnemonic devices, and convenient notations, that could be efficiently parsed by a computer and correctly mapped to computer instructions. However, compilers for specific types of computing problems were commonplace.

Holt describes the situation in General Purpose Programming Systems, a technical report he authored, dated October 30, 1957, based on a talk given before the ACM in Houston, in June 1957 (I own a hard copy). In reference to GP, he states:

General Purpose Programming Systems by Anatol W. Holt October 30, 1957

“The system differs from other compilers,…, in that it aims to provide the programmer with a set of services equally applicable to the solution of any problem – services, in other words, which are claimed to be altogether “general purpose”. Therefore the system contains no special design features which make it better adapted to one area of computation than another.”

One can infer from this, that designing a general purpose language was a very challenging proposition. Similar to developing a general solution in mathematics or science, you first start with specific working examples and try to determine what they have in common to arrive at a generalization. Such was the state of computing in 1950s. There were specific language compilers developed for commercial use in various mathematics and business domains, but the general solution was still being worked out. Holt describes the state of the art:

“In the development of most compiling systems, the designers begin with a special range of problems for which they intend their systems to be useful. They invent special notations which they consider naturally adapted to the area of problems in question, and they construct a translating mechanism with just enough generality to cope with these notations.”

This is a pretty fair description of a modern DSL. But of course this model didn’t scale very well. As Holt observes,

“While…special notation for a given area of problems… may be very useful and important…, the ability to add arbitrary, new notation is even more important than any given set of special notations. … we cannot even hope…to subdivide the entire universe of problems into fixed areas, each with a well-adapted notation. For example, if I have devised on notation satisfactory for business problems and another notation satisfactory for algebra, I am still unable to write convenient coding for problems which…involve a lot of data handling and algebraic computation.”

William Turanski and Anatol Holt at the Univac 1, circa 1957

“In summary, …I claim that it is possible to construct a general purpose compiler…The theoretical foundations for such compiling systems are now being developed at Remington Rand. Early examples, such as GP for UNIVAC 1, demonstrate the practical utility of a system designed from this point of view.”

The rest is history. Sadly my father died as a result of an automobile accident while en route to the Algol 60 conference in Paris. Algol was of course a forerunner to modern languages such as C and Java. I’m sure, if alive today, he would have appreciated that the wheel has once again come full circle.

So I am a huge fan of Ruby and Rails, and then along came Grails. Grails is an implementation of Rails written in Groovy. Derived from Java syntax, Groovy is easy for Java developers to pick up. In addition, Grails uses familiar Java frameworks under the covers, most notably Spring and Hibernate. Recently SpringSource acquired G2one, the company behind Grails and some interesting work has been happening to integrate Grails and Spring integration. Reading the Grails documents and various posts, it was clear to me that Grails down-plays its Rails heritage. I expected some significant differences so I thought it would be interesting to port a Rails application to Grails.

I started with the Rails tutorial which guides you through a simple blog application. I used Mysql 5 for the database and got it up and running in no time. The application allows you to post blog entries and comments on the entries. Two tables are created, posts and comments. Of course there is a one-to-many relationship, so a post has many comments and a comment belongs to a post.

I basically wanted to retain the existing database tables and create the application with Grails. In the process, I discovered some of the key differences between these two frameworks.

The first step is to install Grails. It’s best to stick with the stable release. Being adventurous, I decided to check out the latest code from the svn trunk and build it myself. This is currently version 1.0.5. The latest stable version is 1.0.4. There is also a 1.1 beta release. Version 1.0.5, and 1.1 beta are buggy and caused some problems with object relational mapping. I eventually resigned myself to using 1.0.4, and everything worked as expected.

To create the blog application, type
grails create-app blog
This is analogous to the rails command. It creates the directory structure for your application and sets up a default configuration.

Next, configure the data source for Mysql. Edit grails-app/conf/Datasource.groovy, so that it looks something like this (changes are bolded):

Note that like Rails, Grails provides development, test, and production environments. This configuration provides access to the Mysql database I created with Rails. Note the dbCreate property is commented out. The default behavior for the development environment is to drop and re-create the tables every time you run Grails. In this case, I want to retain the schema and the existing data. Removing this property prevents Grails from destroying the database.

Next, you need to provide the declared driver class. This is the standard JDBC driver for Mysql in this case and is provided in mysql-connector-java-5.0.8-bin.jar, for example. Install this in the application lib directory.

Now, create the domain classes. These are somewhat analogous to the Rails model (ActiveRecord) classes. Grails provides Grails ORM (GORM) which uses Hibernate under the covers. GORM provides some nice features, and a nice DSL, but is somewhat incompatible with Rails in its “convention over configuration.” Key differences include:

• No pluralization of table names
• Automatic record versioning for optimistic locking
• No timestamping records by default. Timestamping uses different field names by default
• DB column names with underscores are converted to camelCase field names by default

So after some experimentation, the Rails compatible domain classes, providing the same features as in the Rails tutorial , are

Notice the boilerplate code required here. The timestamp fields are Grails defaults and will be automatically updated as appropriate. Unlike, Rails, they must be explicitly declared and mapped to the Rails conventional column names.

Versioning is turned off, as the tables do not include version columns. (I am a big fan of optimistic locking, but this is KISS). The constraints closure in the Post class demonstrates how field validation is done in Grails, similar to the Rails tutorial.

I struggled for a while attempting to refactor this code into a base class. I eventually gave up. GORM provides some conventions around mapping inherited domain classes. Also, I couldn’t figure out how to get the mapping closure to execute the base class mapping. It is likely due to my lack of Groovy and GORM expertise, so I suspect there is an easy way to do this.

From this point, it is fairly straight forward. Execute the commands:
grails generate-all post
grails generate-all comment

to generate the controller and view scaffolding code. Then
grails run-app
and you should be good to go.

As a final step, Grails scaffolding creates inputs for dateCreated and lastUpdated. This also behaves differently then Rails. So I went in and edited the view pages, e.g., grails-app/views/post/create.gsp and removed the date fields.

The blog application on Rails

The blog application on Grails

]]>