| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| New HTTP nodes in WBI MB V5 |
« View previous topic :: View next topic » |
| Author |
Message
|
| mverh |
 Posted: Mon Dec 08, 2003 1:39 pm Post subject: New HTTP nodes in WBI MB V5 |
 |
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
Has anyone out there given any thought to how they will utilize the new WBIMB HTTP nodes (HTTPInput, HTTPReply, HTTPRequest) in a request reply model where the broker forwards requests to downstream service providers?
The reason I ask is because prior to V5 microflows were stateless. In my case I have separate flows that handle requests and responses and we either send the state info to the downstream service provider and have them echo it back or we save it off into a d/b in the request flow and retrieve it in the response flow. With the HTTP nodes we no longer are stateless, the flow that has the HTTPInput node must also have the HTTPReply. If this is the case I don't see the benefit of HTTP nodes in the WBI architecture, except perhaps where WBI is the requester of a web service.
I was hoping that I could simply drop a HTTPInput node into my request flow and a HTTPReply node into my response flow and expose existing services to requesters over HTTP.
Comments appreciated.
Marc Verhiel |
|
| Back to top |
|
 |
| mgk |
| Posted: Tue Dec 09, 2003 1:36 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
You can do what you want as of 5.0-CSD2. There is a reply identifier that is placed in the
| Code: |
| LocalEnvironment.Destination.HTTP.RequestIdentifier |
by the HTTPInputNode. This links the HTTPInputNode and the HTTPReplyNode. You can normally ignore it, but if you want to have Input and Reply nodes in separate flows then you must save this in the Input flow, either in the message leaving the flow or in a DB, then reset it again in the Reply flow before the message leaves the HTTPReplyNode. Therefore, although the Input and Reply Nodes still need to be paired, they can be split accross flows if necessary. Indeed the ability to flow from HTTP -> MQOUT -> MQIN-> HTTPReply is one our our design scenarios.
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| mverh |
| Posted: Tue Dec 09, 2003 4:36 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| MGK, thanks for the info..I traced ${Root} and didn't see anything in the HTTPInputHeader that let me know about the requester, I didn't think to trace LocalEnvironment...I'll try it out...thanks again... |
|
| Back to top |
|
|
| mverh |
| Posted: Tue Dec 16, 2003 1:28 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
MGK, I have managed to get the request reply model across two flows. However, the response received by my "Poster" is not what I expect. I get back two bytes of data equal to "Lo" which looks suspiciously like the start of "LocalEnvironment", nowhere in my XML response data are the chars "Lo".
Other than setting LocalEnvironment.Destination.HTTP.RequestIdentifier is there anything else I need to set explicity before the HTTPReply node which may be causing my data to be truncated? |
|
| Back to top |
|
|
| mverh |
| Posted: Wed Dec 17, 2003 5:38 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| Ok, the problem was caused my copying the message headers...I was modifying an existing flow and in the compute node was the logic to copy the message headers...I put in a check to determine if the reply protocol was HTTP and if so I branched around the code where the message headers were copied...this resolved the problem...don't know why 2 bytes were sent when the message headers were copied... |
|
| 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
|
|
|
|
