RE: [OT]: Struts, Web Development, J2EE, and what is too much?
As always, you get what you pay for. If your goal is to minimize the amount of developer effort expended, it's going to be hard to do less work than you would with Hibernate. The downside is that Hibernate isn't exactly high-performance as compared to your own compiled code; this isn't surprising since most of the heavy lifting is accomplished via static reflection which is traditionally 10-15 times slower than directly compiled function calls. Each version of the JDK improves that ratio somewhat, but it's probably never going to get all that close to 1. The upside is the cache is built-in and you don't have to write much (if any) extra code to get persistence. If what you want is raw performance, then straight JDBC is probably your winner (caveat attached below). Abstractions add expressivity and flexibility, but the cost is generally measured in performance metrics. The downside of direct JDBC is you have to write your own O/R mapping code, or write/use an O/R mapper like CoCoBase or Jaxor. You also have to write your own caching code, even if you decide to use Turbine JCS or TopLink ... they only provide the API and you're still on the hook for the glue. Either way, you've got some work ahead of you. But that's why we're raking in the big dot-com dollars, right? BWA-hahahahaha. Ahem. Arguing for EJBs for purely performance reasons is Marc Fleury of the JBoss project. His thesis is stated in http://www.jboss.org/blue.pdf>, and I wouldn't reject his thinking out of hand given the track record of the J2EE container he's spearheading. sometimes-more-is-more-ly y'rs, +Mitchell > -Original Message- > From: Molitor, Stephen [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 12:44 PM > To: 'Struts Users Mailing List' > Subject: RE: [OT]: Struts, Web Development, J2EE, and what is > too much? > > > Aaron, > > You've opened up a big can of worms! There is much debate on > this topic. > > Regarding entity beans and transactions: The recommended > practice is to use > the 'Session Facade' pattern to wrap access to your entity > beans inside a > stateless EJB session bean. The reason is remote calls to > entity EJB's are > too slow. Instead, only use local interfaces for you entity > beans. Your > Struts actions would never talk to entity beans directly; > instead they would > call 'service' methods on session beans. This also means you > need lots of > little data transfer beans to transfer the data in and out of > the session > facade. (Or you can sacrifice explicitness and type safety and use > dyna-beans.) The session facade also provides a good place > for transaction > boundaries. An action will usually call one method on the > session bean, and > that method is a transaction. The user hits a button, and > either all his > changes or saved, or they all get rolled back. That kind of 'atomic > request' is a nice simple transaction model that works for > most situations. > > However, there is a lot of extra effort involved in creating > the session > facades and data transfer objects, and keeping them in sync. > Example: the > xPetStore application, which shows how to use xDoclet, was implemented > twice, once using EJB, and once using just Servlets and > Hibernate (an open > source O/R mapping tool). Excluding the code that xDoclet > generated for > you, the EJB version still had more than twice as many lines > of source code > in the business tier compared to the Hibernate version. So > even with a tool > like Xdoclet, there is still significant extra cost to doing EJB. > > Also, as Robert alluded to, EJB entity beans don't really support > object-oriented development. A good OO domain model is typically fine > grained, with inheritance, relationships to other objects, > etc. The fact > that entity beans don't allow re-entrancy (object 'a' calls a > method on > object 'b', which calls a method on 'a'), inhibits your > entity model. Of > course, if your business model is simple, that might be OK. > > IMHO, the only compelling reason to use EJB is if you need to > provide access > to remote Java clients to your business tier. (Web services > are another > option that also supports non-Java clients. But they do add > overhead.) > Even there, I would just use session beans, not entity beans. > In our app, > we're using Struts with Hibernate and doing everything in the > web container. > We have a servlet filter that start, stops and rolls back the > transaction; > the 'atomic request' approach. Getting EJB out of the mix > really simplified > things for us. We do have a few
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
Aaron O'Hara wrote: Thanks for you detailed reply. Is it a safe to say that if all the following are true, EJBs may not be a wise choice: -- I want to provide DB Vendor specific queries that are optimized to take advantage of each vendor -- the application has only 1 front end, servlets/jsp -- There is only one "data store" and transactions do not span more than 1. -- entity model is far different than object model I find that in my design, the object model differs greatly from database. From an application's perspective, you design it so that it is usable and uses appropriate modeling based off of the requirements of the application. For example, if you stored all email addresses in a separate table and had a contact table, you may decided that your object model will have an emailAddress field and not a foreign key reference to the record in an EmailAddress object. I find this to occur in almost all applications I end up developing. Especially when the database already exists. Joining across tables is not something entity beans handle well... They also don't support stored procedures, if you are using them. From a database design point of view, you may interpret the requirements and design the database based on a number of different factors, such as normalization, performance, etc. An application that is report-heavy may benefit from de-normalized design whereas an input-heavy may benefit from a highly normalized design. Based on that line of thinking, one may decide to put all email addresses in a separate table. (This is not a great example, since most contacts will have a unique address, but hopefully my point is still coming across). Given the above, does it make sense that EJBs are not necessary and I would not receive a great benefit from them? I would say yes in your situation. - Robert Thanks, Aaron -Original Message- From: Robert McIntosh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:39 AM To: Struts Users Mailing List Subject: Re: [OT]: Struts, Web Development, J2EE, and what is too much? Tony made some good points, and my take is that from your requirements, you may not need EJBs. However, if you layered your app sufficiently, then if you end up needing them later on, it shouldn't be too much of a problem. Of course I am assuming you are referring to Entity beans in this case... As for when to use EJBs, what I have always recommended to our clients is that EJBs are good for large scale applications that run on clustered machines and require transactions at the entity bean level. The transactions are good if you have multiple apps and clients that are modifying the same data. If your app is largely read only, it is the only one interacting with the data and you aren't worried about concurrent modifcation, then you probably don't need entity beans. Yes, most app servers can cache and mark entity beans as read-only or mostly read-only for performance, but there are other ways of doing the same thing. Another thing to consider is how your object model is designed. If you have lots of inheritance, entity beans aren't going to fit you well. Same can be said if you have complex query requirements (joins, relationships that the object model doesn't support, etc.). Then again, in some cases as Nash pointed out, EJBs can be simplier from the perspective that any good app server can build the database for you and with tools like XDoclet, you don't have to write deployment descriptors and you don't have to maintain (i.e. code) the interfaces for home, remote and local. - Robert Aaron O'Hara wrote: I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-ma
RE: [OT]: Struts, Web Development, J2EE, and what is too much?
Thanks for you detailed reply. Is it a safe to say that if all the following are true, EJBs may not be a wise choice: -- I want to provide DB Vendor specific queries that are optimized to take advantage of each vendor -- the application has only 1 front end, servlets/jsp -- There is only one "data store" and transactions do not span more than 1. -- entity model is far different than object model I find that in my design, the object model differs greatly from database. From an application's perspective, you design it so that it is usable and uses appropriate modeling based off of the requirements of the application. For example, if you stored all email addresses in a separate table and had a contact table, you may decided that your object model will have an emailAddress field and not a foreign key reference to the record in an EmailAddress object. >From a database design point of view, you may interpret the requirements and design the database based on a number of different factors, such as normalization, performance, etc. An application that is report-heavy may benefit from de-normalized design whereas an input-heavy may benefit from a highly normalized design. Based on that line of thinking, one may decide to put all email addresses in a separate table. (This is not a great example, since most contacts will have a unique address, but hopefully my point is still coming across). Given the above, does it make sense that EJBs are not necessary and I would not receive a great benefit from them? Thanks, Aaron -Original Message- From: Robert McIntosh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:39 AM To: Struts Users Mailing List Subject: Re: [OT]: Struts, Web Development, J2EE, and what is too much? Tony made some good points, and my take is that from your requirements, you may not need EJBs. However, if you layered your app sufficiently, then if you end up needing them later on, it shouldn't be too much of a problem. Of course I am assuming you are referring to Entity beans in this case... As for when to use EJBs, what I have always recommended to our clients is that EJBs are good for large scale applications that run on clustered machines and require transactions at the entity bean level. The transactions are good if you have multiple apps and clients that are modifying the same data. If your app is largely read only, it is the only one interacting with the data and you aren't worried about concurrent modifcation, then you probably don't need entity beans. Yes, most app servers can cache and mark entity beans as read-only or mostly read-only for performance, but there are other ways of doing the same thing. Another thing to consider is how your object model is designed. If you have lots of inheritance, entity beans aren't going to fit you well. Same can be said if you have complex query requirements (joins, relationships that the object model doesn't support, etc.). Then again, in some cases as Nash pointed out, EJBs can be simplier from the perspective that any good app server can build the database for you and with tools like XDoclet, you don't have to write deployment descriptors and you don't have to maintain (i.e. code) the interfaces for home, remote and local. - Robert Aaron O'Hara wrote: >I know this question has probably been asked before, and that biased >publications have had their opinions on it, but I wanted to get some >feedback regarding some "real user experience" regarding the use of EJB >in a web application used along with Struts. > >I am creating a web application and I have decided to use struts. The >application needs to be high performance, uses a single database (so it >doesn't have heterogeneous transactional db requirements). I have >designed the application in layers, and it will only have a web >interface. It's starting small, but will grow to have many functions. >Even though I'm confident that I need not invest in EJB's, I don't want >to develop the application to find out I should have used them (hence >why I'm creating this post). > >In what scenarios have people found the use of EJB beneficial? When >have they been overkill? Does struts integrate smoothly with EJBs? > >My fear is that I'll make the application overly complex by implementing >EJBs, but I'd like to hear from people with experience building large >web-only projects with struts. > >Thanks, > >Aaron > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT]: Struts, Web Development, J2EE, and what is too much?
Aaron, You've opened up a big can of worms! There is much debate on this topic. Regarding entity beans and transactions: The recommended practice is to use the 'Session Facade' pattern to wrap access to your entity beans inside a stateless EJB session bean. The reason is remote calls to entity EJB's are too slow. Instead, only use local interfaces for you entity beans. Your Struts actions would never talk to entity beans directly; instead they would call 'service' methods on session beans. This also means you need lots of little data transfer beans to transfer the data in and out of the session facade. (Or you can sacrifice explicitness and type safety and use dyna-beans.) The session facade also provides a good place for transaction boundaries. An action will usually call one method on the session bean, and that method is a transaction. The user hits a button, and either all his changes or saved, or they all get rolled back. That kind of 'atomic request' is a nice simple transaction model that works for most situations. However, there is a lot of extra effort involved in creating the session facades and data transfer objects, and keeping them in sync. Example: the xPetStore application, which shows how to use xDoclet, was implemented twice, once using EJB, and once using just Servlets and Hibernate (an open source O/R mapping tool). Excluding the code that xDoclet generated for you, the EJB version still had more than twice as many lines of source code in the business tier compared to the Hibernate version. So even with a tool like Xdoclet, there is still significant extra cost to doing EJB. Also, as Robert alluded to, EJB entity beans don't really support object-oriented development. A good OO domain model is typically fine grained, with inheritance, relationships to other objects, etc. The fact that entity beans don't allow re-entrancy (object 'a' calls a method on object 'b', which calls a method on 'a'), inhibits your entity model. Of course, if your business model is simple, that might be OK. IMHO, the only compelling reason to use EJB is if you need to provide access to remote Java clients to your business tier. (Web services are another option that also supports non-Java clients. But they do add overhead.) Even there, I would just use session beans, not entity beans. In our app, we're using Struts with Hibernate and doing everything in the web container. We have a servlet filter that start, stops and rolls back the transaction; the 'atomic request' approach. Getting EJB out of the mix really simplified things for us. We do have a few cases where a remote Java client needs to talk to our business tier, so we will probably use EJB remote session facades for that. But we'll only do the extra work when and where we need it. Hibernate allows you to declaratively cache read-only objects. (Or read-write too, if you're not using a cluster.) Ted Husted has an example app on his page using Struts and Hibernate. OJB is another popular option. Long term, JDO may or may not catch on . All of these tools over true transparent, object-oriented persistence, in stark contrast to EJB entity beans. Steve -Original Message- From: Robert McIntosh [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 10:39 AM To: Struts Users Mailing List Subject: Re: [OT]: Struts, Web Development, J2EE, and what is too much? Tony made some good points, and my take is that from your requirements, you may not need EJBs. However, if you layered your app sufficiently, then if you end up needing them later on, it shouldn't be too much of a problem. Of course I am assuming you are referring to Entity beans in this case... As for when to use EJBs, what I have always recommended to our clients is that EJBs are good for large scale applications that run on clustered machines and require transactions at the entity bean level. The transactions are good if you have multiple apps and clients that are modifying the same data. If your app is largely read only, it is the only one interacting with the data and you aren't worried about concurrent modifcation, then you probably don't need entity beans. Yes, most app servers can cache and mark entity beans as read-only or mostly read-only for performance, but there are other ways of doing the same thing. Another thing to consider is how your object model is designed. If you have lots of inheritance, entity beans aren't going to fit you well. Same can be said if you have complex query requirements (joins, relationships that the object model doesn't support, etc.). Then again, in some cases as Nash pointed out, EJBs can be simplier from the perspective that any good app server can build the database for you and with tools like XDoclet, you don't have to write deployment descriptors and you don't
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
Tony made some good points, and my take is that from your requirements, you may not need EJBs. However, if you layered your app sufficiently, then if you end up needing them later on, it shouldn't be too much of a problem. Of course I am assuming you are referring to Entity beans in this case... As for when to use EJBs, what I have always recommended to our clients is that EJBs are good for large scale applications that run on clustered machines and require transactions at the entity bean level. The transactions are good if you have multiple apps and clients that are modifying the same data. If your app is largely read only, it is the only one interacting with the data and you aren't worried about concurrent modifcation, then you probably don't need entity beans. Yes, most app servers can cache and mark entity beans as read-only or mostly read-only for performance, but there are other ways of doing the same thing. Another thing to consider is how your object model is designed. If you have lots of inheritance, entity beans aren't going to fit you well. Same can be said if you have complex query requirements (joins, relationships that the object model doesn't support, etc.). Then again, in some cases as Nash pointed out, EJBs can be simplier from the perspective that any good app server can build the database for you and with tools like XDoclet, you don't have to write deployment descriptors and you don't have to maintain (i.e. code) the interfaces for home, remote and local. - Robert Aaron O'Hara wrote: I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
Aaron, Try not to think just in terms of EJBs. Instead picture the scenario of persistence management in general. Throw CMPs, BMPs, JDO, Session Beans, Etc. out on the table and consider what each is buying you. In some cases the benefit is in providing a JNDI lookup for other Apps to use if you have several clients using your module. In other cases the benefit is in the memory management features that allow an EJB container to out-perform the servlet container. For myself, I am in the process of ramping up the use of JDO within stateless session beans and Struts is providing the major command pattern breakout of different use cases in the servlet container. A lot of the lower level conditionals and case statement logic for data gathering/updating is in the session beans... some of which uses the strategy pattern for conditionally different persistence management operations. -Tony Aaron O'Hara <[EMAIL PROTECTED]> wrote:I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . . . Tony Baity . . . - Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
Aaron, There is no right answer to your question. Read Chapter 1 of 'J2EE Design and Development' book by Rod Johnson. Mark. Aaron O'Hara wrote: > I know this question has probably been asked before, and that biased > publications have had their opinions on it, but I wanted to get some > feedback regarding some "real user experience" regarding the use of EJB > in a web application used along with Struts. > > I am creating a web application and I have decided to use struts. The > application needs to be high performance, uses a single database (so it > doesn't have heterogeneous transactional db requirements). I have > designed the application in layers, and it will only have a web > interface. It's starting small, but will grow to have many functions. > Even though I'm confident that I need not invest in EJB's, I don't want > to develop the application to find out I should have used them (hence > why I'm creating this post). > > In what scenarios have people found the use of EJB beneficial? When > have they been overkill? Does struts integrate smoothly with EJBs? > > My fear is that I'll make the application overly complex by implementing > EJBs, but I'd like to hear from people with experience building large > web-only projects with struts. > > Thanks, > > Aaron > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
I use Jboss. It works quite well with struts. EJBs have made my application EASIER and LESS complex for me, but I don't know any SQL or database technologies at all. If you're comfortable with managing your own database widgets, you may be frustrated with how slow J2EE is on your hardware and you may also be frustrated you can't access some of the more advanced functions easily. Performance is an issue as you pay mad overhead for the RMI stuff in J2EE. Much slower than native JDBC. If you can afford to upgrade your hardware, you may benefit. YMMV, but, I like it. I'm just using struts for presentation. -nash On Monday, March 10, 2003, at 05:41 PM, David Graham wrote: I've never used EJBs but Struts doesn't need to know about them at all. The actions could talk to a service interface that may be implemented by EJBs or just normal Java classes. David From: "Aaron O'Hara" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "'Struts-user-list '" <[EMAIL PROTECTED]> Subject: [OT]: Struts, Web Development, J2EE, and what is too much? Date: Mon, 10 Mar 2003 14:34:45 -0800 I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]: Struts, Web Development, J2EE, and what is too much?
I've never used EJBs but Struts doesn't need to know about them at all. The actions could talk to a service interface that may be implemented by EJBs or just normal Java classes. David From: "Aaron O'Hara" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "'Struts-user-list '" <[EMAIL PROTECTED]> Subject: [OT]: Struts, Web Development, J2EE, and what is too much? Date: Mon, 10 Mar 2003 14:34:45 -0800 I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT]: Struts, Web Development, J2EE, and what is too much?
I know this question has probably been asked before, and that biased publications have had their opinions on it, but I wanted to get some feedback regarding some "real user experience" regarding the use of EJB in a web application used along with Struts. I am creating a web application and I have decided to use struts. The application needs to be high performance, uses a single database (so it doesn't have heterogeneous transactional db requirements). I have designed the application in layers, and it will only have a web interface. It's starting small, but will grow to have many functions. Even though I'm confident that I need not invest in EJB's, I don't want to develop the application to find out I should have used them (hence why I'm creating this post). In what scenarios have people found the use of EJB beneficial? When have they been overkill? Does struts integrate smoothly with EJBs? My fear is that I'll make the application overly complex by implementing EJBs, but I'd like to hear from people with experience building large web-only projects with struts. Thanks, Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
