Shulou(Shulou.com)06/02 Report--

What this article shares to you is about the comprehensive summary of OSGi and the example of WebSphere application. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

In order to solve the problem of version conflicts encountered in real engineering, I studied OSGi technology. To this end, I searched the Internet for a lot of articles about OSGi, but in the end, I found that few people could clearly explain the origin of OSGi and the most essential features of OSGi, until I found Neil Bartlett's OSGi In Practice. It makes it clear that OSGi is the best way to solve version conflicts in Java projects by understanding the nature of OSGi. This is determined by the nature of OSGi, which is why large Java software products have begun to adopt the OSGi framework. Java has an inherent defect, and OSGi makes up for it. Then I spent a lot of time studying how WebSphere Application Server supports OSGi, and finally successfully made my application support OSGi, thus solving the problem of version conflict.

The Origin of OSGi

With the development and change of technology and requirements, the software is becoming larger and larger. In this way, the biggest challenge is that the design of the software becomes more and more complex and the maintenance becomes more and more difficult. To solve this problem, the software architect splits the software into smaller modules that are easy to understand. So what benefits will software modularization bring to us?

Split manpower: after modularizing the software, we can assign independent teams to deal with independent modules, thus breaking up the manpower. This is not only easy to manage, but also reduce the complexity of the whole software design. Because each independent team can concentrate on designing and implementing its module without having to consider the complexity of the entire software.

Abstraction: after modularizing the software, we abstract the whole software into a multi-layer, multi-module integration. This makes the whole software easy to understand and easy to manage.

Reuse: after modularizing the software, each module has its own independent function and package. In this way, this module can be reused in many places (and even in other software in the future), thus saving manpower.

Easy to maintain: after modularizing the software, when there is a problem with the software, we can easily locate the problem in that module, and each module is relatively small and easy to understand, thus reducing the difficulty of software maintenance.

Based on the above four advantages, in the current software design, software modularization is the mainstream idea of software architects. In order to realize software modularization, the object-oriented high-level programming language arises at the historic moment, and Java is a typical representative of it. Java wraps Java classes and other resource files with its unique Jar format files, so that software components can be packaged into separate Jar files. These Jar files can depend on each other and complete the same work together, thus realizing the modularization of the software. But Java can't really bring us the four advantages of software modularization. Why? To explain this problem, we need to know the definition of the module.

What is a module?

A module should have the following three features:

Self-contained: a module should be a whole of business logic. It should be moved, installed, and uninstalled as a separate whole. A module is not an atomic body, it can contain many smaller parts, but these parts cannot exist independently.

High cohesion: a module should not do many irrelevant things, it should focus on the goal of 1 business logic and try its best to achieve this goal.

Low coupling: one module should not focus on the internal implementation of other modules. Loose connections allow us to change a particular module without affecting other modules.

However, the Jar file of Java language can not perfectly implement the three features of a module, it will mainly encounter the following three problems:

For a Jar file, there is no concept of a corresponding Java runtime. Jar files make sense only at development and deployment time, while in JVM, the contents of all Jar files are simply linked together as a separate global list, which is called "Classpath". This kind of load mode makes Jar files invisible at run time.

The Jar file does not have standard metadata information to indicate the list of externally dependent files required by the Jar file, so it is not clear that the Jar file needs to work with other Jar files. In addition, the current Jar file does not have version information, so multiple versions of the same Jar file cannot be loaded at the same time.

Java has no mechanism to hide information in different Jar files.

These three problems make the Jar file do not do well in the two characteristics of "self-inclusion" and "low coupling" of the module, so that Java does not perform well in the advantages of "split manpower" and "easy maintenance" of the module, while the second problem is more serious, which makes the version conflict of Java application software difficult to deal with.

For the sake of security, the Java language's class loader (note that it is not class loading) is multi-layered and uses a parent delegate mechanism for class loading. Also, when the same class loader loads the class file, JVM loads the first discovered class. So when the new and old versions of the same class are encapsulated in two different jar files (such as ClassVersion2.jar and ClassVersion1.jar), and the two jar files are in the class loading path of JVM, the classes in the first loaded Jar file will be used. However, due to the long-time update and maintenance of Java applications, multiple versions of the same module co-exist everywhere, which will lead to the problem of version conflict. For example, there is a module ThirdComponent in the Java application that relies on the ClassVersion module and must work with the old version of the ClassVersion module (ClassVersion1.jar). When the new ClassVersion module (ClassVersion2.jar) is upgraded to the software, the ThirdComponent module will probably not work, because the classloader will most likely load ClassVersion2.jar instead of ClassVersion1.jar first. In fact, the root cause of this problem is that Java's Jar files do not do a good job of self-inclusion. Jar files only play a role in the encapsulation of the software, but in the run time of JVM, Java only cares about classes and ignores Jar, which makes the class loading of Java become planar linear rather than three-dimensional mesh.

In order to solve the problems in the modularization of Java, the OSGi module system appeared. OSGi, developed on top of Java, provides a way to build modular Java applications and defines how these modules interact with each other at run time.

The most essential characteristics of OSGi

OSGi is a standard jointly defined by an alliance of about 40 companies. According to this standard, there are currently four independently implemented OSGi frameworks, they are:

Equinox: this OSGi framework is currently the most widely used OSGi framework. It was developed by IBM and has been applied to Eclipse,Lotus Notes,IBM WebSphere Application Server and so on. Equinox implements the OSGi specification version 4.1.

Felix: this OSGi framework implements the version 4.x OSGi specification, which is developed and maintained by Apache.

Knopflerfish: this is a popular and mature OSGi framework that implements the OSGi specification of versions 3 and 4.1. It is developed and maintained by Makewave AB.

Concierge: this OSGi framework implements the version 3 OSGi specification.

The two most frequently asked questions about the name OSGi are what does OSGi stand for? Why is I lowercase?

The authoritative answer to these two questions is: officially, OSGi does not represent anything. However, generally speaking, OSGi stands for "Open Service Gateway initiative." and the lowercase letter "I" comes from the word "initiative".

As for the central idea of OSGi, it is very simple. The root of the problem of traditional Java software is the global flat class loading path (Classpath), so OSGi adopts a completely different class loading mechanism, that is, each module has its own independent class loading path. This solves almost all the problems encountered in the modularization of traditional Java, but a new problem arises, and the modules in the software have to work together, which means that there is class sharing between different modules (otherwise, how can one module be called to another module)? if each module has a class loading path, how to solve the class sharing between modules? To solve this problem, OSGi defines a special and complete class sharing mechanism. OSGi will use the displayed import and export mechanism to control class sharing between modules.

In OSGi, the module is given another name, bundle. In fact, OSGi's bundle is a Java's Jar file. OSGi does not define a new standard to encapsulate Java classes and other resource files, and standard Jar files work well in Java applications. In the OSGi system, only some new metadata information is added to the Jar file, which turns the Jar file into a bundle in the OSGi system. So what kind of metadata information has been added?

The name of Bundle. OSGi provides a "symbolic" name as the unique identifier for this bundle.

Version information of the Bundle.

List of Import and export. From this list, we can clearly see that the OSGi bundle needs to import and export the classes of those packages. The imported package is the external resource that this bundle needs to use, and the exported package is the resource in this bundle that other bundle can use.

The smallest version of Java that Bundle needs to run. This information is optional.

A wide variety of other human-readable information, such as the provider of this bundle, copyright statement, contact address, etc.

This metadata information is placed in the MANIFEST.MF file of the Jar file, which is part of each standard Jar file. One advantage of using a standard Jar file as OSGi bundle is that bundle can be used anywhere a Jar file can appear, because bundle is a pure Jar file. When a bundle is used outside the OSGi runtime, this extra metadata information is simply ignored by the Java runtime, so bundle is forward compatible. So besides this, what other benefits does OSGi's bundle bring to us?

What does it mean to provide a class load path for each bundle? To put it simply, we provide a class loader for each bundle, and the class loader can see the classes and other resource files in the bundle file. However, in order to achieve the purpose of multiple bundle working together, between OSGi class loaders, class loading requests can be delegated from one bundle class loader to another bundle class loader. Recall that in standard Java and J2EE, the classloader is a tree structure, and the classloader request is always delegated upward to the parent of each classloader. The class loading mechanism does not allow class loading delegates between horizontal tree nodes. In order for a class library to be seen by multiple branches of the class loader tree, we need to push the class library to the common ancestor node of these branches. In this way, this version of the class library will be seen by all the nodes on these branches, whether or not these nodes want to see this version of the class library. Figure 1 is a typical J2EE classloader hierarchy that shows why class libraries keep pushing up.

Figure 1. Typical J2EE class loader hierarchy

And the tree structure is not what we need, what we really need is the network structure. The dependency between the two components is not a simple superior-subordinate relationship, but a network relationship between the provider and the consumer. The load request for a class is delegated from one bundle classloader to another bundle classloader, which is based on this network of dependencies between bundle. Figure 2 gives us an example of a reticular dependency between bundle in OSGi.

Figure 2. Reticular dependency between bundle in OSGi

In OSGi, the dependency between bundle is determined by the displayed list of import and export class packages. For example, bundle B in figure 2 contains a class package named com.ibm.bundle.b.somePackage. Bundle b can choose to export this class package in its MANIFEST.MF file. Bundle A can also choose to import the class package com.ibm.bundle.b.somePackage in its MANIFEST.MF file. Then in the OSGi runtime, the OSGi framework will be responsible for matching the import and export lists of different bundle. This matching process is called the OSGi resolution process (resolution process). The resolution process of OSGi is quite complex, but this process is implemented by the OSGi framework, and each bundle does not need to care about it. Each bundle only needs to write some simple import and export declaration statements in its own MANIFEST.MF file. Once the OSGi framework matches the class package com.ibm.bundle.b.somePackage in bundle A's import list with the class package com.ibm.bundle.b.somePackage in bundle B's export list, the two bundle will be connected, which means that when bundle A needs to load a class in any class package com.ibm.bundle.b.somePackage, the class load request will be delegated to bundle B's class loader, and bundle B's class loader will load that class And pass the class instance to bundle A. Because bundle A relies on bundle B and bundle C, if all the class packages in the bundle An import list can be found in the export list of bundle B and bundle C, then bundle A will be called a resolution success and it will enter a resolved state (resolved). If some of the class packages needed in bundle A's import list are not found in bundle B and bundle C's export list, then bundle A's resolution will not be successful and bundle A will not be used and started. Thus, in OSGi, the dependency between bundle is determined by the list of import and export displayed.

Hides the information in bundle.

Because in OSGi, the dependency between bundle is determined by the displayed list of import and export, there is no need to export all the class packages in a bundle, which can hide the information in bundle. In OSGi, only those class packages that are displayed in export can be used by other bundle import.

Version control has been added and multiple versions are allowed to coexist.

Not only does OSGi make bundle interdependent by class package names, it can also add version information to class packages. This is the problem that we can cope with the version change of bundle. Export class packages can also carry a version information, while import can refer to all class packages within a version, which allows our bundle to rely on all class packages within a version. So in OSGi, multiple versions of the same bundle can exist at the same time. In the third chapter of this article, I will explain in detail how OSGi allows multiple versions of the same bundle to exist in parallel, thus serving the problem of version conflicts of components in Java applications.

Explain how OSGi overcomes version conflicts

The reason why OSGi can solve the problem of version conflict of components in Java application software is the mesh class loader of OSGi and the version information control of OSGi bundle. Why would you say that?

OSGi's mesh classloader architecture allows each OSGi bundle to have a separate classloader, while bundle is just a standard Jar file. In this way, we can create multiple different Jar files for different versions of the same bundle. The actual contents of these Jar files can be exactly the same, but the file names can be different (even the file names can be the same, because in the OSGi framework, the combination of the bundle name and version is the unique identifier). Therefore, these Jar files, in the view of the OSGi framework, are different bundle, so different versions of the same component can be loaded into JVM at the same time, which solves the problem of coexistence of different versions of the same component in Java application software, and then as long as the problem of version identification is solved, then the problem of version conflict of components in Java application software will be removed by customer service.

OSGi adds version control information to distinguish different versions of the same bundle, and the combination of bundle name and bundle version in the OSGi framework is the unique identifier of this bundle, so through the version control of bundle, different versions of the same bundle can be distinguished, and the direct dependency of bundle can also be limited by version, which can perfectly solve the problem of version conflict of components in Java application software.

So how does OSGi version control?

OSGi adds a version information for each bundle by adding the Bundle-Version attribute in the MANIFEST.MF file, and this version information must strictly follow the format of: 3 digital field + 1 character field. 6.2.0.beta_3 is a typical valid bundle version information. The first three numeric fields are known as the major version, the minor version and the microversion, and the last letter field is the correction section. When any of the first three fields have no value, OSGi will implicitly pay 0 to this field, so version 1 is the same as 1.0,1.0.0. If no version is specified for bundle, 0.0.0 will be considered to be the version information for that bundle.

In addition, in OSGi, versions are compared from front to back. If the first numeric field is different when comparing versions, then the next three fields do not need to be compared, because the previous version of OSGi is the sum of all the subsequent field values, so when the larger version is different, the later smaller version does not need to be compared, for example: 2.0.0 is greater than 1.999.999. If the version information of the two bundle is the same in the first three numeric fields, OSGi will compare the last letter field. The last letter segment can contain uppercase or lowercase letters A to Z, numbers, hyphens, and underscores, so it is more complex. OSGi uses the algorithm of the compareTo () method of the standard Java String class to compare, while the compareTo () method of the standard Java String class compares each letter of the correction segment sequentially until there is a difference. In addition, if the letters are the same, then the value of the short correction segment will be considered less than the long correction segment, and the beta_01 will be smaller than the beta_010.

Finally, it is important to mention that OSGi can specify not only a version information for bundle, but also a version information for each class package, that is, bundle version control can be achieved at the class package level (and this is the recommended OSGi version control method). When bundle is in the export class package, the user can specify a version information for each class package. When bundle needs to import a specific version of the class package, users can specify not only a specific version information, but also a range of version information. For this range, square brackets "[" and parentheses "(") can be used as boundaries. Square brackets "[" means that the boundary value is also within the range, while parentheses "(" is the opposite. For example, [1. 0. 0. 0. 0. 0) represents all small versions from version 1. 0. 0 to 2. 0. 0. 0 is not within this range. Here are some examples of further scope lists, where x represents a valid range list in Table 1 below:

Table 1. Example of version range

Sample version range [1.2.3 dint 4.5.6) 1.2.3

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.