System Management Model and Fractal

1. System Management Model and Fractal Author: WP2 System Management group Identification: WP2-TaskSM-1406-1 Partner: Telefonica I+D, UPM, Telvent Date: 07. 07. 04 Version: v0.1 Status: draft

2. Mapping SM Model into Fractal • Objective: Present some of the approaches discussed in SM mailing lists in order to map the SM Model into Fractal Component Model • Situation • None of the members of SMWG are experts in Fractal, so this presentation must be taken just as some ideas in order to map the SM model into Fractal

3. Fractal and SMWG Goals • The goal of Fractal specification is “to implement, deploy an manage (monitor and dynamically reconfigure) complex software systems • The goal of SMWG is to define a framework that allows both platforms and applications to expose their resources in order to be managed

4. Synergies between SMWG and Fractal • SM Model issues not faced in Fractal • Manageable Components • Notification model • Management Utilities common to several objects like • Logging • Monitors • Management agents and applications • Overlapping • Life cycle management • Fractal issues not faced in SM Model: • Bindings and controllers management FRACTAL SM MODEL

5. Notification Model Concepts • The notification model allows the instrumentation of components in order to push information about its health or even general information to listeners • Entities • Broadcaster: Emits a notification (event, alarm, user data, etc.) • Listener: Subscribes to a Broadcaster in order to receive notifications

6. Notification Model in Fractal • A Notification Component Model is not target specifically in Fractal • The notification model can be understood as an special binding in Fractal between: • a listener, offering a service to handle a notification • a broadcaster, who transmits a notification to the listener using the listener interface • Approach: • Define a notification-controller that provides • information about the notifications that a component can emit • Methods to bind/unbind a listener to the broadcaster component in order to receive notifications • Extending the concept of component to Broadcaster/Listener Component

7. Manageable Components Concepts • Allows a component to be managed. The component must implement an interface in order to expose its functional manageable capabilities (attributes, operations and notifications) • Presents manageable components with an identical interface, regardless of its functionality • Exposes the management interface of any registered component, but it never exposes the object reference. • Management applications will be able to manage all manageable components that satisfy the necessary controllers in a uniform way • Management applications will be able to access attributes and invoke operations of manageable components that are exposed for management

8. Managing Component Functional aspects in Fractal • The Fractal Component Model only expose attribute information from the functional part of a component • In Fractal, an attribute is a configurable property of a component • An AttributeController interface can be provided by the Component to read and write its attributes from outside the component • But maybe not all declared attributes must be manageable ... • Manageable operations and notifications are not considered either in Fractal • In order to target these component management aspects, a new model is needed

9. Manageable Components in Fractal • The SM Manageable Component Model can be mapped into Fractal in order to expose component functional management resources (attributes, operations and even notifications) • Two approaches are possible • Approach A • The ManageableComponent can be considered as another control interface, let call it “manageable-controller” • Every component that whishes to be manageable should implement this controller • Approach B • Define an “special” type of Interface, let call it “ManageableComponent”, that every component that whishes to be manageable should implement • Questions to Fractal Expert Group: Are both possible? Which are the pros and the cons of each solution?

10. Management Agent Concepts • A component or a composite component are managed as a whole by a management application • The management agent acts as a registry for all manageable components, where they can be inserted, deleted and browsed • All components that implements the management model, and registered into the same management agent, can be managed with the same management application • The management agent presents all manageable components registered equally to the management application (with an identical interface regardless of the type of manageable component that is being accessed) • Bindings between the management application and the manageable components are done through the management agent • Allows management applications to receive notifications emitted by the manageable components registered (if the component is declared as a broadcaster)

11. Management Agent in Fractal • A Management agent concept is not target specifically in Fractal • Two approaches are possible • Approach A • In a composite component, the interface Content-Controller??? Gives information about its subcomponents and bindings • As the manageable agent is a registry of components that can be managed, then the registry could be included in such an interface • But in Fractal all is optional, so composite components may be required but manageable components do not. So maybe this is not the best approach • Approach B • The management agent can be mapped a a shared component • This shared component will be used to connect a management application with all the manageable components registered within it • The management agent will used the manageable component model to access to the manageable resources declared by each component • Questions to Fractal Expert Group: Are both solutions possible to be implemented? Which are the pros and the cons of each one of the proposed solution?

12. Log Manager Concepts • Most applications use logs to keep records of activity and occurrences of errors and even debug statements • Logging facilities are not target specifically in Fractal • The log manager component provides a general purpose message logger for components to log whatever information they needs. • The log component can be understood as a shared component in Fractal, that acts as a management utility component.

13. Log Manager in Fractal • The log component can be shared between several components in order to offer logging facilities • Any component that requires logging capabilities can be bind to the shareable logging component in order to log its activity • The log manager component can implement itself the Manageable Component model (either the ManageableController or the ManagedComponent interface) • The log manager component can be registered within a management agent, in order to be managed by a management application

14. Performance Management Concepts • A robust management environment needs to be able to monitor itself and communicate with interested observers about its behavior and important statistics. • The performance model provides a general purpose monitors and timers in order to be used by other components that requires that functionality • Receiving application notifications at a given time, or at a given interval is very important for observers to evaluate the health of an application

15. Performance Management In Fractal (I) • Performance Monitors and timers concepts are not considered specifically in Fractal • Monitors and timers can be understood as shared components in Fractal, that acts as a management utility component • Monitors and timers can be shared between several components to provide performance facilities to them • Monitors and timers can be themselves Manageable Components (either the Management Controller or the Managed Component interface)

16. Performance Management In Fractal (II) • Manageable Monitors and timers can be registered within a management agent in order to expose its resources and notifications to a management application • General purpose monitors: • Attribute oriented monitors • Counter Monitor • String Monitor • Range Monitor • Method oriented monitors • Count Monitor • Timer Monitor

17. Configuration Manager Concepts • Configuration manager provides a general purpose configuration manager for components to register their configuration properties (manageable attributes). • Configuration manager may be in charge of the backup and recovery of components configuration properties both periodically and under request • The Configuration manager assures that those components receive their “safe” configuration data when they are activate in the platform after a crash

18. Configuration in Fractal • Features like the backup and recovery of a component manageable attributes is not considered within Fractal • This fuctionality can be executed by a general purpouse configuration manager • The configuration manager can be understood as a shared component in Fractal, that acts as a management utility component. • The configuration manager component can be shared between several components in order to offer general purpouse configuration facilities

19. Configuration in Fractal • Any component that requires configuration backup/recovery capabilities can be bind to the shareable configuration component in order to backup its manageable attributes values • The configuration manager component can implement itself the Manageable Component model, being a Manageable Component itself • The configuration manager component can be registered within a management agent, in order to be managed by a management application

20. Fractal Control Infrastructure • Managing Fractal Controllers • BindingController • ContentController • LifeCycleController • etc • Approach • Extends the Controller interfaces into ManageableController interfaces • BindingContoller  ManageableBindingController • ContentControllerManageableContentController • LifeCycleControllerManageableLifeCycleController

21. Fractal Control Infrastructure • Approach (cont) • Functional capabilities can be managed using ManagementComponent Model • Component Control capabilities can be managed using ManageableControllers (either binding, lifecycle or content) • ManageableControllers should declare which of its attributes, operations and notifications are declared manageable • When a manageable component is registered within a management agent, both control and functional management capabilities are exposed through the agent in order to be manageable through any management application with a binding to the management agent

22. Conclusions • Fractal does not define some of the “management concepts” introduced in the SM Model • None of SMWG members are Fractal experts nor members of Fractal Expert Group • SMMG has provided some approaches in order to map SM Model management concepts into Fractal • Fractal expert group should decide the SM Concepts they are interested in and choose the best approaches to map the model into Fractal specification