Open Source Gateway Initiative[OSGi] - A Middleware Revolution!

Finally,world realizes the true purpose of Object Orientation - the Re-Usability and today any software development largely consists of adapting existing functionality to perform in a new environment,since large number of standard, well-tested building blocks have become readily available from various vendors.

Now, the core problem is, integration of many different libraries-(building blocks)as these libraries have become complex and require their own libraries to function --even if that functionality is never needed for the product.

This propels the need for tools/frameworks/specifications that standardize the integration aspects of software so that reusing existing components becomes reliable, robust and cheap.

There comes our OSGi!!!!!!!!!!!!!!

So what is OSGi?

A nonprofit organization-founded in March 1999- comprises of IBM,Ericsson,Nortel,Sybase,Sun,France Telecom,Motorola and Phillips that promotes an open dynamic component platform.

The objective of this Alliance is : "How to let applications from different vendors work reliably together and share resources in an embedded/network computer"

OSGi specifies JVM - (now only Java)- based service platform - so that software components/applications/modules/bundles can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot;

Why JVM as Platform
Without any doubts, JVM is evovling as unanimous platform going forward for multi-layered, multi-faceted enterprise applications. Not only Java,but there are many other languages evovling on JVM [Current JVM Languages - PHP,Scala,Groovy,Ruby,Python]and certainly the list is growing day-by-day.

Speficiation - Overview

OSGi technology is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.

The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.

OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces maintenance costs and enables unique new aftermarket opportunities because components can be dynamically delivered to devices in the field.

Framework

The core component of the OSGi Specifications is the OSGi Framework. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers.

L0: Execution Environment
L1: Modules
L2: Life Cycle Management
L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.

The L0 Execution environment is the specification of the Java environment. Java 2 Configurations and Profiles, like J2SE, CDC, CLDC, MIDP etc. are all valid execution environments. The OSGi platform has also standardized an execution environment based on Foundation Profile and a smaller variation that specifies the minimum requirements on an execution environment to be useful for OSGi bundles.

The L1 Modules layer defines the class loading policies. The OSGi Framework is a powerful and rigidly specified class-loading model. It is based on top of Java but adds modularization. In Java, there is normally a single classpath that contains all the classes and resources. The OSGi Modules layer adds private classes for a module as well as controlled linking between modules. The module layer is fully integrated with the security architecture, enabling the option to deploy closed systems, walled gardens, or completely user managed systems at the discretion of the manufacturer.

The L2 Life Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled. Bundles rely on the module layer for class loading but add an API to manage the modules in run time. The lifecycle layer introduces dynamics that are normally not part of an application. Extensive dependency mechanisms are used to assure the correct operation of the environment. Life cycle operations are fully protected with the security architecture, making it virtually impossible to be attacked by viruses.

The L3 layer adds a Service Registry. The service registry provides a cooperation model for bundles that takes the dynamics into account. Bundles can cooperate via traditional class sharing but class sharing is not very compatible with dynamically installing and uninstalling code. The service registry provides a comprehensive model to share objects between bundles. A number of events are defined to handle the coming and going of services. Services are just Java objects that can represent anything. Many services are server-like objects, like an HTTP server, while other services represent an object in the real world, for example a Bluetooth phone that is nearby. The service model is fully security instrumented. The service security model provides an elegant way to secure the communication between bundles passes.

Security
Security is based on Java and the Java 2 security model. The language by design limits many possible constructs. For example, buffer overflows used in viruses are impossible. Access modifiers in the language restrict the visibility of the code to other programmers. The OSGi platform extends this model by allowing private classes, a mechanism that is not available in a standard way in Java. The Java 2 security model provides a comprehensive model to check access by code to resources. The OSGi platform adds full dynamic management of the permissions, simplifying the life of operators and system administrators.

It Is SOA!
On top of the Framework, the OSGi Alliance has specified many services. Services are specified by a Java interface. Bundles can implement this interface and register the service with the Service Registry. Clients of the service can find it in the registry, or react to it when it appears or disappears.

This is similar to the service-oriented architecture made popular with web services. The key difference between web services and OSGi services is that web services always require some transport layer, which makes it thousands times slower than OSGi services that use direct method invocations. Also, OSGi components can directly react on the appearance and disappearance of services.

Examples:

Http Service
The Http Service is, among other things, a servlet runner. Bundles can provide servlets, which becomes available over the Http protocol. The dynamic update facility of the OSGi Service Platform makes the Http Service a very attractive web server that can be updated with new servlets, remotely if necessary, without requiring a restart.


Active participants:
Apache iFelix, iPojo, Spring - OSGi, Eclipse - Equinox


Whats new on OSGi-Release 4:

Powerful new modularization capabilities providing enhanced encapsulation of networked services that can share a single VM.

Modularized class sharing and hiding of implementation details.
Advanced handling of multiple versions of the same classes so old and new applications can execute within the same VM.

Localization of OSGi bundle manifests enabling service deployment anywhere.

Enhancements in security and policies: The new Conditional Permission Admin service provides an elegant and simple way to manage networked services securely. It also supports dynamic policies that can depend on external (custom) conditions. Combined with R4 support for digital signatures, this provides a central security solution to large deployments of products using the OSGi Service Platform.

A Declarative Services specification that addresses memory footprint issues that can prevent small embedded devices from using a service oriented architecture to support multiple applications. Additionally, it significantly simplifies the service-oriented programming model by declaratively handling the dynamics of services.

Compatibility with Release 3, requiring no changes for existing OSGi bundles, applications, or services.

Future is here...
The OSGi specifications are so widely applicable because the platform is a small layer that allows multiple Java™ based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse and cooperate, unlike other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.

The presence of OSGi technology-based middleware in many different industries creates a large software market for OSGi software components. The rigid definition of the OSGi Service Platform enables components that can run on a variety of devices, from very small to very big.

Adoption of the OSGi specifications can therefore reduce software development costs as well as provide new business opportunities.


Courtesy : ACM Queue Jan-Feb 2008 , Wiki

Whats Hot on J2EE design?

Below link describes the best architecure available for J2EE systems today

http://cwiki.apache.org/S2WIKI/struts-2-spring-2-jpa-ajax.html

Design Patterns - FAQ

http://en.wikipedia.org/wiki/Design_Patterns

As per GOF (Gang of Four),the total is :23 and they are classified as below. Classification :Creational(5),Structural(7),Behavioral(11)

Creational Patterns
--- Abstract Factory
--- Builder
--- Factory Method
--- Prototype
--- Singleton
Structural Patterns
--- Adapter
--- Bridge
--- Composite
--- Decorator
--- Façade
--- Flyweight
--- Proxy
Behavioral Patterns
--- Chain of Responsibility
--- Command
--- Interpreter
--- Iterator
--- Mediator
--- Memento
--- Observer
--- State
--- Strategy
--- Template Method
--- Visitor
J2EE Patterns
--- MVC
--- Business Delegate
--- Composite Entity
--- Data Access Object
--- Front Controller
--- Intercepting Filter
--- Service Locator
--- Transfer Object
Misc
--- typesafe enum