EJB design: JMS based-architecture question
- Posted by: Angel Karantzalis
- Posted on: June 24 2004 09:51 EDT
we're building a platform for geographic applications. Our system includes:
1. A rich client, with specialised features regarding Geo. Apps
2. A server, that contains the global geog. DB, and various services
The apps that will run on the platform are hosted in two parts. First, the part that lives on the client,
and a server-side part that performs data lookups & computations on the server.
So far, we're looking towards building a messaging infrasructure that passes messages between
client & server, identifying the calling hosted app and the action to be performed. We're thinking to use
JAXM for the messaging part (and possibly integrate it with JMS).
My question is this:
Would it be a good idea to implement the entry points of the hosted apps on the server-side as
Message oriented beans ? Assuming that I need to have a pool of hosted app instances on the server
wouldn't the use of message beans provide us with the scaling features of a j2ee container, along with
lifecycle management of the beans ?
Thanks a lot for any thoughts/insights,
- seems like a typical application using MDB and session beans... by Shantanu Upadhyaya on June 25 2004 02:36 EDT
Not really sure what you mean by :
* pool of hosted app instances on the server - do you mean hosting the applicating and clustering the server ?
Yes, it would be a good idea to host the entry point using MDBs if :
your requirement is asynchronous processing : clients put the message into a queue and forget about it. Even if clients wanted to get a response & they were listeners/subscribers, they could get a response back via a queue topic. This solution would scale well with MDB pool, app server clustering. I think it would work very well for huge volume of requests.
Client1 ---> queue/topic ---> MDB(onMessage()) --> invoke Session Bean
For this, asynchronous processing should be a requirement.
Not Using MDB:
Use Session Bean and get a response back immediately. For synchronous processing this works well along with a good application server.
It really depends on the business need / type of behaviour the clients exhibit.
Hope that helps a little.