David
From: "Phil Steitz" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: Re: Struts application & infrastructure choices Date: Sat, 14 Dec 2002 15:00:38 -0700David Graham wrote:I would be surprised if RMI per se really turned out to be a significant performance bottleneck -- especially compared to a custom sockets implementation (which essentially amounts to rewriting application server functionality). The real issue is do you want to introduce EJBs, if the application does not already use them.
It should be fairly easy to implement this and do some performance testing. Your DAOs will be the only piece that changes to use RMI. You might try just using straight sockets because RMI is another layer on top of sockets which may slow you down.
David
If you don't want to use EJBs and you do want a physically three-tier setup, then you have a basic deployment/integration problem which some of us would argue is a strong argument to just use EJBs and RMI and rely on the infrastructure provided by J2EE. Here are a couple of other ways to solve this problem that I have seen successfully deployed in large-scale applications:
1. Remote HTTP Server
Physically split the HTTP server from the servlet engine, putting the combined servlet engine/business object (EJB container, if the business objects are EJBs) into a more protected location and leaving only the HTTP server exposed. This configuration is supported by most commerncal application servers. I don't know if you can do this using Apache and Tomcat or JBOSS.
The IBM site below is a bit cumbersome to navigate, but it includes a fairly comprehensive treatment of the deployment topology alternatives, nost of which can be deployed on non-WebSphere app servers:
http://www-106.ibm.com/developerworks/patterns/
More specifically, see
http://www-106.ibm.com/developerworks/patterns/u2b/at2-runtime.html
2. Dual servlet engines
Deploy a "front" servlet engine that includes the view and controller elements (struts would run here) and handle remote communication to a "model" servlet engine via HTTP. The "model" engine can run in a more secure location. A framework implementing the Command pattern can relatively easily be developed using URL objects to make the remoting of model elements transparent to the controller. The advantage of this over a custom sockets implementation is that you don't have to worry about managing the connections, threads, etc. for the "model" container. The disadvantage is that you have to develop the marshalling framework.
3. Standalone RMI servers on tier 2
Use standalone RMI servers for the "model" implementation. The advantage of this is that you don't have to develop any custom marshalling machinery. The disadvantage is that you don't have the resource and systems management infrastructure of an application server/servlet engine to rely on.
4. Web Services
Like 2., except use web services in place of the custom HTTP-based Command framework. If I were to start a new project with the requirements no EJBs+physical 3-tier, I would probably host the model components in a remote web container and expose them as web services, using Axis. See
http://xml.apache.org/axis/index.html
Of course, as David suggests, the important thing is to rapidly develop marshalling prototypes and benchmark. My experience has been that all of the remote marshalling methods described above can deliver very fast performance, as long as your service interfaces are not ridiculous. Performance problems almost always trace back to model component implementation or back end resource (e.g. RDBMS) response time issues.
-Phil
From: "Aymeric Alibert" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "<\"Struts Users Mailing List\"" <[EMAIL PROTECTED]>
Subject: Struts application & infrastructure choices
Date: Sat, 14 Dec 2002 10:38:19 -0600
Hello,
We are successfully running a large struts application. We designed it using a 'classic' architecture:
- A Tomcat server running the application in our DMZ.
- Use of Struts for our front-end and implementation of the DAO pattern to isolate our Data Access layer. Even if everything runs on the same server.
- Use of DBCP pooling from Tomcat to access our Oracle database.
Looking ahead, I can see needs for JMS connectivity or connection to various type of data sources within our company and to communicate with our partners.
Also, our security team does not like having a Tomcat server in the DMZ accessing more and more internal information systems. We would like to take our infrastructure to the next level.
I was thinking of introducing an Application Server within our firewall. It will implement our Data Access connectivity and the DAO on the Web Server will use RMI to access it.
I am a little afraid of performance degradation by introducing RMI between the Web Server and Application Server. Also deployment will probably be more complex.
Another solution would be to have both Web Server and App Server running on the same box in the DMZ. But that
does not solve my security concerns.
I don't have much experience with application servers and would not need the full features of a J2EE app server (at least not right now). Am I on the right path?
Does someone have advices or best practices to follow?
Aymeric.
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
