A fabric application is a service composed of actions and process flows. A fabric developer creates actions as object-oriented classes in .NET and Java, or as 'C' libraries. Task actions can be called directly from a fabric client application or a series of actions can be combined in a process flow. Process flows can be executed from any application using the fabric client API. Tasks, process flows, and other files, described below, are compressed into an application package. The application package is deployed to the fabric and automatically installed on each worker.
How do I build, deploy, and run a fabric application? Good starting points are found in our Application Development Tutorials
Task Actions. Developers implement task actions as simple object-oriented classes that are marked up using fabric annotations in Java, fabric attributes in .NET, or as libraries in 'C' using fabric task interfaces. Fabric tasks are the smallest unit of work within a fabric application, and are only concerned with implementing business logic. Fabric workers execute task methods during the execution of a request against a fabric application. A task may be a fabric client itself which submits work to the fabric. Fabric tasks can be deployed with different execution and life-cycle behaviors:
The fabric is capable of running multiple, concurrent instances of a task on a worker or CPU. However, this is not always desirable. Appistry EAF allows you to configure a task by classifying it as one of four types and adding parameters based on the task type. The table below provides a basic overview of the four task types. For in depth explanations, refer to the appropriate task's tutorial.
| Task Type |
Characteristics |
Configuration |
Tutorial |
| Unlimited |
- No restrictions
- Multiple instances may run concurrently on multiple workers in the fabric
- Multiple requests for the task are serviced concurrently depending on available memory and CPU
|
Task XML file |
Hello World with Process Flows and tasks |
| Limited |
- Only a specified number of instances may run concurrently in the fabric (for example, a limited task may be configured to run on 2 out of 10 workers)
- A worker may run multiple instances of the task
- Multiple requests for the task are serviced concurrently depending on configuration, available memory, and CPU
|
Task XML file |
|
| Exclusive |
- Only a specified number of instances may run concurrently per worker or per CPU (for example, an exclusive task will run on every worker but be restricted to only one instance at a time based on worker or CPU)
- The fabric performs load control to balance requests for exclusive tasks across the fabric
- When multiple requests for an exclusive task arrive on a single worker, the requests are executed in a gated fashion. For example, if exclusive tasks are configured to allow two concurrent per worker, then two requests are serviced at a time while other requests wait their turn.
- Good for long running tasks (several seconds or more) or CPU intensive
|
Task XML file and fabric.cfg |
Computing Pi using Exclusive Tasks tutorial |
| Background |
- Runs constantly waiting for work (like a unix daemon or Windows service)
- Background tasks are not called from a process flow as part of a client request, but rather get "work" as defined by the task implementer. For example, the background task might monitor a queue in fabric accessible memory (FAM), read from a socket. or poll a service external to the fabric.
- Since it is not part of a fabric request, background tasks do not have the same inherent reliability as the other task types
|
Task XML file |
|
Process Flows. Fabric process flows enable a fabric developer to organize their deployed user code into a series of actions that fulfill a single client request. The developer declares a set of process flow states that describe actions that the fabric executes. The actions may be execution of user-defined code in Java, .NET or C/C++, or it may be a sub-process flow (another process flow defined in the application). Additionally, the process flow defines any error handling steps in the event of problems. The fabric handles all of the rest. The developer need not write code to implement reliability, scalability or fault-tolerance. The simplest of business objects deployed as an action in a fabric gains these benefits automatically. Process flows are defined in XML files.
XML-based Definition Files.
| Definition File |
Description |
| Application |
The application definition is an XML file that defines the logical units of a fabric application and the application version. The logical units consist of all the process flow and task module definitions, as well as any support files for a single fabric application. The application definition file may specify a list of access control groups allowed to use the application. |
| Process Flows |
The process flow definitions are XML files that declaratively define the series of fabric task actions to be performed within a fabric client request. The process flow definition file may specify a list of access control groups allowed to execute the flow. |
| Components |
The component definitions are XML files that declaratively describe the Java classes to the fabric. Component methods can be used as actions in process flows and can be called by appropriately configured Spring clients (that live inside or outside the fabric). |
| Task Modules |
The task module definitions are XML files that declaratively describe compiled task code to the fabric. |
Support Files. Supporting files are any files a developer defines that the fabric application needs to complete its tasks. For example, a text file with configuration parameters specific to a task or a .so/.dll/.jar file that a task may be dependent upon. Support files are listed in the fabric application definition file and copied into the fabric application package file.
Fabric Application Package File. The package file is a compressed archive of the physical files listed in the application definition file. To install a fabric application on a fabric, deploy an application package to a fabric. The fabric distributes the package to all the workers and they decompress the file. Once the file is decompressed, the workers are ready to execute the fabric application and fulfill requests for that application's process flows and task actions.
Fabric client. A fabric client application is any Java, .NET or 'C' application that uses the fabric client API to execute requests on a fabric. The fabric client API supports both synchronous, blocking execution, as well as asynchronously submitting and waiting for multiple requests in a multithreaded, non-blocking model. A fabric client may run outside the fabric, or alternatively, the client itself may run inside the fabric as a task while submitting work to the fabric.