Having problems with message search?
I'd setup a HTTP end-point that the client can talk to. This end-point could be Tomcat or something similar. All the end-point does is consume the message and queue it for later handling. It could hand the message off to a bus, grid, space, channel, topic, whatever. This allows you a lot of flexibility because the only thing the client deals with is HTTP. Then you have insulated the API from your internal details and can handle the message however you want internally. And, you can change the way you handle it internally later without impacting the client.
It might look something like this:
client ----------> end-point ----------> (cloud)
The cloud can be a topic, channel, cache, queue, space, whatever. The only concern with this setup is transactions and fault tolerance. If the end-point fails, is the message lost? Do you care if it is lost? If you care and you don't want to lose it, you can write it to disk for later processing. Otherwise, just keep it in memory. If you need to write it to disk, I'd use a selector to transfer the data to disk asynchronously if the client needs a response immediately after the last byte is written. On the flip-side, if the client isn't awaiting a response this doesn't matter as much and you can just write it out in the execute thread of the HTTP server.
-bp
On Sep 2, 2008, at 5:41 PM, Mike Wolfson wrote:
(Thought I would put this architecture question out there to thegroup, and see if some of the geniuses on the group had some good
insight).
We are trying to decide between using HTTP, or JMS as a communication
mechanism for a portion of our system.
Here are some of our requirements.
-Guaranteed delivery
-Asynchronous communication
(Well, these things scream out JMS right, but wait there's more)
-Lightweight protocol (we will be sending a lot of communications).
-Client is external to our enterprise (may or may not be Java, and
likely will not be the same JEE server we use to produce messages).
-Our messages consist of a single XML document.
So wondering if anyone has any opinions of which choice would be better.
With HTTP, we would have to code the guaranteed delivery mechanism
(which would be simple enough, as we could just wait for a response,
and when received, move onto the next communication).
I am pressing for JMS, as smart people have already completed the
persistence mechanisms. But the client developer is worried about the
increased overhead and development time of JMS.
I am also worried about lag between the request, and response, if we
don't receive a response in a timely manner, we could have resource
leaks (while waiting on the response to return, we would be
synchronous).
Quite frankly, I have some older developers that are protecting their
"old way of doing business" and are pressing for using HTTP for this
asynchronous communication. I am wondering if maybe JMS is overkill
for what we want (and maybe I am being the "young wippersnapper" that
is pushing newer technologies just for the sake of using them).
Thanks for any insight in advance.***********************************************************
Mike Wolfson
Senior Software Engineer Phoenix, AZ, USA"Imagination is more important than knowledge."
***********************************************************
Offline 
Send Email