There is an interesting article on the O'Reilly Network java site that talks about the flaws in the EJB 2.0 specification. Mainly it talks about dependent objects, and how they are badly implemented in the spec. Too bad the author does not mention JDO as an alternative solution.
Read it here
Tyler makes some good points but I would argue a different conclusion:
Get rid of entity beans completely and make dependant objects addressable from session beans. I don't see an argument for a heavyweight object that represents typically fine grained persistence objects.
Let EJB 2.0 define the following objects.
A) Message Beans
B) Session beans (stateful and stateless)
C) Some framework for making an Object persistence framework available to session and message bean programmers. Maybe, JDO is a sufficient standard for this.
Remotely accessible persistent objects don't seem that useful.
I think we all ought to congratulate Tyler for having the courage to speak up.
As far as I know he is the first person from inside an EJB vendor for publicly criticizing the specs.
And the fact that he does it in public, confirms what I suspected that the spec guys are not very open to criticism.
They do say that they received a lot of input from leading EJB vendors but I very much doubt that they picked up anything relevant. After all, I think there are a lot of very smart guys out there working very hard to implement the specs, and I wondered how they suffered it so long.
I think we all should support guys like Tyrell, and do the little things we can to build some pressure and momentum that will eventually make the guys responsible of the spec to address the real needs of developers and not whatever they think is a smart architecture.
After all, we do love Java and we definitely don't and to be forced to convert to C# or whatever, because of Sun's next "Ooops, I did it again" (remember applets and client side Java?).
Unfortunately, the remedies are not so simple as Billy tried to put it.
Definitely the Message Beans and the Session Beans have to stay there , they are simple, clear and therefore well designed (they are also straightforward).
I think there are cases where you will want an EntityBean (an object representing a persistent entity and having a distributed interface. ).
But those cases should be made exceptions, and developers should be made aware what it really means (spell it in the specs, java blue prints and whatever else is Sun's J2EE evangelizing effort).
Definitely the actual use of EnityBeans can be replaced with an Object Persistence network, but I very much doubt the current Sun's JDO is up to that.
Not to mention that whatever fixing solution will encounter tough political resistence like Sun admitting to their customers that they did something bad, delaying the schedule of EJB, J2EE and whatever else.
Also if you remove Entity Beans as Billy sugested, you'll break existing code base out there.
From reading your reply, I think things are indeed as simple as I mentioned from a technical point of view. The main obsticles you mention are political and this whole portability thing completely is given the wrong spin from the vendors and from Sun.
The 'new and improved' entity beans in the 2.0 spec are already non backwards compatible in any case. Instead containers are supposed to provide a 1.1 friendly container as well as a 2.0 container.
I could also argue that the notion of entity beans being portable is a weak one in any case due to the fact that most applications are completely dependant on the CMP container characteristics that they were built with. Yes, from a simple point of view, the entity beans are portable in source form but in reality the tuning etc required to get good performance in a real application basically makes you dependent on the container implementation in any case.
I'm looking at J2EE from a different perspective than most I think. It's not about letting you run your code on different app servers, it's about defining standards for app server vendors to use for implementing various aspects of the middleware stack.
Once you start to think about it from a standards, rather than portability point of view then I think whats going to happen becomes a little clearer. I can see the contracts for message beans making their way in to a message broker product or a workflow product. These message bean containers will be implemented with a very specific implementation but so long as the container adheres to the J2EE spec then any J2EE developer can leverage his/her existing development environment when using the product. It's not portable (the container implementation basically prevents this by being specialised) but the skillset is portable across different products.
So, my thinking is that J2EE makes the skillset portable but not necessarily the applications. Applications will be dependant on the container characteristics, whether the container is entity beans or message beans. There will be highly specialised containers for messaging especially. If we ever want to see J2EE entering the realm currently occupied by products like Tuxedo or Encina this must happen.
The idea that a vendor can ship an EJB server with a single message bean container is not a realistic one. Different types of application require different RAS/QoS goals and specialised containers will be required to support these. BEA WebLogic may be the first one with a shipping message bean container but the idea that therefore it's the answer is just false. It totally depends on what sort of application you're developing, i.e. whether the container implementation suits your application.
I think the successful J2EE vendors will be the ones that provide a J2EE infrastructure that is open and one that you can plugin third party container implementations.
Portability will be the ability for a specific J2EE server to support the third party bean container that your application needs. It's not just about the API.
I think you wished it was so simple.
Technically, your points are very consistent, although I might argue that I would like different ways to fix the EJB spec.
Not to mention that Message Beans may end up being the poor's man message queue, and you saw there's already one thread on this site talking about some flaws there.
Let's make a little reductio ad absurdum reasoning.
If it was that simple, Billy would have written a nice email to ejb-spec-comments at sun dot com and everything would be OK.
P.S. I also subscribe to the idea is that portability is only a scape goat.
No sane project manager will want to develop a while with BEA for instance and then jumpshift to IBM all of a sudden.
The only thing that matters is developers' skills that you can migrate.
And the market for reusable EJBs, I think it's science fiction for now.
I wish it was indeed so simple but unfortunately, the politics of the situation won't allow it to be so as you rightly point out.
Let me propose a more effective way to change the faulty EJB spec.
We shouldn't use it as developers.
Not at all.
If the politics requires us to use EJBs we can use Stateless Session Beans and make heavy use of either SQL, Store Procedures or Persistence Frameworks.
The projectd who will use the faulty parts of the EJB spec will fail, and eventually some day Sun will wake up to reality.
Aparently they have a hard time confronting the reality and the apearanbce of an EJB specific benchmark shows that quite clearly.
Why bother fixing what they have broken?
You can send the your comments at their comments address, so you'll know you made at least your part of the effort, but other than that, we can develop the way we see fit, use our own brains to solve our own problems, go on and have a life, etc ...
It's their problem and unless I can't live without it being fixed I wouldn't try to break their self confidence, marketing machine, etc ...
I argue that a Java developer can happily develop Java, instead of miserably suffering from EJB.
I liked the article - it explains me why WL6 has no dependents implementation and why EJB2 is still in draft.
I think Mr.Jewell does not mention JDO because JDO poses a serious threat to Entity Beans, something that the leading current EJB server provider does not want to question!
I'm puzzled by the statement at the end of the article when he says that he doesn't know of any vendor that implements dependents ... he mentions only his own server plus the open-source alternative.
I guess that saying that Orion, a $1500 commercial server, has dependents and implements a good slice of EJB2 (no EJBQL, no many-to-many relationship as of today) would do no good to him ...
... especially when in the last days the Orion list is full of praises for the product from people who switched from WL.
I think you hit the nail right the head here. I can think of one EJB server vendor out there who is trying to push Entity Beans at all cost, even if it meant preventing a much cleaner solution like JDO from being considered. And that vendor is BEA. The reason I say this is because once I had a discussion with one of their Toplink guys, and he kept giving me bad press, and spreading FUD about JDO.
What bothers me the most is not so much that some vendors are pushing one technology over another regardless of its technical merits, and only because they happen to have invested heavily in it. What bothers is the total lack of transparency in the specification process as it is now done in the Java Community Process. I mean the spec has been delayed for a while now, and no one knows for sure why, or what's going on behind these closed doors.
I think all of these guys can learn a lesson or two from the W3C working groups. Not too long ago, the W3C realized that they have problem on hand with the way XML Namespaces are being used. Not being able alone to come to a definite resolution to the issue, a they decided to throw the whole Namespaces issue out in the open, and sollicit input from the community at large. Since then the issue has been effectively resolved in manner that the majority of the XML community is quite happy with it.
I refuse to accept an EJB spec that's going to be handed down to me from above, that can only serve the business interests of certain parties and give them some competitive advantage over their competitors. I want a spec that's clean, elegant, intuitive and based on sound technical fundamentals. Just like java is. But most of all I want a spec that the majority of the java developer community has had a chance to contribute to, and is quite happy with the result.
I want your support for the real point of this discussion.
It's not about blaming Bea or choosing Bea vs. Orion.
It's about getting the word to Sun that they did it quite wrong about the whole EJB spec and it is about time for them to clear the mess.
As to what regards JDO, it's getting the same hype as EJB 1.0 had before release, and really, there is no FUD to spread about JDO. It's just something that doesn't exist.
Not for now at least.
And really, I see no differnece between how Sun developped EJb and how Sun is developing JDO
Well, I never thought my article would garner so much attention. Perhaps I can dispell some rumors and thoughts:
1) I wasn't aware of Orion's dependent object support at the time of publication of the article. If I did know it, it would have gotten appropriate press. WebLogic actually does have a dependent object implementation right now, it's just hidden until this confusion is clarified.
2) I didn't mention JDO because I wanted to keep the discussion focused on Entity EJBs. I am familiar with JDO and what they can accomplish. I'm actually a proponent of Stateless session bean -> JDO implementation. However, I think there are many options available for providing complex persistence. For example:
a) Stateless Session Bean -> JDBC
b) Stateless Session Bean -> Stored Procedures in DB
c) Stateless Session Bean -> JDO
d) Stateless Session Bean -> Entity Bean in relationship
I think that Sun is still exploring a bunch of different options to make available to developers. I understand the support for JDO has, but reality tells me that Sun won't just get rid of entity EJBs that quickly. I figured it's in all of our interest to try and promote entity EJBs and to make recommendations, even if it isn't the best option.
3) This article is leading up to a couple of other things that I'm writing about now:
a) Sun's replacement for dependent objects (I'm aware of it at this writing, and that could be controversial too).
b) An article outlining how to entity EJBs behave as local objects.
c) An article outlining how to make two entity EJBs behave in a life cycle dependency.
4) I tried to the best of my ability to keep everything vendor neutral and will continue to do so in the future.
Take it easy...
I appreciate your reply.
I look forward to read the "other things that I'm writing about now " :) because 'local' and 'lifecycle' persistent objects are so badly needed for implementing a reasonable object model.
The line I like the best in the article is:
I'm not aware of a single vendor that's implemented dependent objects, including BEA WebLogic and JBoss Server, which are usually the most updated implementations.
Yea, sure. All bow to the great BEA Weblogic.
I believe that Borland's IAS, which is generally ahead of BEA also has dependent objects as does Orion and most likely others.
I guess your not aware of much ...
As I mentioned in my previous post, I ALWAYS attempt to do the most thorough research I can before I write an article. However, you do need to keep in mind that an article is written sometimes months before it is actually published (causing the market to shift).
I did clearly admit that I was unaware of Orion's support for dependent objects and I would have given them appropriate press if I had known.
However, your comment about Borland's CMP engine supporting dependent objects is not correct. Please refer to:
. In this document on Borland AppServer 4.5, you will see that they don't even have minimal EJB 2.0 support. Rather, they have a more robust EJB 1.1 implementation.
Despite my employment by BEA, I always attempt to write a fair article and to avoid politics (after all, it truly isn't in BEA's best interest for me to even have written that particular article). By elaborating on JBoss's and BEA's lack of dependent object support (but still maintaining EJB relationship support) I was trying to imply that maybe the vendor's generally had issues with dependent objects -- not that JBoss and BEA are the all powerful.
This is an excellent discussion and about time too.
We have been developing server side Java applications since the first servlet specs and have big issues with EJB Entity beans. Primarily in the areas of inheritance and flexibility of finder methods.
Having written a persistence mechanism into our framework that is more advanced than EJB entity beans but less so that JDO we decided to go directly for JDO support.
However, some companies that are buying into the J2EE concept have been brainwashed into believeing that unless you are using EJB Entity Beans you are accessing data in a non compliant way.
I think that Sun should unify the JDO and EJB entity strategy to at least have the same query language and a transparent API between both.
I very much like your proposal about leveraging JDO in Entity Beans through transparent API, and unifying their query language. I think it's a very common sense approach, worth pursuing, and lobbying for with the expert group. I believe that it presents a nice compromise between being backward compatible as far as Entity Beans are concerned, and offering an elegant, and uniform mechanism for object persistence across the J2EE platform. No offense here Tyler, but having a half dozen, potentialy overlaping, and conflicting different ways to do persistence, depending on what type of bean it is (Entity, versus Stateless, versus Statefull) is a bad idea. Both from a technical perpective, as well as a marketing perspective. It creates confusion in the market. EJB development is already hard, and confusing enough as it is. So adding yet another layer of complexity, and confusion to the mix can seriously stifle the growth of the EJB/J2EE market. If JDO is not good enough as it is, let's make it so. If it's an overkill, let's simplify it. But let's not duplicate the effort.
You know, this whole thing gives me this strange feeling that the CORBA war of the lost (sorry last) decade is rearing its ugly head again. It's almost like deja vu all over again. Only this time it's called EJB. Back then, a substandard technology called COM/DCOM literally steamrolled its way into the market, and rendered all these CORBA vendors irelevant, and niche players. We all know the whole story, so let's not get into it.
I hate to sound so apocalyptic, but could history be repeating itself once again with .NET?
Don't tell BEA this, but my preference at this time is to have session beans, remove entity beans, and to evolve JDO to "better complement" component architectures. I think that would be a fair solution that would achieve a lot of goals.
You must be aware that at the current time the JDO specification is, let's say, unusable.
The query languages both in EJB2.0 and in JDO are ridiculous, at least for the folks that have an idea of what SQL is capable of.
Is it reasonable to create an expectation for certain people that already got burnt with the mistakes of EJB ?
And, on the other hand I have a very very big problem with a tendency by some OO folks that tend to view the relational database only as an auxiliary mechanism of storage ( they call it the "persistent store" ).
It's something like a necessary evil they have to live with, because others of their brave OO coleagues failed to replace.
The EJB spec , the EJB patterns and the EJB hype certainly have this orientation, but I'm affraid the JDO is taking this idea to new heights.
So my bet is the JDO will fail miserably.
One more comments about Entity Bean. I find EB can neither be used as coarse grained business objects, nor fine grained business objects (such as an order) if business logic needs to be attached to that fine grained business object.
1)Entity Bean instances (which must have a corresponding record in DB) can only be created by either ejbCreate() (which will insert a new record in DB) or ejbFind().
2)Initialisation of EB has to be done by a 'business' method (ie. a separate method) .
3) There is no way to have an in-memory only EB instance and make that object persistent only when you want to.
The example application in Ed Roman's 'mastering' book uses two session beans Quote and QuoteLineItem to hold the business logic which should reside in the Order and OrderLineItem entity beans. Here the Order and OrderLineItem are really DB objects for the business objects Quote and QuoteLineItems. May I suggest to rename of these 4 objects as follows:
Quote --> Order
QuoteLineItem --> OrderLineItem
Order --> OrderDB
OrderLineItem --> OrderLineItemDB
Regarding entity beans: I think the point to them was to create re-usable "business transaction programs", like the old CICS/COBOL programs of yore. Reading a lot of Ian McCallion's posts on EJB-INTEREST over the years has sort have "kept the torch alive" in my head about the value of entities.
However, it has always been my position that EJB and J2EE provide minimal (if any) support for realistic persistent object graph management. EJB 2 CMP helps us in this respect, but still skimps in areas of bi-directional relationships and the case of N-owner dependent objects. (Unless I've misread)
I think JDO is a good model, but it could stand to learn alot from what (IMHO) are the only two battle-tested, tried, and true persistent object graph frameworks out there: WebGain TOPLink and Apple's WebObjects Enterprise Object Framework (EOF). Both have rich support for relational and non-relational mappings, have easy to use query APIs (which are much more useful in certain contexts than a SQL dialect like EJB QL), and have great business attribute and relationship manipulation features. (Especially EOF).
I agree with you about Toplink and WebObjects. Whilst they are tried and tested they are not standards.
Entity EJB/JDO should allow for applications developers to implement persistence without the need to tie into one vendors system. Whatever the faults of the early EJB Entity/JDO specs the overall goal of write once/run everywhere still needs to be worked on.
Hopefully products like Toplink will not see JDO as a threat. They could easily be the leading industry choice for JDO implementation with their lead in Java persistence if they supported the standard.
This outburst is amazing. When we first suggested to our prospects that Entity Beans were indeed only of limited use, the general response was often one of horror. One reply we always remember was a somewhat frantic, "you can't break the model!"
So it's a pleasant surprise to see that so many developers see the problems that we’ve seen all along. That Entity Beans do not lend themselves to a fine-grained persistence model or the implementation of complex object graphs. Unfortunately, while the EJB 2.0 spec is trying to change this, it’s building on top of an already flawed model.
However, I think what a lot of people have not fully addressed, are the political complexities. Perhaps a more fundamental question needs to be raised in order to explore this. Q. Why are Entity Beans there? A. To provide the necessary persistence component in the EJB architecture. However, the fundamental storage technology that is considered is not object oriented! So now there is a problem, how do you fit a square peg into a round hole?
Politically it was probably very important to get “buy in” from certain market forces and the database vendors are a large part of where EJB was trying to fit. So to get the DB vendors into the game and gain the necessary momentum for EJB’s to succeed, Entity Beans were created to interface to an essentially non-object oriented persistence mechanism utilizing JDBC. Transparent object persistence was required but under the covers this is really difficult to achieve.
So that’s my throw in to this topic, it’s all politics. From our perspective our customers don’t have to use Entity Beans as we provide transparent object persistence integrated as an alternative EJB container. It works and it’s being used in some significant projects.
I don't agree this is an outburst, at least me, although I'm critical of various things in the whole J2EE, I don't have any reasons to be angry because I'm staying away from the technolgy !!
You only get into problems, like you said when you meet Sun's marketing brainwashing efforts that may work against your profesional judgement.
Lucky me, I work in an wondeful environment, but it's worth lobying for everybody else whose professional judgement and integrity may be questioned by the marketing effort.
Also I'm happy to see that market conditions will further work against the waste of CPU usage, memory usage and development time, and further support the developers who provide solutions, not technological warfare :)
On the other hand I think you got it a little bit wrong.
First and foremost Enity Beans are bad because they are unnecesarily distributed objects and overly managed by the frameworks.
Second, I see very little supporting arguments to put the blame on database vendors.
I think they were pretty much out of the spec effort, and first versions of Oracle App Server didn't have any support for entity beans, and I don't know to this day oif they have.
On the other hand there's a little bit of history repeating itself.
In the early 90's there was a lot of research effort and commercial development done by OO people to replace the Relational Database with superior OO technology.
The conclusions were pretty clear, but apparently many people didn't learn the lessons, so today we are talking again about "storage technology", "transparent persistence" and other OO keywords that failed both in theory and in practice.
I'm not saying that these concepts are somehow doomed to fail, but at least until new research and theoretical effort is put into place, there will be no miraculous "silver bullet" to OO people having to learn SQL and relational databases.
We are far from that goal and I wouldn't be surprised if someone will theoretically prove the futility of these efforts. Watch the JDO effort and see what will happen.
And personally, I expect nothing less than a new OO language (even if it will be Java++) that will provide foundations for "transparent persistence".
Oracle does have Entity bean support now (8.1.7), and basic CMP support (primitive types. Anything more complicated and they serialize your dependents into a RAW field. Not the best..)
Dan - Regarding TOPLink and WO -- they're not standards, but who the #@*&@! needs standards that don't work? :)
TOPLink is technically fairly standard - it allows a standard CMP implementation for WebLogic & WebSphere, with proprietary extentions. There is no persistence-manager interface spec for even EJB 2.0, so it can't get any more standard :D
EOF will be interoperable with EJB when WebObjects 5.0 comes out. I don't know if this will be CMP or BMP. (At least, according to WWDC 2000 information which is a bit old)
My point is that we should look at what *works* before we create a standard. Clearly, TOPLink and EOF work. JDO's public draft is shaky, IMHO, which is why I've been somewhat hesitant to throw my hat in that ring. But it's also very old, I understand, and we haven't seen much progress on that front in almost 1 year.
But the fact of the matter really is:
- Entity Beans and dependents are only realisitic (today) with BMP.
- One can use dependents with CMP (today) using TOPLink.
- One can use dependents with CMP (tomorrow) with mythical "persistence managers" that still require vendors to get a clue and implement them.
So we won't have new competing products in this space until 2002. For now, the only worthwhile EJB O/R mappers I know of are CocoBase, Sequent, EOF and TOPLink. WL's built-in implementation is a toy. Has anyone tried Java Blend?
Object database implementations like GemStone (Brokat), Versant, JavLin, etc. all seem a little rough around the edges (Gemstone isn't even true CMP yet.)
The plain fact of the matter is that Entity beans are terribly under-specified for what they're trying to do: create a re-usable business transaction component that leverages off of a persistent object graph. That's a HARD problem, even for a product -- let alone a specification.
The irony is that most people feel entity beans are over-specified in general.. maybe the world isn't ready for re-usable persitant components, and we should go back to statless, COM+-style components like Session beans (which, ironically, the EJB spec says "shouldn't be used that much").
For the time being, how about
Stateless Session Bean for business process;
Stateful Session Bean (with in-line JDBC SQL) for coarse grained persistent object;
'ordinary' Java Bean for fine grained persistent object;
Happy Bean when you finish the day's work.
Just one extra thing,
Costin, you mention that 'transparent persistence' is a futile effort.
Do you feel that a 'translucent persistence' is worthwhile?
This is what I mean by "translucent persistence": a framework that provides layers of abstraction, which you can delve into depending on how complicated your situation is.
EJB 1.1 CMP was transparent, and was doomed to fail. It took nothing into account about the underlying datastore and required proprietary extentions to do so.
A framework like TOPLink or EOF provides tremendous power assuming you know your RDBMS technology *and* you know your objects. Perhaps this combination of knowledge is rare, and explains why those technologies never became mainstream. They are, however, extremely valuable productivity boosters and definitely aren't "futile", in my experience.
Transparency (usually) doesn't work. Abstraction does. One can't sweep the fundamental problems of [insert difficult topic here] under the rug by using a "transparent toolkit". (Jim Waldo wrote a paper on this subject once, "A Note on Distributed Computing", available on the Sunlabs site.)
I didn't say exactly it was a futile effort, but I stated my doubts, and until a new theoretical breakthrough is done the current efforts (and JDO is an attempt at totally transparent persistence) are doomed to fail miserably.
As a matter this the thing that lacks from Java: RESEARCH.
Unlike many other technologies in computers whicvh started with theoretical papers, cycles of implementations and standardisation only came later on, all the current Java technologies started with SPECIFICATION.
No matter how dumb they may be (and I'm not saying they're dumb, but nobody bothers to give some proof of soundness either) all the vendors jump into the bandwagon.
About the "translucent persistence" it migh be worth trying, certainly if you are happy with them they're a very valuable tool to you, but I can't afford to attempt an opinion on the subject.
I didn't use any of the tool you mention, and from what I understand they're quite expensive, so a project manager would have to make a leap of faith to use them.
But let me say that maybe a "transparent persistence" is at least theoretically a more desirable goals, although practically unreachable for now.
However, having done my little persistence framework, and done extensive research in database technologies I would try to enumerate what is needed to reach that goal (IMHO):
1) A new OO language. Java is not reflective enough and not flexible enough to allow you to construct a query language.
Maybe a Java++ would sufice. The language should support persistence and queries within its core features.
Lucky for us that C# is a perfect clone so it copied all Java limitations :)
2) A better database API. The current API structure (JDBC,ODBC, CLI whatever else) is inherited from the client/server technologies, and database engines are not ready to support a multilevel transactional cache.
3) A better database model (and I don't mean OODB) that will support structural inheritance and maybe more powerful query capabilities. This the only thing that we have available today both in theoretical research and implementations. Too bad it didn't make mainstream.
I can prove that in absence of any of these any attempt to transparently persist the object model is inherently handicapped (hugely handicapped).
You can see what big of a gap we might have in front of us.
The bigger gap we have is between the computer science principles and the way of doing things we have on one side and on the other side are the marketing efforts and managerial efforts to drive big revenues in short time without too much consideration.
So, for now, I'm happy to play with what I have.
Your comments clarify my understanding of your position, thanks.
Regarding research, I agree wholeheartedly.
Regarding "translucent persistence":
They're not necessarily expensive. And Java can be sufficiently flexible to do a persistence framework. I agree we need better languages, but it's not a "theoretical possibility", as you state, it is practical, and it is used by many people. '
As you say, you haven't used these frameworks, so it's difficult to form an opinion on them. I would extend that to say one can't say what's "theoretical" until one tries it. I'm telling you that many people have tried it, it works, but the mainstream hasn't generally been up to the challenge yet. :)
Concrete example: WebObjects is $699 for a production license (it used to be $25,000). It's not EJB, but it's Java and Objective-C. It's not the hottest thing in the press, but it's widely used within a small vibrant community. And iTake a look at the libraries (freely available) at http://developer.apple.com/techpubs/webobjects/webobjects.html
-- particularily the EOControl framework (which has a business object framework and query framework).
Obviously Objective-C had a lot of influence on their design, since it's a much more flexible language than Java. But one can bridge those ideas over to Java. This product is going 100% Java in the next version.
TOPLink used to be Smalltalk. It's a Few $K per developer seat, but no runtime licenses needed. And today it works beautifully in Java. This is more expensive, but not horribly so (considering the level of projects that would use this kind of tool, it is a minisule fraction of consulting and salary expenses.)
Ok, "outburst" was exaggerating. I probably used that description because I had not really seen such strong feelings wrt EJB's and Entity Beans before and was a little surprised.
I'm probably safe in saying EJB's are far from perfect but there is very little if anything in the software industry that is.
I also tried to be fair and even with what I said, I didn't blame the database vendors, I merely said that it was important for the success of EJB's, to include them in the picture. Many if not most of the organisations looking at this technology will have vast amounts of Stored data (typically in an RDBMS) that they want to access.
However, I would not dismiss OODB companies either. There are a growing number of organisations (significant organisations) using these technologies strategically. They are not a silver bullet but neither is EJB, .NET, CORBA, Client Server, Java Spaces or JDO. What must be realised is that market share is a strong motivator for most people and changing an incumbent technology wholesale, is almost impossible.
How about this as an additional suggestion.
Session beans providing the business services over a standard Java domain model persisted in a OODB.
The session bean and appserver provide the transaction management and the OODB just makes the standard Java object persistent.
Gives you fine-grained control over potentially complex object models with Transparent, transulcent, see-through, clear, opaque persistence call it what you like :-)
First I'd like to comment about the article, which is where this forum started. It then rolled off to quite different places, which I will also relate.
The article begins with one page of general introduction. The first section in the second page is also a setup for the comments that follow.
The first actual comment appears in the second section in the beginning of the second page. This is (I think) the main point of this article. To put it shortly, the problem described is that EJB2.0 suports one aspect of life-cycle object, i.e, deletion of dependent objects, but not the other, i.e, creation of dependent objects. I can't see what exactly the author expects. A dependent object has to be initialized upon creation. It's fields should be assigned. How is a container supposed to assign them without the programmer having coded initialization code himself?
All the EJB2.0 spec sais, is that in ejbPostCreate you should make the neccesary calls to initialize your dependents. I would expect nothing else of a specification. I think this is very intuitive. Just like you initialize mebers in your constructor, but have them collected automatically, you initialize dependents in ejbPostCreate and have them deleted automatically.
The third section regards difficuilties in training developpers to use EJB2.0. I really don't know the subject as well as the author and I don't think I can comment. I can say that I doubt the expert group directly consulted training experts, and if so it is a very bad mistake.
As for the final point, I don't really see how this is critisicm of the spec. There are ways to create "local" objects that are not per-spec, and now the spec standartizes it. It also adds some added value to dependent object, but that's not the point. The point is you can achieve the same effect of the vendor specific optimization using standard means.
Now, when that's out of the way, let me say what I think is the *real* problem with EJB :)
First of all, I disagree with most of the former posts. Yes, I do think politics played a major role, and yes, I don't think EJB entity beans are a perfect transparent-persistence solution. But that's true for all major technologies out there. I don't know a better solution (EJB2.0 I mean, not EJB1.1 which was very weak).
I think EJB's main problem is that it's entity beans try to cover a much wider range of options than practically used. If you were to review the EJB design documents out there (including Sun's own Blueprints and J2EE pattern catalog) you would see that it never advises accessing entity beans directly from outside the App. server. Allmost allways a session bean facade is used to wrap entites. In the growing world of web services, it becomes clear that your application server should provide it's clients with services, not directly with data. That is maybe the core of the N-tier architecture class. Data is processed within the server, and clients don't access it directly. Reasons why this is recommended are well known and documented, and I will not re-iterate them.
Even when clients like standalone applications directly use data from the server, they allmost allways use a "Details object".
In fact, most educational EJB design material doesn't even use Entity beans from the Servlet and JSP engines. They allways access detail objects, and they allmost allways update data using facades or "Controllers" implemented as session beans.
So, OK. So the spec allows some features that are not commonly used. What's the problem?
The problem is, the way I see it, that the spec is so general about defining the context in which EJBs are invoked (and run), that we end up with a very loose specification. It is allmost impossible for a "standard" developper to write anything beyond standard beans and not end up breaking the spec. It all could have been far easier (for both the developper and the app server) if the session beans were distributed, and entites were not. And i'm not talking about completely moving to JDO. Entity beans, especially in EJB2.0, have a lot to offer. But they could be far more efficient (and easy to write) if they were not only managed, but also invoked, in the context of the same app server.
Comment are welcome :) take it easy...
When we try to use toplink 3.5 workbench and connect to a db2 database and get the tables, the fields are not imported into workbench and while getting the table there is an error displayed that primary key not defined,whereas there is a primary key defined.
overall the pwic is the best solution :)