I favor approach 2.
Ask yourself the following question. How will a message best survive and guarantee delivery when connectivity is lost between webMethods and fusion? With approach 2, the message sits in the webMethods broker until the client app, fusion, reconnects and retrieves the message. With approach 1, attempting to guarantee delivery of the message to fusion is not as graceful.
Ask yourself the following question. In the future if an additional system wants to also subscribe to the same message, which tier should be the provider, webMethods or fusion? I would think webMethods. Therefore approach 2 solves this most gracefully.
It sounds like webMethods is implemented to provide systems integration in the scenario you described. Therefore, my following suggestion assumes that the webMethods tier is the middle tier, the ESB. My suggestion is focused around decoupling the tiers in your architecture and guarantee delivery of the message.
I favor approach 2. This approach decouples the sender from the receiver better than approach 1. With approach 2, webMethods is decoupled from the target system. webMethods has no knowledge of the target system. With approach 1, it sounds like a point to point to point to point solution.
With approach 2, webMethods publishes the message to its broker for any client subscribing to it may receive it. You explained that fusion sends the data to the target systems. This tells me that fusion has knowledge of the target system. Therefore, coupling already exists between fusion and the target system. That’s OK.
I have seen solutions where fusion is imbedded as part of an Oracle application. The Oracle app cannot function without its fusion module. If this is your case, then definitely approach 2 is your best solution because I see fusion and the Oracle app as an application.
#webMethods-Architecture#webMethods-General#Integration-Server-and-ESB#webMethods