I have used J2EE for past one year. But, I always wondered about the trade offs of using object oriented database instead of using EJBs.
Databases provides most of the services like transactions, security, concurrency etc. just like any App server. Storing object themselves in the database, with associated businees methods, would be far more efficient solution instead of using relational database and then using J2EE wrapper for objects.
I believe this makes sense, as we all acknowledge the fact that it is much easier to treat everything as object. And at all levels we are using objects anyways, then what is the need for the relational database and EJB wrapper?
Argument in favor of relation database is that it is faster, but we are slowing the application at other level by using App server wrapper around the relational database for all middleware services that is automatically provided by any database.
I'll play devils advocate here. You don't need an application server for business logic with a relational database.
Write Java Stored Procedures using DB/2 V6, Oracle V8 or Sybase V12. Put your business logic behind services implemented using a set of stored procedures.
View a service as a set of RPC targets. This maps on to database stored procedures nicely. The database provides threading, connection management, transaction management (client and server/container demarcated), security.
This is also a valid Web Service implementation. Web Services are end points defined by WSDL that are mapped on to a transport. Just as WSDL end points can be mapped to IIOP or SOAP/HTTP they can be equally mapped to stored procedure calls.
This is a big requirement sometimes. Imagine we had a large legacy 2 tier system with the server side written mostly as stored procedures. We need to add functionality and replace chunks of the code without a big rewrite. As easy way to do this would be to write the new code in Java Stored Procedures (why Java, it's usually better than most stored procedure languages, it's easier to find Java people than stored procedure people, the tooling is familiar and we an migrate them to an application server if we want later). The existing stored procedure code can then also call our new functionality as one stored procedure can call another no problem. Try do that if you put the logic in a J2EE application server.
The problems with this are that databases usually only scale vertically, i.e. by buying a bigger box. Databases that scale horizontally such as DB2 EE or Oracle OPS are expensive. Integrating existing systems is also difficult as not all Java enabled databases support calling out of the database, Sybase and DB2 for example don't implement the java.net packages and this makes external communication difficult (Oracle does). We now have standards such as JCA and Web Services to wrap back end systems and unless database vendors provide JCA or Web Services support from within stored procedures then a database would cause you problems if you used it as your sole middleware.
But, I've seen systems where Java stored procedures were a better choice than Java session beans for business logic. Why? It wasn't a new application and the business requirements made stored procedures more sense than session beans, we don't live in an ideal world. The other factor was performance, stored procedures just blow away session beans when it comes to handling data in the database. The stored procedures uses a very optimised interface to the database and it shows in benchmarks.
The thing to remember in middleware is that nothing is clear cut usually. There is room for everything in the complex world we live in and you can find scenarios where almost anything really does make sense if you've been around the block a couple of times.
it's not clear to me how these Java stored procedures would be reused, if any. You mention they could be migrated to an app server later. How would you do that? Are you suggesting there could be a straight mapping between them and entity beans?
Besides, how about migrating them from some database brand to another? As far as I know, this wouldn't be possible as database vendors have never adhered to ANSI SQL.
cristina at acm dot org
Remember, I'm playing devils advocate here.
Java Stored Procedures can be migrated to an application server very easily. It's just a normal Java class that uses SQL/J or JDBC. When I've done these I tested it in a normal Java main and when it was good, I move it to the database and declare stored procedures for the static methods which are public.
You can therefore use the full power of Java for the business logic and get the benefits of OO features etc. This business logic can then be shared by making a Java class that acts as an adapter. This class has static methods which make the calls to the business logic classes.
This approach has many advantages over session beans and the biggest one is universal compatibility. Every language/platform known to us has the ability to talk to a relational database, PHP, Mod Perl, Java, C/C++, RPG, Cobol. All of these platform can reuse our Java business logic in the database with ease. Compare that to RMI/IIOP.
as partly mentioned by Billy, the middleware is very complex and there are mostly more than one solution, getting the goal. But it isn't also so simple as you describe it with Stored Procedures. First the fact, they are very difficult to reuse and secondly they are more expensive to maintain. As a scenario, which i have realized more than once is, developers nowadays are faster in analyzing, adding or changing code to the well known OO-world, than in mostly proprietary Stored Procedures. So these maintaining works end mostly in hacking some workarounds, cross-adressing packages, not well defined wrapper procedures with extensive using of triggers. When the project gets bigger and older no one is fully able to say what consequences or side effects another changing or addon will have. At last the project become unmaintainable and you have to look for new budget for a complete redesign in J2EE.
The problems you describe can also happen with J2EE. Bad design will lead to chaos whether it's a Cobol application, stored procedures or J2EE. Merely using J2EE is no guarantee of success.
Sybase stored procedures are a nightmare maintenance wise unless you're very very careful. Oracle PL/SQL is better and has concepts like modules, public/private etc which can greatly add to the maintainability of the code.
But, Java Stored procedures are written in the Java language that we all know and love. You can use all the OO concepts/approaches in the design of the code. We can package code in to a jar with a wrapper class/classes included. We then declare the public interface to this as a set of stored procedures.
Other applications can then only make calls to it using the public interface/stored procedure interface. This is very similar to a stateless session bean and is equally reusable I would argue.
I would agree with you regarding use of SQL/J stored procedures in place of session beans. But, I think even more than that my point was to replace entity beans in favor of object database. Most of the databases like oracle provide OO features.
Entity bean just represents object wrapper of the data. It is also having very high overhead in terms of efficiency. By using object oriented features and middleware services of database itself, we can avoid this unnecessary overhead.
I was following this discussion threads for some time. I do not think Oracle or DB2 or Sybase can be called a true OO database. They support some OO features though but seriously lack the most important OO paradigm - inheritence! Only some industry specific databases like POET can be seen as true OO database where storage of information is OOD driven. Major database vendors are providing a sort of OO illusion on top of their Relational architecture! This, therefore, can not replace the Entity Bean architecture of EJB. In fact, mapping an Entity Bean to an underlying database is also a developer's biggest challenge, specially, if the database is part of the legacy system! I think, we are missing a point here. We started our journey from 2 tier applications where databases provided the server processing - in form of stored procedures and triggers. It worked. Why did we take a new path where middleware became the most sought after tier then? The reason definitely is the desire to have a well defined separation of processing logic and data storage. With our embracing of OO technology and Java, it became more and more important since database vendors never provided us a true horizontally scalable OO database. Unless that happens, I do not think we can replace EJB with anything else. XML and XML databases may be a solution, but it will be a while before the XML extensions to the database technology matures to it's fullest potential.
Check out the link below, I found on the net regarding odbms. Anyway, this link below has nothing to do with is EJB really needed or not.
Interesting, I like to hear about alternatives. I'm just sratching my head as to how java stored procedures would handle distributed object access, naming, security and roles
"Interesting, I like to hear about alternatives. I'm just sratching my head as to how java stored procedures would handle distributed object access, naming, security and roles "
That was his point. "EJB Really needed?" implies not needing EJB access/naming/security/roles doesn't it? So, scratch your head a little harder and maybe you'll dig something better up.
Access, roles and security and transactions are available in databases since long time. It is just that it hasn't been a tradition to use them properly at the application level, one reason was lack of standard for OODB access like SQL for RDBMS.
But, I believe that with the proper standards for persistent java objects in the database this can really be a very attractive alternative to be considered in place of entitiy beans.
I think that is very good example of using database as a provider of web services. But, objects will always be important even in web services as only one or objects come together in the logical manner to provide the services. And I think OO is still the best way in web services as well, with the standards of communications between different objects.
Databases have had role based security for a long time now. Databases usually have builtin stored procedures that are the equivalent of isCallerinRole for instance.
Naming for most databases can now be done with LDAP. This can replace the old ORacle tnsnames or sybase interfaces file. What you are looking up here isn't the stored procedure, it's the database. You're supposed to know the name of the stored procedures that you're interested in.
The way things are going, distributed objects aren't so important and distributed services are what it's about. The problem with the database stored procedure approach is that with most databases the only middleware that they can use is the database transport, you wouldn't be able to make calls to a Java JMS or RMI/IIOP from a vendor from a stored procedure and you'd therefore need a front end application server anyway where you could place this type of integration code. It would be basically tying together calls to stored procedures, calls to JCA, JMS other EJBs etc. This fits in nicely with the Web Services vision. We can view stored procedures as yet another type of WSDL protocol.
Thanks Billy for a sensible response.
I would like to ask so-called, J2EE experts and EJB gurus about any logical reasons that they can give for using expensive and inefficient entity beans. Entity beans just represents in memory object wrapper around the data. And it boasts of having middleware services from J2EE servers. But, we can have the same facility with OO features of database and in-built middleware services of databases.
The main reason use of relational databases persists is simply market penetration and legacy data.
There is not inherent design reason, and your argument, from a purely technical design reasoning, is very valid - but is neverthelss, from pragmatic reasons, very wrong.
When most of the world's data resides in relational databases, you cannot just make a "design" decision to use object databases.
If you are developing where you have total control and all your data is new, and you don't have to deal with legacy data, you can put your data in any storage mechanism that best fits your design.
Why even use databases, you can take this argument further and further - why not just use XML repositories - you'll have to translate to XML if you send/receive data via XML messages.
Just warning everyone, since this really isn't a pattern I will move it to the EJB Design forum and mark it as a hot thread on Friday.
What you have said is true from the technical point. But as we are aware, databases scale vertically but rarely do they do so, horizontally. So we would run the risk of locking ourselves with vendors. Apart from this, we cannot wish away Legacy applications yet.
Malay's point is very valid, and I have been thinking along the same lines for some time now.
Take PostgreSQL, for example. This is an object-relational database, which means that tables can "inherit" from other tables and that functions can be defined for tables that can be selected just like regular columns. The PostgreSQL object view is very neat, as I'll explain below:
An empty table corresponds to a class. A column is an attribute. Functions can be defined for a table, and these act like class-level (static) methods.
Each row in a table is an instance of the class (an object). If any function of a table uses data specific to a row, then it's an instance method. So we have a complete mapping between objects and database entities.
(There is the issue of enforcing private attributes, of course, but we'll ignore it for now. It may be too much trouble to define setter and getter functions for every column in a table, unless some special processing is required).
As of PostgreSQL 7.1, there was a problem with polymorphism, because overriding of functions wasn't happening correctly, though shadowing of attributes was implemented correctly. I reported the bug and the PostgreSQL team said it was to be fixed in 7.1.1. (I have yet to check if it's been fixed.)
The point is that if this mechanism now works, we do not need in-memory surrogates for rows in the database (which are what Entity Beans are, anyway). Objects are then *always* persistent, and there is no need for CMP or BMP. All method invocations on Entity Beans are direct statements against the database. The entire Primary Key rigmarole is then seen for what it is, - a crude mapping from in-memory objects to rows in a table. Why bother when the table itself gives you methods to invoke?
In short, the world is ripe for a new look at object persistence, and O-R databases like PostgreSQL can be a happy medium between Object Databases (which are a strange new paradigm) and O-R mapping (which is always a kludge).
If the latest version of PostgreSQL (7.1.2) fixes the polymorphism problem, I'll write up a small tutorial on how to implement Entity Bean functionality using PostgreSQL.
Just an indication as to how easy persistence may be with a database like PostgreSQL:
Objects that need to be persistent implement an interface called (say) Persistent. For any operation on objects of type "Persistent", a helper class kicks in and uses reflection to figure out the attributes and methods of the class and maps them to corresponding columns and functions of the underlying table. We will need to follow some consistent conventions for this mapping to work (e.g. "double accountBalance" should map to "account_balance float8"). The helper class will then fire the corresponding SQL statements. So application developers may not have to do anything except ensure that their naming conventions are OK. The helper class will take care of O-R mapping, and the database will directly handle consistency and concurrency issues.
To improve performance, the reflection process can be done once (say, at server startup time), and the mapping information can be cached.
I can see this working very well for simple objects, but the challenge will be for more complex ones and for complex relationships. Oh well, we'll cross those bridges when we come to them ;-).
Malay, If you really need efficiency then why use Java at all, use good old C++ instead. Of course then you will first need to understand the intricacies of C++ and write it in such a way that it is portable. But then you can use Java. You lose efficiency but it is so much easier to code and maintain.
Same with beans or CORBA servants (in my case). These things have been designed on a certain standard and methodology which helps us to write maintainable code. Code that can still be followed when you and I go away because it is based on standard specification. Of course it is a wrapper over the database. Who wants to muck around databases anyway(no offence to all guys who write sql. I do myself). But the point is that databases are protected resources. It is difficult to make changes in them.(You need DBA'S and you need to fill out thousand's of forms). Different databases have different ways of maintaining them. With new J2EE and CORBA based technologies it is so much easier to write everything in one place and change and maintain it according to a fixed standard.
With today's high end servers with excess of 2GB RAM and multiprocessors the efficiency of such wrappers can be increased. Hope you understand my point.
Thanks for your time.
Ganesh and Vinod,
Thanks for your comments.
Thanks for comments. But, I disagree with your point. I am also great supporter of java language because it is robust and scalable. And much better than C++.
But, this can not be the reason to accept inefficient specifications. My arguments are against J2EE entity beans and not against Java or even other parts of J2EE.
There are ways you can use Java itself i.e. SQL/J to write operations in the database. And this are not just procedures, you can also have java objects(data+operations). This can run on any database as most of the databases support it. Then this can be as maintainable as normal java code.
I guess you missed my point. You are right about using SQL/J being written in Java and hence maintainable. But if you directly run it inside database then you are moving towards two tier architecture(Correct me if I am wrong). It means that all your clients need to talk to databases directly. This violates lot of corporate security standards. As I said databases are protected resources. You should not connect to them directly, hence the use of ejb or corba to access databases in a three tier architecture which might slow things down a bit..Maybe the ejb specification is weak in some areas but I am sure feedbacks from people like you can help improve it.
Thanks for you comments
When you do get around finishing the tutorial, could you email it to me at chris_pais at yahoo dot com. Am beginning to evaluate PostgreSQL and your tutorial could possible provide solutions to my design issues.
Folks I think we have missed the point of the original question.
EJB is not very object oriented - at least not using it. Sure it is created with OO technologies but it forces you
do design in a very non - OO manner. For example - see all
of the session bean wrapper patterns etc. EJB encourages you
to do a big OO no-no - separate process from state. That was
the original insight of OO that is lost with EJB. You also
lose Polymorphism - since inheritance is removed from EJB
(for all intents and purposes).
So ignoring legacy data for a moment - why would you use
EJB and not an OODBMS. OODBMS allow you to have an OO system
where your domain objects are persisted as is. No translation step is needed and so on. So when I write data
to an object - I just write data to the object - no call
to a relational database. Most OODBMS products today do it
by enhancement of your class files - just as the new JDO spec prepossess -
As far as the legacy data goes - if it is read only - use a
primer to prime the persistent cache and write a listener
to listen to database changes.
In fact we just did a couple of prototypes writing the same
system - one to DB/2 using Toplink and Weblogic and EJB and one using POET instead. Not only was the POET written proto
type much more Object oriented - the performance difference
was incredible. The EJB solution - about 30 of our transactions per second - after a LOT of database tuning etc. The POET solution? 2,000 of our transactions per second.
The thing to keep in mind - what is EJB supposed to buy you
1 Distributed objects --- OODBMS also does
2. Transaction support --- OODBMS also does
3. Relational mapping - OODBMS can be mapped to legacy databases in the same way any objects can and if you have
new data why use RDBMS
Every time you use a RDBMS it is compromise after compromise
1. Oh you need to change your object model to match your table structure
2. Oh you have a beautiful relational design but now you need
to denormalize to get performance
3. Data integrity - we can't use foreign keys because this
is too big a performance hit.
David, you can achieve polymorphism with EJBs.
Remember what a ejb does - it presents you with an interface. Yes, you cannot provide extensibility on the interface level, but then, would you really want it? (i.e. getting some remote interface and then casting it into specific subtype..)
You implementation class does NOT specify it implements the interface you'll get as either home or remote. Indeed, I think that the ejb creators stopped a bit too early here and that sometimes it would be nice to be able use explicit mapping (i.e. interface method = implementation method) as opposed to explicit and sometimes I would even like to be able to map to two/more distinct classes (well, I'd like a lot other more complicated things here which I won't go into :) ).
There's nothing to stop you from putting an inheritance hierarchy to your implementation class, while reusing the existing home and remote interfaces. The only difference from vanilla inheritance is your starting point - i.e. EJBObject instead of Object (indeed, this is where the local objects can cause a lot of troubles... I can't see a declarative way (at the moment) how to switch between local and remote beans if your implementation must inherit from one or the other).
You can inherit your remote/home interfaces as well, but then you have to specify another bean and yes you can't pass one as another (again, would you want to? If you need to pass your extended implementation as the original, you would have to register another ejb with the original interface and your extended implementation).
What is true though is that nowhere I could see examples and/or explanations how this should be done etc.
Folks I think we have missed the point of the original
>EJB is not very object oriented - at least not using it.
>Sure it is created with OO technologies but it forces you
>do design in a very non - OO manner.
Absolutely agreed. The cost to a project of having to break an OO model down into EJB's with all the associated patterns, etc. must be considerable vs having one OO model implemented as is.
However there are a number of scenarios where i think using an ODMBS in place of EJB's has problems:
1. non-web application clients to your application. You really need an application server if u want the benefits of centralised code.
2. transactions involving external systems - u can't use the database transaction manager.
There are a lot of web applications that don't need transactions incorporating with external systems as well as not needing to scale to an amazon size. An ODBMS seems nearly ideal in these circumstances.
Easily adhoc querying an ODBMS seems to be a major problem. This is criticle for DBA's an most management :-). Some ODBMS' seem to offer ODBC drivers. Does anyone know if these can be used with standard query/reporting tools?
There is a OODBMS Cache (http://www.intersystems.com
/). It has an ODBC, JDBC, and some more APIs to access its data.
Argument in favor of relation database is that it is faster, but we are slowing the
>> application at other level by using App server wrapper around the relational
>> database for all middleware services that is automatically provided by any database.
This is one of most misunderstood things about ODBMS: My experience and all that I heard of shows that some OODBMSes can be 10-100-.. times faster than well-known RDBMS (of cause if not only ODBMSes will be well tuned but the application will be written appropriately. RDBMS relational model gives you a fundamental advantage here: your SQL statements are converted to the internal canonical form by processor. So you can write the same things in any way you wish but processor will understand the meaning, not the syntax and do it always the same best way regardless of how you expressed this meaning in SQL. But often in practice this is not the case.)
In general IMHO there are two primary areas of using ODBMS:
1. As fast object cash.( Special ODB editions exists here like enJin, Javlin. I’ve never tested them and wondering if someone tried any of these two?)
2. As database for storing complex application data.
Third could also be added:
3. In real-time or near real-time systems.
As of EJB:
I'd like to play it's advocate here:
It's very common to hear from some people: why to use EJB at all?
First of all it should be clearly differentiated between non-entity and entity staff. Most of the criticism concerns entity EJBs. This is not the case to start flame war here so I'll be all-non-entity advocate. Even If I'll play devils(entity) advocate here there are some entity specific things that I see as advantage of entity EJB model:
Idea of abstraction of data entities is very useful for corporate enterprises with lots of different storages as well as types of these storages. So data analysis can be unified. Some vendors can provide data mining EJBs (of cause entity model will need some extensions but even if they will be vendor specific it's definitely better to use one API for all analytical services than to use different service for each type of source). So you can mine on the higher level. High performance is not required here. AFAIK there are no such implementations in EJB currently but I know that M$ already has OLE DB for Data Mining implementations. Anyway this is the subject of different thread.
Yes, ODBMS provides mostly the same middleware services as application servers
are providing now. Furthermore entity specifications are moving towards copying services which are standard to ODBMS but with RDBMS instead(EJB relationships, EJB QL).
Some of ODBMS even provide more sophisticated services.
But the primary advantage and design goal of EJB model is that all middleware services are declarative. This is the key principle of RAD methodology: faster development and time-to market + easier maintenance and testing by automating all common staff that can be automated using tools(IDEs like Together CC in this case). This feature compensates all EJB imperfectness and was sufficient to build a new middleware architecture wrapped around CORBA. In following simple comparison consider this fact.
Middleware services comparison:
1. Transactions - many ODBMS are superior in this area. (since most EJB features are inherited from RDBMS model):
Versant VDS ODB for example supports short and long transactions, savepoints, nested transactions, session control, multisessions... But you should consider that you supposed to be expert in all these advanced features to use them and in most projects you don't need them at all so you’ll be satisfied with traditional flat transactions only (Oracle for example supports only savepoints, but you can emulate nested transactions with them ).
This is not reinvent the wheel case but hardcore of transaction processing.
J2EE provides only flat transaction model here.
2. Persistence of objects - ODBMS is beyond comparison.
For example many ODBMSes support java2 collections as well as providing their own relationships.
EJB 2.0 relationships require you to use two general interfaces here. RDBMS do not have them at all.
3. Lifecycle management : EJB is more scalable here.
Using ODB you will probably use CORBA. Being a layer over CORBA, EJB provides you with all the same services but on the higher level. Programmatic manual-lifecycle POA model gives no advantages here if you don't write middleware services yourself. Of cause, having objects resided in ODBMS you don’t need to pool your objects and reincarnate them just as application server because there is no layer between where object actions and where it is stored. Connection pool is the database cache here. But in this case you will loose network transparency.
4. Security - EJB is simpler to integrate.
EJB security was build to easily be used in corporate enterprise, EJB security reflects it's need and integrates well.
But you can use third party Security DK like Entrust. Pros and corns are the same as in 1. You should be familiar with cryptography, general security concepts as well as those SDK APIs that you will use.
This is not reinvent the wheel case but hardcore of security programming and integration.
5. Network transparency - EJB is beyond comparison.
Having ODBMS without CORBA you still can achieve this issue because many ODBMSes are distributed in nature, but this is only across many DB instances of one vendor database. If you need transparency between different systems you will need CORBA or EJB.
In spite of the fact that EJB means ENTERPRISE java bean many people are trying to use it to build standalone portals and then ask the question: Why to use EJB at all?. When you don’t need scalability and integration you can use anything you want as your business processing engine be it RDBMS stored procedures, ODBMS objects or anything else.
Don't you think that JDO is a step in the right direction to solve at least some of these problems?
Of course J2EE is needed. It is also important not to
confuse that J2EE = EJB. It is entirely acceptable to
create a web-centric J2EE comformant application that does
not utilise EJBs. J2EE != EJB.
All the world is not a (single) database, relational or
From my prespective a database regardless of its various
and sundry features is nothing more than a *passive*
datastore. Full stop.
Do not mistake that just because a particular database
engine has the same basic services as a J2EE application
server that they are the same.
Far from it. This thread has mentioned transactions in
particular. Database engines have transactions and EJB
servers have transactions. Therefore they must be the
same. They are not.
The use of transactions in databases, even in stored
procedures are *explicitely* demarcated. In EJBs they
are not, they are declarative. This is an important
Within the context of EJB I can change the transactionality
of a method by changing the deployment descriptor and not
change code. In a database with stored procedures, I see no
other way but having to change the code.
EJBs are intended to be pluggable components, used in any
number of contexts and business workflows.
I have mentioned this in another thread. Do not confuse
intent with mechanism. J2EE is a specification for creating
extensiable, scale enterprise applications. How it is
actually implemented is a different kettle of fish.
From my experience (15+ years) no enterprise that I have
worked with has had all of their enterprise data in a
single datastore (database or otherwise).
J2EE and the use of EJBs (with the addition of the
Connection Architecture) provide extremely powerful
facilities for building enterprise solutions regardless
of where the data is stored.
Just my thoughts.
> I have used J2EE for past one year. But, I always
> wondered about the trade offs of using object oriented
> database instead of using EJBs.
I work for the leading OODBMS vendor (Object Design), so
you may consider my views to be biased.
At least with ObjectStore, middleware J2EE servers
provide complimentary services to the OODBMS. In short,
J2EE servers distribute your business components, and
OODBSs distribute persistent objects. ObjectStore (and
Javlin which provides EJB CMP for ObjectStore) has always
had a truly distributed, horizontally scalable architecture
which is an excellent fit with J2EE application servers,
eliminating the database bottleneck.
Unlike DB2EE or Oracle OPS, ObjectStore does not require
an expensive 'parallel edition' to achieve horizontal scalability. ObjectStore's Cache Forward Architecture is
inherently scalable, and scales horizontally as you add more application server processes (ObjectStore clients). Peristent objects are cached in the 'middle-tier' and automatically synchronized with the database. If you partition your data across application server processes (for example, by geography) then you can achieve in-memory speeds.
> Databases provides most of the services like transactions,
> security, concurrency etc. just like any App server.
> Storing object themselves in the database, with
> associated businees methods, would be far more efficient
> solution instead of using relational database and then
> using J2EE wrapper for objects.
If you are referring to Entity Beans here, then I believe that many of us agree with you. With the Javlin
product, Entity Beans _are_ persistent objects that are
stored directly in the database 'as is', with no O-R mapping. However, even with that level of optimization, Entity Beans are subject to many performance constraints
imposed by the EJB Container specification. So, even with
an OODBMS, Session Beans that access persistent objects directly offer performance benefits.
So why not use an OODBMS with J2EE? (Great question!)
OODBMSs do not have the market penetration of RDBMSs
and customers are often reluctant to adopt another database
product. I think that part of the resistence to OODBMSs initially was that OODBMSs required C++ or SmallTalk which were considered 'too difficult'.
Today, OODBMSs offer Java and XML interfaces, which make them much more accessible to 'the masses'. With ObjectStore, your database schema is defined by your Java classes. You mark certain-classes as persistence-capable and you demarcate database transactions in your application (the ObjectStore interface is very similar to JDO).
It's true that much 'legacy data' exists in RDBMSs, however it's it also true that many web applications use their own separate database to avoid extra load on the 'legacy database', or for security reasons? In which cases, JMS messaging can be used to synchronize the 'front-end web database' with the 'legacy RDBMS database'. In such architectures, it makes complete sense to consider using an ODBMS with your J2EE application server.
We have many customers doing just this. Usually these customers have very high scalability requirements (for example, Amazon), which push them to discard their database prejudices and select the best technical choice. :-)
In a sense this discussion seems to be driving towards comparing RDBMS vs. OODBMS in the context of J2EE (specifically EJBs). The previous post describes the approach taken by ObjectStore, one of the leading OODBMS products.
As a developer who has used ObjectStore extensively (now considering RDBMSs in the context of java/j2ee), I can say that ON THE SURFACE the notion of persisting your objects in the same way that you would deal with them in the runtime/programming environment really holds a lot of promise. But only when you start using OODBMSs(atleast ObjectStore)do you realize that the flexibility that you get is seriously limited. It is simply not enough for the database to directly support the programming model. I must admit that I have used ObjectStore only with C++, but one of the most restrictive aspects is that the database is virtually a black box once it has been built or input with data giving a user/administrator no useful way of determining(easily) its content. Although, the ObjectStore Inspector tool and the "osverifydb" tool addressed this partially, the process of recovering corrupted databases etc. is very painful. Also, you have to know ahead of time, the query patterns of your users and the way in which data in the db will be accessed because queries and indexes with ObjectStore are a design time decision. So, for anything other than navigational access to data or as a high speed object cache, it is not simple. RDBMSs can support adhoc queries against the data and indexes can be added and dropped dynamically. ObjectStore does not support that (If you did not think of a query when you were designing the system and have deployed it, you have to recode your application to support it). Also, in the OODBMS model (especially the C++ interface) the database clients are so tightly coupled with the schema that schema evolution issues are a special challenge. I don't know if it will be any different in the Java case, as I have heard that under the covers it is basically a C++ database with a Java interface.
Also, once you choose an OODBMS vendor, your decision better be good because it is virtually impossible/impractical to switch.
That said, I have had good success with ObjectStore as a cache for objects where I did not need any adhoc/dynamic capability. Their other advantage ofcourse is that they are much cheaper than their RDBMS counterparts. They definitely make sense for certain applications.
I am not downplaying the significance or difficulty of O-R mapping but I feel that it is a small price to pay in comparison to the flexibility and tools that RDBMSs come shrink-wrapped with.
> In a sense this discussion seems to be driving towards
> comparing RDBMS vs. OODBMS in the context of J2EE
> (specifically EJBs). The previous post describes the
> approach taken by ObjectStore, one of the leading OODBMS
The main point of the previous post is that J2EE and
OODBMs are complimentary.
The J2EE application server provides a framework for
distributed application components. It distributes
and scales application logic. ObjectStore distributes
and scales data, in a manner that RDBMSs cannot.
> I must admit that I have used ObjectStore only with C++,
> but one of the most restrictive aspects is that the
> database is virtually a black box once it has been built
> or input with data giving a user/administrator no useful
> way of determining(easily) its content.
One of the 'areas for improvement' with ObjectStore (and
other OODBMSs) is that unlike RDBMSs, there is no standard,
declaractive Data Definition Language (DML) or Data
Definition Language (DDL). The only interface to the data
is through the application's C++ or Java objects. OO
purists may consider this a positive feature, but DBAs are typically frustrated by it.
> Although, the ObjectStore Inspector tool and
> the "osverifydb" tool addressed this partially, the
> process of recovering corrupted databases etc. is very
This is getting easier, especially with Java and XML. We
are very focused on making ObjectStore more accessible and
providing declarative (XML-based) tools. Today, Inspector
and the JavaBrowser will dump your objects to XML and there
are great new tools (for example, eXcelon Stylus) to format
and convert XML data.
> Also, you have to know ahead of time, the query patterns
> of your users and the way in which data in the db will be
> accessed because queries and indexes with ObjectStore are
> a design time decision. So, for anything other than
> navigational access to data or as a high speed object
> cache, it is not simple. RDBMSs can support adhoc queries
> against the data and indexes can be added and dropped
With Javlin, you can define indexes and query strings in
your XML deployment descriptor. The core ObjectStore
product is adopting the use of an XML 'deployment
descriptor' to define routing of methods to caches,
indexes and clustering of data in the physical database.
> ObjectStore does not support that (If you did not think
> of a query when you were designing the system and have
> deployed it, you have to recode your application to
> support it).
This is not true. One of the big advantages of an OODBMS
is support for navigational access, for example, building
a Bill of Materials (BOM) is simply a matter of following
the pointers between 'parts' objects. Whereas in an RDBMS
this requires a recursive join on the 'parts table' which
degrades in peformance exponentially with the number of
However, OODBMSs also support queries on collections.
The difference is that the queries are defined in C++
or Java versus SQL (which makes no sense for objects).
In Javlin, you can add 'finder methods' for your Entity
Beans by simply adding a finder descriptor to the DD,
<Method name="findRestaurantsByMenuItem(String cityName, String menuItem)">
<QueryExpression> getCity() == $cityName &&
getMenu()has_Item($menuItem) == true
The query expression is any validate Java predicate, and
the parameter values (cityName, menuItem) are substituted
Regular (non EJB) ObjectStore applications (Java or C++)
can do the same thing by passing in query expressions and
variables to be bound to the expression at runtime.
> Also, in the OODBMS model (especially the C++ interface)
> the database clients are so tightly coupled with the
> schema that schema evolution issues are a special
> challenge. I don't know if it will be any different in
> the Java case, as I have heard that under the covers it
> is basically a C++ database with a Java interface.
This is true in both the C++ and Java interfaces, because
your database schema _is_ your application's object model.
When you change your persistent object model, you have
to 'evolve'or even dump and load your data. This is
getting easier, especially with all the high quality, low cost XML tools available to convert Java/C++ objects
Another alternative (for both C++ and Java) is to use
a dynamic (XML-like) schema. ObjectStore provides
the Dynamic Data Modeling Library (DDML) to do this,
or you can store your objects as extensible XML (the
eXcelon product line does this). The downside is that
you now have a mapping layer between your objects and
their persistent representation (although this layer
is generic). However you still retain the other benefits
of ObjectStore (navigational access, cache forward
architecture, scalability and performance).
> Also, once you choose an OODBMS vendor, your decision
> better be good because it is virtually
> impossible/impractical to switch.
This is true of _any_ database. I'd argue it's less
true with ObjectStore. When you use an RDBMS, 35-40%
or your application code is typically devoted to moving
data to/from rows and columns in the database. With
ObjectStore you don't have all this extra code.
> That said, I have had good success with ObjectStore as a
> cache for objects where I did not need any adhoc/dynamic
> capability. Their other advantage ofcourse is that they
> are much cheaper than their RDBMS counterparts. They
> definitely make sense for certain applications.
Many telco applications, realtime securities processing,
and high performance web applications require an OODBMS
for performance and scalability. An added side benefit
is the improved productivity for developers.
> I am not downplaying the significance or difficulty of
> O-R mapping but I feel that it is a small price to pay in
> comparison to the flexibility and tools that RDBMSs come
> shrink-wrapped with.
This is changing - Java and XML-based tools are helping
to make that happen. This includes conversion tools using
XML as the standard interchange format, and XML-based
'deployment descriptors' to make your ObjectStore
applications more declarative and easier to reconfigure.
FYI, here is an old article on JavaWorld, titled "Do you really need Enterprise JavaBeans?" by Anil Hemrajani from iSavvix (http://java.isavvix.com
Thank you all for an interesting discussion.
I am relative new to J2EE, OODBMS, EJB and achitectual questions in this sense.
I i understand it OODBMS could become a serious alternative to Entity EJB, but which vendor is the leading OODBMS provider ??
Could someone also explain to me the difference between scaling a DB vertically or horisontal ?
I would like to also point out that mySQL or PostgreSQL(databases) and JBoss (EJB server) are *free*. I don't know of an OODMS that is. This is for those not caring about scaling too much as JBoss does not support multiple servers. Since mySQL does not support transactions, JBoss makes a nice compliment. At least for Mom & Pop.
On another note, I've heard one fellow claim that he went with EJBs (and really the application servers that support them) just because of the support for multiple servers. EJBs provided the network transparency.
Concerning the use of XML, I realize that it's great for data exchange, but leave performance requirements at the door. And for large databases (> 2GB), you want that in XML?? In Unicode?? (2 bytes per character) Yikes!!
Ozone is a free, OS OODMS.
I tend to pick out the bits that are needed for the project I am working on...
J2EE is a good idea because you are least likely to get vendor lock in...and if you want to change, as long as you don't use the add-ons that most application servers throw in, then you can change to another application server when needed...This is particularly important when you want your applications to run on a number of different OS.
I do make a valid point though of staying away from entity beans?? I find them far too performance hitting for any real use...I tend to go with Stateless session beans that act as a facade that use separate Data Access Objects to connect to the data source I need. The stateless EJB offers better scalability per server than anything else. If you need to have state per session then I suggest passing the state around as XML up to the client or storing the state on a DB record.
I use the age-old method of UI - Business Objects - Data Objects...
I can then tailor my objects to any datasource I like...
Keep in mind that if you put all of your logic on to the database then you will have the following problems...
1. Scalability: - Its great for the first 100 users but once you get more hits than this then the DB will start to grind because it is not being used for just handling data...you have got all of the logic knocking around the server now...(it isn't really a DB any more??)
2. Migration of code: - If you want to support multiple DBs then you have to write multiple pieces of logic...more room for error here
3. Maintenance: - Tracking down a bug on a DB can be a nightmare compared to tracking it down in an EJB/Java object...you could have triggers firing all over the place and this means a lot of digging around in your code...
I have pondered on the idea of Java Spaces becoming more dominant in the future since they lend a hand to parallel processing (Scalability/Power) and storage of objects. We will have to wait and see.
Another idea may be to store everything as XML documents even the methods that are linked with the data...you could then just alter the methods in the XML and the code would be re compiled...a bit like a JSP page is compiled to a servlet the first time you call it??
If I was to tackle the problem my key point would be to actually just think in terms of [objects and processes] and not [objects, processes and some sort of datasource]. As previously stated…Java Spaces technology needs to mature just a little bit and it would be a valid contender to replace J2EE application servers…