I am not quite sure if this is the forum
for this or not, as designs for handling MQ workloads can tend to be proprietary
in nature... Regardless, I am going to plow ahead....
Description of topic:
All of us by now are years into the
SOA boom - where messages make up components of "Services"
flows, and although the reuse can be very beneficial, it can get tricky
to track down issues, especially those that appear to be network related.
However, this topic is really focused on the mainframe side of the
"Services" model. So, if you are not using a mainframe
as a large "Service Provider", then this topic is not for you.
There are typically a myriad of applications
running on z/OS. With the SOA model, we want to expose as much of
that world as we can, safely and securely, yet with the ease of adding
additional "Services", or "Service Versions". Since
MQ is "Everywhere" in terms of platform availability, it can
become the vehicle by which this data gets transferred between the two
ends - a Request/Reply model for the large part.
But, as this needs to scale, we start
to look toward Message Brokering concepts where we can hit a middle layer,
and have that configured to know where to route messages to, and even start
to define what can be termed the Enterprise Service Bus (ESB), but that
has many connotations to it and I am not looking to define that in this
topic. As we look towards the brokering concept, the main question
is - where does that broker reside - in a distributed world or on the mainframe
itself? There are obviously vendor products available to assist with
this - and if the solution ends being a distributed message broker, you
still have to get the data between the two platforms. So when it
hits the mainframe, how is it best handled? Is it basically a homegrown
process because multiple application dev teams all handle it as they see
fit, or are mainframe based vendor products the best choice?
Here is my basic list of questions -
of which I know they will all tend to invoke more questions, but hey -
just trying to get started.....
1) Do you expect every application
dev team on the mainframe to handle the vagaries of MQ coding - relatively
simple really, but fraught with pitfalls unless someone is overseeing the
standards and enforcing good message handling practices?
2) How is security handled - i.e.
RACF IDs to run transactions in CICS - one massively powerful ID for everything,
one for each application that needs to be accessed, one for each requesting
application which needs to talk to many mainframe apps, etc?
3) Granularity of tran codes for
CICS tuning, problem determination during crisis
4) I almost have to assume every
differently formatted message has a unique name, so do you give every unique
message name its own unique tran code?
5) Do you somehow identify the
source of the request, and give different tran codes to the same message
name depending on the originator?
6) Who or what is responsible
for some type of message logging for after the fact research purposes?
7) Are other solutions more prevalent
for mainframe communication such as CICS Web Services?
8) How do you ensure that the
requestor of a service is allowed to access that service - and where is
that authentication/authorization performed? Especially for nested
services, one service initiating others.
I am concerned with the processing of
tens of millions of requests / day, So answers need to be robust,
and flexible in configurations, etc. This topic in and of itself
is so large, and has obviously been solved in different ways by many different
organizations, but the question starts to be - if you could start over,
what would you do now?
So, if anyone wants to chime in on this,
I would take everyone's comments seriously, and if you want to reach out
to me off-list, my e-mail is david.corbett-Lu3BmH5xCZrQT0dZR+AlfA@public.gmane.org
IBM Certified Solution Designer - WebSphere MQ V7.0
IBM Certified System Administrator - WebSphere MQ V7.0
Manage Your List Settings
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com