Composite Context Management

DEPRECATED THIS DOCUMENT IS NO LONGER ACTIVE IN ARCHITECTURE MANAGEMENT DISCUSSIONS

It has been requested in many AM workgroup meetings that we need to be part of a "composite context" where not only resources managed by one AM server are fixed, but also one where all of the resources on the other end of the links that it manages are also 'fixed'. So for example if I was looking at a specific 'version' of an AM resource (i.e. it is not allowed to change) and I follow one of its links to a requirement resource, the expectation is that the value of that linked resource is the same as when the link was was originally made. Or at the very least, the same version of requirement resource as when the AM resource was 'versioned' or frozen.

In the AM domain it is nearly impossible to 'version' a specific resource of a resource like a UML element, that is part of a highly fragmented set of resources. Thus, we recognize that individual resource versions are not useful, but rather collections of resources in a 'baseline' are. Taking this concept a little more generically lets consider this a 'context'. A context can be a baseline, or a stream, or any group of interconnected resources whose relationships between each other can be counted on as being reliable and up to date.

Another important concept that we want to preserve is the integrity of the resource and its URI. All resources in the AM domain have a URI which uniquely identifies them. A resource's properties may change, but its URI should not. This is important because it is desired by some referencers to be able to always point to the 'current version' of a given resource, even if its properties change. (for example referencing a work item, just because the work item got closed, shouldn't mean that there is a new URI for it to point to).

With this said there are several scenarios we would like to support that depend on the model integrity of AM resources.

scenarios:

Impact analysis: When a change is proposed to a resource or set of resources (either requirement or architecture) the impact of this change needs to be understood. A user will investigate this impact by examining the resource to be changed, the proposed changes to it. Then all the related resources are examined. Relationships from and too the changes resources need to be followed, and the impact of change on these needs to be accessed. Continuing through all connected resources until there is no impact.

• Impact Analysis Detailed Scenario

Review / Approve: When a review/approval package is put together with a collection of resources that needs to be examined by a group of people, it is important that these resources don't change during the process. Either a lock can be placed on these resources or a referencable version of these can be frozen for the review. This means that the service provider must be able to show the frozen version of the resource to the user at any future time. Typically users will baseline their projects at review points. They will want to link items to a known baseline of the target application. At review points they will want to review the links both against the baseline used for linking, but also against later baselines to access the impact of changes.Thus we should allow for the link to operate in the context of any baseline.

Architectural Forensics: When an architect needs to understand how some unexpected emergent behavior has infected the system it is necessary to examine both the current state of the resources (where the behavior is emergent), and a previous state of the resources (where the behavior is not). Having compare functionality will be useful. The forensics is carried out by examining representations of the resources and following its relationships to other resources and examining them in the same way.

Asset Management: When an asset is defined, it is desirable for that asset definition to reference specific versions of resources that can be retrieved at any given time, than to make a copy and cache the contents on an asset server. This means that the asset manifest needs a way to specify an architecture resource and a specific "version" that is not expected to change over time.

Test Result: When a test case is run, and the results are recorded it may be useful to reference the architecture resources that contributed to the system under test. These references only make sense if they are not the "live" changing ones, but like in the case of asset management, are frozen and represent the exact state of the resource as it was used in the test, and that the test results represent.

Audit: Audits are usually done at some major milestone of a process, usually at the end, looking backwards in time to ensure adherence to certain standards such as corporate polices, regulatory requirements, and approval requirements. It is important that the auditor must be able to recreate the state of any architecture resource, including its relationships, at key milestones of the design and development process. This will enable the auditor to look back in time and conduct compliance investigations relative to the rules and policies associated to the milestones.

Requirements

The following represent some discrete requirements that a baseline/stream/context mechanism must implement.

1. A client does not have to do anything special in order to resolve references in a resource?
2. A client can request the pedigree of a resource.
3. Service providers know which contexts are related/connected to which contexts managed in other servers.
4. A resource can only appear at most in one context associated with another.
5. SA does not have context independent URIs
6. SA doesn't have default context

Terminology

Many systems and environments deal with these same issues and many have related or similar terminology. It is important to remain consistent in the use of terminology when discussing requirements and solutions proposals for this topic.

Most importantly is remaining consistent with other OSLC specifications. The SCM workgroup has a terminology page that provides a comparison of terms used by several commonly used products. It also references this WebDAV document which also provides definitions for common terms.

Proposal

One proposal for managing contexts, both in the AM domain, but more importantly across domains in a generic way, is to rely on a Composite Context Manager. This service is responsible for grouping together 2 or more service provider's contexts (where a service provide context is a set of interrelated resources).

Before we look at the composite context manager, lets see how one server provider could manage a context, and make it available to a client. Suppose we start off with a resource whose URI is http://host/res/42. This is the live base URI for the resource, in its simplest form. This resource will evolve over time. Doing a GET on it today may not yield the same results as doing so next week.

A service provide may create a context (implemented as a baseline of a group of related resources), and assign the baseline itself the URI http://host/baseline1. A client can GET the resource in that context by adding a query string to the base URI with the query parameter oslc.context= and specify the baseline URI as its value to request the representation of that resource as it is/was in that context.it can be thought of as a separate resource because when the query part is included it is a different unique URI. The client can also intepret this as the resource 42 as it appears in the context. If the client wanted the current 'live' version of the resource they would just do a GET on http://host/res/42, with no query part.

Using a query part to identify a resource in a context has the advantage of being able to pass and use a single opaque URI to someone/thing else and to have it specify the specific context the resource is in.

Other ways of doing this might involve using custom HTTP headers with the context identifier in the GET request. The disadvantage of this is that it is difficult for users receiving this URI in an email to GET it in a standard web browser (without having a browser add on like Poster or Modify Headers).

In addition to baselines, other types of contexts might be streams. The main difference being a stream is likely to have changing resources (they are not fixed). This is an option for service providers that want to implement streams where resources don't get assigned new different URIs but maintain the URI of the resource they were forked from.

It also brings up the concept of a 'default context' - kind of like HEAD in CVS. Not all service providers can support the notion of a default context.

Federated or Centralized context management?

If a service provider manages contexts like this, then there are at least two ways to coordinate contexts between providers. There can be a centralized context manager that knows which contexts in which providers are associated with each other. Or each provider can be responsible for managing its own associations.