ExtensibleArchitecturesBestPractices
From SPA Wiki
Participants and organizers:
- [email protected] (AlanGriffiths)
- [email protected] (KlausMarquardt)
- [email protected] or [email protected] (OliverGallowayLunn)
- [email protected] (TonyBarrettPowell)
- [email protected] (VeraPeeters)
- [email protected] (MarkusVoelter)
Sheets at the official OT wall (Session Output)
Extension Mechanisms for Extensible Architectures
- Specialization
- Pros: support in (some) programming languages
- Cons: poorly understood by programmers
- Common data structures / protocols (app level)
- Pros: loosely coupled, runtime extension
- Cons: complex to interact(????), lack of standardization
- scripting language
- Pros: flexible, low maintenance
- Cons: hard to validate, can “break” application
- code generation
- Pros: powerful, efficient
- Cons: extra build steps, consequence of errors/change
- aspects
- Pros: powerful
- Cons: knowledge rare, limited support
- abstract interfaces %2b implementations
- c.f. specialization
Additional Concerns when building extensible architectures
- Extension time: when can you extend the system: build time, deployment time, run time, …
- Quality of service: how do you ensure that extensions don’t break the overall system with regards to performance, resources, robustness
- dependencies and interactions: you have to manage dependencies among extensions -> which extensions have to be used / can’t be used at the same time? (e.g. because of resource conflicts)
- planned or discovered: are extension points explicitly planned or discovered during building one or more systems?
- additional components: is there a central extension registry/manager that keeps track of all the extensions in a system? And coordinates the installation process?
- cascading: can extensions define additional extension points?
- testing and validation: how can an extensible system be tested / and concrete configurations be validated (???? Should be: verified)
- life cycle management: who starts up / shuts down extensions?
- coupling: tight or loosely? A priori versus a posteriori
Examples for Extensible Systems
- MicroMarketer -> data source, filter algorithm
- OnlineMortgage -> countries, and financial products
- LaboratorySystemsManager -> lab analyzer machines
- StockPrediction -> algorithms
- MetaDataStore -> data; defines meta data for concrete DB
- ComponentContainer -> component interfaces code generation
Session Work
Presentation of exiting extensible systems
- MicroMarketer -> data source, filter algorithm
- OnlineMortgage -> countries, and financial products
- LaboratorySystemsManager -> lab analyzer machines
- StockPrediction -> algorithms
- MetaDataStore -> data; defines meta data for concrete DB
- ComponentContainer -> component interfaces code generation
- OlcLibrary
- ExtensionByApplicationLevelProtocol
Techniques, Process, Role for extensions
Abbreviations: T-echniques, P-rocess, R-ole, E-xtension Type
Metalevel Architectures (mostly for data extension) [T,E]
- Pros:
- ultra-flexible
- often easy to use
- extendible at runtime
- Cons:
- possibly complex
- performance?
- constraints
- validation?
- understandability
Aspects [E]
(Weave, interceptions) allow you to extend systems with crosscutting concerns
- Pros:
- powerful concept especially for a posteriori extensions
- Cons:
- not currently natively supported by PL’s -> preprocessing, frameworking
- few people are really familiar with them
- can’t separate extension development from extendee development (if using weaving)
Code Generation [T,E]
(for behavioural extension adaptation)' (might also be metamodel bored) (????)
- Pros:
- very powerful and efficient
- Cons:
- maintenance
- consequence of change
- integration with the build process
- errors in generator have high impact
- extra step in build process -> ease of programming
- not at run time
Specialization [E]
- Pros:
- explicit support in some programming languages
- Cons:
- poorly understood by programmers
Dependency Inversion [T]
- Cons:
- interface is defined in a layer with no knowledge of implementation
- interface changes %2b (framework)
Process issues
Identify extension points (explicitly) [P]
- planned, or
- discovered over time -> refactoring
- learning process
- consider extension points even in systems not initially intended to become extendible
- plug-ins / applications could have a large number of different extension points
- refactoring / copy & paste is an indication for an extension point
- can an extension itself have further extension points? Yes - e.g. composite pattern
- Fear
Complexity of interfaces [P]
- common purpose leads to bloated IF
- usability demands small, concise, coherent IF
- requires explicit effort, architecture
- too much complexity
- identify new extension points?
- split extensions
Factoring common behaviour into the core system [P]
- risk: you need to change the core system and potential influence on other extensions
- do this while in development, stop it when publishing (a release)
- tight coupling of all system components - not technically, but by process
- backward compatibility -> can you change extension points yourself?
Contracts and QoS [T,P]
- how to ensure specific QoS characteristics of extensions
- resource management (memory, ports, …)
- performance
- mutual influence
- Is part of the contract related to an integration point
- Manage dependencies among extensions ?!?
- Measurement, testing
Do extensions {build upon | know about} each other?
- Base interface, or concrete subtypes?
- NO: independent development, testable
- YES: (see eclipse project) growing systems
- feedback between extensions?
- complexity ( ???? extension at multiple levels)
- predictablility & testability of extension behaviour
Installation process/registry (plugger) (optional) [T,R]
- again: runtime, build time, code time etc
- who will register the extensions?
- installation dependencies. E.g. only install A if B&C already installed. Or else: build new rule into core system
- life cycle control
Integration component (optional) [T,R]
Has knowledge of the extensions
- avoid this when 3rd parties develop further extensions
- when to register?
- “dumb” registry ( on a generic level)
- “intelligent” registry, has knowledge of the extensions’ semantics
- integrating component
- centralize the integrating component
- how can you test / verify the system without this “integrating component” [Jackson, combination problem]
We need to decide [T,R]
- Who / when to extend: deployment time, build time, run time, programming time
- programming time is most easy %2b flexible for system owners
- run time is most complex for development, but allows for user administration
- this impacts on how extensions are validated
Common data structures %2b arbitrary contributors [E,T]
- Application level protocol
- Pros:
- loosely coupled
- standards are available for a large number of domains
- extensible at runtime
- Cons:
- you need to agree on a shared, common protocol / data structure
- standards are available for a large number of domains but maybe not for yours
- complex protocol
- possibly complex to integrate
- backward compatibility
- no extension of behaviour, only of raw data
Scripting language [T,E]
- Pros:
- very flexible
- reduced maintenance
- Cons:
- potentially dangerous because it is hard to control what people “script”
- maintenance of language / additions
- decision on restricting to “safe” functionality versus trusting script author
- backward compatibility
- could become too complex
- extremely hard to test, could break the entire application
Abstract interfaces %2b implementations -> Strategy [T,E]
- Or provide a default impl? -> backward compatibility
- Mechanism for defining extension points
- Pros:
- easy to understand (in an OO world), common sense
- Cons:
- hard to implement using component techniques like COM, because here the extensions might not be able to call the core system (limited ability to “inherit”)