33 lines
21 KiB
XML
33 lines
21 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Strolch Overview on Strolch</title><link>https://strolch.li/</link><description>Recent content in Strolch Overview on Strolch</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="https://strolch.li/index.xml" rel="self" type="application/rss+xml"/><item><title>Architecture</title><link>https://strolch.li/documentation/architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/architecture/</guid><description>Architecture Birds View A Strolch agent&rsquo;s architecture can be seen as a simple three-tier architecture. The presentation layer is mostly a web frontend, where the communication with the agent is done via REST API calls.
|
|
The agent itself implements the business logic using Services, Commands, Queries etc.
|
|
The agent can communicate with other 3rd systems using any API, where it is preferred to use JSON over REST.
|
|
The agent can use a standard RDBMS as a storage system, where currently DAOs have been implemented only for PostgreSQL.</description></item><item><title>Configuration</title><link>https://strolch.li/tutorial/configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/tutorial/configuration/</guid><description>Configuration Let&rsquo;s start by creating a new Apache Maven project. We&rsquo;ll need a POM with the proper dependencies. We expect you to be familiar with Apache Maven, so we&rsquo;ll just show you a working POM file:
|
|
pom.xml
|
|
&lt;?xml version=&#34;1.0&#34;?&gt; &lt;project xmlns=&#34;http://maven.apache.org/POM/4.0.0&#34; xmlns:xsi=&#34;http://www.w3.org/2001/XMLSchema-instance&#34; xsi:schemaLocation=&#34;http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd&#34;&gt; &lt;modelVersion&gt;4.0.0&lt;/modelVersion&gt; &lt;groupId&gt;li.strolch&lt;/groupId&gt; &lt;artifactId&gt;strolch-bookshop&lt;/artifactId&gt; &lt;version&gt;0.1.0-SNAPSHOT&lt;/version&gt; &lt;packaging&gt;war&lt;/packaging&gt; &lt;name&gt;strolch-bookshop&lt;/name&gt; &lt;description&gt;Bookshop built on Strolch&lt;/description&gt; &lt;inceptionYear&gt;2017&lt;/inceptionYear&gt; &lt;properties&gt; &lt;project.build.sourceEncoding&gt;UTF-8&lt;/project.build.sourceEncoding&gt; &lt;maven.build.timestamp.format&gt;yyyy-MM-dd HH:mm:ss&lt;/maven.build.timestamp.format&gt; &lt;buildTimestamp&gt;${maven.build.timestamp}&lt;/buildTimestamp&gt; &lt;jdk.version&gt;1.8&lt;/jdk.version&gt; &lt;jersey.version&gt;2.25.1&lt;/jersey.version&gt; &lt;slf4j.version&gt;1.7.25&lt;/slf4j.version&gt; &lt;logback.version&gt;1.2.3&lt;/logback.version&gt; &lt;petitparser.version&gt;2.1.0&lt;/petitparser.version&gt; &lt;hikaricp.version&gt;2.7.1&lt;/hikaricp.version&gt; &lt;postgresql.version&gt;42.1.4&lt;/postgresql.version&gt; &lt;gson.version&gt;2.8.2&lt;/gson.version&gt; &lt;annotation.version&gt;1.3.1&lt;/annotation.version&gt; &lt;javaxmail.version&gt;1.6.0&lt;/javaxmail.version&gt; &lt;serverlet.</description></item><item><title>Model</title><link>https://strolch.li/documentation/model/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/model/</guid><description>Model Before we dive into the entire model, let&rsquo;s show an example and how it would be modelled in Strolch and use in Strolch:
|
|
A possible model would look as follows:
|
|
&lt;?xml version=&#34;1.0&#34; encoding=&#34;UTF-8&#34; ?&gt; &lt;StrolchModel xmlns=&#34;https://strolch.li/xsd/StrolchModel-1.6.xsd&#34;&gt; &lt;Resource Id=&#34;Product&#34; Name=&#34;Product Template&#34; Type=&#34;Template&#34;&gt; &lt;ParameterBag Id=&#34;parameters&#34; Name=&#34;Parameters&#34; Type=&#34;Parameters&#34;&gt; &lt;Parameter Id=&#34;description&#34; Name=&#34;Description&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;color&#34; Name=&#34;Color&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;form&#34; Name=&#34;Form&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;ParameterBag Id=&#34;relations&#34; Name=&#34;Relations&#34; Type=&#34;Relations&#34;&gt; &lt;Parameter Id=&#34;articles&#34; Name=&#34;Articles&#34; Type=&#34;StringList&#34; Interpretation=&#34;Resource-Ref&#34; Uom=&#34;Article&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;/Resource&gt; &lt;Resource Id=&#34;Article&#34; Name=&#34;Article Template&#34; Type=&#34;Template&#34;&gt; &lt;ParameterBag Id=&#34;parameters&#34; Name=&#34;Parameters&#34; Type=&#34;Parameters&#34;&gt; &lt;Parameter Id=&#34;description&#34; Name=&#34;Description&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;barcode&#34; Name=&#34;Barcode&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;ParameterBag Id=&#34;relations&#34; Name=&#34;Relations&#34; Type=&#34;Relations&#34;&gt; &lt;Parameter Id=&#34;product&#34; Name=&#34;Product&#34; Type=&#34;String&#34; Interpretation=&#34;Resource-Ref&#34; Uom=&#34;Product&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;/Resource&gt; &lt;Resource Id=&#34;Customer&#34; Name=&#34;Customer Template&#34; Type=&#34;Template&#34;&gt; &lt;ParameterBag Id=&#34;address&#34; Name=&#34;Address&#34; Type=&#34;Address&#34;&gt; &lt;Parameter Id=&#34;street&#34; Name=&#34;Street&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;zip&#34; Name=&#34;Zip&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;city&#34; Name=&#34;City&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;country&#34; Name=&#34;Country&#34; Type=&#34;String&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;/Resource&gt; &lt;Order Id=&#34;Order&#34; Name=&#34;Order&#34; Type=&#34;Template&#34;&gt; &lt;ParameterBag Id=&#34;quantities&#34; Name=&#34;Quantities per Article Id&#34; Type=&#34;Quantities&#34;&gt; &lt;Parameter Id=&#34;quantity&#34; Name=&#34;Quantity&#34; Type=&#34;Float&#34; Value=&#34;0&#34;/&gt; &lt;/ParameterBag&gt; &lt;ParameterBag Id=&#34;relations&#34; Name=&#34;Relations&#34; Type=&#34;Relations&#34;&gt; &lt;Parameter Id=&#34;articles&#34; Name=&#34;Articles&#34; Type=&#34;StringList&#34; Interpretation=&#34;Resource-Ref&#34; Uom=&#34;Article&#34; Value=&#34;&#34;/&gt; &lt;Parameter Id=&#34;customer&#34; Name=&#34;Customer&#34; Type=&#34;String&#34; Interpretation=&#34;Resource-Ref&#34; Uom=&#34;Customer&#34; Value=&#34;&#34;/&gt; &lt;/ParameterBag&gt; &lt;/Order&gt; &lt;/StrolchModel&gt; Let&rsquo;s go through this model:</description></item><item><title>Model</title><link>https://strolch.li/tutorial/model/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/tutorial/model/</guid><description>Model Looking back at our functionality, we can list the following entities that need to be modelled (We&rsquo;ll go into detail further down):
|
|
Book → books can be orderd UserCart → we want to store the cart of the user Account → we need to know where to send the orders PurchaseOrder → we need to know what was ordered and keep track of its state FromStock → we want to use activities to implement the process of an order In Strolch we model entities by defining the element as a template.</description></item><item><title>CRUD Book</title><link>https://strolch.li/tutorial/crud-book/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/tutorial/crud-book/</guid><description>Preparation Since Books are central to the bookshop, we&rsquo;ll first create the CRUD REST API for them. The API will be as follows:
|
|
GET ../rest/books?query=,offset=,limit= GET ../rest/books/{id} POST ../rest/books PUT ../rest/books/{id} DELETE ../rest/books/{id} Thus corresponding with querying, getting, creating, updating and removing of books. So let&rsquo;s go ahead and add these REST APIs to our project.
|
|
Our project is using JAX-RS 2.0 as the API and Jersey 2.x as the implementation, thus first we need to configure JAX-RS.</description></item><item><title>Do and Don't</title><link>https://strolch.li/documentation/do-and-donts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/do-and-donts/</guid><description>This page discusses things you should and shouldn&rsquo;t do when using Strolch The following is a simple list of do&rsquo;s and don&rsquo;ts:
|
|
1 Service per use-case, should mostly delegate to Commands. Commands implement use-cases or parts of it, and are thus reusable. Subclass ResourceSearch, OrderSearch and ActivitySearch when implementing use-case specific search - this allows privilege checking. One Transaction at a time - no TX inside of another TX. Commands are added to TXs and performed on close: tx.</description></item><item><title>Runtime Configuration</title><link>https://strolch.li/documentation/runtime-configuration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/runtime-configuration/</guid><description>Runtime Configuration A Strolch runtime configuration comprises two parts: a configuration part, and a model part. The configuration are files located in the ..config/ folder, and the model are files located in the ../data folder.
|
|
In an absolute minimal configuration, the Strolch runtime requires the following folder structure:
|
|
../config/ ../StrolchConfiguration.xml → configures the Strolch agent ../PrivilegeConfig.xml → configures user management ../PrivilegeUsers.xml → contains the users in an XML based user management file .</description></item><item><title>Architecture</title><link>https://strolch.li/plc/architecture/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/plc/architecture/</guid><description>Architecture Overview The Strolch PLC architecture sees the Strolch Agent as the server, managing logical devices, i.e. multiple sensors and actors together and thus deciding on further steps. With this architecture multiple PLCs can be combined together in one agent for flow control.
|
|
PLC Architecture On the agent side the two main classes are the PlcGwServerHandler and the PlcGwService
|
|
The PlcGwServerHandler handles connections from remote PLCs over WebSockets and sends the requests to these PLCs.</description></item><item><title>Realms</title><link>https://strolch.li/documentation/realms/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/realms/</guid><description>Realms 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.</description></item><item><title>Components</title><link>https://strolch.li/documentation/components/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/components/</guid><description>Components A Strolch agent can be easily extended with arbitrary components. An agent is basically a container for classes extending StrolchComponent with a life cycle. These classes mostly implement an interface which describes the operations that are supported by the component.
|
|
The following represents a list of the most used components:
|
|
RealmHandler: li.strolch.agent.impl.DefaultRealmHandler PrivilegeHandler: li.strolch.runtime.privilege.DefaultStrolchPrivilegeHandler EnumHandler: li.strolch.runtime.query.enums.DefaultEnumHandler PolicyHandler: li.strolch.policy.DefaultPolicyHandler ServiceHandler: li.strolch.service.api.DefaultServiceHandler StrolchSessionHandler: li.strolch.rest.DefaultStrolchSessionHandler PersistenceHandler: multiple implementations PostInitializer: project specific implementation MailHandler: li.</description></item><item><title>Services and Commands</title><link>https://strolch.li/documentation/services-and-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/services-and-commands/</guid><description>Services and Commands Services are written to implement a specific use-case. Commands are written to implement re-usable parts of a use-case. The use-case can be abstract e.g., AddResourceService 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.</description></item><item><title>Searches</title><link>https://strolch.li/documentation/searches/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/searches/</guid><description>Searches As is custom for every framework, querying, or searching, the model must be possible. Strolch searches are implemented using the StrolchSearch class and one of its concrete implementations: ResourceSearch, OrderSearch, ActivitySearch.
|
|
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.</description></item><item><title>Queries</title><link>https://strolch.li/documentation/queries/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/queries/</guid><description>Queries The Query API is deprecated and the search API should be used instead.
|
|
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.
|
|
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.</description></item><item><title>Example Set-Up</title><link>https://strolch.li/plc/example-set-up/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/plc/example-set-up/</guid><description>Example Set-Up This example setup describes the movement of containers over conveyors. The conveyors have motors which can be started and stopped by a GPIO output pin controlled on a Raspberry Pi and each conveyor has a light barrier to detect the occupancy of a container and the Raspberry Pi detects this on GPIO input pins.
|
|
Further at each conveyor location is a barcode reader to read the ID of a container.</description></item><item><title>Transactions</title><link>https://strolch.li/documentation/transactions/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/transactions/</guid><description>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:
|
|
Opening and closing database connections Releasing locks to strolch elements, if tx.lock(StrolchRootElement) or tx.lock(Locator) was called Performing Commands by executing them in the added order, and validating them first.</description></item><item><title>Policies</title><link>https://strolch.li/documentation/policies/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/policies/</guid><description>Policies 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.</description></item><item><title>Observers</title><link>https://strolch.li/documentation/observers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/observers/</guid><description>Observers All changes done in a Strolch transaction are recorded and then propagated to any registered observers.
|
|
The observer feature is opt-in and is configured for each realm. In the StrolchConfiguration.xml file enable observers by adding the enableObserverUpdates property per realm:
|
|
&lt;StrolchConfiguration&gt; &lt;env id=&#34;dev&#34;&gt; ... &lt;Component&gt; &lt;name&gt;RealmHandler&lt;/name&gt; &lt;api&gt;li.strolch.agent.api.RealmHandler&lt;/api&gt; &lt;impl&gt;li.strolch.agent.impl.DefaultRealmHandler&lt;/impl&gt; &lt;depends&gt;PrivilegeHandler&lt;/depends&gt; &lt;Properties&gt; &lt;realms&gt;defaultRealm, otherRealm&lt;/realms&gt; &lt;enableObserverUpdates&gt;true&lt;/enableObserverUpdates&gt; &lt;dataStoreMode&gt;TRANSIENT&lt;/dataStoreMode&gt; &lt;dataStoreFile&gt;StrolchModel.xml&lt;/dataStoreFile&gt; &lt;enableObserverUpdates.otherRealm&gt;true&lt;/enableObserverUpdates.otherRealm&gt; &lt;dataStoreMode.otherRealm&gt;TRANSIENT&lt;/dataStoreMode.otherRealm&gt; &lt;dataStoreFile.otherRealm&gt;StrolchModel.xml&lt;/dataStoreFile.otherRealm&gt; &lt;/Properties&gt; &lt;/Component&gt; &lt;/env&gt; ... &lt;/StrolchConfiguration&gt; Registering for updates is done by registering an Observer on the ObserverHandler of the realm itself:</description></item><item><title>Versioning</title><link>https://strolch.li/documentation/versioning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/versioning/</guid><description>Versioning One of Strolch&rsquo;s features that sets it apart from other frameworks, is that versioning is baked into Strolch&rsquo;s fabric. The feature is opt-in, as it is not required in all projects, but it only needs enabling, for all modifications to objects to be versioned, so that rollbacks can be done when needed.
|
|
The feature is enabled for each realm. In the StrolchConfiguration.xml file enable it by adding the enableVersioning propery per realm:</description></item><item><title>Reports</title><link>https://strolch.li/documentation/reports/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/reports/</guid><description>Reports Since Strolch has a generic model, it was rather straight forward to create a simple API for writing reports. In Strolch a report is defined by using its own model, i.e. a Report is a Resource of type Report.
|
|
A report consists of the following parts:
|
|
policy definition, thus allowing extensions basic configuration like base object type, order direction, etc. column definitions joins ordering definition filters An example of a report is as follows:</description></item><item><title>Privileges</title><link>https://strolch.li/documentation/priviles/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://strolch.li/documentation/priviles/</guid><description>Privileges No framework is complete without user management and privilege validation. The basic form would be Users and Roles, and then validating that an authenticated user has a given role. In Strolch we go a step further: A User has roles assigned, and each role has a set of Privileges. The privileges can overlap, a validation is performed to make sure that the one role doesn&rsquo;t deny and another role allows a specific action.</description></item></channel></rss> |