Osgi Architecture In Aem
Yufei Labbe
It is a continuation of the work done by the OSGi Alliance (formerly known as the Open Services Gateway initiative), which was an open standards organization for software founded in March 1999. The foundation originally specified and maintained the OSGi standard. The alliance transferred its work to the Eclipse Foundation at the end of 2020.[3]
The OSGi specification describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java or VM environments. It has a service-oriented architecture based on micro services each implemented as an extended Java class file archive (JAR (file format)).
OSGi is built around a service-oriented architecture. Applications or components, come in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot. Management of Java packages/classes is specified in great detail. Application life cycle management is implemented via APIs that enable remote downloading of management policies. The service registry enables bundles to detect the addition of new services or the removal of services, and adapt accordingly.
The OSGi specifications have evolved beyond the original focus of service gateways, and are now used in applications ranging from mobile phones to the open-source Eclipse IDE. Other application areas include automobiles, industrial automation, building automation, PDAs, grid computing, entertainment, fleet management and application servers.
In October 2020, the OSGi Alliance announced the transition of the standardization effort to the Eclipse Foundation, subsequent to which it would shut down.[4] All artifacts have been transferred to the Eclipse Foundation, where an OSGi Working Group" continues to maintain and evolve the specification.
The OSGi specification is developed by the members in an open process and made available to the public free of charge under the OSGi Specification License.[5] The OSGi Alliance has a compliance program that is open to members only. As of November 2010, there are seven certified OSGi framework implementations.[6] A separate page lists both certified and non-certified OSGi Specification Implementations, which include OSGi frameworks and other OSGi specifications.
OSGi is a Java framework for developing and deploying modular software programs and libraries. Each bundle is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (if any).
A bundle is a group of Java classes and additional resources equipped with a detailed manifest MANIFEST.MF file on all its contents, as well as additional services needed to give the included group of Java classes more sophisticated behaviors, to the extent of deeming the entire aggregate a component.
A 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 life cycle 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.
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.
Among its members are (as of February 2015[update]) more than 35 companies from quite different business areas, for example Adobe Systems, Deutsche Telekom, Hitachi, IBM, Liferay, Makewave, NEC, NTT, Oracle, Orange SA, ProSyst, Salesforce, Siemens, Software AG and TIBCO Software.[8]
The Alliance has a board of directors that provides the organization's overall governance. OSGi officers have various roles and responsibilities in supporting the alliance. Technical work is conducted within Expert Groups (EGs) chartered by the board of directors, and non-technical work is conducted in various working groups and committees. The technical work conducted within Expert Groups include developing specifications, reference implementations, and compliance tests. These Expert Groups have produced five major releases of the OSGi specifications (As of 2012[update]).
Apache Karaf is an OSGi-based runtime container for deploying and managing bundles. Apache Karaf also provides native operating system integration, and can be integrated into the operating system as a service so that the lifecycle is bound to the operating system.
The OSGi Alliance is an independent organization responsible for defining the features and capabilities of the OSGi Service Platform Release 4. The OSGi Service Platform is a set of open specifications that simplify building, deploying, and managing complex software applications.
OSGi provides the best runtime platform for Java, a superior class loading architecture, and a registry for services. Bundles can export services, run processes, and have their dependencies managed. Each bundle can have its requirements managed by the OSGi container.
JBoss Fuse uses Apache Felix as its default OSGi implementation. The framework layers form the container where you install bundles. The framework manages the installation and updating of bundles in a dynamic, scalable manner, and manages the dependencies between bundles and services.
An OSGi service is a Java class or service interface with service properties defined as name/value pairs. The service properties differentiate among service providers that provide services with the same service interface.
Each bundle can register multiple services in the service registry using the fully qualified name of its interface and its properties. Bundles use names and properties with LDAP syntax to query the service registry for services.
A bundle is responsible for runtime service dependency management activities including publication, discovery, and binding. Bundles can also adapt to changes resulting from the dynamic availability (arrival or departure) of the services that are bound to the bundle.
The OSGi framework provides an event notification mechanism so service requesters can receive notification events when changes in the service registry occur. These changes include the publication or retrieval of a particular service and when services are registered, modified, or unregistered.
When a bundle wants to use a service, it looks up the service and invokes the Java object as a normal Java call. Therefore, invocations on services are synchronous and occur in the same thread. You can use callbacks for more asynchronous processing. Parameters are passed as Java object references. No marshalling or intermediary canonical formats are required as with XML. OSGi provides solutions for the problem of services being unavailable.
The OSGi framework services are described in detail in separate chapters in the OSGi Service Platform Release 4 specification available from the release 4 download page on the OSGi Alliance web site.
In addition to the OSGi framework services, the OSGi Alliance defines a set of optional, standardized compendium services. The OSGi compendium services provide APIs for tasks such as logging and preferences. These services are described in the OSGi Service Platform, Service Compendium available from the release 4 download page on the OSGi Alliance Web site.
With OSGi, you modularize applications into bundles. Each bundle is a tightly coupled, dynamically loadable collection of classes, JARs, and configuration files that explicitly declare any external dependencies. In OSGi, a bundle is the primary deployment format. Bundles are applications that are packaged in JARs, and can be installed, started, stopped, updated, and removed.
A bundle is a JAR file with metadata in its OSGi manifest file. A bundle contains class files and, optionally, other resources and native libraries. You can explicitly declare which packages in the bundle are visible externally (exported packages) and which external packages a bundle requires (imported packages).
The module layer handles the packaging and sharing of Java packages between bundles and the hiding of packages from other bundles. The OSGi framework dynamically resolves dependencies among bundles. The framework performs bundle resolution to match imported and exported packages. It can also manage multiple versions of a deployed bundle.
I currently work for a customer, who already uses OSGi, as RCP and in a servlet container at backend side. They have really a lot of bundles and most of them are not really good in shape. Beside that no one really cares about their dependencies. This project is a good bad example for a modular monolith. Many developers in the teams dont care about OSGi at all. Its just there, they hate it, they don't really take profit of it. The whole team develops like in ordinary Java. And providing imports and exports is just a work, they don't really like.
I dont think, that this is only a result of just bad habbits. It really goes back to the company structure and culture. Non technical departments tend to spend money for their features not in technical improvements that are not obvious for customers. They often don't care about efficient development processes, well structured software architecture. This is something they expect from the development department, something that should already be there. But if it isn't, the technical dept, stay dept until the end of days until someone realizes that developers and business together create the product.
So, OSGi is overhead for many developers at this customer. And with Peters words: They have an ugly baby. But because it is already OSGi, its much easier to beautify it. But how to convince the developers, that they are on the right track. All they have to do is learn a little bit and try to understand whats happening inside OSGi. These discussions are in the end the hardest part.
64591212e2