diff --git a/li.strolch.rest/src/main/java/li/strolch/rest/endpoint/ModelQuery.java b/li.strolch.rest/src/main/java/li/strolch/rest/endpoint/ModelQuery.java index dbd6cd1b8..04bc33e46 100644 --- a/li.strolch.rest/src/main/java/li/strolch/rest/endpoint/ModelQuery.java +++ b/li.strolch.rest/src/main/java/li/strolch/rest/endpoint/ModelQuery.java @@ -93,8 +93,6 @@ public class ModelQuery { resources.addAll(tx.doQuery(query)); } } - - tx.doNothingOnClose(); } // do ordering @@ -151,8 +149,6 @@ public class ModelQuery { orders.addAll(tx.doQuery(query)); } } - - tx.doNothingOnClose(); } // do ordering @@ -210,8 +206,6 @@ public class ModelQuery { activities.addAll(tx.doQuery(query)); } } - - tx.doNothingOnClose(); } // do ordering diff --git a/li.strolch.website/www.strolch.li/documentation.html b/li.strolch.website/www.strolch.li/documentation.html index 0705be8dc..ea06900c5 100644 --- a/li.strolch.website/www.strolch.li/documentation.html +++ b/li.strolch.website/www.strolch.li/documentation.html @@ -62,9 +62,9 @@
  • Strolch Components
  • Strolch Services and Commands
  • Strolch Queries
  • - + + + + + + + + + + +
    + + + +
    + +

    Policies are an integral part when writing business logic in Strolch. In many cases it would suffice to write + all such logic in Services and Commands, but as soon as behaviour can change, + depending on the element being accessed, then this would quickly lead to many if/else blocks.

    + +

    Since writing large if/else blocks is not maintanable in the long run, Strolch offers a different approach. + All Strolch elements can store Policy definitions. This is a simple key/value store where the key defines + the type of policy, and the value references the policy to use.

    + +

    Currently there are two ways to reference a policy in Strolch, either via a key which defines a further + lookup in the PolicyHandler, or directly as the name of the class to instantiate.

    + +

    Using policies in Strolch gives the additional possibility of easily changing the behaviour at runtime, as a + Service and/or Command would delegate the behaviour to the currently configured policy on the releveant + element.

    + +

    Policies are implemented by defining an abstract class and extends StrolchPolicy. This abstract + class then defines the API of the actual policy. A concrete class then extends this abstract class and + implements the concrete methods.

    + +

    Policies are registered on Resources, Orders, Activities and Actions. The following shows defining two + policies on a Resource, a PlanningPolicy, an ExecutionPolicy in XML:

    +
    +<Resource ...>
    +  ...
    +  <Policies>
    +    <Policy Type="PlanningPolicy" Value="key:SimplePlanning" />
    +    <Policy Type="ExecutionPolicy" Value="java:li.strolch.policytest.TestSimulatedExecutionPolicy" />
    +  </Policies>
    +</Resource>
    + +

    Note how the PlanningPolicy has a value of key:SimplePlanning and the ExecutionPolicy + defines a reference to an actual class.

    + +
    +

    To use the PolicyHandler, it must be configured in the StrolchConfiguration.xml as follows:

    +
    +<Component>
    +  <name>PolicyHandler</name>
    +  <api>li.strolch.policy.PolicyHandler</api>
    +  <impl>li.strolch.policy.DefaultPolicyHandler</impl>
    +  <Properties>
    +    <readPolicyFile>true</readPolicyFile>
    +    <policyConfigFile>StrolchPolicies.xml</policyConfigFile>
    +  </Properties>
    +</Component>
    + +
    +

    And this policy handler implementation requires a file where the lookups for the policies is defined, + e.g.:

    +
    +<StrolchPolicies>
    +
    +  <PolicyType Type="PlanningPolicy" Api="li.strolch.policytest.TestPlanningPolicy">
    +    <Policy Key="SimplePlanning" Class="li.strolch.policytest.TestSimplePlanningPolicy" />
    +  </PolicyType>
    +
    +  <PolicyType Type="ConfirmationPolicy" Api="li.strolch.policytest.TestConfirmationPolicy">
    +    <Policy Key="NoConfirmation" Class="li.strolch.policytest.TestNoConfirmationPolicy" />
    +  </PolicyType>
    +
    +</StrolchPolicies>
    + +
    +

    Now at runtime we can access the policies:

    +
    +PolicyHandler policyHandler = getComponent(PolicyHandler.class);
    +
    +try (StrolchTransaction tx = openTx()) {
    +
    +  Resource res = tx.getResourceBy("TestType", "MyTestResource");
    +  PolicyDefs policyDefs = res.getPolicyDefs();
    +
    +  PolicyDef planningPolicyDef = policyDefs.getPolicyDef("PlanningPolicy");
    +  PlanningPolicy planningPolicy = policyHandler.getPolicy(planningPolicyDef, tx);
    +  planningPolicy.plan(...);
    +
    +  PolicyDef executionPolicyDef = res.getPolicyDefs().getPolicyDef("ExecutionPolicy");
    +  ExecutionPolicy executionPolicy = policyHandler.getPolicy(executionPolicyDef, tx);
    +  executionPolicy.execute(...);
    +}
    + + + + +
    + + + + +
    + + + + + + + + + + + + + + diff --git a/li.strolch.website/www.strolch.li/documentation_transactions.html b/li.strolch.website/www.strolch.li/documentation_transactions.html index 13706481c..8ccb6ff17 100644 --- a/li.strolch.website/www.strolch.li/documentation_transactions.html +++ b/li.strolch.website/www.strolch.li/documentation_transactions.html @@ -50,7 +50,58 @@
    -

    Strolch Transactions

    + +

    Strolch Transactions play a central role in a Strolch agent. A transaction is opened for a realm, and grants + access to the model of the agent. Transactions are implemented as a Java try-with-resources by + implementing + the AutoCloseable interface. This makes it trivial to understand the scope of a transaction. +

    + +

    Transactions handle the following:

    + + +

    When a transaction is opened, it is by default read-only, i.e. does not perform any commands when it is + closed. Should the TX perform commands, then it is important to call tx.commitOnClose(), but + only at the end + of the work, so that exception handling can properly work if something goes wrong.

    + +

    StrolchTransaction offers a myriad of methods:

    + + +

    Transactions are opened by accessing the realm, but there are convenience methods depending on the + use-case:

    + + +

    Important is to always open the transaction as a try-with-resource block and to define if the TX should + commit, or not:

    +
    +try (StrolchTransaction tx = openTx(...)) {
    +
    +  // do work
    +
    +  // either or:
    +  tx.doNothingOnClose(); // can also be omitted, as default
    +  tx.commitOnClose();
    +}
    +
    + diff --git a/li.strolch.website/www.strolch.li/images/Strolch-Squirrel-View.svg b/li.strolch.website/www.strolch.li/images/Strolch-Squirrel-View.svg index 1250d2a9e..b8bbc2120 100644 --- a/li.strolch.website/www.strolch.li/images/Strolch-Squirrel-View.svg +++ b/li.strolch.website/www.strolch.li/images/Strolch-Squirrel-View.svg @@ -1,2 +1,2 @@ -
    Strolch Agent
    Strolch Agent
    Services
    Services
    Commands
    Commands
    REST Endpoints
    REST Endpoints
    DAOs
    DAOs
    ResourceMap
    ResourceMap
    ActivityMap
    ActivityMap
    OrderMap
    OrderMap
    Realm n
    Realm n
    Component X
    Component X
    Component Y
    Component Y
    Component Z
    Component Z
    Queries
    Queries
    Privileges
    Privileges
    Transactions
    Transactions
    Observers
    Observers
    Versioning
    Versioning
    Policies
    Policies
    \ No newline at end of file +
    Strolch Agent
    Strolch Agent
    Services
    Services
    Commands
    Commands
    REST Endpoints
    REST Endpoints
    DAOs
    DAOs
    ResourceMap
    ResourceMap
    ActivityMap
    ActivityMap
    OrderMap
    OrderMap
    Realm n
    Realm n
    Component X
    Component X
    Component Y
    Component Y
    Component Z
    Component Z
    Queries
    Queries
    Privileges
    Privileges
    Transactions
    Transactions
    Observers
    Observers
    Versioning
    Versioning
    Policies
    Policies
    Audits
    Audits
    \ No newline at end of file