Do we have a design flaw?
Hello everyone... just wanted to get some quick peer review action going here...
Okay I won't waste your time with a lot of "big picture" **** of this entire mamoth application we are building... but to try to make a long story short here's the basic idea:
We are doing a lot of main frame integration with a J2EE application (using Websphere and MQSeries). We have a series of EJB's that contain (duh) a lot of our business logic.
We are also using SeeBeyond tools to model business processes... essentially the example where I believe we may have a minor design flaw is this:
SeeBeyond (e*Insight/e*Gate/e*Way) instantiates an EJB. The EJB is responsible for querying one of the databases to build a message that will be written to an MQSeries Queue (which the MF will then read). The EJB simply passes back to e*Insight a ValueObject with the parameters required to construct the message... e*Insight constructs the message then sends this message to the Queue.
Originally I constructed this bean to send the message to the Queue... but was advised against doing that because we would be coupling a specific behavior to that EJB... which I can see... but I also thought that was kinda the point of an EJB... it does a specific task within its problem space.
"Decoupling" messaging from the EJB and moving that responsibility to the client (which may be e*Insight, or in other instances, ColdFusion) does this represent a design flaw, inparticular a "violation" in the J2EE spec?
e*Insight (via e*Ways) are perfectly capable of doing messaging... in fact its the "core" of this product... and to also clarify a bit... this business process I am describing is a credit check. The EJB receives and Order ID from a client. The EJB queries the database, constructs a Value Object and passes that back to the client. The client then writes to the Queue... the MF reads the queue... does the credit check and writes a response to a reply queue. All of this is asynchronous.
So, if the EJB writes to the queue... it contains only one public method: sendRequest(ord_id). Because we never know when the MF may do its thing... the client has the facility to be "triggered" by the reply queue... so the EJB should never worry about getting replies.
I guess the question is this simple: should the EJB be responsible for messaging or is it fine to let the client worry about sending the message?
I know... not exactly earth shattering... but just want to make sure that as this system grows (bloats) we aren't making potential mountains out of mole hills.
./dave
