The process of implementing distributed service framework based on OSGi (II.)

In this process to complete the spike for Jini, the goal is still to determine the routing of services based on Jini, to find the satisfaction of the requirements.

Jini is developed by the Sun Institute, the goal is to achieve distributed services, so in many places can see it and distributed service Framework is a lot of overlap, to see it for the requirements of satisfaction, and finally to analyze to make a summary.

1, how to realize the remote service register to the service center?

A method for temporarily locating a remote registration service to a service center was not found in Jini.

Jini's service needs and service centers are deployed on the same machine, which can be deployed directly through the Service Management Center to support the dynamic management of services, but this does not meet the requirements of the Distributed Service framework.

2. How to find Service Center service in service application end?

In the search for services, the Jini method is estimated to be similar to Jndi, but the requirement is relatively higher than jndi, because it needs to rely on its own servicecontext to obtain services, this is not very good.

3. Is there a ready-made implementation?

At present, there are several Jini, the most famous of course is Sun's own Jini Starter Kit, but for the implementation of the Distributed service Framework, Newton is a better reference.

4. Do you support cluster?

Since the service and service center is on the same machine, so there is no problem in support of cluster, all the machines in the cluster are deployed once.

5. What resources are available for reference?

Jini can refer to the resources are mainly: www.jini.org, through here can find quite a lot of jini information, the better is:

Http://blogs.sun.com/warren/entry/jini_made_easier_writing_a

Http://www.cheiron.org/seven/manual/html/developer/index.html

Http://jan.newmarch.name/java/jini/tutorial/Jini.xml

From the registration of services, find and route these three requirements to see, Jini can directly meet the only search, because we need just a registration, routing, find the framework of the mechanism, and do not need additional functionality, Jini is a bit and this demand is not very fitting, In particular, the Jini itself is a service framework that is not very powerful, if adopted it will cause also need to transform, stripped of its service that block of mechanism or do compatibility, and Jini in use for Jini itself is too dependent on the package, which we expect the Pojo mechanism is very troublesome, of course, Jini is not without merit, if you look at the Jini implementation framework of the visual services of the monitoring end, it is a very good thing, specifically the full Service lifecycle Management (installation, uninstall, start, stop, and the current running state, etc.) functions.

The simplicity of Jndi and the stickiness of requirements make it our choice to implement a distributed service framework based on OSGi.

After choosing Jndi as the registration, lookup, and routing mechanism for services, we need to evolve the design of a distributed service framework based on OSGi, and in subsequent chapters we will stay under the spike process to analyze the current situation of this distributed service framework.