Discussions

News: New Life for EJB: A new choice for EJB 3.0

  1. New Life for EJB: A new choice for EJB 3.0 (77 messages)

    The proposed EJB 3.0 specification defines a new syntax to simplify development but fails to address fundamental flaws in the model.

    We believe we know a better way.

    The documents on this site describe our alternative model and critique both the existing EJB 2.1 spec and the proposed 3.0 spec.

    We think EJB 2.1 has all the required components for building enterprise applications, but its component model is in dire need of refactoring. Accordingly, we have refactored the EJB 2.1 component model, and we find that EJB is now dramatically simplified, as our included code samples will show. There is very little need for annotations and dependency injection in our model, yet application code becomes compact and easy to understand. JNDI lookups disappear, empty callback method implementations are a thing of the past, all interface and method names are clear and evocative (no more wondering about what ejbPassivate() means for an Entity Bean as opposed to a Stateful Session Bean), many callback interfaces are now optional or reduced to markers, etc.

    And all of this with plain Java 1.2 syntax that most developers understand. It imposes no new learning curve with additional concepts.

    We also think the EJB 3.0 proposal is emphasizing ease of development without addressing simplification of the component model itself. This means that the EJB 2.x mess is likely to remain under the covers. Our model is inherently cleaner because it addresses those issues.

    There are also some proposals in the spec that we think are unnecessary and even dangerous. Detached entities are one, and we offer a cleaner alternative using first-class Data Transfer Objects that simultaneously solve the pass-by-reference versus pass-by-value problem without forcing the use of explicit local and remote interfaces. "Magic" or "stray" callbacks are another, where the container calls back any implemented callback method even if the bean doesn't implement the interface. Our alternative is cleaner and safer, because it rationalizes the interfaces to have the minimal number of methods, and many interfaces are now optional.

    Please study these documents and give us your feedback.

    We have received a round of feedback from the spec committee already (which helped us improve our model), and we welcome more such feedback.

    Read: New Life for EJB

    Ganesh Prasad
    Rajat Taneja

    Threaded Messages (77)

  2. Good Job[ Go to top ]

    Excellent Job undertaking refactoring from 2.x.

    The idea of splitting the interfaces for the different Bean types so only relevant methods and most important relevantly named methods would be a boon to new EJB developers and kill a lot of book sales. ;-)

    No more JNDI lookups needs any comment.

    Would like to hear what the spec committee comments are compared to they’re 3.0 draft.
  3. Frankly speaking, as a complete spring and hibernate addict, personally I prefer approach presented in original EJB 3 draft-spec. Well - it's much more sexy :))).

    Artur
  4. Not so cool ...[ Go to top ]

    Frankly speaking, as a complete spring and hibernate addict, personally I prefer approach presented in original EJB 3 draft-spec. Well - it's much more sexy :))).Artur
    Well, if sexy is what you are running after, then Visual Studio .NET is for you, my friend. I don't want to sound like a purist but Java has always been analogous to 'Sound OO design'. No place for intrusive, non-intuitive, not-in-developer's-knowledge-or-control magic. I am not suggesting that EJB 2.x was a
    good OO design, it had its flaws, lots of them. But this is the time to think retrospectively and correct as many of them as possible, right?

    IMHO, 'annotations' and the likes are cool, as long as they follow OO design principles. For e.g. if you don't go by the contract (by implementing SessionBean interface), no matter what annotation you place over your method, the container should not perform callbacks 'magically'. PERIOD.
  5. Not so cool ...[ Go to top ]

    As I remember Java has always been more analogous to "modular programming", but it is not so important.

    I see "procedures" work better than "component oriented programming" on server, how many component frameworks we need to reinvent to prove it ? This stuff is good for UI programming, "portlet" or JSP tag can be a component, but not a "domain object".
  6. Not so cool ...[ Go to top ]

    Well, if sexy is what you are running after, then Visual Studio
    .NET is for you, my friend. I don't want to sound like a purist but Java
    has always
    :) Well, frankly speaking i thought about IoC rather .NET when I was writing
    above. Anyway, if some features of .NET makes some things easier, why don't
    use them? In my opinion such a great idea are annotations. I can't see how
    they makes anything less-OO-designed?
    been analogous to 'Sound OO design'. No place for intrusive, non-intuitive,
    not-in-developer's-knowledge-or-control magic. I am not suggesting that EJB
    2.x
    But all that things, *especially* 'non-intrusiveness' - are what IoC is all
    about. There is no magic behind IoC. Well, in fact IoC is so simple, so at
    first sight it might look as useless idea. When I first read abut IoC thing
    I even thought that it's... stupid - but I changed my mind once I started to
    use this.

    <blockqoute>
    was a good OO design, it had its flaws, lots of them. But this is the time
    to think retrospectively and correct as many of them as possible, right?
    IMHO, 'annotations' and the likes are cool, as long as they follow OO design
    </blockqoute>

    Agreed. But this applies to almost everything - even in pure Java you can
    write code which has nothing in common with OOD. Back to annotations - as
    far as I remember correctly you won't be forced to use annotations in EJB 3.

    Artur
  7. Not so cool ...[ Go to top ]

    :) Well, frankly speaking i thought about IoC rather .NET when I was writing
    above. Anyway, if some features of .NET makes some things easier, why don't
    use them? In my opinion such a great idea are annotations. I can't see how
    they makes anything less-OO-designed?
    Well - you can look at this as code written using two different plains/layers
    So annotations gives you more freedom - but they are really not helping to make things consistent and can easily kill the simplicity.

    For example you can do in traditional OO way:

    class Foo implements Startable
    {
             void start()
             {
             }

    }


    Or using annotations:
    class Baa1 implements
    {
            @Start
            void start()
             {
             }

    }


    class Baa2
    {
            @Start
            void myOwnStartMethod()
             {
             }

    }


    class Baa2
    {
            @Start
            void iHateStartMethodes()
             {
             }

    }



    So what can happens with annotations is that there is more code in metadata layer and less in java layer.
    But total number of lines of code which needed is quite similar.

    Do annotations makes anything less-OO-designed? This is quite hard question - but the answer is rather "yes" then "no".
    We know what object and classes are and we have quite mature methodology to develop them.
    On metadata-layer you are developing some attachments to object and those attachments are used by environment which controls/runs objects. Methods which are used on that layer and rather an extenion to OOP then OOP.

    IMO it is much better to stick to interfaces and pure OO solution as long as they are sufficient.
    But all that things, *especially* 'non-intrusiveness' - are what IoC is all
    about. There is no magic behind IoC. Well, in fact IoC is so simple, so at
    first sight it might look as useless idea. When I first read abut IoC thing
    I even thought that it's... stupid - but I changed my mind once I started to
    use this.
    I don't think that 'non-intrusiveness' is at all important in IoC. IoC is not about 'non-intrusiveness' but rather about the division of competences.
    You are leaving to the container all the wring operations - components are not anymore wiring themselves with other components or services -
    that process is fully under the control of container.

    You probably mean that not-intrusive == less dependent on container.
    If I am right please note that extreme IoC is what makes the things more "intrusive" in the sense you are thinking about it.

    For example if you compare

    class A implements LogEnabled
    {

              setLog( Log log )

    }

    class A
    {

             Log log = LogFactory.getLog(...)

    }


    You can use second class more easily outside the container and it hasn't used IoC for obtain the access to log system.

    So probably you will think about the second solution as less intrusive. It is indeed less intrusive ... thanks to the fact that IoC was not used.
    The question is if it is better becouse of that.


    Michal
  8. Not so cool ...[ Go to top ]

    IMO "traditional OO way" or "OO design" in not a good motyve to accept or to reject some solution.

    BTW "interface" is an COP concept, it is metadata to define contract, so there is no major difference between "@Start" and "implements Startable", it is the mater of taste.
  9. Not so cool ...[ Go to top ]

    IMO "traditional OO way" or "OO design" in not a good motyve to accept or to reject some solution.
    Did I say that something should be rejected:)? I just made a remark that annotations = code in different "plain" but total number of lines of often going to be the same of bigger. Just the code will be differently written

    if we will make Startable interface bit more complicated - annotation based solutions will require even more code:

    interface Startable
    {
        void start();
        
        void stop();
    }

    class Foo implements Startable
    {
        
        void start()
     
        
        void stop()

    }

    compared to:
    class Foo
    {
        
         @Start
        void start()
     
         @Stop
        void stop()

    }

    or
    class Foo
    {
        
         @Start
        void hhhhhh()
     
         @Stop
        void hggjjjjjh()

    }


    Anything which mandates such diversification is imo not a good idea.
    BTW "interface" is an COP concept, it is metadata to define contract, so there is no major difference between "@Start" and "implements Startable", it is the mater of taste.
    Interface is a concept witch exits both OOP and COP.
    But it has different meaning in case of both domain.
    What you call a "contract" = Component Specification = Many Component Interfaces. One Component can have many interfaces

    In Java world for defying component interfaces we are using both java code and
    externa metadata and it is only a question of proportions how much java code will be used and how much metadata (annotations are just providing part of it).
    Some metadata can be places in java code - e.g contructrs in pico or methods starting with "testXX" for junit tests are example of that.

    So I agree that difference between "@Start" and "implements Startable" is a question of taste. My taste tells me that too many annotation = something ugly

    Michal
  10. Not so cool ...[ Go to top ]

    As I understand annototion are for contract with development tool, it can be "@Todo", "@Depricated", "@Version", "@Query", ... .
    It is usefull to for code generation parametrisation.
     COP tools generate interface implementations too, but "interface" as concept is for client, "interface" as language feature is designed for contract. It is not broken and probably your taste is better :)
  11. Not so cool ...[ Go to top ]

    Interfaces are fine. Annotations are fine too. A problem, however, does exist. It arises when people start to use one in place of the other.

    An annotation is more of a 'Dependency Injection' or 'Aspect Weaving' construct. You can use it for documentation (like javadoc) if you consider documentation an aspect of your code. Likewise, a J2EE++ container can supply annotations that developers can use to weave aspects like Authentication and Persistence to a component's core functionality (viz. @authenticate, @entity). All this is fine and dandy, and sexy ;-). But just because my component happens to have a method named after one of the lifecycle interface methods, the container should not be allowed to break the rule (assume more than it should) and start perform callbacks using that method. It is both unpredictable (read: against 'java/oo' policy) and ugly.

    Unless I implement a lifecycle interface and therefore declare that I am interested in them, I don't want my container performing magical callbacks. Now, I can also declare the same interest using annotations, but then there should be no strict naming guidelines. My method can have any name and any signature, and just with one annotation, I would love to see the container performing some magic then. In this, I agree with one of the earlier posts, <b> ONE WAY OR THE OTHER PLEASE </b>.

    Having said that, after a while of argumentative analysis, I agree that it is a mere matter of taste whether someone wants to use annotations or interfaces for marking meta-data info. The two lobbys, I guess, are:

    1. The cool ones who want to use annotations, because it lets their code be free of any extra dependencies. Classes behaving like super-components inside a container, and Plain Old Java Objects outside it. They believe annotations and the likes can completely replace, the good old programming concept and practice called 'contract', which was always a good thing because it increased cohesion and reduced coupling. They view this increased cohesion as a 'dependency' that can (and therefore should) be removed.

    2. The more pragmatic ones, who like annotations but only when they are used in the right places. They support aspect weaving as a fine phenomenon which is definitely going places, but they criticize annotations when they are used like a replacement for plain old interface bound contracts.


    You know where I belong!

    aXe!
  12. Excellent..am indebted[ Go to top ]

    Liked the laundry list of litanies.They are absolute truths.
    It just proves why EJB's only serve the purpose of selling app server,and nothing else. I hope your article gets noticed ,so that i can keep my head held high when i face an interview next time and proudly say "I just dont want to anwser questions on EJB" :)

    Enterprise Beans are such a big bloat on the entire J2EE spec that it gives a chance to people like Rolf Tollerud,to criticize J2EE(sorry Rolf ,no hard feelings :). This bloating of EJB has been been carried so far that ,people after some time will just hate to talk about EJB's, persistence,transactions etc,overlooking even the good points available in enterprise beans.

    Oops ,i can see more "Shaking" news in near future,more architects resigning,more technology officers hopping jobs; and above all ,stock prices falling :) :)

    Thanks for this good work.
  13. Looks very interesting, very thought out. What I don't see is how do you plan to implement marshalling/unmarshalling mechanism for dtos. I'm yet to see a general model that allows for efficient and transparent handling of relations, that can be fitted to all the practical needs out there. If you know one, please let me know, asap. :)
  14. This is a nice job of refactoring EJB 2.1, so this should be called EJB 2.2 (the paper even mentioned this), not "a new choice for EJB 3.0". But IMO, this is still not simple enough as you still have to deal explicitly with the many interfaces required by the container (i.e. I prefer the pojo approach plus annotations). Also, explicit support for DTO (via a marker interface) I think isn't a good idea. IMO, DTO is an anti-pattern and we should fix it, not encourage it. There are good points that the paper makes, specifically the detach/attach mode, service locaters injection, and the overuse of annotations to specify persistence. If persistence annotations can be optional (i.e. specified in deployment descriptors), this problem would go away. Personally, I love dependency injection, especially when explicitly annotated in code. As for the detach/attach mode, I don't know enough to comment.

    Finally about persistence, there isn't 1 solution that fits all but having said that, I think that allowing pluggable persistence implementation is a mistake. My experience with SQL and complex app is that there isn't an ORM solution out there that fits my needs. Having to deal with SQL directly is an absolute must. So in this regard, I think the current EJB3.0 approach for persistence is a good start (because it supports native SQL).

    This is good work and I think the EJB 3.0 EG can definitely glean from this and flesh-out/improve the EJB 3.0 spec.
  15. New Life for EJB: A new choice for EJB 3.0[ Go to top ]

    I find this proposal <strong>very</strong> refreshing. Though it may not be completely perfect, it is in the correct direction. The who's who just has to smooth out some minor rough edges...

    I personally have no *real* problems with the current j2ee, & the 2.x specification of ejb's... Sure they are bloated, and you need some framework/ design patterns to hide the complexities of this bloated implementation... once you accept that, it's not a huge deal. But then again, look at what j2ee & ejb's are doing for the software industry... of course it's going to be a little bloated.

    <strong>The ejb expert committee needs to take a serious look and examine this new look</strong>

    while the current 3.0 spec has some nice features, I think it's potentially leading the industry in the wrong direction. the solution of introducing new "syntax" or "language bloat" to fix older bloat is just plain silly, it will kill the advantage of java & j2ee. What should happen is the "specification/container implementation" should inherently try to hide more the bloat instead, and expose through existing java 1.2+ syntax.

    just a reminder: the goal of application architects & developers is to focus on & write more business logic for our "customers" ... the name of the game is to deliver products & solutions.

    thanks for the ear :)

    Chris
  16. Better, but...[ Go to top ]

    Yeah looks a little less painful than this old approach, however I am still seeing alot of unnecessary code, custom ServiceLocators, type casts, DTOs & marker interfaces..

    DTO are questionable and not all applications want a completely seperated web tier from the business tier.
    POJO domain objects w/ behavior (true domain model) is what OO is about.
    EJB set back OO, and turned it into a cumbersome procedural component model

    DTOs - remove the 'O', or replace it with an 'S' for struct.
    They are data structures that stem from the EJB-land of evil fine grained access to EJBs and not serializable Entities.

    A Spring / Hibernate approach is still much cleaner (read: IoC) and more flexible (read: AOP).
  17. Better, but...[ Go to top ]

    DTO are questionable and not all applications want a completely seperated web tier from the business tier. POJO domain objects w/ behavior (true domain model) is what OO is about.EJB set back OO, and turned it into a cumbersome procedural component modelDTOs - remove the 'O', or replace it with an 'S' for struct.They are data structures that stem from the EJB-land of evil fine grained access to EJBs and not serializable Entities.A Spring / Hibernate approach is still much cleaner (read: IoC) and more flexible (read: AOP).
    You are right about DTO in OOP context, but there is alternatyve. I do not
    evil procedures and structs or objects with behavior. Procedures have a good use cases like RPC and messaging, data access. If you need more popular names in your design then think about procedure as "command" or "service".
    Sorry, but I do not know good buzzword for static or dynamic data structures, probably DTO was a good name, but it is more known as "struct" too (Value Object).
    So, if you will rename things then you will have all buzzwords and pragmatic design at the same time, you will have very scalable, performant and secure system after you will drop "domain objects" and old buzzwords ( they do not have place in RPC, messaging and data access ).


    BTW evrythink is object so procedure is an object too, is not it ?
  18. Nice! (on first scan) Now I need to actually read the monster...

    -geir
  19. Great Work[ Go to top ]

    Really nice. I, for one, finally got the breath of fresh air I was eagerly waiting for.

    The best part is that its plain OO design. Implementations classes implement Interfaces that they are expected to. NO magic behind the screens, which is how we like it, unlike how it is in the microsoft world. Interfaces were never a problem for me; The names were, which is fixed :-)

    Most of the thoughts here have been lingering around (at least in my mind) for quite some time, but nobody ever actually thought out such a big refactoring on the much scary EJB framework.

    Hope the committee gives a serious thought to this one.
    aXe!
  20. Is anybody out there?[ Go to top ]

    After a preliminary preview it seems very nice. I have found most items in the current ejb 2 model sufficient for most projects I have worked on (though without the entity beans- using DTO's and jdo instead) and was wondering if there was a way to save what is good about the spec without sacrificing the larger container services that manage transactions, etc which are very useful depite much large container bashing lately. 1 suggestion- It would be nice to have a way to trace transactions through containers for all beans involved (even conversational- or stateless beans). Right now there is only session-synchronization for the stateful beans that provides such low-level access- it would be nice to have that for all beans as many problems with the current implementations I have found revolve around knowing transaction boundaries- and tracing them can be quite daunting (although theoretically there should not be ambiguities with stateless transactions- in reality there can be- especially with multiple embedded transactions!).
    After reading this very-reasearched work I really only have 1 question- Is anybody out there? With the 3.0 spec already proposed- will this paper actually influence the current proposal- are they listening? I hope so.

    -J
  21. Two tracks ?[ Go to top ]

    After reading this very-reasearched work I really only have 1 question- Is anybody out there? With the 3.0 spec already proposed- will this paper actually influence the current proposal- are they listening? I hope so.-J
    The authors state that the comitee reviewed their work. I find it really nice that this (definitively good) proposal is taken into account, but I also have the same question : now that ejb 3 brand new ideas have (strongly) been widespread, how could this more conservative alternative be integrated in the spec?
  22. Far be it from me to rain on the parade, but did anyone actually read the proposal before raving about it? There are a number of flaws, particularly around their DTO proposal, which is little more than detach/merge in disguise, only more complicated.

    http://jroller.com/page/mschinc/20040805#new_life_for_ejb_a
  23. Your points[ Go to top ]

    Merrick,

    I think you've missed the major difference between the EJB 3.0 spec's detach/merge proposal and our proposal to extract DTOs from Entities and update Entities with the values in a DTO.

    At the end of a detach operation, the Entity itself is detached and ceases to be managed. It is thus *unavailable to other users*. So apart from our objection that it exposes the domain model to other tiers, it also reduces concurrency, don't you think? If all that I want to do is read some data and update it later, can't I work off snapshots?

    (I know you'll ask us next about someone wanting a lock-protected read-for-update capability. We addressed that issue by suggesting the spec implement isolation levels for entities so that you can choose the REPEATABLE_READ isolation level and obtain read-for-update capabilities within a transaction. Terrible for concurrency, but that's the correct way to do it.)

    I don't get your point about JNDI, either. Contrary to what you say, our proposal actually makes testing *easier*. The JNDI lookup, if required, happens under the covers because the manager class does the lookup. The application code only calls a getter method. Now, a testing framework can inject a stripped-down manager into the context that only searches the local classpath, for instance. Isn't this an abstraction that aids testing?

    You also missed the mark with your third point, I'm afraid. We did not say the spec should not address security at all. If you read carefully, we said the authorisation model should follow the authentication model. i.e, the EJB framework should allow domain-specific authentication and authorisation modules to be plugged in. It should not dictate the authorisation mechanism, which it does today (and badly).

    Regards,
    Ganesh
  24. JNDI lookups are very useful[ Go to top ]

    Greetings,

    IMO looking for beans by their absolute names (Java classes) instead of aliases (JNDI reference) would not work. It looks like that according to proposed architecture I have to create entity bean for each DB entity (table) in my system even if they can implement same business interface? For example - lookup tables, they all have only two columns: id and label. I can deploy multiple Entities by mapping same EJB class to different tables and I would give them different JNDI names. Then from my code I would lookup them by their JNDI names not by EJB class because they all have same EJB class.

    Regards,

    Taras
  25. Your points[ Go to top ]

    At the end of a detach operation, the Entity itself is detached and ceases to be managed. It is thus *unavailable to other users*. So apart from our objection that it exposes the domain model to other tiers, it also reduces concurrency, don't you think? If all that I want to do is read some data and update it later, can't I work off snapshots?
    Ganesh, I suggest you have a look at how todays ORM solutions implement detach. You have misunderstood the JSR-220 spec here. Detach does NOT imply the behavior you describe.

    Actually, the stuff you've proposed for entity beans is much less sophisticated, and much more intrusive in the face of the user than what is currently in the JSR-220 spec. Though, I admit, your stuff is closer to the EJB 2.1 model (and closer to the problems of EJB 2.1).

    Basically, what you've described in this paper moves against the direction that the Java community has been moving in for the past couple of years. ie. Plain Java Objects, without hard dependencies to the container.
  26. Your points[ Go to top ]

    It looks like entity database in memory replicated it with RDBMS, it imlies concurrency control and recovery implementation for memory database, it is bit of framework scope, is not it ? I see no meaning to reimplement object database in framework.
    It can be meaningfull if "domain object"/entity is component, but entities are not components in practice, entity is very domain specific and it is too specific to be a component. Entity is more a data model concept and database schema is this domain model, it doe's not depend on programming language, access methods and connectivity, there is no meaning to move it to one of applications and to add limitations.
  27. Your points[ Go to top ]

    Actually, the stuff you've proposed for entity beans is much less sophisticated, and much more intrusive in the face of the user than what is currently in the JSR-220 spec. Though, I admit, your stuff is closer to the EJB 2.1 model (and closer to the problems of EJB 2.1).Basically, what you've described in this paper moves against the direction that the Java community has been moving in for the past couple of years. ie. Plain Java Objects, without hard dependencies to the container.
    I would grant that for IoC vs. Service Locator. IoC can hide a bit more. But otherwise, I see EJB 3 as very annotation intensive. Most (EJB-)platform dependencies that used to be enforced by inheritance or through the deployment descriptor now has to be annotated into the code to get equivalent functionality. You are depending on the fact that the compiler can be set up to ignore annotations. That does mean that the bean is more of a POJO (in that it does not have to extend EJBSomething) and hence can be run outside of the container, but if its EJBness derives from annotations, it it any less intrusive?
  28. Your points[ Go to top ]

    Ganesh,

    An unmanaged entity (either a serialized copy or the entity itself after the end of a transaction) is a snapshot of the data at a point in time. Although it may later be merged back in with changes, it maintains no locks or any other attachment to the database. The model you wish to work with will be quite easy to do with EJB3.

    With respect to JNDI, you have eliminated the creation of an initial context and one try block. A simplification to be sure, but hardly revolutionary for testing. With injection, you can simply invoke the setter in your test case to manually supply dependencies. Service locators require a mock object to be customized and instantiated for every test case.

    Finally, the only issue I see with EJB security is that entities should not require method level permissions. Role-based annotation of session methods is fine for those use cases where it applies.

    Merrick
  29. Magic callbacks[ Go to top ]

    Although many things in the proposal may be considered a matter of taste, the business of magic callbacks in EJB 3.0 spec has a definite design smell. I believe that it is generally wrong to leave developers at mercy of a typing error. An approach of optional callback interfaces proposed in this thread is definitely a better one. Another alternative would be to annotate callback methods and have container invoke them based on their annotations, not the method names.

    Regards,
    --Dmitriy.
  30. re: Magic callbacks[ Go to top ]

    I totally agree. It would better to have a model that enforces compile time checks than “Magic” runtime callbacks. It just seems to me there must be a better way.
  31. Injection and purism[ Go to top ]

    I totally agree. It would better to have a model that enforces compile time checks than “Magic” runtime callbacks. It just seems to me there must be a better way.
    The "better way" is probably through "old-fashioned" lifecycle interfaces. The problem is that when you hop onto the dependency injection boat (like I have), you suddenly want the classes to stay so pure and decoupled that implementing an interface feels like polluting the code by adding a dependency to the particular framework that provides the lifecycle interface. For instance in Spring, should I implement the InitializingBean interface, or should I declare this in the descriptor by setting the onInit attribute? Implementing InitializingBean is probably the choice that leads to the least amount of debugging later on.

    I'd like my objects to be deployed as plain objects in Spring today, and perhaps as container enhanced EJBs when the spec is done and implementations are available. If I want my objects to be lifecycle aware through implementing interfaces, I'd be happier implementing javax.xxx.ConversationLifecycle or javax.xxx.ServiceLifecycle than something under javax.ejb or org.springframework. I think it would be easier to convince "injection purists" that magic methods aren't necessary if some of the genereic interfaces would be independent of the container technology. I really like the proposed terms (conversation, service, event listener e.g) and so they're a good start since nobody "owns" them. :)

    Just my 2 cents,

    Dag
  32. Magic callbacks[ Go to top ]

    Yes, contract by method name is not very clear, there is no meaning to hide contracts, it must be very clear and "vissible".
  33. Re: Magic Callbacks[ Go to top ]

    I really like your idea of using annotations to mark the container callback methods. It's like they went halfway: they got rid of the interfaces and instead use annotations to mark bean classes as such, but instead of marking the interface methods with annotations as well, they left the legacy method signature constraint. It leaves you with unnatural "magic" invocations that cannot be checked at compile time. One way or the other, please.
  34. paused transaction[ Go to top ]

    "Conver ation (Stat ful Servic Bean):This d clar s th g tHandl ()method,through which a client can obtain a serialisabl handl that can be used to resume a paus d transaction lat r (ev n from another cli nt device)."

    How is it possible to "pause" transaction ? Does it means many clients can obtain the same handle and continue the same transaction concurrently ?
    It is a nonsence.
  35. Paused Transaction[ Go to top ]

    Transaction here doesn't (necessarily) mean 'database transaction'. It is the 'conversational transaction' that the client is having with the server using a particular device, say a Web Browser. These conversational transactions are represented by the 'Conversation' beans. By using getHandle() a client that finished only half its work, using a web browser, can continue with its unfinished business, using a PDA, at a later point in time (provided ofcourse that the Conversation bean was in fact serialized).


    Thanks,
    aXe!
  36. Paused Transaction[ Go to top ]

    Transaction is very clear think in j2ee, it is specified by JTA, Statefull beans are desined to propagate transaction (demarcate on client thread, run on server thread), "handle" is usefull for shared objects only, shared object can be statefull too, but you will need "threading models" like DCOM (single,apartment and free).
  37. Ganesh,

    My comments and questions relate to your entity bean implementation:

    1. Why is a Product Bean Interface in your example called a Business Interface? It does not perform any Business Function.

    2. The equivalent implementation of your product entity bean in the proposed EJB 3.0 would be:

    @entity
    public class Product {


    }

    It seems that this is a much simpler solution than the one you have suggested, which implements an entity interface as well as extends the Product bean.

    3. How do plan to serialize related objects (one to many) in a DTO? Is lazy loading going to be an option?
  38. Laundry list is a must for EJB beginners. The DTO pattern for entity beans are widely used in application frameworks. The same goes with the service locator. Closer to using J2EE as the application framework.
  39. Hurrah![ Go to top ]

    I *really* liked this. Pure and elegant. Forget the abominable annotations. Forget the horrid magic methods. Remove the forbidding coupling with web services interface.

    The only thing I may have a problem with is the DTO stuff. But something's got to give, I guess.. I would probably leave DTO's out, and just make entities explicitly local. Anyway, please rename the interface to something else, like TransferObject or anything.

    But how to proceed? The spec committee is NOT going to change course at this point. Maybe this could be submitted as an ECMA spec or something.. Just change the name to JDC (Java Distributed Components) or similar to avoid troubles with Sun trademarks.

    Great Stuff. No let's see the reference implementation :)

    BR,
    Jay

    PS. there's a typo on pg. 30:
    ServiceManager = ManagerFactory.getInstance().getServiceManager();
    - you're missing an 'sm' :)
  40. Great work Rajat and Ganesh,


    I think this is really solid work which properly addresses a very important area; performance and management of data in *multiples* rather than individually.

    As many people are aware, significant requirements, functionality and management are often needed across lists or groups of entities/ data items, and historically this has been difficult and or poorly performant.

    My take on this is that the original EJB focus was on *network distribution* right down to each individual data item and method call.

    This is shown by the pervasive interfacing and RMI semantics. But unfortunately this 'magic bullet' approach for distributed applications was addressed at entities singular, without such focus on session, transaction, resource lookup and suchlike contexts as how an application usually networks/ interacts with the database.

    So typically management shows up to begin with in more complex and rule-dense areas of the application or as transactions increase, but may spread within the application as affected areas, interactions and workarounds spread.

    With the common requirements of database mapping and variation/ integration in systems over time, I like the Session- and transaction- level management boundaries found with JDO. This runs the application session and loaded data as a compact system with data bulked from Queries, efficient use cases and a network boundary back to the database.

    Management is also reliably efficient to implement as this can be placed into any storage or execution node; eg OrderLine thru Order, Customer and above, globals such as Product, DatedOrderSpecials, application context such as Session, UseCase etc. This is efficient and quite linear to code and execute, and temporary info and mgmt can also be placed alongside objects using eg an identity hash-map.

    As you say with dependency injection, this is an issue of lifecycle and context with cleaner lifecycle and more ‘useful’ APIs perhaps addressing the problem better. I did quite like your lookup and context example. Perhaps an easier way might be to shortcut factories/ manager access/ manager creation from the context – with common usages and Class or name- lookup.

    Particularly if multiple managers are be involved or have subclassed functionality implemented by the application, this might be a more compact way to access those pesky execution contexts.

    ResourceManager rm = context.getManagerFactory().getResourceManager();
    ....
    CustomerMgr custM = (CustomerMgr) context.getEntityManager( CustomerMgr.class);
    OrderLineMgr lineM = (OrderLineMgr) context.getEntityManager( OrderLineMgr.class);
    ….
    DataSource ds = context.getDataSource( “PostgreSQL Testing DB” );
    ...
    SomeService someService = (SomeService) context.getService( SomeService.class );
    ...

    Anyway this is all theoretical, though it could be a nicely convenient syntax…

    Hope the committee is receptive to your views, but I agree that improvement might be quite slow in the EJB direction since EJB3 is already quite fixed and vendors are still pushing in that direction. Best luck,


    Cheers,
    Thomas Whitmore
    www.powermapjdo.com
  41. Detached beans[ Go to top ]

    "Clumsy" detached entity beans - I do not agree. I think they would make a lot of sense for systems with optimistic locking, which do not require to lock database row before selecting and updating it. I do not quite understand the semantics of the particular implementation suggested in EJB3 draft. One of the use cases for detached objects is to select data from database or to create a new (detached) instance of the object. Later on (maybe in half an hour), when I am about to store these objects in the database, I would probably want to join them in one transaction or to include them in other, existing transaction. I use the similar approach in my non-EJB application. The nice thing is that if a client decides not to store updates in the database, these detached objects are simply removed from the memory, and the database would not even know about this.
    At the end of a detach operation, the Entity itself is detached and ceases to be managed. It is thus *unavailable to other users*. So apart from our objection that it exposes the domain model to other tiers, it also reduces concurrency, don't you think? If all that I want to do is read some data and update it later, can't I work off snapshots?
    What is a snapshot? If it is a business object, than I do not see difference between a snapshot and a detached bean. If it is a DTO, then I do not want to use DTO within my own application which can use full-blown business objects instead. And how detached beans can reduce concurrency? Maybe I did not read EJB3 spec thoroughly, but I thought that detached beans go out of scope of any transaction. When they are about to be stored to the database, they are included in a context of a new or existing transaction. Is not it supposed to work like this?

    Let me see... EJB3 spec talks about changing state from detached to managed, in particular: "If X is a new entity instance, a new managed entity instance X' is created and the state of X is copied into the new managed entity instance X'." This is all good, detached state changes to managed state, but what about transaction context? Will this entity be included in a transaction and if it will, it which one?

    I would use detached entities exactly as what they are -- as entities, not as DTOs. Seems like everyone has their own understanding of DTO, but for me it is nothing but struct. Entities, on the other hand, can have business rules. I prefer to use entities. But why should I initiate a transaction (including possibly a database transaction too), and create "normal" attached entity just to rollback it later? It is a very common use case, either using online store or payment system or other, when a client creates a bunch of objects, but when they has to be committed, chickens out. If I used detached objects, I would just forget about them, and they would be removed from memory. Simple.(I know you'll ask us next about someone wanting a lock-protected read-for-update capability. We addressed that issue by suggesting the spec implement isolation levels for entities so that you can choose the REPEATABLE_READ isolation level and obtain read-for-update capabilities within a transaction. Terrible for concurrency, but that's the correct way to do it.)What is that, pessimistic locking? This is a way to go for low throughput systems only. My understanding always was that EJB is about _enterprise_ and high volumes. As an example, try to book an airplane ticket on travelocity or expedia. Well, they can even tell you that there _is_ a ticket available, but at the moment when you are ready to lock your flight and to pay, it may be already sold to someone else. This is optimistic locking. I guess, they lock the data right after you chose to buy a ticket, but for a limited timeframe only. They want to sell tickets, not to allow peopleto stare on the screen for day long.

    The point of my example? I belive that it is absolutely unreasonable to use detached beans or DTOs in pessimistic system. If you would need to lock a database row anyway, why not to use the bean linked to that row?

    If I am not mistaken, EJB spec was promoting enterprise beans as a way to represent business entities. So, if I program to EJB, I would program my business objects as beans. And why would I want to use something else than business objects themselves to work with business object data? The best example is presentation: Struts et al. Struts form beans are classic DTOs, they transport data from and to browser. I do not mind to use form beans, because browser cannot understand anything else than form field, and cannot provide anything else than a bunch of name/value pairs. On the other hand, Struts form beans not only provide me with browser data, they allow to validate it and to pass control somewhere else in case of error. This is the kind of DTO that I like.

    But while within my own enterprise application why in heaven I would use some artificial mechanism like DTOs? Just to minimize container and database access? I do not give a flying chili bean for that, a container developer should think about this, and about caching, clustering and other behind-the-scenes low-levl stuff. As an _application_ developer I should not care about that. Now call me a VB junkie (never used VB though), but this is my understanding: if I use something that pretends to be a _service_ for me as developer, this service better be good. Especially if it costs tens of thousands bucks.

    DTO is a way to transfer raw data between different systems, which do not understand the domain data of each other. Using DTOs within the same application does not make any sense, except as to overcome the problems of the container. Why would I need such a crappy container then?

    So, summing it up, I would say:
    * Managed ("attached") entity beans for pessimistic locking
    * Detached entity beans for optimistic locking
    * DTOs for external systems which do not understand domain model.
  42. Detached beans[ Go to top ]

    What about a graph of detached entities? Say we lookup an entity with complex (even recursive) relationships to read some fields in the client tier. I did not understand very well how the container could optimise the read of some sparse fields in such a graph of dependent detached entities. Should it load the entire graph to the memory to detach, since it can't know what will be read? If the entities where attached, the containner could optimise to load as needed.
  43. Detached beans[ Go to top ]

    What about a graph of detached entities?
    Yep, seems it's still a question for EJB 3.0
  44. Detached beans[ Go to top ]

    What about a graph of detached entities?
    Yep, seems it's still a question for EJB 3.0
    I think this stuff is too experimental to be a standard, people must be very brave to use it for distributed production systems, I am not so brave to load database to client memory and to use "optimistic" replication for all entities, is it some reason to do it ?
  45. Detached beans[ Go to top ]

    BTW I know serialized proxy workaround, but it breaks distributed programming concepts, server must serve client request and can not decide about the data client needs ("initialize") this model implies database copy in client memory or broken distributed system design.
  46. Okay, 3 links deep is as far as I go to try to read an article. Pity, it sounds like they have some good ideas. Maybe next week I'll fire up google (if it's up) and see if I can find the actual details.
  47. Our position on DTOs[ Go to top ]

    We absolutely agree with the posters who expressed uneasiness with DTOs corresponding to entities crossing tiers. We are against tight coupling of tiers by exposing the domain model, and in fact, the DTO mechanism we proposed was to be used as a *warning* to remote clients that they were not dealing with an entity reference.

    The DTO mechanism in our model has three applications, two of them beneficial and one controversial:

    1.For *user-defined* Data Transfer Objects, the DTO marker interface is automatically applied by the container when it is serialised to a remote client. This helps clients understand whether they are dealing with the original object or a copy. This has nothing to do with Entities and does not seem to be controversial.

    2.Within a Service bean that creates an Entity, a DTO acts as a convenient snapshot of the entity (which could be empty or populated) that helps to replace createXXX() methods, i.e., if an entity has many non-null properties, this helps the Service set all of them in the snapshot object before calling the createEntity() method of the EntityManager. This is not likely to be controversial either, except that the object in question is a Template and not a Transfer object. We'll see if we can make some cosmetic changes here to address this nomenclature issue.

    3.It is legitimate for Services to pass Entity references to each other, as long as they are within the same VM. But because we have a single interface for Services, regardless of whether the calling component is local or remote, we had to handle the case when a Service was called (accidentally or otherwise) by a component outside the VM. We had two options: either have the container throw an exception, or have it use the same model as for user-defined DTOs, and apply the DTO marker interface to warn the remote client. We chose the softer option (apply the marker interface as a warning). If the remote client knowingly wanted to update the DTO with values and pass it back to another Service method in the Entity's VM, the updates could be applied to the Entity. We thought it would be a useful feature if used responsibly.

    We realise that choosing the softer option has caused the most controversy. It has also made us appear inconsistent when criticising the spec's “detached entity” model, because our model ends up supporting the same tight coupling that we criticise.

    We are now proposing to use the harder option, i.e., if an entity reference inadvertently crosses the VM boundary, the container will not serialise it but throw an exception, because Entities are purely local and must not be seen outside the EJB tier. If the developer needs to transport the properties corresponding to an Entity across tiers, they must write their own DTO and physically copy the property values across. (This is what we have been doing all along as developers. Heh!)

    What do people feel about this proposal?
  48. Our position on DTOs[ Go to top ]

    the DTO mechanism we proposed was to be used as a *warning* to remote clients that they were not dealing with an entity reference.
    Why do you need "entity" if clients do not use it ? "entity" is modeling concept, why do you want to hide model ?
    I think you do not need model if you hide it, domain model becomes just useless infrastructure layer in this case and I think it very broken design.
  49. Our position on DTOs[ Go to top ]

    the DTO mechanism we proposed was to be used as a *warning* to remote clients that they were not dealing with an entity reference.
    Why do you need "entity" if clients do not use it ? "entity" is modeling concept, why do you want to hide model ? I think you do not need model if you hide it, domain model becomes just useless infrastructure layer in this case and I think it very broken design.
    I don't think you understood. The entity is of course visible to its *local* clients (Service and Conversation Beans in the same tier). These business logic components can see and operate on the domain model. But *their* clients in higher tiers should only see a "Services" interface. The domain model should not be directly visible to tiers beyond the EJB tier. It breaks encapsulation. Within the EJB tier, we have a Component-Oriented Architecture. Outside the EJB tier, we have a Service-Oriented Architecture.

    Hope that's clear.

    Ganesh
  50. Mgmt vs Information boundaries[ Go to top ]

    Hi Ganesh,

    What we're finding here is that the distinction between 'management' of the entities and the 'information' within them, is getting in the way.

    We're quite keen on the JDO model which uses a more structured/ less intrusive management model, and leaves the entities as more simple information objects. This really puts the separation of mgmt & data transfer concerns in a more correct place.


    Regards,
    Thomas
    www.powermapjdo.com
  51. Our position on DTOs[ Go to top ]

    the DTO mechanism we proposed was to be used as a *warning* to remote clients that they were not dealing with an entity reference.
    Why do you need "entity" if clients do not use it ? "entity" is modeling concept, why do you want to hide model ? I think you do not need model if you hide it, domain model becomes just useless infrastructure layer in this case and I think it very broken design.
    I don't think you understood. The entity is of course visible to its *local* clients (Service and Conversation Beans in the same tier). These business logic components can see and operate on the domain model. But *their* clients in higher tiers should only see a "Services" interface. The domain model should not be directly visible to tiers beyond the EJB tier. It breaks encapsulation. Within the EJB tier, we have a Component-Oriented Architecture. Outside the EJB tier, we have a Service-Oriented Architecture.Hope that's clear.Ganesh
    I understand it and I think it is overdesign. Both "struct" and "objects" are great things, but there is no meaning to use them both for data access. My favorite way is to drop
    "Component-Oriented Architecture", components solve no data access problems.
    It is very trivial, just read/write data from/to DTO or dynamic data structure and keep model in database as "ER". It can be single and very clear "Service-Oriented Architecture" without model duplication and reinvented concurrency control. This way has no problems, it just not "Component-Oriented".
  52. Our position on DTOs[ Go to top ]

    BTW local entites without DTO is not a problem too, it works in web or in singleuser application ( Hibernate, JDO ), but it is too problematic for distributed systems, DTO is good workaround, but there is no reason to use both.
  53. Our position on DTOs[ Go to top ]

    We are now proposing to use the harder option, i.e., if an entity reference inadvertently crosses the VM boundary, the container will not serialise it but throw an exception, because Entities are purely local and must not be seen outside the EJB tier. If the developer needs to transport the properties corresponding to an Entity across tiers, they must write their own DTO and physically copy the property values across. (This is what we have been doing all along as developers. Heh!)
    So you want to remove the Remote interface from entity beans but otherwise leave everything else the same? Great way to simplify things. You seem to be going through a lot of effort to make things difficult for the developer just because you don't like the idea of domain models "escaping" from the EJB layer.
  54. Our position on DTOs[ Go to top ]

    So you want to remove the Remote interface from entity beans but otherwise leave everything else the same? Great way to simplify things. You seem to be going through a lot of effort to make things difficult for the developer just because you don't like the idea of domain models "escaping" from the EJB layer.
    Merrick,

    I certainly hope you're joking.

    1) Apart from being architecturally unsound by breaking encapsulation, detached entities don't work, because they reckon without a fundamental issue with distributed systems. The client must have some way of knowing if they've got a reference to the entity itself or to a copy. If the client is in another tier, they get a reference to a copy, of course, but how do they know? If it looks like an entity, walks like a entity and quacks like an entity...

    In the world of distributed components, behaviour must be identical irrespective of the location of the component. Remoteability of the implementation is possible only if identical behaviour can be guaranteed irrespective of location (remote or local). The concept of detached entities is a kludgy and incorrect workaround to the remoteability problem. Using entities without knowing whether they're managed or detached can cost you dearly, as this EJB 3.0 example will show:

    Forgive any syntactic errors and look at the concept alone.
    Assume that the transaction type of all methods in this example is “Required”.

    // A session bean in one tier:
    @Session
    public class ClientSessionBean
    {
    public void someMethod()
    {
    // Credit Card Entity reference (part of domain model)
    CreditCard cc;
    ...
    // A reference to another Session bean in the same VM
    // or on another (we don't know which, because
    // we have no explicit local or remote interface, just a general
    // business interface – a POJI)
    @Inject CreditCardSessionBean ccsb;

    // The reference to the credit card session bean is injected,
    // not looked up, so we don't know anything about where it is,
    // relative to where we are.

    // The credit card session bean exposes the domain model
    // by returning a credit card entity. No need for an explicit
    // Data Transfer Object. Nice and developer-friendly :-).
    cc = ccsb.getCreditCard( customerReference );

    // We have a reference to the credit card entity. It we are in
    // the same VM, it's a reference to a managed entity.
    // If we are in another VM, we have a
    // reference to a copy, because this is a “detached entity”,
    // but we don't know!

    // Debit the card by $1000.
    cc.debitAmount( 1000.0 );

    // If the entity is managed, the debit will actually go through
    // and be recorded in the datastore.
    // If the entity is detached, it won't. The datastore will be
    // unaffected.
    // But we won't get an exception either way.
    // So we don't know if the debit went through or not!

    // This isn't very developer-friendly after all.
    // It could even get the developer sacked.
    }
    }

    EJB 2.x at least had the concept of local and remote interfaces.
    Our model proposed a marker interface to be applied to the returned object itself.

    In either case, it was possible for the client to find out whether the reference they had was to the original object or to a copy. Unfortunately, from what the spec says, it isn't possible for a client in the EJB 3.0 model to figure this out, which means this mechanism is broken. (I'm sure they'll scramble to find a workaround now that we've pointed out this gaping hole.)

    2) Second, you need to understand what you mean by a “domain model”. It's not the entity bean *implementations*, it's their *business interfaces*. A domain is modelled by interfaces. Entity beans provide implementations. For example, an Employee Entity may appear as a Payee interface to a Payroll/Accounting system (exposing only a grade and a bank account number), as a ResourceConsumer interface to a Housekeeping/Admin system (exposing location, LAN port number, etc.) and as an AuthorisedUser interface to a User Provisioning system (exposing credentials, role references, etc.). The Entity bean implements the properties of all these interfaces.

    Your “domain model” actually consists of three interfaces: Payee, ResourceConsumer and AuthorisedUser. Your implementation consists of a single concrete class – EmployeeBean. The Entity bean should not be considered part of the domain model!

    You cannot talk about exposing the “domain model” when you really mean allowing other tiers to access the *physical bean* as a detached entity. That's bad design.

    3) If you think hiding the domain model from higher tiers makes things difficult for the developer, you could argue that every such example of encapsulation does the same (“You mean I have to declare all my instance variables private and then write accessor methods for them? Why can't I just make them public? Visual Basic is so much more developer-friendly!”)

    On the one hand, the industry is trying to move towards Service-Oriented Architectures, where domain models are hidden and only services are exposed, so that large, distributed, loosely-coupled systems can be more easily built. On the other, we have a group of people brazenly talking about exposing domain models and encouraging tight coupling. Weird...

    I'm afraid there is no polite way to say this: The model you support is dangerously incorrect, architecturally unsound and retrograde. It's an anti-pattern.

    Ganesh
  55. It's all about data[ Go to top ]

    Even though I agree with the sentiment that tying model and view layers through entity beans is an anti-pattern, it's hard to also advocate creating DTO's manually. They are mind-numbingly boring to write and use, not to mention plain ugly.

    On the other hand, the externally-exposed service layer still has to send, receive and and let its clients work with complex, structured data. These clients have a need to update/create (often non-trivial) subsets of the entire object graph that forms the extent of the domain model. I think this calls for a more automated and smarter approach to handling data. SDO (Service Data Objects) looks to be a pretty good way of doing this, though I haven't played with it extensively:

    http://dev2dev.bea.com/technologies/commonj/sdo/index.jsp - Whitepaper, specs, javadocs
    http://www.eclipse.org/emf/ - An implementation based on Eclipse EMF

    Using a solution like this would allow the clients to use strongly-typed (business interfaces in this proposal) or weakly-typed generic API's to suit their purposes, package the changes to an object graph and apply them automatically to the domain model on the server side. It would be nice to hear from anyone who has experience going this route in order to separate domain model from clients.

    In the meantime, a little discipline goes a long way in making this separation at least conceptually, if not in implementation. Always using interfaces for defining the domain model is sound advice. Coupled with an expression language on the view side (OGNL in Tapestry etc.) and separate client and service layer facing API's in domain model for functionality that should be hidden from clients, I find that exposing the domain model directly is a good enough approach for smaller systems where you can bring the presentation layer closer to the service side.
  56. It's all about data[ Go to top ]

    SDO can be usefull in some cases, but I have never saw this kind of good use case myself. This problem is more trivial as it sounds, do not make data "complex" or "component", relational model is very simple and there is nothing more to invent.
  57. It's all about data[ Go to top ]

    Thank you, Cagatay.

    We *are* looking at SDO to see how that could fit within our model. We're acutely aware of the pain of writing DTOs by hand (because we've been there ourselves), yet exposing the entity itself rather than a business interface is throwing all discipline and software engineering lessons to the winds. Our DTO proposal was meant to be a via media (where a cooked implementation of only the appropriate business interface was sent to each client), and we haven't totally given up on it yet.

    Stay tuned.

    Regards,
    Ganesh
  58. Our position on DTOs[ Go to top ]

    If the entity is managed, the debit will actually go through and be recorded in the datastore. If the entity is detached, it won't. The datastore will be unaffected.
    If this is how detached entities work, it is plain stupid. But I hope it does not work like this. My idea of detached entity is either a newly created object, which may be easily discarded, or existing but unsynchronized object. I want to be able to change the object whatever I like, but when I commit the changes, the object should be flushed to the database. debitAmount() should call commit, it is a transactional method called without a transaction context. If transaction type of the method is "required", detached entity must change its status to managed and be written to the database. If it works like this, I do not have problems with detached entities.

    DTO, on the other side, is not a "solution", it is just some cheap interoperation glue. It is ok to use DTOs for clients which cannot make use of full-blown business object anyway, like web browsers, which just show strings. But for any more or less complex client I would use "real" business objects whenever I can. Entities _are_ business objects, not implementation of business object interface. Business rules do not operate on standalone objects only, business rules are applicable to the "community" of objects, and to the database. Which is why it is hard to separate "pure" business logic on single-object level from "community" logic. Then why should I?
  59. I want to be able to change the object whatever I like, but when I commit the changes, the object should be flushed to the database. debitAmount() should call commit, it is a transactional method called without a transaction context. If transaction type of the method is "required", detached entity must change its status to managed and be written to the database. If it works like this, I do not have problems with detached entities.
    You're now on another server altogether, remember? How can the entity re-attach itself on this server? Does the detached and transported entity encapsulate a handle or remote interface to the original entity? The spec doesn't say so...
    DTO, on the other side, is not a "solution", it is just some cheap interoperation glue. It is ok to use DTOs for clients which cannot make use of full-blown business object anyway, like web browsers, which just show strings. But for any more or less complex client I would use "real" business objects whenever I can. Entities _are_ business objects, not implementation of business object interface.
    There are very good reasons why you would need to work with business interfaces and not the entities themselves. Think about it. Network bandwidth and Security are just two of those issues that come to mind.

    Bandwidth: If your Employee entity has twenty properties (conservative estimate, it's usually much more), including a "photograph" property holding an image file as a BLOB, then detaching and serialising this entity rather than a specially-cooked implementation of a smaller business interface will consume unnecessary bandwidth every time a detached entity is requested. Clients may only need a couple of properties (say the Payroll service on another server may only want the employee's grade and bank account number), but the framework gives you no way to reduce the bandwidth requirement, because it doesn't recognise and use any business interfaces that the developer may create. Keep in mind that the largest entities are also usually the most central to an application and various subsets of their properties are frequently accessed by services and clients. Can you imagine bloated objects zipping around your network because someone didn't have the sense to strip them down to the essential minimum?
    (No, the Transient annotation cannot be used to hide properties from clients. It only tells the container not to serialise a property.)

    Security: The Employee entity may have many properties that are sensitive and confidential (e.g., date of birth, address, salary). If you serialise and send the actual entity implementation to every remote client, all these attributes will be physically available on those clients. Any business interface that you as a developer may layer on the entity may seem to hide the other properties, but you cannot disable *reflection* on the remote client. So there is a definite breach of confidentiality that is possible here. I can tell you straightaway that this design (detached entities) will not pass muster with IT Security in many organisations.

    If you have to, you must only transport specially-created implementations of the entity's business interfaces. You cannot send the entity implementation itself. This is amateurishly bad design.

    Our proposal of DTOs was meant to address issues like this. The framework (container + entity manager) "cooks" up new implementation classes that conform to a business interface, copies properties from the entity to the DTO, and sends only the DTO to the client. The client knows that the object is not the entity (because it implements the DTO identity interface and not the Entity identity interface), so it doesn't try to perform entity operations on it. The object is also no larger than it needs to be, and it doesn't carry any information beyond what it is supposed to expose to the client.

    The delicious irony in all of these discussions is this:
    Many developers (especially the less sophisticated ones) may be attracted to the EJB 3.0 entity model and its detached entity concept, because (i) it doesn't force them to write business interfaces and (ii) it doesn't make them hand-code DTOs. But guess what? Because of issues such as what we've identified here, they'll end up writing business interfaces and sidestepping the detached entity feature by writing their own DTOs anyway! So the spec gets brownie points for not forcing anything on the developer, but if developers want to design and build their application right, they can't take advantage of the populist features of the spec. Nice ;-)

    Ganesh
  60. I want to be able to change the object whatever I like, but when I commit the changes, the object should be flushed to the database. debitAmount() should call commit, it is a transactional method called without a transaction context. If transaction type of the method is "required", detached entity must change its status to managed and be written to the database. If it works like this, I do not have problems with detached entities.
    You're now on another server altogether, remember? How can the entity re-attach itself on this server? Does the detached and transported entity encapsulate a handle or remote interface to the original entity? The spec doesn't say so...
    Well, as I already said, if it cannot do this, than I do not see much use of that kind of entity. It should be replicated the same as "normal" entities.
    There are very good reasons why you would need to work with business interfaces and not the entities themselves. Think about it. Network bandwidth and Security are just two of those issues that come to mind.Bandwidth: If your Employee entity has twenty properties (conservative estimate, it's usually much more), including a "photograph" property holding an image file as a BLOB, then detaching and serialising this entity rather than a specially-cooked implementation of a smaller business interface will consume unnecessary bandwidth every time a detached entity is requested. Clients may only need a couple of properties.
    In that case clients do not need the entity, they need subset of the entity, which is a different thing, don't you think? A cat has four legs, and a long tail behind. I can create two aggregates with "popular" properties and "extended" properties. But these aggregates would be part of the business entity, not just plain DTOs.

    Anyway, as I said, external clients, which just cannot be patched to be aware about business entities, like web browsers, would get their plain DTOs. I agree with you on that. Confidentiality. If you need a level of security that high, than this is probably some external client, and it will use DTO as well.

    You think about parts of an application as of remote enemies. I think about them as of close friends ;)
  61. If you need a level of security that high, than this is probably some external client, and it will use DTO as well. You think about parts of an application as of remote enemies. I think about them as of close friends ;)
    remote enemies do not understand JAVA serialization format in some cases and connects to DB directly. RDBMS has no security and compnent problems, stored procedures is the solution in this case.
  62. But guess what? Because of issues such as what we've identified here, they'll end up writing business interfaces and sidestepping the detached entity feature by writing their own DTOs anyway! So the spec gets brownie points for not forcing anything on the developer, but if developers want to design and build their application right, they can't take advantage of the populist features of the spec. Nice ;-)Ganesh
    Yes, this stuff is more populistic than pragmatic and it is motyvated by buzzwords and "easy to use" argument, quality is more important for most "enterprices" than COP.
  63. Just drop DTO abbreviation[ Go to top ]

    * I do not like annotations.

    * Magic method names suck big time.

    * OK, I finally read your work. "You could squint and look at “myDTO” as a detached entity, because that's what it appears to be on the client side." -- Riight! Now the fog is dispersing. Just do not call it DTO, call it Business Object, and I will buy it right away ;) I use pretty much the same approach, but without EJB at all.

    * I do not like having different local and remote interfaces, but I do not like "marker interface" either. How the client would know is it remote or local to the entity it is working with? So, this will end up with clients always checking for marker interface. I prefer the approach taken by Weblogic and others, where there is only one interface, which works either through references for colocated beans, or through normal serialization when accessed remotely. And yes, I want the differences to be hidden from me. Ultimately, these local or remote beans would be accessed from a "neighbour" application, located in the same LAN, which in turn, would be accessed by means of web services or plain HTTP or some other. We cannot expose EJB to web browser anyway. So I would prefer to think about entities in the cluster as of uniform objects, I do not care if they located in the same JVM as my application or in different.

    On the other hand, this is too smart for me: "On the remote client, we have a ManagerFactory object, a ServiceManager object and a Service stub (each has been a factory for the next). A client component has just invoked a method on the Service stub that is declared to return the business interface implemented by the Entity. The container knows that the client is remote, so it creates a copy of the entity, which implements the DTO marker interface and also the same business interface as the entity. This is what it serialises and sends down to the remote client." -- If I ask for entity, give me an entity (local, remote, I do not care, it should look the same for me). If I ask for business object, which is implemented by entity, give me the business object (what you call a DTO). By the way, did you want to say that container creates _plain java object_ which implements the DTO marker interface and also the same business interface as the entity?

    * Dependency Injection vs. Service Locator. I do not know why JNDI or the likes are out of fashion now. If I program for EJB spec, which already specifies a bunch of interfaces to use and to implement, then I can use another one, big deal. JNDI or Service Locator is easy to understand and easy to debug concept. So, I am all in for it. But I was pretty happy with JNDI and I do not see reasons to "completely hide it from a bean's view".

    * Separate managers -- that is good. But why did you decide to build in facade interface in your spec? Why a client cannot use entities directly, without conversations or services? I understand, that using them through services is cleaner, but this should be a decision of an app architect. It should not be prohibited simply because it is "bad practice".

    * "The second reason to extract an explicit DTO from an Entity is to ensure that entity references are not passed to other components by mistake, if those components happen to be in the same VM." -- Why??? I want to use Entities wherever I can.

    * Stateful and Stateless should be different, I agree.

    * "asynchronous beans" would be a great thing, we implement this behavior now ourselves.

    * Security -- I never used EJB security. I would not cry if it goes away.

    Overall, I like your proposal much better than current 2.1, and more than 3.0. You are totally right, we should program to interfaces. It is a pity, that DTO abbreviation caused that much of response.
  64. Just drop DTO abbreviation[ Go to top ]

    Just do not call it DTO, call it Business Object, and I will buy it right away ;) I use pretty much the same approach, but without EJB at all.
     Yes, but if you know how to design system without populizm and dogma, then you do not need EJB and you can continue to do better software without it.
  65. Our position on DTOs[ Go to top ]

    I'm afraid there is no polite way to say this: The model you support is dangerously incorrect, architecturally unsound and retrograde. It's an anti-pattern.
    For someone who put so much effort into writing an alternate proposal, you should have taken some time to actually read the EJB 3.0 spec you have such issues with.

    1) Business interfaces are either local _or_ remote, not both. You are confusing the implementation of a session bean with the interface by which clients access it. If you get an entity back from a method on a remote interface, it's going to be detached by virtue of the serialization. If an entity is detached and you want to make an update, you merge it. I don't see what's so hard to understand about this.

    2) With EJB 3.0, your domain model is your entity model. Entities are concrete classes and do not implement multiple interfaces (there is no such thing as a business interface for a domain object, they model data). If, in your example, you want to model Employees, Payees and AuthorizedUsers separately, you define three different classes (not interfaces) each with their own object-relational mapping. The EJB 3.0 entity model and implementation strategy is completely different from the EJB 2.1 model. I suggest you take some time to understand what object-relational mapping is and how it is used before you continue attacking it.

    3) This has nothing to do with encapsulation. The DTO pattern was designed to compensate for the poor network performance of entities, not some philosophical notion that clients should never see entities. With respect to the relational model, your EJB 3.0 entity model may be as tightly coupled or course grained as you see fit.

    The concepts and technology behind EJB 3.0 are used daily in production systems across the world. There is nothing new here. Your criticisms of the approach are so far without merit.

    Merrick
  66. Our position on DTOs[ Go to top ]

    1) Business interfaces are either local _or_ remote, not both. You are confusing the implementation of a session bean with the interface by which clients access it. If you get an entity back from a method on a remote interface, it's going to be detached by virtue of the serialization. If an entity is detached and you want to make an update, you merge it. I don't see what's so hard to understand about this.
    What is a "Remote Interface" here? In the new life approach, there is no distinction between "Remote" and "Local" interfaces of an entity. Consider a MyService service bean (your stateless session bean) returning an entity, say MyEntity. It is clear that myMethod() in MyService bean is declared to return an object of type MyEntity. Now a calling client, whether remote or local, will receive an object of the same type, viz MyEntity. Only, if it is remote, the returned object will also implement a DTO interface, in order to warn the clients about the fact that it is not 'managed' but just a 'snapshot'. There is no longer a separate "Local" interface. Therefore, there is no "virtue of serialization". The entity bean doesn't know whether it is being accessed by a local client or a remote client. The container and the client should coordinate in order to take care of that detail. And believe me thats very good.
    2) With EJB 3.0, your domain model is your entity model. Entities are concrete classes and do not implement multiple interfaces (there is no such thing as a business interface for a domain object, they model data). If, in your example, you want to model Employees, Payees and AuthorizedUsers separately, you define three different classes (not interfaces) each with their own object-relational mapping. The EJB 3.0 entity model and implementation strategy is completely different from the EJB 2.1 model. I suggest you take some time to understand what object-relational mapping is and how it is used before you continue attacking it.
    OR-mapping is a totally different ball game. It is the HOW. We are not interested in it. We are interested in defining a framework for abstracting out the details of 'WHO does WHAT and WHEN'. The HOW should be left open, so different ppl can use different approaches. That way for persistence I should be able to use an ORM tool and be done with it, or use EJB-QL instead. All, transparently to the way I write my interfaces/beans.

    Your argument holds good, in that, EJB 3 is not broken in this aspect. But it sticks to the ORM pattern of doing things, where as I think the new life approach is much more flexible. It assumes less and lets you declare more. Why in world should an implementation strategy dictate a framework spec?

    Point: I can have only one bean class implementing three different business entity interfaces with the new life approach. The beauty is, if (like hell) I want to have three different business entity bean implementation classes instead, I can do that as well (without any loss of generality).
    3) This has nothing to do with encapsulation. The DTO pattern was designed to compensate for the poor network performance of entities, not some philosophical notion that clients should never see entities. With respect to the relational model, your EJB 3.0 entity model may be as tightly coupled or course grained as you see fit.
    The answer lies in point #2 above. If I can hide the 'Employee' view (interface) of my bean from the payroll/accounting system, and hide the 'Payee' view (interface) of my bean from the HR/admin system, I have achieved more encapsulation. Now, I can do that either using your approach of having three different bean impl classes OR by having three different business entity interfaces but just one bean impl class. If use EJB 3, I have to stick to the first approach. If I use the new life approach, I can have it either way (DTOs or some such, would come into play only because there is remote invocation involved, not because I want to achieve encapsulation!!)


    Cheers,
    aXe!
  67. Our position on DTOs[ Go to top ]

    What is a "Remote Interface" here? In the new life approach, there is no distinction between "Remote" and "Local" interfaces of an entity. Consider a MyService service bean (your stateless session bean) returning an entity, say MyEntity. It is clear that myMethod() in MyService bean is declared to return an object of type MyEntity. Now a calling client, whether remote or local, will receive an object of the same type, viz MyEntity. Only, if it is remote, the returned object will also implement a DTO interface, in order to warn the clients about the fact that it is not 'managed' but just a 'snapshot'. There is no longer a separate "Local" interface. Therefore, there is no "virtue of serialization". The entity bean doesn't know whether it is being accessed by a local client or a remote client. The container and the client should coordinate in order to take care of that detail. And believe me thats very good.
    Entities don't have business interfaces, session beans do. Business interfaces are the client view into the bean and are either local (default) or remote (signified by the @Remote designation). A session bean can implement more than one if need be. If myMethod() on a remote interface returns an entity, it will be detached. The entity at that point is, by definition, a snapshot of the data at a point in time. Detachment is easy to understand and occurs only in well defined circumstances. There should never be a point where you, as the application designer, don't know whether you are dealing with a detached or managed entity. If you don't trust the system and wish to verify it for yourself, there is a method on the entity manager that will tell you if it is managed or not.

    There is nothing in the EJB 3.0 specification that prevents you from implementing everything locally and doing things the old way, by writing different data structures to send back to the client. If this is what you want, then go right ahead. But from a _technical_ point of view, there is nothing advantageous about the alternate proposal in this context.

    Merrick
  68. Our position on DTOs[ Go to top ]

    For someone who put so much effort into writing an alternate proposal, you should have taken some time to actually read the EJB 3.0 spec you have such issues with.
    :-/
    1) Business interfaces are either local _or_ remote, not both. You are confusing the implementation of a session bean with the interface by which clients access it. If you get an entity back from a method on a remote interface, it's going to be detached by virtue of the serialization. If an entity is detached and you want to make an update, you merge it. I don't see what's so hard to understand about this.
    I assure you there's no confusion at all. We understand it perfectly. As we said, the EJB 3.0 model is just a wrapper around EJB 2.x after all. Instead of looking up a remote home and getting a remote component interface as in 2.x, you inject a @Remote session bean into the client in 3.0. That's pretty typical of the spec, I guess (Fundamental design problem? Take a couple of annotations and call me in the morning).

    We're addressing the *basic* problem with distributed systems, which is that they're not really location-transparent. Whether they like it or not, clients have to know whether they hold a reference to the original object or to a copy. This only affects clients in certain situations, namely when they get back "value objects" (and I use the term guardedly). If the method returns void, or a basic type (ints, Strings) or if the semantics of the application are such that the returned object is never manipulated directly but always sent back, this original/copy issue never arises. You only need to tackle it in the situations where it does arise, which is when a client may try to perform operations on the returned value object expecting those operations to affect the original (or perform some operations expecting them *not* to affect the original).

    Our proposal keeps the solution as small and as close to the problem as possible. Don't know whether the "value object" returned by a service is the original or a copy? Check the object itself to see if it implements a marker interface.

    Creating remote and local interfaces on Services just because *some* of them return value objects that *may* be mistaken for the original is an overly blunt instrument.

    This is one of many fundamental problems with EJB 2.x which EJB 3.0 does not fix. That's the basic theme of our critique.
    2) With EJB 3.0, your domain model is your entity model. Entities are concrete classes and do not implement multiple interfaces (there is no such thing as a business interface for a domain object, they model data). If, in your example, you want to model Employees, Payees and AuthorizedUsers separately, you define three different classes (not interfaces) each with their own object-relational mapping. The EJB 3.0 entity model and implementation strategy is completely different from the EJB 2.1 model. I suggest you take some time to understand what object-relational mapping is and how it is used before you continue attacking it.
    No, you model a domain using interfaces, not using concrete classes. This is a well-known OO concept. You will run into problems the moment you try to use concrete classes to model slightly complex domains which require inheritance (Deadly diamond, etc.). The spec writers seem to be aware of this limitation, which is why the spec only promises support for "light-weight" domain modelling. but they've gone ahead and chosen expediency and populism over good design.

    You may find this link useful:
    http://fishbowl.pastiche.org/2002/12/17/inheritance_taxonomy

    Yes, our model may involve a bit more effort on the part of the developer, but at least it's not broken.

    I think you're confused because Entity beans are meant to encapsulate "data" rather than "behaviour", so you think no interfaces are required. But Java doesn't know the difference between "getName()" and "doSomeComplicatedProcess()". They're both methods.

    As part of our domain modelling, we may realise that two views of our entity have some overlapping properties (such as "getName()"). That's not a problem for us, because our entity can implement both interfaces and the two method names painlessly resolve to a single one in the implementation, which is natural and expected. We can't get such flexibility if we box ourselves into using only concrete classes.
    3) This has nothing to do with encapsulation. The DTO pattern was designed to compensate for the poor network performance of entities, not some philosophical notion that clients should never see entities. With respect to the relational model, your EJB 3.0 entity model may be as tightly coupled or course grained as you see fit.The concepts and technology behind EJB 3.0 are used daily in production systems across the world. There is nothing new here.
    The DTO pattern actually dovetails nicely with a Service-Oriented Architecture, which says that clients must not see the domain model. So don't confuse the original motivation for DTOs with our motivation for using them.

    And widespread use is no indicator of architectural soundness. The Service-Oriented Approach is meant to solve the problems caused by decades of building tightly-coupled systems. We want to see EJB 3.0 being part of the solution, not contributing to a long-standing problem.
    Your criticisms of the approach are so far without merit.
    Really?

    Ganesh
  69. Hi Ganesh,

    Well, management, RMI and chickens which quack like a duck. From the start the distinction between management and data has been a mess.

    The architecture would work fine and clean if either:

    1) clients had a local object mgr, and received an object graph - only part of which need be writable
    2) clients had a local treestruct mgr, and sent/ received binary xml format


    I think things were a mistake from the moment RMI method calls were chosen as the transport, rather than keeping object semantics identical and piping data in thru the back eg JDO.

    Basically the management should be orthogonal from object usage (method calls) and instead placed on the same plane as data (field values). You can make a case for RMI to service objects, but entities are always going to need to traverse tiers.


    Cheers,
    Thomas
    www.powermapjdo.com
  70. Thomas,

    We have been reading your comments with interest. Your viewpoint requires a very different mindset, I guess, from the one we're in right now. It probably represents yet another valid way to solve the problems of applications with distributed components. Who knows, it may be a superior solution to both the EJB (2.x and 3.0) model and our own!

    We will definitely study your suggestions to see if we can incorporate them. At the present moment, it appears to be conceptually very different and difficult to cleanly integrate with what we're doing. We're busy improving the DTO aspect of our design (an update should be available soon :-), so we have to prioritise the feedback and suggestions we get.

    But thank you very much for your insightful suggestions. They will not be ignored.

    Regards,
    Ganesh
  71. Our position on DTOs[ Go to top ]

    Hi Garnesh,

    I generally agree with your arguments about encpsulation and domains. I think your description of the domain model is a bit confusing though. My understaning is that the domain model, models "entities" in the underlying business domain, and in that sense is independant of any specific presentation or application. The business interfaces you describe to me sound like "views" of the domain model, which may be required by a specifc application. These views are application/client specific and are related, but independent from the domain model. This is where your DTOs come in I think (I could be wrong).

    On a related point. I too have been working with EJBs since the days when the focus was on distributed services. Now the fashion appears to have reverted back to "stove pipe" systems with all the components running within a single JVM linked to a single RDMS. These are the types of applications mulit-tier distributed systems were meant to replace. The truth is that many J2EE applications built today are "stove pipe" in design, whilst incurring the cost and complexity of a distributed infrastructure.

    I can see this debate going on and on as it appears that many people are comparing apples with pears (stove-pipe verses SOA). Having worked closely with commited XPers I am of the opinion that companies are moving away from distributed service architectures and are building the "simplest" thing possible to meet the needs of a given application (dispite duplicating code across the enterprise).

    My view is that the XP,Spring and Hibernate crowd will end up winning this debate. We just seem to be poor at building systems on the large (enterprise wide) scale. A revised EJB spec may help, but IMHO the problem goes much deeper.

    Good work, and good luck.
  72. Our position on DTOs[ Go to top ]

    How about name your 'getDTO' method 'getView' and make everyone happy? :)
  73. Our position on DTOs[ Go to top ]

    We absolutely agree with the posters who expressed uneasiness with DTOs corresponding to entities crossing tiers. We are against tight coupling of tiers by exposing the domain model, and in fact, the DTO mechanism we proposed was to be used as a *warning* to remote clients that they were not dealing with an entity reference.

    The DTO mechanism in our model has three applications, two of them beneficial and one controversial:

    1.For *user-defined* Data Transfer Objects, the DTO marker interface is automatically applied by the container when it is serialised to a remote client. This helps clients understand whether they are dealing with the original object or a copy. This has nothing to do with Entities and does not seem to be controversial.

    2.Within a Service bean that creates an Entity, a DTO acts as a convenient snapshot of the entity (which could be empty or populated) that helps to replace createXXX() methods, i.e., if an entity has many non-null properties, this helps the Service set all of them in the snapshot object before calling the createEntity() method of the EntityManager. This is not likely to be controversial either, except that the object in question is a Template and not a Transfer object. We'll see if we can make some cosmetic changes here to address this nomenclature issue.

    3.It is legitimate for Services to pass Entity references to each other, as long as they are within the same VM. But because we have a single interface for Services, regardless of whether the calling component is local or remote, we had to handle the case when a Service was called (accidentally or otherwise) by a component outside the VM. We had two options: either have the container throw an exception, or have it use the same model as for user-defined DTOs, and apply the DTO marker interface to warn the remote client. We chose the softer option (apply the marker interface as a warning). If the remote client knowingly wanted to update the DTO with values and pass it back to another Service method in the Entity's VM, the updates could be applied to the Entity. We thought it would be a useful feature if used responsibly.

    We realise that choosing the softer option has caused the most controversy. It has also made us appear inconsistent when criticising the spec's “detached entity” model, because our model ends up supporting the same tight coupling that we criticise.

    We are now proposing to use the harder option, i.e., if an entity reference inadvertently crosses the VM boundary, the container will not serialise it but throw an exception, because Entities are purely local and must not be seen outside the EJB tier. If the developer needs to transport the properties corresponding to an Entity across tiers, they must write their own DTO and physically copy the property values across. (This is what we have been doing all along as developers. Heh!)

    What do people feel about this proposal?

    Ganesh
  74. Our position on DTOs[ Go to top ]

    Within a Service bean that creates an Entity, a DTO acts as a convenient snapshot of the entity (which could be empty or populated) that helps to replace createXXX() methods, i.e., if an entity has many non-null properties, this helps the Service set all of them in the snapshot object before calling the createEntity() method of the EntityManager.
    How this is different from creating a detached bean, and then changing its state to managed?
  75. My vote[ Go to top ]

    Reading this hige proposal paper and this discussion I'm still vote for EJB 3.0
    For me DTO and Service Activators are _ANTI_ patterns one should avoid.
    Also testability of this approach is the same as "old" EJB. (Here was a post about it already).
    I prefer approved solutions like Spring (Pico.. etc) and Hibernate (JDO etc), but anyway thanks to Ganesh et al. for the new vision on EJB.

    Renat Zubairov
  76. Call it EJB 2.2 proposal[ Go to top ]

    Ganesh and Rajat,

    Great job and an excellent proposal.

    I feel your proposal should be the EJB 2.2 spec (continuation of EJB 2.1 without many of the defects) as opposed to EJB 3 (which is far more revolutionary). I feel that EJB 3 appeals to those who would like to upgrade from a Spring+Hibernate approach to a standards-based one.

    I feel that those working on complex enterprise development would prefer your evolutionary proposal. Despite all the latest fads and buzzwords (AOP, IoC, Annotations etc.), core OO and software engineering principles shouldn't be abandoned.

    Regards,
    Kalyan
  77. IoC[ Go to top ]

    What i understood is that your suggested model is a refactored version of ejb2.1, so Inversion of Control may appear off-topic here.

    However, could you give your position about IoC as alternative to ServiceLocator approach ?

    José.
  78. IoC[ Go to top ]

    What i understood is that your suggested model is a refactored version of ejb2.1, so Inversion of Control may appear off-topic here.However, could you give your position about IoC as alternative to ServiceLocator approach ?José.
    Inversion of Control is now called Dependency Injection. We have quoted Martin Fowler's position on "Dependency Injection versus Service Locator" in our document and shown how we use the best features of both.

    Ganesh