| Author |
Message
|
| zpat |
 Posted: Thu Nov 20, 2003 2:58 am Post subject: MQSI/WMQI direct access to databases? |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
How many sites are directly accessing or updating production business databases via ODBC from MQSI/WMQI message flows?
As opposed to sending a MQ message off to another component on another platform to access the database?
What are the pros and cons of each approach? |
|
| Back to top |
|
 |
| wmqiguy |
| Posted: Thu Nov 20, 2003 10:03 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
I've seen both and here is my quick $.02:
1. The purist in my soul thinks that applications are ultimately responsible for their own data. The traditional application architecture has Presentation, Business Logic, and Data Access. Middleware is just a method that two applications use to pass data back and forth. Therefore, WMQI should just provide messages to the receiving application. That application is then responsible for all the inserts/updates, etc. Additionally, it moves all those costly DB I/O functions off of my EAI Server. 
2. On the other hand.....(and there is always another hand), having WMQI do the insert does have its advantages. For instance, it simplifies coordinating the transaction since I can do it within the broker.
Like most things in IT, it depends more on what your environment (technical and political) is like and what you are trying to accomplish. I usually push for #1 and then default to #2, depending on what the environment is like.
Good luck. |
|
| Back to top |
|
|
| Missam |
| Posted: Thu Nov 20, 2003 2:46 pm Post subject: |
|
|
Chevalier
Joined: 16 Oct 2003
Posts: 424
|
Hi wmqiguy,
Even though WMQI suggests to avoid calls to DB from flows.There will be situations you have to hit the database.what you do if both sending and receiving applications are not willing to change the code to hit the database.
Thanx
sam |
|
| Back to top |
|
|
| RatherBeGolfing |
| Posted: Fri Nov 21, 2003 6:14 am Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
We do both in our shop. If there is an existing component that is already responsible for interfacing with the database, then we try to communicate with that first. Many of our legacy apps are on the mainframe, so we make a good bit of use of the Aggregate Node to launch both CICS and IMS/DC transactions.
However, we have also coded flows that directly insert/update data into both mainframe and SQL Server databases via ODBC. Less of the former than the latter.
Larry |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Nov 21, 2003 7:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
All the above makes sense to me. It probably depends how close the database is to the WMQI broker both physically and platform wise.
I don't like the idea of UNIX ODBC to the mainframe DB/2 - no way to XA coordinate it for one thing. |
|
| Back to top |
|
|
| kirani |
| Posted: Sat Nov 22, 2003 10:46 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| zpat wrote: |
| I don't like the idea of UNIX ODBC to the mainframe DB/2 - no way to XA coordinate it for one thing. |
Yes, I agree with you. It will be too much of an overhead.
In our shop we access database from our message flows. We read from DB2 (on Windows and M/F) and sQL server databases and update DB2 (on windows only). I guess it depends how you want to design your application. Sometimes you cannot separate your DB logic/access from transformation.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
|
|
