| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMB 7 SOAP Nodes port |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Wed Jun 01, 2011 3:56 am Post subject: WMB 7 SOAP Nodes port |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
By now I've read heaps of material on the whole 'find the port' issue in V7, concerning http nodes, soap nodes, biphttplistener etc, and I just want to ask one simple question:
Is it possible to configure all SOAP nodes to listen on one port, maybe the biphttplistener port, despite being in seperate EGs?
I'm 99% sure the answer is no, but there are a few reason I wanted to make sure:
1. It's possible to have http nodes listen on the EG listener, so I thought maybe the reverse might be possible.
2. The fact that each EG has a seperate port creates a much more complex and messy network, especially on the specific site I'm on now. Having one port for all webservice flows will simplify my setup immensely, sparing me from adding and managing an additional component (Apache or Tomcat with proxy servlet), whose main operation is url-to-port mapping, so clients are not exposed to port changes.
I'm also wondering if IBM might consider adding this feaure in the near future. Probably not, given the way the broker manages SOAP nodes threads, but I hope I'm wrong.. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jun 01, 2011 4:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The reason that Broker in earlier versions was able to accept all HTTP requests for a given broker on a single port was because the HTTP handling was offloaded to the bipHTTPListener process.
A single network address and port can not be READ from by more than one process.
Because there is no such thing as a "broker" process, merely a set of DataFlowEngine processes, the EGs can't all listen to the same port for incoming SOAP requests.
So, the answer to your question is indeed 'No'. The bipHTTPListener is not capable of providing the necessary infrastructure to meet the needs of the SOAP standards.
There is a conflicting set of requirements in this area.... lots of people "want" to have a single port for all the HTTP requests to a given Broker, but they also balk at the notion of maintaining something like the bipHTTPlistener - a separate, standalone process that is not as directly manageable as a given EG.
You might, however, consider the support available in v7.0.0.2 (maybe 7.0.0.1, I've forgotten) to create a SOAPInput node that acts as a WS passthrough.
You could then construct a flow that acted as a proxy for all your real flows - and deploy this to a single EG. And construct a similar flow for your HTTP requests.
Then you have a single EG that acts as the official 'endpoint' of all your requesters, and this is on a single fixed port, and you then route data internally to the rest of the EGs on their ports.
But this is likely at least as much work as configuring the HTTP Proxy Servlet - except it doesn't require additional web containers. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Jun 05, 2011 2:47 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
| There is a conflicting set of requirements in this area.... lots of people "want" to have a single port for all the HTTP requests to a given Broker, but they also balk at the notion of maintaining something like the bipHTTPlistener - a separate, standalone process that is not as directly manageable as a given EG. |
Well, to me it seems rather obvious that some sort of distributer is necessary; and it shouldn't be that difficult to add some sort of basic management to this process, say httpsoaplistener, through the toolkit or otherwise..
| mqjeff wrote: |
You might, however, consider the support available in v7.0.0.2 (maybe 7.0.0.1, I've forgotten) to create a SOAPInput node that acts as a WS passthrough.
You could then construct a flow that acted as a proxy for all your real flows - and deploy this to a single EG. And construct a similar flow for your HTTP requests.
Then you have a single EG that acts as the official 'endpoint' of all your requesters, and this is on a single fixed port, and you then route data internally to the rest of the EGs on their ports.
But this is likely at least as much work as configuring the HTTP Proxy Servlet - except it doesn't require additional web containers. |
By WS passthrough you mean it's possible not to supply a wsdl?
That sort of solution has come in discussions here, but I'm trying to have the least amount of coding involved. And like you say, it sounds like as much work as the proxy servlet, or much more. Finally, this sort of design will block me from monitoring the individual flows, unless I monitor them directly, thereby missing the whole point. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jun 05, 2011 7:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, there is a way to configure a SOAPInput node to accept all SOAP traffic, and not validate against a specific given WSDL.
Yes, it means that if you monitored this flow, you wouldn't necessarily know which "real" SOAP flow was going to be called later - although I strongly suspect that the actual URL information will still be visible from a monitoring point of view.
The problem with creating an additional standalone process - bipsoaplistener or whatever - is that you are then really re-inventing the wheel, and most customers if you are going to make use of an external http container separate from the message flows really do end up wanting to have some choice and control over what that container is. And, again, there certainly are customers who just want to integrate Broker's http functions into their standalone WAS/IHS configurations.
But unfortunately, you really need to be having this conversation with the development team directly, through a Requirement. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jun 08, 2011 7:44 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| mqjeff wrote: |
| Yes, it means that if you monitored this flow, you wouldn't necessarily know which "real" SOAP flow was going to be called later - although I strongly suspect that the actual URL information will still be visible from a monitoring point of view. |
Visible, yes, most probably, but not a reliable source for knowing whether the "real" processing flow is up or down. And since HEAD requests do not activate the gateway flow - which is the whole point - there's no way to program it either.
| mqjeff wrote: |
| But unfortunately, you really need to be having this conversation with the development team directly, through a Requirement. |
And so I shall. I'd like to see a soaphttplistener as an option, at least.
Much obliged, as always  |
|
| 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
|
|
|
|
