HiveMind 序説

  
public String myMethod(String param)
{
  if (LOG.isDebugEnabled()) 
    LOG.debug("myMethod(" + param + ")");
    
  String result = // . . . 
  
  if (LOG.isDebugEnabled())
    LOG.debug("myMethod() returns " + result); 
    
  return result;
} 

This approach doesn't do a good or consistent job when a method has multiple return points. It also creates many more branch points within the code ... basically, a lot of clutter. Finally, it doesn't report on exceptions thrown from within the method.

Let HiveMind add a logging interceptor to your service. It will consistently log method entry and exit, and log any exceptions thrown by the method.

The following descriptor snippet defines a service, provides a core service implementation (using <create-instance>), and adds method logging (using <interceptor>):

<service-point id="MyService" interface="com.myco.MyServiceInterface">
  <create-instance class="com.myco.impl.MyServiceImpl"/>
  <interceptor service-id="hivemind.LoggingInterceptor"/>
</service-point> 

private SomeOtherService _otherService;

public String myMethod(String param)
{
  if (_otherService == null)
    _otherService = // Lookup other service . . .

  _otherService.doSomething(. . .);
  
  . . .
} 

How the other service is looked up is specified to the environment; it might be a JNDI lookup for an EJB. For other microkernels, such as Avalon, there will be calls to a specific API.

In addition, this code is not thread-safe; multiple threads could execute it simultaneously, causing unwanted (and possibly destructive) multiple lookups of the other service.

Let HiveMind assign the other service as a property. This is dependency injection. HiveMind can inject dependencies using JavaBeans properties or constructor arguments.

private SomeOtherService _otherService;

public void setOtherService(SomeOtherService otherService)
{
  _otherService = otherService;
}

public String myMethod(String param)
{
  _otherService.doSomething(. . .);
  
  . . .
} 

HiveMind uses a system of proxies to defer creation of services until actually needed. The proxy object assigned to the otherService property will cause the actual service implementation to be instantiated and configured the first time a service method is invoked ... and all of this is done in a thread-safe manner.

Find a properties file or XML file (on the classpath? in the filesystem?) and read it, then write code to intepret the raw data and possibly convert it to Java objects.

The lack of a standard approach means that data-driven solutions are often more trouble than they are worth, leading to code bloat and a loss of flexibility.

Even when XML files are used for configuration, the code that reads the content is often inefficient, incompletely tested, and lacking the kind of error detection built into HiveMind.

private List _configuration;

public void setConfiguration(List configuration)
{
  _configuration = configuration;
}

public void myMethod()
{
  Iterator i = _configuration.iterator();
  while (i.hasNext())
  {
    MyConfigItem item = (MyConfigItem)i.next();
    
    item.doStuff(. . .);
  }
} 

HiveMind will set the configuration property from a configuration point you specify. The objects in the list are constructed from configuration point contributions and converted, by HiveMind, into objects. As with services, a thread-safe, just-in-time conversion takes place.

The type and number of extension points and how and when your code makes use of them is entirely up to you, configured in the module deployment descriptor.

In complex environments, such as EJB containers, you will often have to deploy your code and then test it from the outside. EJB code in particular is hard to test because collaborating EJBs make use of JNDI to access each other. It is very difficult to "stub out" part of the overall application for testing purposes.

Making code testable is a key concern of HiveMind, and shows up in its general testing strategy:

• Because HiveMind services are simply POJOs, your unit tests can simply instantiate them directly.
• HiveMind services are always identified by interface, so it's easy to provide a mocked-up implementation of the interface.
• Services collaborate via dependency injection, so it's easy for a unit test to wire a service to real or mock implementations of collaborating services.
• Because configuration data is just lists of Java objects, unit tests can easily create objects suitable for testing.