[oslc-ArchMgmt] OSLC AM Minutes 12-May-2011

James Conallen jconallen at us.ibm.com
Thu May 12 11:43:33 EDT 2011



The minutes of today's call have been posted:


Attendance


Regrets: Steve Speicher, Dave Johnson, Vishy Ramaswamy, Tom Picolli, John
Crouchley


Atendees: Alann Zito, Clyde D. Iscuspit, Jim Conallen


Minutes


Low turnout due to vacations, and some of the Rational folk busily
preparing for the Innovate conference.


We picked up on discussions from last time regarding the baseline proposal
being discussed in the core. The big concern today is scalability for some
systems that need to copy resources to complete a snapshot and when the
transitive closure can't be computed efficiently. Design Manager (DM) fits
into this category.


When DM snapshots even just a single resource, it must snapshot the entire
project context. This is because the resources are highly fragmented. For
some of our larger test models, the snapshot process can take from 10
minutes to 3 hours! This puts into question the proposal's approach of a
simple POST with the camera capability to create a snapshot. A client is
not going to wait anywhere from 10 minutes to 3 hours for a response to a
POST call.


The way DM does it today is that a POST is used to start a snapshot
creation, but the response to the POST does not include the summary of it.
Rather the client requesting the snapshot polls the server for the status
of the snapshot (creating, aborted, done...). We may need the proposal to
be extended to accommodate service providers with extremely long snapshot
times.


In general we modeling folk think of baselines as all encompassing actions
on the model. We tend not to think of baselining just a small subset of
model elements (a diagram, a class, etc). One possible use case for
baselines might be to support formal reviews on resources that are frozen.
In these scenarios normal users will create a review on a subset of
resources (models, requirements, test cases), and request a snapshot of
each to include in the baseline. The review is then carried out on the
baseline. Such a scenario might be carried out a couple times a day by
different users. For a provider like DM this means the creation of several
snapshots a day - something that will not scale in its current form today.


One idea tossed in the meeting is instead of taking a snapshot of the
entire project context in the repository, we instead cache a rendering of
that subset of resources (diagrams, properties, oslc responses). When
clients ask for the baselined resource we return the cached resource. Of
course this type of baseline would not allow the navigation through
resources that were not explicitly part of the snapshot, and we could not
support general querying. But it would, by orders of magnitude, increase
the efficiency of baselining small sets of resources.


It was pointed out that even in this scenario a user viewing one of these
baselined resources, might want click on an element in a diagram (that was
not cached in the baseline) or navigate to the parent of an element or
something. We see this desire in looking at historical requirements. When
you look at a requirement's previous version, you often want to know what
the linked, or sibling requirements were at that time as well. Similarly
looking at a work item's history is only part of the view. If I note the
state of a work item at a particular time, it is not easy to figure out the
state of the other work items in the same project at that same time.


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


More information about the Oslc-Am mailing list