Http/Https asynchronous handle implementation in WMB

Here I present simple option to work with the Http nodes in an asynchronous way.
The http/https in Websphere Message Broker handled by Http Listener process.
You may also work with IE01 support pack to implement the functionality of the WebSphere Message Broker HTTP listener in an external Servlet Container.

WMB Http/Https Handling in General:

Http Listener communicates with the broker by those three queues:



Each http request is written to the SYSTEM.BROKER.WS.INPUT queue which than picked up by message flow (correlation made by the URL written in the HTTP Input Node).
The HttpInputHeader is constructed from the http header data contained in the message.
Here is an example of the written request message by Http Listener to the SYSTEM.BROKER.WS.INPUT Queue:



After the message flow processing the reply message is written to the SYSTEM.BROKER.WS.REPLY queue by the Http Reply Node
(The correlation is done by MQ correlation, the correlation ID is written by the HttpInput Node to LocalEnvironment.Destination.HTTP.RequestIdentifier) which then picked up by the Http Listener process and return to the Http client.

You can find more details on this link.

The asynchronous Implementation:

I implement this scenario by two message flows, First flow receives the request and the second flow sends the reply. They connected by WMQ and they can be deployed to different execution groups.

First you receive the request.



Then construct the MQMD and store the RequestIdentifier in the MQMD header,MsgId.




At the end puts the message on the queue.


Get the message from queue.



Set the http reply correlation field by the MQMD MsgId and Optionally you can Remove the MQMD and the HttpInput headers.



That is all you need to do to make a synchronous façade for an asynchronous transaction in WMB.

SOI with WMB

It's is very strange thing but I think that IBM missed a very important feature in websphere message broker design, the Infrastructure assets.
Each organization has its own assets which its develops and customize for their use.
In the SOA approach you build infrastructure services and application for reuse.
The reuse option in WMB can be achieved by the subflow ability.
Subflow is a regular message flow with small difference, It starts from Input node, logic inbound port and not physical one. ( Like direct ports in Biztalk).
You than can drag your subflow to the your message flow, it would be represented by single node.
What really happens there is an inline copy of the subflow to the message flow during the bar compilation. Thus you getting different copy of your subflow during each bar compilation.
It's like they didn't hear about REFERENCE in IBM.
So now for example you developed a logging subflow, or generic error handler. You put the subflow in all your projects.
Now if you make change in your subflow you need to recompile all of your message flows projects!
And here is the problem.
Every time you make change in your infrastructure you need to recompile all your projects.
This is a major development issue.

Some Tips to ease on this issue:

- Develop as many as you can of your infrastructure in java. thus won't need to
recompile your projects.
- Use scripting abilities of the webpshere message broker to recompile/redeploy the projects.
http://www.ibm.com/developerworks/websphere/library/techarticles/0706_spriet/0706_spriet.html

Working now on different approach to solved this, will post more details on it soon.
Hope to achieve the right agility with websphere message broker.