So the web service in step 5 is hosted on IS, correct?
When the request is published, I assume there is an IS-hosted subscribing service for each of the partner systems. That subscriber then does whatever it needs to communicate with the partner and get the data and then does a reply. Is that an accurate?
If that’s the case, and you end up needing to do deliverAndWait then the pub/sub approach isn’t providing any benefit–since the main service now needs to know about all the targets and deliver to each of them.
Two alternatives come to mind.
- The Java API of Broker can be used to do this. You’ll need to write some Java code and be a direct Broker client rather than relying on IS facilities. If you want to host this within IS, which is doable, you’ll need do avoid using the built-in services to do the work. You might be able to leverage the IS connection to Broker, but you may also need to manage a connection yourself.
The upside is this is that it preserves the intent of pub/sub by making the main service unaware of all the partners. It just knows its going to get multiple responses and it doesn’t care where they come from. You’ll have one component managing the request (via pub not deliver) and all replies, instead managing multiple threads.
The downside is it won’t be a “normal” IS-Broker interaction which might confuse others down the road.
- Another option is to have the main service call all the partner services directly, rather than via the Broker deliverAndWait. If you have to increase the coupling by using deliverAndWait, might as well go the tiny bit further and just call the IS services directly (if my assumption about the interaction with each partner being done with an IS service is right). You’d use the threaded approach here with doThreadInvoke of each service and then join each later. My concern here is the managing the timeout of each join. I’m not sure if you can control each individually and one slow partner could hold up the whole works–and if multiple partners are late, then your SLA will be toast.
Upside is that this would be a more “normal” IS implementation. Downside is the thread management funkiness that might torpedo the whole thing.
Hope this helps!