Implementation of Distributed Service Framework (DSF) based on SPRING-DM (I.)

After the previous analysis of the Distributed Service Framework blog, the formal renaming of the previous series of distributed service framework based on OSGi (by the way of the Distributed service framework to use DSF abbreviation), because it has been decided to implement based on SPRING-DM, why, And why must it be SPRING-DM, instead of just saying spring?

Today is SPRING-DM 1.0 release of the big day, not easy ah, did so long, specific how has not had time to scrutinize, but before the useful 1.0 m2, already feel very good, I believe 1.0 release will not be disappointed.

In my eyes, spring is a big thing, in fact, DSF need not many things, but also want to maintain the micro-core and extensibility, plug-ins, with a good extension of support framework is undoubtedly the best choice, OSGi is undoubtedly a good choice, But there are so many things that OSGi has to do for itself, and SPRING-DM is the best choice to meet my two-point requirements, with a plug-in framework and a lot of usable and powerful things, In particular, spring's transparency in local invocation and remote invocation provides excellent design support and guidance, such as spring-provided hessianserviceexporter, Jndiobjectfactorybean, and so on. And when spring and OSGi are combined, you can choose the enhancements of spring that you need, depending on your needs, without having to embrace the entire spring, and, of course, spring is not completely stripped off, and it will be much better after SPRING-DM 1.1.

In the previous analysis of the Distributed Services Framework blog, has said that in fact, to achieve DSF concise say is: efficient storage, search strategy + efficient communication strategy + meet the needs of the service model + strong integration capabilities, in fact, the most important here, but also strong integration capabilities, why, because of it, The top two key points are quite a few alternatives, need to make a different choice according to the situation of the system operation, this time requires the DSF to have the very good integration ability, enables the very convenient to carry on the different realization plan's switching, this spring has already proved many times to the world, For these reasons SPRING-DM honored to be chosen as DSF.

Take a look at the blog based on the previous analysis of the Distributed service framework and the choice of SPRING-DM after the DSF became:

is not feel and before the DSF figure there are a lot of different places, as to why it will become so, you can look at the analysis of Distributed Service Framework blog, not in this detail, this will be detailed introduction under the current DSF first version v 0.7, that is, each part of the above figure:

First, the overall situation, it is still divided into service applications and service centers, but it can be seen from the diagram that the mechanism of service lookup and invocation differs from the previous one, in which the service only registers its meta information directly in the service center, which is DSF by the service center to the distributed cache db:memcachedb. When the service application side makes a service call, it will directly access the Memcachedb to find the access mechanism of the target service, and then communicate directly with the target service application, rather than through the service center route, and here is a little bit of why memcachedb is used, In fact, to solve the DSF in the efficient storage, look for the mechanism, of course, there is actually a detail, that is cluster consideration, you can think, if the target service metadata is directly cached in the service application side, then when the target service meta information changes, it is a very troublesome thing to inform, So simply find something to support cluster persistent and efficient caching, but fortunately with memcachedb, of course, you can also according to the actual needs of the application you are facing, for example, your target service can not exist the phenomenon of meta information change, That can simply cache the target service's meta information to the service application (even if this step can be done directly during the deployment period), these DSF can be considered after the later version of the mechanism adjustment support, but in V 0.7 will be used in the schematic scenario.

After the change of mechanism, the service center becomes very simple, and the pressure is very small, it will need to assume more responsibility for the management of services and monitoring, gradually will increase the pressure, here is not to talk about it too much, or to see the service application, in fact, the V 0.7 need to do the work:

1, Service Search

This service lookup is responsible for and memcachedb communication, according to the service model for the filtering of services, only to consider switching to other search methods (such as based on Distributed file system, service lookup, local cache, etc.), because it is based on SPRING-DM, will not have any problems.

2. Publishing Service

Using spring's serviceexporter to implement, in V 0.7, the only way to provide jndi for the time being is to use the JBoss JNP, the Hessian, WebService release, which is directly supported by spring. :), it is necessary to implement an integration strategy when the service application is not implemented with the spring implementation.

3. Call Service

Referring to the Objectfactorybean implementation of spring, spring already provides Jndiobjectfactorybean and Hessianproxyfactorybean, since v 0.7 has only jndi and Hessian methods. , so this piece is not to be considered for the time being.

In later versions, this piece needs to be considered in terms of caching and so on.

4, and service application-side integration

The temporary assumption in V 0.7 is that the service application is also based on spring, so the integration problem is not considered for the time being.

OK, so far, the two remaining jobs are:

1. Service meta-Information model

The service meta Information Model fully references the OSGi service.

In v 0.7, XML is the only way to describe the registration of the service meta information model, and what needs to be done here is to parse the XML into the meta information model.

2. Service Management End

V 0.7 provides only the view of the list of services, service registration, meta information modification, and uninstall.

V 0.7 need to do is to put the DSF shelves, to ensure that the scable based on the feasibility of DSF, of course, the service itself is also to consider scable (such as service operation resources, etc.) before the line, in the follow-up 0.7--> The 1.0 process will be refined from the details, such as supporting more communication protocols, supporting more integration of service applications, and improving performance.