| Author |
Message
|
| chris boehnke |
 Posted: Thu Jul 19, 2007 5:30 am Post subject: Need to implement either httpInput or MQInput node concept |
 |
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
Hi Guys,
Right now our flow looks like this:
1. FanOut(request): MQInput -> Aggregate Control -> XMLTransformation(by using Stylesheet) -> MQOutput -> Aggregate Request
2. FanIn(reply): MQInput(response from destination application + Original Input msg, to maintain the state of the message) => Aggregate Reply -> XMLTransformation(by using Stylesheet) -> MQReply
Now we plan to implement the web services concept by using http Input and http Reply nodes to the existing message flows(which I mentioned above).
We are planning to use both MQInput and http Input(either or) concept
Questions:
1. How to implement either MQ Input or http Input nodes to the same flow(in the request flow, FanOut)?.
2. We are planning to use WSDL for the web services concept. We need to create the messageset(message definition file) for the WSDL provided. When we implement MQInput and http Input nodes concept to the same flow, do we get any conflicts with the messagesets as webservices uses WSDL and MQ Input uses Cobol copybook in our messagesets?.
Your suggestions and thoughts are appreciated.
Thanks. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jul 19, 2007 5:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You won't be able to do HTTP request/reply in two flows - asynchronously.
It's a synchronous protocol, after all.
This means you will have to convert your MQ flow to be synchronous as well.
That means put everything in one flow, and replace your FanIn MQInput with an MQGet.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Jul 20, 2007 5:11 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| jefflowrey wrote: |
You won't be able to do HTTP request/reply in two flows - asynchronously.
It's a synchronous protocol, after all.
This means you will have to convert your MQ flow to be synchronous as well.
That means put everything in one flow, and replace your FanIn MQInput with an MQGet. |
Hey Jeff,
Is it possible to implement the agrregation nodes when we use the http nodes(web services)?.
From your response, I am planning my design like this:
http Input ->Filter node(decision making whether Cobol XML or IAA XML) -> XMLTransformation(business logic in Stylesheet) ->http request -> XMLTransformation(business logic in Stylesheet) -> http Reply
Now there is another problem: we want to keep the state of the message. How can we implement this with the http input nodes?. Can we use the Aggregation nodes when we implement the http nodes?.
Normally when we were using the FanOut and FanIn flows(by using the MQInput, MQOutput and MQReply nodes) by using the aggregation nodes, we used to save the original message in FanOut flow and send it to the Aggregation Reply node in the FanIn flow to generate the reply message(combining the original msg and response msg from the destination application).
How can we achieve this by using http nodes?.
yout thoughts and suggestions are appreciated.
Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 20, 2007 5:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's not necessary to use the Aggregation nodes with a synchronous request/response.
I suppose one can, though.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Jul 20, 2007 5:41 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| jefflowrey wrote: |
It's not necessary to use the Aggregation nodes with a synchronous request/response.
I suppose one can, though. |
Thanks Jeff.
You mean as web services(http nodes) is a synchronous process, we dont need to maintain the state of the message??.
We are going to use the WSDL to create the message set. As far as I know we need to import it into the messageset project and create the message definition file for the WSDL provided. Correct me if I am wrong.
Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 20, 2007 5:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I imagine you'll find out if you're wrong once you've tried it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vsr |
| Posted: Fri Jul 20, 2007 6:08 am Post subject: |
|
|
Centurion
Joined: 04 Apr 2006
Posts: 104
|
Aggregation nodes best suits when there is a single request and broker has to make a desicion on responses from multiple applications. This can be simple composite of all the responses or taking a decision what to do next.
Like Jeff said HTTP Requst/Reply is synchronous.
In your design, if your requirement is to call multiple other applications (can be Cobol or even a web service) to make a final decision, then you still have to use aggregate nodes to achieve that. It depends basically on what you wanted to achieve. Please don't confuse HTTP request/reply to aggregation.
This link may be helpful to understand better:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac34540_.htm |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Jul 20, 2007 6:19 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| vsr wrote: |
Aggregation nodes best suits when there is a single request and broker has to make a desicion on responses from multiple applications. This can be simple composite of all the responses or taking a decision what to do next.
Like Jeff said HTTP Requst/Reply is synchronous.
In your design, if your requirement is to call multiple other applications (can be Cobol or even a web service) to make a final decision, then you still have to use aggregate nodes to achieve that. It depends basically on what you wanted to achieve. Please don't confuse HTTP request/reply to aggregation.
This link may be helpful to understand better:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac34540_.htm |
Thanks vsr!!! |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Wed Jul 25, 2007 5:19 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
[quote="chris boehnke"]
| vsr wrote: |
Aggregation nodes best suits when there is a single request and broker has to make a desicion on responses from multiple applications. This can be simple composite of all the responses or taking a decision what to do next.
Like Jeff said HTTP Requst/Reply is synchronous.
In your design, if your requirement is to call multiple other applications (can be Cobol or even a web service) to make a final decision, then you still have to use aggregate nodes to achieve that. It depends basically on what you wanted to achieve. Please don't confuse HTTP request/reply to aggregation.
This link may be helpful to understand better:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac34540_.htm |
I am implementing web services(by using http nodes) and aggregation nodes to get the responses and aggregate all the responses to generate a single response.
My design flow is as below:
http Input -> Aggregation Control -> FlowOrder(path 1) -> XML Transformation(business logic in XSLT) -> http Request -> Aggregate Request
FlowOrder(path 2) -> Save the original message(Compute node) -> ECHO.Queue(MQ Output queue) -> Aggregate Request
Question: In the FlowOrder(path 1) I am trying to use Aggregate request node just after the http request node.
The message which returns from the web services is passed through the http request(out terminal).
Could anybody suggest me whether I am going in the right direction in using the Aggregate nodes in my flow?.
Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 25, 2007 3:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Aggregation is not typically used with a synchronous protocol like http but more with an asynchronous protocol like mq:
Example:
on the Fanout flow
mqinput aggfanout compute(1) mqout(1) aggreq(1)
compute(n) mqout(n) aggreq(n)
on the faninflow
mqinput--->aggfanin--->compute--->mqreply
What does this mean?
If your only operation in the aggregation is an HTTP service call you're better off not using aggregation.
If you have (n) http service calls in the aggregation you're better off running each of the http service calls as it's own flow and have something like this
mqinput-->aggfanout---compute(1n)--> mqoutput(1-n)--->aggrequest(1-n)
The fan in does not change.
Then you will have n flows with:
mqinput-->httpservicecall-->mqreply
Thus you have decoupled the synchronous calls from your aggregation...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Thu Jul 26, 2007 12:25 pm Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| fjb_saper wrote: |
Aggregation is not typically used with a synchronous protocol like http but more with an asynchronous protocol like mq:
Example:
on the Fanout flow
mqinput aggfanout compute(1) mqout(1) aggreq(1)
compute(n) mqout(n) aggreq(n)
on the faninflow
mqinput--->aggfanin--->compute--->mqreply
What does this mean?
If your only operation in the aggregation is an HTTP service call you're better off not using aggregation.
If you have (n) http service calls in the aggregation you're better off running each of the http service calls as it's own flow and have something like this
mqinput-->aggfanout---compute(1n)--> mqoutput(1-n)--->aggrequest(1-n)
The fan in does not change.
Then you will have n flows with:
mqinput-->httpservicecall-->mqreply
Thus you have decoupled the synchronous calls from your aggregation...
Enjoy |
Could you explain the below statements in a bit detail please:
If you have (n) http service calls in the aggregation you're better off running each of the http service calls as it's own flow and have something like this
mqinput-->aggfanout---compute(1n)--> mqoutput(1-n)--->aggrequest(1-n)
The fan in does not change.
Then you will have n flows with:
mqinput-->httpservicecall-->mqreply
thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 26, 2007 12:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The idea is to put each synchronous HTTP request inside it's own flow, driven off an asynchronous MQ call.
Then you can manage the aggregation portion of it as if it was all MQ.
If you had other kinds of requests over other kinds of protocols - perhaps using the file extender to exchange data over a file, or etc - you could do the same thing.
Then you have only a minimal amount of change to make to your "main" aggregation flow, if you need to add or change the requests/replies being aggregated.
But if you know that a) all your requests are going to be HTTP, b) you have only a small number of them, c) they are generally going to be reliable - you will get a lot better performance by putting them all directly in one flow and not using the Aggregation nodes at all.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Jul 27, 2007 7:07 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| chris boehnke wrote: |
| fjb_saper wrote: |
Aggregation is not typically used with a synchronous protocol like http but more with an asynchronous protocol like mq:
Example:
on the Fanout flow
mqinput aggfanout compute(1) mqout(1) aggreq(1)
compute(n) mqout(n) aggreq(n)
on the faninflow
mqinput--->aggfanin--->compute--->mqreply
What does this mean?
If your only operation in the aggregation is an HTTP service call you're better off not using aggregation.
If you have (n) http service calls in the aggregation you're better off running each of the http service calls as it's own flow and have something like this
mqinput-->aggfanout---compute(1n)--> mqoutput(1-n)--->aggrequest(1-n)
The fan in does not change.
Then you will have n flows with:
mqinput-->httpservicecall-->mqreply
Thus you have decoupled the synchronous calls from your aggregation...
Enjoy |
Could you explain the below statements in a bit detail please:
If you have (n) http service calls in the aggregation you're better off running each of the http service calls as it's own flow and have something like this
mqinput-->aggfanout---compute(1n)--> mqoutput(1-n)--->aggrequest(1-n)
The fan in does not change.
Then you will have n flows with:
mqinput-->httpservicecall-->mqreply
thanks. |
I want to use httpInput instead of MQInput node and httpRequest instead of MQOutput(1) just before the Aggregation Request node to call the web services.
Is it possible to use httpRequest instead of MQOutput(1) just before the Aggregation Request node to call the web services?.
Please suggest....thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 27, 2007 7:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are doing HTTPRequest, you don't need Aggregation.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| chris boehnke |
| Posted: Fri Jul 27, 2007 7:33 am Post subject: |
|
|
Partisan
Joined: 25 Jul 2006
Posts: 369
|
| jefflowrey wrote: |
| If you are doing HTTPRequest, you don't need Aggregation. |
Hey Jeff,
Thanks for your inputs. Yes, I am planning to implement httpRequest node and call the web services.
We need to call multiple services and an aggregate reply should be generated. Do you think without using the aggregation nodes we can achieve my requirement?.
If the aggregation is not needed, this is the flow design what I have in my mind.
httpInput->XMLTransformation(business logic in Stylesheet)->httpRequest->XMLTransformation(business logic in Stylesheet)->httpReply.
Please let me know if I am wrong.
In the above planned design, how can we call multiple web services as we can place only single URL in a httpRequest node?.
Thanks for your valuable suggestions. |
|
| Back to top |
|
|
|
|
