MediaWiki API result

{
    "warnings": {
        "query": {
            "*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
        }
    },
    "query-continue": {
        "allpages": {
            "gapcontinue": "References"
        }
    },
    "query": {
        "pages": {
            "2226": {
                "pageid": 2226,
                "ns": 0,
                "title": "Redmine",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "= Introduction =\nRedmine is an open source, web-based project management and issue-tracking tool. Redmine allows hyper-linking information between tickets, revision control systems (e.g. SVN, GIT) and wiki contents.\n\n= gCube Redmine Project =\nThe D4Science infrastructure provides an instance of Redmine with a dedicated project for gCube tracking issues. This instance is available at [https://support.d4science.org/projects/gcube https://support.d4science.org/projects/gcube]\n\nThe D4Science Redmine instance supports AGILE methodology: the development process is made up of '''Milestones'''. The target of a Milestone is a new gCube release. Inside each Milestone, the work is mainly organized into '''Sprints'''. A '''Sprint'''  is a collection of actions taken to reach a goal. A '''Sprint''' should not have a duration of more than 2 weeks and should never last more than one month. The tickets associated to a '''Sprint''' are the list of actions required to reach the goal.\n\n= Tracker Types =\nRedmine is used to (i) trigger new activities for the gCube software, (ii) answer to support requests, (iii) react to defects found in candidate releases of the gCube System, and (iv) manage release procedures (e.g. start of releases, subsystem configurations attachment etc.).\n\nThe gCube project provides different tickets types (''trackers'' in the Redmine terminology) to build up a clear view of the gCube Software system status. Each tracker may have different fields and different status. In order to be compliant with AGILE methodology, each task must belong to one Sprint.\n\n== Feature ==\nUsed to define a task, in order to accomplish the objective of the '''Sprint''' it belongs to.\n\n== Bug ==\nUsed to keep track of malfunctionings (bugs) of software components or of issues in a release process.\n\n== Support ==\nTo request support for using a software component. It can be used by a developer to request information about a particular library built by another developer. Otherwise, it can be used by an end-user to ask help for interacting with an interface.\n\nWho opens this type of ticket MUST be sure that a similar ticket does not exist already. After each request of support, developers should take actions in order to merge requests referring to the same issues.\n\n== Release ==\nUsed during release cycles, to keep track of the subsystems and the related components to release.\n\n\n= Open Release =\nRedmine allows the definition of complex queries and save these queries for quickly access the results. This feature is used to organize the release tickets into a global and synthetic view of the integration status of the current release.\n\n[[File:Release_status.png|700px|center|frame]]\n\nFrom this view, it is possible to immediately identify:\n* how many and what components have been released in each subsystem (''Subject'' column)\n* the release status (''Status'' column) of a component (New, Available, Under Integration, Build Issue, ...)\n* the responsible of each component/subsystem (''Assignee'' column)\n\nFrom this view it is also possible to select multiple release tickets and perform batch operations on them (e.g. set statuses). This makes the view very convenient for [[Role_Release_Manager|RMan]] and [[Role Subsystem Manager|SMan]] that often need to update several tickets at once.\n\n= Eclipse Integration =\n\nThe Redmine instance has a Mylyn connector plugin which allows to create/update tickets from an external application.\nSo far there is the possibility to use an Eclipse plugin which simplify the ticket management. The developer does not need to open the browser to check/create/update tickets, because he/she can do it directly from Eclipse.\n\nMoreover the plugin allows the developer to activate the ticket he/she is working on.Moreover, the plugin can perfectly integrate with versioning system and help the developer to link the SVN/Git commit to the ticket .\n\nThe Redmine instance has an svn/git connector. Redmine recognize some words in svn/git comments and create references between comment and tickets. You can take a look to [https://support.d4science.org/projects/gcube/repository https://support.d4science.org/projects/gcube/repository] to check how it works.\n\nTo install the Eclipse plugin you can follow the guide [[Install Redmine Mylyn Plugin in Eclipse]]."
                    }
                ]
            },
            "377": {
                "pageid": 377,
                "ns": 0,
                "title": "Reference Model",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "[[Category: Developer's Guide]]\nAccording to <ref>MacKenzie, M.; Laskey, K.; McCabe, F.; Brown, P.; Metz, R. Reference Model for Service Oriented Architecture 1.0. OASIS Committee Specification, August 2006</ref>: <blockquote>A reference model is an ''abstract framework'' for understanding significant relationships among the entities of some environment. It enables the development of specific ''reference'' or ''concrete architectures'' using consistent standards or specifications supporting that environment. A reference model consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain, and is independent of specific standards, technologies, implementations, or other concrete details.</blockquote> This section introduces the concepts characterising gCube as a system. Before proceeding, it is fundamental to clarify the fact that gCube is actually composed of two different materialisations: the \u201c''living system''\u201d users interact with (a.k.a. the gCube Infrastructure) and the \u201c''software system''\u201d supporting the deployment and operation of the D4Science Infrastructure (a.k.a. gCube framework). Clearly, they are closely related, since the software system is the enabling technology of the living system. This guide focuses on the \u201csoftware system\u201d but the concepts presented in this reference model characterise both \u201csystems\u201d. \n\nThe concepts constituting the gCube Reference Model are organised in different domains:\n: ''(i)'' the [[Reference_Model#Resource_Domain|'''''resource domain''''']] represents the entities managed by gCube system; \n: ''(ii)'' the [[Reference_Model#User_Domain|'''''user domain''''']] represents the entities, both human and inanimate, interacting with the system; \n: ''(iii)'' the [[Reference_Model#Policy_Domain|'''''policy domain''''']] represents the rules governing the system behaviour and functionality; \n: ''(iv)'' the [[Reference_Model#Architecture_Domain|'''''architecture domain''''']] represents the concepts and relations needed to characterise a gCube based architecture; \n: ''(v)'' the [[Reference_Model#VRE_Domain|'''''VRE domain''''']] represents the concepts and relations needed to characterise a ''Virtual Research Environment''.\n\n== Resource Domain ==\ngCube is a software system conceived to manage an infrastructure consisting of a set of heterogeneous entities that we call ''gCube resources''.\n\nAll such heterogeneous '''''resources''''' share some commonalities (''gCubeResource)'': \n\n* each gCube resource has a '''''unique identifier''''' (ID);\n* each gCube resource has a '''''type '''''(Type); this information characterizes the role the resource plays in the infrastructure;\n* each gCube resource has '''''multiple scopes '''''(Scopes) allowing to characterise the contexts the resource is supposed to operate (VO/VRE);\n* each gCube resource has a '''''profile''''' (Profile) to capture the distinguishing features of the resource to support resource discovery and usage.\n\nThe XML document schema that describe shared commonalities can be found here: [[Common Type Definitions XSD|XSD]]\n\n===Resource types===\nEach resource type is defined thanks to an XML Schema Definition document which describes the distinguishing elements and attributes of the resource type.\n\n* '''gCube Service''': A resource representing software, primarily a networked service. ([[gCube Service XSD|XSD]])\n* '''gCube Hosting Node''' (''gHN''): A resource representing the hosting node on which gCube can dynamically deploy a Service (along with all the needed software libraries) to create a RunningInstance. ([[gCube Hosting Node XSD|XSD]])\n* '''gCube Running Instance''': describes a deployed and running instance of a ''gCube Service'', primarily the endpoint of a networked service. ([[gCube Running Instance XSD|XSD]])\n* '''gCube Generic Resource''': Resource representing a generic entity. ([[gCube Generic Resource XSD|XSD]])\n* '''gCube Runtime Resource''': Resource representing software service that is running on a generic host. ([[gCube Runtime Resource XSD|XSD]])\n* '''WS-Resource''': According to the \"OASIS Web Services Resource Framework\" A WS-Resource is the composition of a resource and a Web service through which the resource can be accessed. ([[WS-Resource XSD|XSD]])\n\n== User Domain ==\nIn gCube the term \u201cuser\u201d identifies entities entitled to interact with the infrastructure. This definition includes not only human users (externals to the infrastructure) but also services (part of the infrastructure itself) autonomously acting in the system. Batch services (e.g. monitoring services) are an example of such type of users that, by reacting to status changes or on a temporal basis, interact with other entities. Thus, some gCube services need to be identified and managed, from the authentication and authorization point of view, as users.\n\nThe gCube architecture exploits the Public Key Infrastructure (PKI) paradigm to uniquely identify users in the infrastructure. gCube users are provided with a private key and a public certificate that can be used to authenticate to other entities. Private keys and public certificates are issued and revoked to users by a trusted entity, named Certification Authority (CA). The gCube infrastructure is designed to support CAs acknowledged by the International Grid Trust Federation ([http://www.igtf.net/ IGTF]).\n\nVO-Management components provide functionalities to manage gCube users and their credentials.\n\n== Policy Domain ==\nIn gCube, the '''Virtual Organization''' (VO) concept is used to define authorization policies in the infrastructure. A Virtual Organization is a dynamic pool of distributed [[Reference_Model#Resource_Domain|resources]] shared by dynamic sets of [[Reference_Model#User_Domain|users]] from one or more real organizations. Resource Providers (RP) usually make resources available to other parties under certain '''sharing rules'''. Users are allowed to use resources under Resource Provider (RP) conditions and with the respect of a set of VO policies.\n\nFollowing this approach, the '''gCube VO Model''' defines a policy as:\n\n: a '''permission''' for a [[Reference_Model#User_Domain|'''user''']] to perform an '''operation''' on a specific [[Reference_Model#Resource_Domain|'''resource''']]. \n\nThe gCube VO Model also leverages the concept of '''role''', as introduced by the RBAC model, to decouple the association between users and permissions. Furthermore, roles are organized in hierarchies, thus allowing a natural way to capture organizational lines of authority and responsibility. Role hierarchies are not constrained to be trees; each role can have several ancestors with the only constraint that cycles are not allowed in the structure.\n\nThe gCube VO Model is shown in Figure 2.\n\n[[Image:VO_Model.jpg|frame|center|Figure 2. gCube VO Model]]\n\nThe model takes into account two different actors managing policies over resources:\n\n* '''Resource Providers''' \u2013 resources' owners defining sharing rules, i.e. policies to resource access with respect to Virtual Organizations as a whole;\n* '''VO Managers''' \u2013 users defining permissions, i.e. policies to access resources with respect to VO members individually. Permissions have to comply with sharing rules defined by Resource Providers for a specific VO.\n\n== Architecture Domain ==\nThe gCube system relies on a component-oriented Architectural model which subsumes a \u2018'''''component-based approach'''''\u2019, i.e. a kind of application development in which:\n\n* The system is assembled from discrete executable components, which are developed and deployed somewhat independently of one another, and potentially by different players.\n* The system may be upgraded with smaller increments, i.e. by upgrading some of the constituent components only. In particular, this aspect is one of the key points for achieving interoperability, as upgrading the appropriate constituents of a system enables it to interact with other systems.\n* Components may be shared by systems; this creates opportunities for reuse, which contributes significantly to lowering the development and maintenance costs and the time to market.\n* Though not strictly related to their being component-based, component-based systems tend to be distributed.\n\nThe components characterising a gCube based system from the architectural point of view have been introduced in the [[Reference_Model#Resource_Domain|Resource Domain]] section: all the ''gCubeResource'' types with the exception of the ''ApplicationSpecificResource'' are considered first class citizens in a component-oriented architecture. \n\nThe Architecture Domain itself can be described through ''different and focused views'', capturing a different aspect of this multifaceted domain. Each of these views potentially uses a subset of the architectural components. For example:\n* if the goal of a view is to describe the current running instance of the gCube based Infrastructure serving D4Science the concepts that will be primarily used are the notions of: ''gHN'' (to capture the machines implementing the Infrastructure), ''RunningInstance'' and ''ExternalRunningInstance'' (to capture the running services supporting the operation of the whole), and ''gLiteResource'' (to capture the nodes of a gLite based infrastructure conceptually contributing to the whole) are used. \n\n* if the goal of a view is to describe the system from a static point of view, i.e. its software constituents, the notions of ''Service'', ''SoftwareLibrary'' and ''ThirdPartyLibrary'' are used.\n\n== VRE Domain ==\nThe notion of ''Virtual Research Environment'' (VRE) is a cornerstone of the whole gCube Infrastructure. \n\nFrom a user perspective, a Virtual Research Environment is an integrated and coordinated working environment providing participants with the resources (data, instruments, processing power, communication tools, etc.) needed to accomplish the envisaged goal. Such environment has the strong characteristic of being extremely dynamic because of the potential dynamism of the participating community, both in terms of the constituents and requirements. \n\nThis also meets the e-Science vision that demands for the realisation of research environments enabling scientists to collaborate on common research challenges through a seamless access to all the resources they need regardless of their physical location. The resources shared can be of very different nature and vary across application and institutional domains. Usually they include ''content'' ''resources'', ''application services'' combined to produce new knowledge, and ''computational and storage resources,'' which physically store the content and support the processing of the services.\n\nFrom a [[Reference_Model#Resource_Domain|Resource Domain]] perspective, a VRE is a pool of ''gCubeResources'' dynamically aggregated to behave as a unit with respect to the application context the VRE is expected to serve. Each VRE is a '''''view''''' over the potentially unlimited pool of resources made available through the gCube infrastructure that (''i'') is regulated by the user community needs and the resources sharing policies and (''ii'') produces a new VO constraining the scope and usage of resources actors playing in the VRE are subject to.\n\n== Notes ==\n<references/>"
                    }
                ]
            }
        }
    }
}