All software ultimately exists to provide some kind of service to one or more users. Fabric applications contain one or more services organized in a fashion that is consumable by the fabric. These services are deployed to the fabric to gain one or more of the features of the fabric (e.g., scalability or reliability). We refer to the users (or consumers) of these services "fabric clients". A fabric client could be running as a service inside of the fabric or running somewhere outside the fabric.
Fabric services are composed of one or more "fabric actions" which are methods of the software deployed to the fabric. The services can be:
- single "action" that is executed by the fabric on demand by the fabric client leveraging the scalability of the fabric (the service can run on any of the workers in the fabric) and the reliability (once initiated, the service will be run to completion by the fabric), or
- "multi-step" process flow - where the fabric runs multiple "actions" when the service is invoked. The organization of the action is declared in a finite state machine within the process flow XML, describing which actions to run and the order in which to run them.
The user code implementing the service along with the supporting XML describing what services to publish are packaged into a single file and deployed to the fabric. The fabric will install the fabric application on all workers within the fabric and exposes the service to the clients. Examples of creating and deploying applications can be found in our Application Development Tutorials
These actions could be:
Java Spring Beans
Using the fabric ultimately results in building a distributed application where the client and service run on different computers. Applications can leverage the Spring remoting architecture with the fabric to easily distribute software as a service to the fabric and to call this service from the client. This involves the concepts of a service exporter and a proxy generator. The fabric provides a configurable service exporter which you use to expose (or publish) your service as a Spring bean. Leveraging both fabric XML and Spring XML, the developer can configure and expose a remote service (with little or no code written).
Once the service is exposed, you need to develop a client that can access the service. This can be one of the most complex parts of writing a distributed application. Once again you can leverage the fabric and Spring to encapsulate these details. Spring hides the fabric remoting architecture from the client code by generating a client proxy of the service. The proxy handles the details of remoting to the fabric service, calling the remote object, and dealing with errors.
See Running Spring Beans in the fabric for more details.
Java Components
Service written in Java can be exported from (or exposed by) the fabric without an dependency on Spring using the fabric's Java Components. The Java Component is fabric-native service exporter which you can use to configure and expose a Java class as a fabric service using a declarative model. This approach allows the service to configured and deployed to the fabric with little or no new code written.
See Running Java Components in the fabric for more details.
Fabric Tasks
The most flexible approach to developing and deploying fabric services is configuring "fabric tasks". Tasks can be written in C/C++, Java, or a .NET language, and packaged into a module consistent with the language (i.e., shared library (or DLL) for C, a Java jar file, or a .NET assembly, respectively). Information about each service is defined in the Task XML and exposed as a service via a Process Flow XML.
Fabric Tasks have direct access to the fabric request, the object sent from the the client to the service via Appistry's proprietary transport. Two mechanisms exist for the task to get data from the request - annotations and the fabric API.
Annotations - the fabric will unmarshall data from the fabric request into properties of the services class and parameters of the method that have specific fabric annotations. This provides the developer complete control over how the request is used to get data from the client to the service. This mechanism is available for .NET languages and Java.
Fabric API - optionally, the exposed service method can take a request and the developer writes the code to read inputs from the request and write outputs back into the request. This mechanism is available for C, Java and .NET. Note: due to the lack of reflection in C/C++, this is the only mechanism available to C.
See Running tasks in the fabric for more details.
Process Flows (with Spring, Java Components, and/or Tasks)
Process flows are used to publish services from the fabric. They are sophisticated finite state machines written declarative in Process Flow Definition XML that allow user code delcared as Spring Beans, Java Components, or Fabric Tasks to be organized into a series of actions with control over order of execution of those actions. The result is a fabric service that can execute many smaller services in a reliable, scalable macro service. Process flows are hierarchical. Process flows within an application can invoke other process flows in the application - resulting in even "larger" services exposed by the fabric - all with a declarative model describing appropriate error handling when things don't go as planned.
See Process Flow Definition XML for more details.
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.
