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).
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.
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)
Business analyst: Edits and manages business rules, reviews process definitions. (Guvnor BRMS).
Developers: use IDE to integrate with guvnor repository for shared/reusable artifacts.
(obviously within the above groups there is much finer detail in practice).
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.
AtomPub defines a simple interface over HTTP to publish and subscribe to artifacts (files) and collections of artifacts (services/packages).
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).
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).
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
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...