Typical DMZ/Firewall client concerns, etc

How do you usually address client concerns for security at the firewall? Do most of you use the reverse proxy mechanism recommended by webmethods? (requiring 2 webmethods server installs). Do you go right through the firewall to the internal network? Do you have clients request the files from your server? (initiating the request on their end). Do you ever put files on the DMZ for the client to pick up?

I would like to get a forum going on practical issues such as these (not-specific to GEAR necessarily), as well as dealing with non-xml files (incoming/outgoing) with trading networks (or when sender/receiverID’s are not in the document). Many backend systems deal with comma/tab delimited files, etc.


We actually set up the 2 tier architecture before knowing that webMethods recommended the reverse invoke.

Agree that a 2 tier architecture is best, where a server in the DMZ protects the internal webMethods servers. There’s advantages & disadvantages to using a webMethods server in the DMZ compared to an ordinary proxy server. Advantages include better processing of documents (since proxy servers don’t generally understand the XML documents being sent in), better resilience to buffer overrun attacks (since it’s all Java), and less familiarity to attackers (a “security through obscurity” defense). Disadvantages include less familiarity to the IT organizations that manage most DMZs.

So there’s not a right or wrong approach on this… like anything with security, it’s a matter of tradeoffs.

As for Reverse Invoke vs. webMethods acting as a Reverse Proxy, there are again pros & cons for each. For many organizations, it’s important not to have any inbound traffic through the internal firewall, and reverse invoke allows passing the data without initiating any inbound communications. Some organizations want to avoid having any authentication information stored in the DMZ, which is a perfect fit for Reverse Invoke, since it just passes the data to the internal server. Other organizations want to validate all user identities in the DMZ before allowing the traffic in, which can’t be done by Reverse Invoke.

I wouldn’t say there’s a universally recommended approach. It’s what’s better for your organization.

Jeremy Epstein
Director, Product Security


The disadvantage as I see it with letting only the front end server access the back end server is that if someone gains control of the front end server in the dmz, the backend server will still allow it through. So I guess the reverse invoke would be preferred, but then you have 2 webmethods servers that network IT people aren’t familiar with (and potentially requiring administration by us). I guess the bottomline is that if you have multiple options and costs associated, the client can choose what degree of security they want. I also don’t think storing files on the dmz is a good idea, but if a client wants to initiate the request without using a reverse invoke, we have to queue up the documents somehow.
Thanks for your responses!

Can you throw some light on how to do to “Reverse Invoke” settings.

Best place to start is Chapter 8 of the Integration Server Administrator Guide.


I want to know if the resilience mechanism exists into nirvana regarding Integration Server because resilience allows to take flow back one where he was arrested.

Could you help me please?