Raees, I had posted a reply to this question on SCEA_PREP. I am attaching the same reply here for your benefit. HTTP tunneling is primarily used for masquerading other protocol requests as HTTP requests so that the firewall will let them pass. You are faced with the issue if you want clients (and I am assuming rich clients, in your case) want to communicate with your EJBs. It is a non-issue for Web clients because they will communicate via the web tier anyway. Of course there is a software way around the issue as well. You use servlets as wrappers for all calls (web based or otherwise), so that you have a single point of interaction between web and EJB Tiers. In other words, it is not a good practice to have the client tier directly communicate with the EJB tier...this affects the maintainability and manageability of the system. If you make changes to your EJB tier, you should not have client-tier dependencies to think about. Web Clients --> Protocol Router --> Front Controller --> Dispatcher Rich Clients --> PR --> RC Controller --> Dispatcher is a better architecture. HTH.
Sanjay Raghavan<br />SCJP2, SCEA-J2EE<br />Moderator - <a href="http://groups.yahoo.com/group/scea_prep" target="_blank" rel="nofollow">SCEA PREP</a><br />Co-Author - <a href="http://www.whizlabs.com/scea/scea.html" target="_blank" rel="nofollow">SCEA@Whiz</a><br /><i>Where did you sip your Java Today?</i>
Joined: Aug 15, 2002
Thanks Sanjay, I was concerned about the performance loss that will occur if every request goes through a Servlet. But I think a Servlet (based solution for both clients) is necessary to authenticate every incoming requests ( intercepting filter ). Hope this will pass the speed requirements for both the client
Your job may be easier depending on what Application Server you are using. For example, WebLogic supports tunneling T3 connections over HTTP. Therefore, it would be very easy for a client to communicate directly with an EJB over port 80. Of course, this solution would tied to the vendor, so if this question is relating to the SCEA assignment than I would stick with a vendor agnostic approach.
Originally posted by Chris Mathews: ... tunneling T3 connections over HTTP. ... would (be) tied to the vendor ...
Hi Chris, your approach would be the one I would prefere. But there are two contradictionary things I do not understand: 1. "tied to the vendor" as you wrote, and 2. Mark Cade & Simon Robert: Sun Certified Enterprise Architect for J2EE Technology,
- page 147: "IIOP ... can tunnel through port 80/HTTP". So if we use RMI-IIOP, how can that be "tied to the vendor"? - page 149: "tunneling using HTTP ... is supported by JRMP". So if we use RMI-JRMP, how can that be "tied to the vendor"? - How does the deployer(?) or client(?) decide/configure wether to offer/use RMI-IIOP or RMI-JRMP? The client by knowing the port number of the desired service / finding the necessary port number appended to the url? I.e. like www.mydomain.com:1099 for JRMP? These questions are very important to me. Thomas.