RISCOSS Architecture

On the left side there's everything that exists and that is used by Open Source communities to manage their projects and activities. Usually what we find here is publicly accessible (with some exceptions).

In the bottom we find companies, and in general users of the RISCOSS Platform, with the systems they use to manage their project and activities. This can be considered functionally equivalent to what we find in the Open Source communitites with the difference that they are not accessible from the outside of the company.

In the middle we find the RISCOSS Platform that can interact with these systems and provide functionalities to users in order to perform risk analysis of Open Source component adoption.

Components inside the RISCOSS Platform Boundaries

• Risk Data Collector: a standalone components that are able to collect relevant raw data from different sources. (see riscoss-data-collector repository for detailed information)
• Risk Data Collector Manager: it manages the Risk Data Collectors available in the platform by providing, through an API, information about what is available, and which are the parameters they need. It also manages the execution (e.g., scheduling) of the Risk Data Collectors. By having such a component, when the Layer Manager creates a new entity it will ask the user how to configure the Risk Data Collectors that must be run to collect Risk Data for that entity. The Risk Data Collector Manager will then receive this data so that it can start the data collection process, and associate the collected data to the right entity in the Risk Data Repository.
• Risk Data Repository: it provides storage and query facilities for storing and retrieving Risk Data. Risk Data Collectors will use the exposed APIs to send and store the extracted Risk Data into the RISCOSS Platform.
• Domain Administration System: it is the central element of the RISCOSS Platform and provides isolation for the activities performed in the RISCOSS Platform. A domain is a container for all the data related to a given context. An entity using the RISCOSS Platform will have its own domain isolated from the others. In each domain, users can specify its own models, layers, roles, and store relevant data for performing risk analysis (e.g., business models, risk reports, etc.).
• Authorization and authentication: it provides authorization and authentication functionalities to the RISCOSS Platform. The Domain Manager will use it in order to grant (or not) access to the resources stored in a domain to a given user.
• Event Notification System: it provides the functionalities for tracking activities and send notifications when particular events occurs (e.g., a new risk report is created).
• Risk Analysis Engine: it contains all the logic for performing the risk analysis using the data available in a given domain. (see riscoss-analyser repository for detailed information)
• Domain Manager: it is a macro-component that manages all the data that can be manipulated in a given domain. It contains several sub-components that will be detailed in the following sections.
• Layer Manager: it provides the means to define and manage (i.e., store, query, retrieve) which layers are actually present in a given domain. In particular it provides a way to create a hierarchy of layers, and define the structure of an entity belonging to a layer. A layer in this context, represents a set of entities that belongs to a given category (e.g., OSS Components, Products, Projects, etc., and the relationships among them).
• Role Manager: it provides the means to define and manage (i.e., store, query, retrieve) which roles are actually present in a given domain. A role defines a class of users, and is used to define the rules for accessing data and functionalities.
• Risk Analysis Manager: it provides the means to define and enforce the process for performing risk analysis in a domain.
• Risk Configuration Manager: it provides the means to manage (i.e., store, query, retrieve) all the artifacts needed by a risk analysis.
• Risk Report Manager: it provides the means to manage (i.e., store, query, retrieve) the results of Risk Analysis performed in a given domain.
• Form/Questionnaire Manager: it provides the means to define and manage (i.e., store, query, retrieve) user input forms for letting the user insert information that is needed by the Risk Analysis Engine.
• Feedback Manager: it provides the means to manage (i.e., store, query, retrieve) user feedback on data managed in a domain. In particular such feedback is given on risk analysis reports, but it's not limited to it.

Components outside the RISCOSS Platform boundaries

The following components are outside RISCOSS Platform boundaries and, thus, are managed by other entities with respect to the ones managing the RISCOSS Platform.

• Tools for OSS Development and Management: these components are the building blocks of the systems that are publicly accessible, and that are used by Open Source communities to manage their projects and support their activities. This raw data is a crucial ingredient for understanding the characteristics of the Open Source Software, of the community revolving around it, and thus, for evaluating the risks that might arise in adopting such a software. Examples of such systemts are: Code repositories (e.g. http://github.com , http://gitorious.ow2.org ), Bug tracking systems (e.g. http://jira.ow2.org , https://bugs.eclipse.org/bugs ) or Mailing list and their archives (e.g., http://lists.xwiki.org ).
• Data Mining and Analysis tools: These systems provide a view on the data available through the Tools for OSS Development and Management in order to highlight certain aspects. These tools provide an effective means to aggregate raw data coming from the Tools for OSS Development and Management in order to extract very detailed information on some well defined aspects (e.g., software quality, licenses, interactions, etc.).Examples of such systems are: Sonar (e.g., http://nemo.sonarqube.org), Antelink (http://www.antelink.com ) or Ohloh (http://www.ohloh.net).
• People (Community): Of course people are not components, though they can play a role in the whole picture in the sense that people actually store (qualitative) information about the Open Source projects and communities to which they participate. And they can indeed provide this information through different means if requested.
• Company management systems: These systems are the ones used by a company to manage its activities. In some sense they are functionally equivalent to the ones used by Open Source communities, even though they are not accessible from outside the company itself - in this context we will find again bug tracking systems, code repositories, mailing lists, and so on.