I don’t think I fully understand the problem, but I do think that you are attempting to overengineer a solution. I will try to address what I understand.
1/2) Why a reverse invoke? For arguments sake, the internal IS handles the processing with your internal systems, and the DMZ IS handles external requests/replies. For any transaction, the DMZ IS would handle the receive from trading partners, and would also post (via https it seems) to the trading partner.
For the TN questions, I think you can have TN inside the firewall, assuming that the DMZ IS is just a pass through.???
- If documents are delivered via a VAN, they won’t hit the DMZ IS? Why have the DMZ IS if it doesn’t accept all transactions? I assume these are EDI transactions…which either IS could handle.
I think my best suggestion would be to take a step back and define the architecture you are looking for to process the transactions. Then begin to define areas where there may be security issues. In my previous experiences (which includes industries that have sensative data such as banks and DoD), I have not needed to create an abnormal architecture. I have been to a client that had the DMZ IS provide all the core processing (receive, map, etc), and the internal IS makes the calls to the internal systems). The DMZ is would do a remote invoke to the internal IS. We didn’t do reverse invokes, but would assume it would occur in the same fashion.
Hope that helps a bit…
#webMethods-Architecture#Integration-Server-and-ESB#webMethods-General#webMethods