Juan Pablo Lorandi wrote: > > > > > > > > > > > > And I can't see that someone manually generating code is going to > > > > take less time. There are still more layers. > > > > > > > > > > I can code an EJB "manually" using IDEA and XDoclet in minutes. And > > > the layers, they lend to easier code reuse/location transparency. > > > > And you can't do that in JDBC? > > Yes, you can do that. I said easier. With JDBC(no EJBs), to relocate a > class I would need to start RMID, configure it(talk about wicked > configuration) and connect to it, among other plumbing. To be able to > have transactional(voting) components executing in different JVMs I > would also have to code my own distributed transaction manager. >
So in this case you are referring to distributed transactions across systems with disparate object instances. Most likely then then using a EJB container to solve that particular problem is a good design decision. I suspect that overall there are very few projects that require that. Although the projects that do would tend to be larger and thus require more developers and with more experience. > I think maybe your customers, because of their particularities, are more > likely to want all source code and not leverage from a common > infrastructure in the form of an application server. This is true esp. > with banks, but many other clients present different scenarios. > I question the "many" part but other than that I agree with you. > Sorry, I'm unfamiliar with the term field level security(I think you > mean security on database fields instead of records). Yes and I have seen a great deal of interest in that. > What J2EE provides is role-based security. > By defining a set of roles in an application you're allowed to define > which roles may execute each remote/remoteHome method of an EJB(getters, > setters, business methods, create/find/remove methods). This is done > declaratively, so no recompilation is needed. Impersonation (Run-As) is > also supported by many servers, and mapping to existing user/role > persistence is supported in almost every flavor for every server(LDAP, > Kerberos, WinNT, DB tables). And of course, each EJB has the credentials > available in its context to implement the security checks > programatically. > Yes, that is how I thought it worked. My point however, is that by the time one gets to the EJB no one cares about that. At least not in my experience. Sometimes they care about the object itself (not the methods.) And sometimes they care about the fields in the object. > The idea isn't to skip testing, but to be able to deploy the same > solution in a different DB/Server combos more easily. EJBs aren't an > excuse for poor programming practices, and I figure not using EJBs isn't > one either. Since I don't code persistence code(or, more acurately, I > code minimal persistence code), then my cost to switch DBs is lessened. > This doesn't come from any data that is statistically valid, only MY > experience. If yours is different, great, but just as you aren't > convinced until proven otherwise, neither will I. And I have experience > in the "let's-roll-out-our-own-tools" thing. Painful experience. Now, I > don't expect to convince you, but honestly, I wouldn't say my experience > is representative of the J2EE technology user base, and I don't think > you can, either. > I don't have any problem believing that your code is more portable. And if you are creating software that targets more than one customer then that would seem appropriate. I wouldn't want to use EJBs solely for that reason however. And as I also pointed out elsewhere I believe that most software is developed for in house use. That, along with poor planning practices, means that even if they do need to move to a different database that everything will have to be re-written anyways. The database vendor specific code will end up being only a small part of that. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
