| Author |
Message
|
| lionsdame |
 Posted: Thu Jun 03, 2010 5:06 am Post subject: Broker and web services advice |
 |
|
Newbie
Joined: 02 Jun 2010
Posts: 2
|
Hi
I am new to the forum and am hoping that you will be able to assist with a question: I have been told that we need to integrate with a client via web services. So far I have only ever had to work with queues and FTP, but not with HTTP and SOAP. 
I have gone through the samples, but I wanted to get some input for more experienced folks on the following:
1. What are the gotchas when working with HTTP and SOAP from Broker?
2. What are the benefits / disadvantages of using HTTP instead of MQ ... it seems to me that HTTP is much flakier than MQ ?
Thanks for the help,
Jane |
|
| Back to top |
|
 |
| joebuckeye |
| Posted: Thu Jun 03, 2010 5:46 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
One gotcha I had was that messages that originate from an HTTPRequest node take their default properties from the Properties tree of the message and not from an MQMD you might add to it. When the message was being output via the MQOutput node it would build a new MQMD from the Properties tree and not use the MQMD I had created for it. Took me awhile to figure that out when trying to set an Expiry value for the outgoing message.
Got around that issue by saving off the old MQMD from before the HTTP call and using that to build the response message.
This was for v6.0 though, not sure if v7 works the same way.
Look up "Properties versus MQMD folder behavior for various transports" in the InfoCenter to see it explained. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Thu Jun 03, 2010 5:51 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
It basically comes down to this (from the InfoCenter):
| Quote: |
In summary:
1. When your message flow is sourced by an MQInput node then the MQMD takes precedence over the Properties folder in terms of value propagation between the folders.
2. When your message flow is sourced from an input node that is not the MQInput node (such as the HTTPInput node or a user-defined input node), the MQMD header does not take precedence over Properties folder .
3. When a MQMD folder is added in a tree that was created by the HTTP Transport then this MQMD does not have control over the Properties folder and the value propagation direction is not MQMD to Properties; it is Properties to MQMD.
|
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 03, 2010 6:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There is a significant difference in how a disparity between Properties and transport specific headers (MQMD, HTTPRequest, etc.) are resolved in different versions and FP levels of Broker, and where and how the disparity is created affects how it is resolved as well.
Use the InfoCenter for the specific version in question.
Run experiments. |
|
| Back to top |
|
|
| lionsdame |
| Posted: Sun Jun 06, 2010 10:49 am Post subject: |
|
|
Newbie
Joined: 02 Jun 2010
Posts: 2
|
Thanks for the replies ... at least that gives me a sense that this is achievable, and I will start tomorrow with some experiments.
Any answers to question 2?
2. What are the benefits / disadvantages of using HTTP instead of MQ ... it seems to me that HTTP is much flakier than MQ ? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Jun 06, 2010 12:45 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Remember that in many cases, using WMQ is a fire and forget transport.
Yes you can wait for replies but this is not mandatory.
WMQ has this little thing called assured delivery. Also very useful at times.
There is no such thing as queues in the HTTP/SOAP world.
You have to do things 'NOW' if you don't have the resources to process the request, you will get timeouts. I'm sure you have seen them with websites not responding in a second or so.
There are some functions that are really not well suited to Web Services. There have been posts on this forum where the poster wanted to delay the processing for seconds or even hours. These are really not well suited for WebServices.
If you are going to use SOAP then it is essential to get the contract (ie the interface, aka WSDL) document set in stone before you start. This includes the error codes. Make sure you follow the SOAP standard for namespaces including the use of the correct one for error returns.
Then (finally) get your testing methodologies in place before you start. SoapUI is a good place to start especially with scripted testing. Force the developers to test everything in the contract. If they don't, it is not worth the paper is is printed on.
Personally, I'm not a great fan of WebServices. This is especially true for non external facing services. But, it seems to be the current buzzword/fashion.Sigh.
_________________
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 |
|
|
|
|
