HTTP tunnelling or SOAP with HTTP?

HTTP tunnelling or SOAP with HTTP?

I have to write a 3-tier app in a bank. There's a WebSphere AppServer in a DMZ. That's where my BOM-Objects (SessionBeans) will be contained. My Java thin clients will run on NT-Machines in the corporate network. The only open port for communication between the app. server and the clients is http. What are possible solutions for this issue without changing the environment documented above? I see the following possiblities: (1)Using RMI/IIOP tunnelled trough HTTP (2) Using SOAP with HTTP. What would you suggest?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Most Web servers have unique implementations of HTTP Tunneling and some have no support at all. This makes HTTP tunneling tricky at best. Further complications are added when attempting to move from one EJB Server to another. Proprietary extensions added by EJB vendors for many developers into supporting only one or two EJB providers. RMI, which is fairly beefy, with stub code downloading, distributed garbage collection, client-activation, RMI registry code, etc. is also starting to scare developers away. With these things in mind, many engineers are turning to a two-way, client-callback solution.

In a two-way, client callback solution, the client first attempts to establish a connection to the server using sockets. If the client can connect successfully to the server over an arbitrary socket connection, the server discovers the client's location and establishes a callback-socket connection in which to relay messages over. If firewall issues prevent the arbitrary socket connection from succeeding, then the client morphs into a client-side HTTP-server. At this point, the client and server can communicate over port 80 using HTTP requests/responses.

With the communication channel in place, the server acts as a front controller that dispatches requests to the appropriate business-logic modules (Java classes, Java Beans EJBs, SOAP provider, etc.). The server then receives the results from the business-logic modules, formats them for the client and passes them back to the client over the communication channel.

Using the data-format protocol is a decision that should be made based on the needs of the client and the services provided by the server. XML data formats such as SOAP are becoming more and more prevalent and generally prove to be a safe bet for a generic implementation.

This was first published in April 2002

Back to top