OpenSAF Wanted Architecture TLC view Mario Angelic Technical Co-Chair OpenSAF Project mario.angelic@ericsson.com June 4th, 2009

OpenSAF TLC view on architectural evolution Presentation Scope OpenSAF TLC view on architectural evolution Architectural aspects covered in this presentation Modularity Improving current support on modularity Functional content Addition of new functionality Streamlining of functionality

Modularity What do we want to achieve? Why ? How ? OpenSAF functionality delivered as number of functional modules Why ? Reducing entry-cost for Application Reducing maintainance overhead for ”functionality” applications they do not need Addressing wider range of applications How ? Analysing intrinsical service inter-dependency Identifying ”modules” and it’s boundaries Cleaning up ”module” dependencies

Analyzing service inter-dependency Standardization View (SA Forum) Describe dependency between services Describe Possible Modularization alternatives allowed by standard Implementation View (OpenSAF) Describe actually implemented SAF services Implementation dependencies OpenSAF infrastructure services

Standardization view: Functional content AIS Utility Services AIS Management Services Checkpoint (CKPT) Information Model Management (IMM) AIS Frameworks Event (EVT) Notification (NTF) Availability Management Framework (AMF) Lock (LCK) Logging (LOG) Messaging (MSG) Security (SEC) Software Management Framework (SMF) Naming (NAM TImer (TMR) Cluster Membership Service (CLM) Legend Platform Management Service (PLM) AIS Services and Frameworks AIS Platform Services HPI Services Hardware Platform Interface (HPI)

Standardization view: Typical Service Dependencies Optional AIS Management Services AIS Utility Services AIS Frameworks CKPT SMF IMM EVT LOG LCK AMF NTF MSG NAM SEC CLM TMR PLM HPI Optional AIS Platform Services

Implementation view: SAF Services AIS Utility Services AIS Management Services Checkpoint (CKPT) Information Model Management (IMM) Event (EVT) AIS Frameworks Availability Management Framework (AMF) Notification (NTF) Lock (LCK) Logging (LOG) Messaging (MSG) Software Management Framework (Rel 4) Legend Cluster Membership Service (CLM) AIS Services and Frameworks AIS Platform Services HPI Services Hardware Platform Interface (HPI)

OpenSAF Service Dependencies (Release 3) AIS Frameworks AIS Management Services AIS Utility Services SMF CKPT IMM EVT AMF LOG LCK CLM NTF MSG OpenSAF Infrastructure Services OpenSAF CLI RDE MDS Logtrace SRMSv MASv HPI Optional HISv MBCSv LEAP DTS IFSv PSSv Optional

OpenSAF Infrastructure Services “OpenSAF Core” AIS Management Services Minimum set of inter-dependent services Offers high-availability and managebility support usable to wide-range of applications SA Forum Services: AMF (Availability Management Framework) CLM (Cluster Membership Service) IMM (Information Model Management) NTF (Notification Service) LOG (Logging Servive) PLM (Platform Management Service) OpenSAF Infrastructure Services: MDS (Message Distribution Service) RDE (Role Determination Engine) MBCSv (Message Based Checkpoint Service) DTS (Distributed Trace Service) Logtrace (Log&Trace foront-end) AIS Frameworks SMF IMM AMF LOG CLM NTF AIS Platform Services (move CLM here) PLM OpenSAF Infrastructure Services RDE MDS Logtrace DTS MBCSv LEAP Optional

OpenSAF Wanted Architecture Management Clients (3pp, etc.) OpenSAFCLI AIS Utility Services OpenSAF GUI Possible finer-grained modularity CKPT EVT After PLM introduced AIS Management Services AIS Frameworks LCK HISv SMF PSSv IMM MSG Deprecated & Removed AMF ... MASv LOG CLM SRMSv NTF Same package AIS Platform Services (move CLM here) PLM OpenSAF Infrastructure Services MDS MBCSv LEAP IFSv ?? Optional DTS RDE Logtrace Optional HPI

Streamlined Architecture Reuse internally Ex. Consolidated Logging Rely on standard interfaces C standard library POSIX interfaces Reuse from external open-source projects Using open-source trace backend Focusing on key values/advantages

Consolidated logging Today, OpenSAF have several means of logging information: Stdout redirected to files Per service log files Using DTS service Using syslog Using LogTrace (log levels to syslog, trace levels to file) Using SA Forum Log service Preferred method for logging is by using SAF Log service, but …. some services need to be started before SAF Log service (like IMM), so what should use IMM for logging?

Consolidated logging, cont. Proposal is that: All OpenSAF services use Logtrace API as Log and Trace interface (front-end) Trace API would then use syslog as backend for logging until SAF Log is started. Once SAF Log starts Trace API will dynamically switch to use SAF Log service for logging. Trace API will use DTS as trace backend, or some other available open-source tracing backend (like LTTng, for example)

Consolidated Logging in OpenSAF, proposal LogTrace API In future replaced with some open-source trace backend (for example, LTTng) Trace levels DTS OpenSAF services LogTrace SAF Log available? SAF Log Log levels Front End Back-End Part of Operating System layer syslog

Consolidated logging, cont. What about Applications ? They should directly use SAF Log service Application will not have any problem (compared to middleware services) since SAF Log services will always be available prior any application is started

Relay on standardized interfaces Relying more on POSIX and C stdlib LEAP becomes more as utility library then porting layer Improves coding style/readability of OpenSAF services

Status for architecture related features Addressed in Release 3 IMM, NTF part of OpenSAF Addressed in Release 4 SMF part of OpenSAF Configuration framework: MASv -> IMM AMF using NTF for sending notifications

Questions ?

Thank You! For more information: http://devel.opensaf.org