Home

News: Jakarta HiveMind 1.0 final release

  1. Jakarta HiveMind 1.0 final release (27 messages)

    The Jakarta HiveMind team is proud to announce HiveMind 1.0 final release.

    HiveMind is a services and configuration microkernel; an infrastructure for all types of Java applications. HiveMind encourages the use of best practices, as well as encouraging the aggressive refactoring seen in Test Driven Development.

    A HiveMind application stack consists of a Registry of services and configurations:

    <img src="http://jakarta.apache.org/hivemind/images/FrameworkStack.png"/>

    The top zone, "Application", is your application, responsible for creating the Registry and obtaining services from it. This may be a Tapestry application, or any kind of servlet-based application, a command line tool, or a GUI built on Swing or AWT ... HiveMind doesn't know or care about the application.

    Each service (represented as a yellow circle) is an interface combined with a Plain Old Java Object (POJO) implementation of that interface. These services are containers of business logic, in much the way that stateless session beans are used in a typical J2EE application. In many cases, the few services exposed to the application are facades around larger networks of services.

    HiveMind is responsible for thread-safe just-in-time instantiation of your services. In addition, HiveMind uses the dependency injection pattern to connect your services together.

    Collaborating services are represented as objects (implementing an interface) injected into a service implementation. A service implementation never has to know anything about the lifecycle of a collaborating service, it simply knows that an object with the right interface is provided. This greatly simplifies unit testing, because your unit tests can easily inject mock implementations of the other services.

    HiveMind mates its rich services model to an equally rich configurations model. HiveMind configurations (the blue boxes in the diagram) are containers of XML ... think of them as a kind of generic deployment descriptor for any kind of data needed by your application. You define the configuration point in terms of a simple schema (elements and attributes) and rules to convert contributed XML into Java objects; your services see the end result: a list of application-specific objects ready to be used by the service. You get the benefits of flexible XML configuration without the hassles!

    Combining the services model with the configurations model is extremely effective; it allows significant data-driven solutions to be assembled easily. Because configurations can easily reference services, it becomes simple in HiveMind to build all kinds of complex patterns: pipelines, factories, strategies ... all of the best design patterns become practical, even easy.

    HiveMind also includes a built-in documentation facility, HiveDoc. HiveDoc is a hypertext representation of all the services, configurations and contributions in a Registry, allowing you to easily see exactly how your application is structured.

    HiveMind interoperates well with other frameworks; it is built specifically with J2EE in mind (and explicitly addresses the thread safety and class loader issues implicit in using J2EE), and has explicit interoperability with Spring.

    HiveMind is based on the same four principals that have made Tapestry so successful: Simplicity, Consistency, Efficiency and Feedback.

    HiveMind is available under the terms of the Apache Software License 2.0.

    HiveMind 1.0 has been in development for nearly a year and a half. The HiveMind team consists of James Carman, Erik Hatcher, Harish Krishnaswamy, Howard Lewis Ship and Knut Wannheden.

    HiveMind's home page contains extensive documentation and examples:

    http://jakarta.apache.org/hivemind/


    HiveMind can be downloaded from Apache's network of mirror servers:

    http://jakarta.apache.org/site/binindex.cgi#hivemind-stable

    Threaded Messages (27)

  2. Jakarta HiveMind 1.0 final release[ Go to top ]

    Congratulations to Howard and the whole HiveMind team! This really is a great product. I am using it now on a project for a large financial institution and it is really paying off. Code is naturally cean and modular with less clutter and complexity.
  3. Is it like Spring?[ Go to top ]

    I'm trying to learn Spring, but I found HiveMind is similar to it. Who can tell me what's the different between them? And which one is better to use and study?
  4. Is it like Spring?[ Go to top ]

    I'm trying to learn Spring, but I found HiveMind is similar to it. Who can tell me what's the different between them? And which one is better to use and study?
    Here is a good comparison:

    http://howardlewisship.com/blog/2004/06/hivemind-vs-spring-philosophy.html

    I think both are very good. I just like HiveMind better. Nothing to say you can't use both, too. HiveMind has good Spring integration.

    Ben
  5. Thanks a lot![ Go to top ]

    I will read the article carefully:)
  6. Jakarta HiveMind 1.0 final release[ Go to top ]

    I understand Hivemind is also an approch to have a rich service model work well with a configuration model.Then how does it really differ from the Spring Framework which also looks at similar coupling of service model+configuration model

    What are its benifits over Spring?
    Why should one go for Hivemind?

    Can someone enlighten me more on this topic.

    Tharun G Babu
  7. Congratulations Howard.

    It seems like I'll be using Hivemind soon in a project at a client. There will be plentytof Spring stuff as well, so it'll be interesting to see how they work together...

    a
  8. Jakarta HiveMind 1.0 final release[ Go to top ]

    I read some document of HiveMind,I found that the thought of HiveMind is same as Spring.Why did they do the simlar work?
  9. HiveMind and Spring[ Go to top ]

    This is a constant thread, HiveMind and Spring seem to overlap in functionality quite a bit. In fact, they are similar in spirit, quite different in focus and implementation.

    I've done some work with Spring. I think if you compare adding a logging interceptor to a HiveMind service with doing the same thing to a Spring bean, you'll get a feel for the differences in the frameworks.

    In fact, the previous example shows the underlying difference in philosophies between the two frameworks. Spring provides services in the form of individual classes and interfaces, with "recipes" for how to assemble each one, explicitly, in a single XML descriptor (or in a group of nested descriptors).

    HiveMind provides named services using fully qualified names. The services are simply available, no "recipe" required (alternately, you can consider the fully qualified name to be the "recipe"). You provide a module descriptor for your application specific services, and that is mixed in with the descriptors for any libraries on the classpath (including the HiveMind framework itself). To me, that embraces two of the key philosophies: Simplicity and Consistency.

    HiveMind is built around the idea that you don't want, or even can't have, a central descriptor for your application. It draws some inspiration from Eclipse and its plugin model, where you scan for plugins and startup and build the descriptor for your application from what's available. HiveMind does the same thing, scanning the classpath for hivemodule.xml descriptor files.

    The structure this view imposes is very important for extremely large scale projects (hundreds, even thousands, of services, divided across dozens of modules). It also supports the idea that you may have different configurations of your application, by manipulating which modules are on the classpath at runtime.

    Which brings up the most fundamental difference between Spring and HiveMind: configurations. Spring has the ability to inject a simple map or list into a property of a bean. However, the content of that map or list is specified in-line, in the bean definition.

    HiveMind's primary purpose is managing configuration data; a canonical example is a toolbar that different modules may want to contribute icons into. In HiveMind, you would define a Toolbar configuration point, and different modules would contribute into it.

    HiveMind configurations are extremely rich; internally, there's a construct similar to Digester at work, meaning that the XML your modules contribute into a configuration is visible, to the services which access the configuration, as a list of application-specific Java objects. More Simplicity and Consistency ... and a lot fewer bugs, since this code is written once and tested as part of HiveMind, not your application.

    Combining configuration data seamlessly with services is very powerful. For example, the PipelineFactory builds a service by stringing together a series of filters specified inside a configuration. Tapestry 3.1 is making use of this structure, which allows for nearly unlimited extension points to how Tapestry operates ... without requiring any code changes to Tapestry itself.

    However, it is quite clear that HiveMind will not be competing with Spring any time soon on vertical integrations: Spring has had explosive growth in terms of integrations (with Hibernate, with iBatis, transaction support, JMS support, more stuff than you can name!).

    HiveMind already has basic integration with Spring; if you provide HiveMind with a Spring BeanContext, you can define new services in terms of Spring beans. Of course, this is quite simple, because the POJO/IoC/Dependency Injection model is so small, simple and flexible! That integration (which I hope will be bi-directional someday) will become richer in the future.

    For example, in Tapestry 3.1, there will be tight integration between Tapestry and HiveMind. It will be possible to inject a HiveMind service into a Tapestry page or component property/ If you use the syntax service:mymodule.MyService, a HiveMind service will be injected. But you can instead use spring:MySpringBean to inject a Spring bean instead.

    So, Spring users will be able to do a tiny amount of HiveMind configuration (to link HiveMind to their Spring instance) and work using Tapestry and Spring to their heart's content.

    Finally, I frequently get a question along the lines of Why didn't you just integrate your ideas into Spring? Well, above we've seen that there are basic differences in philosophy between the two frameworks. Neither is right or wrong per se, they simply adopt different developer's views and attitudes. The two key HiveMind innovations, configurations and distributed configuration data, would be very hard to integrate into Spring. For example, Spring has a fixed configuration DTD, and HiveMind has an informal schema that is partly self-defining (and all internally validated).

    Practically speaking, it would take the cooperation and understanding of the entire Spring team to make any one of the changes suggested (such as adding line precise error reporting), and possibly break some backwards compatibility along the way. The cooperative competition of HiveMind may inspire the Spring team to put in that effort, but the idea of a new and (to them) unknown developer coming in an upsetting the apple cart in such a large way is impractical; the time it would have taken me, personally, to learn the Spring code intimately enough to implement any of the HiveMind ideas in Spring is much longer than the time it took to implement the first usable versions of HiveMind. Therefore, it is better for all involved to focus on interoperability.
  10. HiveMind and Spring[ Go to top ]

    First of all congrats to HiveMind team!

    Here are some of my thoughts:
    HiveMind is built around the idea that you don't want, or even can't have, a central descriptor for your application.
    That reduces the chances to understand the effective object structure (i.e. what is really executed) even further. It's already not trivial with Spring with all of its configs and AOP but there is at least a definitive place to look into (config file[s]). With the configs spread all over the class path and assembled dynamically (via contribution), I'm afraid nobody will be able to reconstruct what's going on and how it has come to it.

    I really love the IOC approach but have to admit that when it comes to debugging it's harder to figure out how thing come together. Especially for a new person, i.e. not for the author of the piece of software in question.

    For me, HiveMind sounds a little bit more flexible in what it makes possible but also somewhat more academic. Spring has found the right mix of flexibility and 'practicability' :-)

    Al
  11. HiveMind / Big View and HiveDoc[ Go to top ]

    First of all congrats to HiveMind team!Here are some of my thoughts:
    HiveMind is built around the idea that you don't want, or even can't have, a central descriptor for your application.
    That reduces the chances to understand the effective object structure (i.e. what is really executed) even further. It's already not trivial with Spring with all of its configs and AOP but there is at least a definitive place to look into (config file[s]). With the configs spread all over the class path and assembled dynamically (via contribution), I'm afraid nobody will be able to reconstruct what's going on and how it has come to it.I really love the IOC approach but have to admit that when it comes to debugging it's harder to figure out how thing come together. Especially for a new person, i.e. not for the author of the piece of software in question.For me, HiveMind sounds a little bit more flexible in what it makes possible but also somewhat more academic. Spring has found the right mix of flexibility and 'practicability' :-)Al
    The right mix will be particular to each developer.

    However, your comment is one that has concerned me from day 1 ... which is why I've been uncomprimising in support of HiveDoc. HiveDoc is automatically generated HTML documentation derived from your descriptors. It's hyperlinked together so you can see how everything fits together.

    In terms of pragmatic vs. academic ... I will always favor a more "academic" (that is, rigorous and free of ambiguities) approach, then gradually ease up. You can see this in the evolution of HiveMind to release 1.0, where the descriptors have gotten more and more stripped down, and the key built-in services (particularily BuilderFactory) have started doing more and more "guesswork". It's very easy to loosen the reigns, but very hard to bring order out of chaos.
  12. HiveMind / Big View and HiveDoc[ Go to top ]

    People ,
    I'm working with Hivemind in a big application for government
    from Argentina (Tax Agency ). I saw many frameworks for IOC , but Hivemind he is the best one.


    Good work HLS.
  13. HiveMind and Spring[ Go to top ]

    Mr Howard Lewis Ship,
    MANY MANY THANKS for the comparison. And for developing Hivemind of course!
    I dream about a day, when similar comparisons will be available for all software projects!

    Dear developers, please follow this wonderful example and write what differentiates your project from similar offerings.
  14. HiveMind and Spring[ Go to top ]

    First of all, congratulations on the final release, Howard! HiveMind certainly has an interesting focus and a unique configuration model, inspired by the Eclipse plugin model. I appreciate that the lightweight container movement explores different paths :-)

    Regarding HiveMind and Spring, I think it's important to strengthen the point that Spring's scope is *much* wider than HiveMind's. HiveMind is basically a core IoC container with AOP-like functionality and a sophisticated configuration mechanism. Spring on the other hand consists of the following:

    1. core IoC container with pluggable configuration formats (XML as default)
    2. sophisticated proxy-based AOP framework (fully AOP Alliance compatible)
    3. application context with resource loading and message access abstraction
    4. transaction management abstraction (with pluggable backend strategies)
    5. data access object abstraction (data access exception hierarchy etc)
    6. sophisticated JDBC data access support (including BLOB/CLOB access etc)
    7. sophisticated data access support for Hibernate, JDO, OJB, iBATIS SQL Maps
    8. lightweight remoting via Hessian, Burlap, JAX-RPC, RMI, HTTP invoker
    9. support for access to and implementation of EJBs (both local and remote)
    10. support for convenient sending and receiving of messages via JMS
    11. additional middle tier services like mail sending and scheduling
    12. generic web MVC dispatching infrastructure (for both web MVC and remoting)
    13. request-driven web MVC framework (with support for form controllers etc)
    14. web view support for JSP, Tiles, Velocity, FreeMarker, XSLT, PDF, Excel
    15. included Struts and JSF support (for easy access to a Spring middle tier)

    Arguably, HiveMind just covers point 1 and partly point 2 and also 9 (IIRC) of the above. As is quite obvious when comparing the frameworks on their whole, Spring is much more than "just" an IoC framework with AOP capabilities: A very important focus is on lightweight middle tier facilities (points 3 to 11), and also on web support (points 12 to 15).

    A concrete example: One of the most popular features of Spring is the generic transaction management, which gives you the full power of programmatic or declarative transactions with pluggable backend strategies. Your code can easily adapt to a concrete environment, be it native JDBC transactions or JTA, through configuration. Combined with the support for a wide variety of persistence strategies, this gives you full-fledged local middle tier support.

    Note that Spring is designed such that any of its parts can be reused as far as possible. This means that you can choose to use just the IoC container, just the AOP framework, or just the JDBC support. Or you can easily leverage the transaction management facilities completely without Spring's core container. Or you can use Spring's HibernateTemplate for implementing your DAOs, without having to manage your DAOs as beans in a Spring bean factory.

    As an example for reuse, Bob Lee has combined Spring's transaction management with his own DynAOP framework with great success. This was possible through the AOP alliance interfaces, supported by both Spring and DynAOP. There is simply no need to reinvent those middle tier facilities just because you chose another core container!

    Regarding the point of threaded services: Note that Spring has been supporting pluggable TargetSources since last November, including ThreadLocalTargetSource, PrototypeTargetSource and CommonsPoolTargetSource - so this is not a unique feature of HiveMind. As a side note: Interestingly, most people still use the default SingletonService for most of their services.

    Regarding configuration formats, Spring provides a default XML configuration format that follows a DTD, because we found that this eases external validation and tool support. The XML parsing format is completely pluggable through the XmlBeanDefinitionParser interface, so it would be as straightforward as possible to add a different XML-based configuration format.

    Finally, regarding specifying references and values in-line in the bean definition: Spring has supported placeholders since its very early stages, allowing to externalize configuration settings to properties files or any other external configuration source, simply linking them into XML bean definitions via Ant-style ${...} placeholders. Have a look at the sample applications, which externalize their data access configuration this way.

    Juergen
  15. HiveMind and Spring[ Go to top ]

    Thanks for the post! I'm the first to admit that HiveMind is far behind Spring in terms of inegrations with 3rd parties. However, the HiveMind vision is to eventually have the 3rd parties include hivemodule.xml deployment descriptors with their JARs so that everything fits together with minimal end-developer effort. In the meantime, we'll leverage Spring or whatever else to achieve these goals.

    Configuration support is more than just ${...} style replacements (which are supported inside HiveMind quite elegantly). The meat of configurations is the <schema> approach to defining what can be contributed to configuration points (or used as parameters when invoking a service implementation factory). In addtion, HiveMind is focused on the problems caused by lots of modules contributing to the same configuration point, which raises issues about ordering and conflicts (which are addressed by HiveMind as well).

    In fact, the configurations were the driving force for HiveMind, and the need for services (to access and manipulate those configurations) was secondary ... however, the ability to mix and match the two results in some terrific, elegant, powerful solutions. Often, the HiveMind module deployment descriptor transcends into a higher-order (declarative) programming language.

    Obviously, the HiveMind/Tapestry integration addresses the web UI issues.

    The threaded model (and pooled model) are rarely needed, singletons really do rule. But when you need them, you need them! Having thread local data without dealing with ThreadLocal is wonderful (in both Spring and HiveMind).

    So ... any thoughts on integrating HiveMind with Spring from the Spring side?

    Back a TSS Symposium, Rod and I talked about that kind of tight integration, so that Spring could gain from HiveMind's configuration model (which would be hard to add to Spring, since it relies on a dynamic schema, not a fixed DTD). Any thoughts?
  16. HiveMind and Spring[ Go to top ]

    Howard

    I would be interested to discuss such integration, offline. It makes sense to look at leveraging HiveMind's strengths rather than build similar capabilities in Spring, for users that might benefit from your extension point model. There are going to be a number of dynamic capabilities in Spring 1.2, but they're quite different from HiveMind's approach.

    HiveMind users can gain from all the work that has gone into Spring's transaction management, DAO and integration capabilities, which are decoupled from the Spring IoC container. Of course you should be able to manage such Spring components via Dependency Injection in a HiveMind container: it's important to emphasise that we're all on the same page wrt a POJO model, and the interoperability benefits are clear.

    Of course we're both Apache license, which makes things easier, too...

    Rgds
    Rod
  17. HiveMind and Spring[ Go to top ]

    However, the HiveMind vision is to eventually have the 3rd parties include hivemodule.xml deployment descriptors with their JARs so that everything fits together with minimal end-developer effort.
    Spring takes a different approach to achieve more than that: It offers dedicated integration and convenience classes for those third-party modules. For example, all supported persistence strategies are integrated with Spring's transaction and data access object abstractions: We can't achieve this by simply including a deployment descriptor in a third-party jar.

    I guess one of the key differences here is that Spring aims to provide full-fledged middle tier support, as independent from the core container as possible. You could easily use Spring transactions with HiveMind... It's effectively a complete transaction management API, with a variety of prebuilt implementations. This is much more than just configuring a third-party tool.
    Configuration support is more than just ${...} style replacements (which are supported inside HiveMind quite elegantly).
    I'm aware of this, of course. I just wanted to point out that Spring does support externalization of configuration properties; it does not require to put all property values in XML files (which you more or less implied above).
    In addtion, HiveMind is focused on the problems caused by lots of modules contributing to the same configuration point, which raises issues about ordering and conflicts (which are addressed by HiveMind as well)
    As I said, I consider this a quite unique configuration strategy (well, inspired by Eclipse, but at least unique in the IoC area). Spring rather focuses on centralized configuration files for an application; of course, you can easily split those into multiple files, load them by file patterns, load all config files with a given name from jar files, etc.
    Obviously, the HiveMind/Tapestry integration addresses the web UI issues.
    Spring goes far beyond that, i.e. it offers far more choice: We support our own web MVC framework, Struts, and JSF in the core distribution; for WebWork and WebWork2, the OpenSymphony guys provide various integration strategies; and there's a clearly documented strategy for Tapestry integration. Therefore, we explicitly support all major web frameworks out there...
    So ... any thoughts on integrating HiveMind with Spring from the Spring side? ...so that Spring could gain from HiveMind's configuration model (which would be hard to add to Spring, since it relies on a dynamic schema, not a fixed DTD).
    I don't see why a dynamic schema would be a problem for Spring. I already stated that bean definition reading is completely pluggable, and there's even an explicit XmlBeanDefinitionParser strategy to ease implementation of an XML-based format. You can easily parse a dynamic schema there, just like you can parse a DTD-based format...

    What would HiveMind support look like? A Spring FactoryBean that exposes a component from a HiveMind registry, accessible for bean references in the Spring container etc? That would certainly be possible, similar to how we already allow to link in JNDI objects and local SLSBs (and all sorts of remote proxies). I haven't thought hard about such HiveMind integration yet, though...

    Juergen
  18. HiveMind and Spring[ Go to top ]

    In addtion, HiveMind is focused on the problems caused by lots of modules contributing to the same configuration point, which raises issues about ordering and conflicts (which are addressed by HiveMind as well).
    I guess what I don't understand is, at some point, you're actually building an application, right? For my application, I want to configure the services I use and pull them all together in one place, not have my services defaulted by the jar provider. They're just providing me some class library that does something and has some API, I'm the one who's putting it together with other pieces to build an application.
    In fact, the configurations were the driving force for HiveMind, and the need for services (to access and manipulate those configurations) was secondary ... however, the ability to mix and match the two results in some terrific, elegant, powerful solutions. Often, the HiveMind module deployment descriptor transcends into a higher-order (declarative) programming language.
    Ick. This doesn't sound like what I want from a configuration, which is something easy to read, understand, and tweak, even without deep knowledge of the technology.
  19. HiveMind / Ecapsulation[ Go to top ]

    What HiveMind gives you is a higher-level encapsulation of the services provided in a JAR. More than just compiled Java classes, the services can be configured more intricately. For example, the hivemind.lib.PipelineFactory doesn't define a pipeline; it defines a factory that can build any number of pipelines, using any number of interfaces.

    I think HiveMind solves some difficult integration problems using these kind of techniques. In a Spring application, you may combine several classes provided in one or more JARs but you have to be "aware" of all of them.

    In HiveMind, you can cherry pick the key "facade" services provided by a module, even though that facade may be dependent on any number of additional services. The facade is defined by its own module, and your code and configuration need never be concerned with how it is implemented ... just its qualifed name and service interface.

    This approach is yet another good seperation of concerns, and leads to simpler services (just more of them), and higher levels of reuse. It makes things easier to test as well.

    Finally, you said "you are building an application" ... what happens when the "you" is several dozen developers in many different geographic locations? For Vista, we had something like thirty developers in Mass., Vancouver B.C. and (somewhere in) India. What we needed, what HiveMind was designed to provide, was an infrastructure where we wouldn't be stepping on each other's toes ... where we wouldn't be getting constant merge conflicts on central files.

    HiveMind directly addresses those needs, and allows an equivalent application to be created with vastly smaller amounts of code.

    As I'm working over Tapestry 3.1 using HiveMind, I'm reaffirming for myself that HiveMind is the correct path; Tapestry itself consists (so far) of half a dozen sub-modules. This keeps each descriptor short, focused and readable ... but there are still the issues with integrating contributions from the different modules.

    HiveMind 1.1 will extend further in this direction; I'm finishing up code to allow configurations and services to be private ... invisible except within the module.
  20. I was just at the Utah nofluffjuststuff symposium, and found that Hive Mind was quite popular there. It's great to see more momentum behind the lightweight container <or insert your favorite buzz word> movement.

    Hivemind advances the state of the art with a dynamic configuration model.

    As to a comparison, Spring's got more prepackaged services to choose from, and Hive Mind has a richer, more dynamic model. Said another way, Spring has broader community support, including services, but Hivemind has a more dynamic container. Both have a place.
  21. HiveMind momentum[ Go to top ]

    I've been surprised at the number of people coming up to me and saying "we're using HiveMind in our production app". They've beaten me to the punch.

    I've been using HiveMind in my current client engagement with great success. I've rigged things so that HiveMind services are injected into my pages as properties (kind of a preview of what will be available in Tapestry 3.1).

    In addition, I've been using HiveMind with Tapestry 3.1 itself with terrific success. One of the great things about working with any of the dependency injection models is the twist on the development cycle. I can create a service interface and an implementation. Anything too tricky becomes another services, injected as a property.

    For example, when coding a service that locates a Tapestry engine instance from a shared pool, the first step is to identify the locale. That involves querying the HttpServletRequest, which is only a few lines of code ... but I expect to do some more work in that area in the future (narrowing the possible locales that are accepted). So that became another service interface.

    Using EasyMock, I can test my engine accessor service, using mocks for the other services (such as the one that identifies the locale). I don't write implementations of those collaborating services until after I've finished coding and testing my primary service (the engine accessor, in this case).

    During the process, I may change the collaborating service interface ... but since there's no implementation, that rarely causes any issues outside of my unit tests.

    Once I'm happy with my primary service, I can then go code one of the other collaborating service implementations. Lather, rinse, repeat.

    One of the things making the code for Tapestry 3.l so much easier is threaded services. Threaded services in HiveMind are services that are singletons for the current thread, not globally. Threaded services are useful for holding request-specific information, such as the HttpServletRequest and related objects.

    Underneath the covers, the proxy object uses a ThreadLocal, but none of my code has to care ... it's just an object of the correct interface to invoke methods on.

    So HiveMind becomes this rich "object soup", where all the information needed by any particular service is just available, ready to be plugged into any service implementation.

    I find it quite liberating; I can code naturally, my many concerns are kept very seperated, I can test easily and there are very, very few code paths through my code. All the normal code paths about looking up or creating various collaborating services (or objects, or whatever) just evaporate.

    Back to me current project; because it's a translation of a JSP site to a Tapestry site, there's the issue of mapping old requests to new. I use a HiveMind service and a matching HiveMind configuration. The configuration recognizes particular URL patterns and query parameters (using regular expressions) and translates them into new URLs. The service uses the configuration and does a server-side redirect. For example:

        <redirect match-path="/products/thread.jsp"
          query-string-pattern="tid=(\d+)"
                 redirect-path="/app?service=external/ProductThread&amp;sp=l{1}"/>

    (Hope that comes out).

    Anyway, I haven't done enough work with Spring to get the same joy there ... I'm sure it's there, but my personal connection to HiveMind makes it more intense.
  22. First of all,

    I want to say that I have no experience with lightweight containers.
    I just started working with Hivemind a few weeks ago (1.0rc2) and I was quite amazed by several features.

    First of all, the concept of "service models" (or how should services be instantiated). Hivemind provides 4 models (primitive, singleton, threaded and pooled).
    What I found terrific is the capability to mix service models in call-chain like in: "A calls B" where
    -A is singleton
    -B is threaded (one new instance for each thread)

    With dependency injection of B into A (constructor or setter, HiveMind supports both), one may wonder: "how can a singleton instance of A get -at construction time- an instance of B (and store that instance into a member of A) that will be different for each thread?
    If you had to do that by yourself, how would you do?
    - forget about DI and pass the threaded instance of B as an arg to methods of A
    (ugly and heavy)?
    - forget about A being a singleton and force it to be threaded as well (not very scalable an sometimes problematic if A needs to acquire a resource that is unique)
    - ?
    Actually, Hivemind provides the 3rd way ;-) This is transparent for you!
    In the detail (as far as I could see) all this "magic" is done by proxying B and
    injecting the proxy into A at construction time, then when A calls a method of B, the proxy will decide to use a different instance of B (depending on the current thread or instantiate B if the current thread is not yet associated with any instance of B).

    Moreover, the notion of service models is something dynamic: you can provide your own if you have special needs (until now I did not discover such a need but I think it could perfectly occur in some projects, like the need to create a new instance of B at _every_ method call -even in the same thread- for instance).

    Second point that I particularly like in Hivemind is the way to define a specific schema for the configuration of a service, and the ability to "contribute" to the configuration of a service from different modules; for instance, you can declare your service interface and its config schema in one module, define its implementing class in another module, and contribute to its configuration from two other modules. From your service class viewpoint, you will get all the configuration in one time, merged bu HiveMind.

    Third appreciated point is the capability to break down the project in "modules", ie jar files containing classes + a Hivemind config file, and then to let HiveMind "plug" all these modules to one another.

    Now let's talk about some weak points (at least from my viewpoint):
    - the interceptor mechanism. Although interceptors are important (nobody would disagree on that, I think), the way you must implement them in HiveMind is a little bit awkward (read: needs too much work). I would have expected to implement one Interceptor class (possibly implementing a specific interface), and that class would be instantiated and called for each service to which the interceptor is added. In HiveMind, creating an interceptor requires more work: you need to create an interceptor factory service, that factory must create each interceptor as a proxy to the service it must intercept (so you create as many interceptor classes -dynamic proxies or javassist classes actually) as there are services to be intercepted.
    This means that if you chain 10 interceptors for a service, you have 10 proxy classes for your service. Maybe it would be possible to extend HiveMind to support for more "lightweight" interceptors, and having a possibility to chain them without having a proxy generated (even behind the scene) for each of them.

    - the lack of support services for integration with very common libraries. I need to use Hibernate in my project, I would like to have some "standard" HiveMind services that inject a Session to my DAO services, and also manages
    transaction (something like EJB, but maybe simpler, I am not sure all possible transaction demarcations in EJB are really necessary...)

    Of course in all that there is nothing that could not be quickly added to the HiveMind core, so I am sure these will not be weak points for long!

    In conclusion, I would like to congratulate the HiveMind team for their valuable work. I hope I did not make too many mistakes in my descriptions (as I said, I just started a few weeks ago with HiveMind).
  23. James Carman is working on adding AOP-alliance style interceptors to HiveMind. I like the Javassist approach because of the power and raw speed. There's also example code showing how to create JDK proxies as interceptors. That's why I love interfaces ... it just doesn't matter what the implementation is.

    More integrations, either native, as as wrappers around Spring, will certainly show up in HiveMind 1.1.

    Untlike Tapestry's lethargic pace, we hope that a HiveMind 1.1 will be available in just a couple of months ... even though we have no idea what, exactly, will be in it!
  24. Congratulations[ Go to top ]

    Congratulations!
  25. HiveMind - my 2 c[ Go to top ]

    As for me, it's seems that HiveMind is simpler than Spring (I think because of spring integration with everything - which is a good feature but a way to intrusive).
    Also it would be very nice not to write methods for dependency injection, i.e.

    public class Consumer {
       protected Service instance = null;

       public void businessMethod() {
          ....
       }

       /* Here comes the injection methods */
       public void setInstance(Service service) { instance = service; }

    }

    Off course it's automatically generated by all IDE but I think (as soon as HiveMind uses byte code manipulation) it would be nice to have dependencies set without additional method (as one possibility).

    Anyway thanks' allot for such a nice framework. It makes my work easier :)
  26. HiveMind - my 2 c[ Go to top ]

    As for me, it's seems that HiveMind is simpler than Spring (I think because of spring integration with everything - which is a good feature but a way to intrusive).
    Sorry, I don't get your point here: Why are prebuilt integrations - which are entirely optional - intrusive? They are a pure convenience...

    The Spring core does not impose any dependencies (except for Commons Logging) on you. All other dependencies just when apply when you're actually using the respective integration classes: i.e. dependency on Hibernate just applies when you're using the Hibernate integration classes, etc.

    And if Spring wouldn't provide those integration classes out of the box, you'd usually have to code some yourself (for the actual tools that you're combining with Spring)... Do you really want to implement and maintain those transaction strategies and DAO templates yourself?

    One could rather argue that HiveMind's approach is intrusive: It demands HiveMind service descriptors in the third party jars, requiring them to know about HiveMind and maintain those descriptors... (At least that seems to be Howard's vision; feel free to correct me.)
    Also it would be very nice not to write methods for dependency injection (...) Off course it's automatically generated by all IDE but I think (as soon as HiveMind uses byte code manipulation) it would be nice to have dependencies set without additional method (as one possibility).
    Well, it would be trivial for any IoC container to support such a feature, but all the popular ones currently deliberately choose *not* to do this. The problem is that your application classes would then depend on being managed by a container, as you can't use them with programmatic initialization (i.e. direct instantiation and population in plain Java code) anymore...

    Juergen
  27. HiveMind - my 2 c[ Go to top ]

    I completelly agree with you , Juergen, about setters, now I know why do I need all this injection methods.
    But I don't agree with you about integration staff.

    <QUOTE>And if Spring wouldn't provide those integration classes out of the box, you'd usually have to code some yourself (for the actual tools that you're combining with Spring)... Do you really want to implement and maintain those transaction strategies and DAO templates yourself?</QUOTE>

    The main question is "do I need it?" some times yes, and it's more than valuable but sometimes not. Spring is very nice and usefull project but sometimes I need a pure IOC container wihch has more features than PICO, that's when HiveMind is more appropriate than Spring, IMHO.
  28. HiveMind - my 2 c[ Go to top ]

    The main question is "do I need it?" some times yes, and it's more than valuable but sometimes not. Spring is very nice and usefull project but sometimes I need a pure IOC container wihch has more features than PICO, that's when HiveMind is more appropriate than Spring, IMHO.
    You have a point there regarding scope: You shouldn't need to bother with complexity for features that you don't need. However, note that Spring is highly modular - it's just bundled! Have a look at the packages and the separate jar files in the distribution. You can have a pure IoC container will full configuration power, without all the integration stuff: Just take spring-core.jar (~240 KB) from the Spring distribution, and off you go.

    The reason why we ship most integrations in the core download is that we don't want to force our users to worry about version compatibility etc when combining the core with extension packages. All integrations in the Spring core distribution are fully coherent and tested. The point is that you're still able to grab the jar files that you need and don't bother about the rest! Have a look at readme.txt for a detailed description of the packages and jar files.

    Juergen