Infiniflow is based on two industry standards that are set to transform the software application and runtime worlds - OSGi™ and SCA (Service Component Architecture). These two standards are backed by most of the biggest names in the industry, including IBM, Oracle (and BEA Systems), Red Hat, SAP and SpringSource. Customers can be confident that, with Infiniflow, they are leveraging a standards-based, state-of-the-art solution that avoids architectural compromise and proprietary lock-in.

Infiniflow is Java based and has transparent support for POJO's and development frameworks including the Spring Framework. Infiniflow is also able to support non-Java based applications.

loosely coupled interchangeable component framework that is both flexible and easy to maintain.

OSGi technology also addresses the management issues caused by components within business systems evolving at different rates (a.k.a. DLL/Class Loader hell), as OSGi allows components of the same type, but of different versions, to be used in the same JVM runtime.

The OSGi standard has been developed under the stewardship of the OSGi Alliance, and the OSGi specification developed by the members is an open process and made available to the public free of charge under the OSGi Specification License.

OSGi was initially aimed at the embedded, 'smart home', automotive and mobile industries and significant adoption has occurred. Since late 2005 there has been a huge surge in interest and activity in OSGi technology from the enterprise software vendor community which has led to the establishment of the Enterprise Expert Group (EEG) in 2006, within the OSGi Alliance, and Paremus is an active member.

For more information on OSGi in the Enterprise, take a few minutes to browse through the technical presentation delivered to NYJavaSIG in Oct 2007. You can also review the OSGi Alliance EEG Charter.

Three open-source, interchangeable, OSGi Platform implementations of the specification are available, each designed to run in a local JVM - Equinox (Eclipse), Felix (Apache) and Knopflerfish (Apache).

JEE application server vendors are moving en-mass towards being built on an OSGi component framework (see InfoQ August 2006). Indeed, all the leading application server vendors (including IBM, Oracle (and BEA Systems) and Red Hat) and open source projects (Geronimo, JOnAS v5 ) have announced the intention to decompose their traditional monolithic application servers into framework solutions with pluggable OSGi components.

The open source Eclipse IDE has been based on OSGi since 2004. The popular Spring Framework also supports OSGi.

A large number of other open source projects have announced support, or intent to support, OSGi including:

For further details please see the OSGi Alliance website.

following its incubation period, was formally submitted to OASIS in March 2007 for advancement through its open standards process.

SCA has huge enterprise software vendor industry support (over 20 vendors including IBM, Oracle (and BEA Systems), Red Hat and Sybase, and many others including Paremus). It is being organized via the OASIS Open Composite Services Architecture (Open CSA) Member Section and six Technical Committees have been established.

SCA is an industry standard way of describing how to create a composite application by defining which components are required and how they should be wired together. SCA is implementation neutral, neither protocol or application infrastructure is mandated, and it defines connectivity between composites using SCA bindings.

SCA uses SCDL (Service Component Definition Language), an XML-based description, to provide a structural description of the composite application. This can include the required application and infrastructure components, their configurations, and which SCA bindings to use. This loose coupling of components and bindings make it extremely flexible and adaptive. For example, to change two composites that communicate with each other via SOAP, to use JMS instead, one simply changes the relevant SOAP SCA bindings to the appropriate JMS SCA bindings.

Within the context of Infiniflow, SCA provides the equivalent of an architectural blueprint or a recipe - a way of describing an Infiniflow System in terms of its composites, the components that are used to create those composites, and how these entities are interconnected.

Using SCA, an Infiniflow System description need not only describe a composite application that is constrained to a local JVM runtime, it may also comprise of a number of components spanning many physical or virtual machines. The description can also include all of the required software infrastructure components; specific messaging, co-ordination, caching and transactional middleware services required by the Infiniflow System; and the associated SCA bindings for these components.

For further information on Service Component Architecture (SCA) please see the OSOA Collaboration website and the OASIS Open CSA SCA website.