25 lines
16 KiB
XML
25 lines
16 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>Documentation on Strolch</title><link>https://strolch.li/documentation/</link><description>Recent content in Documentation on Strolch</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="https://strolch.li/documentation/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>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>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>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>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> |