The Spring development framework has fundamentally re-shaped the Java enterprise market place. SpringSource succeeded in challenging the dominance of the major Java application server vendors and changing the mindset from monolithic application server infrastructure to a development framework that is abstracted from the runtime environment.

The ability to dynamically assemble applications from a library of re-useable software components has been a long-term objective of software engineers and architects, and Spring's adoption of OSGi™ brings the realization of this one step closer. Spring 2.5 supports OSGi and Spring Dynamic Modules 1.0 (formerly Spring-OSGi) was released last month.

Benefits that the adoption of OSGi brings to Spring include:

• Increased separation of application logic into modules,
• The ability to concurrently deploy multiple versions of a module,
• The ability to dynamically discover and use services provided by other modules within the local JVM,
• The ability to dynamically deploy, update, and remove modules from a running system,
• Use of the Spring Framework to instantiate, configure, assemble and decorate components within and across modules,
• A simple and familiar programming model for enterprise developers to exploit the features of the OSGi Service Platform.

Spring's OSGi support also makes the development of OSGi applications simpler, and developers more productive, through component re-use and by building on the ease-of-use and power of the Spring Framework. However, to realize the full potential of Spring Dynamic Modules (DM) requires an OSGi-based dynamic and flexible distributed runtime.

The hardware and operating system agnostic Infiniflow Service Fabric v1.2, is just such a runtime. Any application built using Spring DM can be deployed, distributed, made resilient, scaled and managed by Infiniflow without any code changes.

Infiniflow also makes it easy to Develop Local and Deploy Global.

Developers can test a set of their services within a local OSGi runtime and when ready, thanks to Infiniflow's use of Service Component Architecture (SCA), the services can be distributed across a network of servers. A wide range of remote communications protocols, for example RMI, WS*, JMS, etc., can be introduced without any code change, by simply replacing local bindings in the SCA document with the appropriate remote bindings. With Infiniflow, SCA provides an industry standard approach to describing distributed Dependency Injection style applications, a little like a distributed version of Spring.

The snowballing adoption of OSGi and the standardization of SCA, allows the largest of organizations to benefit from Infiniflow, confident that they are leveraging a standards-based state-of-the-art solution that avoids both architectural compromises and proprietary lock-in.

The Cloud Computing and utility SOA vision that started with commodity hardware, grid computing, ESBs and server virtualization, progressing via Amazon S3 and EC2 together with Google-type utility service models, is finally fully realized by the Infiniflow Service Fabric.

The Value for Developers & Architects

By leveraging OSGi and SCA standards, Infiniflow simplifies the development and implementation of composite applications. OSGi provides the re-usable component building blocks, called bundles, and SCA provides an abstraction of the technology used to handle communication between components.

OSGi ensures complete code isolation, removing the 'DLL hell' of conflicting jar files, isolating applications from each other and the runtime itself. The OSGi model also allows each service to clearly define its dependencies on other libraries, guaranteeing that the correct dependencies will always be used while also allowing multiple versions of the same service to run at the same time.

As mentioned above, SCA enables the “late binding” of communications protocols to the OSGi components, providing a very efficient and flexible approach for distributing the composite application.

By making it easy to re-use OSGi components and compose applications from them using SCA, Infiniflow allows developers to significantly enhance their productivity. The need to duplicate mundane functionality is removed, and developers can focus on the more interesting challenges of each requirement.

Infiniflow views middleware in exactly the same manner as business logic, allowing runtime systems to be rapidly assembled from a selection of middleware infrastructure services and breaking the one size fits all approach imposed by traditional middleware vendors. The architect simply selects the most appropriate SCA bindings and corresponding middleware services to achieve the desired operational behavior for each composite application. These can then be deployed and run without any need for the developer to change any of the software components.

Infiniflow currently support ESB (Mule), CEP (Esper), Java Spaces (Blitz Project) and Caching (Oracle Coherence). In addition to these third party middleware offerings, Paremus supplies Compute Grid and high throughput Real Time Grid SCA service bindings and transactional services (JTA/Jini).

In addition to the structure of the composite application, the architect also dictates how each component of the composite application, including middleware, should scale in the runtime to maximize throughput, minimize latency, minimize cost, etc.

Architects can also specify which servers or virtual machines should be used to run which components of the composite application. Considerations may include platform type, owner, locality, cost and availability characteristics.

The Benefits for Operations & CIO

Infiniflow directly addresses the operational complexity and business system agility issues facing the CIO's of Fortune1000 companies. These are measurable via their impact on OPEX, governance and the agility and availability of business systems. Zapthink succinctly explains these issues with respect to traditional SOA solutions (see The SOA Forecast for 2007 and Forget Maturity Models – It's Time for an Agility Model).

Acknowledging in 2003 that business applications should not be viewed as static structures, rather highly dynamic entities that must each easily and rapidly adapt to accommodate both changes in resource availability and changes in their internal composition, Paremus embarked upon building a distributed runtime (you could think of it as a virtual application platform or Cloud OS) capable of meeting these challenges and reducing operational complexity. Infiniflow is unique in the industry today for acknowledging and addressing these challenges head-on, and by leveraging industry standards such as OSGi and SCA to ensure no proprietary vendor lock-in.

Infiniflow is a Model-Driven Architecture and this dramatically simplifies the processes and procedures for deploying, running, changing and un-deploying applications. Any runtime composite application (referred to as a System in Infiniflow) can only be started, changed or stopped by interacting with its SCA description which is defined in a document (referred to as a System document in Infiniflow). All interactions with the SCA System document are fully secured and audited.

To deploy and start a System, an operator with the appropriate privileges simply sets the SCA System document to ‘active'. Once activated, Infiniflow dynamically checks the software dependencies and the availability of the specified server or virtual machine types (reporting any issues), and proceeds to dynamically deploy the System to appropriate servers or virtual machines, scaling in the manner described by the architect in the SCA System document.

The Infiniflow Service Fabric continues to monitor the running System against its SCA description (i.e. its Target State ) . If resources fail, Infiniflow will automatically re-provision the failed components onto other servers or virtual machines and if the SCA System description is changed, Infiniflow will automatically re-align the runtime System to its new SCA description.

It is no longer necessary to build the under-utilized application silos (including compute grids) that are crippling today's data centers.

As Infiniflow is able to automatically, and within seconds, deploy and un-deploy applications across distributed servers, we can ensure that specific owners of servers and/or applications receive the appropriate computing capability when they require it, and that the servers are available for other tasks or powered down when they aren't required.