Servlets vs. Stateless Session Beans for Stateless Requests

Discussions

News: Servlets vs. Stateless Session Beans for Stateless Requests

  1. A new article on developerWorks takes another stab at comparing servlets to stateless session beans with regards to their ability to handle client requests. "...the servlet architecture's lightweight threading model makes servlet scalability particularly efficient, whereas stateless session beans provide an excellent balance between access to robust enterprise resources, good response time, and overall scalability..."

    Read J2EE pathfinder: J2EE technologies for the stateless network.

    Threaded Messages (114)

  2. looking forward to your comments[ Go to top ]

    Hmmm, my thoughts.

    The servlet container is usually configurable to the number of service threads per WEB APP. However, has anyone seen this extended to configure how many threads are allowed per SERVLET? Since the scalability of given features may differ drastically, I think this is something to look for in a web server...
    or...
    look at the EJB containers which all seem to offer a more fine grained way for you to control the concurrently executing beans - per BEAN. Also, the stateless session beans provide a more robust feature set including security and transactions (although does not the JTA give Servlets the ability do some sort of transactions)?.

    What I infer: Begin with your DAO objects and factories, or your chosen O/R Mapping tool framework objects. Use these in your web app jsps / servlets / Front End Controllers,etc.

    THEN,

    1) When concurrency for particular use cases presents itself as a problem, "delegate" it back to a stateless session bean and control it.
    2) OR, When you want to supply data for EAI, again delegate back.
    3) OR, when you want a quick way to support Web Services or CORBA clients, it seems obvious to delegate it back to the session bean.

    What do you think? IS that an XP approach?
  3. Do I need EJBs???[ Go to top ]

    This is a snippet from a post I made in the EJB Programming forum, I'm repeating it here to hopefully get a detailed response:
    Firstly checkout http://radio.weblogs.com/0107789/stories/2002/05/24/isEjbAlwaysNecessary.html

    Now with that you have that in mind, if I have the following deployment:
    * One machine has J2EE server (web container + EJB container if necessary)
    * Another machine has Postgres database
    * Support for hand-held devices

    Scalability can be achieved using Cisco load balancing with sticky sessions and using eRServer (postgres replication).

     In what context does EJB make a great solution??? In my deployment model is there ever a need for EJB that can not be done just as easly using the tools outlined in the article??

    I have spent quite a bit of time on this issue and it appears to me that their are simpler and better (in terms of maintance and performance) ways of doing what EJB does. What is so good about EJBs??? I'm not at all saying that they suck, just that there are better ways of achieving the same thing.

    Can you give me clear examples of where to use EJBs??? then I might understand there purpose and when they are the best choice.

    Taking all the above into consideration, do I need EJBs???
  4. Do I need EJBs???[ Go to top ]

    There's material in chapters 1 and 7 of my book, Expert One-on-One J2EE Design and Development, about how to choose when to use EJB. Chapter 1 is available free on the Wrox site.

    I'm also giving a talk on this issue at the ServerSide Symposium in Boston in June.

    Rod Johnson
  5. Do I need EJBs???[ Go to top ]

    Cameron,

    Short answer is never use EJB or O/R (or JDO). Use DAO!

    I said in another thread:
    EJBs should only be used for CORBA, like 1% of time.
    I find only newbie’s even talk about EJBs or JBOSS anymore.
    Same goes for O/R, don’t use it, such as JDO, or OMG. I wish OMG did more for .NET.
    Why? O/R ends up matching relational, such as multi row master/detail.

    Your data access should be similar to ADO.NET, disconnected, here is sample Java Code
    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicportal/src/basicWebLib/org/apache/basicWebLib/DAO
    or
    http://developer.java.sun.com/developer/technicalArticles/javaserverpages/cachedrowset

    To learn more good practices over the web with Struts for almost free (not for newbies):
    http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg57534.html

    I asked Floyd to post the training, winner of Best Training by Java Developers Journal but..


    .V
  6. Re: Vic[ Go to top ]

    Vic,
      I think saying 'never use EJBs or O/R' is extremely short sighted. If you are working with a larger (and I hate this word) 'domain model', you are going to be spending a lot of time not only creating the objects that represent your model, but also creating the table and writing the procs to update the tables. I could throw together a 30 class domain model in about 2 hours with the persistance tier completely implemented in about a tenth the time it would take me to create all the data objects, the DAO objects, the tables, write all the sql to update the tables, test the sql, etc. Websphere, for instance, has nice entity bean testing tools so I just type in some field values and click 'go' and verify the data is all hooked up (although it's never criss-crossed values in a table before, but I certainly have made that mistake in the past).

    So, don't shoot down EJBs too quickly, I know that people have misused them in the past but using them in even simple applications can speed delivery of a product. and with the EB access hidden behind a business tier, you could remove any EBs that you feel are not performing adequately.

    -Chris
  7. Re: EJB, OR.[ Go to top ]

    I did not say never use EJB, I said only CORBA (ie Dsitributed) but it is very rare!

    ADO.net net does not do OMG O/R but a disconcted row set!
    Everyone knows that the fastest way to get to DB is JDBC, such as ROWSET, and not any layer. So for larger sites, you have to be closer to the metal.

    If you please, please read the disconcted row set paper I linked above, you will find that you do not write any updates, that the Sun Java Row Set writes the update for you!

    Writing 30 unit tested DAO with RowSet is faster than writing 30 EJBs anytime.
    I would be glad to debate you. Even code again you? My code is available to be seen on sf.net (basicPortal), you have samples?
    Majbe join news.basebeans.net news server, and post on mvc group there?

    .V
  8. Re: Vic[ Go to top ]

    Vic,

    <quote>
    Short answer is never use EJB or O/R (or JDO). Use DAO!
    </quote>

    Sorry, I don't know how i misconstrued that into EJBs and CORBA. I don't want to make this into a pissing contest about who is better at coding, etc, but given the same programmer, I feel that writing a model object and an EB to implement the persistance tier is faster than writing a model object and all the SQL required to get to the database (although the rowset object manages the update statements, you still need to query the data down, don't you? And what about creations? I'm familiar with ADO.NET, but not sure how you can just use it to perform inserts without writing some kind of sql to define the roset that you addNew to....

    -Chris
  9. Re: Vic[ Go to top ]

    Chris,

    You said?
    "
    I feel that writing a model object and an EB to implement the persistance tier is faster than writing a model object and all the SQL required to get to the database <snip> what about creations? I'm familiar with ADO.NET, but not sure how you can just use it to perform inserts without writing some kind of sql to define the resultset> that you addNew to....
    "
    Very good!

    I do not use ResultSet! Result set is JDBC 2.0. In JDBC 2.1, Sun introduced RowSet.
    You might think you know RowSet, but I beg you to read this:

    http://developer.java.sun.com/developer/technicalArticles/javaserverpages/cachedrowset/

    In it it clearly shows how to do an insert (and update) without writing the SQL string!

    So I implemented open source DAO at basicPortal.sf.net using rowset and not resultset, since you do not need to write insert or update sql commmands!

    And there is also no need to DTO,VO becuase the RowSet has the data even after it rleases DB connection/resources.

    When you need to update, you just say update. I use this with Sturts (auto-setters) and .... it's very fast and minimal GC. For more speed, add poolman.sf.net and the results are auto cached.

    .V
  10. Re: Insert/Update without SQL[ Go to top ]

    Vic,

    <quote>
    n it it clearly shows how to do an insert (and update) without writing the SQL string!
    </quote>

    I could be wrong, but according to the article the following code used to initialize the cached row set:

    Contacts.setCommand("SELECT name,telephone from Contacts");
    Contacts.execute();
    Contacts.first();

    is required so that when you call moveToInsertRow() and associated updateString(col,value) it knows what columns you are updating and in which table. I qualify "Select name, telephone from Contacts" as needing to write SQL, and pretty much what I was saying in my first post:

    <quote>
    I'm familiar with ADO.NET, but not sure how you can just use it to perform inserts without writing some kind of sql to define the resultset that you addNew to...
    </quote>

    -Chris
  11. Re: Vic[ Go to top ]

    Vic,

    Do you know which databases have a RowSet implementation? i know that Oracle does, but how about some of the other vendors - DB2, Informix (SQL Server via a 3rd party)?

    Raju
  12. CachedRowSet[ Go to top ]

    Version of Sun's and I think Oracle's CachedRowSet commit after every acceptChanges(). It means if one needs to update more then one CachedRowSet in the same transaction (unit of work) and one of the CachedRowSet would fail the other will commit. This is unacceptable for almost all applications. Did you create your version of RowSetWriter?
  13. CachedRowSet[ Go to top ]

    Leonard, Raju.

    Sun CachedRowSet is good, So is Oracle
    But ... like you point out, for some tweaks, I like Open Source.
    This is an open source RowSet
    http://jxdbcon.sourceforge.net/nightly/
    and it points to jxUtil, etc.

    All the benefits of open source, including e-mailing the developers.

    I have use RowSet in several comerical aplications with no problems. (JDO, O/R had problems).
    Truely, it's the beast DAO to go against DAO.net.
    I would look for a JDBC that supports RowSet, like we are in version of JDBC 3.0.
    Here is a list of drivers and if they support rowset
    http://industry.java.sun.com/products/jdbc/drivers
    .V
  14. Re: EJB, OR.[ Go to top ]

    Vic,

    I have seen the same thing posted by you on other threads. But where is the evidence for all your "no EJB" and "always use DAO stuff"?

    Don't tell me that it is a GOLDEN RULE of some sort- "Don't use EJB unless you use CORBA!". What crap! You should use the tools that will allow you to do the job correctly and efficiently. Give me something more than the vague statements you have been making on these threads.

    This is not a personal attack, I really want to know what you are thinking - but you need to be more specific with your statements and explanations.

    Thanks
  15. Re: EJB, OR.[ Go to top ]

    Raju, in my other posts I linked about 6 links that point out all the problems with EJB (from slow, to complex)
    If you can't find then either ask me to post here or e-mail me personal vc at basebeans.com.

    ALso, anecdotal evidance of my clients/friends is that people that do EJB, leave such a bad impresion at customer, that the customer goes to .NET.


    .V
  16. Bad Customer Image[ Go to top ]

    Vic,
      I have no doubt about this. I've been on a few sites myself where some hotshot who wanted to implement a new framework that could handle anything and everything imagineable left a system in place that was so convoluted that when I was asked if it would have better be done in .net, my response was 'Well, if the .net version tried to be as all-encompassing as this project attempted to be, then no...but if you start from scratch with some specific design goals in mind, then it could be better in .net, but if we re-write it in Java, it would be better too.'

    I'd like to take a time-out now and plead to the brainiacs in the IT industry doing Java work and trying to make these 'simple' systems that require complex work to make them do _anything_ useful (Rolf: as simple as your little engine is, having to remember every field name instead of having discreet objects is _not_ simple (nor adhering to KISS as you constantly provess, nor is 'Everything is a String!' a recipe for simplicity).


    Please please please please please please, enterprise architects of the Java world, solve specific business problems, don't invent business problem solvers that require 50 times the work to solve a specific problem.....FOCUS FOCUS FOCUS.

    I'm out.

    -Chris
  17. O/R tools == "Quick and Dirty"[ Go to top ]

    Chris,

    re:"having to remember every field name"

    Have you perhaps done the reflection that it is a possibility that I have saved them in a simple text file or even printed them on plain old paper?
    Probably have my code finished and tested even before your IDE even have started up..

    I am just happy that I don't have 10-20-30000 unnessecary LOC in my application.

    BTW, thank you for your condescending tone!

    "I am further amazed how this can be talked about with an attitude of superiority".

    Regards
    Rolf Tollerud
  18. Re: EJB, OR.[ Go to top ]

    Vic,

    Long rant follows :) ....

    I have read those links - they are quite well known links. Some of them are plain useless (the 101 EJB damnations - half of them are idiotic and off-topic).

    Anyway, I am asking for more than anecdotal evidence. There are many cases where people go crazy trying to create this awesome "can do everything-even washes my car for me" sort of application framework. This is truly overkill. I have seen projects where common sense was applied when using EJBs and they worked quite well.

    Yes EJBs are somewhat complex ... bu with today's tools (XDoclet etc.) it is very easy to automate a significant part of the process. On my current project, we completely automated the entity bean layer (i.e. code generation etc.). Its very easy to spit out the entire entity bean code + associated classes.

    I want someone to give me more than anecdotal evidence. Show me some numbers. i used XXXX entity beans and YYY session beans on a server ZZZ dealing with AAA users/transactions per second. And then give me some information about the application. Then tell me why it sucked or why it was good.

    I have a lot of trouble with the "don't use EJBs cuz they suck" articles & posts. Primarily because nobody provides any hard evidence as to why they suck. Sure they can be slow and if you are developing EJBs using textpad and a command prompt, without the aid of tools such as ant and xdoclet, the process will be slower than a snail. But like I said before, these things need to be done intelligently and with some forethought.

    I am not completely in love with EJB. I know that there are issues with the technology. But for the cases when people/teams were not doing bone-headed things, what was the outcome of using EJB?

    Thanks,

    Raju
  19. <Raju>
    I have read those links - they are quite well known links. Some of them are plain useless (the 101 EJB damnations - half of them are idiotic and off-topic).
    </Raju>

    I have heard posters on this forum criticize the 101 EJB Damnations article. But I have never seen any detailed counter to it. Can someone point me to a detailed counter-argument to it?
  20. Re: Vic[ Go to top ]

    The problem I find with EJBs is that I end up with a session bean that returns data transfer objects for almost every entity bean. Eg.
    /**
     * Product catalog
     *
     * @author Cameron Zemek
     * @version 1.0
     *
     * @ejb:bean name="webshop/ProductCatalog"
     * display-name="ProductCatalog"
     * type="Stateless"
     * view-type="local"
     * local-jndi-name="ejb/webshop/ProductCatalog"
     *
     * @ejb:transaction type="Required"
     *
     * @ejb:ejb-ref ejb-name="webshop/Product"
     **/
    public class ProductCatalogEJB implements SessionBean{
    private SessionContext mContext;
        
        private ProductLocalHome productHome;
        
        /**
         * Return a collection of all the product specifications
         *
         * @return collection of all product specifications
         *
         * @ejb:interface-method view-type="local"
         **/
        public Collection getCatalog(){
            Collection products = null;
            try{
                products = productHome.findAll();
            }catch(Exception e){ return null; }
            Collection productDTOs = new java.util.ArrayList(products.size());
            Iterator i = products.iterator();
            while(i.hasNext()){
                ProductLocal product = (ProductLocal)i.next();
                ProductDTO productDTO = new ProductDTO();
                productDTO.setId(product.getId());
                productDTO.setName(product.getName());
                productDTO.setImageName(product.getImageName());
                productDTO.setDescription(product.getDescription());
                productDTOs.add(productDTO);
            }
            return productDTOs;
        }
    ............

    Not only that but CMP also has these problems:
    * EJB-QL - has limitations and is another language to learn
    * CMP only handles first-class objects
    * Can not implement validation for set methods without adding additional methods that don't follow the JavaBean spec

    It seems to me that it is much easier to use an O/R mapping tool when the domain model is simple. When I started out with J2EE I thought EJB were good despite the complaints but as I have been developing with it, it seems like overkill (even with Xdoclet).
  21. training[ Go to top ]

    <quote>
    I asked Floyd to post the training, winner of Best Training by Java Developers Journal but..
    </quote>

    well the middleware company also offers trainings so it isn't at all suprising.

    However its funny they claim to be a neutral party in the petstore debacle, independantly reporting it and all but they dont post news that harms the mothercompanies bussiness

    well what is it guys ? :)
  22. training[ Go to top ]

    <quote>
    I asked Floyd to post the training, winner of Best Training by Java Developers Journal but..
    </quote>

    Guys, if you new how many 'XXX product one XXX award' press releases I see every week you'd know why TSS doesn't post ANY such announcements. It's simply not important news.

    Floyd
  23. Enough with the EJB bashing...[ Go to top ]

    <Vic>
    Short answer is never use EJB or O/R (or JDO). Use DAO!

    I said in another thread:
    EJBs should only be used for CORBA, like 1% of time.
    </Vic>

    I posted a response to Vic's EJB bashing in another forum, so here it is pretty much repeated, mainly for Vic's benefit because I don't think he can have read it...

    There are several reasons for using EJBs other than for CORBA:

    1. If you need greater scalability than a web app can offer then a distributed EJB app using stateless session EJBs DOES offer this.

    2. If you need remote access to your components over RMI/IIOP from a non-web client. (OK so web services style remoting may fill could fill this role, but for now this seems a valid reason)

    3. If you need asynchronous methods then Message-driven EJBs offer by far the easiest way to implement this.

    While saying "never use entity EJBs" might be justifiable as a lot of people do seem to run into problems using them in real-world projects, conversely the reverse seems to be true for session beans and message-driven beans. I have not heard of anyone having problems (productivity, performance, or maintenance) with session beans or message-driven beans. In fact they have been used very successfully in a large number of projects. How many times do I have to hear people damn EJBs just because they have an issue with entity beans...

    Regards,
    Gavin
  24. Enough with the EJB bashing...[ Go to top ]

    Hey Gavin,

    1. As the public performance test point out EJB is slow. So they are not scalable and should be avoided in places where scalability is required.

    2. Axis and XML-RPC are better than RMI/IIOP. But it is a fine line becuase like I say, if you need CORBA, than EJB!.

    3. Using Async for EJB is no good IMO. Async like send e-mail or get RSS feed can be done other ways. One way is to have a "cron" like process read content and e-mail tables (in a dB) and process e-mail and process new RSS. Then the web apps just insert new e-mail to be sent and just display RSS from a table. I find this rock solid and simple.

    In general, I say:
    Anyone can build a web site. Any one can use EJB. But only a software engeeiner can show you the cheapest and fastest way to build the web site.

    If you can't do it simply with Tomcat or Resin, you are making it to complex. Kiss!
    I use the disconected row set to competere with disconected ADO.net and I win clients for J2EE. EJB drives them away becuase it is expensive. And it's complex! And it' slow.

    What you are saying is very similar: "never use entity EJB".
    From there one can think, is it worth the complexity for the other things, and just have a POJB (Plain Old Java Bean) instead.
    I include JDO and O/R in don't use for reasons listed in prior topic. Just use DAO! That is a guide line.
    Now if you are familiar with the risks, and costs, and are willing to create mutiuple objects via DTO, VO, Caching layer, and stress out GC, etc. .... than go for it.
    I can save your client money (by removing all those O/R, JBoss toys) and make it faster.
    If you do not go DAO, you will likely go ADO.net, IMO.
    .V
  25. Enough with the EJB bashing...[ Go to top ]

    2. Axis and XML-RPC are better than RMI/IIOP. But it is a fine line becuase like I say, if you need CORBA, than EJB!.


    you are consistently talking about performance reasons why not to use EJBs, but now you favor Axis and XML-RPC over RMI or IIOP ? Are you insane, do you know 'the third law of distributed computing' ?

    Parafrasing Icaac Asimov's Laws of Robitics:

    The First Law of Distributed Computing:
    Inter-process call is three-to-four orders of magintude slower then in-process call.

    The Secong Law of Distributed Computing:
    Remote (inter-machine) call is order of magnitude slower then inter-process call, thus four-to-five orders of magnitude slower then in-process call.

    The Third Law of Distributed Computing:
    Web-services call (or any that uses HTTP and XML) is ORDER OF MAGNITUDE slower then native remote call (one that uses raw TCP/IP or UDP and binary format to marshall parameters, like IIOP, DCOM or RMI), thus about two orders of magnitude slower then inter-process call and five-to-six orders of magnitude slower then local call.

    Also, Axis IS slow (I did not say worse or bad, just slower)compared to some other WebServices implementations, like Glue. So, please do your own research or search the Internet before stating things.

    Mileta
  26. Enough with the EJB bashing...[ Go to top ]

    <Gavin>
    1. If you need greater scalability than a web app can offer then a distributed EJB app using stateless session EJBs DOES offer this.
    </Gavin>

    Can you elaborate on this?? Can't multiple web servers accessing the same database (which can be replicated) with a cisco load balancer with sticky sessions scale just as much as EJBs???

    <Gavin>
    2. If you need remote access to your components over RMI/IIOP from a non-web client. (OK so web services style remoting may fill could fill this role, but for now this seems a valid reason)
    </Gavin>

    Writing RMI server objects is easy http://java.sun.com/docs/books/tutorial/rmi/index.html

    <Gavin>
    3. If you need asynchronous methods then Message-driven EJBs offer by far the easiest way to implement this.
    </Gavin>

    Umm. I don't know much about messaging. But couldn't a framework for writing messaging JavaBeans be written that didn't require an EJB environment???

    <Gavin>
    ...have not heard of anyone having problems (productivity, performance, or maintenance) with session beans or message-driven beans...
    </Gavin>

    POJO are easier then session beans and achieve the same thing. The way I see it is that having implicit transaction management is no more difficult then declarative management when you don't need distributed transactions. So in my situation that would mean it is better (ie. easier to code, easier to maintain, more reusable) to use POJOs instead of session beans.
  27. Enough with the EJB bashing...[ Go to top ]

    Writing RMI server objects is easy...POJO are easier then session beans


    word, Cameron. You know whats up. all them ejb folks be whack.


    >But couldn't a framework for writing messaging JavaBeans be written

    damn, your smart... you should check out the fly patchbay framework in that dynamo application framework them dope ass developers at ATG be cook'en up. It's the shit.
    You can send and receive jms messages from vanilla java beans without ever importing javax.jms, it's as easy as drinking a forty on the stoop at sunset. Damn, I could use one of them big 40oz malt liquored smoothies right now.
  28. Patters are language agnostic[ Go to top ]

    One of the problems when discussing issues like O/R tools is that you don't know if you are speaking to:

    1) Plumbing software developers
    2) Contract developers producing software under a limited time schedule, or
    3) Enterprise applications product developers

    Because the prerequisites for these three categories are so different it leaves room for a lot of misunderstanding.

    I really do not care about if you use Java or .NET, it's just that exaggerate claims or/or sweeping bashing gives me a knee jerk reaction, especially when it is given with an air of superiority..

    Anyhow when I have an evaluation version of both Siebel port to Websphere and MS new CRM product, I promise I give a thorough evaluation of this two products, with an eye to O/R.

    I do think I am suited to do this since I have both Java and .NET experience and a solid background of CRM.

    The difference between Java and Microsoft development is, not so much about whoever have the best classes, IDEs or fastest VM/CLR, but a question of philosophy- the Java camp think that the right way to go is EJB and/or O/R tools. (COM and O/R tools in MS world) - a road MS developers usually not chose not to. That is more interesting IMO, than any technical difference.

    Regards
    Rolf Tollerud
  29. POJO are good for ONE JVM architecture. When you need to implement REALLY distributed application ( running on different machines) you NEED messaging. And Stateless Session Beans with JMS Beans are perfect in this situation.
  30. Enough with the EJB bashing...[ Go to top ]

    EJBs are clearly designed for distributed applications and they work very well in that role (excluding the entity beans). Sure you can build RMI servers with simple applications if you consider J2EE app servers to be too much weight. However, there is a treshold where your regular RMI servers will become hard to manage and program.

    For example, consider that you have to worry about threading with RMI servers. You could synchronize the remote methods but what if you need to serve multiple concurrent calls? Then you create internal handler objects to deal with those calls and the whole thing starts to look a whole lot like those session beans you didn't want to use (except now you have to create all the crap yourself!).

    Well, that is not so bad, but you need to manage your application. You probably start your RMI servers from one VM. You might have to stop one server and start another, but how can you do that without building somekind of management interface if you want to avoid bringing down your whole thing.

    You can just see how your problems start to propagate. You could have just used an application server. It is not that hard and all that basic stuff is done for you. If you still feel that you don't have to use an application server then good for you; your application is obviously simple enough so you can forget about all that stuff.
  31. RE: Enough with the EJB bashing...[ Go to top ]

    <Tero>
    For example, consider that you have to worry about threading with RMI servers. You could synchronize the remote methods but what if you need to serve multiple concurrent calls? Then you create internal handler objects to deal with those calls and the whole thing starts to look a whole lot like those session beans you didn't want to use (except now you have to create all the crap yourself!).
    </Tero>

    I agree, it probably is better to use EJBs for RMI access. But web services can achieve remote access to the business logic without having to use EJBs. If EJBs were required you could have the stateless session beans delegate to the POJBs that the web tier is using (web and ejb tier are in the same JVM).

    I recommend everyone to check out the sample chapter of Rod's book at http://www.wrox.com/books/1861007841.htm
  32. Do I need EJBs???[ Go to top ]

    Vic,

    <quote>
    Short answer is never use EJB or O/R (or JDO). Use DAO!
    ...
    Same goes for O/R, don’t use it, such as JDO, or OMG. I wish OMG did more for .NET.
    Why? O/R ends up matching relational, such as multi row master/detail.
    </quote>

    The usual balanced view here, then...
    It would seem to me that your suggested alternative to using JDO / O/R Mapping Tools is that you should write all your own SQL, tightly coupling your code to the database schema (as Rolf also seems to be suggesting), or that you should write your own framework which maps your object fields to the database (which would seem to be re-inventing the wheel).

    Why is either of these options superior to O/R frameworks? The object model doesn't always end up mirroring the database model as you suggest - in many large companies developers are working with pre-existing database schema that they may not change and therefore may require an object to map to several tables. O/R mapping tools can handle this. And if the object model ends up matching the relational - so what? O/R mapping tools can handle this.

    What O/R tools buy you is de-coupling and clean separation of your business objects from your data tier, and code that is easy to maintain and change. I would also dispute your claim that using DAOs offer faster developement. So what is not to like?

    By the way the criteria that you use to justify your opinion - being able to churn out code fastest (initially) or being able to produce the code that runs fastest - are not actually such a big deal as you seem to be making out. As long as the application meets its performance requirements, then flexibility and maintainability are actually much more important criteria for real-world projects.

    Regards,
    Lawrie
  33. Do I need O/R tools???[ Go to top ]

    Lawrie,

    "tightly coupling your code to the database schema
    (as Rolf also seems to be suggesting)"

    When I read this I’m absolutely speechless. Is it not common decency to have read the posts in the discussion before you participate?

    First, it is so obvious that you have not read anything from this thread, for instance my post:
    http://www.theserverside.com/home/thread.jsp?thread_id=17805&article_count=71#73467

    Second, is it not common decency to assume that the participants in TSS have at least some years experience?

    O/R mapping is only good for "Quick and Dirty" contract programming, not for any serious work.

    If you really want quality in your app, consider using something like Rods Johnsons DAO framework which is to be open-sourced on sourceforge under the "Spring framework" public name. There .NET and Java people will cooperate for the first time, as Rod pointed out "it is good to see J2EE and .NET sharing best practices (cross-pollenating or something like that)".

    Check out http://p2p.wrox.com/list.asp?list=expertj2ee_with_rodjohnson

    I (and many others) don't want 10-20-30.000 LOC auto generated in out apps, be forced to use a ridiculous home grown query language instead of ANSI SQL, have to use a cache system to help up the poor performance and generally make an ass of ourselves.

    Regards
    Rolf Tollerud
  34. Do I need O/R tools???[ Go to top ]

    Rolf,

    <quote>
    When I read this I’m absolutely speechless. Is it not common decency to have read the posts in the discussion before you participate?
    </quote>

    I apologise for not having read all your numerous posts Rolf, sometimes I find that my brain's in-built filter just sieves out patronising, repetitive, unbalanced, and unsubstantiated arguments. (Oops - light the red touch-paper and stand well back!)

    However, I think I have read enough of them to get the gist...

    Ok, so you map the field names, fair enough. but judging from the following code snippet which you posted earlier...

    <quote>
    sqlCmd s = new sqlCmd();
    s.Cmd = "UPDATE";
    s.Table = act.company;
    s.Set = "Addr1 ='112 Bay Area'";
    s.Set = "Zip ='111111'";
    s.Where = "id = 'C0921221501030'";
    //Console.WriteLine(s.buildSQL());
    int rowsAffected = s.SQLupdate();
    </quote>

    ... it would appear that you are locked into a one-to-one object to table mapping, so I a was partially correct - you are coupled to your database schema.

    <quote>
    Second, is it not common decency to assume that the participants in TSS have at least some years experience?

    O/R mapping is only good for "Quick and Dirty" contract programming, not for any serious work.
    </quote>

    Dig the superior attitude - I am glad that your years of experience see you writing-off all the alternatives offhand. The people posting about their successful use of O/R mapping tools must all be lying, right? Or perhaps it is just the O/R mapping tool vendors pretending to be satisfied customers? Have you tried any of these O/R mapping tools recently - if so what is your big issue with them (apart from having to learn a new, and <sarcasm> probably very hard to learn </sarcasm>, query language). I'll agree that for very complex queries it might be easier to use JDBC to map straight to the database, but this is the exception, not the rule.

    <quote>
    Performance is better, productivity is better, maintenance is better (without tons of generated objects), and best of all, I don't have to learn anything new (I have enough to learn anyhow).
    </quote>

    Ok so I'll concede that performance may be better but probably by not that much - it totally depends on the O/R tool's implementation - and, as I've stated before, performance is not that big a deal: as long as an application meets its performance requirements, then flexibility and maintainability are actually much more important criteria. Hardware is cheap!

    As for "productivity is better, maintenance is better (without tons of generated objects)" - this is just your subjective opinion. Where is your evidence? You have not substantiated that your framework leads to higher productivity - just because you say it does not make it so. As for maintenane: O/R tools do not neccessarily generate tons of objects (this surely depends on the how the O/R mapping is implemented), but even allowing for implementations that do - if you don't need to touch the generated objects then why do you think this is such an issue? You don't have to maintain them - just re-generate them. (Many people seem to use XDoclet quite successfully for a number of tasks...)

    Finally, just because you know SQL and your framework very well doesn't mean new developers will find it any easier to learn than an O/R query language or an O/R mapping tool. O/R mapping tools are not that difficult to understand!

    Whilst you'll probably take what I've said as heresy and dispute every word I've written, I am really just looking for balanced arguments, backed up with evidence that can be corroborated (which is why people who bandy around comments like "never use XYZ" annoy me).

    Please don't misunderstand me - I think your framework sounds like an interesting and more than valid approach. It is just that IMHO we should at least be aspiring to program in terms of objects and components and not letting the object / relational impedance intrude on our object model, for instance by enforcing a one-to-one mapping of objects to tables.

    Regards,
    Lawrie
  35. Why the fear of generated code?[ Go to top ]

    Slightly off-topic, I know, but why does there seem to be an irrational fear of generated code even when it is code that you do not have to touch/maintain?

    One issue that I have heard people bring up is the potential for bugs in the generated code - and that you then would have to get your hands dirty to fix it. However, surely this is just a bug in the code-generating product and is no different from a bug in other normal product, e.g. Oracle Db. And if there is a bug then the product vendor should fix it (or if it is open-source, then you, or anybody else can do the job)

    If you don't need to maintain the generated code, and the only work it involves is ensuring that you include it in your build file, then why the fear?

    My only other explanation is that perhaps people are worried because they might not have an understanding of the generated code. But I would argue that they should have no need to understand it. They should be treating it like a black box and only need to understand the interfaces into the product, and how to work with it, not its internals.

    Lawrie.
  36. "In the beginning"[ Go to top ]

    "it would appear that you are locked into a one-to-one object to table mapping"

    This is really an example of people from different planets speaking to each other! You try to find an O/R mapping where no exist, because this is your world.

    I will explain by taking you down a path by which is think are more or less taken by intelligent people (like you and me!)

    1) In the beginning you have all your JDBC in your code, building up strings. Then after a while you find that you have bound yourself to one database, Oracle, SQL server or whatever. If the name of a column is changed you have to a dangerous search and replace in all your code..and so on. So you look for something better..

    2) Then you think, this CRUD code is very boring to do, why don't I make a generator that will look into the metaschema in the database and do all this menial work for me? - and you do that - works very well with one table - but after a while in the real world you discover complicated joins over 4,5,6 or more tables with transactions and complicated updates. So you look for something better..

    3) Then you shop for an "industrial strength" O/R tool, like toplink or cocobase..
    But then you find that the solution to your problem is more complicated that the problem in the first place! And your code base is 5 -6 times as big! Memory usage is up -performance is down - and there are still issues not solved..So you look for something better..

    4) So - you are back to JDBC again. First you divide your databaselayer into two parts, one of which is replaceable (call it class A). Then you have solved the database lock in. Second you have an XML-mapping of your database, no objects! - only simple name to alias mapping. (in a small database you just have constants placed in class A). Then you have solved the problem with changing table and colnames and have even internationalized your database. Then you want all the SQL calls to go through one central point so you can modify them if needs arise. That is the function of your second layer (class B that inherits class A) to assemble your sql, to make restrains in the queries, logs to audit trail files, etc etc. Voalá!

    So you see, the class B which you though were a one-to-one O/R map is just a utility class..

    Of course this extreme simple method does not cover all cases - but it actually covers 90%. And with the new Open source Spring framework, based on Rod Johnson’s framework, we will look for something better..

    Regards
    Rolf Tollerud
  37. O/R == more code?[ Go to top ]

    Rolf,

    Why do you think an O/R tools adds more code? I have found this to be the opposite. Once the mappings are defined (which can be gen'd by XDoclet for many of these tools), persistance is a matter of one or two lines of code. The rest is handled automagically. The only thing that requires additional developer involvement are custom queries, naturally.

    Have you had a different experience? If so, what O/R tool(s) has you used?

    Ryan
  38. O/R == more code?[ Go to top ]

    If you have 200 tables with 60 cols the you have 12.000 - 14.000 additional "data-object LOC" in your app + the LOC from the toy Query language. All this is just additional layer - ANSI SQL syntax still have to be used in the end.
  39. about O/R tools work. Thanks.

    -Chris
  40. Woo hoo![ Go to top ]

    <quote>
    I will explain by taking you down a path by which is think are more or less taken by intelligent people (like you and me!)
    </quote>

    no hint of superiority in _that_ statement!

    -Chris
  41. Our industry is brain dead[ Go to top ]

    Where to start. There are som many things wrong with this article ant the reply above... so lets first exaimine why the article sucks..

    "In the case of EAI there is little contest between servlets and EJB components, since servlets have limited usage in an integration context.In the rare scenario where an application needs to invoke a J2EE method and no other mechanism is available aside from HTTP, a servlet is useful for EAI. Otherwise, it simply poses additional overhead and unnecessary architectural complexity."

    WOW! so i guess webservices are not applicable to EAI? Guess what, webservices can be exported via servlets. No shit! And servlets via HTTP are pretty fucken light weight.. for the client, server and bandwith. (of course it depends on what is being served.. often xml is the culprit not HTTP).

    "They are very lightweight (in contrast to stateful session beans), and can be easily pooled to ensure excellent scalability. State management is often needed within EAI, but this can be handled by a proprietary mechanism or by J2EE transactions. Thus, the burden of state management is removed from the application server"

    WHOA!!! use statless session beans, great.. but then where is the state managed? keep the transaction open through remote method invocations? what are you talking about Kyle Gabhart? explain your vauge and crappy writing!

    "If your client and server are separated by a firewall, you'll want to have your client communicate with a servlet through HTTP. "

    What about proxies? I guess IIOP and tunneling RMI via HTTP just does not exist does it.. Kyle, you are full of shit.

    "For more complex requirements, or higher request frequency involving enterprise resources, business processing should be delegated to session beans."

    WHY? justifiy your cliams! you think we can read your mind? you are writing an technical article not expressing opinions

    Kyle, you make no mention of type saftey, versioning of interfaces, or contracts. These are so important to any distributed system, and EJBs solve these problems so much better then a http interface to a servlet.. but you don't mention it because i don't think you have a fucken clue what you are doing. Take your "dynamic knowledge company " and shove it up your "enthusiasm and dynamic analysis" ass.
  42. Our industry is brain dead[ Go to top ]

    |
    | Our industry is brain dead
    |

    And this sort of post just proves it.
  43. well then do it.[ Go to top ]

    Come on nick... prove it.. say something intelligent to back up your valuless statement.
  44. well then do it.[ Go to top ]

    You seem quite bitter.
  45. I feel the need to let you know and take active meassures about this issues. This is the chance you get for keeping your current job. Look at it this way. in the next 2 years your job could be offshored.
    http://www.unionvoice.org/campaign/offshoring/
  46. <quote>
    This is the chance you get for keeping your current job. Look at it this way.
    </quote>

    WARNING! DANGER! Increasing productivity leads to massive layoffs and less jobs! Take action immediately! Say NO to improvements....
  47. For companies that now pay 1/2 and get 4 developers at some thirdworld country were the cost of living is 1/10th of the cost of living in the US. But if the companies are making money from US consumers, then they should employ US developers. Globalization is only good when its fair. Then why make our students waste their time. We should just eliminate Computer Science or science altogether from the university programs. Since they are not gonna find a job in any case. Offshoring should be implemented right. Paying extra taxes for intellectual property coming from another country. Offshoring should be taxed, so that greedy companies dont get away with it just to increase their profit.
  48. offshoring is progress? For whom?[ Go to top ]

    dude,
     
    you gottta get a life instead of trolling endlessly!

    cheers!
    dd
  49. David, makes perfect sense in outsourcing. I hink you have a very less idea of what are being outsourced?? cars?? clothes?? meat ?? oil?? building materials?? electronics?? tell me one thing which you have on you or in your house which is made in USA. My friend i think we are becoming a third world country.. get the meaning.... IT outsourcing is not even $30 bill not even a fraction spent on IRAQ war. Look in to walmart, toyota, any damn company you can think of .... do not walk on side lines.. walk straight and think that way.. you get the answer of dependency..........
  50. Our industry is brain dead[ Go to top ]

    FYI to anonym anonym:

    The correct spelling of the following words are:
    - "fucking" not "fucken"
    - "vague" not "vauge"
    - "some" not "som"
    - "bandwidth" not "bandwith"
    - "tunnelling" not "tuneling"
    - "safety" not "saftey"

    I must confess, I get a real kick out of reading your incoherent posts. Have you considered a career in writing?
  51. Our industry is brain dead[ Go to top ]

    I'm sometimes surprised myself at the juvenile manner some people thrust their opinions around. Where am I, Slashdot or ZDNet?

    Listen anonym anonym, if you legitimately care whether anyone even considers what you have to say (I surmise you do, since you spent precious time writing the above), clean up your comments accordingly.

    If you have a point, I really don't care what it is.
  52. Our industry is brain dead[ Go to top ]

    "I'm sometimes surprised myself at the juvenile manner some people ... Listen anonym anonym, ...If you have a point, I really don't care what it is. "

    Jamison, I added some good point to this thread. Examining and refuting the arguments in the article. You have added nothing but personal attacks. Just so this reply increases the value of my contributions to this thread, rather then detract from it. Here is one more points of interest that this thread is missing.


    - servlets do not mean web interface. As the article points out, it does not even necessarly mean http. Just as ejb does not rmi. So all you monrons who are talking about html pages, and slapping servlets in from of ejbs are missing the point of the crappy article.

    Finally, this article sucks, and this thread is not much better. Lets see if my beer from last night is not too flat.
  53. Our industry is brain dead[ Go to top ]

    |
    |You have added nothing but personal attacks.
    |

    What? And telling the author to shove the article up his arse is insightful technical commantary?

    Aside from calling people "monrons", I dont understand a single thing you have written. Perhaps you should concentrate less on insulting people you dont know and concentrate more on writing something coherant and valuable.

    -Nick
  54. Our industry is brain dead[ Go to top ]

    Sorry if my replies don't include pictures. But let me summarize my points in the hope you will understand them by shear repetition.

    - despite what the article states, servlets are applicable to EAI. Often servers and tools expose a web-service through a servlet. That is, they deploy a j2ee web application, which contains a servlet that handles soap requests. Therefore the article is bunk.

    - the author claims that state can be managed "J2EE transactions" or a proprietary mechanism which does not include statefull session beans. My refute to this was that there are no such mechanisms besides keeping the transaction open through method calls.. which should almost never be done.

    - rmi and iiop can be proxied through firewalls, but the author was not aware of this, and was stating that a firewall necessitated the use of HTTP.

    - the author makes some silly claims like complexity of the application dictates the protocol and interface to it. I challenged him to justify these statements with arguments.

    As a side note, I commented that the article makes no mention of type safety, and data type definition and conversion which is one of the greatest benefits to using EJBs, and rmi objects over a lower level solution such posting to a servlet.

    Lastly, I commented on the authors short biography at the end of the article and brought to lite some questions about his large ego, and made a recommendation about where to store the massive ego.
    to continue adding value to this almost dead thread (thanks to you Nick!), I will make another fresh point..

    - servlets offer greater interoperability then an ejb component or an rmi component could as they place far fewer demands on the client. The client needs only to make an HTTP request, rather then be an RMI or CORBA client.
  55. Our industry is brain dead[ Go to top ]

    You know, if your original post was this (that is, the original post w/o the ad hominem), I would think a lot of useless posts would be gone.
    Anyway, I agree with most of your points here.
    Both SSB and servlets have theirs uses.
    Re your last point (clients): this tends to be especially true when your client (applet for example) is deployed over internet. In such a case you'd have only few options:
    - tunnel RMI/IIOP through HTTP. Might not be possible, as your client is very likely to be behind another fw you have no control over.
    - wrap the EJB in a web service (means possibly deploying huge jars as part of the applet. yuck)
    - use servlet. A lot of roll-your-own code, but probably the smallest footprint.
    Regards,
    Vlad
  56. Our industry is brain dead[ Go to top ]

    that is, the original post w/o the ad hominem),


    I had never presented an ad hominem in the original post. I refuted the arguments of the article with solid evidence, my personal attacks where not justifications for my arguments, in fact it was the reverse, my personal attacks are justified by my arguments against the author. For example... "your article sucked, therefore you are stupid" rather then "you are stupid, therefore your article sucked". You will note, that my post took the structure of the former not the latter summary.

    >use servlet. A lot of roll-your-own code, but probably the smallest footprint.

    As I explained in my previous post, many existing tools already expose a web service via a servlet. The tools generate much of this code, just as the ejb stub and skeleton generators create code for you. The only difference as the the web services tools have yet to be standardized, and I don't think they should be.

    >Both SSB and servlets have theirs uses.

    Sure, but this article has made no progress in defining what those uses are. TSS should be a shamed of even linking to this piece of shit article.

    I am glad that Nick made some good points in his reply about how the ejb standard allows different protocol interfaces to be exported for the same ejb, this makes the technology very attractive.
  57. Our industry is brain dead[ Go to top ]

    I consider any personal attacks in a post ad hominem, mostly because w/o direct interaction with the author you may not know the context. (i.e. it might not be the author who's stupid but the managers responsible for this). I've seen a number of papers from people I would not consider stupid that were really bad (just as well their managers didn't seem to understand irony...).
    Mind you, I'm not taking away your right saying that the author is stupid, the article (in absence of any other evidence :) ) gives reasonable grounds for this assumption. I just stated that saying so hadn't helped the discussion, quite opposite it hampered it as people who would otherwise very likely agree with your arguments went berserk w/o even reading them.

    But anyway..

    - WS via servlets.
      I know this. My roll-your-own was meant for the client side rather than server. I don't really care whether on the server I have or don't have to include another 1MB worth of jars (axis for example), but it may make a huge difference on the client - 1MB+ stock tickers?

    Regards,
    Vlad
  58. Our industry is brain dead[ Go to top ]

    Thanyou finally for a sensible post (though you still continue with snide comments that insinuate that I am completely stupid). Its usually good manners NOT to assume fellow readers are completely stupid - expecially since you dont have a clue who they are, what they do, or what they know. You only make yourself look silly.

    I will repeat one last time (as have many others on this thread) leave out the personal attacks, snide comments, profanities, insults etc - then maybe people might actually listen to what you have to say. Otherwise, read here for more tips on pissing your fellow readers off.

    |
    | despite what the article states, servlets are applicable to EAI
    |

    Yes, true. However, to say "Servlets" is a little low level IMO. SOAP and XML messaging have a place in EAI. However, typically, for EAI we want some kind of guaranteed asynch transport which makes JMS a more suitable choice. For synch interactions, then, yes SOAP over HTTP is a decent choice (IMO, in this scenario, a SOAP binding onto a stateless SB is the best choice as it allows SOAP, CORBA and RMI).

    |
    | - rmi and iiop can be proxied through firewalls, but the
    | author was not aware of this, and was stating that a
    | firewall necessitated the use of HTTP.
    |

    Theoretically you are correct. However, in reality (or at least, in my experience) security people are very, very reluctant to do this. Essentially using http allows you to avoid the stupid, but inevitable, buerocracy that arises trying to get binary protocols through an external corporate firewall. (internal firewalls are a different story - but even then, I would avoid proxying, and just allow the protocol on the required port)

    | - servlets offer greater interoperability then an ejb
    | component or an rmi component could as they place far fewer
    | demands on the client. The client needs only to make an
    | HTTP request, rather then be an RMI or CORBA client.

    While largely true (dont forget that servlets dont even require http) its all a question of what level you want to be working at. In order for it to be useful, you want to be working with something like SOAP over HTTP. Now, IMO this is much simpler than a CORBA client (any day) and its about even with an RMI client in most situations. As I stated earlier, a stateless SB, provides SOAP, RMI, CORBA client bindings and is by far the most flexible (and also gives you transaction demarcation and security for free).

    -Nick
  59. Our industry is brain dead[ Go to top ]

    Theoretically you are correct. However, in reality (or at least, in my experience) security people are very, very reluctant to do this.


    I was reffering to the ability of the sun jvm to tunnel rmi via http. Performance sucks, but is better then soap.


    > stateless SB, provides SOAP, RMI, CORBA client bindings

    thats a very good point, the addition of a soap client view is a nice addition to the spec, I have not seen this in a product yet, hopefully it will not complicate the deployment of an ejb any more the necessary.
  60. Our industry is brain dead[ Go to top ]

    |
    |I was reffering to the ability of the sun jvm to tunnel rmi
    |via http. Performance sucks, but is better then soap
    |

    However, there are not too many appservers that suppourt RMI/http. In fact, Weblogic is the only one that I know of.

    -Nick
  61. Our industry is brain dead[ Go to top ]

    You have added nothing but personal attacks. Just so this >>reply increases the value of my contributions to this >>thread, rather then detract from it.


    When did you begin interpreting my suggestions to you as personal attacks? I was critical of the manner you presented yourself - a manner of which I feel is immature - and that you can change. I'm not attacking you.

    If you feel that my above statements were personal attacks, I truly feel sorry for you.

    TO THE OTHER READERS: I normally just ignore individuals who post in this manner, but I value the mature dialogue in this forum. This is branded as "Your J2EE Community", so is it asking too much to expect posts to be free of name-calling, profanity and outright flaming? Or is basic netiquette a thing of the past?
  62. Tunneling works, sorry...[ Go to top ]

    <quote>
    What about proxies? I guess IIOP and tunneling RMI via HTTP just does not exist does it..
    </quote>

    Guess again. It _does_ exists. And, sorry to tell you, but it is older than J2EE, actually.

    []s
    Michael Nascimento
  63. Tunneling works, sorry...[ Go to top ]

    That was sarcasim you dolt. I was pointing out that the article incorrectly assumed that a firewall implies the need for http. It does not, as you point out, but the author of the article must not have too much experience other then "mentoring" and whiteboarding.
  64. Database access logic and business logic should not be inside JSP.

    EJB is designed for TRUE three-tier client/server application where the middle-tier (your application logic) is independent from presentation tier. You can replace your front tier without re-implementing your business logic, or have more than one presentation tier: JSP, Swing, J2ME, CORBA program or upcoming Java Server Page.

    If you implement your business logic and database access logic inside JSP, you will have to do it again when you need a different presentation tier.

    Perfecting J2EE!
  65. Database access logic and business logic should not be

    >inside JSP.

    I strongly agree (who wouldn't). But pure Java objects (pref. JavaBeans) are in _most_ cases just as good as EJB's. Haven't tried JDO yet, but it does sound like a sound idea for persistence. JSP/Servlet/POJO/JDO using an MVC framework will be my next try..

    Not that I have anything against EJB's. Actually I love them.. but if all you have is a hammer, everything starts to look like a nail, doesn't it :)

    //ras
  66. tools[ Go to top ]

    ...but when all you have are nails, *nothing* looks like a hammer.
  67. n-tier client/server applications[ Go to top ]

    |
    |If you implement your business logic and database logic
    |access inside JSP, you will have to do it again when you |need a differentpresentation tier.
    |

    Nobody advocates that Database access logic and business logic should be inside JSP.

    But you can only use an XML mapping file to make you database independent and even protect against changes in tablenames and colnames. Then you need neither EJB nor O/R. The business logic and database logic can still be completely separated in PLJO.

    Regards
    Rolf Tollerud
  68. Re: Rolf[ Go to top ]

    Rolf,
      If you have a home grown component that can manage object to database mappings (the XML mapping file you refer to), you are correct (by the identity principle of O/R mapping) that you don't nedd an O/R tool. However, not everyone is going to go through the work of inventing their own O/R mapping when there already exists tools out there to manage this for you (such as TopLink). I recommend people to get to using 'standard' or at least widely used tools rather than re-inventing a ever-evolving wheel from project to project for consistency's sake. As far as EJBs, and I assume you are referring to the 'Entity' portion of EJBs, CMB entity beans are also filling the role of O/R where fields of the bean are being mapped automatically to a database field (and perhaps this mapping is saved as an XML file, but this implemetnation detail is vendor specific). In both cases, you shouldn't need to modify any code to change how the objects are being mapped to a database (this should be configured through a separate tool).

    However, the other 2/3 of EJBs (the SFSB and SLSBs), in my opinion) is where the business logic should sit, whereas servlets should be married to JSPs to manage user interaction with the JSPs. I think a good arcitecture is a set of servlet-JSPs to present the user the web interface functionality, the session beans to perform business work that the user requests, and entity beans to persist the data to persistant storage (such as a database). Some people hate EBs (entity beans) so badly that they will just have their session beans make use of JDOs instead of EBs, but I think it comes down to your comfort with a tool, some people think it's easy to make solid EBs that perform well, others think they can't trust the tools and will only be happy doing it themselves. (I think, if you have time in a project, to try it both ways, but who has that much time?)

    -Chris
  69. Home grown?[ Go to top ]

    Chris,

    |
    |not everyone is going to go through the work of
    |inventing their own O/R mapping
    |

    You misunderstand me (or I was not clear). I have not made my own home grown component that can manage object to database mappings. The XML file I refer to is only a simple file that matches the names (tablenames, colnames) to the internal names. No objects are involved. In fact, in case of small databases I just put the names as constants.. an insurance in case somebody changes the names - to another language for instance.

    Then I use a tool to generate the CRUD JDBC code. Again, no objects are involved.

    On the contrary, it is the O/R - tool vendors who use home grown code - by that I mean that they use their own home grown query language instead of ANSI SQL.

    The database layer is divided into two classes, one of who is replaced in case of a different database (or language), and is together only about 600 rows of code (15KB). The results are returned as dictionary collections.

    1) I am insulated against the database changes and name changes
    2) I have insulated the database layer against the business layer
    3) I have a central point where I can modify the queries (additional restraints)
    4) I have an audit trait of every change, on field level (for replications or security)
    5) I have the full power of SQL query language, with transactions.

    I am not saying that it will suffice in all cases (for example I am restricted to SQL databases) but it will suffice in 90% of the typical Web-applications cases.

    Performance is better, productivity is better, maintenance is better (without tons of generated objects), and best of all, I don't have to learn anything new (I have enough to learn anyhow).

    In one word, KISS

    Regards
    Rolf Tollerud
  70. Re: Home grown?[ Go to top ]

    Well, when you describe a tool that takes a file that maps one field (and in this case, not a physical object, but certainly a 'coceptual one' or is everything in your system basically a hashtable?) that's exactly what O/R tools do, although in the traditional sense a physical object is being mapped to a relational db. In your system, it sounds like there are still 'objects' in the sense of collections of data that is being mapped to a table....and the 'tool to generate the CRUD JDBC code' something you found on the web or something you created for yourself? If you made it for yourself, that's what I'm referring to as 'home grown'.

    <quote>
    On the contrary, it is the O/R - tool vendors who use home grown code - by that I mean that they use their own home grown query language instead of ANSI SQL.
    </quote>

    On the contrary on the contrary, Toplink does not do that, it mantains an XML file with the object fields to table mappings (and some other meta data about how the relationships map, such as 1 to 1, 1 to many, how the referred to objects should be created (proxies or directly)). There is an API to create queries to the datastore but this is just an abstraction of the data layer, the storage may not be in SQL (but the API isn't that strange, you have statements like:

    Expression builder = new ExpressionBuilder();
    builder.get("reviewStatus").equal(theStatus));

    <quote>
    The database layer is divided into two classes, one of who is replaced in case of a different database (or language), and is together only about 600 rows of code (15KB). The results are returned as dictionary collections.
    </quote>

    Ok, I've been in this situation before, and this is only easily maintained by the person who wrote the system. New people comming in will not be able to look at an object model or a JavaDoc or something describing what fields exist for a given data type. Everthing in your system is reduced to Strings, and complex objects are complete out the window.

    Also, with only 2 classes, means that if you have any type of source control, only 2 people will be able to maintain the code at the same time. In more complex systems (whcih are becomming the simple systems nowadays) involving shipment services, billing, inventory, order status and customer support, you'll have more than 2 developers that will need to work on their persistance layer for their respective tasks, and having 2 classes do the entire job will prevent that from happening.

    But, hey, if it works, it works, so you go girl! I'm sure it's a very practical system once you get used to it, and that's really my point about using EJBs, O/Rs and all the other technology we're debating: once you know how to use it, it becomes very natural.

    -Chris
  71. Maintenance?[ Go to top ]

    Chris,

    <is only easily maintained by the person who wrote the system/>

    What maintenance? Takes about 10 min to grasp it..

    <Also, with only 2 classes, means that if you have any type of source control, only 2 people will be able to maintain the code at the same time/>

    What maintenance? A generic system doesn't change from project to project.

    Everything in your system is reduced to Strings, and complex objects are complete out the window

    That is correct. Why not? Works very well in 90% of all Web-applications.

    Regards
    Rolf Tollerud
  72. Genericity[ Go to top ]

    Rolf,
      There is such a thing as being 'too generic'. I would like you to humor me and tell me how many fields are in your database that you are mapping your data...I don't mean tables, i mean columns of tables. I want you to tell me if you have Customers, Orders, OrderItems, Addresses, Roles (for security), Inventory objects, etc....I want you to give me a number, I'm gonna guess it is something around 60, and then I want you to tell me how 'easy' it is to remember those 60 fields, with the proper case, and that you can do this in 10 minutes.

    Bullshit. But I can learn 6 objects in 10 seconds and let code insight tell me what properties are there, and even tell me their types.

    With physical objects, you don't need to remember every individual field, just the objects themselves (I've named 6 above), and most IDEs will do the rest of the work for you with code-insight. And with complex data types, I can get to nested data in a more natural manner such as shipTo.address.getCity() using objects, vs: shipto_address_city as a field name. Lord knows that it's possible that you could make your billing address city found in billto_address_cityname which is completely legal, but reusing Address objects keeps everything consistant with respect to addresses.

    Maintainable? Maybe if you wrote it yourself, but handing it off to a support team would be a nightmare without very detailed documentation (which you should bundle into your total time of development...I can run JavaDoc for a complete object model in about 10 seconds.)

    -Chris
  73. RE: Genericity[ Go to top ]

    I never thought I'd come out supporting Rolf on something, but I think he has a point. For my last project, I wrote a simple SQL-XML mapping framework (built off of ibatis's database layer) to map the sql results into jdom elements. I then took those elements and, using stxx (http://sf.net/projects/stxx), transformed them into html.

    This worked well for a couple of reasons. First, the client had only a slight idea what the requirements and desired functionality even were starting the project. Yes, that includes schema. Second, the mapping layer performed query caching by caching the xml objects, and combined with the ability to only pull what data was absolutely necessary, the data layer was actually pretty fast. Third, it was really easy to debug as you could always just dump the xml to the screen (feature of stxx). Finally, as the data was completely separate from the presentation layer, it was perfect for sending different views of the data (html, wml, pdf, etc) to different types of clients.

    Of course your point about "everything a string" applies. It also has some disadvantages like increased memory usage and more resources to transform the xml (when its not sent to the client for the transformation).

    However, given the dynamic situation and eventual requirements, it turned out to work quite well. Obviously, it wouldn't work for everyone and if your domain model is set in stone, it would lose much of its attractiveness, but for rapid development and flexible design, it was a good match.

    Oh, and application did have all three layers - presentation, business facade, data access - but of course the last two spit out xml elements, which actually is kinda nice because, for example, the data access layer could be getting its data from anywhere as long as it is transformed into xml for output.
  74. RE: Genericity[ Go to top ]

    Hey, if it works, it works. And at no point did I ever argue that the methods you are using doesn't keep the presentation-business-data tiers separated....I just argued that they are not as easily learned or maintained as a system using OO principles (yeah, here's a whole new can of worms to open, i know, but let's just digress on the OO comment and stick with what we have been talking about all along).

    <quote>
     I never thought I'd come out supporting Rolf on something, but I think he has a point. For my last project, I wrote a simple SQL-XML mapping framework (built off of ibatis's database layer) to map the sql results into jdom elements. I then took those elements and, using stxx (http://sf.net/projects/stxx), transformed them into html.
    </quote>

    Ok, sounds like you are using yet-another-homegrown-O/R-tool. I've been arguing this whole time that O/R tools are fine. No argument. This particular thread is about genericity and where too much of it is a bad thing. In Don's case, if you have schemas that can give some structure and definition to the otherwise infinitely flexible nature of XML, then I think you are doing the right thing. If the XML structure means that you can change it easily, and if you are using to shuttle information between data tiers and presnetation tiers and business tiers, well that's fine and dandy too.

    I think it started to break down when you said that you may send the XML structure to clients so that they can transform the XML for you. This could be a problem because when your XML structure changes (and that's why you are using in the first place: it's so generic that you can make changes to it easily) but now you need to go back to all your clients and notify them of the changes. My solution to this would be a internal XML structure that you an use to model your data, and a 'published' XML structure that is used to communicate to your clients. This way you can have a flexible implementaiton of your data model, and your clients can rely that the information they are going to recieve is in a reliable and consistant structure.

    Anyways, I think I'm going to have to step back from this thread as it's going a little too far off topic for me.

    -Chris
  75. But .. where is the data ?[ Go to top ]

    Is it not possible to measure the performance of systems doing equivalent work with these two designs ? A page of peformance data would be worth more than a thousand opinions in my view.

    Does anybody have numbers from real work ? By this I mean not from a vendor ... I know that I have never taken the opportunity to build a system in production with two different architectures. (Budget people get so upset when I say stuff like that ;-D ) But ... anyone else ?

    For me .. talk without numbers is not very convincing. Gabhart deserves respect in my opinion by the way and I dont understanding the trashing of him or his work. We all do the best we can ... right ?
  76. Rot in hell Commie[ Go to top ]

    For me .. talk without numbers is not very convincing. Gabhart deserves respect in my opinion by the way and I dont understanding the trashing of him or his work. We all do the best we can ... right ?

    If we reward effort, then all thoese retards running the 50 yard dash in the special olympics will be running this country. You want that? you fucken commie.

    My arguments aginst the article are clearly expressed. Did you read it? do you disagree? then reply with your arguments! not this vauge "can't we all get along" crap. Ignorance should be exposed, I have no respect for people like Kyle Gabhard, there ideas and thinking is flawed as I have already explained.


    "Is it not possible to measure the performance of systems doing equivalent work with these two designs ? "

    What desings? nobody is talking about any, protocols, systems, use cases or even existing systems or requirments.. and you want numbers? thoese numbers will be just as meanigless as this article, and your post. Come on, think before you type.
  77. I forgot to mention[ Go to top ]

    Ah, I forgot to mention that Toplink provides the same SQL power you were speaking of before, as you can write hand-rolled sql if you want:

    ReadAllQuery query = new ReadAllQuery(Document.class);
    query.setSQLString(sqlString.toString()); // make sure this SQL has all the fields of the Document table or toplink will not be able to map.
    return TOPLink.readAllObjects(query);

    -Chris
  78. to send the whole SQL string directly[ Go to top ]

    Chris,

    <query.setSQLString(sqlString.toString());/>

    If you do like that, then you will not have any central point where to modify the sql, do audit trail, security test etc etc.

    Regards
    Rolf Tollerud
  79. Central Point[ Go to top ]

    Firstly, I did not say where sqlString was being initialized from, it could come from a external file.

    Secondly, why is centralization so sexy? If you have 1 file with all your statements in it, that means only 1 person can be modifying it at a time...even with CVS, you'd still have to merge allt he changes from all the people working on this central file.

    Thirdly, I only included this point to demonstrate that the 'power of SQL' is still at your fingertips if you need to write tricky and crafty queries by hand, otherwise it's recommended to use the API because querries can then be cached (another sexy feature of Toplink).

    -Chris
  80. Re: security, audit trail, etc[ Go to top ]

    Rolf,

    <quote>
    If you do like that, then you will not have any central point where to modify the sql, do audit trail, security test etc etc.
    </quote>

    As far as security, if you are talking about applicaiton security, to me that's a business logic rule and does not belong in the data tier. If you are talking about data security, you do have to log in to the database with a user/password.


    As far as audit trail, TopLink (and I can't imagine other O/R tools not supporting htis) has a debug mode and logfile configuration that will output all the requests made to the Toplink engine so if anything goes wrong you can see exactly what TopLink is trying to do.

    -Chris
  81. Chris,

    You are right in the number of cols in the tables, it is usually around 40 - 50. About code insight I don't know, I never don't use IDEs, preferring to use a text editor and the debugger. You may have a point there, albeit a small one.

    <handing it off to a support team would be a nightmare without very detailed documentation/>

    I only can say that I don't think you really have grasped KISS yet.

    only 6 methods,

    executeSQL
    executeSingleRow
    executeNonQuery
    SQLupdate
    SQLinsert
    SQLdelete

    example of use,

    //Update
    sqlCmd s = new sqlCmd();
    s.Cmd = "UPDATE";
    s.Table = act.company;
    s.Set = "Addr1 ='112 Bay Area'";
    s.Set = "Zip ='111111'";
    s.Where = "id = 'C0921221501030'";
    //Console.WriteLine(s.buildSQL());
    int rowsAffected = s.SQLupdate();

    About user, groups and roles.
    Take an example that we have users and groups that are able to see information on hundreds of places in the application. On any particular request, the system shall check if this particular person have the right to the information she have requested. Or, it doesn't have to do with security, the case can be that the secretary (or whoever) have asked to see only information that belong to one specific user or group.

    The best way to do it, IMO, is to have all SQL request go through the one point where they can be modified (restrained). How do you do this otherwise?

    Audit trail
    If somebody modify information I want log, the unique id, tablename, colname, date,user,group owner, type of modification, before value, after value. Important for replication and other issues. Again. So, how do you do this in your system?

    Regards
    Rolf Tollerud
    (everything is a string!)
  82. Re: Rolf, Redux....[ Go to top ]

    Ah, i think my point is being completely missed....but, since you admitted to preferring to use text editors instead of full fledged IDEs, I can see what I'm dealing with here: someone who is completely set in his ways and no point discussing it.

    -Chris
  83. I am jealous[ Go to top ]

    text editor and the debugger


    Wow! If I had such excellent memory to remember all those APIs, columns, etc. and/or time to look and memorize all words,their cases, parameter types etc. I am agree: text editor is the excellent brainteaser!
  84. Rolf,

    I assume that the code example you gave is from your framework. How do you handle things that O/R tools address for you, such as inheritence and object relationships? Also, how is your framework different than an O/R tool?

    Ryan
  85. what is is unclear?[ Go to top ]

    Ryan,

    Your question is very abstract and vague Ryan, why don't you give me some real life examples instead?

    Or better still, give me an answer to the questions I raised in post #73507, about user/groups restrains and audit trails? (Which was elegantly sidestepped by turning attention the completely irrelevant issue of whenever to use IDE or not that had nothing to do with the discussion -a way of arguing that is unfortunately all to common here in TSS and used when you run out of arguments).

    The miniframework should be self explaining, what is it that is unclear?

    Regards
    Rolf Tollerud
  86. what is is unclear?[ Go to top ]

    Rolf,

    Fair enough. I will try to be more clear this time.

    From you code snippet, it looks "similar" to the steps one would go through when setting the parameters in a PreparedStatement. By similar, I mean that there is a line of code per attribute being updated. I also assume that the column names being used are "logical" names that are mapped top the actual database column through your mapping file. I also appears that each sqlCmd object applies to exactly on table.

    If this is the case, I am curious how you handle inheritence. For example, say you have a class that has two subclasees. The common attributes are stored in one tables, and the attributes unique to the two subclasses are stored in two other tables. Would I have to (in code) create to an sqlCmd object to handle updating one of the objects? Would I have to have that same code for the other object, too?

    Also, if I want to delete on object, will it handle deleting dependant objects, or do I have to code that part, too? If I update an object that contains dependant objects, will they be updated, too? Finally, since everything is a String, how do you updated items that are not represented will by Strings, like timestamps (although this could be overcome) and binary data.

    I am not trying to disparage your framework. Maybe some of my assumptions are wrong and I sure it has worked fine for you. But O/R tools handle many complex O/R issues, some very cleanly and compactly, greatly reducing complexity AND code. They are not just for "quick and dirty" projects.

    As for auditing/security...this seems orthogonal to persistance. You can have a persistance framework and easily plug a security framework. Is the persistance layer really the right stop FOR security? In fact, shouldn't the security question be answered BEFORE you get to the persistance part? Also, most O/R tools (and databases) provide very fined grained auditing, including logging every single database statement.

    I hope this clarified my questions from before. It is also a welcome and refreshing "calm" exchange :-)

    Ryan
  87. communication problem[ Go to top ]

    Ryan,

    <From you code snippet, it looks "similar" to the steps one would go through when setting the parameters in a PreparedStatement.By similar, I mean that there is a line of code per attribute being updated. />

    Yes it looks familiar, but the class is just an utility to build the SQL statement.

    <I also assume that the column names being used are "logical" names that are mapped top the actual database column through your mapping file/>

    Yes, that is correct.

    <say you have a class that has two subclasses. The common attributes are stored in one tables, and the attributes unique to the two subclasses are stored in two other tables/>

    But this is about JDBC, DAO only - there are no mapping-objects, only SQL".

    <Also, if I want to delete on object, will it handle deleting dependant objects, or do I have to code that part, too?/>

    Again, there are no objects. The database is normalized, with integrity constraints and cascade deletes.

    <since everything is a String, how do you updated items that are not represented will by Strings/>

    Of course you can have all types of Items in the database. By everything is a string I mean that I always deliver the resultsets as string arrays (dictionary collections really). Binary fields have to be handled separately (not that I have much use for them!)

    <As for auditing/security...this seems orthogonal to persistance. You can have a persistance framework and easily plug a security framework. Is the persistance layer really the right stop FOR security?/>

    Fine for me. You can have it wherever you want AS LONG IT IS IN ONE PLACE ONLY. I must be dumb, but I still can not understand how toplink or any other O/R tool handles this issues. It must be explained to me - slowly. Pretend I am 7 years old.

    Regards
    Rolf Tollerud
  88. This one's for you, Rolf[ Go to top ]

    Rolf,
      Please refer to the url: http://www.webgain.com/pdf/products/toplink/toplink-java35wp.pdf

    It gives a detailed description of TopLink capabilities, including how to do complex joins (which you probably are doing to only return records a person is allowed to see). As a snipit of code that you can see here:

    <quote>
    ExpressionBuilder emp = new ExpressionBuilder();
    Expression allSmiths = emp.get("lastName").equal("Smith");
    Expression inNewYork = emp.get("address").get("city").equal("New York");
    employees = session.readAllObjects(Employee.class,allSmiths.and(inNewYork));
    </quote>

    The addresses for a employee is in a separate Adress table, but you don't need to know this because the TopLink mapping already handles this for you.

    In your question about handling security, just substitute 'city' with 'role' and you can begin to see that if you have a user->role relationship table in your system, you can find all objects where a user's role allows it to be seen.

    There's all sorts of juicy information in that article too about doing query by example (this is sexy: you create the object, specify some values in the object that you want to match on, and then call the ReadAllObjects passing the 'search criteria' object to it, and it will find all matches.)

    Hope this helps.

    BTW: the argument that O/R tools creates more LOC is complete bunk.

    -Chris
  89. Chris is back again![ Go to top ]

    Chris,

    I would answer your post if you had not done the remarks in post #73579 and #73580, and for the try to turn the whole discussion into an IDE or not IDE issue.

    You can not retort to personal bashing and dishonest arguments and then turn around again and try to be serious. Sorry!

    Regards
    Rolf Tollerud
  90. Too bad[ Go to top ]

    The truth hurts, I know, but it takes a big person to admit when he's wrong. Sorry you can't learn from this thread, but it's your loss.

    -Chris
  91. use O/R[ Go to top ]

    <//Update
    sqlCmd s = new sqlCmd();
    s.Cmd = "UPDATE";
    s.Table = act.company;
    s.Set = "Addr1 ='112 Bay Area'";
    s.Set = "Zip ='111111'";
    s.Where = "id = 'C0921221501030'";
    //Console.WriteLine(s.buildSQL());
    int rowsAffected = s.SQLupdate(); />

    this kind of technique have a number of issues, first that comes to my mind is security.

    to make the point:
    most probably most of your data is coming from user input form, so let say company_id has to be entered as "C0921221501030;drop tablespace users;" (exaggerated to make a point), and you use this as your where clause, and you execute your SQLupdate... and poop your tablespace user is gone. this can happen in any place of the code. createParameter is provided for you and other parts of JDBC to properly use it. there are so many security issues that i can't discuss here with this kind of technique.

    the most annoying part is when you handle datatypes and different databases, your "SQL framework" will grow astronomically. it maybe acceptable if you are handling one particular database, but still; handling datatypes is a nightmare with that technique. how would you handle dates? datetime, clob, blob, long, float...etc.

    I18N, how do you handle this? the simplest scenario of this is NLS date format.

    i can still list a lot...care about refactoring? schema redesign? column renaming? and on..and..on, oh well i'm tired already..., i hope others will shy away from "SQL framework" and use O/R instead.

    O/R tools is becoming easier and easier, specially runtime attributes in java is becoming a reality.
  92. Use DAO[ Go to top ]

    Nicky,

    <the most annoying part is when you handle data types and different databases/>

    Well, I never said that could handle all the cases, did I? But column renaming? Have you read the thread? Extensive schema redesign? I think most system will have a problem with that!

    <I18N, how do you handle this? the simplest scenario of this is NLS date format./>

    With data types and different databases it boils down to (binary formats are not that common in my world) the date issue - if I have a choise I always put date as string YYYY-MM-DD, it still can be presented in the any cultural format.

    In web service situations you pass everything as strings anyway. But as I said I can not handle all the cases, my god, it is only 2 small classes!

    But it is the leanest, meanest and fastest.

    +

    I have not give up my powerful SQL queries (a la Joe Celko which BTW have taken many years to learn)

    <O/R tools is becoming easier and easier/>

    Have anybody told you O/R tools are difficult? On the contrary Mr Holmes, IMO - O/R tools is for dummies and quick and dirty contract programming. You - the expert - is not in control anymore.

    Regards
    Rolf Tollerud
  93. DAO, SQL + 1; O/R -1[ Go to top ]

    Just my support for DAO and SQL.
    It is reusable, OO, fast, simple, easy, etc. etc.

    O/R can't do complex apps, you create more GC objects, and like Rolf said, you are no longer in control.

    The "lie" is that if you do DB apps, you do not need to know SQL (but learn OQL or EQL).
    The truth is that if you do DB, somone must know SQL.

    SQL takes a long time to learn, and mostly senior people know it well.
    The position that I do not need to know SQL might mean that you have not needed to write a complex application or one with a large # of users.

    O/R can do simple small load apps.
    Like I say, anyone can write a web app.
    An Engineer can make it faster/cheaper.

    .V
  94. DAO, SQL + 1; O/R -1[ Go to top ]

    Good god!

    Come one Vic ! Once again, you are spouting generalities. I guess you really don't want to answer any of the REAL questions that anybody posts around here.

    Please please put up some more quantitative information. Actually this all leads me to ask --> how many projects/times have you used or done industrial stregth EJB development ?
  95. Use Common Sense[ Go to top ]

    |
    | You - the expert - is not in control anymore.
    |

    This, sadly, is the assumption that most developers make and the first place they go wrong.

    Most developers are not experts - yet many like to believe they are. Just because your developers are writing everything, doesnt mean you are in control. (We have the same argument with C++ programmers who "want to be in control" and who are used to manual memory management and hand-writing everything that the Java API's give you).

    The parallel with C++ isnt an altogther valid one - so I wont continue with it - however, the desire to be "in control" is a common one - even if false.

    There are a couple of things that I always see in O/R vs SQL debates and I see the same from Vic and Rolf.

    1) "SQL is more powerful".
    Well, firstly I think "powerful" is silly term with respect to software (how do you measure it? In horsepower? kW?). Anyway. The fundamental thing is that, under the hood, it its still SQL. The question is who writes that SQL.
    Obviously, everything that an O/R mapping tool can do in terms of Optimistic concurrency, caching, lazy loading, eager-loading, batched updates, optimised writes, etc, can be reproduced in hand-written code. But at what cost? The truth is (if anyone has ever looked at the SQL code that O/R tools generate, its exactly what you would have to write by hand.

    2) "SQL gives the best performance"
    This again, relates to the first item. It depends on the tool and the use-case. Essentially, for most use cases, to achieve the same level of performance when writing by hand, takes a great deal more effort (and its bound to be less reliable). Caching, eager loading, batched updates, optimistic concurrency, optmised writes (detecting what has changed and only writing back changed fields) are all basic features of an O/R tool. These, for the same degree of effort, usually beat raw JDBC access for many use cases. For those where, despite a good knowledge of the tool, JDBC/SQL is faster (and you actually NEED that performance) then by all means use it.

    3) "O/R tools are too complex"
    There is a complexity associated with O/R - but how that affects you is all down to common sense. If you are trying to use the O/R tool to do something its not designed to do, then yes, it gets complex. However, if you know the tool (so you havent missed a critical feature) and for a particular use case, using straight JDBC is easier, then by all means USE it. Its not an either/or choice. You are allowed to use both.


    The difference is that, for 80% of the database access, if you are using an O/R tool, you dont need either an O/R or a DB expert. And for the remaining 20%, the "expert" only has to be involved in the design rather than the actual implementation.

    My point, by way of conclusion, is that by all means use JDBC/DAO where that makes sense. But dont use that as an argument to NOT use an O/R mapping tool. You are allowed to use both - and an O/R mapping tool beats handwritten code hands-down for maintainability and speed of development.

    -Nick
  96. there is always a catch, isn't it[ Go to top ]

    "Its not an either/or choice. You are allowed to use both"

    You got a point there. Probably a combination is the best.. But the catch is that is not an option just to allow straight sql directly to DB, if we do that we are back to square one again. And at least for me, the central point of execution is very important.

    Regards
    Rolf Tollerud
  97. use DAO inside your O/R[ Go to top ]

    <Well, I never said that could handle all the cases, did I? But column renaming? Have you read the thread? Extensive schema redesign? I think most system will have a problem with that! >

    have you ever used O/R? or created one? why not give it a try. if you use some decent O/R tools you will find that renaming or schema redesign is easy, all you have to do is to edit the config files, and you don't need to recompile or adjust your classes. in my case i always use my "O/R framework" for a full control.

    <O/R tools is becoming easier and easier/> -- you cut-out runtime attribute, why? you don't understand what i mean? it seems i need to explain it to you or do some little tutorial. ;-)

    below is my "O/R framework" that i written in dotnet, because i can't find any decent O/R in dotnet world, and objectspaces still on the horizon.

    let say you have a value-object "CAR", so most probably you will write it like:

    class Car {
      public long id;
      public string model;
      public string make;
      public string manufacturer;
      public DateTime created;
      ...
    }

    with my O/R framework (in dotnet), these dumb-value-objects becomes super-value-objects:

    [DbTable(XML_CAR_TABLE_NAME)]
    class Car : IDbTriggers {
     [DbPrimaryColumn(XML_CAR_ID)] public long id;
     [DbColumn(XML_CAR_MODEL)] public string model;
     [DbColumn(XML_CAR_MAKE)] public string make;
     [DbRefColumn(XML_CAR_MANU,XML_REF_MANU)] public string manufacturer;
     [DbColumn(XML_CAR_CREATED)] public DateTime created;
      ...
      //contructors to set filters
      public Car(long id) {
        id=id;
      }
      ...
      public IDbFilter getInstanceFilter() {
        ... cols to filter
        return filter;
      }
      public static IDbFilter getFilter(long id,...) {
        ...
        return filter;
      }

      //triggers
      public void afterSave {
        ...
      }
      public void beforeSave {
        ...
      }
      ...
    }
    it is simplified, so that you can understand it. so all i need to do is call my O/R utils like:

    //single instance;
    Persistor p = new Persistor(typeof(Car));
    Car car = (Car)p.load(Car.getFilter(1234));
    car.created = DateTime.Now;
    p.save();
    p.delete();

    //for multirecords
    Persistor p = new Persistor(typeof(Car));
    Car[] cars = (Car[])p.load(); //no filter
    foreach (Car car in cars) {
      car.created = DateTime.Now;
      p.save(car);
      p.delete(car);
    }
    i did not tacle on relationship to make it easier for you. and these VO can be use anywhere, in view, in my controllers, web service. you mention webservice passes are all string? maybe your talking about XML; i guess you need to dig more about it.

    db can change, but i don't care. i can even restructure my tables without touching my classes. so who is in control now? O/R is not for dummies, it is for sane people.
  98. use DAO inside your O/R[ Go to top ]

    What are you trying to prove by showing that OR works well with a single table?

    And you don't have to roll your own, there are at least 2-3 and more coming - I am sure that next year it will be 20+ something..

    pick up at http://www.pragmatier.com

    time will see..

    Regards
    Rolf T
  99. use O/R[ Go to top ]

    < What are you trying to prove by showing that OR works well with a single table?>

    you really don't understand O/R. i rarely respond to a discussion, but your arguments are to much to bear, it may mislead sideline observers that are looking for sulotions. that why i compel to answer.

    <And you don't have to roll your own, there are at least 2-3 and more coming - I am sure that next year it will be 20+ something.. >

    i know them, but doesnt cut-out what i need, "full-control" you mention it right? 20+? where did you get that number, java has been around for 7 years, and there only a handful decent O/R's that i used/know of.
  100. DAO Frameworks[ Go to top ]

    I thought http://ibatis.com/common/common.html is a good DAO framework and O/R mapping tool. Hibernate also looks good, however I haven't used it.

    Here are a list of O/R mapping tools that I didn't like:
    * Cayenne - must implement DataObject interface
    * JGrinder - must extend DomainObject and objects are still not normal JavaBeans
    * XORM - interface based is no good for field validation
    * jRelationalFramework - must extend PersistentObject

    I also don't like byte code or source code enchancers. I don't think much of certain code generation tools either. For example, having to generate DTO (data transfer objects) indicates to me that entity beans are an anti-pattern.

    My domain objects should be ordinary JavaBeans. Reflection, Dynamic Proxies, Inceptors seem to be the way to achieve this. In summary I want a persistence layer that can:
    * Persist POJO (plain old java objects)
    * No byte code or source code enchancement
    * No implementing an interface or subclassing a persistent class
    * Support complex object graphs. Ie. Inheritance, Depend objects

    Cameron Zemek
  101. Cameron,

    Hmm, that seems interesting..

    I will take a look depending on your recommendation. I hope it's something useful!(I don't have a lot of time on my hands and I don't want to catch O/Rticulus - the urge or force or whatever you call it, the yearning to sit behind your desk and construct large systems in stead of being out there and gain money!).

    BTW, have you seen the Trifork's J2EE reimplementation of the .NET PetStore? Same number of LOC, and performance is great too! That confirms a suspicion of mine that there is nothing wrong with Java nor the Java community either - except that it looks like they have gotten an exceptionally severe attack of O/Rticulus..

    Patterns are language agnostic.


    Regards
    Rolf T.
  102. DAO Frameworks[ Go to top ]

    Cameron,

    I totally agree with two of your requirements for a persistance mechanism: The ability to implement and persist domain objects using POJOs, and the ability to support complex object graphs. IMHO both are definitely essential.

    However, could you clarify what your issues are with byte/source code enhancement? (please see my earlier post http://www.theserverside.com/home/thread.jsp?thread_id=17805&article_count=103#73566)

    As to your third point "No implementing an interface or subclassing a persistent class", whilst I would agree that you certainly do not want to be forced to inherit from a persistance base class, I don't really see why needing to tag your domain classes with a marker interface (- an interface with no methods, so no requirement for your domain classes to implement anything) would be an issue. Marker interfaces are already used by in the JDK (e.g. the Serailizable interface) and seem to be a reasonable way to specify a class "attribute" of this kind. Or is it just non-marker interfaces that you have a problem with?

    Regards,
    Lawrie
  103. Re: Tagging interfaces[ Go to top ]

    Lawrie,
      I think my problem with tagging interfaces is that now it ties your application to a specific O/R tool. It would be better to have a tool that externally persists POJOs without putting any code in the POJOs that tie it to a specific persistance mechanism.

    -Chris
  104. Re: Tagging interfaces[ Go to top ]

    I agree, tagging interfaces infect (in a virus like fashion) your source code. I see persistence as an "Aspect" and as such I don't believe in byte/source code enhancement. If you use byte code enhancement for the persistence aspect then how many other aspects can also use there own byte code enhancements?? I could be wrong about byte/source code enhancement, but it seems like a hack to me.
  105. Re: Cameron[ Go to top ]

    Cameron,
      I hate to sound like a TopLink enthusiast (really my only exposure to professional level O/R tools (other than EB CMP)), but have you ever evaluated toplink? It would be interesting to see how you like it, as it seems to satisfy your requirements in a O/R tool (plus it has a good mapping editor).

    -Chris
  106. DAO Frameworks[ Go to top ]

    |
    | For example, having to generate DTO (data transfer objects)
    | indicates to me that entity beans are an anti-pattern.
    |

    What have entity beans and DTO's got to do with each other at all?

    Entity Beans are a persistance mechanism - and DTO's are anessential optimisation for network programming. (And in no way should Entity Beans have DTO's on their interfaces.)

    -Nick
  107. DAO Frameworks[ Go to top ]

    You are right, Entity Beans should not have DTO's on their interfaces. But if for instance I want a web page to display a product I have to have a DTO Factory (session bean) create a DTO from an Entity Bean. This is an anti-pattern. With DAO I don't have to create an object with the same properties as the entity bean.
  108. DAO Frameworks[ Go to top ]

    |
    | This is an anti-pattern.
    |

    No its not.

    Your DTO's are use-case oriented. They represent the view on the persistant data.

    In reality they usually aggregate data from a number of entities. A 1:1 correspondance between your entity and your DTO is more of a coincidence (or perhaps bad design).

    -Nick
  109. MVC?[ Go to top ]

    And, I forgot to say, in the pages with html, there are no (zero, nada) code. Not even the small tags that Velocity puts in.

    DS
  110. Don't follow you[ Go to top ]

    Do you include calls to clustom taglibs as code? if so, then using velocity syntax rather then jsp taglibs comes down to just that.. syntax. It is hard to create a dynamic page without controll flow in the pages, like interation and if statements. Otherwise, you do the reverse, embed html in your java code which is just as bad, perhaps I just don't follow what your are saying?
  111. Patterns is language agnostic[ Go to top ]

    Anonym anonym,

    Sorry, forgot to say that it is .NET. I should not have mentioned the MVC system as it is digressing from the main subject of discussion, which are O/R tools.

    The system work just as well in Java, in fact the Java code is nearly identical to the C# code.

    But, for a brief explanation: The html field on the page is set by the "codebehind". It is not so important really, not to have a little "velocity syntax" on the page.

    Regards
    Rolf Tollerud
  112. EJB provide AspectOriented framework for developers ( although fixed number of aspects: Transactions, Security ) and EJB assume that it should be sufficient in most cases.

    EJB( Session/ Entity ) provide nice type control and reduce guess work. Might be what we want or not, depends on a particular case. Servlets have ONE method to call, it look like old C style function declaration "void func()" - it means that the function accepts ANYTHING, ANY number of parameters with various types. For me it looks like Servlet: extremely flexible but very difficult to deal with. If that is what are you looking for, then go ahead an use Servlets.

    But it looks like most people are trying to create wrappers around Servlets, and use Servlets as http connectors only, well, then it looks like ONE Servlet per application will be enough. Struts might be a very good example of such approach.

    IMO: There is one killer reason in favor of CORBA, EJB and alike: those FW define life cycle for objects and various clients (Standalone, WEB-Tier, etc.) can deal with the same _instance_ of business logic.

    In other words: If you tend to treat WEB-Tier as just another UI framework ( I do ), then there is an ultimate need for a real Logic server(EJB, CORBA, anything), otherwise go ahead and explore options...

    j2c (Just 2 cents
  113. Apples and Oranges[ Go to top ]

    I think comparing servlets to EJBs is comparing apples and oranges, from an architectural standpoint. I don't really want to read general arguments in favor of one OR the other.

    I think it would have been better to write an article about a real project, with a history of the architectural decisions that were made. These silver-bullet articles are not always directly usable in the real world.
  114. EJBs are useful[ Go to top ]

    I agree with those who have stated that it is not fair to compare servlets and stateless session beans. Just because EJBs are often used in web-based applications does not mean that is what they are best suited for.

    I'll give you an example of a project that I worked on where EJBs were probably the best option available. The application is similar to an EAI broker. It is responsible for communicating transactions between systems within the enterprise and to external organizations.

    Approximately 90% of the application's processing takes place automatically, so servlets were not an option for these processes. Each transaction is stored in an Oracle database, and each one results in updates on several tables. There are also situations where a single transaction results in updates on tables across mutliple databases. The easiest and most reliable way that I know to implement a sophisticated transaction management strategy is through the use of EJB container-managed transactions. By using EJBs, I was able to implement distributed transaction management without even having to know how a two-phase commit works.

    I'll admit that these types of scenarios are few and far between, but EJBs were obviously not designed with the simple web application in mind. EJBs are really only useful in situations where the most important concerns are things like availability, reliability, and scalability.

    My two cents.

    RAW
  115. Another useless short article[ Go to top ]

    IBM likes those short articles that don't really explain much or add to developer's knowledge. If the reader knows what EJBs and servlets are, what do we really learn from this article? I think absolutely nothing. Hoping to see something interesting and thought-provoking on TheServerSide soon.