| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| d |
« View previous topic :: View next topic » |
| Author |
Message
|
| woodrow |
 Posted: Sun Oct 30, 2011 4:45 am Post subject: d |
 |
|
Guest
|
dd
Last edited by woodrow on Thu Nov 03, 2011 11:15 am; edited 1 time in total |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sun Oct 30, 2011 6:48 am Post subject: Re: Best Development & Testing Environment: Configuratio |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| woodrow wrote: |
Hi All,
Goal: To configure a common, robust library for our department's MQ needs.
Objectives: a) Isolate developers MQ Queue Mgrs from each (preferably on the local environment). |
Each what?
| woodrow wrote: |
| b) Enable placing of dummy messages on the queue. |
For what purpose?
| woodrow wrote: |
| c) Mock out the queue to increase our capability to test our client access code (all paths) |
What do you mean by "mock out?"
| woodrow wrote: |
d) Further down the road, we might swap in a different Queue technology via configuration. |
Do you mean replacing WMQ with some other product? And you come to mqseries.net to ask for help with this?
| woodrow wrote: |
| Access from: .NET |
Currently available.
| woodrow wrote: |
Currently, although we have the MQ Series client dll's locally, we use a central server for such testing. At times this is problemmatic (e.g. disconnected from LAN, our MQ Series server outages).
To start, we'd like to configure MQ Series Queue Manager completely locally. Is this possible with the current licensing & product options? |
Technically speaking, all qmgr configurations and definitions are done locally.
Is this a college computer-science assignment?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| woodrow |
| Posted: Mon Oct 31, 2011 5:23 am Post subject: |
|
|
Guest
|
Mocking out layers, objects, isolation, automatically feeding in test data and enabling of developer local testing (i.e. no reliance on external servers/installing the required server configurations locally), are best practices to maximize coverage of unit testing/integrating testing, and enable TDD and configuration driven development.
While I wanted to leave the question somewhat open to interpretation to allow for a variety of perspectives and insights, a much more simpler & clarifying quesion is this:
---> Is there a Developer Edition MQ Server?
Your polite response is appreciated. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 31, 2011 5:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| woodrow wrote: |
| Is there a Developer Edition MQ Server? |
Ask your IBM Sales representative.
Your company might, for example, already have an Enterprise license that would allow you to install qmgrs everywhere.
Or you might already have some other kind of license that provides for a full install of WMQ Server on developer workstations for specific purposes (broker toolkit for local testing, for example).
But also strongly consider the security implications of every developer having full access to a queue manager on their desktop, and what that means in terms of connections to your production queue managers.
When in doubt, firewall it out. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 31, 2011 5:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| woodrow wrote: |
a much more simpler & clarifying quesion is this:
---> Is there a Developer Edition MQ Server? |
The short answer is no. The slightly longer answer is ask your IBM rep.
IMHO it's a simple enough task to have a single development queue manager and have as many copies of the queue sets needed as you have developers on that manager. Such a queue manager has no real message load and in this way queue design and configuration remains in the hands of the WMQ admins where it belongs.
That last one will get a few rocks thrown by a few people, but I've always done better where queue standards are enforced centrally and applications are provided with what they need not what they want, naming standards are maintained for the benefit of the support team and developers are not expected to be WMQ experts as well.
Illustrative example: I was pulled into a meeting on a WMQ-using project for a client which was running late. 2 key components of their project were having problems: a message correlation and batching application sitting on a database and a message distributor. The problems were the usual ones, dba team couldn't provision a database in time, reponse times were poor, etc, etc.
I innocently asked why they weren't using a WMQ cluster for message distribution, and what message grouping in WMQ didn't provide that they needed. After a few awkward minutes it transpired that the application team were unaware of either of these constructs and had spent a number of months working on these rather oval wheels.
My 2 cents, other experiences may vary.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
