Infiniflow: Next-Generation Distributed Application Server based on OSGi and SCA

Posted by Ryan Slobojan on Feb 20, 2008 08:30 AM

Community

Java,

SOA

Topics

Application Servers,

Enterprise Architecture

Tags

Service Component Architecture,

OSGi

Paremus recently released version 1.2 of Infiniflow, a next-generation distributed application server based on OSGi and SCA. InfoQ spoke with Paremus Marketing Manager Andrew Rowney to learn more about this release and about Infiniflow's new application server model.

Rowney first explained that Infiniflow was based upon OSGi and SCA, and that it follows an application server paradigm - a component is written as a series of OSGi modules, it is linked to external services through the SCA bindings, and Infiniflow provides life-cycle management, monitoring, scaling and fault-recovery for any application deployed on it. Rowney also described some best practices for application development with Infiniflow:

To take advantage of the full capabilities of Infiniflow, an application needs to be presented as a composite application rather than a single runtime entity, with different parts of the processing requirements being handled in separate components (OSGi bundles). A good example is where a part of the composite application contains an intensive calculation that can be run in parallel to reduce the overall processing time. For this type of applications the developer is able to specify that Infiniflow should duplicate the bundle that runs the calculation, instantiating as many copies as possible in order to calculate the final result as quickly as possible. This could be regarded as grid computing, however this approach doesn't require an expensive dedicated 'grid silo', instead the hardware can be shared with other applications (that are also under the control of Infiniflow, which automatically allocates resources and manages any contention).

Infiniflow has several major features:

• Support for all major OSGi containers - Equinox, Felix, and Knopflerfish OSGi runtime containers are all supported for application deployment
• SCA compliance - Infiniflow implements version 0.96 of the SCA specification, and 1.0 compliance is expected by the middle of this year
• Open source basis - Infiniflow is built on top of Newton, which is open source under the GNU General Public License
• Spring Dynamic Modules support - Because Spring Dynamic Modules applications are OSGi compliant, they are transparently supported on Infiniflow
• Automatic scaling - Infiniflow scales an application automatically according to its SCA System description
• Self-similar architecture - Infiniflow itself is built using OSGi, and wired together using SCA System descriptions
• Eclipse-based tooling - An Eclipse-based plugin allows deployment and testing inside of Infiniflow
• Automatic fault recovery - if a resource fails, the failed component is automatically re-provisioned onto other servers
• Model-Driven Architecture - to reduce operational complexity, application runtimes can only be modified through their SCA System descriptor, and all interactions with the descriptor are secured and audited

InfoQ asked Rowney to explain in more detail how Infiniflow handles scaling of an application:

An Infiniflow Service Fabric consists of a number of Infiniflow containers - OSGi-enabled JVM's - which are able to dynamically install/start/stop/uninstall code packaged in the OSGi bundles referenced from the SCA System document.

The basic scale out behaviour is as follows:

• The Service Fabric receives a System description which describes how the service components should be assembled to build the ‘System’ and defines its 'Target State'. Each service component may have its own runtime requirements and scaling behaviours
• Based on the required scaling behaviours, Infiniflow Provisioners dynamically negotiate with available servers/virtual machines to identify potential candidates that can host components of the System
• Servers that agree to host a Service component receive the relevant SCA fragment from the Provisioner, and the server agrees to host the service component for an agreed period of time (the contract)
• Each server proceeds to download (pull) the relevant OSGi bundles specified in the fragment from the Service Fabric repository and instantiate the services locally
• The Service Fabric continues to monitor the runtime population against the SCA document, scaling and re-deploying services components as required to meet Target State

At the application layer within the Infiniflow Service Fabric architecture, scale out behaviour of a composite System is a function of:

• the SCA bindings used between distributed service components within the System
• the replication behaviour applied to each composite Service
• the associated middleware, if appropriate

This means that a rich set of scale-out behaviours are easily configurable, including SEDA, Federated Space, Hadoop-based, for message, asynchronous or synchronous patterns of communication between distributed service components, using an array of possible protocols including RMI, SOAP or TCP/Streaming.

Rowney went on to describe the future plans for Infiniflow as:

• Increasing the autonomy of Infiniflow by embedding more intelligence in the Infiniflow Service Fabric
• Continuing efforts to integrate with middleware providers
• Further integration with monitoring and auditing frameworks
• Increasing robustness through extensive scale-out and failure test scenarios
• Improving developer support through utilization of open source tools
• Working with standards bodies to ensure that the Infiniflow architecture remains open and flexible

• Older >