The cornerstones of the Infiniflow architecture are technical concepts and functionality as follows:

• Model-Driven Architecture
• Component Re-use
• Autonomic Runtime
• Virtual Resource Market

Core to the Infiniflow architecture is the distinction between the Functional System description, also referred to as a composite application description, and its instantiated runtime ‘form'. Each Functional System runtime ‘form' is defined in, and controlled by its own unique SCA-compliant, XML-based, SCDL ( Service Component Definition Language) document called a System Document.

Similar in concept to architectural blueprints or a recipe for a meal, the System Document defines the model of the functionality required for each Functional System including the business logic, middleware, runtime requirements and SLA policies.

Each System Document provides a list of the required OSGi components (together with the quantity and version number) along with details of how the components are wired together. In addition the document can specify absolute or preferred capabilities that a compute resource must offer in order to run a specific component e.g. chipset, operating system, memory capability or external 'gateway' functionality (e.g. database access).

Infiniflow itself utilizes the same model-driven approach to describe the ‘form' and instantiate the command and control services, called Infrastructure Services, used to run and manage the Service Fabric.

The model defined in each System Document represents the Target State of the desired Infrastructure Service or Functional System when running. Once a System Document is activated, the Infiniflow Service Fabric instantiates all of the prescribed functional elements and then proceeds to manage the runtime entity with respect to its idealised model, i.e. the Target State .

• To dynamically upgrade a component in a running application or Functional System, simply change the component version referenced in the source System Document - Infiniflow will automatically roll the new version out and gracefully retire and clean up all instances of the old component.

• To change middleware (e.g. from or to - messaging, caching or transactional), simply modify the relevant infrastructure components referenced in the source System Document.

Infiniflow delivers on the Model-Driven promise, assembling the simplest to the most complex applications from these self-auditing System Documents. Infiniflow consists of over one hundred OSGi components, automatically deployed and assembled by activating the supplied Infrastructure System documents. Functional Systems can be made up of just a few components or 10's or 100's of components, the number determined by the desired granularity.

One of the key Infrastructure Services that Infiniflow provides to realize the operational simplicity of the model-driven architecture is a resilient Provisioner Service.

Clearly Infiniflow uses some very sophisticated techniques, however they are all automated and require no human intervention, which enables very simple, yet powerful management functionality. Deploying, Operating and Managing applications using Infiniflow is really simple. A composite application can be built and deployed in just two steps:

Step 2: Deploying and running a composite application across the Service Fabric

Use the Fabric Administration GUI to start System Document #1.0.

This results in System Document #1.0 being passed to the resilient Provisioner Service which negotiates with available compute resources to run the required components.

These resources download the relevant OSGi components from the Content Distribution Service and assemble the component functionality as described in System Document #1.0.

Throughout this process no manual deployment to any compute resources is required; human intervention is minimized to simple document management.

Infiniflow is based on the premise that applications and Functional Systems are composites, made up of loosely coupled, re-usable components, often referred to as services. This allows developers to rapidly and easily modify and enhance applications by changing only one or two components rather than the whole stove-piped hard-wired application. It also allows developers to create a wide variety of applications and Functional Systems without the need to duplicate effort building the common functionality that many applications and Functional Systems share.

All of the components in an Infiniflow environment (including Infrastructure Services, application components and middleware components) are defined as OSGi bundles. Infiniflow fully leverages the OSGi R4 component framework and Paremus is actively involved in the OSGi Enterprise Expert Group.

Infiniflow borrows heavily from Complex Adaptive System (CAS) design principles, where extensive studies in non-IT related topics (e.g. natural and political systems), has identified that there are common traits to all successful dynamic, autonomic systems. These traits include: loose coupling of simple components; tagging of components to enable reuse; and aggregation of these simple components within hierarchies at multiple levels to offer increasingly sophisticated behaviors.

Infiniflow has been designed from the ground-up with these key characteristics in mind and this has enabled Infiniflow to achieve advanced autonomic capabilities that maximize business agility and simplify management:

• Self-assembling
• Self-healing
• Self-managing
• Self-scaling
• Self-auditing

With no single point of failure and no special frames of reference, Infiniflow boasts a truly distributed dynamic architecture, from command & control and management all the way through to business applications running on the fabric.

The power of this architecture is realized not just in enhanced application availability but in the OPEX savings made by simplifying and automating many of the labor intensive operational tasks in enterprises and datacenters today.

An excellent example of the power achieved by fusing the model-driven architecture with the autonomic runtime is the self-healing capability which provides automated resilience to your composite applications.

The Provisioner Service identifies that some of the running components have disappeared from the runtime, in this case a green circle and two yellow squares. This sets off the negotiation process, aiming to restore the 'target state' detailed in System Document #1.0 (in the example above).

The composite application controlled by System Document #1.0 continues to run, albeit in a sub-optimal state. If there are no suitable resources available for running the blue triangle, then the application defined in System Document #1.0 continues in its sub-optimal state until available resource is either identified or the application is stopped and decommissioned.

Dynamic provisioning has been realized by designing Infiniflow as a model-driven, agent-based architecture. This dynamic provisioning capability enables Infiniflow to offer advanced Virtual Resource Market behaviors that ensure the most efficient dynamic distribution of service components across the available compute resource. The Virtual Resource Market operates at many levels, from basic capability matching through to sophisticated 'price' based negotiations.

For any market there needs to be supply and demand. In Infiniflow's world, supply is limited by the available compute resources and demand is created by the business application requirements. At the simplest level the capability negotiation includes metrics such as owner, chipset, operating system, memory capability or external 'gateway' functionality (e.g. database access). At the more sophisticated level once the base capabilities have been met, the suitable resources offer prices to the applications for running the required functionality for periods of time.

This Virtual Resource Market capability offers huge benefits to the enterprise, the Service Provider and SaaS markets. Not only does it ensure the optimum use of resources to meet the application demands, it also provides the ability for owners of the physical infrastructure to 'charge' on a usage basis providing cost efficiencies and savings for both provider and consumer.