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 <[email protected]> To: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-am_open-services.net
