Meeraj Kunnumpurath's Blog

TSS Symposium Europe - Day 2

The first session I attended was by Ted Neward on the importance of message-based architecture. I was quite impressed with Ted's presentation and delivery style. Though, I thought Ted was trying to over-emphasise the superiority of message-based model over an RPC-based model. All I would say is messaging can improve scalability and percieved performance, RPC has its use cases as well in terms of QoS and user responsiveness. Also, as soon as you step into the world of transactional and persistent messaging, some of the scalability gain would start suffering badly. Another interesting point was the notion of tight-coupling with an interface-based approach for RPC compared to the percieved loose-coupling with messaging. I am not sure how true this is. As soon as the producer changes the message structure, the consumer should be able to adapt with this. This is often achieved by using a text-based data representation protocol or something like a JMS map message. A counter argument would be that you can achieve the same level of loose coupling by using loosely typed arguments for your RPC calls. Some of these points were clarified further by Ted during the Q&A session. Had an interesting chat with him on XA and recovery after the session. Quite friendly and approachable guy.

I missed the session by Bruce Snyder on JBI & Servicemix due to work commitments. There were also a parallel session by Rikard Oberg on WSRP.

The next session was by the Terraccotta on transparent JVM clustering. Imagine the piece of code below,

public class MyCache {

  private Map cache = new HashMap();
  
  public synchronized Object get(String key) {
    return cache.get(key);
  }
  
  public synchronized void put(String key, Object value) {
    cache.put(key, value);
  }
  
}

A mundane thread-safe cache. Now imagine you can take this class and transparently apply the native Java syntax and semantics for threading across multiple JVMs on a replicated instance of this class. This is what Terracotta provides. I have seen this is implemented in a few payment switches I have come across. However it is nice to have a product that allows you to transparently cluster any application. There are a lot of use cases I can use this in the applications I am working on, including cluster-wide singletons, keeping track of cluster-wide running totals etc.

The next talk was on JPA by Mike Keith. The talk was more API and spec focused. The talk before by Patrick Linskey on a more subjective view of JPA would have been more interesting. I don't want to over-elaborate on JPA itself as more than enough has already been written on the topic. However, I would say Hibernate style criteria objects would have been great. An interesting thing was pluggable persistence providers and Spring 2.0 offering a JPA provider. I think this concept started out in EJB 2.0 and disappeared from the final version. I am a bit skeptical about the portability aspect, I am sure the vendors will be tempting developers with proprietary annotations. Do you want a good example, Spec has left to the providers on how to perform eager fetching. So the provders can say, hey, you can use sub-select fetch or join fetch using our proprietary annotations. I have similar apprehensions about the whole concept of bulk updates and the grey area around how the current attached objects are kept in sync with the underlying datastore.

The last session for the day was by Nati Shalom from Gigaspaces and Rod. They showed a neat example on how Spring can hide the transport intricacies of accessing a clustered space. I think a lot of people are doing the same kind of things with spaces, with Mule providing similar support. I have been playing around with writing a spaces binding for the SCA implementation Tuscany. It was quite interesting when Nati said we didn't need relational databases anymore (or did I get him wrong?). It may be true for greenfield projects with the rubustness provided by spaces implementation like Gigaspaces (how about durable storage?). However, with terrabytes of corporate data residing in enterprise relational databases and systems being built around existing information set, databases are here to say. The key is finding the right synergy between using existing information stores with space-based grid paradigm. Anyway, the demo was quite impressive. I am sure I will be going back to Nati on more info on how this fits into stuff I have been doing. On a side note it was quite nice to catch up with Rod after a while.

Comments

• "It was quite interesting when Nati said we didn't need relational databases anymore (or did I get him wrong?)" I don't think I used this phrase, since at GigaSpaces we invested, and are still investing, great efforts in integrating our IMDG (In-Memory Data Grid) with existing databases. See the Database Cache & Persistency section in our documentation for more details. In our upcoming release, we will go even further to enable transparent synchronization with existing databases, using a mirror service that listens for changes on the IMDG and updates them on the underlying database. What I meant was that there are certain data elements stored in the database for reliability; persisting the data to the disk guarantees that it won't be lost. In most transactional systems, trasactions are stored in a database primarily for this reason. My argument was that for this need, storing data on disk does not necessarily add reliability, especially in a 'hot failover' scenario in which the data needs to be available immediately in the alternate node. In these kinds of scenarios you can get much better scalability, performance and reliability by storing the data in the IMDG. The fact that you are using the IMDG as your primary data store does not mean that you need to throw your database away. As mentioned above, not only can we store the data in the underlying database, but we can do so with much smaller performance overhead. Nati S.

  Posted by: natis on July 03, 2006 at 03:29 PM

This work is licensed under a Creative Commons License.