| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Service Gateway -> Msg Validation Options |
« View previous topic :: View next topic » |
| Author |
Message
|
| Seb |
 Posted: Mon Sep 06, 2010 10:58 pm Post subject: Service Gateway -> Msg Validation Options |
 |
|
Apprentice
Joined: 27 Mar 2009
Posts: 41
|
Hi guys,
in terms of building a gateway that also validates incoming service requests, we have to do message validation.
Using broker facilities we would have to create and deploy a message set from our WSDL/schemas for every new service.
Apart from the development efforts, we are further concerned with the performance impact. So is there an alternative in using ESQL to parse and validate messages? We could probably do it with a JCN instead (not using Message Sets), still not sure about the performance of that solution. Does anybody has some experience to share with such an approach, before we actually start building and testing?
Thanks,
Seb  |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Sep 06, 2010 11:16 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I expect Kimbert (the man who knows these things) may well be alone with a more accurate answer but from my own experience,
Using a message Set and NOT using a JCN (with no messages sets) is going to be a far more performant solution.
The XMLNSC parser is IMHO very highly optimised and performs well. Obviously if you have message designs that are really bad then you could pay the price in performance terms but even so I think that using a JCN in the way you suggest is plain daft.
One vital fact you left out of your oriiginal post was the volume of messages you are expecting the gateway to process. Some idea in terms of both quantity, size & complexity would help here.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Seb |
| Posted: Tue Sep 07, 2010 12:34 am Post subject: |
|
|
Apprentice
Joined: 27 Mar 2009
Posts: 41
|
The gateway will be part of a banking solution, means loads of messages, large in size and quite complex as they are based on IFW schemas.
For most of the messages hitting the ESB, WDP is used for validation and routing, but we need to provide a WMB gateway for certain use cases as well. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Sep 07, 2010 5:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| is there an alternative in using ESQL to parse and validate messages? |
What did you have in mind? An XML parser implemented in ESQL / Java? Or an XML parsing library accessed from ESQL/Java?
| Quote: |
| Apart from the development efforts, we are further concerned with the performance impact. |
Performance of what? I would be very surprised if a JCN out-performed the XMLNSC parser on XML parsing and validation. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Sep 07, 2010 5:45 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Having direct experience in this area, I can give you some insight into what you should expect.
Think of the long term vision and why you want an Enterprise Service Bus. In any thing about life, you have to trade some things to get other things. This holds true for ESBs as well.
You will find that the performance is acceptable. If your existing system is slow, adding an ESB to the equation will not change that. An ESB buys you the flexibility and the ability to seamlessly grow your architecture. What you trade for that benefit is a small increase in latency, on the order of about 50 milliseconds.
You need to be more specific in your questions. Also it appears that you have no experts on your team. Don't try to implement this with people who have no history using this technology. Hire (contract) two or three people who have done this before.
Your initial direction, as you have currently described it, is not founded in reality and IMHO is not the right way to go. This is not a cheap business. If you can not afford to have veterans on your staff, then you cannot afford this technology. Veteran consultants would have provided you better direction than what you described.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Seb |
| Posted: Wed Sep 08, 2010 1:15 pm Post subject: |
|
|
Apprentice
Joined: 27 Mar 2009
Posts: 41
|
Hey guys,
thanks for your answers so far. Talking about a WMB based gateway, even if we call it part of an ESB or not, the purpose is to do security and validation checks at the front door.
Now talking about validation, we would need to create an MSet for every new service/interface we provide. Given WebServices (SOAP&HTTP/JMS), our interfaces are based on WSDL&XSD. Now the original question was if we should go and create MSets for every new interface, which would probably require some manual steps in terms of MSet configuration or would it be easier to upload the as is WSDLs/XSDs to the filesystem and use existing Java libraries for parsing/validation. In addition we were not sure about the footprint of having MSets or rather the pure artifacts in memory for that piece of work.
Cheers,
Seb |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Sep 08, 2010 1:49 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
A few more questions for you. I'm not trying to interrogate you - just trying to get a clear picture of the problem.
| Quote: |
| we would need to create an MSet for every new service/interface we provide |
Why do you need a new MSet for every service? Would it be possible to put a number of services into the same message set? If we were discussing a pure XML parsing problem then it would certainly be possible.
| Quote: |
| the original question was if we should go and create MSets for every new interface, which would probably require some manual steps in terms of MSet configuration |
What would those manual steps be? The mqsicreatemsgdefs command can be invoked from the command line in batch mode, but I assume you know that already.
| Quote: |
| would it be easier to upload the as is WSDLs/XSDs to the filesystem and use existing Java libraries for parsing/validation |
However those files get onto the server ( BAR file or 'upload' ) you will need to have some way to manage the configuration of the server in a repeatable way. Deploying BAR files is one way to achieve that. The phrase 'easier to upload' makes me wonder whether you're trading repeatability for convenience - but I'm sure you wouldn't do that 
| Quote: |
| we were not sure about the footprint of having MSets or rather the pure artifacts in memory |
The footprint of a message set is not large - XMLNSC uses a compiled form of the schema so the raw schemas are not loaded into memory. Java libraries, if they deliver good performance, are likely to do something similar. What makes you suspect that Java might have a lower memory footprint? |
|
| Back to top |
|
|
| Seb |
| Posted: Wed Sep 08, 2010 2:47 pm Post subject: |
|
|
Apprentice
Joined: 27 Mar 2009
Posts: 41
|
A few more questions for you. I'm not trying to interrogate you - just trying to get a clear picture of the problem.
| Quote: |
| we would need to create an MSet for every new service/interface we provide |
Why do you need a new MSet for every service? Would it be possible to put a number of services into the same message set? If we were discussing a pure XML parsing problem then it would certainly be possible.
Not exactly, but yes we will make reuse of cannonical schemas providing one common MSet, but every service has an individual interface with respect to its function.
| Quote: |
| the original question was if we should go and create MSets for every new interface, which would probably require some manual steps in terms of MSet configuration |
What would those manual steps be? The mqsicreatemsgdefs command can be invoked from the command line in batch mode, but I assume you know that already.
Given a common MSet that is used by all services, the creation of a service specific MSet would just be the 1st step.
| Quote: |
| would it be easier to upload the as is WSDLs/XSDs to the filesystem and use existing Java libraries for parsing/validation |
However those files get onto the server ( BAR file or 'upload' ) you will need to have some way to manage the configuration of the server in a repeatable way. Deploying BAR files is one way to achieve that. The phrase 'easier to upload' makes me wonder whether you're trading repeatability for convenience - but I'm sure you wouldn't do that
No doubt the mqsideploy is just another way of upload in contrast to a simple FTP, but my point was more related to the fact that we would have 2 types of artifacts for the same purpose ... thinking far into the future using WSRR.
| Quote: |
| we were not sure about the footprint of having MSets or rather the pure artifacts in memory |
The footprint of a message set is not large - XMLNSC uses a compiled form of the schema so the raw schemas are not loaded into memory. Java libraries, if they deliver good performance, are likely to do something similar. What makes you suspect that Java might have a lower memory footprint?
Thank you very much for that insight. We just had a discussion what might have a smaller footprint, talking about hundreds of services (schemas).  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 08, 2010 3:18 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should consider the balance point between "it works like magic" and "we have no idea what it actually does, but we think it probably works".
That is, if you put in place a process where someone can deploy a brand new service without any governance, then you will very rapidly lose track of what your services are, what they do, and etc. etc. etc.
So you need to consider how strongly to reign in the natural desire to script everything and make everything very dynamic and flexible and self-assembling.
Looking ahead to integration with WSRR, there are WSRR nodes in Broker. You might consider, since you are only deploying a small portion of your endpoints into broker, using those endpoints as a pilot for your use of WSRR.
All that said, there are ways to script the creation of a message set from a WSDL or an XSD. And there are increasing ways to develop solutions based on patterns and scripting, so that the amount of effort to create a specific service endpoint can be reduced and streamlined. |
|
| 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
|
|
|
|
