> > 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'm afraid that I'm unable to connect the need to distribute load or the necessity to have collaborating components in different physical locations with the need for more developers, unless you plan to do all the plumbing yourself. It's trivial with J2EE. You don't actually need to code anything extra, just to deploy differently. Also, think about a system with a change in distribution requirements while in production. It will require careful analysis even if you're using J2EE, but the implementation may be trival or less expensive. Initial costs don't worry me as much as litigating the cost of change. > > 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. > I arbitrarily define many clients as N clients, provided N > 5. Cool? ;-) Honestly, I cannot presume of knowing how many, and I think neither can you, so on the subject I will concede anything you propose provided we stop talking about something that we don't have definate numbers about. > > 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 fields are accesible thru methods. (In the Remote/Local interface). That takes care of as much field level security as you may want. You cannot see the (public) fields of an EJB, first, because it violates the OOP encapsulation rule if you did and second, because you never get a reference to the actual EJB, only a stub implementing an interface; thus, if you don't access those fields thru the methods, you don't access them at all. The objects are accessible thru Home methods (In the RemoteHome/LocalHome interface). You cannot access an EJB without getting them thru the Home interfaces. That takes care of as much object(or record for Entity Beans) level security as you may want. Of course you can implement some access control at a different level; but then how does affect field/record level security? (there would be none, right?). If they care about very fined grained permissions operating on a field/record level, then an EJB(wether it's Entity or Session) gives them the perfect place to implement fine-grained permissions in a clean fashion. Also Joe, in some of your previous posts you seem to imply that no business logic belongs in Entity Beans. Entity Beans are fully blown business objects. They're not just another O/R mapping tool. They allow(to certain degree) to extend into OOP concepts and practices to enterprise systems. More complex business logic involving several domain entities is usually coded in Session Beans, but the burden of coding security for them is lessened by (a) J2EE security already commented and (b) the already implemented security at the Entity level(provided you coded it, It won't shield you from a bad architecture). > > 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. > Neither would I. I think that for the proper problem, EJBs are quite desirable for many reasons esp. because I find that J2EE(including EJBs) allows ME to manage change more efficiently. > > 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. > I agree. That's my bread and butter, I get paid to fix the poor architectures flying around, and it's quite profitable. I'm afraid that the market is quickly rotating out of those practices(in-house dev), as John Harby pointed out. It's becoming more administrator oriented than anything else, and more and more developers are becoming 'redundant', as this "new IT" is about buying customizable systems(not components, systems) and managing the day-to-day administration of them. This "new IT" doesn't revolve around the lessened costs of keeping dev teams inside the enterprise(actually, costs are more elevated IMHO), but to outsource the risks involved on each IT endeavor. Being a developer I hope that this rotation doesn't ever go beyond the 'hype' phase, but I'm afraid I've yet to find solid arguments against the rationale behind it. On the mean time I'm adapting to these changes in rules and trying to make the most out of it. =========================================================================== 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".
