[oslc-ArchMgmt] OSLC Architecture Management (AM) Meeting Summary (and call for discussion)
Sandeep Kohli
sandeep.kohli at in.ibm.com
Mon May 2 08:59:31 EDT 2011
Hi Jim
Is the new version of a resource and new resource itself or just a query.
In REST terms, should that have its permanent URI or should it be a query
parameter denoting a baseline in the original resource. Implementation
aside, we should first address this. What concept do we want to use.
Depending on what we choose, then we have different set of problems to
resolve.
If we treat each committed modification as generating a new resource, then
we should be generating the URI to represent the new resource immediately.
For example the following 2 URI can represent a class at two different
snapshot's ( or baselines )
https://jazz.net/projectb/Class1/c1
a little while later if some modififes the resource
https://jazz.net/projectb/Class1/c2
and
https://jazz.net/projectb/Class1/latest
is just an alias for whatever be the latest and for the current example it
just points to https://jazz.net/projectb/Class1/c2
Assuming that the new URL is generated on every commit, Such system has
its own benefits and overheads.
Benefits.
Snapshots are easy and fast as URL is already computed and available.
More closure to REST way of doing things. Everything is a resource and is
cleaner.
URL are opaque.
Drawbacks ( or someting that needs to be implemented )
How do you identify version ( probably embedding UUID in the resource )
How do you find all the possible version of a given resource.
How do you decide if you should link to the snapshot or the latest.
Second way of doing things is treating the resource as one single thing
and treating every committed modification as a query param appended.
This has it own benefits and draw backs.
Benefits
Faster to compute a resource if given a snapshot descriptor ( note:
Computing snapshot is the whole system will be difficult. )
Faster to find all version of resources.
Drawbacks
Probably more expensive to create a snapshot.
URL are not opaque
more expensive to retrieve a resource.
My 2 cents is that we should first decide which of the above 2 strategy we
want to adopt in general. And depending on that we should then decide what
kind of services do we need to create to address to requirement of the
chosen strategy.
PS: I used snapshot and baseline almost interchangeably.
Regards,
___________________________________________________________________________
Sandeep Kohli
Architect/Senior Manager
Analysis Design and Construction tools
IBM Software, Rational
Bangalore
Twitter | Facebook | YouTube
From:
James Conallen <jconallen at us.ibm.com>
To:
oslc-am at open-services.net
Date:
29/04/2011 11:44 PM
Subject:
[oslc-ArchMgmt] OSLC Architecture Management (AM) Meeting Summary (and
call for discussion)
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
_______________________________________________
Oslc-Am mailing list
Oslc-Am at open-services.net
http://open-services.net/mailman/listinfo/oslc-am_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-am_open-services.net/attachments/20110502/20f8638b/attachment-0008.gif>
More information about the Oslc-Am
mailing list