Turn: OSGi Introductory article: module layer

OSGi Introductory article: module layer

1 What is modularity

The module layer is the most basic part of the OSGi framework, where the modular nature of Java has been well implemented in this layer. However, this implementation is obviously different from some of the existing modularity features of Java itself. This article describes some of the basics of the module layer and some of the considerations that OSGi Alliance makes when designing the module layer. The OSGi standard has come to this day, not out of thin air, it is just to make up for some of the previous technology flaws.

Modularity is a common concept in computer science: "Breaking down a large system into smaller, more collaborative logical units by forcing the logical boundaries between the modules to improve the maintainability and encapsulation of the system."

The definition of a module in OSGi can be consulted:

This means that a module defines a logical boundary, which itself precisely controls which classes are completely encapsulated and which classes need to be exposed for external use. This allows us to easily shield the implementation from the inside of the module and expose the public API to the external part.

2 Why you need modular 2.1 OSGi and object-oriented linkages and differences

According to the above modular definition, some people may ask: "In the object-oriented, there is no support for the modularity?" "Yes, the object-oriented concept can be said to support modular programming to a certain extent, so why do you need the modularity features provided by OSGi?" This involves different granularity of the "logical boundary".

When writing object-oriented programs in Java, a person who understands the object-oriented concept does not plug all the functions into the same class, object-oriented lets you discover multiple things from the problem domain, and each thing is responsible for different functions, as much as possible for high cohesion and low coupling. Here, we can say that object-oriented modularity granularity is at the "class" level.
The modularity of OSGi, however, is to define which classes should expose which classes are hidden in the package by adding metadata to the jar package, and the granularity of its control visibility is at the level of the bundle (Jar package).

As a result, they are capable of ensuring high cohesion and low coupling by controlling visibility and usability, but with different granularity, one at the object level and one at the module level. Since the responsibility is different grain size, then the two do not conflict, each has its own role in the inside.

2.2 Limitations of Java in terms of modularity 2.2.1 underlying code visibility control

Java provides four levels of access control for private,public,protected and package private (no modifiers), but this only provides the underlying OO data encapsulation features. The concept of package is really a function of dividing code, but if the code in the package needs to be visible outside the package, it must be set to public (or protected, if it is inherited). In this case, there may be a problem:

First, let's take a look at the following example, which has three Java files:
Org.serc.helloworld.Hello.java: Defines an interface

package org.serc.helloworld; public interface Hello { void sayHello(); }

Org.serc.helloworld.impl.HelloImpl.java: The Hello interface is implemented

PackageOrg.Serc.HelloWorld.Impl;ImportOrg.Serc.HelloWorld.Hello;Public Class Helloimpl Implements Hello{Final StringHellostring;Public Helloimpl(StringHellostring){ This.Hellostring=Hellostring;}Public voidSayHello(){ System.Out.println(This.Hellostring);}}Org.Serc.HelloWorld.Main.Main.JavaPackageOrg.Serc.HelloWorld.Main;ImportOrg.Serc.HelloWorld.Hello;ImportOrg.Serc.HelloWorld.Helloimpl;Public Class Main{Final string Hellostring;public static void< Span class= "PLN" > Main (string[] Args hello Hello =  new helloimpl ("hello,serc! ");  Hello.               /span>                

}

These three files are in separate packages. It is helloimpl that this implementation detail should not be exposed to other packages, but from the main method of Main.java we can clearly see that in order to create an instance of Hello, we have to introduce the Helloimpl class, But Helloimpl as the implementation details of the interface, it should not be exposed to the user, which violates the principle of encapsulation, obviously not very good.

However, if we do not want to expose Helloimpl, we need to do extra work to ensure that "both the implementation details are hidden and the simple creation of an instance that implements the Hello interface." There are more than one way to do this (such as Factory mode), some of which are still very common today, but this adds extra work that is not relevant to the application itself, and it is a bit tedious to think that if you want to develop an application every time you have to do extra work to achieve the above purpose, So this can be said to be a major limitation of Java.

Limitations of 2.2.2 Classpath

When we add a jar package to the classpath, we simply give the file path, and the version and consistency of the jar package is what it depends on, and we cannot explicitly set it in Classpath or see these properties from the classpath.
And the jar packages in the classpath are loaded sequentially, for example:

Classpath=c:\servlet2.2\servlet.jar;c:\servlet2.3\servlet.jar,

So in the practical application, Java lets you use servlet2.2, not servlet2.3. In this case we can also see which version is used, if the large system in the development of the individual servlet package, and the version number is not the same, then in the final merger of the development results, the time of the use of which version of the servlet package is difficult to figure out, It is also said that the controllability is relatively strong.
Even if Classpath can notice the issue of the version, it cannot pinpoint the dependencies. Try to recall that you have been in the process of setting up the classpath: After you think that Classpath has been set up, you try to start the program, the result of the virtual machine throws an exception to tell you the lack of packets, and then you add the missing packages, and then start the program, This is repeated until the virtual machine does not run until the packet exception is missing.

2.3 OSGi improvements to these limitations

The limitations of Java mentioned in the previous section have been well addressed in OSGi.

• Package Visibility: OSGi improves the Java code access control mechanism by introducing a package visibility mechanism that gives full control over which modules are visible to the code in a package, not just the non-discriminatory visibility.
• Package version: OSGi by adding version information to the package, you can precisely control the dependencies of the Code, ensure the version consistency of the code, and compensate for the shortcomings of the classpath.

3 OSGi Module-Layer Foundation 3.1 bundle concept

This is the core concept of the module layer and is the representational representation of the concept of module in OSGi. Next you will create and use countless bundles in the world of OSGi.
What is bundle? --bundle is a modular physical unit in the form of a jar package that contains code, resource files and metadata (metadata), and the physical boundary of the jar package is also the wrapper boundary of the runtime logic module.

A more intuitive note: After adding some of the bundle's modular features to the standard jar package's manifest file (metadata mentioned earlier), the jar package becomes a bundle.
So with the description above, you might also think that the biggest difference between bundles and ordinary jar packages is metadata.

3.2 Using metadata to define bundles

The purpose of the bundle metadata is to accurately describe the modularity-related bundle features so that the OSGi framework can properly handle all the bundles (such as dependency parsing, forced encapsulation, etc.), which have these three parts:

• Readable information (optional): Helps to better understand and use bundles
• Bundle identifier (required): uniquely identifies a bundle
• Code visibility (required): Define internal and external code

3.2.1-Readable information

These can help people intuitively understand what this bundle does and where it comes from. The OSGi standard defines several metadata entries for this purpose, but none of the entries are required, and there is no effect on the modularity feature, which is completely ignored by the OSGi framework.
Here is an example of this type of information:

  bundle-name : SERC helloworld Bundle-vendor: Gr,< Span class= "PLN" > Sercbundle-docurl:< Span class= "PLN" > Http://elevenframework.org bundle-category: Examplebundle-copyright:  SERC               

Identifier of the 3.2.2 bundle

In the readable information mentioned in the previous section, some seem to be able to uniquely identify a bundle, such as bundle-name, but in fact, he is not used to identify a bundle. The early OSGi standard did not provide a way to identify a known bundle until the OSGi R4 standard "unique bundle identifier" was raised. For backwards compatibility, bundle-name cannot be used as an identifier, otherwise it will increase the work of maintaining backwards compatibility, so the new manifest attribute is Born: Bundle-symbolicname

Bundle-symbolicname:org.serc.helloworld
In contrast, Bundle-name is read to the user, and Bundle-symbolicname is read to the OSGi framework, allowing the OSGi framework to uniquely identify a Bundle.

Only one bundle-symbolicname is sure to uniquely identify a bundle, but over time your bundle may have a new version, and adding the version attribute will make your bundle's information more accurate.

  bundle-name : SERC helloworld Bundle-vendor: Gr,< Span class= "PLN" > Sercbundle-docurl:< Span class= "PLN" > Http://elevenframework.org bundle-category: Examplebundle-copyright:  SERC               

3.2.3 Code Visibility

If the jar package in the javase is placed inside the classpath, it is visible to all programs under this classpath, and this visibility cannot be changed, and the OSGi standard defines the following attributes to describe the visibility of the code:

• bundle-classpath-it defines where all the code that forms this bundle is located, similar to the concept of Java Classath, except that the ClassPath in Java is the location of the defined jar package, This attribute describes the path of the class within the bundle in the bundle. Here are some examples:

  Bundle-ClassPath:.,other-classes/,embedded.jar 

• Export-package-explicitly exposes code that needs to be shared with other bundles, separated by commas, and each package can use modifiers to decorate other features of the package.

    export-package : Org.. Hellworld; Vendor= "serc org.. Hellworld. Impl; Vendor= "gou Span class= "Typ" >rui "           

• import-package-defines the external code that the bundle relies on, in the same format as the Export-package, and can also use modifiers to decorate the package. The modifier here, however, is used to limit the scope of a dependent package, like a filter, rather than a feature used in Export-package to declare a package. For example, the following statement:

  Import-Package: org.serc.helloworld; vendor=”SERC”

4 Summary

Through this chapter, I hope that readers can have a preliminary understanding of the OSGi module layer, understand what this layer is focused on to solve some of the problems, and after this with the "OSGi development environment of the establishment and HelloWorld" chapter can try to create a bundle, Expose some packages by filling in the metadata in the manifest file to introduce some packages. In the next introductory article, we will explain the lifecycle layer of OSGi.

Turn: OSGi Introductory article: module layer