|
|
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
monitors and discovery services are similar patterns and sometimes do double duty service. Services usually use a URL as their address and logical name. When a component needs to find a resource service, it requests the location from a Discovery service, and then connects to that remote service URL. Thus applications in self-* systems are a ‘logical’ construct made up of from a pool of distributed, deployable component/resource services.
So recapping, the ‘application’ pattern is loaded as metadata into a Registry. A Service Launcher reads this information and automatically deploys the service into a Container on a server in the grid pool. The service gets its start up state from a proxy to the Registry. The service then registers itself with the Monitoring service. Then, to do the job of the application, it goes to the Discovery service to find address of all the component/resources it needs, then it links to them and the application is functioning. Periodically the service renews its healthy state data in the Monitor. If the Monitor finds the healthy state data is expired, it assumes the service is lost, de-registers it from the Discovery service, and then requests the Service Launcher to re-launch the service elsewhere in the logical domain.
This treatment of self-* architecture is short and may vary slightly from self-* system to system. Mostly services today are SOA services, either Java app services, Jini services, or web services. Component services can be large or small depending on the capacity of the pool servers and the service loader. Services can be short lived or very long lived (sometimes called ‘sticky’ services.). A single Boot-strap service can launch from scratch, every needed service into a clean grid pool – usually in seconds.
Self-* Networks
In this world, devices should behave much like services/applications. The device will have an active pattern (not as is current, a passive relationship) with the larger system. Devices will support some communication system, usually a web service interface or a java interface. On startup, a device will find the discovery service and register its state. It is required to periodically renew this information and refresh its lease on life. If the monitor finds the state information old, it assumes the device is not functioning. It puts in an automatic service recovery request, often attempting to restart the device before opening a trouble ticket. Note the device leads the health-conversation - not, as is done today, the management system finding the device and driving communications to its MIB. The self-* system takes over when the device is not healthy.
|
|
Communications connections are also monitored as a ‘logical’ service. These are registered as communications links or paths and the device acts as a proxy to maintain the health data in the monitor. If the health data is stale, it is assumed the connection is down and must be attended to. The registering of device state, connections, and their state can be done in a specialized monitor application which then becomes a ‘model’ of the network. This model can be replicated for specific tasks, such as network capacity simulations. If a two-way action pattern supporting transactions is established between this network model service and the devices, then the model becomes a provisioning service component. The provisioning service places the new connection in the network model, and the network model replicates it to the devices in the network. Note, the network devices understand and implement transactions.
Most frameworks or Service fabrics contain a large set of ‘mandatory’ component services. These provide common requirements. Security services are an example. Some self-* implement the entire AAA framework. Another component service is a transaction controller; often, many copies of which are deployed as resource services. The most complete frameworks include a collaboration service and other patterns for service orchestration, which support the notion of a service SLA.
Generally, all these orchestrations and interactions are governed by Policy statements. The services act as active ‘agents’ to enforce this policy. Sometimes there is a work manager that will ensure a flow of data or control occurs according to the goals and needs of the ‘logical’ application. The Policy service can implement a pattern of activity derived from biology, such as Stigmergy.
Qualitative or discrete stigmergy is the use of different stimuli to trigger different responses. Franziska Klügl explains: “The main problem with the application of this form of co-ordination in artificial systems is its development: one agent has to modify its environment so that the others respond to stimuli in the intended way.” The question remains, in a software system, what is the environment? Today, the environment is the self-* framework in which the agents or services interact.
Again, Richard Nicholson explains:
The signature of any real next generation distributed runtime is easily identifiable. A next generation "Service Fabric" will dynamically instantiate the most sophisticated composite applications from their structural descriptions; scaling,
article
page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
|
|
|
