Version 5

    1. Background

     

    1.1 Why do we need the Guvnor repository?

     

    Users need a location where SOA artifacts can be subject to governance. Governance includes capabilities like security (access control, change control, etc.), preservation (ensuring that key resources are maintained) and integrity (of individual resources and the links between the resources being governed).

     

    1.2 Why can't we use an established source code management (SCM) system like Subversion?

     

    SCM solutions are designed for development scenarios, but Guvnor covers more.

     

    1.3 Will Guvnor be a replacement for an SCM?

     

    Not in the short term. Initial versions of Guvnor will not be a replacement for an SCM, and we expect Guvnor and standard SCM systems to be deployed in the same environment. In the long term, the other repositories might offer a superset SCM solution including governance.

     

    1.4 Why can't we augment a SCM to have Guvnor capabilities?

     

    Since SCM were not designed to cover Guvnor use cases, supporting Guvnor as an extension to an SCM would be difficult. Further, each solution would be SCM specific, and hence we'd have to support a number of different Guvnor implementations for popular SCM products.

     

    1.5 Even if Guvnor were a superset SCM solution, can we mandate that SOA-P adopters use it?

     

    This is not clear. We do not mandate that SOA-P users select only our specific database, for example, and we try to support as many choices as possible. (For platform-internal use, this is less of an issue.) Even if Guvnor were a superset SCM, what would we say to clients holding investment in existing SCM solutions, especially commercial ones (where the transition costs could be very high/impractical)?

     

    1.6 What is the position of Guvnor with respect to SCM?

     

    Guvnor will exist (again, in the foreseeable future) side by side with existing SCM installations.

     

    1.7 What is resource identity and why is it important to this discussion?

     

    Resource identity refers to being able to assert that two resource instances are copies of the same 'master.' For example, if two developers take a local copy of a specific source code file from a SCM and the version is the same for each, then each of these two resources have the identity. Independent changes in each of these two copies will need to be merged into the master copy. For two resources that are not identical, independent changes do not have to be merged into a master copy.

     

    2. Design Questions

     

    2.1 Will the set of resources be partitioned between Guvnor and the SCM, or could there be overlap?

     

    In almost every case, there will be overlap between Guvnor and SCM resources.

     

    2.2 If there is overlap, then where is the master file, in Guvnor or the SCM?

     

    This is not clear. As much as we'd like to mandate that Guvnor controls the master copy, it is unlikely that users will always agree.

     

    Even assuming that one system (Guvnor or the SCM) can be taken as the owner of the master copy for a resource, then what is the status when the Guvnor version, the SCM version and the local copy diverge? How is resource identity resolved so changes in these three places can be accommodated?

     

    2.3 Will Guvnor contain any type of resource (examples: Java source files, ESB configuration files, business process definitions, rule definitions) or be restricted to certain file types?

     

    Guvnor will be restricted to a set of file types that need to be governed.

     

    If Guvnor is to control specific types of resources (especially for referential integrity) then Guvnor needs to 'understand' these resources. That is, Guvnor needs to have a model for each resource type that allows resource instances to be evaluated.

     

    2.4 How will these Guvnor resource type models deal with:

    • Specific versions of resources where the rules might change (example: in one version of SOA-P, the ESB configuration file might have certain constraints, in a later version, certain constraints might have changed)?

    • Incomplete resources: Will Guvnor allow resources that do not conform to model constraints into the repository? If so, then how are these constraints violations tracked and reported to users?

     

    2.5 If project resources in Eclipse are to be governed (associated with a resource in Guvnor), then what happens when:

    • The resource is renamed or deleted, but doing so would violate constraints in Guvnor?

    • The resource is changed in the SCM, but doing so would violate constraints in Guvnor?

    • The local resource is changed, then changes propagated back to Guvnor, but then the SCM is found to have a different (later) version of the same resource (c.f. resource identity above)?

     

    2.6 Does deleting the resource in the Eclipse project delete the resource in Guvnor? In the SCM? Both? Neither?

    • Does renaming the resource in the Eclipse project rename the resource in Guvnor? In the SCM? Both? Neither?

    • Does moving the resource in the Eclipse project move the resource in Guvnor? In the SCM? Both? Neither?

     

    2.7 If project folders (and projects themselves) in Eclipse are to be governed, then:

    (Same questions about delete, rename, move as above for resources)

     

    2.8 If the user tries to add a resource to a governed folder, but Guvnor does not have a model for that resource type, what happens?

     

    2.9 If the SCM has resources in a folder that is also governed and these resources does not have a model in Guvnor, what happens?

     

     

    2.10 Common SCM mechanisms for managing resources include:

    • Versions

    • Tags (names applied to historical versions)

    • Branches (partition of versions based on common ancestor, so each set can independently vary)

     

    Will Guvnor have (at a minimum) versions, tags and branches?

     

    I suspect the answers are yes, no, no? If we have all three in Guvnor, then it starts to look like an SCM.

     

    If Guvnor does not support tagging and branches, then how does it react when faced with SCM operations in this area?

    The user tags a version of a resource in the SCM. The user naturally would expect the same from Guvnor. If Guvnor does not have tags, then if the user switches to a tagged version from SCM, Guvnor will incorrectly see that as a resource content change. If Guvnor has a notion of tags, then what happens when the tags are moved in the SCM, but not through Eclipse? (That is, the Guvnor tags and the SCM tags are unsynchronized.)

    The user branches code in the SCM, and hence now has two versions of a predecessor resource that can independently vary, but Guvnor does not have the same? (Even if Guvnor did, see previous question about tags being unsynchronized: the same would apply for branches).

     

    2.11 How will Guvnor react to SCM specific operations? Given that there are a number of SCM specific capabilities (such as atomic commits in Subversion and multiple views in Clear Case), how can Guvnor remain consistent in such environments? (Note that we are not talking simply about 'nice to have' features here, but rather SCM operations that will render the relationship between Guvnor, Eclipse, and the SCM inconsistent, causing user confusions and errors.)

     

    Aside from the technical questions above, the key issue that must be addressed is the user experience. Many, if not all, of the technical issues expressed above can be 'solved' by some arbitrary decision. These decisions will not be obvious to (all/many/most) users and, taken together, will not form a consistent users model.

     

    2.12 How do we expect users to understand and use Guvnor?

     

    In my view, the problems described above are self-inflicted. Guvnor is sort of an SCM. 'Sort of' solutions do not result in consistent user models, users become confused, and all the unhappy consequences of having confused users appear (adoption of alternative choices, increased tech support/forum activity, bad publicity, etc.).