>From: <[EMAIL PROTECTED]> >Subject: [jdjlist] Platform Selection - Should I use J2EE+EJB? >Date: Thu, 19 Sep 2002 11:36:16 +0800
>Everyone knows Entity Beans are used to represent business objects or >persistent data. They often exist as single records in database. If I am >not >using RDBMS, but a database which formed by thousands of xml files with >quite >complex tree structure. Moreover, the some applications are going to >perform If... but. Why doesn't this sound right to me? :) >persistent data. They often exist as single records in database. If I am >not >using RDBMS, but a database which formed by thousands of xml files with >quite >complex tree structure. Moreover, the some applications are going to >perform >high volume calculations base on the values stored in the xml files. (e.g. >a >calculation may have to access a single field in all xml files for a >summarized >result) > >Should I go ahead with J2EE+EJB? For some reason, your question gives me the screaming meemies. The concept is correct - you'd use bean-managed persistence to access and manipulate (and persist) the data, and the latest EJB specs certainly support crossing individual entities... but the idea of adding high volume to "thousands of xml files" with "complex" in their description... I'm not sure you're going to GET high volume, no matter what you do. You can use EJB if you like, certainly. It has the capability to support what you seem to need (XML access, cross-entity operations). I'm just not sure you don't need to see if there's a way to shortcut the data collection phase to get that one of the elements in "high volume," "thousands of files," "complex XML" out before investigating technologies. ----------------------------------------------- Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.com IT Consultant _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To change your JDJList options, please visit: http://www.sys-con.com/java/list.cfm
