ARCHITECTURAL PATTERNS - III Unit- 6 ARCHITECTURAL PATTERNS - III Presented by Sushma Narasimhan Asst. Professor, Computer Science Department Engineered for Tomorrow

Unit-VI Adaptable Systems Microkernel Reflection

Adaptable Systems Definition Systems that evolve over time new functionality is added existing services are changed must support - new versions of OS - user-interface platforms - third-party components - libraries - new standards - hardware platforms provide services that differ from customer to customer.

Contd.. Design for change is therefore a major concern when specifying the architecture of a software system. Two patterns that help when designing for change: i) Microkernel pattern - separates a minimal functional core from extended functionality and customer- specific parts. ii)Reflection pattern – an application is split into two parts : a) meta level b)base level

Unit-VI Adaptable Systems Microkernel Reflection

Microkernel Pattern Definition Example Resolved Context Problem Engineered for Tomorrow Microkernel Pattern Definition Example Resolved Context Problem Solution Structure Dynamics Implementation Variants Known Uses Consequences

Microkernel Q: What does a Microkernel do? A: Separates a minimal functional core from extended functionality & customer-specific parts. Serves as a socket for plugging in these extensions and coordinating their collaboration.

Example Suppose we intend to develop a new OS for desktop computers called Hydra. Design goals must be easily portable to the relevant hardware platforms. must be able to accommodate future developments easily. must be able to run applications written for other popular OS, such as - NeXTSTEP - Microsoft Windows - UNIX System V

Contd.. User has a choice of selecting the OS from a pop-up menu. Should display all currently running applications within its main window. Fig: Hydra Operating System

Contd.. To emulate all these OS, Hydra will integrate special servers that implement specific views of Hydra’s functional core. Ex: Emulation of Microsoft Windows by a server process.

Context Development of several applications that use similar programming interfaces that build on the same core functionality

Problem Application platforms such as operating systems and graphical user interfaces have a long life-span, sometimes ten years or more new technologies emerge and old ones change Following forces have to be considered when designing such systems: The application platform must cope with continuous hardware and software evolution. The application platform should be portable, extensible and adaptable to allow easy integration of emerging technologies.

Contd.. Example Hydra is designed to run applications that were originally developed for popular operating systems such as Microsoft Windows or OS/2 Warp. So inculcate the following forces: The applications in your domain need to support several similar application platforms. The applications may be categorized into groups that use the same functional core in different ways. The functional core of the application platform should be separated into a component with minimal memory size, and services that consume minimal processing power

Solution Microkernel component The fundamental services of the application platform are encapsulated in the microkernel component. Ex: - inter-communication of components running in separate processes - maintaining system-wide resources such as files or processes - provides interfaces that enable other components to access its functionality .

Contd.. Internal servers Core functionality that - cannot be implemented within the microkernel - which increases the size or complexity should be separated in internal servers External servers is a separate process that itself represents an application platform implement their own view of the underlying microkernel Clients communicate with external servers by using the communication facilities provided by the microkernel.

Structure The Microkernel pattern defines five kinds of participating components: Internal servers External servers Adapters Clients Microkernel

Contd.. Microkernel Represents the main component of the pattern. Implements central services such as communication facilities or resource handling. Many system-specific dependencies are encapsulated within the microkernel. Maintains, controls and coordinates the access to system resources - processes or files.

Contd.. Example In Hydra we want to support UNIX System V and OS/2 Warp, amongst other operating systems. We face a problem when implementing Hydra's process model. implemented in UNIX by cloning an existing process OS/2 Warp handles process creation totally differently Hydra is therefore designed to supply basic services for both the mechanisms.

Contd.. Internal server Also known as a Sub-system. Extends the functionality provided by the microkernel. Example: device drivers that support specific graphics cards are implemented by internal servers. The microkernel invokes the functionality of internal servers via service requests.

Contd.. External server Also known as a personality Is a component that uses the microkernel for implementing its own view of the underlying application domain. Each of these external servers runs in a separate process. It receives service requests from client applications , interprets these requests, executes the appropriate services and returns results to its clients. For implementation, external servers need to access the microkernel's programming interfaces.

Contd..

Contd.. Example In Hydra, we want to implement an OS/2 Warp external server and a UNIX System V external server. Both these servers use the mechanisms of the underlying microkernel to implement a complete set of OS/2 Warp and UNIX System V system calls.

Contd.. Client Is an application that is associated with exactly one external server. Only accesses the programming interfaces provided by the external server. Every communication with an external server must be hard-coded into the client code. Such a tight coupling between clients and servers, however, leads to various disadvantages: Does not support changeability very well. If external servers emulate existing application platforms, client applications developed for these platforms will not run without modification.

Contd..

Contd.. Adapters Also known as emulators. Represent the interfaces between clients and their external servers to protect clients from direct dependencies. If the external server implements an existing application platform, the corresponding adapter mimics the programming interfaces of that platform. Protect clients from the specific implementation details of the microkernel. Whenever a client requests a service from an external server the adapter forwards the call to the appropriate server.

Contd.. Example Due to encapsulation by an adapter, a Hydra client associated with the OS/2 Warp external server does not know whether it is running on a native OS/2 Warp system or on a Microkernel system that provides an OS/2 Warp external server. It just uses the OS/2 system calls. What happens 'behind the scenes' is hidden by the adapter. The microkernel, collaborates with external servers, internal servers and adapters. Each client is associated with an adapter used as a bridge between the client and its external server.

Contd.. Fig: Static structure of a Microkernel system Internal servers are only accessible by the microkernel component.

Dynamics The dynamic behavior of a Microkernel system depends on the functionality, it provides for inter-process communication. Scenario I Demonstrates the behavior when a client calls a service of its external server: The client requests a service from an external server by calling the adapter. The adapter constructs a request and asks the microkernel for a communication link with the external server. The microkernel determines the physical address of the external server and returns it to the adapter.

Contd.. Now the adapter establishes a direct communication link to the external server. The adapter sends the request to the external server using a remote procedure call. The external server receives the request, unpacks the message and delegates the task to one of its own methods. After completing the requested service, the external server sends all results and status information back to the adapter. The adapter returns to the client, which in turn continues with its control flow.

Contd.. Fig: Scenario - I

Contd.. Scenario II Illustrates the behavior of a Microkernel architecture when an external server requests a service that is provided by an internal server. The external server sends a service request to the microkernel. A procedure of the programming interface of the microkernel is called to handle the service request. During method execution the microkernel sends a request to an internal server. After receiving the request, the internal server executes the requested service and sends all results back to the microkernel. The microkernel returns the results back to the external server.

Contd.. Finally, the external server retrieves the results and continues with its control flow. Fig: Scenario II

Implementation To implement a Microkernel system, carry out the following steps: 1. Analyze the application domain If you do not have detailed knowledge about the external servers, that will be implemented, then - perform a domain analysis - identify the core functionality necessary for implementing external servers 2. Analyze external servers Analyze the policies external servers are going to provide. Example : In Hydra operating system, external servers are: UNIX System V, OS/2 Warp, Microsoft Windows & NeXTSTEP.

Contd.. 3. Categorize the services Whenever possible, group all the functionality into semantically-independent categories. Example: In Hydra the core categories are – operating systems are memory management, process management, I/O & communication services. 4. Partition the categories Separate the categories into services that should be part of the microkernel, and those that should be available as internal servers.

Contd.. In Hydra, the microkernel provides services categories services provided by services provided by microkernel internal servers In Hydra, the microkernel provides services - process management - memory management - communication - low-level I/O Internal servers provide additional services - page fault handlers - drivers or file systems

Contd.. 5. Find a consistent and complete set of operations and abstractions for every category you identified in step 1. Example : In Hydra, operations such as the creation of processes or threads are handled differently by operating systems like UNIX or Microsoft Windows. Hydra supports both by providing the following services: - Creating and terminating processes and threads. - Stopping and restarting them. - Reading from or writing to process address spaces. - Catching and handling exceptions. - Managing relationships between processes or threads. - Synchronizing and coordinating threads.

Contd.. 6. Determine strategies for request transmission and retrieval Microkernel may provide several alternatives: Asynchronous communication v/s synchronous communication One-to-one, a many-to-one or a many-to-many relationship Low-level communication facilities such as message-passing or shared memory Compare design patterns such as Forwarder-Receiver & Client-Dispatcher-Server

Contd.. Example: Hydra provides two basic communication facilities: Synchronous Remote Procedure Calls (RPCs) Asynchronous Mailboxes 7. Structure the microkernel component Design the microkernel using the Layers pattern to separate system-specific parts from system- independent parts of the microkernel. Example: In our Hydra project, we use object-oriented techniques to implement the microkernel:

Contd.. Lower-most layer Intermediate layer Uppermost layer - low-level objects that hide hardware-specific details(bus architecture) from other parts of the microkernel. Intermediate layer - provide the primary services(memory management, process management). Uppermost layer - comprises all the functionality that the microkernel exposes publicly represents the gateway to the microkernel services for any process.

Contd.. 8. To specify the programming interfaces of the microkernel, you need to decide how these interfaces should be accessible externally. microkernel is implemented as a module - use method calls to invoke the methods of the microkernel. microkernel is implemented as a separate process - use existing communication facilities to transmit requests from components to the microkernel. Example : In Hydra, microkernel component is part of each user process. Services are therefore accessible by conventional system calls.

Contd.. 9. The microkernel manages all system resources - memory blocks, devices or device contexts. using a handle to an output area in a graphical user interface implementation. In Hydra OS, handles refer to objects that are instances of a resource class. Each object offers a uniform interface to control access to a specific resource. 10. Design and implement the internal servers as separate processes or shared libraries. In Hydra, device drivers, authentication servers & page fault handlers are implemented as internal servers.

Contd.. 11. Implement the external servers Each external server is implemented as a separate process that provides its own service interface. The internal architecture of an external server depends on the policies it comprises. In Hydra, the following external servers will be developed: - A full implementation of Microsoft’s Win32 and Win16 APIs. - The complete functionality provided by IBM OS/2 Warp 2.0. - An implementation of OpenStep. - All relevant UNIX System V interfaces specified by X/Open.

Contd.. 12. Implement the adapters Design the adapter either as - a conventional library that is statically linked to the client during compilation, or as - a shared library dynamically linked to the client on demand. - The Proxy pattern can therefore be used to implement an adapter. 13. Develop client applications or use existing ones for the ready-to-run Microkernel system. Example: In Hydra, we can develop Microsoft Windows applications by accessing the services of the Microsoft windows external server.

Variants 1. Microkernel System with indirect Client-Server connections A client that wants to send a request/message to an external server asks the microkernel for a communication channel. After the requested communication path has been established, client-server communication takes place indirectly, using the microkernel as a message backbone. 2. Distributed Microkernel System Every machine in a distributed system uses its own microkernel implementation. From the user's viewpoint the whole system appears as a single microkernel system-the distribution remains transparent to the user.

Uses/Applications i) Mach was developed at Carnegie Mellon University in 1986. Mach microkernel forms a base on which other operating systems can be emulated. ii) Amoeba consists of two basic elements: - the microkernel itself and - a collection of servers used to implement the majority of Amoeba's functionality. iii) Chorus commercially-available Microkernel system developed by the French research institute INU specifically for real-time applications.

Contd.. iv) Windows NT was developed by Microsoft as an operating system for high- performance servers. It offers three external servers, an OS/2 1 .x server, a POSIX server and a Win32 server. v) MKDE(Microkernel Datenbank Engine) Introduces an architecture for database engines The microkernel is responsible for providing fundamental services. Various external servers run on top of the microkernel and provide different conceptual views of the underlying microkernel.

Consequences Benefits of the Microkernel pattern: i) Portability A Microkernel system offers a high degree of portability. No need to port external servers or client applications , if you port the Microkernel system to a new software or hardware environment. Microkernel can be migrated to a new hardware environment by modifications to the hardware-dependent parts.

Contd.. ii) Flexibility and Extensibility To implement an additional view, all you need to do is add a new external server. Extending the system with additional capabilities only requires the addition or extension of internal servers. iii) Separation of policy and mechanism The microkernel component provides all the mechanisms necessary to enable external servers to implement their policies. Strict separation of policies & mechanisms increases the maintainability and changeability of the whole system.

Contd.. Distributed variant of the Microkernel architecture offers the following additional benefits: i) Scaleability Easy to scale the Microkernel system to the new configuration whenever a new machine is added to the network. ii) Reliability Two issues are important in achieving reliability: availability and fault tolerance. Availability - The same server can be run on more than one machine.

Contd.. If a server or a machine fails, the failure does not necessarily impact an application. Fault tolerance - Distributed systems hide failures from a user. iii) Transparency Each component can access other components, without needing to know their location. Details of inter-process communication with servers are hidden from clients by the adapters & the microkernel.

Contd.. Liabilities of the Microkernel architectural framework: i) Performance Compare a monolithic software system designed to offer a specific view with a Microkernel system supporting different views. The performance of the former will be better in most cases. ii) Complexity of design and implementation Analyzing or predicting the basic mechanisms provided by a microkernel component becomes difficult sometimes. The separation between mechanisms and policies requires in-depth domain knowledge and considerable effort during requirements analysis and design.

Unit-VI Adaptable Systems Microkernel Reflection

Reflection Pattern Definition Example Resolved Context Problem Engineered for Tomorrow Reflection Pattern Definition Example Resolved Context Problem Solution Structure Dynamics Implementation Variants Known Uses Consequences

Reflection Pattern Definition Provides a mechanism for changing structure and behavior of software systems dynamically. Supports the modification of fundamental aspects - type structures & function call mechanisms An application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Also known as Open Implementation, Meta-Level Architecture

Example Consider a C++ application that needs to write objects to disk and read them in again. We must specify how to store and read every type in the application. Many solutions to this problem exist: implementing type-specific store and read methods - expensive and error-prone. Persistence and application functionality are strongly interwoven Example

Contd.. Persistence and application functionality are strongly interwoven Example: we can provide a special base class for persistent objects from which application classes are derived, with inherited store and read methods overridden. Changes to the class structure require us to modify these methods within existing application classes. Here the focus is on Developing a persistence component that is independent of specific type structures. To have dynamic access to the internal structure of C++ objects.

Contd..

Context Building systems that support their own modification a priori.

Problem Software systems evolve over time. They must be open to modifications in response to changing technology and requirements. Designing a system that meets a wide range of different requirements, a priori can be an overwhelming task. Several forces are associated with this problem: i) Changing software is tedious, error prone, and often expensive. ii) Adaptable software systems usually have a complex inner structure.

Contd.. iii) More the techniques that are necessary for keeping a system changeable, more awkward and complex its modification. parameterization, sub-classing, mix-ins, or copy and paste iv) Changes can be of any scale providing shortcuts for commonly used commands to adapting an application framework for a specific customer. Even fundamental aspects of software systems can change. - the communication mechanisms between components

Solution Make the software self-aware, and make selected aspects of its structure and behavior adaptable and changeable. This leads to an architecture that is split into two major parts: a meta level a base level The meta level provides a self-representation of the software to give it knowledge of its own structure and behavior Consists of so-called meta-objects. Meta-objects encapsulate and represent information about the software. Examples include type structures, algorithms, or sseven function call mechanisms.

Contd.. The base level defines the application logic. Its implementation uses the meta-objects to remain independent of those aspects that are likely to change. Meta-object protocol (MOP) - interface is specified for manipulating the meta-objects. allows clients to specify particular changes (modification of the function call mechanism). responsible for checking the correctness of the change specification, & for performing the change

Structure Meta level consists of a set of meta-objects. Each meta-object encapsulates selected information about a single aspect of the structure, behavior, or state of the base level. There are three sources for such information: It can be provided by the run-time environment of the system - C++ type identification objects. It can be user-defined, such as the function call mechanism. It can be retrieved from the base level at run-time. Ex: information about the current state of computation

Contd..

Contd.. Base level models and implements the application logic of the software. Its components represent the various services the system offers as well as their underlying data model. Specifies the fundamental collaboration and structural relationships between its components. The base level uses the information and services provided by the meta-objects. location information about components & function call mechanisms.

Contd..

Contd.. Meta-object protocol (MOP] serves as an external interface to the meta level, and facilitates the implementation of a system using reflective pattern. Example: a user may specify a new function call mechanism for communication between base-level components. the user provides the meta-object protocol with the code of this new function call mechanism. the meta-object protocol then performs the change, - generates an appropriate meta-object - compiles the generated meta-object, - dynamically links it with the application - updates all references of the 'old' meta-object to the 'new' one.

Contd..

Structure The architecture is a layered system with 2 layers - i) meta level ii)base level Each of which provides its own interface. The base-level layer specifies the user interface for exploiting application functionality. The meta-level layer defines the meta-object protocol to modify the meta-objects. In contrast to a layered architecture, there are mutual dependencies between both layers. The base level builds on the meta-level, and vice-versa.

Contd.. Fig: General structure of a reflective architecture

Dynamics Scenario I Illustrates the collaboration between base level and meta level when reading objects stored in a disk file. The scenario is divided into six phases: i) The user wants to read stored objects. The request is forwarded to the read ( ) procedure of the persistence component. ii) Procedure read() opens the data file and calls an internal readObject() procedure.

iv) Procedure readObject( ) requests an iterator over the data Contd.. iii) Procedure readObject( ) calls the metaobject that is responsible for the creation of objects. The 'object creator' metaobject instantiates an 'empty' object of the previously-determined type. It returns a handle to this object and a handle to the corresponding run-time type information (RTTI) meta-object. iv) Procedure readObject( ) requests an iterator over the data members of the object to be read from its corresponding meta-object.

Contd.. v) Procedure readobject( ) reads the type identifier for the next data member. If the type identifier denotes a built-in type, the readobject ( ) procedure directly assigns the next data item from the file to the data member, based on the data member's size and offset within the object. Otherwise readobject( ) is called recursively. After reading the data, the read ( ) procedure closes the data file & returns the new objects to the client that requested them.

Contd.. Fig: Scenario I

Contd.. Scenario II illustrates the use of the metaObject protocol when adding type information to the meta level. Consider a class library used by the application that changes to a new version with new types. The scenario is divided into six phases which are performed for every new type: i) A client invokes the metaObject protocol to specify run-time type information for a new type in the application. ii) The metaObject protocol creates a metaObject of class type-info for this type.

Contd.. iii) The client calls the metaObject protocol to add extended type information. To handle the inheritance relationship, the metaObject protocol creates meta-objects of class baseInfo. iv) The metaObject protocol is provided with the name and type of every data member. For every data member the metaObject protocol creates an object of class dataInfo. v) The client invokes the metaObject protocol to modify existing types, that include the new type as a data member.

vi) Finally, the client calls the metaobject protocol to adapt Contd.. vi) Finally, the client calls the metaobject protocol to adapt the 'object creator' metaobject. The persistence component must be able to instantiate an object of the new type when reading persistent data.

Contd..

Implementation Guidelines for implementing a reflective architecture: i) Define a model of the application Analyze the problem domain and decompose it into an appropriate software structure. Answer the following questions: Which services should the software provide? Which components can fulfill these services? What are the relationships between the components? How do the components co-operate or collaborate? What data do the components operate on? How will the user interact with the software? Follow an appropriate analysis method when specifying the model.

Contd.. ii) Identify varying behavior Analyze the model developed in the previous step & determine which of the application services may vary and which remain stable. The following are examples of system aspects that often vary: Real-time constraints - deadlines, time-fence protocols, algorithms for detecting deadline misses Transaction protocols - optimistic & pessimistic transaction control in accounting systems

Contd.. Inter-process communication mechanisms - remote procedure calls and shared memory. Behavior in case of exceptions - handling of deadline misses in real-time systems. Algorithms for application services - country-specific VAT calculation iii)Identify structural aspects of the system, which, when changed, should not affect the implementation of the base level. type structure of an application its underlying object model distribution of components in a heterogenous network.

Contd.. iv) Identify system services that support both the variation of application services identified in step 2 and the independence of structural details identified in step 3. Examples of basic system services are: - Resource allocation - Garbage collection - Page swapping - Object creation v) Define the meta-objects For every aspect identified in the three previous steps, define appropriate metaobjects. Encapsulating behavior is supported by several domain-independent design patterns - Objectifier, Strategy, Bridge, Visitor, and Abstract Factory

Contd.. The metaobjects that provide the run-time type information for our persistence component are: type-info - C++ standard library class used for identifying types. extTypeInfo - provides access to Information about the size, super classes, and data members of a class. BaseInfo - offers functions for accessing type information about a base class of a class, as well as to determine its offset in the class layout. DataInfo - includes functions that return the name of a data member, its offset and its associated type_info object.

Contd.. - a defined and controlled modification and extension of the vi) Define the metaObject protocol. Support - a defined and controlled modification and extension of the meta- level - a modification of relationships between base-level components and meta-objects There are two options for implementing the metaObject protocol: i) Integrate it with the meta-objects. ii) Implement the metaObject protocol as a separate component.

Contd.. vii) Draw the base level Implement the functional core and user interface of the system according to the analysis model developed in step 1. Use meta-objects to keep the base level extensible and adaptable. Connect every base-level component with meta-objects that provide system information on which they depend. Provide base-level components with functions for maintaining the relationships with their associated meta-objects.

Variant of Reflective System 1. Reflection with several meta levels Changes to the run-time type information of a particular type requires that updation of the 'object creator' meta-object. To coordinate such changes, introduce separate meta-objects, and-conceptually-a meta level for the meta level. Such a software system has an infinite number of meta levels in which each meta level is controlled by a higher one, and where each meta level has its own metaObject protocol. Ex: RbCl programming language

Known Uses/ Applications i) CLOS Classic example of a reflective programming language. Operations defined for objects are called generic functions. Their processing is referred to as generic function invocation. Generic function invocation is divided into three phases: First determines the methods that are applicable to a given invocation. Sorts the applicable methods in decreasing order of precedence. Finally sequences the execution of the list of applicable methods.

Contd.. ii) MIP Is a run-time type information system for C++. The functionality of MIP is separated into four layers: The first layer includes information and functionality that allows software to identify and compare types. The second layer provides more detailed information about the type system of an application. The third layer - provides information about relative addresses of data members, - offers functions for creating 'empty' objects of user-defined types. The fourth layer provides full type information, - about friends of a class, protection of data members, or argument and return types of function members.

Contd.. iii) PGen Is a persistence component for C++ that is based on MIP. Allows an application to store and read arbitrary C++ object structures. iv) NEDIS Car-dealer system , which uses reflection to support its adaptation to customer- and country-specific requirements. Includes a meta level called run-time data dictionary. v) OLE 2.0 Provides functionality for exposing and accessing type information about OLE objects and their interfaces. This information can be used to dynamically access structural information about OLE objects, & to create invocations of OLE interfaces.

Consequences Benefits of a Reflection architecture: i) No explicit modification of source code No need to touch existing code when modifying a reflective system. Just specify a change by calling a function of the metaObject protocol. By passing the new code to the meta level as a parameter of the metaObject protocol. ii) Changing a software system is easy The metaObject protocol provides a safe and uniform mechanism for changing software.

Contd.. Hides all specific techniques such as the use of visitors, factories and strategies from the user. Hides the inner complexity of a changeable application. iii) Support for many kinds of change Meta-objects can encapsulate every aspect of system behavior, state and structure. An architecture based on the reflection pattern, potentially supports changes of almost any kind or scale. Even fundamental system aspects can be changed, function call mechanisms or type structures.

Contd.. Liabilities of a Reflection architecture: i) Modifications at the meta level may cause damage Even the safest metaObject protocol does not prevent users from specifying incorrect modifications. Such modifications may cause serious damage to the software or its environment. ii) Increased number of components A reflective software system may include more metaobjects than base-level components. iii) Lower efficiency Reflective software systems are usually slower than non-reflective systems. This is caused by the complex relationship between the base level and the meta level.

Contd.. iv) Not all potential changes to the software are supported Although a reflection architecture helps with the development of changeable software, only changes that can be performed through the metaObject protocol are supported. Example : changes or extensions to base-level code v) Not all languages support reflection A Reflection architecture is hard to implement in some languages, such as C++. offers little or no support for reflection impossible to exploit the full power of reflection, such as adding new methods to a class dynamically