Hlavní menu
Nástroje
|
ComponentizedPlatform.PreliminaryIdeasAndGoals History
Hide minor edits - Show changes to markup
05 April 2011, 17:52
by PremekBrada -
Changed lines 5-24 from:
- We need a support of plugins (component, modules) to extend the platform based on different customer's needs.
- the modules should be manageable according to a given customer as follows:
- enable/disable
- monitor
- charge out
- limit the resources
A list of possibly relevant topics (with relevance to IW needs):
- (automatic) adaptation of components to (slightly) different APIs? (medium)
- adaptation and modification of third party-components
- generating adapters for existing clients of our (changing) API
- what-if scenarios - which clients would I break with such-and-such API change?
- search a repo for a relevant API for an existing client
- metrics to assess API - stability, complexity
???
to:
- We need a support of plugins (component, modules) to extend the platform based on different customer's needs
Topics with highest relevance
(A) (automatic) adaptation to evolving APIs? -- see notes from brainstorming
- generating adaptation and modification of third party-components (existing clients) to changes in our API
- what-if scenarios - which clients would I break with such-and-such API change?
- search a repository for a relevant API for an existing client
- metrics to assess API - stability, complexity
- process to support the above - how to assess API, how to evolve it, what to do after it evolved
(B) testing of components based on semi-real data
- monitoring (QoS?) in customer environment, obtaining real usage data
- generating tests (mainly load, performance, reliability) with data based on those monitored
- testing in a simulated environment
- visualization of results and metrics and test results
Changed lines 25-26 from:
to:
A previous list of possibly relevant topics (with relevance to IW needs):
Added line 48:
Added line 55:
Added line 61:
Added line 66:
Deleted line 71:
05 April 2011, 17:27
by PremekBrada -
05 April 2011, 17:14
by PremekBrada -
Added lines 21-27:
05 April 2011, 16:39
by PremekBrada -
Added lines 13-20:
- (automatic) adaptation of components to (slightly) different APIs? (medium)
- adaptation and modification of third party-components
- generating adapters for existing clients of our (changing) API
- what-if scenarios - which clients would I break with such-and-such API change?
- search a repo for a relevant API for an existing client
- metrics to assess API - stability, complexity
Added line 28:
Changed lines 34-36 from:
- (automatic) adaptation of components to (slightly) different APIs? (medium)
- adaptation and modification of third party-components
- probably needless for our home-made components
to:
05 April 2011, 15:22
by vaclav sykora -
05 April 2011, 15:18
by vaclav sykora -
Changed lines 6-11 from:
to:
- the modules should be manageable according to a given customer as follows:
- enable/disable
- monitor
- charge out
- limit the resources
Changed lines 18-19 from:
- authentication of messages
to:
- authentication of messages
- role based authorization mechanism
Added line 24:
- (vaclav sykora) I don't fully undestand the point
17 March 2011, 16:53
by Lukas Holy -
Changed line 52 from:
- visualization can be useful in following points mentioned above:
to:
Visualization can be useful in following points mentioned above:
17 March 2011, 16:53
by Lukas Holy -
Changed line 10 from:
- an 'universal' bus, events, messiging, ...
to:
- an 'universal' bus, events, messaging, ...
Changed lines 21-22 from:
- visualisation of components (low)
- visualisation of considerable wide set of components
to:
- visualization of components (low)
- visualization of considerable wide set of components
Added lines 25-27:
- Custom metric visualization (including QoS?)
- Exploring component dependencies
- Traceability analysis (including EFP)
Changed line 30 from:
- components customised based on customer needs.
to:
- components customized based on customer needs.
Added lines 32-33:
- Tool for dependencies visualization and assembling
- Visual exploring of variation/extension points
Added line 36:
- Automatic update hints (with/without visualization)
Changed lines 46-48 from:
to:
- Visualization of results and metrics and test results in diagram
Added lines 52-61:
- visualization can be useful in following points mentioned above:
- verification of components compatibility
- repository of components
Additional ideas:
- Internal component analysis
- Visual comparison of views
- Automatic finding components in code (or macro-components in components)
16 March 2011, 14:45
by PremekBrada -
Changed lines 41-42 from:
to:
- analysis of platform-plugin-component structure/technology solution
- development, SCM and build support
16 March 2011, 11:32
by kamill -
Added lines 10-13:
- an 'universal' bus, events, messiging, ...
- monitoring of messages coming through
- filtering of messages
- authentication of messages
Changed lines 15-17 from:
- if we had a lot of components in different versions we would need to check whether a change of a component affects a system
to:
- verification of different version on components
- replacement of an old components by a new one.
- verification of compatibility of third-party components
Changed lines 19-20 from:
- important in a case we allow third-party components. Then we may want to adapt existing components to fit our API.
to:
- adaptation and modification of third party-components
- probably needless for our home-made components
Changed lines 22-24 from:
- useful for once we have wide sets of components. It include tooling for visualisation of stand-alone or running components.
to:
- visualisation of considerable wide set of components
- monitoring of runtime state of components
- monitoring of customer installation
Changed lines 26-28 from:
- product lines - components may be customised based on customer needs. We may have 'free', 'silver' 'gold' edition of components for different prices
to:
- product lines
- components customised based on customer needs.
- different edition for different prices
Changed lines 30-32 from:
- important if we want to plug components to a running platform on the fly
to:
- updates of running systems
- seamless update without restart
- configuration on the fly
Added lines 35-36:
- building up the application from storage
- mining components based on configuration
Changed lines 38-40 from:
to:
- testing in development environment
- monitoring (QoS?) in customer environment
16 March 2011, 11:20
by kamill -
Changed line 8 from:
- communication of components with with each other and communication of components with the platform (high)
to:
- communication of components with each other and communication of components with the platform (high)
Changed line 13 from:
- important in a case we allow a third-party components. Then we may want to adapt existing components
to:
- important in a case we allow third-party components. Then we may want to adapt existing components to fit our API.
Changed line 15 from:
- useful for a wide sets of components. It include tooling for visualisation of stand-alone or running components
to:
- useful for once we have wide sets of components. It include tooling for visualisation of stand-alone or running components.
Changed line 17 from:
- product lines - components may be customised based on customer needs.
to:
- product lines - components may be customised based on customer needs. We may have 'free', 'silver' 'gold' edition of components for different prices
Changed line 19 from:
- important if we want to plug components to a running platform
to:
- important if we want to plug components to a running platform on the fly
Changed lines 22-25 from:
- monitoring ans testing of components (medium)
to:
- monitoring and testing of components (high)
16 March 2011, 11:14
by kamill -
Added lines 1-25:
Ideas of what could we do
Current state:
- We have a platform
- We need a support of plugins (component, modules) to extend the platform based on different customer's needs.
A list of possibly relevant topics (with relevance to IW needs):
- communication of components with with each other and communication of components with the platform (high)
- a unified way of communication
- verification of components compatibility (medium)
- if we had a lot of components in different versions we would need to check whether a change of a component affects a system
- (automatic) adaptation of components to (slightly) different APIs? (medium)
- important in a case we allow a third-party components. Then we may want to adapt existing components
- visualisation of components (low)
- useful for a wide sets of components. It include tooling for visualisation of stand-alone or running components
- configuration of components based on customer needs (high)
- product lines - components may be customised based on customer needs.
- deployment of components to the running platform (low)
- important if we want to plug components to a running platform
- repository of components (medium)
- monitoring ans testing of components (medium)
|