Hlavní menu

Nástroje

ComponentizedPlatform / PreliminaryIdeasAndGoals

View (print) - Edit page | Recent changes - Page history

Updated 05 April 2011, 17:52 by PremekBrada

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

???

  • existing solutions
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:

???

  • existing solutions

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)
    • a unified storage
  • monitoring ans testing of components (medium)