Strolch Realms are also responsible for opening Transactions, as these are bound to the persistence layer
configured for this realm. At runtime, a realm is then accessed from the ComponentContainer:
-
+
ComponentContainer container = getAgent().getContainer();
StrolchRealm realm = container.getRealm(StrolchConstants.DEFAULT_REALM);
try(StrolchTransaction tx = realm.openTx()) {
@@ -244,7 +244,7 @@ try(StrolchTransaction tx = realm.openTx()) {
lock the relevant Strolch elements before execution.
A typical Service and Command implementation would look as follows:
-
+
public class SetParameterService extends AbstractService<SetParameterArg, ServiceResult> {
public static final long serialVersionUID = 1L;
@@ -304,7 +304,7 @@ public class SetParameterService extends AbstractService<SetParameterArg, Ser
}
-
+
public class SetParameterCommand extends Command {
// input fields
@@ -440,16 +440,6 @@ public class SetParameterCommand extends Command {
To quickly get started developing Strolch, this projects provides scripts to checkout all the
- relevant projects and implements a Maven module so that building this projects builds all Strolch
- projects.
This bill of material is a Maven project which, when imported in one's own Strolch project, pulls in
@@ -480,6 +470,14 @@ public class SetParameterCommand extends Command {
A tutorial application which showcases how to setup Strolch as a standalone Java Webapp which can be
deployed to a servlet container e.g. Apache Tomcat 8.
A minimal project to get started using REST with Strolch.
+
Development
diff --git a/li.strolch.website/www.strolch.li/blog.html b/li.strolch.website/www.strolch.li/blog.html
index a0c1c4b84..f681f1f54 100644
--- a/li.strolch.website/www.strolch.li/blog.html
+++ b/li.strolch.website/www.strolch.li/blog.html
@@ -184,24 +184,22 @@
Resource objects representing machines, human resources, etc., and
Activity/Action hierarchies defining a workflow.
-
With the latest couple of commits to Strolch we have now added Activities and a basic
- planning of Actions onto Resources. Activities have an
- ordered list of IActivityElement which allows creating an arbitrary deep tree structure
- of Activity and Action elements.
+
With the latest couple of commits to Strolch we have now added Activities and a basic planning of
+ Actions onto Resources. Activities have an ordered list of IActivityElement which
+ allows creating an arbitrary deep tree structure of Activity and Action elements.
-
Action objects have a list of IValueChange objects which define the start,
- end and further value changes over time on a referenced Resource. Thus planning an
- Activity is done by iterating the Activity hierarchy and for every Action
- selecting a relevant Resource and then then applying the changes of the
- Action on to the referenced TimeState on the Resource.
+
Action objects have a list of IValueChange objects which define the start, end and
+ further value changes over time on a referenced Resource. Thus planning an Activity is done by
+ iterating the Activity hierarchy and for every Action selecting a relevant Resource and then then
+ applying the changes of the Action on to the referenced TimeState on the Resource.
-
This implementation is currently very simple as it ignores all constraints which a
- Resource might have. In further development we shall implement a Violation
- model so that UIs can be built to visualize the over-use of Resources.
+
This implementation is currently very simple as it ignores all constraints which a Resource might
+ have. In further development we shall implement a Violation model so that UIs can be
+ built to visualize the over-use of Resources.
In even further steps we would then start implementing algorithms to not just apply the changes onto
- a Resource, but to actually search the Resource for time slots when the
- value changes would not violate any constraints applied to the resource.
+ a Resource, but to actually search the Resource for time slots when the value changes would not
+ violate any constraints applied to the resource.
We are very much looking forward to these new features. Stay tuned for your updates - even though
they do take their time to arrive =).
This page describes how to setup the development environment.
-
+
+
Development
+
This page describes how to setup the development environment.
+
-
-
Prerequisites
- To start developing Strolch you need an installed:
-
-
Java JDK 8
-
Apache Maven 3
-
+
+
Prerequisites
+ To start developing Strolch you need an installed:
+
+
Java JDK 8
+
Apache Maven 3
+
-
Getting Started
-
Setting up Strolch is just a few lines:
-
+
Getting Started
+
Setting up Strolch is just a few lines:
+
git clone https://github.com/eitchnet/strolch.git
cd strolch
mvn clean install -DskipTests
-
Note: If you want to run the tests, then either install a PostgreSQL DB and configure the users as is required by the project, or remove the project from the li.strolch.dev module build, otherwise the build will fail =))
+
Note: To run the tests you will need to configure the PostgreSQL Databases. See the README in the
+ module.
-
After running the Maven build, you will have a full build of all Strolch projects. Now you can start modifying the projects, and add your own features, or, far more interesting, start developing your projects using the Strolch agent.
+
After running the Maven build, you will have a full build of all Strolch projects. Now you can start
+ modifying the projects, and add your own features, or, far more interesting, start developing your projects
+ using the Strolch agent.
-
Strolch Project Configuration
-
To use Strolch in your own projects, look at the two tutorial apps on how they are configured. You can also simply copy the projects, modify the Maven POMs and remove what ever you do not need.
+
Strolch Project Configuration
+
To use Strolch in your own projects, look at the two tutorial apps on how they are configured. You can also
+ simply copy the projects, modify the Maven POMs and remove what ever you do not need.
-
The following sections describe the Strolch configuration files and folder structure.
+
The following sections describe the Strolch configuration files and folder structure.
A Strolch agent can be easily extended with arbitrary components. An agent is basically a container for
classes extending StrolchComponent. Theses classes mostly implement an interface which
- describes the
- operations that are supported by the component.
+ describes the operations that are supported by the component.
The following represents a list of the most used components:
@@ -80,8 +79,8 @@
these threads and also allows the component to be started again. The destroy step destroys the instance and
makes it unusable anymore, i.e. shutdown of the agent.
-
Each component has its own configuration parameters. A component is registered in the
- StrolchConfiguration.xml file with a
+
Each component has its own configuration parameters. A component is registered in the StrolchConfiguration.xml
+ file with a
As is custom for every framework, querying the model must be possible. Strolch queries are implemented using
the StrolchQuery interface and one of its concrete implementations: ResourceQuery,
- OrderQuery,
- ActivityQuery.
+ OrderQuery, ActivityQuery.
A Strolch element always has two identifiers: Type and Id. The type is important as
- it classifies an element.
- So if a car and a house would be modelled in Strolch, then those would both be a Resource, but
- one of type
- Car and the other of type House. Both would have different parameters.
+ it classifies an element. So if a car and a house would be modelled in Strolch, then those would both be a
+ Resource, but one of type Car and the other of type House. Both would
+ have different parameters.
Thus one of the inputs for every query is it's type, which is defined as the navigation. It is said that we
navigate to the Cars, or Houses. Thus when instantiating a ResourceQuery, pass the navigation to the type of
Resource as well. Same applies for Orders and Activities.
Further input for a StrolchQuery are the selections. These selections get translated into RDBMS
- WHERE
- clauses. Selections support boolean operations thus allowing for complex querying.
+ WHERE clauses. Selections support boolean operations thus allowing for complex querying.
StrolchQueries also support Ordering and object transformation. Following classes provide the most used
scenarios:
Realms implement multi-tenant capabilities. A Strolch agent can have an arbitrary number of realms
- configured and each realm has its own persistence configuration, allowing to separate mandates
- completely.
+
Realms implement multi-tenant capabilities. A Strolch agent can have an arbitrary number of realms configured
+ and each realm has its own persistence configuration, allowing to separate mandates completely.
A realm can run in one of the following modes:
-
EMPTY
- This is a transient data store mode, where no model changes are persisted - they are only kept in
- memory. When the Strolch agent is started, this realm is empty as no data is loaded.
+
EMPTY This is a transient data store mode, where no model changes are persisted - they are only
+ kept in memory. When the Strolch agent is started, this realm is empty as no data is loaded.
-
TRANSIENT
- This is the same as EMPTY, but with the difference that when the Strolch agent is started, a model file
- is parsed and the in-memory realm is populated with the elements parsed from the model file.
+
TRANSIENT This is the same as EMPTY, but with the difference that when the Strolch agent is
+ started, a model file is parsed and the in-memory realm is populated with the elements parsed from the
+ model file.
-
CACHED
- In this mode, all data is stored in-memory, and any changes made are written back to the persistence
- layer. This allows for fast in-memory qeuries, but makes sure no data is lost when the agent is
- restarted.
+
CACHED In this mode, all data is stored in-memory, and any changes made are written back to the
+ persistence layer. This allows for fast in-memory qeuries, but makes sure no data is lost when the agent
+ is restarted.
-
TRANSACTIONAL
- In this mode no data is kept in-memory and every query, and element retrieval is passed to the
- persistence layer to be retrieved from the underlying database. This is similar to typical Java
- applications where JPA is used.
+
TRANSACTIONAL In this mode no data is kept in-memory and every query, and element retrieval is
+ passed to the persistence layer to be retrieved from the underlying database. This is similar to typical
+ Java applications where JPA is used.
Realms are mostly hidden from a developer as a StrolchTransaction exposes all important
- operations needed to
- access Strolch objects. A developer will however need to configure the realms for their specific project. If
- the project only requires one realm, then the defaultRealm can be used, where the developer
- only is
- required to configure the mode and any relevant model file.
+ operations needed to access Strolch objects. A developer will however need to configure the realms for their
+ specific project. If the project only requires one realm, then the defaultRealm can be used,
+ where the developer only is required to configure the mode and any relevant model file.
If the mode is CACHED or TRANSACTIONAL, then the PersistenceHandler component is required to be
- configured,
- so that the DAOs know how to access the underlying database.
+ configured, so that the DAOs know how to access the underlying database.
The configuration in the StrolchConfiguration.xml file is as follows:
@@ -112,10 +105,8 @@
A multi-realm configuration would be as follows. Note how the defaultRealm is still enabled, and
- has its
- configuration as before. Further the PostgreSQL PersistenceHandler is configured to show how
- the realms are
- connected to the persistence handler:
+ has its configuration as before. Further the PostgreSQL PersistenceHandler is configured to
+ show how the realms are connected to the persistence handler:
Accessing a realm is done in multiple ways. Important is to note, that a user should use the
- StrolchTransaction object, instead of accessing the Realm directly.
+
Accessing a realm is done in multiple ways. Important is to note, that a user should use the StrolchTransaction
+ object, instead of accessing the Realm directly.
Opening a transaction is done from a Service by calling one of the openTx()-methods.
Nevertheless, the realm can be accessed as follows:
Services are written to implement a specific use-case. Commands are written to
implemente re-usable parts of a use-case. The use-case can be abstract e.g. AddResourceService
- or very specific e.g.
- CreatePatientService.
+ or very specific e.g. CreatePatientService.
Should the use-case be re-usable in different scenarios, then commands should implement the logic, and the
- services should then execute the commands. E.g. The CreatePatientService would use a
- CreatePatientResourceCommand and then use an AddResourceCommand in a single
- transaction, so that the task of
- creating the actual Patient Resource can be re-used somewhere else.
+ services should then execute the commands. E.g. The CreatePatientService would use a CreatePatientResourceCommand
+ and then use an AddResourceCommand in a single transaction, so that the task of creating the
+ actual Patient Resource can be re-used somewhere else.
-
Services extend the abstract class AbstractService and then implement the method
- internalDoService(ServiceArgument). AbstractService defines generic template arguments with
- which the
- concrete service can define a specific input ServiceArgument class and output ServiceResult class.
+
Services extend the abstract class AbstractService and then implement the method internalDoService(ServiceArgument).
+ AbstractService defines generic template arguments with which the concrete service can define a specific
+ input ServiceArgument class and output ServiceResult class.
The AbstractService class has multiple helper methods:
@@ -77,8 +74,7 @@
Commands extend the Command class and then implement the method doCommand().
- Commands have helper
- methods:
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.
+ implementing the AutoCloseable interface. This makes it trivial to understand the scope of a
+ transaction.
Transactions handle the following:
@@ -69,8 +69,7 @@
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.
+ only at the end of the work, so that exception handling can properly work if something goes wrong.
The following downloads are releases of Strolch, but remember that it is always
- possible (and fairly easily)
- to re-build the artifacts on your own by following the easy steps on the development
- page
+ possible (and fairly easily) to re-build the artifacts on your own by following the easy steps on the development page
0VV2&5+qd(d>LN~%2Wvre2&p7W2f618`@~Jqwgr=&REq)nzp0wDm$Em_m&@oRJ%Okc)usd(G==L7eIsz;>wv>
zAVl#AX&jvm_D_xuQ{o`6BLm~u`SYLqkc)j43o7c4w5Wu{csh_tq*N@*0yA75ArvcM
zr=&a9zbTv1W+&kTIiVA>IHPWVa;z}Qe#lZA-d9D=D38%eK=!VBG4q+90In7>1`Et+lH*wU&WZ+)>+|
z(Qe1U`mVaG?T&YwMpqvhSnGg%l#VtYjrC4WJRdFcPT(T>d~~Ny;69IZ&K>*ypFYM!
zO_h7qAn|KTOG`>CxDN*TF=IR)X}cO8x5wkwxU1>yuA(+OSkV*{gtDWJcUmp1wUp8B
zjTN4ke*<5t-&HGNA`nF0f}VtllT7g
zsKi`ArXiBkLIlmz7Wi!^PQj^Li~uT$YH$@OesOjNwhjNew~=FpM1&Y{B5lSJ8mM*~
z_x-`wb^k*?o}3CH_l&4`t&|I^z!%W}FG)q6cnQpcvE%uq>)sZ*ULsE#OBp&S*8skh
f;iyOQUKlONUV0f>g(_6xI}HB;i8L^&0QLX?evWws
diff --git a/li.strolch.website/www.strolch.li/index.html b/li.strolch.website/www.strolch.li/index.html
index 97b1e109a..34b250b56 100644
--- a/li.strolch.website/www.strolch.li/index.html
+++ b/li.strolch.website/www.strolch.li/index.html
@@ -62,9 +62,9 @@
used to implement applications with multiple users/customers for instance in SaaS environments.
The parameterized data model consists of three top level objects, Resources, Orders and Activities. These
- objects can have any number of ParameterBags which in turn can have any number of Parameters on them.
- This allows for a very dynamic modelling of data structures including modification at run time. Multiple
- ready to use Parameter types are already implemented which handle the primitive types in Java including
+ objects can have any number of ParameterBags which in turn can have any number of Parameters on them. This
+ allows for a very dynamic modelling of data structures including modification at run time. Multiple ready to
+ use Parameter types are already implemented which handle the primitive types in Java including
ListParameters for collections of these primitive types.
One of the main features of the Strolch agent, is that persistence is handled transparently and the user must
@@ -137,20 +137,32 @@
Strolch strives to use as few external dependencies as possible, so that the Strolch runtime is not bloated
unnecessarily. The following list of Strolch dependencies is a summary and was created using mvn
- dependency:tree on the li.strolch.dev project on the 2014-09-18.
+ dependency:tree on the strolch_minimal project on the 2016-09-16.
Implements the PostgreSQL Persistence layer used by li.strolch.persistence.postgresql
+
com.zaxxer:HikariCP:jar:2.3.6:compile
+
Implements connection pooling for JDBC access
+
+
com.google.code.gson:gson:jar:2.3.1:compile
+
Used to transform to JSON
+
+
javax.activation:activation:jar:1.1:compile
+
Used when sending e-mails
+
javax.mail:mail:jar:1.5.0-b01:compile
+
Used when sending e-mails
+
log4j:log4j:jar:1.2.17:runtime
-
Logging facilities Implementation
+
Used for logging
+
org.slf4j:slf4j-api:jar:1.7.2:compile
+
Used for logging
+
org.slf4j:slf4j-log4j12:jar:1.7.2:runtime
+
Used for logging
@@ -159,7 +171,7 @@
If you want to access Strolch using the RESTful API, then we got you covered - but sadly RESTful service
development requires quite a few extra dependencies: