ExtensibleArchitecturesBestPractices

From SPA Wiki

Jump to: navigation, search

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”)

ExtensibleArchitecturesBestPractices

From SPA Wiki

Contents

Participants and organizers:

Sheets at the official OT wall (Session Output)

Extension Mechanisms for Extensible Architectures

Additional Concerns when building extensible architectures