[oslc-ArchMgmt] OSLC AM bi-weeking meeting minutes. Topic: core baseline proposal

[James Conallen]

the minutes are now posted on the OSLC AM wiki (and copied here).  Please
take a few minutes to look over them, and reply to this email if you have
ANY comments or questions.



Our main goal is to summarize a list of issues/recommendations regarding
the core baseline proposal that are of particular interest to our AM
domain.

Our primary concern is the scalability of the camera capability and
snapshots.  In the AM domain we have highly fragmented resources, and
computing the closure of resource URIs necessary to re-render and represent
may be impossible for some providers.  The result is that for providers
like Design Manager, even snapshotting a single resource will in turn
require the entire molding context (i.e. UML model or project) to be
included in the snapshot.

This means that some providers will end up creating snapshots that include
nearly a million resources, and may take from 10 minutes to 3 hours to
complete.

Given that a snapshot may now take three hours to create and include over a
million resource URIs, we are concerned that the camera proposal will not
scale for typical clients.   I client will have to wait for nearly 3 hours
for the return of a POST to create a snapshot, and then process the million
URIs that come back (hopefully as a paged resource).

Additionally in the AM domain we are more likely to want to snapshot and
entire context (project) each time, than a small subset of resources.

It would useful to be able to create a snapshot and instead of getting a
list of all the URIs in the snapshot (again potentially over a million),
and instead get a some moniker, perhaps a URI of the snapshot instance to
use later in the creation of the baseline resource.  We think that
snapshots would be useful as persistent things.

The baseline resource could then be populated with snapshot references
instead of resource instance URIs.

We also discussed briefly one of the goals of the baseline proposal; to be
able to compare baselines.

In the AM case, using the current proposal, the baseline resources will
have possibly millions of URIs in them, each opaque and unique to the
snapshot'd instance of the original resource.  In order to compare
baselines a client will have to GET a resource's representation from one
baseline, then keep GETing resources in the other baseline until it finds
the one that has the same dcterms:identifier of the resource in first
baseline.   For a baseline with millions of resources this is daunting.

It might be useful to specify some services that a client could use to more
quickly find the snapshot'd URI of a resource in a baseline, so that it
would not be request to walk through the baseline one resource at a time.
This might be in the form of a query on the baseline resource or some other
service.


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/20110526/617f310c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1D622652.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110526/617f310c/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/20110526/617f310c/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1D876450.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110526/617f310c/attachment-0002.gif>