Im having some dilemas / questions regarding the adoption of WebServices and their place in the overall J2EE Architecutre.

A very common deployment seperates the web-tier (web-server) from the business-tier (application-server) and the data/integration-tier (databases and EIS).

More and more i see that the business-tier is requried to converse with external-services (Trading partners, Billing-systems etc). These services facilitate getting and updating data and are very much coupled with the business-tier logic.

The traditional 3-tier design mandates a separation between the tiers in terms of security (Virtual Lans, VPNs, or even firewalls between the tiers). This is considered a good habit, and reduces the risk of the business-tier and data-tier being exposed to external threats.

But today, we need to make this communication between external systems and the business-tier happen.
We can say that all web-service incoming and outgoing communication will be proxied by the web-tier.

Another alternative is to build vpns or vlans between all known partners for communication and the business-tier. But this only applies for predefined partners of communication (and not for services that are found dynamically).

If we say that the business-tier is the one to perform the integration with the external services then we open up another issue.
How does our J2EE servers behave when we open sockets (cause that whats happen when we make soap call), and worse, how would they react in extreme situations caused by communication problems to other systems (this is relevant to synchronous calls and less to 'messaging-like' calls).

So, what are the considerations in deciding where to put the code that sends the tentacles (er, calls web-services), what are the risks and how do you handle them,
What are you guys doing?
How does your J2EE servers react to soap calls from within your code?
What extreme situations did you encounter?

And most important, what am i missing here... :)

Any help would be appreciated,
Thanks, Yuval.