[oslc-ArchMgmt] OSLC Architecture Management (AM) Meeting Summary (and call for discussion)

Fri Apr 29 13:52:11 EDT 2011

In this weeks OSLC AM call we continued our discussion of baselines,
specifically examining the current Core proposal for baselines in the
context of AM.

In this proposal the term "configuration" is defined, and from System
Architect's point of view roughly corresponds to a workspace, and from
Design Manager's corresponds to a project or stream.   A baseline in this
proposal corresponds to a snapshot in DM and a baseline in SA.

Baselines are created for the most part to provide an immutable
configuration for clients. Another scenario involves baseline comparison.

The overall proposal defines a camera capability which is used by a client
to tell the server to prepare a snapshot (frozen version) of a resource(s).
The snapshot'd resource is represented with a new URI. Implied in this
approach is the rewriting of all internally referenced URIs, should the
snapshot be part of a collection of interrelated resources. The client then
prepares a baseline resource with all the snapshot references in it and
POSTs it to the server.

While this proposal does not exclude cross service provider baselines, it
does not attempt to solve the problems of synchronizing snapshots of
resources across service providers and domains.  Jim Amsden noted that the
only right solution is to not have separate projects/providers where
resources of different types are managed by different providers. He argued
that by dealing with this specification we are not only perpetuating the
problem, but hardening in capabilities that may be difficult to change
later.

In AM domain, due to issues creating transitive closure, we typically
create a snapshot of entire configuration.  AM projects may contain 100s of
thousands resources to millions of resources.

This places a great burden on the client assembling the baseline resource,
since they must GET the entire list of snapshot URIs and then POST them
back in the baseline document.

We need a way in which a client can request a snaphot, but not be required
to explicitly add each and every resource URI individually to the baseline
resource. It would be nice if the client could get some other 'project
snapshot URI' from the camera action that represents the entire closure of
resources and can be passed into the baseline resource.  We currently do
something like this when we create baselines with JFS.  There we can create
a baseline resource by passing it a query instead of a list of resources.

Assuming we can get something like this to work in the proposed baseline
approach, Tom verified that System Architect's approach for baselining is
compatible with this. In SA when a workspace (configuration) is baselined
(snaphot'd) all the resources and the URIs are frozen. If/when a new
workspace is created from the baseline the resources can change, and only
when they do, does their URI also change.

In this scenario it is possible for the same resource URI to be part of
multiple baselines.  The current baseline proposal does not seem to forbid
this.

For Design Manager this proposal is a little more problematic.  Since DM is
a Jazz application and uses JFS for storage and baselines, its current
approach is to use the JFS baseline API to freeze the resources without URL
rewriting.  A baseline in JFS is basically moved to a separate index. DM
uses the convention of appending a query part to the URL to specify
baselined content.
This means that DM will have to either manually do the URL re-writing as
part of the baseline process (not sure how that will work with the JFS
baseline API), or we will have post-process all GETs on baselined resources
and update the URIs there.

Regarding baseline comparison, it is not clear that a client can do
baseline comparison easily.  Since the URLs are changed for each snapshot
of a resource. A client would have to GET each and every resource in both
baselines, and use the dcterms:identifier property to determine that two
resources were in fact just different versions of the same resource.  For
AM baselines that contain hundreds of thousands of resources (due to
transitive closure issues), this is quite a burden.

It may be useful to define some services that a client can use to more
easily map a resource URI to the re-written URL in a baseline.

I think we still have more to discuss with the approach, and I am hoping we
can keep up the conversation in this mailing list.

Regards,
___________________________________________________________________________

 Jim Conallen                                                                  

 Design Manager Lead Architect                                                 
 OSLC Architecture Management Lead                                             

 IBM Software, Rational                                                        

 Philadelphia, PA | 215-723-0489                         Twitter | Facebook |  
                                                                      YouTube  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110429/ce4b4e9b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 22724400.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110429/ce4b4e9b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110429/ce4b4e9b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 22812986.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110429/ce4b4e9b/attachment-0002.gif>