Version 26

    Terminology:

     

    Workspace:

     

    Workspace is nothing more than visual space, it just contained 0...n modules, but in itself the workspace is not versioned, it's not an asset. It's just saying, open these modules and put them in my workspace. I might then rightflick a module and select to deploy it. Or if I want to hide the other modules, which aren't relelvant now, I can "go into" a module which makes it the root of the tree folder - but that's an extra feature, and only if a users request it. Just think of the workspace as doing nothing other than grouping together some modules that I may want to work on. Those modules could be complete separate from each other. I can select each module individual and tell it to deploy. If I want to open a module, it has to open in a worksace, i.e. the module is added to the workspace. I can add it to an existing workspace or tell it to open in a new workspace. but it's nothing more than a placeholder, the workspace has no meaning with regards to deployment, knowledge bases etc. It's just a way to group things, nothing more, nothing less, sorta like windows desktope. It's just a convenience place to hold things that I want to work with

     

    With regards to dependencies, I add a module to my workspace, I can expand it and it'll show it's child modules, and I can navigate into those too. I may chose to add a child module to the workspace too. So that means I can navigate to a module via two ways, navigating to it via the parent, or just add it to the workspace and open it there. but it's still the same module and the workspace adds no extra meaning or behaviour to it. So it's really more like a bookmark. a workspace is just me book marking modules that are relevant to give easy navigation to them.

     

    BTW, one reason why we need to be able to depend on individual assets is one feature tha ilog does, which is needed for large systems. You can make a query, that pulls rules into a deployable module. So you can say find me all the rules that are blah and deploy them. So for that to work for us. the selection process would list all the rules. I would then create a new module that would just have a list of references to the items that were selected. ilog call it "rule select". you can write a query that selects the rules to deploy, so for us it would just be making sure all resultset was added to a module, as symlinks. As you can query on the rule content itself, get me all the rulesthat have Person( age > 60 ), and any rule that cotrains on that, is included. It doesn't need to be a symlink, I just mean it's some sort of pointer or something, but it's a way of saying I'm deploying this module and this module contains a drl file that exists in another module.

     

    Questions regarding workspace:

    1. Can a workspace add a module that was originally created under another workspace? I guess the answer is yes.

    2. Should each workspace have its own GlobalArea? or should workspaces share a same GlobalArea? I guess probably each workspace wants its own GlobalArea. To do this, we will have to invent a name schema for GlobalAreas so that their name do not conflict with each other (module nodes are all located under the ASSETS_AREA node no matter which workspace it belongs to). Maybe sth like globalarea-workspace1. We also need an extra attribute on the globalarea-workspace1 node called displayName so that globalarea-workspace1 node can still be displayed as GlobalArea in the GUI.

    3. Maybe for the initial verion, we just say there is only one GlobalArea across all workspaces. We can always refactor this later once we have more concrete feedbacks.

     

    https://issues.jboss.org/browse/GUVNOR-1166

     

     

    Module: 

     

    Module is a root concept has a hierarchical Folder structure (well, this may not be ture. We may not want to create any folders under the module node due to performance concerns). Module has a runtime type, esb, ws, drools, bpel etc. That type associates a builder with it. It says how do I take this module and all it's dependencies and build a jar or a war or what ever is the resulting deployable artifact.

     

    The depdency mechanism behaviour is dependant on the module type. In Drools it just combines everything at build time and can be used to describe sets of knowledge either via inheritence or composition or both. Other's may have a different dependnecy type.

     

     

    Module Builder: 

     

    Module builder is a plugable mechanism that knows how to build a module for a specific domain (Drools/Jboss ESB etc). The builder knows how to validate, how combine and assembly assets, how to generate the deployment unit (jar/war etc) for the target domain.

     

    Asset:

     

    Asset is atomic, an atomic asset is a low level rule, xsd etc. Asset can not depend on other assets. Module can contain assets. Module can depend on assets.

     

    Package:


    Package would no longer exist in Guvnor. Package is replaced by Module.

     

    Global Area:

     

    Global area is a collection of useful assets I might want to use individually in my own module. A module, regardless of it's type, can include (reference) individual assets from that GlobalArea. From the module's point of view, there is no difference between depending on an asset that belongs to the module itself or depending on an asset that belongs to the Global Area. An asset can be promoted from module to Global area if it is decided that this asset can reused by other modules. It can also be depromoted from Global area to module.

     

    We have two choices when it comes to the concept of Global area and modules.

    1) create two concepts for containing assets. Global area is not a module. It is just a folder where all reusable assets are stored.

    2)  create one concept for containing assets, but additionally have  properties that defined the allowed behaviour of that container -  dependency, building. We can say Global area is a module. It's just a module that itself cannot be depended on, and it can not be built. An alternative way to describe this relationship is we can say there is a base Container class, Global area is the base type. The Module extends that. A Module as a minimum is a container of assets, we may then allow a module to part of a dependency chain and we may allow Module to be built resulting in a deployable artifact.

    Option 2) avoids introducing more than one concepts for "containing" assets. However this concept of "Global area = module" may cause confusions in some cases. For example, when Guvnor is used to govern web services, we say a module is a web service. If Global area is a module, then Global area is a web service. But Global area is not a web service. Anyway, this is sth for further discussions.

     

    Dependency:


    http://community.jboss.org/wiki/GuvnorDependencyManagement

    https://issues.jboss.org/browse/GUVNOR-1156

     

     

    Perspectives:

     

    1. Perspective for Author and Runtime

    2. Perspective for Drools and JBOSS-ESB?

     

    https://issues.jboss.org/browse/GUVNOR-1125

     

    Repository structure

     

    1. Drools:


    Display schema: this is how assets are organized and represented to users in the GUI. The actual storage structure in JCR might be different from this.

     

    WorkSpace1

          |--mortgages (mortgages is a module)

          |            |--Business rule assets

          |            |          |--Bankruptcy history

          |            |          |--Pricing loans

          |            |--Technical rule asset

          |            |--Functions

          |            |--DSL Configurations

          |            |--Model

          |            |          |--MortgageModel

          |            |--Processes

          |            |--Enumerations

          |            |--Test Scenarios

          |            |          |--Are they old enough

          |            |--XML, Properties

          |            |--Other assets, documentation

          |            |--WorkingSet    

          |

          |--Module2 (Module2 is a module)

          |

          |--GlobalArea

                       |--Business rule assets

                       |          |--mydrl2

                       |          |--mydecisiontable2

                       |--Technical rule asset

                       |--Functions

                       |--DSL Configurations

                       |-- Model

                       |           |--myjavamodule2

                       |--Processes

                       |--Enumerations

                       |--Test Scenarios

                       |           |--mytestscenario

                       |--XML, Properties

                       |--Other assets, documentation

                       |--WorkingSet  

     

     

    Couple of notes:

     

    1. We display only one workspace in the GUI. User switchs workspaces(similar to "Switch Workspace" in Eclipse) using the Perspective button.

     

    2. The type structure (Business rule assets/Technical rule asset/Functions...) is a named hierarchy under the module node as well as the GlobalArea node. The terminology can be arbitrary and it is user configurable. When Guvnor is used to govern ESB, ppl may perfer using the terminology of WSDL/XSD/Configuraiton etc. In some cases, ppl may prefer the terminology of hr/finance/engineering.

     

    3. The name "modue" is user configurable. When Guvnor is used to govern ESB, ppl may perfer using the terminology of "service". In some cases, ppl may prefer using the terminology of folder/container.

     

    4. We can probably provide some pre-configured hierarchy name conventions to suit different projects. For example, hierarchy name convention "Business rule assets/Technical rule asset/Functions" for Drools, and hierarchy name convention "WSDL/XSD/Configuraiton" for ESB.

     

    5. Shall we provide an option that there is no hierarchy under the module node?

     

    Corresponding JCR schema:

     

    ROOT

      |--REPOSITORY_AREA

         |-ASSETS_AREA

           |-- mortgages

           |        |        |---jcr:content:

           |        |              |-- title

           |        |              |-- desc

           |        |              |-- lastModified

           |        |              |-- checkInComment

           |        |              |-- content: empty

           |        |              |-- content_binary: mortgages.jar, this is generated by building mortgages module.

           |        |              |-- DefaultLifeCycle: created

           |        |              |-- dependency (multi-value-property)

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/BankruptcyHistory.drl

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/Pricingloans.xls

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/MortgageModel.jar

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/Aretheyoldenough

           |        |              |-- moduleType: drools

           |        |              |-- workspace: WorkSpace1

           |        |--BankruptcyHistory.drl

           |        |        |--jcr:content:

           |        |              |-- title

           |        |              |-- desc

           |        |              |-- lastModified

           |        |              |-- checkInComment

           |        |              |-- content:

           |        |              |-- content_binary:

           |        |              |-- DefaultLifeCycle: empty (assets do not have lifecyles,modules have)

           |        |              |-- dependency (multi-value-property): empty. atomic assets can not depends on atomic assets

           |        |              |-- displayFolder: drl

           |        |              |-- assetType: drl

           |        |--Pricingloans.xls

           |        |--MortgageModel.jar

           |        |--Aretheyoldenough

           |

           | -- module2

           |

           | -- GlobalArea

           |

        |--SCHEMA_AREA

           |--METADATA_TYPE_AREA
                            -metadata_type_string
                                   -jcr:content

                                        -- description

                            -metadata_type_multi_value_string                         
                            -metadata_type_life_cycle
                            -metadata_type_dependency
           |- -LIFECYCLE_AREA
                            -default_life_cycle
                                  -created
                                         -jcr:content

                                             -- isInitialPhase

                                             -- description

                                             -- nextPhase
                                   -developed
                                   -tested
                                   -production
                                   -retired

     

     

    Couple of notes:

     

    1. Workspace is not a physical structure in JCR. Its an attribute belongs to module node to indicate which workspace this module belongs to.

     

    2. The named hierarchy structure (Business rule assets/Technical rule asset/Functions...) is not a physical structure in JCR. This is because we dont want a deep hierarchy mainly due to performance and simplification reasons.  Every asset node has an attribute called displayFolder. This attribute is used to help GUI to display the asset under the corresponding hierarchy name.

     

    3. Every module has an attribute called moduleType. This attribute is used to associate module with a corresponding module builder.

     

    4. Every asset has an attribute called assetType. This attribute is used to associate asset with a plugin based asset hander. The asset handler knows how edit and display the asset in the GUI.

     

    BTW, below is the current repository schema used by Guvnor:

     

    rootnode-

              -RULES_REPOSITORY_NAME

                                        -RULE_PACKAGE_AREA

                                                                      -packageA

                                                                                     -ASSET_FOLDER_NAME

                                                                                                          -assetA

                                                                                                          -assetB

                                                                      -packageB

                                                                                     -ASSET_FOLDER_NAME

                                        -STATE_AREA

                                        -PACKAGE_SNAPSHOT_AREA

     

     

    2. ESB:

     

    Display schema:

     

    WorkSpace1

          |--travelService (travelService is a module)

          |            |--WSDL

          |            |          |--travelService.wsdl

          |            |--XSD

          |            |          |--travelService.xsd

          |            |--Configuration

          |            |          |--jboss-esb.xml

          |            |--Other assets, documentation

          |

          |--service2 (service2 is a module)

          |

          |--GlobalArea

          |            |--WSDL

          |            |          |--myService.wsdl

          |            |--XSD

          |            |          |--myService.xsd

          |            |--Configuration

          |            |--Other assets, documentation

     

     

    Corresponding JCR schema:

     

    -ROOT

      |--REPOSITORY_AREA

         |-ASSETS_AREA

           |-- travelService

           |        |        |---jcr:content:

           |        |              |-- title

           |        |              |-- desc

           |        |              |-- lastModified

           |        |              |-- checkInComment

           |        |              |-- content: empty

           |        |              |-- content_binary: travelService.esb .

           |        |              |-- DefaultLifeCycle: created

           |        |              |-- dependency (multi-value-property)

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/travelService.wsdl

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/travelService.xsd

           |        |                     --/ROOT/REPOSITORY_AREA/mortgages/jboss-esb.xml

           |        |              |-- moduleType: jboss-esb

           |        |              |-- workspace: WorkSpace1

           |        |--travelService.wsdl

           |        |        |--jcr:content:

           |        |              |-- title

           |        |              |-- desc

           |        |              |-- lastModified

           |        |              |-- checkInComment

           |        |              |-- content:

           |        |              |-- content_binary:

           |        |              |-- DefaultLifeCycle: empty (assets do not have lifecyles,modules have)

           |        |              |-- dependency (multi-value-property): empty

           |        |              |-- displayFolder: WSDL

           |        |              |-- assetType: WSDL

           |        |--travelService.xsd

           |        |--jboss-esb.xml

           |

           | -- myservice2

           |

           | -- GlobalArea