Basic concepts

At first, to understand what is Flower and how it works you need to learn basic concepts and terms.

The directory

The central part of Flower is the directory. The directory is a hierarchical persistent storage used by the Flower components to store their data and communicate with each other. A single instance of Flower has logically a single directory (physically the directory may be distributed, but Flower knows nothing about that). The directory for Flower is something like a file system for an OS, but more robust. For example, unlike most of file systems the directory is transactional.

Every entry in the directory has an id, name, creation and last update timestamp, associated permissions list and other attributes. Any entry may have child entries and one parent entry (except the root which has no parent). The set of attributes of an entry is not arbitrary, but determined by the entry type. These types are predefined by the directory specification.

The directory stores:
  • Assemblies containing workflows and all their dependencies.
  • Services configuration in form of Spring.NET IoC containers defined in XML.
  • States of the running processes, so that, if a processor crashes, the state of its processes could be restored from the last save-point.
  • Messages by using which applications communicate with the processes and the processes with each other.
  • Security roles.
  • Other metadata information used by the platform.

There are also folder entries the only purpose of which is to group other entries. They are just like directories in a file system.

Processes and workflows

In Flower terminology process is a job scheduled for execution or being executed; a workflow is a definition of a process. Workflow (or process definition) may stand for a class defining a process or an algorithm in abstract, while a process is an execution of that algorithm.

In general, a process is initiated by an external application via the Flower client API. The client creates an initial state of a process and the corresponding directory entry which is assigned to one of the registered processors. The directory can notify a processor on that. As soon as notified, the processor picks the process for execution (if the notification is not supported by the directory implementation, the processor polls the directory checking if there are pending processes). Executing a process the processor saves its intermediate states to the directory. The process can send and receive messages thus communicating with other processes and external applications. If a process waits for some event for too long, the processor may unload it and resume as the event occur. In this case or in the case of system crash or restart the process is resumed at the last savepoint. When the process is finished, the processor unloads it permanently.

architecture.png

Directory contents

Flower relies on the directory structure making assumptions on where entries of a specific type should be. Location of an entry has different semantics depending on the entry type and it is usually very important. Developing applications and workflows on Flower you will almost never work directly with the directory, but grasping its structure is important for understanding where the entry paths come from.
  • Assemblies are contained under the top-level folder '/Assemblies' in a folder structure similar to that of GAC. Relying on this structure Flower locates assemblies with the requested name and version.
  • Services configurations lie under '/Services' folder. This folder may contain service configurations directly or in subfolders which play a role of namespaces. For example, a service CustomerCare in an IoC container CustomerManagement may have a shortest path '/Services/CustomerManagement/CustomerCare', but if you have multiple systems using the same Flower instance, you may have additional level of namespaces so that the service will have a path say '/Services/CRM/CustomerManagement/CustomerCare'. Here 'CRM' is a subfolder of '/Services'. The namespaces may be nested and the depth of the nesting is not limited.
  • The folder '/Sets' contains two subfolders - 'Shared' and 'Local'. They contain metadata of the sets. More on the sets can be found in the section 'Sets and inter-process communication in Flower'.
  • Registered processors metadata lies under '/Processors' folder.
  • Processes are represented by the entries stored in subfolders of processors. Process states are the child entries of the processes.
  • The folder '/Roles' contain security metadata.

To start developing workflows, you don't need any directory instance. You can run the processes in unit-test environment with services and directory mocked using the Flower testing API. For applications development you may choose to install the directory service locally and use in-memory implementation initialized with a copy of some testing environment (see "Setting up Flower services").

Paths and ids

Every resource in Flower has its corresponding directory entry, so it can be identified by a path or an id. A path is much like a path in a file system - it is the names of all ancestor entries joined by slash. The directory itself supports only global paths i.e. starting with '/', but for convenience in many cases Flower allows relative paths and extend them relying on conventions.

Paths are case sensitive.

An id starts with '#', then goes an identifier unique within the directory - number, GUID or whatever a particular directory implementation use for ids.

Depending on type resources are addressed more by ids or by paths. In general, the resources number of which may be large and those for which it is difficult to find a unique name are addressed by ids (messages, processes); other resources a usually addressed by paths. However, in the directory service interface paths and ids are always interchangeable.

Getting started with Flower

To get started with Flower, you need to download the installation package. It is a zip archive containing binaries and configuration files of the Flower components. The components are installed by MSBuild so you need .NET SDK 4.0 to perform the installation. To install a component you need to execute a corresponding task and specify where you want the component to be installed (the default location is 'C:\Flower\<Flower version number>'\Bin).

To develop and test workflows and client applications, you need to install the testing API (all other required libraries will be installed as dependencies). In the package directory run the following command:

msbuild /t:Testing /p:InstallDir=c:\Your\Flower\Installation\Path

After that the directory you have specified as InstallDir will contain all the DLLs you need (they are not added to GAC by the installer). For other components the installation location will also contain executables with configuration files and it will be the base directory for all Flower services and tools.

Now you are ready for the next tutorial: Creating the first workflow.

Last edited Oct 26, 2013 at 10:58 AM by dbratus, version 3

Comments

No comments yet.