> > > Given > > > that there is at least one more layer in EJBs that means one more > > > layer to be generated. > > > > I can't follow you here. Do you advocate for not using EJBs at all? > > I wasn't discussing that. The point was that coding time > with EJBs is faster than using JDBC. In my experience using > EJBs requires an additional layer. Thus more code.
I take that by "using JDBC" you mean "using JDBC without EJBs at all". If you bundle your JDBC code inside an EJB(a Session Bean, perhaps), then the extra layer is already there, right? Nothing "extra". In such a case, it depends on the coder, previous experience, etc. MY TOOLS allow me to code an EJB in a similar amount of time it takes me to code raw JDBC code. Experience helps. And maybe your home brewn tools close the gap sometime. Now, for general purpose systems, I prefer EJBs; they allow me to accommodate to change better. > > > > > > And thus for the techniques I > > > use (rolling my own generation > > > tools) that means that EJBs always take longer. > > > > Longer to code? But you don't code... you have your own tools that > > autogenerate everything. On the other hand, I presume it took some > > time to roll out your generation tools, and it will take some extra > > time to maintain them. I also presume your tools aren't > defined by a > > widely known and adopted spec, which means that while I can find > > somebody with EJB experience to help me, you won't find as > many that > > have "Joe Schell's Generation Tools" experience. How you > account for > > that is your choice, but the cost is there, unless you run > a one man > > show. > > > > In my experience each company that I work for uses a > different EJB container. And although the specs detail what > containers must do they have a tendency not to be specific on > how it must be done. > > Thus for example, neither the EJB spec (2.1) or the J2EE spec (draft > 1.4) specifies how one configures a connection pool. > > Now it is probably just my in-experience but certainly for > the containers that I have used, they all used a different > method of configuring a connection pool. And the specs, even > the newest ones don't specify this. > > That means that every new container, and perhaps even new > version of the same container, that I must learn how to > configure the connection pool. > > So the fact that there are specs don't help a great deal with > this sort of thing. I thought the point was speed of coding, not deployment ;-). Standarization in server management is being covered by Sun, in a different spec, as including this could compromise each vendor's ability to distinguish itself from other vendors and effectively compete. Nevertheless, on this issue you should try to get vendors around here to approach and tell you their views. > > > > > > > > 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. > > > Sure, you could manage your own transaction with JDBC and > manage the > > connection pool yourself; and provided you have a magic button that > > autogenerates everything, you'll be as fast. Me, I'm lazy, > and don't > > have the magic button, so I let the EJB Server programmers do that > > coding for me. I use JDBC from within Session Beans so I > can relocate > > code without rewriting it, and I code based on specs so whenever > > there's a new developer I don't have to teach him about the > home brewn > > tools(generation tools, custom security tools, connection pools, > > transaction management, session tracking, etc.). They learn > J2EE and > > from then on they're concerned with the business logic(to a great > > extent, nothing is perfect). > > I wasn't commentting on J2EE but rather EJBs specifically. > > On the projects that I have worked on there are very few > developers that work on the database side anyways. On the > projects where I have worked with 30 developers the database > layer side was 5 or less developers. So I would never expect > to have to teach every developer anything about the database > code. Regardless of the the methodology or even language > used. That has held with smaller projects where I was the > only developer that interacted with the database in any way. > It still is 5 or less. And you have to teach them. And you also mentioned that you roll out your tools per each project(which makes sense to avoid mantaining tools for projects you're not it anymore). So on each project you have to roll out your tools and sometimes teach 5 developers about the tools. If it works for you, great, but I work a little bit different(lot of work done offshore, people coming in and out of prjs), and my way accomodates me better. 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. > > > > > > > > So I can only guess that you are using a tool that generates > > > everything. But if it generates everything for EJBs then > surely it > > > can generate everything for JDBC? Which means the > > > coding speed would be the same. > > > > > > > No, my tools do not generate everything for JDBC. Probably any jSQL > > compiler may do the trick, but it won't leverage from declarative > > security, > > Security on the EJB? I haven't mentioned that but it seems > like a good > point. I have never been on a project where security was even a minor > concern at the database level. If a user (person or process) > has gotten > to the database level then they are already validated for all > operations. > > And most projects where security at that level might have an impact it > was usually at a field level rather than a entity level. And > EJBs have > nothing to do field level security correct? Sorry, I'm unfamiliar with the term field level security(I think you mean security on database fields instead of records). 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. > > > ...automatic transaction enrollment, etc. unless the code is > > within a Session Bean. Also database portabilty is a > concern for many of > > our projects, as they're engines and modules that will be > deployed on a > > variety of environments. On this last point, there's a tradeoff: EJB > > applies some constraints on which those environments will be(some > > combinations of DB/App Servers won't be supported), but provides a > > cleaner migration path for all of them. > > Good point. That is harder to do in JDBC because if it isn't > compatible > then the only way you are going to find out is by testing it anyways. > > > But presumably you do test your code on different databases anyways > right? > 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. > > > > > > > > > Perhaps you are referring really not to EJBs themselves but > > > the wrapper functionality that the EJB server provides and > > > that one might have to then code when using just JDBC? > > > > Yes, among other stuff. My point is that benefits/penalties > of choosing > > EJBs over no-EJBs and Entity Beans over Session Beans + > JDBC shouldn't > > concern performance alone. Look, here's the bottom line: my > customers > > money is better spent paying my teams to code business > logic and not the > > plumbing; I don't want everybody here having to master hardcore Java > > concepts such as critical sections, pools, caches, etc. > Ideally I want > > coders here to solve the business problem at hand. And I > certainly don't > > want to maintain and support that plumbing as it isn't my > core business. > > > > I don't believe I mentioned performance specifically. I am in > concurrence with some others post that performance because of > the layers > is going to be slightly less than using JDBC. But the other point was > made, which I also agree with, is that the performance degradation is > rather slight and could be safely ignored in comparison to > other issues, > such a design, which can affect performance significantly. Great, we agree on this. > > But are you saying that you code business logic in EJBs? > Yes. Where do you code yours? Stored procedures perhaps? Common java classes? > > > > --A. The > > > data set was so small and the requirements of the system so > > > low that EJBs would be overkill and even caching of any of > > > the data was not needed. > > > > Cool. Sometimes EJBs are overkill. Nowadays I'm profficient > enough to do > > it in EJBs faster than not, but I try to make the best > judgement on a > > case by case basis(not to mention hardware/software > associated costs). > > If I the user needs a bicycle, he expects to pay a > bicycle's price, and > > I try to match that while providing the best solution I can > give him. > > Nevertheless, I don't get small customers anymore, and > usually I don't > > even use Java for those rare occasions. > > > > I don't believe it applies to small customers. One project that I was > familar with involved producing an application for a large > international > corporation which would be installed in something like 3000 > (or 30,000?) > places world wide. However the data set that the application > dealt with > was so small that j2ee and/or ejbs would have been severe overkill. > Depends on the application. OpenGL could be overkill if you're coding the GUI of an simple text editor a la notepad. But nobody forbids you to use it. Maybe (if you can, I know it's hairy) you could tell us about the app. Maybe you could have done it in Access?. > > > > > > Now I can certainly imagine data sets that did not follow the > > > above. But I find it hard to believe that most data sets > > > don't look like the above. > > > > Some do, in other fields. My experience with banking systems (just > > regarding to caches) is that caches are not applicable. > There are rarely > > record updates, mostly INSERT and SELECT statements. Also > all access to > > the RDBMS is often serialized. But I've worked on other > systems in which > > caching was quite useful as the use-patterns are different: > > Marketplaces/Auctions, Content(News, Forums), on-line gaming and > > gambling (it's much like banks, but many more datasets are quite > > cacheable). > > Of course it applies to some fields. My question is what > percentage of > fields and of the total developement market is is applicable to? How > many developers work for banks as compared to those working for online > gambling? I dunno. I'm not the Gartner group and I certainly can find entertaining more ways to spend 200 grand other than to commision them to produce a paper on the subject ;). I know this: Regional banks aren't that common worldwide; in the US, there's a bank(not counting branches) per 30,000 inhabitants). Here in Ireland I'd say it's more like 500,000 inhabitants at least, and my home country, Argentina, it's always been for sure over 750,000 and rising due to the crisis. And since I don't have that data, and AFAIK nobody else has, then I think that EJBs should try to solve a number of general purposes irregardless of the common use patterns. If someday there is a more bank-systemts oriented spec then great, but for the time being I'm quite comfortable with the spec being general purpose. Regards, JP =========================================================================== 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".
