Inversion of Control Containers: A write up

Discussions

News: Inversion of Control Containers: A write up

  1. Inversion of Control Containers: A write up (40 messages)

    Mike Spille has taken the time to write up a detailed account on Inversion of Control, and three of the implementations out there: HiveMind, Spring, and PicoContainer. He discusses what he likes and why, and details an interesting section on Object Identity vs. Object Type in IoC.
    Inversion of Control containers (aka IoC) have been all of the rage in the past year. You can hardly turn around on the web without hitting somebody somewhere touting some IoC solution/framework/silver bullet. This blog entry talks about my own experiences with IoC over the past 4 months, and compares my own viewpoint of what IoC should be to what's available in three popular IoC implementations: Hivemind, PicoContainer, and Spring. Examples are shown based (very loosely!) on my own recent work, so that we're at least partially grounded in reality.

    Read Mike Spille in Inversion of Control Containers

    Threaded Messages (40)

  2. bidirectional dependencies[ Go to top ]

    Should an IoC container manage both directions of a dependency?

    For instance, there are IPlugin and IPluginManager service types. IPlugin has pluginManager property, and IPluginManager has pluginList property.

    I may implement setPuginManager like

    void setPluginManager(IPluginManager pluginManager) {
      this.pluginManager = pluginManager;
      pluginManager.addPlugin(this);
    }

    but I don't like statement

      pluginManager.addPlugin(this);

    in service implementation. As I understand, container should set service to service references.

    Nebojsa
  3. bidirectional dependencies[ Go to top ]

    Should an IoC container manage both directions of a dependency? For instance, there are IPlugin and IPluginManager service types. IPlugin has pluginManager property, and IPluginManager has pluginList property. I may implement setPuginManager likevoid setPluginManager(IPluginManager pluginManager) {  this.pluginManager = pluginManager;  pluginManager.addPlugin(this);}but I don't like statement  pluginManager.addPlugin(this);in service implementation. As I understand, container should set service to service references.Nebojsa

    It probably comes down to individual preference but I would say that this would be the wrong approch.

    In the above example, you should really have the PluginManager pass itself as a reference to the Plugin when the Plugin is added to the manager (essentially, the opposite approch to your example).

    When it is done this way, things clear up a little. Your IoC configuration should declare a plugin manager and specify which plugins to include, and the code (i.e. outside of the container) should provide the plugin manager reference back to the plugin in the pluginManager.add() method. Why?.. because the former is clearly configuration, and the latter scafolding.

    Im sure someone will disagree with me, but in my experience, with bi-directional associations of the type you indicate (basically, where the relationship is inteded to be a mirror), I prefer to keep the maintainance of one of the sides well encapsulated and in-code where it cannot be easily tampered with.

    In the case of a 'non-mirrored' bi-directional realationship it probably makes sense to configure everything in the IoC configuration (you cannot really break anything in this case, you can misconfigure, but you cannot break integrity).

    So... now that I have thought about it, it seems your question is not so much based on the management of bi-directional relationships in IoC but on the management of relational integrity, and my conclusion is that this task should always be performed in code (or rather, the most relevant side of the relationship in IoC configuration and the other side managed by the code), by managing integrity in IoC configuration, you invite duplication, and hence, error.
  4. bidirectional dependencies[ Go to top ]

    Should an IoC container manage both directions of a dependency? For instance, there are IPlugin and IPluginManager service types. IPlugin has pluginManager property, and IPluginManager has pluginList property. I may implement setPuginManager likevoid setPluginManager(IPluginManager pluginManager) {  this.pluginManager = pluginManager;  pluginManager.addPlugin(this);}but I don't like statement  pluginManager.addPlugin(this);in service implementation. As I understand, container should set service to service references.Nebojsa

    Defintitly plugin inovoking some operation of PluginManager (e.g. in order to register itself) is a desing smell. This is against Hollywod principle.

    If any plugin needs PluginManger to perform some operation it does not implies that PluginMnager must be injected as dependecy into it. It can be as well provided as a parameter in business methods.


    PluginManager
    {
        void doA()
        {
           Plugin plugin =..
           plugin.doA( this );
        }

        
    }

    Plugin
    {
        void doA( PluginManager );
    }


    after all the name PluginManger well indicates that this is the master object which manges its slaves (Plugins). And IoC principle should apply also at that mirco-level and plugin should be really passive entity in that scenario.


    Michal
  5. Spring is easier than it looks[ Go to top ]

    For people who are considering taking the plunge, I would submit that Spring is easier than Mike implies. When speaking of all the Spring features, Mike stated in his article that using only what one needs is a false argument.

    I respectfully disagree. I had a project that had a hard deadline of seven weeks. This project, like most of our(all us developers), was built in previous work and experience. The group consisted of me(supposedly senior), a part-time senior, and three junior mid-levels. I wanted to make sure that the agressive timeframe didn't shortcut quality or design. The appeal of Spring, for me, was that claim that despite its considering laundry list, I could focus only on my immediate needs.

    In my case, I wanted to start light, by just replacing my custom factories with Spring based versions. I originally figured that the next iteration would allow for the use of more features.

    I was wrong.

    The Spring wiring was so easy we decided to explore some other features. Spring's Hibernate support made using Hibernate, with which we were familiar, even easier. It took me one eight hour day replace my custom dynamic proxies with Spring's declarative version. Even their email convenience classes were trivial.

    Now, I'm condensing weeks of stuff into a few sentences, but my point is that over the course of weeks, I was able to easily add more features because each specific feature was very modular and each, in and of itself was reasonably straightforward to add.

    I don't think that Spring's assertion that you use what you want is false at all. For example, I am not using Spring's transaction support(yet), so I know very little about it. I didn't have to learn it to learn how to use the other features, so I was able to focus only what I used.

    If you have reservations about using Spring because it seems to do so much, I would say go for it. You will, I believe, find that you can absorb quite a bit without having to understand all the nuances.

    Have fun!
  6. Very good article. I could not agree more. Especially the rant
    about this stupid religious fight constrcutor versus setter is
    really annoying.

    I think the only thing that is missing is the JMX support. This would be a perfect fit. Somehow the services should be managed and why not use an existing specification for this.

    If someone out there will now say that the JBoss microkernel already offers this than do not forget that you have to implement JBoss specific interfaces. Definitely a wrong attempt. Who want to write software that is tied to one vendor?

    So the best would be a JBoss like microkernel without their interfaces and just simple MBeans.

    But to the JBoss fame one must admit that they have done it years before HiveMind, pico or whatever. Unfortunately they just did it wrong but they had the right idea.

    Just my 2 cents
  7. PICO comes with JMX support I think you want to look at...
    nano-jmx
  8. JMX support[ Go to top ]

    Andreas,

    I'm waiting for JMX as well! I believe it's on its way in the next release though. Please confirm, someone.

    Kit
  9. JMX support[ Go to top ]

    There is already JMX support in the sandbox. I've been running it for a few weeks and it comes in very useful. Have a look for an earlier TSS thread on this subject because I think they were planning on re-implementing before incuding it into the 1.2 release.
  10. JMX support[ Go to top ]

    Andreas,I'm waiting for JMX as well! I believe it's on its way in the next release though. Please confirm, someone.Kit

    Kit,

    indeed, tha basic JMX support is scheduled for Spring 1.2 which will allow to transparently expose Spring-managed beans as MBeans. The long term goal for JMX support is to expose BeanFactory itself via managed interface.

    Regards,
    Dmitriy.
  11. I think the only thing that is missing is the JMX support. This would be a perfect fit. Somehow the services should be managed and why not use an existing specification for this.If someone out there will now say that the JBoss microkernel already offers this than do not forget that you have to implement JBoss specific interfaces. Definitely a wrong attempt. Who want to write software that is tied to one vendor?

    Have you looked at MX4J? Their configuration loader MBean does almost all you wish: It can instantiate beans, confugre their properies and call methods in IoC way specified in XML configuration file; it also supports calling singleton factories to initialize properties and pass parameters to methods. So you can consider MX4J configuration loader as IoC container bundled with JMX implementation. I used it and it's very flexible way to configure applications, so that I never needed additional IoC container like Spring or Pico.

    The only thing I'm currently tired with using JMX this way it's never provided direct object reference, just MBean reference and you're restricted to call only MBean exposed properties and methods VIA REFLECTION which is sometimes serious performance penalty.

    Thanks,
    Dima
  12. So the best would be a JBoss like microkernel without their interfaces and just simple MBeans.But to the JBoss fame one must admit that they have done it years before HiveMind, pico or whatever. Unfortunately they just did it wrong but they had the right idea.Just my 2 cents

    FYI, you do NOT have to depend on any JBoss specific interfaces, but you do have to implement create, start, stop, or destry methods in your management interface if you want to hook into lifecyle and component dependencies. Lifecyle/dependency is something that the JMX specification does NOT define. JMX also provides the concept of ModelMBeans in that any POJO can be defined as a management bean through descriptors. Our XMBean implemetnation.


    Adrian Brock is currently revamping our microkernel in JBoss 5.0 to allow:
    * multiple subdeployments per archive
    * easier embeddability in other environments. (We are embeddable in non-JBoss environements already, but its not that nice)
    * A bunch of usability features that IoC users expect

    We expect to have an early access release by end of year.

    Some features our microkernel currently has over all others is:
    * classloader scoping(and unscoping)
    * packaging and deployment of any archive format and a Deployer abstraction to handle this (i.e. Hibernate archives (.har), .war, EJB jars, .ear, datasources *-ds.xml, AOP packages .aop, EJB3 .ejb3)
    * Hotdeployment of any packaged deployment
    * JMX GUI management console that can graph, monitor, snapshot, and email alerts.

    JBoss Microkernel basically give you the backbone to define your own application server with only the components/services you require, while at the same time providing packaging for these components, dependencies, hot deployment, classloader flexibility, and GUI management. So, if you just wanted hibernate+Tomcat+connection pooling+clustering, you could have that and only that.

    Bill
  13. Good news. Actually who needs pico or spring when there is already everything in place with JMX. I mean that is what a service is all about. It is a manageable part of your application. If it depends on other services then no problem. Either define it or get the service from the MBeanServer. Such a container would be a very small wrapper around a MBeanServer. There is already everything in place.

    When I say JMX I does not mean that the container should offer
    JMX support. I am talking about the services itself. Although I haven't found any documentation about this nano-jmx I am quite sure they are talking about the container. Maybe that's nice (at least they can claim that they support JMX).

    Funny to see that the others are moving along the way to end up where the JMX spec started. One could call it history is repeating.
  14. Actually who needs pico or spring when there is already everything in place with JMX.

    Anyone who is advocating JMX as a replacement for Spring, or vice versa, has not used both technologies.

    JMX is the superior technology for services that need to be externally monitored, or have their configuration changed at runtime.

    However, JMX is too verbose and cumbersome for lower level application services, and this is where Spring is the better choice.

    In the future, I'm sure there will be more overlap between the two worlds, but right now there are clear distinctions.
  15. Well said!

    Spring's approach focuses on configuring and wiring the _internal_ dependencies of your application objects (simple POJO object references within a single JVM). Using JMX to manage this internal structure is flat out overkill, and kludgy. I'd consider it an abuse of the technology.

    With that said, Spring's container is also a facilty for decorating POJO application objects with value-add infrastructure in a declarative fashion. So with Spring, you can export a POJO "service" (bean) as a JMX-managed MBean if and only if you need standard-based monitoring/management. Similiarly, you might export a POJO as a web-service or an EJB if you need remoting. In all of these cases, this export process is transparent to the managed objects themselves: they stay decoupled from infrastructure, grounded in their problem domain.

    This is a big reason why Spring powered, Hivemind powered, and Pico powered applications are so clean, easy to test, and easy to scale up as requirements grow/change.

    Keith

    Keith Donald
    Interface21 (i21)
    http://www.springframework.com
  16. Actually who needs pico or spring when there is already everything in place with JMX.
    Anyone who is advocating JMX as a replacement for Spring, or vice versa, has not used both technologies.JMX is the superior technology for services that need to be externally monitored, or have their configuration changed at runtime.However, JMX is too verbose and cumbersome for lower level application services, and this is where Spring is the better choice.

    Um, what you say sounds like: JMX (or the JBoss microkernel for that matter) is much more powerful but it is too cumbersome to use, so I use Spring. That's not a very reassuring statement I must say. Particularly not with something like runtime reconfiguration/management in mind, which, for me, has always been _the_ most problematic issue in the construction of server side applications. J2EE has a huge problem in this area with its inflexible idea of "deployment".

    On the other hand keep hearing about magic new features of JBoss, now it's even version 5 we're talking about, but I can't seem to find any documentation on all of this. I have no problem buying a book if that's what it takes. But if I have to go read the source code to be able to use these features, then you are right that it's too cumbersome.
  17. Good news. Actually who needs pico or spring when there is already everything in place with JMX. I mean that is what a service is all about. It is a manageable part of your application. If it depends on other services then no problem. Either define it or get the service from the MBeanServer. Such a container would be a very small wrapper around a MBeanServer. There is already everything in place.When I say JMX I does not mean that the container should offer JMX support. I am talking about the services itself. Although I haven't found any documentation about this nano-jmx I am quite sure they are talking about the container. Maybe that's nice (at least they can claim that they support JMX). Funny to see that the others are moving along the way to end up where the JMX spec started. One could call it history is repeating.

    What you talking about Willis? These containers are going to be implementing JMX. Meaning they will handle all the init stuff for you...
  18. Actually who needs pico or spring when there is already everything in place with JMX.

    Well, you'll typically just expose *specific* components in your application via JMX - namely, the ones that you want to manage via a JMX console. Arguably, JMX is not an appropriate core for a component model, which would imply that *all* of your components depend on it.

    In an application, there are usually many, many fine-grained components that are not supposed to be exposed to the outside in the first place. Consider DAOs etc, or even DAO helper strategies (for LOB handling or the like).

    Considering every little managed object in your middle tier as JMX component is like considering every one of those objects as potential remote service. The latter view has fortunately been abandoned by most people in the meantime.

    Spring takes a different approach in that respect: Managed objects in a middle tier are by default considered as purely local. Many of those objects will never be used in a remote fashion at all, so there's no point in designing them as remote-capable upfront.

    Just if you define an exporter (or multiple exporters) for a component, it is gonna be visible as remote service (under a specific protocol or under multiple protocols) or as JMX component. Your component itself is generally not aware of this, though: It neither implements remote interfaces nor JMX interfaces.

    Juergen
    http://www.springframework.org
  19. JMX[ Go to top ]

    Hm, well said Juergen but in the end this seems gradually going the way I was always expecting. Adding more and more stuff (JMX, 2PC TX, Messaging etc.) to the sweet & simple thing like pico, spring whatever will make it over time as bloated as your regular J2EE server - just more unstable. It is the doom of man that they forget.
  20. JMX[ Go to top ]

    Adding more and more stuff (JMX, 2PC TX, Messaging etc.) to the sweet & simple thing like pico, spring whatever will make it over time as bloated as your regular J2EE server - just more unstable.

    Well, that's not the same by any means: Spring does not provide its own JMX server, 2PC transaction coordinator or JMX message broker - and never will.

    It rather "just" enables you to expose Spring-managed components via your *existing* JMX server, delegate transaction management to your *existing* JTA implementation, access JMS queues and topics of your *existing* message broker in Spring-managed objects.

    Spring also doesn't provide an HTTP server, servlet engine or JSP engine; it doesn't even provide a connection pool. All of the above, from JMX, JTA, JMS to servlet engine and connection pools, needs to be provided by third parties: typically, but not necessarily, by your J2EE server.

    If we talk about Spring supporting JTA, JMS or JMX, we refer to convenient means of working with those APIs. The choice of backend implementations is yours: Spring allows you to plug in individual services there, for example standalone JOTM or ActiveMQ, or access J2EE server facilities.

    After all, Spring is an *application framework*, not an *application server* (or system service provider in general). It provides infrastructure for use within applications, including appropriate abstraction and glue between your application and your system services.

    It's all about decoupling from concrete system services, not about reimplementing a J2EE server's services. A major benefit of Spring is that it allows your components to adapt to the concrete environment - be it full J2EE, plain Tomcat, a desktop application, or a test suite.

    Juergen
  21. JMX[ Go to top ]

    Hm, well said Juergen but in the end this seems gradually going the way I was always expecting. Adding more and more stuff (JMX, 2PC TX, Messaging etc.) to the sweet & simple thing like pico, spring whatever will make it over time as bloated as your regular J2EE server - just more unstable. It is the doom of man that they forget.

    How many times must we dance this dance? As the Spring guys metioned just about everytime you make this assertion, Spring does have its own messaging, jmx, or transaction manager.
  22. JMX[ Go to top ]

    As the Spring guys metioned just about everytime you make this assertion, Spring does have its own messaging, jmx, or transaction manager.

    I assume you mean: Spring does not have its own messaging, jmx, or transaction manager :-)

    Juergen
  23. JMX[ Go to top ]

    As the Spring guys metioned just about everytime you make this assertion, Spring does have its own messaging, jmx, or transaction manager.
    I assume you mean: Spring does not have its own messaging, jmx, or transaction manager :-)Juergen

    Yes! Sheesh! Why can't we edit these posts?!?!
  24. Dance til you drop...[ Go to top ]

    How many times must we dance this dance? As the Spring guys metioned just about everytime you make this assertion, Spring does have its own messaging, jmx, or transaction manager.

    Then, frankly, the spring guys are in denial. For all practical purposes spring does have just that, because it comes bundled with a lot of functionality (and will come with more) and this, for most users this will be a prime reason to use just that. If only, because this particular integration is "proven to work".

    And a simple fact is, that most people _require_ it to come with all the add ons, because they need prove that they work in the first place. And anyone who has ever, say, integrated a third party transaction manager with a third party messaging system will be careful to avoid performing such an integration himself if at all possible....
  25. Dance til you drop...[ Go to top ]

    I fully agree that pre-built integrations are an important part of Spring's value proposition. There is no point in rebuilding Hibernate integration, JMS support etc for every use case. It's better to rely on proven integration code that's guaranteed to be in sync with the core framework.

    Spring is not about providing system services but rather about using them. It is an application framework, not an application server. Spring does not compete with J2EE, they rather complement each other: J2EE provides various system services, Spring allows to conveniently use them when they're available.

    Additionally, Spring offers alternative strategies that work outside of J2EE too (e.g. local transactions), using the same configuration and demarcation style. After all, standalone applications have transaction and data access needs too... Local strategies are also appropriate for test suites, even if the target platform is a J2EE server.

    Juergen
  26. Dance til you drop...[ Go to top ]

    In my experience, in all but the most trivial applications there is an unavoidable amount of glue code that you have to write. Some examples would be:

    1. Code to glue different objects together (services) so they can talk to each other.
    2. Code to get these services the configuration information they need to get their job done.
    3. Code to integrate 3rdparty APIs (particulary service APIs like JDBC or Hibernate)
    4. Code to deploy your application to take advantage of enterprise services.

    Such glue code has nothing to do with your business. Furthermore, hand coded glue code is often invasive (getting it fingers in your application code), easily [b]inconsistently[/b] implemented, and costful to maintain/support.

    Spring flat out eliminates hand-coded glue code. IoC and AOP are the enablers. The J2EE support libraries build on these enablers to deliver J2EE services in a non-invasive way. This brings consistency, as well as a complete decoupling of application code from infrastructure, which goes to building cleaner, more maintainable, and more adapatable systems.

    I suspect this approach is quite a rare find in software, perhaps thats why people who haven't tried Spring on a project sometimes don't believe it.
  27. Dance til you drop...[ Go to top ]

    Juergen, not argueing with it. Let's put it this way: Spring does not lock you in (most of the time). But of course, because of its broad value proposition, it may lock You in. I am just pessimistic out of principle (and experience), not because I particularly like or dislike the technology or the product :-).
  28. Dance til you drop...[ Go to top ]

    How many times must we dance this dance? As the Spring guys metioned just about everytime you make this assertion, Spring does have its own messaging, jmx, or transaction manager.
    Then, frankly, the spring guys are in denial. For all practical purposes spring does have just that, because it comes bundled with a lot of functionality (and will come with more) and this, for most users this will be a prime reason to use just that. If only, because this particular integration is "proven to work". And a simple fact is, that most people _require_ it to come with all the add ons, because they need prove that they work in the first place. And anyone who has ever, say, integrated a third party transaction manager with a third party messaging system will be careful to avoid performing such an integration himself if at all possible....

    I respectfully disagree. As I wrote in at the start of this thread, I was able to easily use just the Spring factory. It was only because that integration was so painless that I tried other features and each one as added independently of the others.

    I am able, for example, to use Springs Hibernate support and dynamic proxy support but not Spring's declarative transaction support because I simply didn't have time to learn it.

    Yet, the sky didn't fall. I'll be the first to admit that the level of support in Spring made it attractive, but the claim that I could use as much or as little as I wanted cinched the deal.

    So far, Spring has delivered. The only dropping I've done has been at home after a productive 8 hour day. :-)
  29. Dude:

    I like the comment and I guess I'll have to do it (with my example code) and put it out for public consumption. I already have done this and I want to put into public production soon because I could use this for business automations.

    David L. Whitehurst aka piratepete irc.freenode.net
  30. Service discovery[ Go to top ]

    A very useful article! After reading all the stuff about type based or identity based service instantiation, I was wondering if nobody in the IoC community thought about the rather old concept of service discovery based on properties that might even change at runtime. It was one of the most prominently presented features of directory services back in the day.

    It's the use case where your code says: I want a service of type Printer. It must support color printing at a speed of at least 10 pages per minute and the print queue should not be busy right now.

    Another thing I'm constantly fighting with is dynamic reconfiguration. For example, if you have a website where users can create projects and each project gets its own database, you have a need to add database connections at runtime and of course they have to be discovered at runtime as well. Does any of these IoC containers allow you to add services at runtime and are they able to store the dynamically added configurations back to their config files?
  31. Service discovery[ Go to top ]

    A very useful article! After reading all the stuff about type based or identity based service instantiation, I was wondering if nobody in the IoC community thought about the rather old concept of service discovery based on properties that might even change at runtime. It was one of the most prominently presented features of directory services back in the day. It's the use case where your code says: I want a service of type Printer. It must support color printing at a speed of at least 10 pages per minute and the print queue should not be busy right now. Another thing I'm constantly fighting with is dynamic reconfiguration. For example, if you have a website where users can create projects and each project gets its own database, you have a need to add database connections at runtime and of course they have to be discovered at runtime as well. Does any of these IoC containers allow you to add services at runtime and are they able to store the dynamically added configurations back to their config files?

    Pico does some of it. It can switch implementations on the fly:
    http://www.picocontainer.org/Implementation+hiding+and+Hot+swapping
  32. Service discovery[ Go to top ]

    Spring also supports hot swapping of implementations using the HotSwappableTargetSource class. Behind the scenes, Spring will build a proxy to the object and the target of the proxy can be swapped out at runtime.

    Spring 1.2 will introduce Spring JMX so that bean properties can be changed easily at runtime using a central access method and with time many of the Spring internal components, specifically BeanFactory and ApplicationContext, will be exposed using JMX.

    We are also working on ways to persist bean property changes back to the configuration file or some other store so that modifications can survive application restarts.

    The crux of this: hot swapping is already supported in Spring, but you have to wait a while until you can have bean property changes persisted back to the config file.

    robh
  33. Service discovery[ Go to top ]

    That's great. But will I be able to actually add a service at runtime, or just swap the implementation of a preconfigured service?
  34. Reconfiguration/hot-swap[ Go to top ]

    Hi,

    I am very familar with an IOC container that is service-lookup based. My understanding, so far, why dependency-injection in IOC containers is useful is that the component is setup and configured prior to use (other than auto-wiring). How does that jive with the notion of reconfiguration, with/without JMX, since most likely the reconfiguration will happen after the component has been created and likely used? Or is it "caveat emptor", in that the implementor must be knowledgeable about how the system is implemented, which arguably is the case for most non-trivial systems anyway. In other words, "any yahoo off the street with x-years of experience" shouldn't be implementing complicated business systems, and must know in detail how a component is created, used, configured and reconfigured?

    Also, how does Spring guarantee that a component is not being reconfigured while it is in use, particularly since the components don't expose any life-cycle semantics to the container? Same question regarding hot-swap: does it mean that only new instances of the component will have the new implementation, or existing instances of the component will be swapped out as well? If exisitng, how will dependent components (the ones that are using the component being swapped out) be notified of the swapout? Do you end up with a mix of diffently configured component instances, possible some with different implementations, based on when they were created?

    In containers with life-cycle support, it is possible to have components to have start/stop semantics, and so reconfiguration can be attempted when the component is stopped, but even then it is not easy for the container to know when to stop the component...i.e. this is rife with threading and other issues. Or, a component could implement a life-cycle interface that explicitly accepts reconfiguration, in which case the component knows how to stop/start/reconfigure itself when given new configuration. You can do that with change-listeners on bean properties, I guess, if the container supported it...but then the component is far more complicated than the POJOs that are always touted, isn't it?

    These are not issues applicable specifically to Spring, but universal issues. Just curious how Spring resolves this.
  35. At the end of the day, IoC is just a fancy name for the age-old strategy pattern. What's the fuzz about?
  36. At the end of the day, IoC is just a fancy name for the age-old strategy pattern. What's the fuzz about?

    I'm very new to IoC (but have been programming for a long, long time). It took a while for the 'Aha!' moment where I realised what its all about. Its about decoupling classes and wiring: Allowing services and relationships between classes to be specified at a single easy-to-configure point. Its also about encapsulation: avoiding the need to use arbitrary system-visible Singletons to hold configuration information.

    I think its very neat.
  37. Dion, is freedom of speech above morality?[ Go to top ]

    Sorry to bother you (for second time) with the same
    question:

    Did you remember that Mike asked explisitely not to be
    linked to and discussed here?

    I will be first to welcome Mike here.
    But he asked for something and, IMHO, it is your understanding and sensitivity at test now.

    Alex V.
  38. Is anybody experienced in migrating business logic layer from session beans to POJOs managed by Spring, HiveMind or Pico. I've got a basic understanding of cons and pros of these frameworks and I've heard about pooling target sources in Spring, but anyway I'd like to hear any opinions.

    Regards,
    Fyodor Kupolov
  39. Rod Johnson's excellent book 'J2EE Development Without EJB' covers this topic very well.

    It talks about moving from EJBs to Spring-managed POJOs, and also goes into detail about whether pooling service objects (as in SLSBs) or whether just instantiating a new service object per request performs better.

    Rather than a reference manual on Spring, it discusses exactly what it says in the title, showing how this can be achieved using Spring.
  40. Here is the quote from the original thread:

    J2EE without Enterprise Java Beans?

    Posted by: Rod Johnson on December 05, 2001 in response to Message #35052 1 replies in this thread

    I completely disagree with the article. Firstly, not all EJB containers are expensive. What about Orion ($1500 per server) or JBoss (open source, free)?

    Secondly, unless a project is quite simple, EJB's simplify, not complicate, the development task. Transparent transaction demarcation and thread management are the main advantages.

    Using EJB also promotes good design--separation of presentation from business logic etc.

    I hear the same words again but now Spring is a sample of good design.
    May be lightweight containers is just another fashion, like EJB ?

    Regards,
    Fyodor Kupolov
  41. Sure, I used to believe. I wanted to believe. Until I took a dispassionate look at whether the benefits of EJB in practice were all they promised--initially based on all the EJB projects in the group of companies I then worked for--and whether there was a better way to achieve the good things in EJB.

    Anyway, 3 years is a long time in this industry. When I wrote that, the choice was EJB or homegrown framework. EJB looked much better in that comparison than it does compared with lightweight frameworks where they're a choice for doing the same thing. (Which is not all uses of EJB.) For example, at that point EJBs were the only game in town for declarative transaction management--one of the key benefits I cited. Now they're not, and you can apply declarative transaction management to POJOs with other technologies.

    Rgds
    Rod