Service components (HiveMind)

Service components in Jucas are normal HiveMind-Services. HiveMind is a sort of Service container which is maintained by Apache .

HiveMind is both easy to use and powerful. Because very good documentation on HiveMind can be found on the HiveMind-Homepage, HiveMind has quite some features and Jucas Services are just HiveMind-Services I just want to give here a brief overview on HiveMind (copied form the HomePage) and explain how Jucas uses HiveMind.

NOTE: for Jucas-0_6-alpha users

Jucas-0_6_alpha is distributed with an older (a few weeks old) HiveMind jar. In the mean time HiveMind (which is like Jucas also in alpha) has changed some tag names. The HiveMind homepage only documents the new tag names and not the old ones (which are used by the HiveMind jar distributed with Jucas-0_6_alpha). However apart of this not much has changed. So if you encounter problems using Services because the hivemodule.xml file can not be parsed replace the tag-names as stated in the following table.

I want to release Jucas-0_6_1-alpha soon. In this release the new HiveMind jar will be included.

HiveMind and its Services

(This is just copied from the HiveMind Homepage)

HiveMind is a centralized registry of services and extension points.

Services are represented as an Java interface accessible within a registry using a unique id. Services are usually singletons, though other service models are available.

Extension points are used for configuration information. Each extension point is a list of elements, also accessible using a unique id. The elements of an extension point are provided by extensions that appear in many modules, which is the basis for allowing multiple modules to work together to form the application.

Frequently, services and extension points are used together; modules contribute to an extension point and a related services makes use of the combined data.

HiveMind combines together a number of modules to form a registry of services and configurations. Each module consists of:

• Extension points

• Services

• Extensions (to extension points)

• Service extensions

Any module may contribute to any other module, including itself.

Each module has a HiveMind deployment descriptor , (hivemodule.xml) . This defines the services and configurations defined by the module, its contributions, and its dependencies on other modules.

Jucas and HiveMind

When the web-app starts up Jucas builds a HiveMind-Registry. (That is what the JucasContextListener is for). The Registry can be gotten from BeanManager.getHiveRegistry(). Note: The Registry can not be gotten from HiveMind.getDefaultRegistry() it won't be in there.

This registry will contain all modules which are in the ClassPath of the web-app. It will also (and this is Jucas specific) contain all the modules which are in the /WEB-INF/jucas/config directory.

The modules in the config directory are normal HiveMind hivemodule.xml files. However their file-name is not hivemodule.xml (so that mulitple can be in one directory). The name can start with anything but must end with .hivemodule.xml (ie my_module.hivemodule.xml).

It was always said that Jucas Services are retrieved from the BeanManager by their name URI. This is true but they can also be retrieved from the HiveMind Registry Jucas provides. There is no difference the BeanManager does internal the same (and nothing else except evaluating a fragment part if present in the URL). Of course if you use the HiveMind Registry you don not provide an URL but just the HiveMind id (the host of the URL you would use with the BeanManager).

That is everything to mention about HiveMind, which can not be found at the HiveMind Homepage. Remember Jucas Services are just HiveMind services and every HiveMind Service is a Jucas Service - they are synonyms. Therefore everything said on the HiveMind homepage is also true for Jucas Services.