Thank for reply. Normally, we treat the Queue as Messaging Endpoint for retrieving messages. Why can’t we treat the Queue as something like Web Service/RPC/Function End Point for synchronous request-reply operation which can run side by side with the original asynchronous nature of JMS.

In my project, I have chosen HornetQ for its 307% performance boost and its efficiency of managing large object transfer. I am implementing something like below:

Clients (REST/HTTP) HornetQ + [Request Handler]

Then, effectively, we can make HornetQ work like Apache Web Server PLUS all the benefits of HornetQ Messaging capability & scalability which allow synchronous and asychronous client communication using just REST api and also can optionally live inside JavaEE ecosystem for other Heavy Duty operation.

If I can obtain the full sources of the HornetQ REST Api, perhaps I can work out some experiment on it.

Thanks.

Also I would be happy to flush out your requirements and implement something you need. Ping me here, on hornetq dev list or resteasy dev list.

The REST api is very useful. I will be grateful if you can share some idea about how could we implement “Request-Response” pattern for a queue using the new REST api which allow us to achieve the same behavior as the existing HornetQ examples eg. Queue Requestor or Request-Reply. Assuming that I have a JMS MDB or custom consumer to processing the incoming client message.

Thanks.

Rgds,
Danny

I bought your book, “Restful Java” – it is an mazing resource! Thank you!

Got a question on one of the recent readings off of burkecentral.com
I was following some ideas for RestEasy clients on http://www.javauc.com/java/1432

Where is the following 2 annotations defined? Or, is it something one need to write thier own? I searched every maven repository – could not find any jars with those interfaces

@ResponseMapping
@ExpectedCode(int)

For example, in the following:

@ResponseMapping
@ExpectedCode(200)
public interface MyResponse {

@Body public Customer getCustomer();

@LinkHeader public Link getNext();

@LinkHeader(“last”) public Link getLastCustomer();

@Header(“ETag”) public String getHash();

}

–
Have a Nice Day!

Suresh Bhaskaran
Consulting IT Specialist
Home
Work
Cell (310) 499 6211

In this example java.util.HashMap is the unmappable object, the example below could be modified for any unmappable object.

For all references to the umappable object, you annotate the property with @XmlJavaTypeAdapter. The value of this annotation is the class you are going to use to convert the unmappable object into a mappable one:


import java.util.HashMap;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;

}


The following XmlAdapter is used to convert the unmappable java.util.HashMap into a mappable MyHashMapType:


import java.util.HashMap;
import java.util.Map.Entry;
import javax.xml.bind.annotation.adapters.XmlAdapter;

}


The mappable object MyHashMapType (and MyHashEntryType) look like:


import java.util.ArrayList;
import java.util.List;

public class MyHashMapType {
public List entry = new ArrayList();
}


and


import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlValue;

}


The following code can be used to test the above:


import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Marshaller;

Marshaller marshaller = jaxbContext.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
marshaller.marshal(foo, System.out);
}
}


JAXB is not very extendable. For example, I’d love to be able to define custom annotations that trigger callback APIs so that I can read/write custom properties from an XML document. For example, ever try to do Map support? I’ve also wanted to convert URLs to/from Link objects in resteasy with hooks into RESTEasy runtime for automatic URL writing. I just couldn’t find a way to do it within resteasy.

Have you considered using a javax.xml.bind.annotations.adapters.XmlAdapter?:
http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html

The Javadoc itself demonstrates how to handle Map using an XmlAdapter, you can also use it to convert objects to/from link representations.

I agree with you post. Here are three issues I have with Software Engineers that are okay with many languages but have not mastered one:

1. The learn-a-new-langauges-annually thing is so 1980’s. You could pick up a book like one by Peter Norton and know everything you need to know about computers then. Now, it takes years to get proficient (not good or great) at ASP.NET and C# (with its huge API). Plus, you got WPF, WF, EF 4 and many others. This is only in the .NET space. Now you have Ruby on Rail, Clojure etc- Rocky Lhotka full-time job is to keep current with just .NET and he cannot. Technology moves too fast and is too large to try everything and expect to know the quirks, bells and whistles to be competent.

2. C# has features from functional languages, dynamic languages OOP languages and more. This reduces the need to try to get a functional language feel from a pure functional language.

3. It takes dedication to become great at a tool/API, especially those with high learning curves (e.g. WPF.) Distracting yourself by trying to learn everything else can reduce you powess and mastery in a tool. If you are afraid of getting stuff knowing one thing that may be gone tommorrow, there will be tutorials. For example, Microsoft guided Software Engineers that moved from VB6 to VB.NET. You just will not be dead in the water.

Now, languages designers may need to learn a new language annually. Plus, it does not hurt if you learn a new languages annually just because you like programming. However, nowadays I do not feel that it is that urgent as it was in previous decades. Plus, polyglot-languages like C# lets you dive into non-OOP features. It is better to solve a programming the long way and quickly with a tool you are great at and can easily support THEN to build it with a more suitable tool you do not know well, may take longer to build since you are learning along the way and will forces others to learn things way outside their knowledge-area to support.