An architecture reflecting the requirements of the SERSCIS project has been developed. The individual components of this architecture are currently being implemented by the project partners and will be integrated into the testbed in the next phase of the project.
The architecture shown here depicts the components of the SERSCIS testbed for a particular service provider. Two channels of communication exist between downstream service consumers and upstream service providers. The management channel allows information to be exchanged regarding the negotiation of access to resources and their characteristics (encoded as SLAs), as well as runtime usage information relating to these terms and conditions. The application channel allows the functional services to be invoked and return results (both interim and final) based on this invocation. Within a service provider’s domain, the components communicate via an Enterprise Service Bus (ESB). The individual components are explained in more detail below.
Decision Support
Monitoring of events occurs at each service, using a service monitor. These events are sent to and aggregated by a monitoring hub, which monitors specified Key Performance Indicators (KPI). These are displayed to the operator, who can filter/query the information, using the decision support tool. This will help SERSCIS-assisted operators to manage the system by administration of other SERSCIS components (through their admin interfaces) or by direct actions on the critical infrastructure resources or ICT applications.
System Models
These models integrate service models in terms of abstract workflows, service-level QoS parameters and service management actions (responses to failure) to ensure that the total system configuration can reasonably be expected to adequately satisfy system-level performance and availability requirements based on local service monitoring and management actions.
SLA Manager
The SLA manager hosts SLA templates and handles requests from clients for SLAs based on them. The SLA manager grants new SLAs, provides information to the clients on their status, and may terminate existing SLAs if required.
Resource Manager
The resource manager handles the acquisition/allocation and removal of resources, and maintains a registry of these resources in which the orchestrator can discover resources when it has to execute a service workflow. This allows service providers to pursue dynamic provisioning strategies.
Service Manager
The service manager is responsible for ensuring that the service can meet its current and future commitments. Service providers can operate a flexible management strategy in the response to failure or under-performance in resources. When certain events occur (such as agreeing a new SLA, the failure of a resource or the provision of service outside of the terms of an SLA), the service manager may use the resource manager and SLA manager to alter its resources and/or commitments to keep them in balance with each other. It may also change the access control policy on the service.
Service Access Control Point
Access to the service is restricted according to a security policy that is dynamically updatable and enforced at the time of invocation.
System Orchestrator
The system orchestrator coordinates the use of application services to execute a workflow. A workflow editor is used to define an abstract workflow, which represents the orchestration of resources (including external services) used by a system (which may itself be a service), together with non-functional requirements on its execution. The workflow composer concretises these workflows by selecting appropriate resources from the semantic service registry, in which the resource manager has stored all resources available to the service. The workflow service coordinates all the steps that are required for workflow execution.
Application Services
The application services represent the actual functionality offered by the service provider and which are wrapped and invoked as Web services.
Recent Comments