Jacob Hookom's Blog

Constraint-Based Services with RPC

The Concept

A while back, I started to write DAO's for an application at work; and of course we chose Hibernate. I've been on this 'K.I.S.S My App' kick lately with keeping things as simple as possible and actually leveraging APIs to their full extent. This theme was carried out so much so that the DAOs actually returned Criteria objects:

public class WidgetDao extends DaoService {

  public Criteria queryByCategory(long catId) {
    return this.getSession().createCriteria(Widget.class)
                  .add(Restrictions.eq("category.id",  catId);
  }

  public List findByCategory(long catId) {
    return this.queryByCategory(catId).list();
  }
}

So why the heck would I expose Criteria objects? Well, the answer is simple: I wanted to allow the most flexability at the point of most concern. So the DAOs expose this initial constraint over the data with whatever business/domain logic (the case above is really simple), but as to the what and how the data is returned, now the client of the DAO is free to decide.

This really came to light when creating UIs where we could gain Criteria instances, then assign projections, sorting, and additional filtering over the data without pressing this use case back onto my DAO/Services layer. The end result was highly efficient, agile, and fast data mining within the UI. No needless layers of complexity and procedural contracts with my service layers to expose the information I needed.

SOA, RPC, and AJAX

Let's apply this concept to SOA and RPC. Many of these new AJAX 'frameworks', and Action MVC frameworks in general, rely on pushing content around. You spend time building up these procedural contracts to expose data models, but there's no way to know what information is used and how the information will be used.

This blindness really comes to light when you are dealing with desparate systems with client/server or server/server architectures. You've written an RPC method to deliver a set of Widgets. Well, in your domain, Widgets have a lot of aggregate and composite relationships, how do you know what to expose and how to expose it to all clients? You may simply choose to push 2K of object graphs when all you needed was the Widget's ID and Description. So you begin to see the waste. This gets even more tricky when clients access to some of that aggregate data on Widgets, and if that fails in performance, are you going to write more RPC methods?

Some of the public SOA APIs from major vendors kind of do this with providing specialized parameters/attributes within their requests to specify client-based constraints such as, "Do you want short or long details on the product search?" (Amazon).

Possible Solution

Because we are blind to all possible use cases of our domain models and services, we come up with a way for the client to interrogate the data or add constraints to our RPC calls within the remote request itself. Ideally, this would be taken care of by some mediator framework such that the RPC could be invoked on the server, but based on the constraints provided by the client, we can selectively return "lighter" responses.

So take a Widget catalog exposed over SOA. We still have the RPC contract for security such that we apply initial constraints, but client could use XQuery or some other standard to specify how and what is being transported back over the network. How do you know all the possible ways of exposing your data model to a client? Wouldn't it be easier to just use some kind of mediator to query/filter/sort your data as each client needs it?

In terms of the UI, it would be conceivable to back this by a templating engine on the client such that a JavaScript Agent could pre-determine what data is presented and selectively query generic RPC services on the server.

Conclusion

It all comes down to a cost highlighted with network latency. Having objects in memory on the server is cheap, but we all know that XML/etc is horrible at efficiently representing object graphs and that network latency is an obvious crutch in thin-client applications. We alleviate this issue to some extent by coming up with an Agent-based solution on the client with a server-side mediator which will specify the what and how data is transported over the network. Keep in mind, the traditional push model for data can be both expensive to the client and server.

At JavaOne, we'll be talking about other approaches with AJAX and how component-oriented MVC (in general) not only supplements the complexity of UI constraints, but also is more agile than traditional approaches. JSF Avatar carries the torch in this context such that we've gone through the work, once, of defining our view and how the 'domain' of the UI relates; then we allow the client Agent to describe how it wants to interact with the view in an efficient and secure manner.

Comments

• But if you return a criteria object, i can't switch from hibernate to an other persistance technology.
  

  Posted by: res1st on April 12, 2006 at 11:25 PM

• Well, what if you changed MVC frameworks?

  Posted by: jhook on April 12, 2006 at 11:29 PM

• You have two problems. First SOA and RPC are incompatible technologies. It's one of the great shortcomings of Java (though there have been significant recent efforts to address this) that its WS approach has been RPC based. Building any kind of application around RPC is problematic. It leads to your second problem. You have a tight coupling between your view technology and your domain model. That's why you find yourself forced to expose everything about the domain to your view (thus Criteria as a return object.) Don't feel too bad though. As you pointed out with Amazon's WS, many other people make the same mistake.

  If you really need to get to all of your data and support any kind of SQL92 manipulation of that data, then what you really want is Toad (or Squirrel or pick your favorite SQL GUI.) Actually if you are really doing a lot of data mining, what you really want is a powerful OLAP tool, like Hyperion.

  Posted by: michaelgalpin on April 13, 2006 at 10:43 AM

• I like the long / short details request & response SOA idea

  I'm not a fan of returning Criteria objects in DAOs. Later if I have a DAO interface and I want to create an implementation for simply JDBC, or something more oddball (XML stream, Filesystem) no other persistence API will support the Criteria object

  Posted by: phlogistic on April 15, 2006 at 07:46 AM

• phlogistic, the criteria object is returned to support UI concerns, but domain dependencies between business logic still use the wrapped methods that return lists/instances, protecting yourself from long term refactoring. as for providing multiple implementations of the same dao, seems far fetched within a corporate infrastruture, and most change would requiring refactoring the one instance, not creating separate instances of the same logic/transaction scripts (why maintain this in multiple places?). usually if you chance your underlying implementation method signatures would probably change, return types would change-- there's things certain APIs like Hibernate allow you to do, which you should take advantage of, such as passing domain model references instead of just identities. allow yourself to get fooled once-- you'll end up with a lot lighter/agile code that's just as easy to refactor (if not more)

  Posted by: jhook on April 17, 2006 at 08:02 AM

• Not in all cases, you don't want to hit database for performing criteria. I have a simple UI class similar to hibernate Criteria object. But the filter/sort is done on list based on jakarta commons collection, predicate etc.. I agree for large results hitting db is appropriate.. Not for small filters.. I would have liked if hibernate allowed(added feature) to do query on simple java collections instead of database objects. Any ideas??

  Posted by: hari_sujathan on May 05, 2006 at 07:12 PM

This work is licensed under a Creative Commons License.