EJB 2 Final Draft 2 released, dependent objects scrapped

Discussions

News: EJB 2 Final Draft 2 released, dependent objects scrapped

  1. Briefly, the major change from the PFD1 is that they have introduced local interfaces for BOTH entity and session beans. Local interfaces allow you to pass arguments and return objects by references using the Java language semantic, while the remote interfaces use pass by value, and follow the RMI semantic.

    This is a good enhancement from the performance's point of you, especially for the EJB relationships, which now are restricted to local interfaces only (Spec 10.3.2), therefore dependent objects have been dropped.

    The Persistence Manager role has been dropped too.
    Final note: fortunately, the ejbCreate() return of CMP has been reverted back to return the PK (As EJB 1.1)
    instead of void.

    http://www.java.sun.com/products/ejb/docs.html.

    Threaded Messages (93)

  2. clustering performance?[ Go to top ]

    One thing about dependent objects though - I'm pretty sure an entity bean and its dependent objects would all be instantiated on the same vm within a cluster. Can the same be guaranteed with finely grained entity beans (ie all the beans instantiated in a relationship)? Performance gains would be lost if the beans were on different vms in the cluster.

    thanks!
    Markus
  3. clustering performance?[ Go to top ]

    I'll answer my own question :) - from the spec... "the local client view required the collocation in the same JVM of both the local client and the entity bean that provides the local client view".
  4. Okay, can I guess the spec authors rationale behind the changes here in pfd2:

    "Let's get rid of dependent objects, but keep the functionality by..."
    1) offering local interfaces to beans to make them more "lighter-weight" like dependent objects would have been
    2) including a cascading delete option, just as a dependent object would have been deleted if its parent had removed

    I'm not saying this was a good or bad move -- I don't feel comfortable evaluating this decision at this point. However, I must say I was surprised at the choice of #1 above, for that is a very EXTENSIVE change to many parts of the specification. Now an EJB can have 4 interfaces instead of 2!

    I'd like to hear opinions on this question especially... How much of a benefit is there in the local interface concept? If products like WebLogic optimized intra-JVM invocations to pass by reference anyway, just how much of a real improvement is this?

    thanks for any ideas that might help me see this clearly...
    -Mark
  5. First, this post is not an opinion of the specification. I'm just making guesses.

    I think the reasoning behind offering 4 different interfaces is to allow EJB compilers stronger type checking when determing how the container should handle EJBs in a relationship. For example, the spec specifically states that entity EJBs using CMP relationship mapping can only reference the other bean in the relationship through the local interface.

    I think that having a local interface allows Vendors to perform stronger type checking and analysis at container generation time for Entity EJBs in a relationship.

    Also, if you read into the specification, there was one point where it seems like they were advocating that all entity EJBs should almost NEVER have a remote interface! They kind of implied that one option of development would be to define all of your entity EJBs as coarser grained objects in CMP relationships. The relationships and entity EJBs are accessibel through local interfaces. Then, write a session EJB with a remote interface that does a more business abstraction of the entities.

    They also recommended having a heavyweight consolidator entity EJB that has a remote interface for access that uses a variety of other entity EJBs through local interfaces.

    Tyler
  6. The reason to add local interfaces instead of letting the Container do the optimization was to not break the RMI semantic.
    I agreed partially
    If I have an RMI interface, I make few assumptions like args passed by value, remote exceptions, RMI restrictions for the remote interface.
    If the remote was optimized by the Container, the RMI would get broken "conceptually" , and the developer would have to change/consider when the interface is optimized(local) or not.
    Local interfaces are not location transparent either.
    I am not talking how/what the Container does to optimize intra JVM calls, but the concepts and the semantic you have to follow when you develop RMI objects which ARE remote.
    There has been a long debate about that in the EJB expert group .
    Of course, I know that this brings more complexity in the EJB model among the developers who do find them already complex





  7. Gianni Scenini wrote:

    The reason to add local interfaces instead of letting the Container do the optimization was to not break the RMI semantic.
    I agreed partially
    If I have an RMI interface, I make few assumptions like args passed by value, remote exceptions, RMI restrictions for the remote interface.
    If the remote was optimized by the Container, the RMI would get broken "conceptually" , and the developer would have to change/consider when the interface is optimized(local) or not.

    --------------

    This is something I've never understood at all. Who says that remote calls can't be optimized out, without keeping remote semantics?

    What prevents the container from making copies of objects (through serialization) when it is about to make an optimized local call? In fact, why can't ejb deployment involve the creation of optimized serialization routines for the parameters in remote method calls?

    EJB hardly needs any more user effort involved. I don't think asking the implementers to do simple things to increase performance is a bad thing to do.

    God bless,
    -Toby Reyelts
  8. As I said I agreed partially :-)
    However if I develop an RMI interface, I MUST consider few restrictions ( like return type must be serializable...), something that I WOULD NOT DO if I wrote a local interface!
    The point here is to let the developers who develop the interfaces to decide because they in advance can take semantic considerations in writting their code.
    My personal opinion is different. I do not care
    if it is remote or local, if the container does guarantee
    the right arguments passings, it is fine to me. :)

    Haefel, I do agree with ORBER BY, and I would add dynamic queries as well!!


  9. The specs almost lay down an unmandated design strategy of wrapping up entity beans in local interfaces and accessing them through session bean remote interfaces. I feel they should have gone the whole hog and abolished remote interfaces for entity beans altogether. I can't see any scenario where people would directly want to access an entity bean through its remote interface and then access the related entities through value objects. Why not have them access entities only through a session bean remote interface? This would sacrifice flexibility but the moot point is do we need this flexiblity, given the whole idea behind the remote/local interfaces was to avoid the performance overheads with remote entity beans?

    Satadru
  10. But this is a major change in the entire concept behind dependent objects...

    Before, a dependent, for the most part, was an implementation technique used to prevent parts of EBs from being serialized as objects into data fields. If my Person EB needed an Address, and I wanted to represent an Address as an object, it would need to be a dependent in order to have its fields saved for searching. From a design standpoint, a dependent was not really an entity on its own and access to it was limited to the EBs that I specified (well, OK, I could get it via QL). A dependent was part of an EB.

    An EB, on the other hand, is an object to be considered in design. I guess thats reasonable. Its fine for my Person EB to use an Address class thats an entity.

    I'm not sure how I feel about this change. My first impressions are guarded, as I seem to like it. I actually have experience codeing dependents (using the MVC Soft Persistence Manager for jBoss) and I can confess it has been a pain in the butt.

    I am already in the habit of using SLSBs to access my EBs. I already do all my parameter checking and business logic in my SLSBs, so if having a "local interface" between a SLSB and an EB helps performance, than thats OK with me. Again, I wonder how much recodeing...

    But I have a project thats close to deployment ready. I'm now terrified that I have to rewrite a lot of stuff. I was expectng the dependent change, but there seem to be other extensive revisions as well. These extensive revisions not only make more work for me, but deply server products from hitting the market, except from those vendors who boiught in to the info and charge $30K for a server. I can't afford that.

    Is this spec 100% backwar compatible with the EJB 1.1 spec?

    I wonder if this second "proposed final draft" will be followed by a third. I sure hope not. I have work to get done and the long, long revision period on the first "proposed final draft" has really screwed me. Life on the bleeding edge, I guess, but due to this in large measure, I have been bleeding green...

    OK, I guess my confused rant is over... For now.

    Jim
  11. Jim,
    The spec says that the Container does have to support both
    EJB1.1 and EJB2, but because the contracts are different, the deployer has to choose one during the deployment
  12. Jim, I agree with you. The only way not to get screwed is to be in the EJB expert group( but only few companies are in there, fortunately the company I work for is in) and get the latest as they come, or as SUN "suggests", do not implement anything based on the PFD but only on Final Spec.
    But if you do that, you might be very late against your competitors if the PFD is confirmed as final :(
    Feel free to email me Jim (gscenini at hotmail dot com)

     
  13. What does that mean...[ Go to top ]

    What do they mean by "The persistence manager role has been dropped" ???

    Jim
  14. What does that mean...[ Go to top ]

    The Persistence Manager role has dropped means
    that the is no more a concept of Pluggable Persistence Manager, therefore the Container does provide the persistence of the CMP entities instead of delegating it to the Persistence Manager provider.
    Of course the spec does not define it, but you could have it, however you need a well known interface to the Container
  15. What does that mean...[ Go to top ]

    Thanks Gainni...

    I thought it meant that, but I had hoped it didn't. Do you know why they dropped this? It seemed like a nice feature and it created a nice incentive for ISVs to prodice special PMs with special features...

    Jim
     
  16. How long till an actual spec?[ Go to top ]

    I expect the changes in this spec are nearly as controversial as the dependents and things in the previous PFD. I hope the very long delay in geting this revision out means that the involved parties have resolved their differences and we have entered a relatively short public comment period.

    Does anyone have any insite to offer on how long until this PFD is final?

    Thanks...

    Jim
  17. So we have a local and remote interface.
    Why didn't they just put a flag in the descriptor, allowing
    us to say:

    always local, always remote, your choice

    Wouldn't it be nice to *declare* how we want the EJB to be handled, instead of having it in code?

    (I guess there is the type checking that they can do)

    But then again, I would kinda like to be able to setup
    lazy-loading as an option, as well as ... :)

    Dion
  18. Dion, the spec does say you can implement both interfaces on the same bean. The reason I wouldn't want to see this choice defined in a DD is that it potentially mandates code changes (ie passing by value vs. reference)... better let the developer be in charge of this.
    cheers,
    Markus
  19. Ahh, so we can extend EJBObject,EJBLocalObject and be done with it? that works.

    Thanks,

    Dion
  20. Since we may want to have the same bean accessible from
    both Local and Remote interfaces, do you think there
    will be more usage of a business interface? Then both the remote and the local can extend it. But it will have to throw RemoteException :/

    Dion
  21. Honestly I think that the use of both local and remote interfaces will make EJB model more successful and used in the future applications.
    Now if you do not have the remotability of the clients, you could still use the EJBs because of the local interfaces. If you have used dependent objects in EJB relationships, you saw the pain you had to go through.
    Local interface was a feature that had to come sooner or later. Dependent objects were an architectural mistake to me.
  22. Aren't mistaken re: the signature of CMP ejbCreate.

    Sure you have to return null and not the primary key
    but the signature is the primary key type so that you can subclass a CMP bean by making it a BMP bean.
  23. Robert,
    I am not, but you right the public doc ejbCreate signature return void. It is a mistake in doc writting.
  24. I guess it doesn't make sense to debate point by point on this thread, probably it would be better if Floyd would make a category on the spec itself and then we can take it point by point as there are too many controversial, unfortunately.

    I do agree though that having now 4 different interfaces is not very clear conceptually although with hard work and a lot of black coffee one can get over this impediment :)

    Anyway my first impression is that is quite dubious how a "final draft 2" can have such drastical changes.
    Although by studying it I get an idea that they're in a hurry to catch the java 2 deadline and please everybody in the same time.

    Too unfortunately , I think.
  25. If anybody has a copy of the draft can they email robert at elastica dot com I'd like to get a copy from you. Today I cannot get it from javasoft. It keeps failing both via ftp and http.

    Please email me first before sending the spec.

    Thanks.
  26. I really don't understand why Sun isn't able to release a clean and coherent specification !

    Entity bean with local interface will be very fine-grained, and having no support for inheritance at this level won't be practical.

    Java is an object language why EJB isn't completely object ?
  27. One glaring omission in the EJB QL specification is the lack of a ORDER BY clause. Have you ever worked on a real world project where you didn't use an ORDER BY clause?

    This seems shortsighted to me. Relational and OO databases are perfectly capable of providing ORDER BY functionality. AND the databases will do it much more efficiently then the bean provider will.

    IMO, this is a rather large hole in the EJB QL specification and I believe Sun will regret not including an ORDER BY clause in the specification.
  28. My understanding of the QL is that it is abstracted one level away from the database - so you are not referring to rows in a database, but to objects themselves. Wouldn't an orderby clause mandate that ordering logic be added not only to each bean, but also to any object contained within the bean?
  29. I would say that there is not a glaring omission in the EJB QL.

    The EJB QL itself is a terrible idea in the first place.
    Not to mention that we'll soon have another half baked query language in the JDO specification which is not quite the same.

    After all even if they are allergic to SQL and the relational model in general, what is then wrong with ODMG ?
    I guess it's not invented by Sun.

    Even if they included ORDER BY, does someone really expect anybody to drop the database SQL language or OQL or whatever they might really use for the new kid on the block, EQL ?

    Another clue that they might be allergic to the relational model is that they use the notion if "relationship" which can be "unidirectional" or "bidirectional" (wow!).

    There are also funny things that denote the hurry in which they hastily assembled the EQL, like the IN keyword:
    "FROM Order AS o, IN(o.lineItems) l"
    and "WHERE o.country IN (?UK?, ?US?, ?France?)"

    The first use of "IN" is just to support the key OO concept of "navigation" (therefore "relationships" can be "unidirectional" or "bidirectional") which is to replace the "obsolete" relational ideas like relation and join.
    The spec looks like going back in time to hierarchical database concepts.

    I don't want OO foos to jump on me here and lecture me again on OO/Relational mismatch and a big divide.

    As far as I know there are at least two research direction which evolve the relational model by adding key OO concepts one of which has been successfully implemented in pratice.
    But they're not from Sun.

    "Not invented here" syndrome strikes again.
    Overall I think the general impression is not that good. The problem is if Sun's going to do anything about it.

    Costin
  30. I agree that EJB QL is a bit silly but it seems like its not going away so the best approach (if you can't get rid of it) is to improve it.

    EJB QL will be translated into SQL or OQL or whatever the database uses during the deployment process, so the fact that EJB is an object abstraction for a data source is not material to the fact that an ORDER BY clause is necessary. You need an ORDER BY clause whether you're dealing with objects or rows.

    I would suggest that Sun adds the ORDER BY and make the return type java.util.SortedSet for finders and selects that use it.
  31. You do run with the ball.... :-)

    Lets suppose, our objects were not persisted to an SQL database. Lets say our objects were mapped to some CICS transactions, an object database, a legacy system wrapped using MQ series or a combination of all of the above. What good is SQL in this case?

    We want to wrap these using an object model. We may want the object model to aggregate several back end systems. We need a query language that can be mapped on to the various finders for the back end objects.

    This is basically what Component Broker from IBM did/does. We wrap each individual back end system using a data object. We define finders for these objects. These objects are not always SQL databases.

    We then define business objects (entity beans) that are composed from data objects. We use a OSQL language for the finders on the business objects. A query engine takes the OSQL and maps it on to the underlying finders. The query engine knows what sorts of query each backend does and then decides whether to push down the query part to it. Example, an Oracle backend may be able to do a where clause efficiently but a MQ series back end may not. Joins, order by, group by etc would need to be done at the highest level, i.e. the query engine.

    This is the sort of architecture that Sun are aiming at now with EJB QL. I'm not saying it's perfect, I'm just pointing out what they are shooting at. Entity beans only persisting to an single vendor SQL database is a short sighted view of what entity beans may do in the end.

    They could have used a standard query language like OSQL etc but they didn't.
  32. Costin, as usual you are too much database oriented.
    The world is not only the database!
    You are like the emacs maniacs.
    Emacs is an application server, emacs is a database, emacs is a OLTP. Let's face the reality, and if you really want to know, only 30% of the world data is stored in the rdbs!
    First, IN. You should know the IN helps you to avoid the cartesian product, should not you ?
    Second, SQL. SQL is for database only. You CANNOT assume the the persistent datastore is always a rdb!!!
    However, I have to say that I do not like the EJBQL, I would have used OQL like we did with Component Broker which is optimized with the pushdown technology.
    I would suggest you to take a look at the CB architecture
    (By the way, its implementation is awful) which is one of the best OTM to me.
    Costin...Costin...

    -Gianni
  33. Yes, Gianni
    you might be right about 30%
    and other 10% might be stored in Microsoft Office documents and who made this statistics and how?

    The world is supposedly producing exabytesa a data per day so what should we do now, try find a good implementation General Problem Solver or what ?

    I might be a database maniac, i don't know about that, but I'm sure you must be an OO maniac.

    And as maniac as I might be I'm not saying that we should drop the OO languages.
    But neither OO maniacs like you should try to say that the relational model is bad or inadequate, because the reality proves you wrong.
    The two biggest software company Oracle and Microsoft are producing relational database, the only one important with non relational databases is IBM and those products look like in maintenance mode.

    The fact is that OO databases tried to replace the relational databases, but they didn't succeed, and I'm sure if somebody would start a business project and would ask you what database should use you'll have to recommend probaly DB2 as an IBM fan, but I'm certain you won't recommend IMS neither you would try to find a new kid on the OO block.

    So, what's your reality ?

    The problem is that these antagonism between OO and relational could easily be overcome if there weren't such flame wars like this one.

    You cannot assume "persistence datastore" is something I use. i'm not using any persistence datastore I'm using SQL databases.
    This idea of reducing database to "object persistence", "persistence store" or "persitence logic" is totally a bad one.
    If not for else but for the fact that databases are terribly expensive products and it's not economically wise to reduce them to filesystem like functions and reinvent the wheel over and over again in the "object layer".

    So what's a good solution to this dilema?

    My opinion is that we should evolve to a model that takes the benefits of both approaches OO and relational.
    I'm not sure how many OO people are in a mood to accept that the relational model has some advantages and aslo I'm not sure how many relational folks are in the mood to get to OO concepts.
    Worse, I'm not sure how many commercial software companies are in the mood to risk for such a project.

    But doing one model at the expense of the other is not the way to go.

    Cheers,
    Costin
  34. Costin,
    When you are in difficulty, you put words I never said in my mouth. :-)
    You wrote:
    "...you should try to say that the relational model is bad or inadequate"
    NEVER SAID THAT. Take a look back to my posting!
    I said that the rdatabase is not the world!
    Second, do not put the discussion on rdb vs odb!
    That is not the subject of this thread, and nodody is trying to compare the two models.
    3RD, I am not an IBM fan, I AM a fan of
    the things that are well architected and bring good (Theorical and practical) technologies.
    I do like Component Broker's architecture, but I think
    Websphere advanced is a piece of crap! So ? IBM fan ?
    If you work with objects, you want an OQL!
    If you work with a rdatabase, you do want SQL!
    Would you query a rdb using a object query language ?
    So, the point is to standarize an OQL for object queries
    The OQL could just query the memory and not the datastore.
    If then, you use the datastore, you have to translate it into a specific datastore query language, right ?
    Thats it!





     


  35. The OQL could just query the memory and not the datastore.

    >If then, you use the datastore, you have to translate it into
    > a specific datastore query language, right ?

    No you can't query the "memory" only unless in very limited and theoretical only cases, without dropping trabsactional consistency and other good stuff that are provided by the databases.

    And, if I use a reltional database, I don't think it is wise to use a supra query language that translates only to a subset of SQL.

    >If you work with a rdatabase, you do want SQL!
    So what's that I should use SQl or EQL or OQL ?

    Costin
  36. No?!?!
    Costin, not all the objects are persistent as a db maniac might think ;-)
    (Guys, I and Costin are friends...but he is really a db maniac!! ) ;-)

    I CAN query in memory non-persistent objects.
    If then, they are persistent, I need to "pushdown" the query to the persistent store to get the stored state of the objects!
    That is computer science! That is not an opinion!
    If your argument is that EJBQL is not well designed,
    we agree!
    If your argument is to use SQL instead, to query objects (Because the rdb is always the datastore ) I disagree!

    Ciao
    Gianni

  37. Gianni,

    If you're object are not persistent ok, go ahead and construct your query framework, whatever, i'm fine with that.
    I never felt the urge to query my persistence objects, but it would be nice if I could.

    We were not talking about that, and it is concludent that no OO language designer unitl now has ever considered the query problem.

    After all one of Codd's strongest arguments it was that the end users do not understand pointers and other language constructs (like object nowadays).
    They understand values and we should try to query based on values so we could best support the end user in business ("enterprise") applications.

    About SQL,
    my argument if you cared to read me thoroughly, was that we needed something that is evolved both from relational model and the OO model taking the best and not the worst from both.

    What many people seem to agree is that EQL is rather "involved" from SQL.

    Salut,
    Costin

  38. Cotzin, we agree then, I can go to sleep happy tonight....

    Thats just what I said. I think you'll agree that the OQL layer makes sense to allow the scenario I outlined, object model over hetergenous backends.

    But, we shouldn't do it at the expense of reducing the possible expression of SQL for the much simpler persistence models using only a relational database.

    We need a scalable query language that lets us do queries across hetergenous back ends whilst at the same time taking advantage when it can of the characteristics of individual backends such as relational databases.

    It's seems apparent that right now, EJB QL doesn't meet the above criteria.
  39. Billy,

    Well, I guess it is first a bad project management decision that the EJB specification contains everything for everybody.
    A new query language should have been a separate project in its own right and not some twenty pages in the EJB spec.

    And what do we do if the JDO comes out with its own query language and then we want to use JDO to implement CMP or BMP ?

    And after all, there is a good observation by C.J. Date that if we want to have a query language against objects, then the right solution must be that the query language should be an integral part of the OO language itself.
    This could be a good solution in the long run.

    I think it would be disastruous in the long run if we'd start to train large army of developers in the brand new EQL, and vendors will be locked in the EQL model.

    So I agree that we need a scalable query language that lets us do everything we want and need to do, but first we have to research whether this is at all feasible and provide a good model for that.

    Cheers,
    Costin
  40. Hi Guys-

    Any possibility of taking the QL discussion to another thread?

    I'm REALLY interested in hearing more comments about changes made between PFD1 and PFD2 of the EJB specification which was the original intent of this thread. EJB-QL has been in the specification for awhile, so I think it would make sense to debate those particular topics elsewhere.

    Tyler
  41. Hi Tyler,

    EQL also suffered a big change fro the former PFD because its underlying model -"relationships"- changed.
    That doesn't mean that the previous version was better.

    I agree we need to take each problem step by step in a separate thread, and I proposed to Floyd to create a separate category (forum) for such threads.

    Floyd,
    are you there ?

  42. Costin wrote:
    " ..then the right solution must be that the query language should be an integral part of the OO language itself
    This could be a good solution in the long run. "

    Oh sure!!!, we are going towards portability, and cross language applications and you suggest a object query built in the language, therefore a query for Java, a query for C++, a query for Smalltalk ..

    No No NO!
    Good for you Bill, I am not going to sleep tonight ;-)
  43. What portability and cross language applications are we talking here ?

    I thought we were talking about EJB ...

    Cross language , well, you might want to start a thread on .NET amnd common language runtime.

    Joking aside, C.J. Date has a few valid points about that, if you put you "query language" into host strings then you loose compiler checking that made you use the host language in the first place.


    Cheers,
    Costin
  44. Well, then what do we do then, going back to the hierarchical model ?

    I'd agree to your argument if the problem with the other non-relational models were not easy to query in the first place.
    You can access them using their specific ways , but I'm not sure if you can easily build queries on them.
    After all, if they were capable of query we wouldn't have had the relational databases now.
    I guess that the quasi-majority of new projects as far as I know start using relational databases, and many enterprises are migrating their data towards relational stores.
    I don't know if anybody would start a new enterprise project from scratch and go with IMS.

    Even that it would be fine with me to have a supra query language that does everything for evrybody if possivle at all.
    But if this language and their idea of relationship would make me bent and twist the relational model, then I don't like that.

    I'm not sure if sacrificing the most common case for the rare cases is a good way to go.

    Costin
  45. Lots of enterprise customers have large investments in CICS, IMS and other 'legacy' systems. People want to build object models and people want to express queries at the object model level, not using 2 or 3 proprietary query languages.

    So long as the query language and query engine were clever enough to map straight on to SQL when using queries that only involved objects that mapped to a single database then I don't see a problem. So, solve complex problems for the 5% of people who need it but don't screw up performance etc with the other 95% of the real use cases.

    The only time the query engine needs to run parts of the query it-self is when a query runs over multiple back ends. Here the query gets split and each part runs on the appropriate back end. The query engine then combines the results, filters it, orders it etc. The query engine needs to be clever enough to do this.

    EJB QL does how-ever need to be as functional as object SQL as else developers are just going to get frustrated with it, as seems to be the case with some of the postings on the thread.
  46. Gianni, I think Costin has a point. One can almost never be "too" database oriented... it really is the lifeblood of the enterprise and the chief productivity and performance bottleneck of our systems. I think one of the major reasons we have EJB in the first place is because it's difficult to create re-usable and maintainable systems out of triggers and stored procedures with some form of procedural SQL.

    Now of course having said that, mapping straight to SQL would probably be a bad thing for the reasons outlined above both by you and Billy. But as was said, don't screw the 95% for the 5%... which was something that was very apparent with prior versions of the EJB specification. (find methods, for example, are virtually useless using BMP persistence and only really make sense with CMP)

    Now, Costin, here's my question: how does EJB QL (or general object query languages) harken back to the hierarchial model? Chris Date has bible-thumped on this argument for a decade now, and we're seeing signs (SQL-99, for instance) that we're adopting a hybrid approach to this vs. a purist approach.

    The honest truth is that sometimes a model is more usable with pointers. Navigation-intensive object models do not require the flexibility of equi-joins. Especially models with high cardinality relationships or long traversal paths.

    Entities provide a way of achieving a balance between low coupling (componentization), and object based data abstraction: high coupling with in a component. EJB QL is a necessary balance between the SQL paradigm and the object paradigm. I don't know why they're not using the ODMG's OQL. It could be for political reasons - the ODMG never seems to get much respect.

    My beef with EJB QL is that it is lacking an API-based dynamic query mechanism.

    Perhaps we'll have to wait for EJB 2.5, but in my experience we don't need a new query language, we need an mechanism similar to the EOQualifier / FetchSpecfication API in WebObjects' EOF, or TopLink's query API.

    Such a mechanism is pure *joy* to use since it maintains conceptual integrity when performing queries: you never have to leave your target language. It requires the ability to mentally jump between the object & relational model, but I find those to be more friends than enemies.. it's SQL itself that causes the impedence mismatch, and is best left for set-based transactions in stored procs.

  47. Yes STU,

    Up to a point I agree with you, especially in what regards object.

    It is far more preferable to have a Query API to query for "host language objects" (if my terminology is correct).
    By specifying queries in strings against the objects that are under the language control you loose compiler checking and programming is definitely more complicated.

    Yes pointers are more efficient for navigating objects, but there's a confusion here.
    You only need to have pointers in order to have a good implementation of queries, while at the interface level pointers are rather unnecessary because relational model is enough.

    That was Date's argument if I understood it correctly.

    Where the EQL and "relationships" model brings us back to hierarchy and networks , I'll come back with more details when I'll have more time.

    But lok at this scenario:
    You have 4 types of entities if not more
    BMP entity with remote interface
    BMP entity with local interface
    CMP with local
    CMP with remote
    and entities with both local and remote
    then you have "relationship", "bidirectional and "unidirectional" ( only this "direction" thing is enough to be already in the network model)

    Then relationships can be only between local interfaces, so it apears that the remote client cannot query the remote interface for the related objects, even if the entity has also a local interface.

    Anyway the "relationship" thing looks quite restricted from a proper relation as we have in algebra or in relational model.

    And we have such a conceptual mess about this notion that we have local and remote entities and BMP are different.

    I thought object distribution is matter related to separation of concern and as someone pointed here, it is very easy for the container or the ORB to take care of that, provided the model allows it to do so.

    The specs writer seems more concerned with the query engine genrating a remote call which is an implementation matter while writing a proper model and a query languahge is a totally different thing.

    It is true that EJB has been overly criticized on the remote call matter but this wasn't the wright solution.

    Well, those are only a few things.

    Cheers,
    Costin

  48. Costin:"...But lok at this scenario:
    You have 4 types of entities if not more
    then you have "relationship", "bidirectional and "unidirectional" ( only this "direction" thing is enough to be already in the network model) "
    It is so clear, and obvious in the OO

    "Then relationships can be only between local interfaces, so it apears that the remote client cannot query the remote interface"
    Please go back to the fundamentals of EJB.
    You query using Homes!!!, moreover ejbSelect is only for EJB bean internal use!!

    STU,
    I agree with few points with you, especially with the query over hierarchial systems, and API based queries.
    By the way, we (ATG) have a Repository model
    (With DB,LDAP,XML's implementations , and RQL query language API based! )

    I would not bet too much about 95%-5%. You might be wondered to know how many financial institutions and banks still use the hierarchial models. (That comes from my extensive experience)

    Abstraction tends to hide the deeper properties,
    which means the more you abstract, the more you tend to loose the abstracted specific behaviour. Even in the SQL, you have specific database features!

    100% on impedence mismatch between rdb and OO!

    -Gianni




     

  49. Gianni,

    Directionality might be an obvious thing in OO but has nothing to do with relation concepts.
    You can have it as an implementation matter if you put pointers back and forth in usual OO way.

    But the pure mathematical fact is that if
    aRb then bR'a where R' is the inverse relation, you can't escape from that.
    By adding directionality to relations we are suddnely in the graph theory instead of relational calculus, hence my conclusion that we're kind of back to the old database models.

    And you introduce unnecessary complexity with no real benefit.


    And don't send me "back to basics" until you try to understand what i'm saying.

    So let me spell it out what I meant:
    so through a CMP managed relation a Parent bean may have a
    Set getChildren() method returnig a set of Children beans ( references to them ).
    But this "relationship" cannot be visible non locally, in the Parent "remote" interface according to the new spec, or at least according to what I understand of it.

    But what do you have to say that through this "relationship" it is the first time when I saw predicated the side-effects:
    parent1.setChildren(parent2.getChildren())
    has side effect on parent2 in a case of 1 to n "relationship".
    And that is "satndardized".

    Common are we joking here or what ?

    Cheers,
    Costin

    P.S.
    >100% on impedence mismatch between rdb and OO!
    That's what i meant when I said you're OO fanatic.
  50. Costin, ..and this is it for today ;-)
    "Set getChildren() method returnig a set of Children beans ( references to them ).
    But this "relationship" cannot be visible non locally
    "
    That is why relationships are restricted to local objects!


    "Directionality might be an obvious thing in OO but has nothing to do with relation concepts. "
    You are always set up on DB, we are talking about EJB relationship or what ?
    That's what i meant when I said you're DB fanatic. ;-)


    "But what do you have to say that through this "relationship" it is the first time when I saw predicated the side-effects:
    parent1.setChildren(parent2.getChildren())
    has side effect on parent2 in a case of 1 to n "relationship". "
    If you had read the spec more carefully, you would have noticed that the referential integrity of the relationship must be enforced by the system, therefore for the above mentioned case:
    parent1.setChildren(parent2.getChildren())
    --> parent2.getChildren == null or empty collection if I guess you wanted to say getChildrens ( IF MANY)
    See special semantic of Collection operations!

    Ciao
    -Gianni









  51. Gianni

    You always say "read carefully" but you always don't read very carefully what other shave to say.

    Enforced por not enforced by the system do you mean to say that "relationship" chapters don't promote side-effects ?

    At least I know that databases enforce refernatial integrity through exceptions.
    It would be a terrible mistake to enforce it by side effects.

    Do you or do you not agree to side effects ?

    Ciao
    Gianni
  52. Costin,
    I would call it "natural behaviour of the automatic relationship semantic enforcement ", but if you wanna call it side-effects, that is ok to me.
    Costin, let's suppose you have ONE to MANY relationship,
    (Company-Employee) and you have decided to manage the relationship using a distinct table.
    Correct me if I am wrong, but nobody stops me in inserting an entry(ref of a second Company) in the distinct table
    ending up with 2 to MANY, huh ? ..Unless you define the Company ref as PK of the distinct table.
    Therefore no referential integrity, or Am I missing something ?

     
  53. Gianni,

    Here is where it could help you to be a little more inclined towards the values of the relational model.
    Of course you're missing something, you're missing the big picture about how relational model is supposed to work.

    So let's say you have company to person relation called "employment" and one person should be employed by just one company like you said.

    In the database world you usually do that by a foreign key but let's admit that we do it your way so we have PERSONS table and COMPANIES table and we have the EMPLOYMENT table which contains at leas PERSON_ID and COMANY_ID as fields and foreign keys to their respective table.

    Because we have 1 to n relation then we'll have a unique index or a primary key on EMPLOYEE_ID in the EMPLOYMENT table to enforce this constraint, and not like you said that we declare PK as a COMPANY_ID like you said.

    Then let's say personA is currently emplyed by companyA and we want to change that to companyB.

    If we want to INSERT INTO EMPLOYMENT(PERSON_ID,COMPANY_ID) VALUES(personA,companyB) the database will get back to us with fury and let us know that we violated a constraint.
    In this case we have to do either UPDATE or DELETE the old relation and INSERT the new one.
    But it is never wise that when we need to INSERT the database instead will do an UPDATE for us.


    There's also here a more subtle difference because databases regards relation as a mathematical fact on values, while the OO models regard relations as an implementation fact because you have pointer members from one object to another.
    Hence, the easy escape through side-effects, and stuff like "direction".

    Relational databases took over the hierarchical and network databases especially because of the former usage of pointers.
    OO database were quick to forget this lesson and reintroduced the pointers, navigation, direction and other cool stuff as a first class concept of the model and by all likelyhood they failed to compete with RDBS.

    So , aside this rather phylosophical but very important consideration as has been proven by practice, the rule is simple:
    When you violate a constraint you get an exception but to say that the system will modify the state of another object to make room for your violation is absurd.

    It is called side-effect and not the fancy name you invented.
    Last time I learnt about programming side effects were considered bad.
    Did something changed in the meantime ?

    Costin
  54. Costin,
    Of course, it was a writting mistake in my posting, PK in employee otherwise you would have only 1 company with 1 employee ! ;-)

    Stu, I agree with you that EJBs will be used with database
    as persistent datastore.
  55. Gianni,

    Does this mean that now you see you can do it therelational way or it measn that you agree that side effects are bad ?

    I mean, common, this is an easy thing to be changed until the PFD3, and you could send them a message through your company involvement that they could get the crap out of the "relationships asignment semantics".

    But to have a spec which promotes side-effects, it would really be a shame for the whole Java community.

    Ciao,
    Costin
  56. No Costin,
    The point here is the abstraction that the EJB model provides.
    Using special semantic of the Collection/setter/getter as required by the spec, the Container's implementation enforces the relationship semantic, not the EJB client.
    I do support the relationship semantic specified in the EJB 2.
    However, I really do not like the EJBQL , and I would choose an API based approch as I said in my earlier posting (and STU suggested as well)
    Keywork as orderby is missing.
    I do want the pluggability of the Persistence Manager, which has been dropped in the PDF2.
    The introduction of the local interfaces is good, but I would think another way to use them, maybe a declarative approch in a DD, or transparent to the developer letting the Container make the optimization .
    Inheritance has not been addressed here, if we really want to truly reuse objects and let models envolve... (following the OO paradigm), but this is not an easy topic!

    -Gianni


     


  57. Side-effects[ Go to top ]

    Ok, Gianni, so you support side effects, saying that they provide a nice abstraction.

    Being on the vendor side it's nice from you that you want to shield us the mortals EJB client writers from the hairy scary complexities of "relationship".

    I want though to point out that when a developer says
    parentA.getChildren().add(childB)
    Then if childrenB was child of a parentB the side effect is not only on the childB which might be regarded relatively OK, but is also on the parentB who is not even present in the statement (like in the previous example where we talked about parentA.setChildren(parentB.getChildren()) which might be argued about that is relatively correct.

    While side effects are in general error prone, this particular case might be an invitation to disaster, at least IMHO.

    Can anybody give a second opinion here, or maybe I should learn again the basics of programming again ?

    Gianni, about inheritance the spec writers pointed out that it is already supported by the Java language both at interface and at implementation level, which is kind of right up to a point.

    So could you be more specific what you want your inheritance to be ?
  58. Side-effects[ Go to top ]

    Costin,
    About the relationship, I am more than willing to discuss the topic, but first read the related chapter in the spec, and not trying to put code here and there to show "side effects" or whatever you have in mind to say it is bad implemented or even it makes no sense.
    However, briefly if you add a member to a relationship, you have to remove it from any relationships it belongs to ( if special semantic is required like 1 to many/ 1 to 1).
    With many to many, this rule is not applied
    (Group-Person, a person can belong to more than 1 group, and a group can have more than 1 person).

    About the inheritance, that's another mistake you make, because you consider EJB as "regular" objects instead of components.
    Java language inheritance is different from EJB inheritance.
    Nobody stops you to extend your EJB bean(your implementation) from a superclass!
    Different is when we talk about inheritance at EJB level as entireness, which implies polymorphism, and dealing with the primary key's inheritance. You cannot archieve that with simply inherit your EJB bean from a superclass. You have to do more stuff. I used the IBM's early technology with WAS (WebSphere), but you were restricted to use the same primary key. It is possible to make it work but they just want to standarize it so that it will work in any container.
    -Gianni
  59. Side-effects[ Go to top ]

    About the inheritance, that's another mistake you make, >because you consider EJB as "regular" objects instead of >components.


    Gianni, this shows how superficially you read other's posting. I didn't say that , the spec writers said it, and my opinion was not enough, so I was asking your opinion about it.
    If you want to have a dialog then please read carefully, otherwise is like you're not enough.

    EJBs are NOT components, despite whatever marketing buzz is being pushed by Sun, but on this you can respond to me on the "Component Pattern Language" thread (below this one) where I put my arguments about that.


    >Different is when we talk about inheritance at EJB level >as entireness, which implies polymorphism, and dealing >with the primary key's inheritance

    I guess you either have a confusion here or you can't say exactly what you mean.
    By using Java inheritance you already have polymorphism and you can use and to talk about Primary Key inheritance this is just where implementation have to go figure out what they should do, anyway if you want to have complicated hierarchies as Primary Key (even a derived class is too much), then you're way outside what can be an efficient data model.
    Let me remind you that a 4 byte integer is all you need in 95% of the cases and what is best to use, so why create another hairy scary model on this subject.
    Maybe you can come up with a concrete example where the primary key lack of inheritance doesn't satisfy you.

    Can you tell what's "EJB level as entireness" and try to define concepts here and not mumbo jumbo ?

    About side effects is pointelss to discuss any further, unles you're talking concretely.
    So I lay out my arguments again like for math demonstration:
    If the developer say
    ParentA.getChildren().add(objectB) and objectB already isrelated to a parentB then it is very likely we have a programming error, a constraint is violated so you throw an Exception.
    The correct way of moving objectB from one parent to another is:
    objectB.setParent(parentA)
    like in
    UPDATE CHILDREN SET PARENT= <parentA_ID> WHERE CHILD_ID=<objectB_ID>

    Why they don't use this correctand simple aproach and waste lots of pages on these rather useless cases about "collection assignments semantics" is because theyare entrached like you also are in the OO concepts and they think of "relationship" as with directions being given by a collection of pointers.

    Relation is a mathematical notion and it being given by a mathematical condition (CHILD.PARENT_ID=PARENT.PARENT_ID) so because of these you never need in the relational model to talk about "relationship semantic assignments".

    But of course , maybe the relational model is obsolete and we shouldn't discuss it.

    Cheers,
    Costin
  60. Side-effects[ Go to top ]

    Costin,
    finally what you said makes a lot of sense to me!
    YOU DO WANT to go back coding embedded SQL, that is all you want. It is very clear!

    Saying that EJB is not a component model, it is pretty scary. Can you agree it is not procedural ? ;-)

    I am out of this discussion with you, sorry.
    Your argument is ONLY dropping these "malicious" objects or component or whatever you think they are because you could use the rdb directly.
    (By the way, please leave the math out of this discussion, nobody is questioning the validity of the mathematical model behind the relational databases!!! )

    I DO NOT have nothing against the relational model, instead I think it is one of the few proven things it works...
    ..but we are developing with objects trying to find a smart way to make them persistent (when needed) without emphatizing too much the impedence mismatch between the two models.

    About the EJB inheritance, I am just speakless, but considering you find EJB non components, everything is clearer now.

    Have a nice day
    -Gianni

     

  61. Side-effects[ Go to top ]

    Gianni,

    I'm sorry to find out it's easier for you to make a process of intentions than to have an intelectual exchange of ideas.

    Yes, I CAN say EJBs are not components, it is free speech after all, and it would be a preety ugly if every body involved in Java programming will bow his head to his Majesty Sun's ruling on what is black and what is white.

    But if you want to have a good intellectual exchange of ideas you can come to the thread below this one and tell us what is a component and see if that fits EJB.
    In the thread below this one we especially debate what is a componet or a component model.
    You don't want to say that component is whatever Sun chooses EJB to be, or are you ?
    Or whatever is non-procedural ?

    You must know that there are few books in this world which it makes no purpose for one to debate them polemically, and I have to tell you that EJB spec is not among them.

    Ok, so you want me to leave math out of discussion, relational model out of discussion, components out of discussion then we'll debate whether EJB QL should be strings or API, and finally we'll have to leave EJB spec out of discussion because it HAS to be the only possible good thing sent to us by holly SUN.

    "we are developing with objects trying to find a smart way to make them persistent "

    No, not we, this a fundamental mistake that is done by many people, and I guess I am more entitled than you to choose how I develop projects because I am on the project development side while you are on the tool development side, so if you want to disregard my needs and tell me what you think is best for me, well go ahead and do it, I'll be happy not to buy your tool.

    So I am developing whatever it makes sense to me, be it SQL, or C, or Java or Delphi or C# if it so pleases me.
    But my only final concern is to have valid DATA that reflect business reality.
    And my secondary concern os to access and manipulate DATA in a way that makes sense and it is optimum from a mathematical perspective about performance and validity as well as from a software engineering perspective about ease of use maintainability and so on.

    What you see on a bussiness final balance sheet is data is not algorithms, also data is what you seeon your invoicves and every where output is presented to final user.
    The state of a business system is also defined by the DATA, usually in the rdb, and NOT by the objects in the middleware.
    We are in the business of having correct and truthful data in the database, not in the business of layering fancy objects in the middleware.

    It is like "verba volant, scripta manent" data remains in the database and in the archives.
    If you like to look at data only through your OO glasses in the middleware go ahead and do it.
    But stop trying to pretend it's the only valid way to do it.

    Anyway, I guess I'm out of this discussion also, I just wanted you to know exactly what I think and not what you think I think.

    Cheers,
    Costin
  62. Side-effects[ Go to top ]

    "But if you're using CMP "relationships" and EQL is just that you can't access the relational data, but through twisted non relational ways as I pointed out.
    We're accessing relational data in the same way as if we had IMS behind the scenes !"

    The whole point of EJB QL is that it's *not* relational data you're accessing. It's an object oriented abstraction data.

    If you want pure SQL access, you're free to use JDBC like you'd normally would -- and deal with the cumbersome manual mapping of ResultSets to objects. (Or you can just use raw rows with HashMaps if you're looking for ad hoc access).

    Certainly making relationships first class citizens of the EJB world would be an interesting development, but I would think that very few programmatic systems have approached this direction. (Do you know of any? Commercial, I mean.) And so, we hit the "need more research" situation .. which I think really isn't the job of the EJB expert group, they need to specify solutions that are realistic for vendors to implement without too high of an investment..

  63. Also..[ Go to top ]

    "The state of a business system is also defined by the DATA, usually in the rdb, and NOT by the objects in the middleware. "

    ... Which is (I think) clearly understood. The objects represent process, validation, and knowledge.

    "We are in the business of having correct and truthful data in the database, not in the business of layering fancy objects in the middleware."

    Ahh, no. I think we used to be in this business, back when data management was a novelty. It's not a novelty anymore, it's just business. The more I explore it, the more I feel that the software-encoded knowledge of a business domain in those "fancy objects" is the real value-add to the business.

    Certainly, data should be managed carefully. But data without context is meaningless. I think we're degenerating into the data vs. process debate, which usually winds up fruitless, kind of like an argument about the benefits of armor vs. mobility in warfare. They're both important -- data has been emphasized in the past, but it's quite boring without operational or analytic systems to operate on it... and Object orientation, like their big-brother frame-based systems, have provided (so far) one of the better ways to represent process, constraints, and general domain knowledge.

    "It is like "verba volant, scripta manent" data remains in the database and in the archives.
    If you like to look at data only through your OO glasses in the middleware go ahead and do it.
    But stop trying to pretend it's the only valid way to do it."

    We could turn that argument around... But anyway, I don't think anyone's been pretending it's the only way to do it, but we have been saying that this is the EJB way of doing it... and it's also one of the reasons EJB is still gaining popularity: the potential of CMP (when it's done right). Leveraging a true object oriented representation of data is something the industry hasn't really done en masse yet -- such a development would most likely yield a lot of productivity benefits.

    I'm looking forward to it.
  64. General comments on pfd2[ Go to top ]

    So far, I like it.

    The Local/Remote interfaces merely provide two different views into your component. It's an easy idea and solves quite a few problems:

    - fine grained entities are kosher at last (the Persistence PowerTier guys must be dancing for joy)
    - the non-standard pass-by-reference optimization that's often used
    - simplifying CMP 2.x, and potentially speeding up finder methods.
    - big for me: locking is much finer grained now (with dependents + a CMP cache, commit option A would mandate a bean-wide lock which to me is about as primitive as a table lock.. bad for hotspot data!). I still think EJB needs a fine-grained locking control...

    Playing around with some sample code under the new model, it definitely makes my CMP 2.x beans a bit simpler -- the deployment descriptors too.

    I also notice they've taken out the remote ejb references for relationships, probably a good thing to enforce coarse-grained remote entities & fine-grained local entities.

    I think the only major concern is that people might not like the "between 2 and 4 interfaces per object" idea, especially given the sad state of most develeopment environments in handling large numbers of files and dependencies. It's a conceptually clean approach, but in practice feels a bit messy. This is the Java Way, however... Perhaps the tedium will make people more open to dynamic typing in the future :D

    Anyway, need to mull over it more, these are my initial impressions..
  65. Also..[ Go to top ]

    Stu,
    That is what I have been saying along this discussion.
    I could not be more agreed with you on that.
    -Gianni
  66. With all due respect[ Go to top ]

    Costin
    "
    No, not we, this a fundamental mistake that is done by many
    people, and I guess I am more entitled than you to choose how I develop projects because I am on the project development side while you are on the tool development side, so if you want to disregard my needs and tell me what you think is best for me, well go ahead and do it, I'll be happy not to buy your tool. "

    With all due respect, I have worked in the global services for 10 years developing the biggest projects using all the possible technologies , and now I am in the product development, EJB container development to be accurate!
    Please do not say anything about a person if you do not know what a person has done!!! This shows how arrogant you are!
    -Gianni
  67. With all due respect[ Go to top ]

    Gianni,

    As good friends you said we were and I certainly agree we'll try to read carefully what the other has to say and respect each other's rights to their opinion, before we jump to conclusions.

    I said "I guess I am more entitled than you to choose how I develop projects ",
    that is within my projects I will choose how I do stuff and I don't see why I am arrogant for that.

    Even with your big involvement your advice I shall not follow your advice if does not make sense to me.
    And I meant ESPECIALLY because you haven't been writing business project code for a while and ESPECIALLY because you develop containers now
    you should be more attentive to what the "other" developers want you to provide.

    Stop throwing words like that please.

    Cheers,
    Costin
  68. With all due respect[ Go to top ]

    Costin,
    "
    I said "I guess I am more entitled than you to choose how I develop projects ",
    that is within my projects I will choose how I do stuff and I don't see why I am arrogant for that.
    "

    NOBODY here is more entitled than others!!!
    Moreover, when you are in a circle, you ofter do not see outside its boundaries. It is pretty interesting to me to see the opinions of other people in DIFFERENT CS fields (not only project development!), like relational db, oltp, research.. etc, to understand, compare, and evaluate better the technology on discussion, and to make it
    fit all the needs, considering all points of view.
    The point here is not to make a CS field (relational vs object..) better than another one, because we do also have to change the context where the technology is used in.
    Coexistence is also possible!


    "
    Even with your big involvement your advice I shall not follow your advice if does not make sense to me.
    "

    I am not pushing anything, neither try other people to follow whatever.
    Moreover, at the end, if the technology
    I have implemented is used successfully in the application developments, I will be successful as well ;-) !
    So, it is pretty much my interest to meet the real problems
    .

    "
    And I meant ESPECIALLY because you haven't been writing business project code for a while and ESPECIALLY because you develop containers now
    you should be more attentive to what the "other" developers want you to provide.
    "

    You know me, therefore you should know that not having written projects for a year does not mean I forgot/thrown away 10 years of strong experience in that field, and othes like research I have done.
    Instead, I am gonna use my experience in different CS fields to make the technology more helpful and usable (and less theorical) for applications developers.
    However it is not easy, I have to admit.
    Sometimes, beautiful theorical models fall in their implementation.
    But that is another story... :)
    -Gianni
      




  69. With all due respect[ Go to top ]

    Gianni,

    "Sometimes, beautiful theorical models fall in their implementation"

    A theoretical model is not beautiful, but at least is not a good one if it can't be implemented.
    I guess the relational model doesn't need to prove anything anymore and it is a good theoretical model.

    By the way, OO can be a CS research field but nobody that I'm aware of came up yet with a sound theoretical model for OO, because OO people are very well entrenched in implementation.
    Much less for the EJBs :)

    So I guess sometimes they fail to see the bigger picture.

    >Coexistence is also possible!

    No, not coexistence, they must support and complement each other.
    I think I proved why relational model makes room for EJB model (it doesn't make room for a general OO model but EJB is way behind a proper OO model),
    while if I am to program folllowing the Entity EJB model I fall in a terrible small subset of the relational model.

    This is the MAJOR flaw of the current specification.

    And if you think beautiful theoretical models can fall in their implementation, you'll be the first to see what implementation problems poses a spec that is thought of especially with implementation in mind !!


    Cheers,
    Costin


  70. With all due respect[ Go to top ]

    Costin,
    "A theoretical model is not beautiful, but at least is not a good one if it can't be implemented. "
    I disagree, but I respect your opinion

    "I guess the relational model doesn't need to prove anything anymore and it is a good theoretical model.
    "
    The discussion was general. Why do you put relational model anywhere, anytime ?? Is it your vision so limited that you see only relational models ?

    "
    No, not coexistence, they must support and complement each other."
    How can you have support and complementation without coexistence ?

    "
    I think I proved why relational model makes room for EJB model (it doesn't make room for a general OO model but EJB is way behind a proper OO model),
    "
    You did not prove anything, believe me!!!!!!!

    "
    while if I am to program folllowing the Entity EJB model I fall in a terrible small subset of the relational model.
    "

    So your statement is that the EJB model is a subset of the relational model... Can you confirm it ? I wanna make sure I am not having a nightmare :)


    "
    And if you think beautiful theoretical models can fall in their implementation, you'll be the first to see what implementation problems poses a spec that is thought of especially with implementation in mind !!
    "
    Never said EJB model was perfect, did I ??

    -Gianni

  71. With all due respect[ Go to top ]

    I think I'll stop right about now, just one more response:

    "I'll use them when they'll get out of this "everything is an Object", "every relation is an OO relationship" paradigm, to make room also for the guys who don't need to load a whole object to update one field or to calculate a sum"

    Costin, you might as well forget about ever using EJB. Or Java even. They're never going to move out of that paradigm. Objects as we currently know them are disjointed from the relational model and will remain that way until a successor language to Java comes along.

    From my perspective, almost all of those operations you mentioned would normally be flattened to pure SQL -- they wouldn't involve object hydration, unless one was purposefully being naive (i.e. they had an O/R mapping tool like TOPLink that does auto-SQL generation and weren't yet ready to optimize their system)

    Secondly, finder methods have generally been useless (and continue to be) with bean managed persistence. But, under the pfd2's CMP spec, they actually become somewhat useful again now that the performance characteristics are much improved. Though they lack dynamic query support....

    And yes, I did look at Friday's link. It's very intriguing. But it's years from becoming a commercially successful product. To build one requires enormous resources, time, and dedication -- and risk management.


    So, generally, your non-OO interests have not been addressed because they're effectively out of scope for EJB, and Java in general, for that matter. It seems you're looking for a new programmatic model for relational data manipulation that goes beyond what current SQL extentions (PL/SQL, T/SQL, etc) provide. I agree, this is a noble goal, and should be a focus of future innovation. But such innovation will not come from Sun, most likely. It will come from the fringes, as it always has.

    Your continued flaming of Sun because they're not blazing new trails is somewhat disappointing to me. A lot of your arguments have been very thought provoking and I've usually enjoyed this exchange, but I find as we continue this train of discussion your views are becoming more and more hard-line and less malleable to dialogue or openness. So, it's time to give this thread a rest...
  72. With all due respect[ Go to top ]

    "So, generally, your non-OO interests have not been addressed because they're effectively out of scope for EJB, and Java in general, for that matter."

    "Costin, you might as well forget about ever using EJB. Or Java even."

    Preety inflamatory considerations don't you think ? I don't use EJB now but my hope is that I'll be able to use them down the road.
    I do use Java everyday and database theory is one my biggest hobby.

    Well, if Sun stewards enterprise java against database theory and only based on OO "practicalities" I'll rest my case and mind my own business.
    After all the Java standard edition is good enough to use right now and promise to be better in the very near future.
    Unless you land in some company where the management has been brainwashed with EJB marketing, and that's where I don't want to leave the EJBs alone without spreading the word out that they are still imature.

    And don't pretend you're not aware of that.

    >Secondly, finder methods have generally been useless (and continue to be)
    So if it doesn't affect you, it can rust in there ?

    >Your continued flaming of Sun because they're not blazing new trails is somewhat disappointing to me.

    Yes, sure. They don't blaze new trails but they make existing ones impracticable.

    Anyway, I noticed that the thread has been linked by the JavaWorld, and considering you probably consider me detrimental to the cause, I'll get out of here and even ask Floyd to remove our polemics if at all possible.

    "Whoever's not with us is against us"

    Gianni, if you really want an exchange of ideas and didn't do polemics just to help the cause we can always exchange emails, as well as honour my invitation to come to the thread exactly below this one, where you might want to help us in finding out why EJBs are components.

    Cheers,
    Costin

  73. With all due respect[ Go to top ]

    "I do use Java everyday and database theory is one my biggest hobby."

    Database theory is a hobby of mine too. :-)

    "Yes, sure. They don't blaze new trails but they make existing ones impracticable. "

    Yes, that's arguably correct.

    But who has *ever* made it practical to create a full fledged programming language & platform that was intimately linked with the relational paradigm? Most attempts have been "tack-ons" such as PL/SQL. The object oriented extentions to such languages are rather primitive as well.

    If I use embedded SQL in C or COBOL, I have the same shackles as EJB -- I have to deal with 2 different type systems, 2 different language models, and 2 different realms of thought: one of set theory and one of structures & pointers.

    Can and should we make our language's data structure support more based on relational theory? Almost certainly.

    But if you're going to claim that EJB makes relational theory impractical, you might as well look at every other mainstream programming paradigm. They all have the same fundamental problems.

    (Unless someone has seen a nice marriage in Lisp, Haskell, etc. that I might not be aware of.)

    "whoever isn't with us is against us"

    I don't think I ever implied this... The fact that you're a skeptic generally a good thing as it challenges our assumptions about why we use Java and EJB. The only down side to this is that sometimes I feel that the "heat of the debate" tends to intimidate others into joining the discussion.

    "If you program a system using the EJB Entity model BMP/CMP/EQL whatever you like or all of them then your data access patterns to your relational database is only a small subset of what the relational model is offering you."

    Ahh, the meat! Yes, this is quite true. I'd love a language that would dynamically create an object for me based on a query definition, and I'd love to be able to dynamically attach behavior that on an as-needed basis.

    But to get to this point, we're effectively going back to LISP in the ability to move transparently between representation and process. We lose strong type checking. We gain complexity. It's probably the future, but it's a ways away... the mainstream (Java and EJB's target audience) aren't ready for this.

    For now we either use "dumb objects" to auto-map rows (HashMaps, ResultSets, etc) or "smart objects" with a manual mapping such as that specified by EJB's entity beans and CMP.


    "Also the declaration that the relational model makes room for the EJB model is self evident because you usually use SQL to "persist" your entities and there's no impediment in the relational model that would prevent you to implement all the EJB specs. "

    Except that in practice the relational model means SQL and procedural SQL is the bottleneck in terms of what it can express, how easy it is to maintain, etc. Chris Date has been hitting on this for years.. the whole ODBMS vs. RDBMS debate could have been resolved if we just had a better set manipulation language.

    Language influences thought to a high degree. To a relational adherenet, programs are merely processes to operate on sets of data. To an OO programmer, a database is merely a bucket where I can save my objects. I think it's clear the relational model has much more power in terms of manipulating sets. I think it's also clear that object orientation has much more power in dividing up computational responsibility & manipulating individual data structures.

    I think what's not clear is how to make these disjoint strengths work better as a whole.

    "Of course Stu could say here that the subset of data access patterns that Entity EJBs projects to the rdb could be the best one, and I shouldn't need anything more ... "

    No, I wouldn't say that, and I'm sorry if I misled you to think that was my position.

    I think the entity EJB model is a primitive, yet improving form of encapsulating state-intensive business operations and automating the persistence of such objects. I think there are better models that are much more inclusive of the relational model (and I've mentioned them numerous times: TopLink and WebObjects' EOF.)

    I think that you would benefit from looking at when either of those aformentioned products offer to see where entity beans most likely will be heading. The subset of relational functionality offered by these tools is quite useful.
  74. With all due respect[ Go to top ]

    Hi Stu,

    I'm glad that we could continue our discussions.

    " Chris Date has been hitting on this for years.. "

    So, you dare call me a database fanatic/fundamentalist/bla bla, and then cite C J Date's arguments in your support ?
    One could only imagine what THE database fundamentalist C.J. Date would have to say, should he bother himself to analyse this Entity/CMP/EQL enchilada ...

    "If I use embedded SQL in C or COBOL, I have the same shackles as EJB -- "
    No, not by far, you're totally wrong here, the preprocesser will strongly enforce type mapping and you'll have full expression power with regards to your database.

    "But if you're going to claim that EJB makes relational theory impractical"

    You're totally wrong again, I'm not claiming that EJB's make relational theory impractical, I claim quite the opposite.
    Because Entiy EJBs / CMP/ EQL concepts so chose to ignore the relational model they are themselves in the foul play situation.
    I don't think there's anything that could make relational model impractical just because Sun so said it.

    Now instead going on with this OO/Relational debate, which should be done in another thread methinks, I'll be more explicit on my statement that Sun made existing trails impractical.

    So, of course you could use Session beans as facade to SQL wich is a perfect solution and stop debating the Entity non-sense, and as Rick pointed out if you want to view your data as objects you can do so at your sole discretion.

    But if it was that simple why do I make that much fuss about it ?

    Because of political reasons.

    Entities make up at least 50% of the specs, Sun is pushing them App vendors is pushing them.
    App Server cost that much especially because they implement the whole entity enchillada.
    I'm not aware of any app server that would offer you a half cost license with removal of Entity Beans, more, if I'm not mistaken Entity Beans are mandatory now in order to achieve the J2EE certification.

    So, if you are not a project manager or a CTO or if you don't have a project manager and a CTO who trust your professionalism, you just simply could not avoid using Entiy Beans because of political reasons.

    So, Sun is gravely at fault for several reasons:

    1. Not realizing that distribution, declarative transaction management, and object persistence are orthogonal aspects.
    They could simply have made these totally orthogonal aspects separate projects,
    and respect the elementary principle of modularity.
    Now they bundled them in a 500 pages monster and everybody can see the results.

    2. Killing competition and innovation.
    They now dictate a "standard" that every java app server vendor will have to implement.
    Please take notice that the EJB standard at least is biased towards imllementation issues, therefore is killing competition.
    No matter what marketing papers may say there aren't too many good ways to implement an EJB server.
    Innovative companies like ATG, Gemstone and many others now have to abandon their proprietary and GOOD ways, or double their efforts in order to stay alive under Sun's marketing pressure.
    Do I need to mention NetDynamics which until 1999 was THE most advanced app server AND development tool (it is still present in JDJ Best IDE poll as we are speaking),
     and after being bought by Sun is now on a dead line because Sun realized it didn't fit in their J2EE as THE ONLY WAY vision.

    3. Putting political and marketing pressures on end developers to make them accept Sun's way of doing things as THE way of doing things.
    I and my colleagues at work are joking that Sun has a vested interest into making their specs dumb, because they make their profits from hardware afterall.

    And I could continue, but I shall stop here.
    I guess these 3 counts are enough.

    Cheers,
    Costin
  75. With all due respect[ Go to top ]

    Rick,

    "bloated and unnecessary"? Which part is the unnecessary part :) .. I think there needs to be an O/R mapping standard to help foster that market along. Perhaps killing CMP altogether and just promoting JDO might work (which many on this site, including Floyd, have advocated)?

    Most of your complaints about finder methods are true in the BMP case, but it's usually the *implementation* of a CMP finder that makes it slow, so if you used something that supported SQL optimized hints, like TopLInk, there really wouldn't be a problem, would there? Should EJB standardize SQL optimization in finders? I think not...

    Furthermore, I think you're exaggerating the case with development productivity. Creating the interfaces is not *that* big of a deal assuming you have a tool to do so quickly (some IDE's do this today)... (and if pfd2 gets approved such things will proliferate :) .. this isn't an EJB problem so much as it is a Java problem, being strongly typed.

    So, while I think Entity beans are inadequate, I think there's *some* merit there...
  76. With all due respect[ Go to top ]

    Stu,

    Entity Beans are unnecessary in order to establish a good persistence framework. This is in contradiction to what is believed by many about EJB. Many believe you cannot have one without the other. Many believe that you cannot even develop good Java systems without EJB.

    When in fact, the Java community has been developing good Java systems well before EJB was even around.

    I'm not saying at all that EJB should support native SQL optimizer hints. I'm saying that it is a weakness. I'm also saying that EJB (both CMP and BMP) are weak in terms of their overall design. And what I say about developer productivity does in fact hold. Entity EJBs are cumbersome to write. Cumbersome to deploy. They do not scale well in terms of project size and scope. They do not seem to fit all Java situations. This is also a weakness. And a costly one.

    Creating the interfaces is a big deal. If you *have* to do it at all. Why create an interface to begin with? Doesn't it seem a tad silly to create an interface? What about inheritance? Does Entity EJB support good OO design concepts such as inheritance and polymorphism? Strongly typed? I won't even get into the issues where Java (and especially EJB) lack in that arena. I can break a distributed EJB Java system with a single incorrect cast from an Enumeration. But it still will compile. Very weak.

    I could go on and on and on and on, but I won't. I will go back to my original point.

    Companies can still develop good, scalable, robust systems without using Entity Beans, and without the drawbacks associated with them.

    Regards,

    Rick





  77. With all due respect[ Go to top ]

    Stu,

    I'll ask you a question and ask you for a straight answer.

    Do you think that distribution and persistence should be bundled together ?

    That's what I and Rick were arguing, that it shouldn't.

    We are happy if we use stateless session been that are simple and non-controversial and provide certain aspects like security management (tentatively at least), transaction management and distributioin management.

    Rick will want to use a persistence framework, I will not and only create objects from the data I retrieved only when I feel that I need to.

    But from a object persistence point of view Entities are quite lousy and you admited that at least partially in several occasions.

    But they are tightly bundled in the whole enchilada when they shouldn't be.
    Now Sun has two diiferent persistence projects, the JDO and the distributed Entity and the local Entity.

    Please note that if you use a persistence framework behind a stateless session bean you have all the goodies in the EJb spec and you don't need to use Entities any further because they effectively offer you nothing more in terms of security, distribution and transaction, and in the persistence aspects they are lousy.

    So the solution to this whole confusion is very simple if Sun has the vision and/or courage.

    Take the Entities out of EJB spec, and unify all JSR efforts with regards to persistence in a separate effort because persistence is a totally separate aspect.

    It goes with the basic principles of good programming that separate aspects hsoul be treated separately and not bundled and intertwined together.

    Otherwise you could argue that Entities are not the perfect persistence framework,
    but they provide security transactions, distibution, load balancing, failover and many other blas.

    Ther's no but, the above argument is false and it goies against the basic principles of software modularity.
  78. With all due respect[ Go to top ]

    Costin,

    1) Regarding modularity: the "distribution" part of EJB is already modularized (RMI), so EJB's not doing anything bad there. As for persistence, yes, it is definitely arguable that it is orthogonal to what EJB should be about.

    2) Killing innovation, yes. Killing competition, certainly not.

    I mourn the lack of app server innovation because of J2EE. That goes without question. But I guess people were *afraid* to innovate when you had this behemoth known as Microsoft Transaction Server looming on the horizon. So EJB stole some of the good ideas from MTS .. in hindsight (to me) it turned out that MTS really wasn't much of a threat since programming COM in C++ wasn't really something enterprise developers wanted to do.

    A standard presents a unified front to the market place, it eliminates confusion. Conforming to one hurts technological innovation, but it HELPS a marketplace to stabilize. Customers do not want to have to deal with 15+ proprietary application servers, it's just too difficult to find/train people for them, it leads to skyrocketing service costs and lock-in.

    One can technically claim J2EE is just another form of lock-in, but it appears that customers are more comfortable with this kind of lock-in than the other kind.

    As for NetDynamics, I used it in 1998 and wasn't overly impressed with their server OR development tool (I also was involved with a contract doing QA on that tool, and wow it was buggy). I was a GemStone fan, though.

    3) Is there something wrong with promoting conformance to a standard? Certainly there are trade-offs. Suggesting that Sun deliberately keeps their specs dumb to profit from hardware is very inappropriate.

    Back in 1998 - 1999, the market was *very* skeptical of EJB catching on, and the introduction of J2EE was a joke... IBM wasn't going to follow it, some vendors (I worked with one vendor's senior architects on a contract back in 1999) were very pissed at the holes in EJB and were going to branch & do their own innovations.

    But then, something happened. *Customers* bought into EJB and J2EE. It became a brand not for vendors to cooperate on, but for customers to latch on to. Vendors weren't given much of a choice. IBM capitulated. BroadVision is being sued by investors partially BECAUSE they're not J2EE compliant. BEA WebLogic is #1 not due to technical superiority, but the speed at which they release spec-conforming products.

    J2EE is a brand that customers wanted. Sun was right, they read the tea leaves appropriately. techies like us may want innovation, but it doesn't always jive with business demands.. we sometimes get ahead of ourselves.

    Doesn't bother me one whit. J2EE is fine for now, and in due course there will be a better alternative to EJB, J2EE and even Java.

    Now, regarding your second message:

    Distribution + persistence definitely can be bundled together, as the means of distribution will influence how objects are retrieved and constructed from a persistent store. There are many interlocking concerns: how does one ensure identity across address spaces, for example? One needs a model that carries over to the distribution space.

    Now, does EJB do this right? Of course not. People were weeping with laughter on the webobjects-dev list when they first read the EJB specification. I think EJB came out of the world of CORBA -- they wanted to make distributed objects scale. And since they were in a position of power to influence others, they decided to throw in object persistence... but they weren't experienced with this, and they messed it up horribly. CMP 1.x was ridiculous. 2.0 pfd2 looks much better. Rick would argue the interfaces make it unpalatable, but I think that given a sufficient tool the interfaces aren't too hard to use (and they're a necessary Java evil anyway).

    Certainly one can use a Session bean + persistence framework and get all the advantages of productivity that entity beans are supposed to provide but fail to. In fact, I've done this projects. And I've seen Martin Fowler & Alan Knight's talk at JavaOne 2000 suggesting this very thing. I agree with it. And I believe that Apple WebObjects 5 is going to take a similar approach to their EJB support... transparent use of their persistence framework inside an existing EJB server, and transparent exposure of regular EOF objects as EJB's (based on their WWDC 2000 talk).

    Anyhow. It's been enlightening.
    :)
  79. With all due respect[ Go to top ]

    "As for NetDynamics, I used it in 1998 and wasn't overly impressed with their server OR development tool (I also was involved with a contract doing QA on that tool, and wow it was buggy)."

    Well, sorry about your experience.
    I guessed you couldn't have liked because it was NO OR at all, it was a purely relational tool and in fact it wasn't too OO in the style of programming, however their object framework was impressive.

    But the whole purpose of the framework was to let you construct SQLs and Stored Procedure calls effectively, and after that take the data and pass it to the HTML page.
    Not to mention about the Connectors architecture that you see now in J2EE is taken directly from NetDynamics and ND had it since 1998.

    The fact is that it was a big production capable app server ever since 1997 (can you tell me who was production capable then), and as to what regards developer productivity in Web applications, there's no match as yet.
    I might recommend you huge production sites (literally huge load) that are still running today on ND versioin 3 (1997).
    The only reason for Sun to take it down was that it was pretty much incompatible with their narrow vision for J2EE.

    " There are many interlocking concerns: how does one ensure identity across address spaces, for example?"

    Yes, OO folks like you want to have things complicated.
    At the end of the day you'll want the database to manage transaction and if you want to take it in your hands in the middleware you might be in for unpleasant results .
    Some app servers do want to play with transactions,locking, and app server in the middleware, no matter that database does it anyway a second time, and the database does it better.

    So no, as long as you're in a transaction and you get the data from your database and put back what you've updated, you don't want to complicate things !!!
  80. With all due respect[ Go to top ]

    Let me add that killing innovation also kills competition.
    There's no question about that.

    Sometimes you can have standards without killing innovation.
  81. With all due respect[ Go to top ]

    Costin, See next message.Rick,I guess there isn't much of a real disagreement here. People definitely are naive in their assumptions that entity beans are *required* to do good Java systems or persistence frameworks. They are definitely not. I do believe the idea of a "persistent" distributed component with pluggable object/relational mapping has merit though, and have some (not much, but some) hope that entity beans can be reformulated to do this appopriately.Entity beans are weak in their design, yes. CMP 2.0 pfd2 is less so, IMHO, but BMP still is, and CMP 1.1 was ridiculous. One needed an add-on tool that extended the spec to do practical CMP.Why create an interface? Surely you recognize that it's the same problem as any server that uses declarative configruation, like COM+: there needs to be a means by which the server can "hook in" to each bean invocation. EJB uses proxies/stubs ... The interface is the means to allow this polymorphism to occur. We can't just call directly from bean to bean, we need something similar to "aspect oriented programming" when we're dealing with declarative method-level security and transaction settings amongst objects.

    The question really is whether your fine-grained persistent objects really need all the associated EJB services. Costin argues no - they're orthogonal. And given the dearth of good CMP implementations it probably is true that they should try to get at least "one" standard right. Allowing the persistence manager to work *with* the EJB server is a difficult thing. EJB was definitely over-ambitious in trying to come up with both a persistence standard AND a distribution standard.
    Stu
  82. With all due respect[ Go to top ]

    Stu,

    Can yopu detail more what are the Services you need from EJB layer to work behind a Session Bean, and you don't have them unless you're using Entities.
    I guess none

    Simply by connecting to datasources you already connect to transaction management services, security is checked once at the entry in the session beans, and you don't weant to check it all over the stupid place, what else Stu ???

    Don't mention to me the life-management cycle ...

    By the way, I solved the "stupid ejbFind" problem.
    So BMP might be less of a problem, but there's no excuse for not having a mechanism withint the spec.
    Are those people thinking in there or what ?

    I'll post the pattern here when I'll have time to test it because I'm happy not to work with EJB.
    So now I can say BMP Entities suck less but they still do :)

  83. With all due respect[ Go to top ]

    Stu,

    I am mostly in agreement with your response.

    For me (and many others), I think the Entity EJB spec was really poorly done. For me (and many others), the _entire_ EJB spec was really too sweeping of a specification. And was not needed by the industry. We were getting along just fine without it.

    And I do feel that the EJB propaganda/marketing had serious consequences. So many companies bought into the technology... only to realize that really... it had a poor ROI (return on investment). The great majority of projects have no need for all of these 'services'. To require us to purchase them is really somewhat obtuse, IMHO. The great majority of projects just need instance pooling, connection pooling and transaction management. Not all of these fancy features that almost nobody uses... or knows anything about.

    I think the EJB specification is not unlike any other "it does everything but wash the dishes" type of solutions. They look really good from the outside, but when you get into the details, it costs you a lot more than you planned.

    I personally have fought tooth-and-nail to get people to NOT adopt this standard -- not to jump on the bandwagon. But too many people took the attitude of : "If Sun says it is good... then it must be." Which is really the wrong approach.

    So many people have abandoned "best practices" just to ride this wave. A lot of people thought I was crazy for not being an EJB advocate -- and some still do. But the industry is learning the lesson the hard way, I think.
    More and more, companies are using Costin's approach for the persistence layer... or using other more efficient, faster, and easier to use persistence frameworks or tools. And rightly so.

    Instead of pushing EJB... I wish that Sun would better concentrate their efforts on more meaningful efforts... such as improving the Java language itself. Java still needs a lot of work. Especially in the area of parametric types and genericity.

    Let the rest of the industry innovate new products to fill the needs for persistence frameworks and service modules. And let the system architects and developers establish good patterns and interfaces to piece these modules together.

    IMHO, _that_ is the best solution.

    Regards,

    Rick









  84. With all due respect...[ Go to top ]

    Hello everyone,

    I've read this entire thread and I'm going to jump on Costin's bandwagon here. This is a quality post. Mainly... it has a key sentence that I've been preaching since this whole EJB craze started:

    "Yes, sure. They (Sun) don't blaze new trails but they make existing ones impracticable."

    This persistence framework for EJBs (to me) is nothing but a marketing tool for Sun. Bloated and almost completely unnecessary.

    You know... life did exist before EJBs. We have excellent persistence design patterns for abstract data object frameworks that support good ACID transaction management as well as excellent performance. And _most_ of them don't require implementing tons of interfaces, code bloat, application server dependence, or any such ilk.

    To me, entity beans are inadequate. They really only provide a usable interface for very simple DB relationships. But the second you go into one-to-many (dependent objects), or many-to-many relationships (inter-dependent objects), they fall apart.

    Worse yet, they perform VERY poorly. The 'fetchByXXX' is particularly bad in dependency fetches. Optimizing an entity bean for speed is incredibly difficult and cumbersome (for BMP) -- and if you are using CMP, it is almost impossible. Many SQL optimizations require creating non-normalized queries that generate many-to-many result sets. Many optimizaitions require native database functions -- such as optimizer hints.

    There is a large list of 'holes' that the EJB spec does not fill. Nonetheless, I do not think it a reasonable nor adequate fit for the persistence layer. IMHO, It creates WAY too much development overhead and cost. It creates an unbelievable amount of unnecessary code bloat. And it really isn't scalable -- large implementations become slow and sloth-like... while it drives the price up for small projects considerably because of all the extra code/software/maintenance.

    Give me a good SQL code generator and an O-R mapping tool (like TopLink) and some decent transaction management any day... over EJB.

    Well... off the soap box...

    -- Rick
  85. With all due respect[ Go to top ]

    just bear with me a little non-controversial responses to Gianni.

    "How can you have support and complementation without coexistence ? "
    I guess you know what I meant.
    If they only coexist (OO and relational) it's not good enough, it is even bad because you have the "impedance mismatch", the "big divide" and other many bla blas.
    They have to coexist and support and complement each other.

    "So your statement is that the EJB model is a subset of the relational model... "
    Let me be more clear:
    If you program a system using the EJB Entity model BMP/CMP/EQL whatever you like or all of them then your data access patterns to your relational database is only a small subset of what the relational model is offering you.

    Also the declaration that the relational model makes room for the EJB model is self evident because you usually use SQL to "persist" your entities and there's no impediment in the relational model that would prevent you to implement all the EJB specs.

    Of course Stu could say here that the subset of data access patterns that Entity EJBs projects to the rdb could be the best one, and I shouldn't need anything more ...

    Cheers,
    Costin
  86. Also..[ Go to top ]

    Stu,

    I'm glad your happy to find your OO concerns addressed by the new spec, but you'll have to admit that my "non-OO" concerns are totally disregarded.
    More, the spec goes aginst them.

    So for me the only valid way to program EJBs would be to use stateless session beans with SQL (of course I could have objects on top of my relational data, but when I choose to and consider appropriate ).
    But the fact is the high cost of EJB app servers is only justified by efforts to implement Entity Beans, so I'm more than happy not to use EJBs at all.

    I'll use them when they'll get out of this "everything is an Object", "every relation is an OO relationship" paradigm, to make room also for the guys who don't need to load a whole object to update one field or to calculate a sum, or who don't need to return primary keys from an ejbFind() and all other cool stuff like that (I guess you noticed the stupidity of ejbFind is still there).

    "We could turn that argument around...".

    No you could not the relational model makes you room for the case where you load all data at once layer it out in your fancy object, do whatever you feel like with them while you're in a transaction and you use ejbLoad()/ejbStore().

    While the "EJB way of doing things" is clearly a small subset of relational way of doing things and not the other way around.

    As to the data vs objects war, it is not a war.
    I'll respectfully remind you that data will stay in database or archives more than you OO middleware but that's not the only point.

    The main point is object=data + behaviour.
    OO languages and techniques evolved up to the point of saying object = (our way of layering and accessing data) + behaviour.
    As you know relational model doesn't tell you anything about what you do with your cached data within a transaction so it makes room for OO foos like you.

    Object models and EJB models is clearly more restrictive so it is a limited narrow way of doing things.
    QED.

    Anyway if you studied the reference I given you Friday probably you know by now there are models that include both relational and OO models so this OO vs relational debate is pretty much because the industry is lazy enough and falls under the "not invented here" syndrome.

    Cheers,
    Costin
  87. Actually, only unintended side effects are bad!
  88. Gianni,

    I'm quite aware of the amount of IMS and/or VSAM data still in existance. SAP too. But the *amount* of data doesn't relate to the number of implementations out there. IMS, for example, has only between 10 and 20 thousand deployments throughout the world according to IBM's website, if I recall correctly.

    My suggestion is that most people using EJB will be using an RDBMS, so that while EJB shouldn't be biased to an RDBMS, it shouldn't sacrifice its performance, either.




    Costin,

    A couple of points:

    a) EJB 2 is to encourage separate evolution between "internal" components vs. "external" components. Or, in other words, "facades encourage re-use". This was something Vlada Matena has been suggesting since the EJB 1.0 days, and dependent objects were an initial stab at that. This is why we don't expose CMP relationships in the remote object - it breaks encapsulation.

    b) I think we're in agreement about the problems with embedded SQL.

    Though I would note a query API would not provide strong type checking either, since one still has two different type systems. A pre-compiler with database connection like SQLJ can do strong type checking, but has the impedence mismatch problem.






    c) In this recent (enlightening, I might add) discussion of how EJB QL might take us back into the hierarchial/network database days, it made me think of all the old anti-ODBMS arguments, but I just realized an interesting point:

    EJB doesn't bring you back to those days because it is merely a *view* into your data.

    Meaning, your arguments are effectively that EJB QL corrupts the relational model, but this is effectively untrue - if you're using an RDBMS underneath, the relational model is still fully intact underneath EJB providing its referential integrity and data constraints, indices, joins, and all the wonderful things we've come to enjoy about it. One can still call stored procedures for set-based transactions, or rely on referential integrity exceptions, depending on how good your CMP implementation is (TopLink, for example, is quite good about these things).

    You seem to write off the utility of a graph-based data model in favor of a set & tuple based model. I reject that in favor of an approach that provides a graph-based VIEW (i.e. application biased data model) into a tuple / set based data model (i.e. general data model).

    EJB provides this using CMP, EOF and TOPLink provide this with their O/R mapping tools and query api's, and Oracle provides this with its ORDBMS "object views", etc.



    Graph theory and set theory both can provide excellent maintainability and performance when leveraged in appropriate ways. For instance, the whole reason we use Java for database systems at all is because PL/SQL, T-SQL, etc. is because they tend not to have any forms of advanced dependency management and any since of directional relationships - something that abstractions and polymorphism give you.

    The notion of a Collection abstraction is quite powerful when dealing with business entities. It allows one to work with Set abstractions, performing intersects, differences, and unions in the target host language. These are all relational concepts. But beyond, this it's also a means of leveraging a graph to traverse interelated concepts such that you can use your objects and components as a primitive frames & slots based system (which is effectively what most moderate-complexity OO business systems are anyway).







    One thing I do somewhat agree with is the notion of direction in a graph model. An undirected graph is usually necessary for integrity reasons and most object models are only directed. This is another area that WebObjects' EOF shines -- the EORelationshipManipulation service effectively makes the "base case" for all persistent object relationships to be undirected, using the addObjectToBothSidesOfRelationship:WithKey method to relate any two objects, thus ensuring integrity (but keeping the use of directed relationships open).
  89. Stu,

    > Meaning, your arguments are effectively that EJB QL corrupts the relational model, but this is effectively untrue

    Wow, yes of course it doesn't corrupt the underneath relational database, god forbid that !
    It doesn't have the means to do it
    But if you're using CMP "relationships" and EQL is just that you can't access the relational data, but through twisted non relational ways as I pointed out.
    We're accessing relational data in the same way as if we had IMS behind the scenes !!

    On the other hand you'll this idea of encapsulation might be worth it if I choose to not if I am imposed to it.
    But effectively "relationships" are second class concepts of the entity world, although the vast success of the relational databases might suggest it would be wise if they were first class.

    Cheers,
    Costin
  90. I fully agree!!!

    If we are pulling out a lot of objects, we are
    going to have to sort the collection ourselves,
    instead of simply adding an "order by" and passing
    that to the database.

    What is Sun thinking here!!

  91. I have a question. It seems like 99.9% of the app servers place the Home stub into JNDI. Why isn't there an optional tag in the standard ejb-jar.xml for this? The "minimum" vendor specific descriptor has us put in the jndi-name (e.g. <jndi-name> in the weblogic-ejb-jar.xml), and some servers will assume defaults (e.g. JBoss).

    They don't have to FORCE this tag, but it would be nice to have it in the standard as an option. Any reason not to do this?

    Dion
  92. hi -

    Right now, if you are in a cluster (say using WLS), if your servlet tries to use an EJB WLS will try to grab it
    from the same machine, and will use call by reference (if you have <enable-call-by-reference> setup).

    Now, with local interfaces, will the server be able
    to do things like "check for a local bean first, else
    use remote"?

    Could we do this kind of thing via a pattern? E.g.

    try to get a local bean
    if the bean isn't available, try to get a remote bean

    Do you think people will use the approach of having an EJB implement both the EJBObject and EJBLocalObject?

    Dion
  93. Also how can you seemlessly go from working w/ remote
    objects to local ones. It seems a pain that you have
    to deal w/ RemoteException 's for remote objects.
    I could see wanting to quickly make a local object remote
    without having to change all code to check for a RemoteException
  94. Dion,

    The spec says that you should keep the local and the remote interfaces (in case you have both) totally separated.

    Of course they could have put as well n interfaces instead of 2 just like in COM.