XMLWordPrintable

Details

    • Epic
    • Resolution: Unresolved
    • Major
    • None
    • None
    • None
    • Visualization of application dependencies
    • To Do
    • 55
    • 55% 55%

    Description

      As a user I want to have a graphical overview of the dependencies of, within and between the assessed apps in order to better understand my app portfolio for the migration/modernization.

      What I would love to see as a user is:

      • (1) apps an their library dependencies of a specific app (example can be found here: https://github.com/Maarc/application-graph):
        • 3rd party libraries
        • known open source libraries
        • self-written libraries
        • embedded war's / ejb modules - and for the war's of course their respective packaged libraries with the same requirements
        • when selecting a node, it provides more information such as
          • 3rd party libs / known libraries: maven coordinates if existent / extractable, archive name, url. basically what is already present in the dependencies report
          • self-written libraries/ embedded war's / ejb modules: size, maven coordinates if existent / extractable, archive name
      • (2) dependencies between different apps:
        • by connecting them based on the integration points (e.g. app1 exposed service1, app2 consumes service1)
        • the displayed information on the connection of nodes: type (e.g. REST, JMS Queue etc.), the name e.g. of the queue, the REST path, ...
        • when selecting a node, the app name should be displayed
      • (3) usages of libraries in different apps (something similar to shared libraries, just visually displayed)
        • imagine something like commons-lang. Show a graph with all the apps using it. see below for the handling of multiple versions
        • one connection per different version of commons-lang is also useful as I could then see the usage of each version ithin my app portfolio
      • (4) another graph showing the JDK the app / lib was built with, use unknown if this information is not known to us

      A navigation between those visualizations is not necessary for the MVP and will be handled separately later on.

      (1) and (2) are the MVP.

      These reports should be available in the static reports, following the current approach, there could be a rule provider generating the necessary data which is then included as script (jsonp) in the html page.
      The kubernetes-topology-graph could be a good starting point. it's used in manageiq (cloudforms) as well and uses D3 underneath. A starting point could be Marcs example here: https://github.com/Maarc/application-graph.

      Attachments

        Activity

          People

            Unassigned Unassigned
            jaeichle@redhat.com Janine Eichler
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: