I will have multiple (4 -10) clients distributed across the country running the same exact java web application. These clients would like to exchange some information between themselves. To do this we expect to have a server (a hub) that will facilitate this communication. The clients will only communicate their requests to the hub and the hub will forward the requests to one or more other clients. The requests will be processed by the clients, results will go to the hub and the hub will return the final result to the original client.
We plan to use web services (either Axis or CXF ) to send/receive the requests.
The requests could be coming from each client at the same time to communicate with all of the other clients. The requests will also be allowed at only certain periods of time during the day, they will have to stop and continue when the allowed timeframe comes again. Everything must be secured (WS-Security). These communications may need to be logged to a hub's database. Some messages may need to be adjusted by mapping certain values to more common values before the results are returned.
I'm sure this is not a new problem. I'm sure there is a technology out there that is doing at least some of it already. We can build something like this in house but it would be nice if all this multithreading and routing and load balancing would be handled by an existing technology/product.
Any ideas would be greately appreciated.
the message flow with webservices bound to a strict client-server model. the web service endpoint in your hub has no method for adressing arbitrary/specific ws-clients and sending out a message to them.
a ws-client has to make a request to get an response; this means you have to implement the forwarding of messages with clientside polling of every client which wants to receive messages.
this means that your timeframe-based messaging cannot be controlled completely from the hub. depending on the message rate an number of clients you have the choice of 3 pollingmethods: clients
can be implemented using asynchonous calls (polling on the responseobject or callback with a handler) - jax-ws supports this. But this means, the hub binds resources for these waiting calls and maybe
you will get timeout-related problems over the network. maybe its better to keep it simple and let the clients poll synchronous and the ws-hub-endpoint answers immediate whether a message is available or not.
a second call would then get the message.
hope it helps
Thank you for your reply. I was more looking for a kind of out of the box solution. Maybe implementing messaging or an ESB.
I started looking at ESB and Mule seems to be a good pick but a cost might be prohibitive.
Does ESB seem to fit into my design?
Any ideas about what to choose? JBossESB, Camel, Servicemix? I'm going to be running a JBoss AS and may need to deploy esb to the jboss app server.
The requests could be coming from each client at the same time to communicate with all of the other clients.
It seems like the requirements are rather broad. Maybe they look better in one of your documents.
Who owns the data? You have data being sent to more than one person, each of whom can make changes? And there is some magic time at which no one is allowed to send anyone else data?
Some messages may need to be adjusted by mapping certain values to more common values before the results are returned.
If everyone is running the same application, why would there need to be any mapping of values?
I wonder if the problem might need to be scoped down a little. It seems like you are being asked to create a magic cloud that solves all the world's problems.
(Sorry, I know this doesn't answer any of your questions.)
1. Multiple thick client (desktop/server applications) as you mentioned.
2. Single hub application.
3. A MQ Server, something like websphere mq server to glue all applications.
This kind of architechture will provide you good control upon system load which will be always scaleable in correspondence to processing power you have at hub.
As, you can control and change number of parellel messages retieved from mq easily.
Also, such architecture will be performance effective as in MQ calls objects can be serialized and sent over.
So, if you have java on both sides and you are dicy about webservice then you can simply use java serialization.
I will have multiple (4 -10) clients distributed across the country running the same exact java web application.
As you are already using a web application, I recommend using web services than other technology as this keeps your architecture extendible.
The clients will only communicate their requests to the hub and the hub will forward the requests to one or more other clients. The requests will be processed by the clients, results will go to the hub and the hub will return the final result to the original client.
I understand in both sending request and receiving response, hub is mandatory as an intermediary to process something. How long do you think the whole trip take? Is that manageable in minimum amount of time, you might have to consider volumes of data here without getting time out by exceeding configurable value? Synchronous or Asynchronous type of web services usage depends on this. Also, what would your request originated at one client(A) do on the other client(B) end? Is it going to "push" data on to the client web application? Or is B going to get the processed request data of client A from the hub? And the same questions vice-versa.
I like the idea of using MQ but at the same time feel a bit overkill for your specific application?
The requests will also be allowed at only certain periods of time during the day, they will have to stop and continue when the allowed timeframe comes again.
To allow this requirement, you should consider temporarily storing request details somewhere in the hub as "certain period of time" may be starting after your hub already processed the request data and ready to forward to other client.
Yes, an ESB seems to be a good option. As far as I recall, there is a community-version of Mule that can be used free of charge (correct me if I am wrong!). Apache ServiceMix is indeed free of charge.
It may be enough with some framework that implements enterprise integration patterns. In that case, take a look at Apache Camel or Spring Integration.
To answer some of your questions:
The clients have exactly the same application and same web services. The web services could be/will be asynchronus.
The request from client A will be processed on client B. The response from client B will be pushed to Client A.
Since the requests could only be processed during a certain time, I intend to pool for the requests to process from the hub. So the hub will ask client A (using a web service call) to give it the next record to process. The hub will log some info about this request and route to a web service on the client B. When the response comes from client B the hub will also log some status information in the hub database and push the response to client A.
What I need is a routing mechanism on the hub and a load balancing mechanism. Something that will easily pool/send/receive web service requests (CXF or Axis), log the communication to the database and do some content based routing to the next web service.
Unfortunately, due to the nature of the exchanged information I can't queue up the requests/responses.
So I need the hub to route the requests/responses and also to control the volume, wouldn't like to kill either the hub or any of the clients.
I was also looking at Apache Camel and Apache Synapse.
We are a java/JBoss shop. I'm also thinking to use Quartz to confine requests to a certain time fraime.
I would appreciate any ideas about the architecture or an existing technology to use.
Thanks in advance.
Think of how stupid the average person is. And how half of them are stupider than that. But who reads this tiny ad?
The WEB SERVICES and JAX-RS Coursehttps://coderanch.com/t/690789/WEB-SERVICES-JAX-RS