[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
Converting JMS to Java  XML
Forum Index -> Terracotta Platform
Author Message
Admin

master

Joined: 05/24/2006 12:45:08
Messages: 71
Offline

Converting JMS to Java
Posted: Aug 10, 2005 1:23 PM Reply


At first glance DSO looks like a wonderful way to replace existing distributed/clustering based technologies with simpler Java. One area that is most relevant to me is JMS. It would be good to have a best practices guide for converting/adapting various APIs and technologies like JMS.

It appears that creating an application like it wasn't a distributed application but then configuring DSO to make it one is the way to approach application development.

So, using commonly available Java libraries how would you replace features in JMS such as (or would you just use JMS):
- persistant destinations
- time to live on messages
- message durability, especially for topics (so that a message isn't removed until all registered listeners have received the message.
Admin

master

Joined: 05/24/2006 12:45:08
Messages: 71
Offline

Re: Converting JMS to Java
Posted: Aug 11, 2005 11:59 AM in response to: wpoitras Reply


Hi. This is an excellent question that goes to the heart of DSO's value proposition. We are working on putting together a guide such as you describe.

The short answer is that the best practice is highly dependent on the use case. In some cases, we see that JMS is simply used as a transport for maintaining a distributed cache; DSO is a natural drop-in fit there. If you have more of a pub-sub use case, DSO can still help, though you may need to write some simple code in the app layer to express the delivery semantics you describe.

We're also investigating hybrid solutions in which we would optionally and transparently back a DSO cache with JMS. This would give you the best of both worlds: a simplified programming model with JMS' qualities of service.

We'd be very interested in talking with you more to understand better how Terracotta might be able to address your specific needs.

Cheers,
-p

---
Patrick Calahan
Product Manager
Terracotta, Inc.
Admin

master

Joined: 05/24/2006 12:45:08
Messages: 71
Offline

Re: Converting JMS to Java
Posted: Aug 11, 2005 1:34 PM in response to: pcal Reply


Hi Bill,

Let me take a stab at answering your questions:

Persistant Destinations:
DSO uses a database on the L2 to persist objects to disk, so both the messages and the destinations can be persistent. The easiest way to build a messaging system using the Java APIs would be to share a java.util.List. There would be trade offs to this approach -- you wouldn't get some JMS features like TTL and message selectors, but you would get other features that JMS does not provide, such as object identity (pass-by-ref semantics across VMs), distributed wait/notify, and of course, a *much* simpler API.

Time To Live:
Using DSO in the 1.1 release, you would need to handle this at the app level, i.e. put a time-to-live as a field in the object, and have the application code filter expired messages. It might be possible to extend DSO to handle this automatically in a future release. We'd love to hear your requirements around this.

Message Durability and Durable Subscribers:
JMS pub/sub with durable subscribers can be modeled using a hashmap of queues, where the key is the subscriber id. For each published message, an object will be added to every queue. But note that it is not a separate copy of the object on each queue, but a reference to a single object, hence the overhead is low. This data structure could be combined with either distributed method call or wait/notify to notify clients when new messages (objects) are published.

Longer term, we've considered creating a transparency layer that would map java.util.List onto JMS, such that JMS would be used for the message transport. This might be useful for integrating with JMS-based systems while providing a simpler API, and for exploiting special features of different JMS implementations.'

In light of the functionality that DSO provides, you may also consider whether your application needs to be designed using a messaging paradigm. Using DSO, it is possible to design and develop for a single multi-threaded VM, with the knowledge that some of the objects will ultimately be shared. This allows you to focus on the application logic and data structures, without worrying about state distribution and clustering. You may find that it changes the way you approach building distributed systems in Java.

Hope this helps,

-Don Ferguson
 
Forum Index -> Terracotta Platform
Go to:   
Powered by JForum 2.1.7 © JForum Team