Schematic Of Brokerage App

FlowBasedProgramming Example

Requests (transactions) coming from users enter the diagram at the upper left, and responses are returned at the lower left. The "back ends" (on the right side) communicate with systems at other sites using CORBA (CommonObjectRequestBrokerArchitecture) or MqSeries. The cross-connections represent e.g. requests that don't need to go to the back ends, or requests that have to cycle through the network more than once before being returned to the user.

For more information, see http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication.

Can you describe the point of this? Why would I want such an architecture? Why are there two points where requests can be short-circuited (ProcessRequest and Router)? Why are there two points where requests can be recycled (ProcessResponse and HandleBack-endData)? How are decisions made to short-circuit or recycle? Is there any assurance that this won't enter an infinite loop?

Re the first two questions, see material on FlowBasedProgramming - too much to repeat here.

Re the next couple of questions, if an error is detected in the initial request, you may want to go back to the user, rather than continue on to the back end. Similarly, some requests may require several passes to the back end(s) before returning to the user with the final answers. It doesn't hurt to have the paths available in the network - it is the program logic that decides whether to use them or not. I suppose you could enter an infinite loop, just as with any piece of code - again, it is the application logic that decides whether all necessary processing has been completed.