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

In this space, the future analysis of the service lifecycle management of this distributed service framework in a distributed service framework, dynamic deployment, uninstall, and escalation of support services are critical, and the lifecycle of services needs to be notified in such a way as OSGi, and will be analyzed in this space, Finally, the lifecycle model of this distributed service framework and the service architecture model to date are formed.

To analyze whether the lifecycle of the service is required to do a dynamic notification like OSGi DS, here is an example of a service component installation. The OSGi DS Service lifecycle model, in OSGi DS, is first checked for lazy when a new service component is installed. If lazy or this service component external services to complete the installation, generate Serviceregistration objects into its service center, if not lazy or this service component not to provide services, You first check that the service that it refers to is available, if it is not available, try to activate the referenced service, if all referenced services are available, activate this component, provide this service externally, and issue a service active event The Service Lifecycle Event Manager will find all component that reference this service after it receives the event for service active, such as if component is not activated, attempt to activate, if activated, This active service Instance is injected according to the configured Bind-method.

Based on the above analysis, in the context of distributed service applications, take a look at the diagram below for a typical distributed service application diagram:

Based on the lifecycle model of the OSGi DS service, when we deploy a distributed service on the service application, the service first needs to register with the service center, and when registering, check to see if the referenced service is available and, if available, activate the service. You also need to send this message to all service applications that reference this service. This whole process is quite smooth, but we can think about, if this service is a basic service, by the N multi-service Application reference, then what will be the situation, then how many servers to inform (can imagine 100+ Service group), although it can be cluster+ synchronized,:), more complex situation, when this service refers to other n services, first need to send a message to try to activate these services, and then those services activation and then bring the N service activation, this makes the whole process becomes extremely tedious, The overall difficulty of implementation and the complexity of the logic greatly increased, dynamic processing of life cycle changes will bring great technical difficulties and uncontrollable factors, such as in a high concurrency scenario when a service suddenly unavailable, but its notification message is still passing, what will be the result? Since it is so difficult to control, it is simply not to control this dynamic change, simplifying the entire lifecycle model to ensure the simplicity of implementation and the high stability of the system, which is the principle that all systems must follow: "Simple (but not simple) to controllable, satisfying demand".