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

The previous article said that after the analysis of the decision to choose Jndi to implement the service of remote registration, search and routing, in this blog to detailed analysis based on Jndi how and OSGi integration to implement the service remote registration, lookup and routing.

1. Remote Registration

OSGi DS Registration is currently registered directly in the local service instance, to support remote registration you first need to modify the DS Registration Service section of the code, in the DS description of the need to add a configuration item to support the registration of services to the Remote service center, for example:

<service>
<provide interface="cn.org.osgi.opendoc.bulletin.service.WebCommand"/>
<server>jnp://10.100.100.100:1099,jnp://10.100.100.101:3099</server>
</service>Register directly with InitialContext for registration, but here to take a different strategy, is usually jndi registration is bound to the actual object of the instance, but to note that in fact, in the Distributed Service Framework system, services are distributed deployment, service center is only a registration, Routing, then in this case, only the relevant meta information of the service can be registered to the service center, so this time we will provide a service meta information object, and then bind this meta information object to Jndi, here is a problem involved in the name of Jndi how to take, This name makes it easier to find a service, while ensuring uniqueness.

Can see that in this implementation, the most important thing is the service Meta information object, this metadata object should contain the same information as the OSGi service model, but also need to include the service status information, because contains state information, called Meta Information object is a bit incorrect, or simply call service or serviceinfo.

2. Remote Call

The remote call should be classified as a reference to the remote service and the invocation of the remote service two parts, because the Lazy init service is the first remote lookup service, but does not occur, so here is also divided into two steps to describe.

Referencing remote services

Reference to the remote service this block. The current implementation of Jndi is certainly difficult to meet demand, according to the OSGi service model, the reference service is the interface name that provides only the service, at most, by adding certain properties of the service to qualify the scope of the service, while Jndi specifies the name lookup directly when looking for the bound object. One-on-one, but the services available in the OSGi service model are likely to be multiple, to see how to modify the implementation of this requirement.

The first is still to modify the DS description to support referencing remote services, such as:

<reference name="CommonDaoService" interface="cn.org.osgi.module.hibernate.service.CommonDaoService" bind="setCommonDaoService" unbind="unsetCommonDaoService"policy="dynamic" server="jnp://10.100.100.100:1099"/>

When looking for services at a remote service center, this should be done by extending the Jndi lookup by using Jndi to pass filtering conditions such as the interface, attributes, and so on of the service that needs to be found to the server side. The Jndi Service Center finds the qualified service Meta information object from the registered service, based on the filtering criteria, after receiving the request. and returns a collection of service meta information objects to the caller, after which the lifecycle Management object determines the subsequent actions, and the lifecycle Management Objects are analyzed in detail in the latter chapter.

Invoke remote Service

When a remote service is invoked, one of the configurations that should be provided at this time is whether the service center can be skipped directly to the other end of the service (in some cases this may be required), and the configuration of the synchronization call and the asynchronous invocation is supported.

When invoked, a communication mechanism can be passed to the interface, method, and parameters of the requested service to the service center or the corresponding service provider, and when the service provider end is processed, the communication mechanism returns the processing result to the caller.

After the analysis above, we can see that the registration and lookup of services based on Jndi is not a difficult task, and it is more complicated to analyze the management of the lifecycle in the later chapter, and the lifecycle management is much more complicated than the lifecycle management of OSGi DS after entering the distributed environment.