MOVE-FLOW architecture is based on Service Oriented Architecture SOAmixed with Component based Architecture.  The use of SOA allows exposing MOVE-FLOW functions through a standard and discoverable interface.  In turn other application can use and integrate with MOVE-FLOW in a standard way.  Component based design facilitated dividing the system into a set of collaborative components that communicate with each other through a well defined Interface (contracts).
The following Figure  shows SaaS-Flow system architecture.  It is Client/Server architecture. The client side can be one of three different clients:
MOVE-FLOW Web Portal: used by system admin, organization admin, and end user. 
Client application: integrates with MOVE-FLOW through its webservice interface.  It enables application developers to build their user interface for users to work on their tasks instead of using SaaS Web Portal.
Task Manager: of another MOVE-FLOW server.

Server Side contains: Engine, Pluggable Agents, Task Manager, Communication Layer, object builder and Data Repository.  Another two components not shown in the above Figure  and exist at server side are Process Interpreter and Membership Provider.  The following subsections describe these components and their role in the process execution, starting by Communication Layer as an application edge passing through the rest of system components, finishing with Task Manager and its role in MOVE-FLOW WfMS.

It is responsible of exposing system functionality to other systems in standard way. Its main goal is to enable other application developers to use and integrate with MOVE-FLOW in a standard way.
Communication Layer consists of a set of XML web services  based on Ws-* standards. It is developed using Windows Communication Foundation (WCF).  WCF handles the communication infrastructure through the .NET Framework 3.
Communication through this Layer is secured using Secure Socket Layer SSL. Application communicate with MOVE SaaS-Flow provides their credentials in the header of the request. Communication Layer isolates Credentials from incoming requests and passes it to Membership component to authenticate them. Membership component will be described in more detail in next subsection.
The Communication Layer consists of a set of web services grouped in six contracts as follow:

1. Engine Service Interface: defines methods that support process execution and control.  E.g. starting process execution, Canceling Process Execution, Changing Execution Flow …etc.
2. Task Manager Interface: defines methods that handle user tasks such as getting user task list, open task, finish task …etc.
3. Process Management Interface: defines methods that enable handling process registration to system, getting all allowed processes of certain organization or of a certain user, updating registered process …etc.
4. Process Monitoring Interface: defines methods that allow monitoring process execution and getting information about finished jobs.
5. Agent Management Interface: defines methods that allow upload and registering new agents, delete existing agents and updating them.
6. Membership Management interface: defines methods that used to manage subscription information, adding new user and updating user credentials.

Membership provider is a global component that responsible of:
Registering members (organizations) to system.
Authenticating credentials of incoming requests.
Guarantee that each member has a unique namespace used to identify processes and operations related to his organization.
Used to manage organization's users.  Adding new users, updating users' data, and handling users' credentials. User credentials are: username & password and assigned organization's roles.

Process Schema Provider uses Process Interpreter to interpret process written in standard language called XPDL.  MOVE-FLOW architecture allows plugging-in interpreters for other modeling languages.  MOVE-FLOW has XML configuration file used for mapping: instantiation information of interpreters and their corresponding modeling languages.  The output of Process interpreter is a process modeled in the form of Process Object Model (POM). The following Figure  shows the UML diagram of POM.  Next section describes MOVE-FLOW Engine components which executes process in the form of POM

UML diagram of the process definition

It is responsible of process execution by organizing work between all working components.  Engine is hosted as a singleton object and can be accessed manually through console application.  Other applications can communicate with the engine through its communication layer.
components managed by MOVE SaaS-Flow Engine are:
Process Execution Service and Activity Execution Service: used by engine to execute the process.
Process Schema Provider: this service handles Process storage in its static view.
Repository Data Provider: this service handles storage of Process execution data such as saving state and tracking information.

Scheduler Service: monitors execution times, delays and trigger events related to these delays.
The engine receives the process in the form of POM for execution.  The following Figure  shows the execution sequence of a process, for simplicity the Communication Layer, Process Schema Provider, and Repository Provider are ignored.

Process Executeion Sequence Diagram
Engine opens a thread for each activity execution. AES uses a callback delegate to inform engine for activities status changes. The same happen with PES.  Engine has a method called ProcessExecutionEventHandler which responsible of handling AES and PES callbacks.
As shown in the above figure, engine handles human tasks as remote services executed by human.  It is executed as a service call to agent.  This frees the engine from considering how the activity will be executed.  All activities are the same; they executed as a service and request engine to finish task to continue the flow of process execution.
Engine publishes important events; e.g. Process Start, Process Finish, Activity Start…etc, using Event Manager.  Event Manager publishes events to subscribers registered in its XML configuration file.  Subscribers are classes' implementing IEventHandler interface and subscribed to Event Manager to trace engine events.
All mentioned services are pluggable components.  A special class is used to realize plug-in pattern which is ObjectBuilder. 

Process Schema Provider and Repository Data Provider are the Data Access Layer DAL of MOVE-FLOW.  They work using plug-in pattern which means that the Database management is abstracted from MOVE-FLOW.  Also MOVE-FLOW is independent of Database used.
Process Schema Provider is responsible of handling process in its static view.  It is responsible of:
Registering process to system.
Update registered process with new versions: Each update of a process is saved as new version.  User can choose which version to load for execution.
Load Process: used to load process for execution based on the execution request coming from user.  If the process version was not provided, latest version will be returned, otherwise the required version is returned for execution.
Delete Process: allows deletion of a process or one of its versions. Deletion can only be done if the process is never used. If the process has active jobs deletion will be refused.  If the process has previous jobs, the process will be archived and marked as deleted.
Get Process List: get all processes registered, Process of a certain subscriber, or process of a certain user.
Repository Data Provider contains process execution information, and complete history of previously executed processes.  Repository Data Provider is responsible of:
Save Job data to database associated with its currently working tasks and finished tasks.
Update Job status and Task status while process execution.
Upload unfinished Jobs with its execution context to be ready to complete its execution.
Get history of finished Jobs for auditing.
Next subsection describe pluggable agents and its role in process execution.

Pluggable agent is an executable code that executed in relation to the execution of certain Activity. 
There are two types of Activities, Automated Activity that need no human intervention, and Manual Activity, that need human intervention to complete the task.  For the Automated Activity agents finishes its work and callback engine to inform finish.  For the Manual Activity, the agent calls Task Manager to register user task.  After user finishes the task, Task Manager informs engine about task finish.
When Activity Execution Service executes activity, it loads instantiation information of its correspondent agent from the Repository.  In turn Object Builder creates an instance of the agent.  Then Activity Execution Service passes callback delegate and task parameters to the agent then executes it.  The callback delegate is used by the agent to inform engine for its status updates.
Developers can create their Agents by implementing  Agent interface.  Then associate it to its related activity through system portal. Agents can be reused for activities that need similar execution action. 
An example of reusable agent is UserAgent and Notify User agents. User Agent is used to register Human Interaction Tasks to Task Manager.  It calls Task Manager locally or remotely over the web to register user task.  Notify User agent is used to send email using user email parameter provided with task parameters.

MOVE-FLOW Task Manager is responsible of handling tasks that require human interaction.  It acts as interface between the engine and client applications. 
Task Manager Functions are:

1. Receiving user tasks and registering them in its local store.
2. Makes user task list available to client application and other WfMSs.
3. Allow client application to access user tasks and update its state.
4. Inform engine for task completion
5. Act as interface between MOVE-FLOW and other workflow management systems.