This document outlines the SAVARA requirements for a SOArepository.

Artifact management:

• Upload individual and groups of     artifacts
• Find artifacts based on artifact     type and possibly artifact type specific extensions, e.g. artifact     type = wsdl and wsdl-specific-namespace = http://acme.com/schema
• Delete artifact and relationships     (relationships should not exist unless both ends exist)
• Delete relationship
• Create relationship between two     artifacts
• Relationships should support a     type attribute (e.g. uses, implements, contains) and be directional
• Relationships should allow     additional metadata to be defined, to qualify the relationship (e.g.     BPEL process 'implements' "participant Seller" in a     related BPMN2 choreography)
• Support automatic creation of     relationships between uploaded artifacts, and artifacts already in     the repository, based on predefined (extensible) policies
• Support standard queries on artifacts, e.g. all users of this     artifact
• Provide validation extension points, triggered when artifacts     (or relationships) are created, changed or deleted. In the case of     deletion, a 'pre-deletion' hook may be necessary.
• Validation issues need to be recorded against the relevant     artifact – possibly retained as part of the artifact comment     history
• Artifacts and relationships should support comment history
• It might be necessary to enable a user defined status change,     associated with an artifact/relationship, to override any system     derived status (may be subject to certain role privileges)
• Change in validity status should be reported to relevant     users. Users/groups should be identified based on the appropriate     relationship types. The report to the specific users should be based     on artifact the user/group is associated with, e.g. if development     manager of a service X, then notification should be reported as     “Service X has a fatal error” - the nature of how the reports     should be aggregated needs some thought – but should aim to remove     unnecessary notifications (i.e. provide a single summary per main     artifact associated with user with all relevant changes).
• Notification filters should be possible – e.g. stakeholders     may not be interested in a projects fluctuating status until close     to the proposed release date. They may also not be interested in the     individual low level artifacts causing the problem, just the overall     service status, so some content filtering may also be appropriate.
• User/group relationship – relationship type might define     the user/group's responsibility in respect of the artifact, e.g.     group X “responsible for” (i.e. develops) service Y, or user A     is the stakeholder for project B.
• Projects should be defined as an artifact, acting as the     container for the artifacts created during the lifecycle of a     project. Some artifacts will be shared across projects, such as in     the case of shared services, or different versions of a choreography     between version 1 and version 2 of a system.
• Access control – need to control visibility of what a user     can view and edit. Need to consider how best to achieve this, as we     don't want a user to be directly related to each artifact they are     permitted to edit/view, as this will be a maintenance nightmare. So     needs to be achieved based on a scope – e.g. if a user has edit     privileges on a project, then that should mean they can edit     anything within the project – but need to decide what this means     when dealing with shared artifacts? Does the project need     authorisation from the artifact's owning project's manager before     they can share it – and when establishing the share, possibly this     is where an agreement is established concerning the edit rights.

User interface:

• User validation
• Navigation views focused on user's areas of responsibility     (e.g. list of primary artifacts the user is related to –     potentially via its group(s))
• Project view – ability to list projects user is     directly/indirectly involved within
• Enable user to navigate through the artifacts in those views,     that they have visibility of, using any suitable visual     representation appropriate for a graph (could be hierarchical tree     or graphical graph representation). The navigation will be based on     the relationships, showing the relationship types.
• Edit artifact – where an editor exists for the artifact     type, it should be possible to edit the artifact directly in the web     application. Collaborative editing would be even better.

Eclipse integration:

• Metadata should accompany artifacts downloaded to Eclipse     workspace, providing repository id info and relationship details
• Tools should be provided to enable related artifacts to be     located within the same workspace
• Should be possible to relate new and existing repository     artifacts, within the workspace, prior to the new artifacts being     uploaded to repository. Once uploaded, the temporary relationship     information should be translated into persistent relationships, and     the relevant updated in the Eclipse workspace.