Version 44

    Guvnor is the repository and management tools for the SOA repository - where you store assets/interface contracts, and a web interface to manage it all (including rules, processes, services).


    Guvnor mission:


    To provide versioned service registry (storage) for all service artifacts. Make these artifacts available in a controlled and searchable fashion via user interfaces, web APIs, developer desktops and to runtime systems. Guvnor assists in governance for SOA and WOA systems, providing a single point of truth for shared artifacts. Guvnor also has a web based interface which provides a single entry point for management and administration and analysis into the underlying systems.




    - More info on AtomPub integration, Jervis' soa-repository design proposal, Guvnor repository schema discussion, Guvnor Dependency Management, wish list from the Savara Project, JBoss internal discussions (I will try to summarize and publish this soon).

    Who would use this

    • System administrator: interacts with JON/command line for deployment and systems monitoring. JON plugins for management of runtimes (Drools, jBPM, service deployments etc)

    • Service architect: defines interfaces and services, sets policies. (Guvnor SOA flavour)

    • Business analyst: Edits and manages business rules, reviews process definitions. (Guvnor BRMS flavour).

    • Developers: use IDE to integrate with guvnor repository for shared/reusable artifacts.

    (obviously within the above groups there is much finer detail in practice).

    • Service runtimes themselves ! (via AtomPub) any service runtime that requires storage of configuration, meta data, routing data etc.




    Guvnor can act as a filesystem (via webdav), or as a runtime repository (via AtomPub - eventually UDDI). Ideally all SOA or WOA artifact can be stored, even non executable items such as design documentation.


    Web interface



    WebDAV interface



    WebDAV can be use from OSes directly, and productivity applications.



    AtomPub interface

  defines a simple interface over HTTP to publish and subscribe to artifacts (files) and collections of artifacts (services/packages).


    AtomPub interface serves following purposes:


    1: provide "feeds" for people/systems to monitor for changes: For example, user subscribes to a feed which lists contents of package or user subscribes to feed which lists changed contents in a package

    2. provide the default remote api to push/pull content and meta data from the repository. All other things, ESB, messaging, that will store config in the repository will access it via atom pub programmatically.


    Atom feed/entry schema:


    A typical Atom entry may look like below:

    <entry xmlns="" xml:base="http://localhost:9080/repository/packages/testPackage1/assetes/testRules">
      <title type="text">testRule1</title>
      <summary type="text">desc of testRule1</summary>


      <link href="http://localhost:9080/repository/packages/testPackage1/assets/testRule1"/>


      <metadata xmlns="http://overlord/drools/1.0">
        <property name="archived" value="true" />
        <property name="rule-format" value="dsl" />
      <content type="text">this is the actual content of testRule1</content>




    1. The <metadata> element is an Atom extension element. We will have pre-defined schemas for each type of artifacts that are supported by Guvnor, for example, a xsd for Drools rules, a xsd for JBoss ESB etc. However the <metadata> schema must be extensible/customizable, so that users can extend or customize the schema to suit their own needs. The <metadata> serves as tags that users can apply to their artifacts, it also helps for indexing, querying etc.  Front end GUIs can also be driven based on this meta data XSDs.


    2. The <content > element is used to return the content of the artifacts. Its content can be the actual content in a text format (or in html/xml format) , or can be a link to the actual content (when its a binary or its better to be managed separately, for example, we may want to use a separate URL to manage rules as media types). E.g.:


    <content type="application/xml" src="/repository/packages/testPackage1/assets/testRule1"/>


    3. If we decide life cycle is an attribute common enough to all artifacts, then we can add a <lifecycle> extension element, see below:


    <entry xmlns="" xml:base="http://localhost:9080/repository/packages/testPackage1/assetes/testRules">


      <metadata xmlns="http://overlord/drools/1.0">



      <content type="text">this is the actual content of testRule1</content>


    CRUD through AtomPub interface:

    Details can be found on


    Versions and History:

    Using an URL like "http://localhost:9080/repository/packages/testPackage1/history" or a query like URL "http://localhost:9080/repository/packages/testPackage1?history=all"?



    TBD: use OpenSearch?


    Support the access of "snapshot" packages:



    IDE/developer interface

    The IDE plug in allows developers to push/pull content from the Guvnor repository. Artifacts can live both in guvnor and the developer SCM.



    Notification engine

    As many artifacts require human review/authoring/approval, a notification engine can provide notice of changes to artifacts (perhaps requiring approval) via email, Atomfeeds etc... (pro-active monitoring of changes for humans).



    As both artifacts (files) and services (packages - collections of artifacts) can have lifecycle tags attached to indicate what status they are in. Individually each artifact can have a lifecycle of its own, but more importantly packages of artifacts (which define a service - a service can rarely be defined as one artifact) can use the snapshot facility to allow a deployment lifecycle (test, deploy etc).

    Lifecycle needs to be extensible and customizable.




    Service repository

    Backing guvnor is a JCR repository storing packages (services) as collections of artifacts.

    Artifacts can be shared between service definitions (packages) via references (which can be specified to a particular version, or the latest version of an asset). Proposed storage schema.


    Snapshots for deployment

    To isolate runtime systems which may depend on specific versions of artifacts from inadvertant changes, a snapshot system allows services (packages) to be versioned at will (collections of artifacts can be versioned as one unit).



    Rich full text and meta data searching will be provided to allow people to quickly find and re-use artifacts (this will be enhanced in future thanks to JBoss DNA).



    • Relationship to BRMS: BRMS is essentially a subset of Guvnor, adding widgets and builders for rule specific artifacts. (they will both be built on the same technology). Guvnor came out of BRMS initially (as you can see from the pictures above).

    • Relationship to JBoss DNA: DNA will form the underlying repository (eventually) and provide deep searching of artifacts and relationships (via its "sequencing" capabilities).

    • Relationship to ESB: ESB services can use guvnor repository (via AtomPub API) to store and retrieve artifacts for centralised view and control (a "registry").

    • Relationship to JBoss ON: JBoss ON (RHQ) will provide the runtime service monitoring and deployment of artifactrs such as rules, via its agent plug in system. Its webconsole will also be re-used for graphical views into these runtime systems and services.

    • Ajax UI: a re-usable ajax shell (using GWT) will be used/provided (same as drools BRMS and jbpm console).



    • JBoss DNA integration

    • UDDI interface

    • Business and Service Activity Monitoring views (BAM & SAM)

    • Policy management and enforcing

    • Artifact dependencies, including transitive dependencies.



    discuss dependencies - Can a package include another package? (and in which case is it transitive). Or should assets have list of dependent assets? In which case if they are shared, are they transitive? Being in a package is almost an implicit declaration of dependencies (but not always - eg rules on model, but NOT other rules necessarily). Discuss...












    Use case design: