In the latest issues of Object Watch newsletter, Roger Sessions asserts that Sun probably might want to deprecate EJB due to "The technical problems with EJB are well known, and include poor performance, machine affinity, and potential database corruption. But Java DataObjects (JDO) seems to solve none of these problems, and adds to them what I think is the worst implementation of a Distrust Divide in the industry."
In a TheServerSide exclusive, Craig Russell (Java Data Objects Specification Lead) responds to Roger's comments on JDO, stating "It is unfortunate that Roger Sessions has so completely misunderstood the architecture of J2EE and Java Data Objects, and worse, makes no attempt to understand the technology before spouting off."
Read Craig Russell Responds to Roger Sessions' Critique of JDO
Feel free to discuss Roger's critque and Craig's response here.
I kind of like the Starbucks analogy and it neatly illustrates how clients don't (shouldn't) directly interact with business services. Z is a Session manager responsible for transaction scope and it is Z who invokes (and composes)the business services on behalf of Roger. Z starts and commits the transaction and ends the session when Roger leaves the counter.
I consider session and transaction management as a distinct and separate tier between client/presentation and business logic. In a previous thread we debated whether session and transaction management should occur in a SFSB, a servelet, or a fat client. Valid arguements can be made for all three.
Pretty funny that Roger should be so down on EJB/J2EE, etc., considering that he might be regarded as the founding father of Entity Beans. If you read his 1996 book Object Persistence, he describes his extensive involvement as an IBM representative in the OMG's Persistent Object Service specification. His proposal to the OMG featured a remotable PersistentObject interface with "store" and "restore" operations called invisibly around transactional invocations of business methods. Sound familiar? (Sun people readily acknowledge IBM heritage in the EJB specification). Unfortunately, both are bad ideas, IMHO: that business objects should be remotable and responsible for their own persistence. Thatis why I've always preferred POJOs and OODBMSes, and why I'm grateful for the JDO alternative.
And we're supposed to believe that MTS is better? I became fairly disgusted when I read an SD Magazine article by Roger a few years ago on MTS, in which it dawned on me than in MTS, every method on a business object class has to take a parameter identifying the object on which the method is to operate. Gee, and I thought intrinsic identity was one of the fundamental tenets of object-oriented programming languages. MTS seems to unencapsulate state from behavior and reduce OOPLs to a fancy way of organizing a subroutine library.
It seems that when Roger couldn't get his way with IBM and the OMG, he bailed out and became the mouthpiece of Microsoft. I find his antics rather childish, personally.
I have to assume that either Roger Sessions is simply on a pro-Microsoft/anti-Sun crusade or that he is actually not reading about the stuff he then writes about. He makes many false implications about J2EE and JDO of course, but the man is a successful professional who's articles are read by many people.
I can only conclude therefore that he probably does know he's talking (broadly speaking) rubbish and that he is in fact simply spreading the Microsoft FUD for other, less professional reasons. Am I giving too much credit? :-D
The only thing we can do is what has been done - publicly give the information as it should be given and we must definitely *not* resort to similar tactics directed back, no matter how tempting that might be!!
"He makes many false implications about J2EE and JDO of course"...
care to elaborate?
I agreed with you. Roger is doing a lot business with .NET
Roger Sessions is the CEO of ObjectWatch, Inc, a company that specializes in architectural level training in the .NET platform and other eCommerce architectures......
Peter Shillan wrote
>> I can only conclude therefore that he probably does know he's talking (broadly speaking) rubbish and that he is in fact simply spreading the Microsoft FUD for other, less professional reasons. Am I giving too much credit? :-D
>> The only thing we can do is what has been done - publicly give the information as it should be given and we must definitely *not* resort to similar tactics directed back, no matter how tempting that might be!!
Interesting comparison: the "J2EE v .NET for Web Services" article posted by Ed Roman on this very site. It suffers from the same inaccuracies (documented in thread 7056
) and bias you ascribe to Roger Sessions, except this paper is of course biased toward J2EE.
You can't believe everything you read.
Even this! :)
Sessions' article is a joke, at best. Just to pick one statement:
>could build business logic components, for example, that >hide the details of Java DataObjects,
why would one want to hide something that has never been exposed? JDOs are not designed to be remotely accessible, neither is the PersistenceManager.
Roger could as well blame the JDBC API, as it fulfills basically the same purpose as JDO, that is provide an interface to persistence. JDO does this the Java/Object way, JDBC goes the Java/SQL way - thats all. Of course, mentioning JDBC would not be wise for him, as it is remarkably similar to some other well-known API from the realm which Roger defends so poorly.
I could easily and frm conviction write articles criticizing CMP EJBs to the marrow, but that article is plain propaganda IMO.
spot on, christian.
i have no idea what sessions was going on about, and obviously, with the arguments he proposes, neither does he. the last time i looked at mts or com+, it was basically a non-java ejb spec without entity beans. they both use remote objects for which many aspects of behavious are declaratively set. the different transaction types (SUPPORTS/REQUIRED etc) are either the same or remarkably similar.
i personally don't use entity beans myself, but comparing them with jdo does not make any sense at all. in fact, using jdo's with session beans is quite an elegant solution.
I am surprised that Craig Russell found Roger's article worthy of a reply. It's probably the poorest article I have read in a long time.
And what's with the obsessive coffee drinking.
is this some kind of product placement ?
A Microsoft/Starbucks conspiracy ?
Isn't Starbucks the Microsoft of Coffee ?
You know, I might find Starbucks coffee a little strong, but the quality is very good. Comparing Starbucks to Microsoft is pretty accurate. I guess that the equivalent analogy for Sun/Java would be to compare it to the generic store brand coffee you can get at any grocery store. Yeah, that seems to work. A little weak, and not much to talk about.
BTW, based on Roger's ill-suited comments, why did Sun drop the implementation of the Java Data Objects from the Sun ONE Studio? Just wondering.
I think the whole argument about the Distrust Divide is irrelevant here.
The distrust divide is really a security issue (if you read carefully the concerns that Mr. Sessions is trying to address). It is up to each software project to decide on the right architecture, and how to include an appropriate level of security in it. It shouldn't be built into every component of every system.
These is really an question of architecture - specifically security and persistence - not of Entity Beans vs. JDO, which are both good, useful, things.
P.S. I would also observe that the whole description of Sessions' time at Starbucks is self-indulgent and doesn't
really belong in an article of this nature.
The question, as I see it, is would you expose an object to the client that has persistence methods? That has anything other than get/set methods? That contains private instance variables?
At the very least, I'm not going to tolerate a persistence "hit" every time the client does some setter method. (J2EE likes keeping the db in sync with the object) Nor the network "hit" to call the remote object's setter method. (How many setter and getter calls can YOU make the saturate the network? No prizes if you suceed...)
Bad, bad, bad, bad, ... bad.
It doesn't matter if the object I'm passing to the customer has J2EE-based persistence, JDO, or name-your-tool.
It was silly not to pass a simple data container to the customer to begin with (E.g., the Latte as opposed to the Latte along with a reference to the cash register.) The failure of not isolating persistence methods is not an indictment of any persistence technology.
You can be considered dangerous armed with nothing but your wits -- or lack of same.
You nicely summed the problem with MTS/J2EE/JDO. A few years ago OO came into its own; and it was good. Now, we have to break up our nice objects. We end up with a bunch of stinkin' procedural-method calls.
We can't use real objects because of the network overhead, latency problems, etc. So we resort to the hodgepodge of junk we have now.
I'm suddenly feeling all gooey and sentimental about CORBA....
I remember a story involving NeXTStep's distributed objects: every getXX() method, setXX() method ended up being a network call. You ended up with TCP packets of minimal length (header, plus, say an Integer you're setting). Lots of overhead.
They had the object server in Chicago, and a lot of users in Tokyo. Internal network got saturated...
Bottom line: you have a public interface, an abstract class, and a concrete class. To think these should coalasce (sp) into a single object is a mistake.
Going back to the story, the NeXTStep stuff was replacing old C code that passed a struct via XDR, but only when the infrastructure server/client library thought it needed. Far lighter, more robust... Even with the fact that the code was 85% kruft and becoming unreadable is placed into consideration, it was still better...
Good grief Roger!
And to think there are so many good coffee houses in Toronto too. It shouldn't be that hard to find one. Then you could communicate with some truly knowledgeable people and quit pestering the help staff at Starbucks who are already overworked. And stop wasting the world's time with a bunch of half-baked ideas.
In the mean time if you want to understand EJB, Roger, why don't you go talk with IBM, BEA, and IONA? Maybe they can explain the whole thing to you better than some guy who make lattes.
Floyd, maybe you should point him to some good cafes up there, eh?
I've been following Sessions' ObjectWatch newsletter pretty much since the beginning, back around '97, and I have always considered his articles to be thought provoking and intelligent, albeit biased toward Microsoft and its Windows DNA/COM/COM+/.NET.
This article is a first for Sessions. I can't believe that he published such a rant. He seems to totally miss the idea that hiding fine-grained business objects behind stateless session beans is a **good** idea. You necessarily make the session bean interfaces coarse-grained, and atomic. In the enterprise environment, state limits scalability, which is why you want to avoid stateful session beans.
I have never personally considered entity beans a great design, as I could never see a reason to remotely expose fine-grained, persistent objects -- your performance would suffer tremendously. Sessions points this out in ObjectWatch newsletters 20 through 20d. With the introduction of local interfaces, entity beans have taken a step closer to what JDO pretty much mandates: local manipulation of fine-grained business objects.
I have long wanted to see the integration of ODMG transactions and J2EE transactions; with JDO, I get not only that, but also a persistence framework that works in embedded, two-tier, and three-tier environments.
I have to admit that when I first learned of the notion of enhancement (using Poet's Object Server Suite back in version 5), I was a little uncomfortable. However, after seeing the huge amount of development time it saved me, I was convinced. The largest expense in any development effort is that of the humans involved, and enhancement lets me avoid writing persistence mapping code, which, if written by a human is buggy and is produced much more slowly than an enhancer. Additionally, I am free to think about my problem domain; no need to worry about how to persist this foo or that bar, especially when there are trees in my model, which is almost always in a model of any complexity.
I don't know what kind of architecture Sessions advocates now. I always considered myself to be in general agreement with some of the higher level points that he makes, but now, I don't even know where he stands.
I still think that encapsulating JDO-persisted fine-grained business objects behind stateless session beans or message-driven beans is the best way to go, passing either (a) value objects, (b) disconnected jdbc result sets, (c) xml schema-generated serializable objects, or (d) raw xml itself between client and session bean.
Let's face it; the pendulum swingeth. It used to be all about procedures and data structures, then came object orientation, where procedures and data were brought into much closer proximity, and, with the arrival of highly scaled, distributed computing, the pendulum necessarily is swinging back. Coarse-grained session beans represent the procedural aspect required by distributed design; fine-grained business objects represent the more purist object oriented, stateful, long-lived entities.
I could go on, but I've got stuff to do.
Sadly, its the same sort of organic residue that we come to expect from Mr Sessions. Though this is the most patently completely-missed-the-point article of his I have read.
Here is an amusing quote from a loving reader (pulled from the strangely non-interactive "feedback" section of his ObjectWatch site):
"I am a member of Ed Roman's www.theserverside.com. The other day, when I visited that site, I saw a link to your article that compares .NET and J2EE. I followed that link and the rest is history. I mean, I have spent the last three, yes three days, reading all your articles. I re-read some of them, actually !!! I like your style of explaining things. It is very earthy. I mean, very practical. I consider you as a guru of the middle tier. As for me, I am a middle-tier enthusiast. I must say that I learnt a lot about 'Life in the Middle Tier' from your articles. Great stuff."
Guru?? I hope not.
Oh well, it keeps people entertained at least... ;)
I wish I could see the response from Mr. Sessions
Well, as they said "every dragon has a weak spot". According to Craig Russel presentation JDO will
- scales from embeded to enterprise
- provide transparent persistence for RDBMS, ODBMS, files and hierirchical databases
- integrates with ejb and j2ee technologies
- no need for sql/oql
The only thing which it want do is to make cup of coffe.
Let's compare jdo spec with Roger Session's complains:
1.PersistenceManager interface. In order to do anything program has to obtain this interface. From it you can get transaction object and query. The PersistenceMananager has all funky methods from getID through evictAll() which flash cash (very dangerous) to deletePersistentAll without transaction. All in one. Accessed for every need, without role security model.
2.Integration with transaction monitor.
From JDO spec:
"16.1.3 Stateless Session Bean with Bean Managed Transactions
Bean managed transactions offer additional flexibility to the session bean developer, with
additional complexity. Transaction boundaries are established by the bean developer, but
the state (including the PersistenceManager) cannot be retained across business method
boundaries. Therefore, the PersistenceManager must be acquired and closed by
each business method."
1. Because JDO spec doesn't have Criteria and Query By example, the brave JDO developers should learn one more ad-hock query language after SQL, OQL, EQL.
2.Distributed cash, locks, LRU cash, time/count limited cash are outside of spec, as synchronizations with data in rdbms. So it will be the same problem as with entity beans or cashes in existed O/R mappers. If you want to update object, you have read it first which is slow. If you cash it you have problem with synchronization data in storage.
4.JDO specs lucks object proxy so if you need get user id by password and login you have to read the whole user object (can be very big).
Interesting - it presents mostly all existing (and near-future) technologies pretty well (in my opinion).
I expected more about the message-driven, non-RPC programming model characteristic to SOAP (and Web Services in general). And maybe more details about XML-based messaging architectures like Biztalk Framework or ebXML. But, anyway, the DCOM/.NET/CORBA/EJB summaries are worth reading.
Okay, I've read before the articles and I think that they BOTH make good points. I think that Roger's ideas of on EJB deprecation and JDO's faults are valid. I also think that Craigs response is also valid. They also both have overlooked very important details. And here they are:
Roger has failed to realize exactly what Craig stated. J2EE is design for encapsulation. You the programmer have access to all the logic, the end user does not. So, when I go to MyBookstore.com and add a book to my cart, of course I'm not going to be fiddling around with JDO objects or even EJB objects. I'll probably have a nice servlet interface, which has a nice EJB interface, which has a nice JDO interface. Enough said.
Craig has failed to realize the clients are not end users. I'm a green programmer at Mega Corp. inc. and I'm assigned to work on a tool that views peoples shopping carts real-time. Okay, I start looking around the code and notice that there are all these JDO objects that I can use to get access to the database. GREAT! So, I start playing around with them. The command line utility is now the client and JDO does have very little support for making sure that certain clients can only do certain things (as for as I've seen). EJB does. I can tell the deployment descriptor to NOT allow Mr. Green Programmer access to write methods on Entity beans.
I tend to agree with both of these guys on certain points. Though, I to tend to favor OMG over JDO and I agree that Entity EJBs bite the big one :)
>> I tend to agree with both of these guys on certain
>> points. Though, I to tend to favor OMG over JDO and I
>> agree that Entity EJBs bite the big one :)
What, specifically, do you think is wrong with entity beans?
Somebody before mentioned that he followed the ObjectWatch newsletter since its beginnings. Well, I just started with this article and before actually reading it I was even considering going to the architecture workshop advertised there. After reading the article, I don't think I will make the effort.
It really looks like it was written for the sake of starting a flame rather than discussing any technical / architectural topics. I have seen much better EJB / JDO comparisons on theserverside.com written by far less famous authors. It seems like Roger was out of discussion topics...
I am a Java J2EE developer and I did experience first hand some of its shortcomings, but I do believe that the benefits by far outweigh those shortcomings.
I have read this article as well as "Java 2 Enterprise Edition (J2EE) versus the .NET Platform Two Visions for eBusiness" and I realized that Roger Sessions is extremely biased and his articles sound more like Microsoft marketing papers than professional articles.
It s because your mind is biased by your faith in Javatechnologies .
Free yourself !
Both technologies are godd if they provide you money to survive .
A both architect (COM/DCOM , J2EE, and soon a .NET Arch.)
While I found Sessions' article on JDO hardly worth the time I spent reading it, I would say that I, too, am hoping that the dev world gets to a point where a client simply says "I want .NET" or "I want J2EE", and all the rest is just details. With C# on .NET or Java on J2EE, all of the patterns are still the same. One should pick the technology that presents the most value for the task at hand, and value is determined by a multitude of things:
* training costs
* product costs
* OS flexibility
* development time
* legacy integration
The list can go on and on, and each factor needs to be weighed.
Sure both technologies are good to a certain extent but it depends on what you want and paying the bills it's certainly
important but you can also do what you like along the way.
It really scares me that Roger Sessions can get this SO wrong. He is supposed to be an expert...he gives presentations and people listen to his views. This comes with responsibility to the developer community and I think he should be more than a little ashamed.
In summary, I hope that the "experts" among us spend a little more time researching and thinking, and a little less time writing off the cuff commentary.
Full disclosure, I'm a JDO fellow traveler and work for an ODBMS company.
I've read Roger Sessions article on objectwatch.com and all of the comments here with interest.
I'm surprised that none of you has made the obvious point about Roger's Starbucks analogy.
Roger ran afoul of Z, you know her, "big brown eyes", "likes him" but has " a trust boundary" to keep him at a distance, he was rummaging behind her counter in search of a drink of water. Yea right. After being disciplined, he concludes that it is OK that Starbucks in the person of Z (that charming and lovable corporate paragon of customer service) forces him to act as if water costs money even though it is free. All this because they didn't, can't or won't change the location of the water relative to the counter or visa versa. Whatever happened to "the customer is always right"? How about a pitcher, what about a drinking fountain or a hose? Let your imagination run wild Roger, but stop eyeballing the help, Janet might notice or even worse Bill ;-)
Obviously, Starbucks has a vested interest in keeping Roger out of the cash drawer, not to mention away from Z, but what does that have to do with water? Doesn't Starbucks want all of its customers to be satisfied? Even Roger, within reason. Are the customers servicing Starbucks or is Starbucks servicing the customers? Does it matter? Why can't both get what they want? i.e. Roger away from Z and the bucks, but fully hydrated.
Roger seems not to have noticed in his analogy that he, the Java drinker, is analogous to a Java developer in the technical domain he is criticizing (Sun, EJB/J2EE entity beans, JDO, transparent persistence, ODBMS and subconsciously I think OO itself).
Hard to credit but he does seem to think all of this stuff is interrelated in some big Sun conspiracy. If you don't believe me, read that book of his somebody mentioned from 1996 "Object Persistence" which would be more truthfully named if he added the subtitle "None of Both". Roger can really carry a grudge. We know only a monopoly could manage a conspiracy that big, gee? Was it Sun convicted of using monopoly power recently, I forget?
JDO is analogous to a very adaptable counter. Since we are in analogy land as opposed to tech land, we will dub this counter a "super counter" (SC). The SC increases the throughput, more customers served with less effort by the customer, it also gives each lucky fellow a completely consistent and identical tasting cup of coffee even if half are receiving the finest Kona and the rest get an infusion of gym sox. Coffee delivery services can depend on the consistent standard SC interface across all coffee suppliers. The SC allows Starbucks to hide all of the complex and ever changing issues Roger is worried about that happen behind the counter. Starbucks can do a good job of managing this complexity or not, it's up to them but don't blame the SC if Starbucks screws the back room up. Best of all the SC makes it so Roger doesn't need to see behind the counter even while getting what he wants with less work. Unfortunately he doesn't see Z's new tattoo.
Z might be there she might not be, maybe she is wearing a bikini, maybe there are layers or a whole hierarchy of old style pre SC counters back there. Roger only has to queue up once. Roger's time is valuable, he doesn't know or care which counter is supplying his various order items. Starbucks accounting for the money received and the inventory used correctly and consistently need not concern him. Starbucks can put whatever it wants (good, bad or ugly) back there but Roger keeps getting coffee. Maybe Z has run off to Columbia with Juan Valdez after covering him with foamed skim milk and for a while all that is back there is a shelf of prefilled cups with a microwave, hope she makes it back before they run out.
THINK OF THE POSSABILITIES
Wow got carried away. Sorry
One thing I'll say for Roger, his article is entertaining and so probably will have a bigger influence on the universe then what we have said here. Misguided, manipulative, clueless who knows. But you have to hand it to him he came out with the needle after lots of time under the haystack looking for Z. We agree with him that, "Good counters make good neighbors". Even though we suspect he won't really be happy until across that counter Z gives him a coffee tree, a hose and a sun lamp, how about clay to make a cup and a kiln.
No hard feelings I hope Roger, we all have to eat.
These opinions are decidedly my own and not my employers and similarities to "Expert opinions" are purely coincidental.
I am and have been a long-time subscriber to ObjectWatch, and humbly suggest that a simpler response to (most of) Session's ideas is to realize that he is a Microsoft "camp follower", and has managed to work his head so far up Bill Gate's behind that he long-ago lost his ability to conduct an impartial and honest evaluation of any non-Microsoft technology, period.
I really wonder whether even **he** takes himself seriously anymore.
I read the 'quotation of the month' at the top of this article and think I must be missing something. Perhaps somebody can help?
Roger, the CEO of ObjectWatch (and presumably the sole author of the newsletter?) is "once again" the winner of the Quotation of the Month Contest. The prize? A Roger Sessions book or BBQ apron. Signed by Roger, naturally.
He must have quite a collection!