| Author |
Message
|
| satyabodharao |
 Posted: Wed Dec 01, 2010 8:14 am Post subject: Message broker and REST services |
 |
|
Newbie
Joined: 01 Dec 2010
Posts: 3
|
Hi, I am new to websphere message broker. My current projects demands use of websphere message broker for providing REST webservices to our clients. Through reading I have acquired some knowledge. I need your help in realizing if I am doing it right.
We want to use the broker to
1) receive the incoming request
2) validate the request
3) log the request type and validation in a database
4) route the incoming request to proper instance of service implementation ( we have two instances of the service implementation running )
5) cache the request/response
here is message flow nodes
MQ-Input -> HTTP-Input -> Validation -> DataInsert -> Route -> ... etc
My questions are
1) do I need a MQ for this implementation?
Is it possible to manage with out MQ and still serve our clients with minimal loss of requests?
Please note, I am asking this question after reading this, "The message flow can accept a new message for processing only when all paths through the message flow".
2) If the answer for previous question is yes, is appropriate to have MQ-input node followed by HTTP-Input node. Is this the best practice? Please suggest if otherwise.
Your help is greatly appreciated.
-Satya. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Dec 01, 2010 8:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can't wire anything to the front of any Input node, including MQInput or HTTPInput.
So your flow as laid out doesn't function.
I don't believe there's a standard defining what REST messages look like when they are stored in an MQ message rather than in an HTTP document.
I think you need to go back over your course materials from the broker training class that you took. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 01, 2010 8:31 am Post subject: Re: Message broker and REST services |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| satyabodharao wrote: |
| Through reading I have acquired some knowledge. |
If you think you can connect an MQInput node to an HTTPInput node (or that you'd want or need to) then you need to hit the books again.
| satyabodharao wrote: |
| 1) do I need a MQ for this implementation? |
Well you've got one (because the broker's using it) so why not use it?
| satyabodharao wrote: |
| Is it possible to manage with out MQ and still serve our clients with minimal loss of requests? |
Of course it's possible. The loss of requests is a function of the non-guaranteed nature of http transport; how you minimize this loss is down to your design and code.
| satyabodharao wrote: |
| If the answer for previous question is yes, is appropriate to have MQ-input node followed by HTTP-Input node. Is this the best practice? Please suggest if otherwise. |
Again I repeat; this is not just inappropriate and not best practice, it's impossible and unnecessary. To ask the question indicates to me you need to be reading a lot more.
Or get some formal training (as my most worthy associate obliquely indicates). 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| satyabodharao |
| Posted: Wed Dec 01, 2010 8:47 am Post subject: |
|
|
Newbie
Joined: 01 Dec 2010
Posts: 3
|
mqjeff and Vitor, Thanks for the quick response. I totally agree with you both, I am a novice in this subject and I need lots of reading.
Mean while could you please suggest me a basic flow for the above stated requirement? (Assuming that the requests are queued) .
Thanks,
Satya. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 01, 2010 9:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| satyabodharao wrote: |
| could you please suggest me a basic flow for the above stated requirement? (Assuming that the requests are queued) . |
Well the basic flow you have there seems nice, though clearly there's a fair amount of work in that "etc" you've got.
It's also worth pointing out (to increase the level of charity I'm displaying this morning to a level nearing "human") that you can have an MQInput node and an HTTPInput node fronting the same flow. How you route the response from the webservice back via the correct transport is an interesting but not insurmountable challenge in that circumstance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 01, 2010 9:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
And it's again not clear what the data looks like if it's written to a queue... among other things, it's not clear where any URL parameters would be put...
Also, parsing JSON in Broker is not a task for the faint of heart or skill. So be prepared to use some Java code if you need to deal with JSON data. |
|
| Back to top |
|
|
| satyabodharao |
| Posted: Wed Dec 01, 2010 9:32 am Post subject: |
|
|
Newbie
Joined: 01 Dec 2010
Posts: 3
|
Good to know, I am not totally off the base.
| Quote: |
| It's also worth pointing out (to increase the level of charity I'm displaying this morning to a level nearing "human") that you can have an MQInput node and an HTTPInput node fronting the same flow. |
I do not have any specific requirement to use both MQInput and HTTPInput nodes. I am happy to use just HTTPInput node if it is possible to receive messages from a queue one at a time using HTTPInput.
Also, I can use just MQInput node if it is possible to process http requests with out using the http specific nodes. ( by processing, I mean parse through the message for validation, logging etc)
If both are feasible, I would like to know which one scores over other.
| Quote: |
| Also, parsing JSON in Broker is not a task for the faint of heart or skill. |
At this time, we support only XML requests.
For routing, I want to use JavaCompute node (I am choosing this because, we have two instances of services running, so I can use out and alternate terminals of JavaCompute node to route the messages)
For caching, I am thinking of using user-defined nodes as I am not aware of any built-in nodes that comes ready with caching ability.
For reply, I will be using HTTPReply node. This single node will intake data from different nodes to send responses (Assuming that is possible)
Please comment.
-Satya. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 01, 2010 9:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| satyabodharao wrote: |
I do not have any specific requirement to use both MQInput and HTTPInput nodes. I am happy to use just HTTPInput node if it is possible to receive messages from a queue one at a time using HTTPInput.
Also, I can use just MQInput node if it is possible to process http requests with out using the http specific nodes. ( by processing, I mean parse through the message for validation, logging etc) |
You really, really need to hit those books again. Or get a refund on the training course. You can't use an HTTPInput node to receive a message from a queue (the clue is in the name) any more than you can receive an http request with an MQInput node (again the name is a clue).
Seriously. Read more. Think.
| satyabodharao wrote: |
| If both are feasible, I would like to know which one scores over other. |
Whichever is appropriate (i.e. works) for the transport mechanism you're using.
| satyabodharao wrote: |
| For routing, I want to use JavaCompute node (I am choosing this because, we have two instances of services running, so I can use out and alternate terminals of JavaCompute node to route the messages) |
Rather than the Route node, or an ESQL node with labeling? It's a very narrow view. Especially if someone ever decides to start a 3rd instance of the service to scale it up.
| satyabodharao wrote: |
| For caching, I am thinking of using user-defined nodes as I am not aware of any built-in nodes that comes ready with caching ability. |
You are by your own admission a novice. You seem to have some issues with the difference between an MQInput node and an HTTPInput node. And you want to do create a user defined node. something really advanced? It would be rude of me to say you're crazy.
You're crazy.
Define what you mean by "cacheing" & why you need (or think you need) it.
| satyabodharao wrote: |
| For reply, I will be using HTTPReply node. This single node will intake data from different nodes to send responses (Assuming that is possible) |
It's possible. It'll be a bit problematic if you're using WMQ as a transport layer as that node uses http.
| satyabodharao wrote: |
| Please comment. |
I think I've said it all. But I'll say the bit about reading, thinking & getting training again.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 01, 2010 10:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Even if you won't read, think, and get training..
Please at least TRY stuff before you follow up too much more. |
|
| Back to top |
|
|
|
|
