|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MDB setup for parallel development? |
« View previous topic :: View next topic » |
Author |
Message
|
vmcgloin |
Posted: Mon Dec 22, 2008 3:03 am Post subject: MDB setup for parallel development? |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
Hi,
We have a limited set of development environments, but we also allow developers to run their code locally against these environments. They insist that they need to communicate with backends rather than test locally which introduces problem with multiple MDBs listening on the same queue with the same filter (local PC code and WAS server code competes for the same messages.) These MDBs are generally used for processing asynchronous responses from backend systems.
Ideally we would like to avoid code changes as we do not want e.g. userid filtering to be propagated to production, but we do not have any smarter ideas for this.
I was wondering what anyone else does?
Thanks,
Vicky |
|
Back to top |
|
 |
JLRowe |
Posted: Mon Dec 22, 2008 11:34 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
I feel your pain
Have you heard of the spring framework?
Use the spring framework, write your business logic in POJO's - unit test them outside the container, deploy in a wrapped up MDB and then integration test them - jobs a good 'un! |
|
Back to top |
|
 |
vmcgloin |
Posted: Mon Jan 05, 2009 2:20 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
Hi,
Am I right in thinking (with the very brief googling that I have done) that POJO's still need to be able to access a queue? So each developer would need MQ installed or we would need to create queues for each developer?
We have tried introducing a (shared) unit testing queue for developers, so that at least they do not interfere with the user acceptance testers. Then the developers cannot do integration testing without deploying their code to the servers, so of course they do not use these unit test queues. I guess it is a problem with environments and test procedures - two big cans of worms around here...
Thanks for your help,
Vicky |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jan 05, 2009 12:01 pm Post subject: Re: MDB setup for parallel development? |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
vmcgloin wrote: |
Hi,
We have a limited set of development environments, but we also allow developers to run their code locally against these environments. They insist that they need to communicate with backends rather than test locally which introduces problem with multiple MDBs listening on the same queue with the same filter (local PC code and WAS server code competes for the same messages.) These MDBs are generally used for processing asynchronous responses from backend systems.
Ideally we would like to avoid code changes as we do not want e.g. userid filtering to be propagated to production, but we do not have any smarter ideas for this.
I was wondering what anyone else does?
Thanks,
Vicky |
Hi Vicky,
Sounds eerily familiar with some of the stuff we have going on.
What you should look into is making the specific MDB inactive on the server so that the there is no contention and the local PC gets them all.
Then when that phase of testing is over stop the server on the local PC and activate the MDB on the server. As I suspect the DB being used on the local PC and the server are the same you should be golden.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
JLRowe |
Posted: Thu Jan 08, 2009 6:12 am Post subject: |
|
|
 Yatiri
Joined: 25 May 2002 Posts: 664 Location: South East London
|
vmcgloin wrote: |
Hi,
Am I right in thinking (with the very brief googling that I have done) that POJO's still need to be able to access a queue? So each developer would need MQ installed or we would need to create queues for each developer?
We have tried introducing a (shared) unit testing queue for developers, so that at least they do not interfere with the user acceptance testers. Then the developers cannot do integration testing without deploying their code to the servers, so of course they do not use these unit test queues. I guess it is a problem with environments and test procedures - two big cans of worms around here...
Thanks for your help,
Vicky |
What we do is write all our business logic (our POJOs) so they are not reliant on resources such as JDBC or JMS. So, your POJO MDB accepts another POJO and not a JMS message. You can then test the vast majority of your business logic outside the container. To test the JMS part you still have to deploy. We use ActiveMQ to test sometimes, it has an 'in-memory' JMS provider that allows us to unit test our code without deployment.
If you haven't heard of spring & POJO's etc, then you have a lot of reading up to do. But, this is what a lot of people are doing and they are gaining loads in productivity and ease of unit testing. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|