This document outlines the SAVARA requirements for a SOArepository.

Artifact management:

1. Upload individual and groups of artifacts
2. 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
3. Delete artifact and relationships (relationships should not exist unless both ends exist)
4. Delete relationship
5. Create relationship between two artifacts
6. Relationships should support a type attribute (e.g. uses, implements, contains) and be directional
7. Relationships should allow additional metadata to be defined, to qualify the relationship (e.g. BPEL process 'implements' "participant Seller" in a related BPMN2 choreography)
8. Support automatic creation of relationships between uploaded artifacts, and artifacts already in the repository, based on predefined (extensible) policies
9. Support standard queries on artifacts, e.g. all users of this artifact
10. 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.
11. Validation issues need to be recorded against the relevant artifact – possibly retained as part of the artifact comment history
12. Artifacts and relationships should support comment history
13. 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)
14. 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).
15. 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.
16. 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.
17. 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.
18. 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.
19. Version management - different 'versions' of an artifact must be maintained in the repository. This could mean different referenced versions, such as two versions of a WSDL definition used in different services, or change history versions used when an artifact is edited online, as a means of viewing the changes (and reverting if necessary). However once a particular version is referenced, it should be managed as a primary artifact within the repository.

Lifecycle Management:

• Groups of artifacts will need to be managed through stages of a lifecycle
  • Example could be a BPEL process with associated WSDL, XSD and deployment descriptor managed as a Service through development, testing, user acceptance and finally production deployment phases.
  • Another example might be a rules package, being deployed through a Business Rule Management System
  • A further example might be a system architecture, consisting of a set of scenarios (use cases) as requirements, a choreography representing the 'global' behaviour, a deployment architecture representing various levels of detail regarding the deployment of components, and the component contracts (i.e. service contracts).

(Note: although the last example is not a deployable group, it represents a set of artifacts that describe the solution being built, and must equally move through stages of refinement, verification and authorisation. Once the service contracts are available, the indivual service development 'sub-projects' can proceed through their separate lifecycles, but be regularly checked to ensure they conform to the system(s) they are associated with. Its also possible that multiple development projects may be started to implement the same service but in different contexts/technologies - so the completion of a solution can be assessed based on the deployment to production of atleast one instance of each service implementation).

User interface:

1. User validation
2. 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))
3. Project view – ability to list projects user is directly/indirectly involved within
4. 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.
5. 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:

1. Metadata should accompany artifacts downloaded to Eclipse workspace, providing repository id info and relationship details
2. Tools should be provided to enable related artifacts to be located within the same workspace
3. 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.

This article was generated from the following discussion: Savara SOA Repository Requirements