OSGi Combat (1)-First osgi-what is Osgi__osgi

Currently, there are few learning resources or technical documents about OSGI technology in the industry. I searched for "OSGI" books in a certain treasure net, but the results were there, but the kind was poor and few people bought it.
I need to learn OSGi for the reason of my work, so I have to try my best to learn OSGi actively. I will learn the entire process of OSGi with a textual record, by organizing books and video tutorials, to make me more aware of this technology, but also to have a clear learning line for the comrades who need to learn the technology.

We need to solve a few problems:
1. How to correctly understand and recognize the OSGi technology.

We see the OSGi interpretation and definition from the foreign material or from the translated data, but the true meaning of OSGi is not necessarily the meaning of Chinese literal translation. The explanation of OSGi is the Open Service Gateway initiative, the literal translation is "the opening of the portal (Gateway) initialization", it sounds very puzzling, what is the service Portal initialization.

So we're not going to translate this osgi, we'll describe the OSGi technique in a different way.

Let's go back to some of our previous development scenarios, assuming we use the SSH (struts+spring+hibernate) framework to develop our web projects, we do product design and development is a modular, we split the purpose of the module is to achieve the "decoupling" between modules, The further purpose is to facilitate the control and management of a project.
After we modularize a project, we can give different modules to different developers to complete the development, then the project manager will put together the completed modules, and then assemble into a final product. Generally we develop this is the basic situation.

Then we develop the time is expected to be the function of the system, according to the system's function to carry out the division of the module, that is, the function of this product or customer needs is an important basis for division.

But we have to keep in touch with each other in the development process, such as a module to get some data from B module, and B module may call some methods in C module (except the common low-level tool class). So these modules are just a logical division.

The most important point is that we deploy the final project to a Tomcat or JBoss server. So when we start the server, can we close a module or function of the project? Obviously cannot do, once the server starts, all modules must start together, all need to occupy the server resources, therefore cannot close the module, assumes can forcibly take off, will affect other function.

These are some of the limitations of our traditional modular development.

We do software development has been the pursuit of a realm, is real "decoupling" and "separation" between modules, so that we will be more flexible in the management and development of software, even when the deployment of projects to customers can be more flexible and controllable. But we did not meet this requirement when we used architectural patterns such as the SSH framework for product development.

So we "architect" or the top of the technical experts are in the development of modularity efforts to explore and try, and then our OSGI technical specifications emerged.

Now our OSGi technology will suffice for what we have said before: complete separation in different modules, rather than logical separation, is a physical separation, that is, after the deployment can be run without stopping the server directly to take some modules down, the other modules are not affected by the function.

As a result, OSGi technology will become very important in the future, as it goes further than the SSH framework that is often used in implementing module decoupling. This technology in the future large-scale, high access, high concurrency Java Modular Development field, or project standardization management, will greatly exceed the status of SSH and other frameworks.

Some of the mainstream application servers, Oracle's WebLogic servers, IBM's Websphere,jboss, and Sun's GlassFish servers all provide a powerful support for OSGi, based on OSGi technology. With so many large vendors supporting the OSGi technology, we can see the importance of OSGi technology. So in the future, OSGi is a very important technology in the future.

However, OSGi still does not support the framework, because OSGi itself uses many of the basic controls of frameworks such as spring (because of the ability to implement AOP dependency injection), but which project does not rely on third-party jars.



2.OSGI technology is helpful to the development of our project.

(1) Project display
Next we have the project code to show the charm of OSGi:
We don't have to rush to understand how to use OSGi, so let's take a look at the effects of OSGi in one project first.
(The following engineering code is a sample of online teaching video, source code I here is not)
(in advance: we have to learn the key point is that our shopping site how to combine OSGi technology, making the project more flexible and controllable, and the shopping site itself is not the focus.) )


First of all, open our single server version of the project in Eclipse:

Startup success:

This is a Web project, we open the browser to look at the effect:

Can be seen as an online shopping project.

Let's take a look at what distinguishes our project based on OSGi technology from our general projects.
First, introduce the module of this project:

1. Large class display


2. Small class display (large category of sub products)

After that, it's the product's specific information.



3. Shopping Cart
It's empty to buy something:

After you have finished buying:



4. Commodity management (shelves, shelves)



As you can see, this project is no different from what we normally develop (I know the interface is very simple = =), the focus is its startup and loading process.


(2) about server
We started our project by dynamic loading, or "hot deployment". That is, after we put this project in the Web container, we can take some of the features down and take them off without affecting the other modules.

When we used to run Tomcat, we started the server, loaded the Web project one at a time, and the console appeared similar to this message:


But when we started this project, it wasn't like this:


So we're not using Tomcat and JBoss, which is how to deploy and launch Web projects. No Web server middleware is possible. Here we tell you, OSGi technology is embedded in a Web server, is jetty.

We open the Run Configuration Configuration window for this project and look at the plugins needed to run this project:

As you can see, there is a jetty in addition to the jar packages that some Web projects need. So the server used is jetty, no longer tomcat.


You may be more familiar with Tomcat, for Jetty is not too familiar, then we briefly introduce jetty:
Jetty is also a relatively good web container, with some performance aspects more powerful than tomcat (such as high concurrency, long connections). And its entire structure is much lighter than Tomcat (Tomcat is more bloated), the specific difference you can go to the Internet to see for themselves.


(3) operation mode and plugin
Let's take a formal look at this project's operating mode under OSGi:
When we started, we loaded four modules, respectively:

According to the modular thinking they are four corresponding functional modules.
The engineering code of their corresponding four functional modules can be seen in eclipse:



Let's take a look at our startup configuration (still open is the Run Configuration Configuration window):

The

configuration is divided into "WorkSpace" and "Target Platform", which are plug-ins for our workspace (our own project modules and tool classes), and Plug-ins for running platforms (some of which depend on the jar's configuration), which will work correctly when we start our project.

After we start the project, we enter the directive "SS" at the console, and we will have all of our loaded Plug-ins running:


When it starts, it loads the eclipse's OSGi plug-in first (eclipse itself is also a container of OSGi) :

We open our Eclipse installation directory and then find the Plugins folder, where you can see all of Eclipse's plugins:

You can see a folder-style plug-in with a jar in it.

How do we understand plug-ins? A
plug-in is actually a jar package that is managed and configured by a development tool or an OSGI container.  

We randomly open a folder type of plug-in, you can see:

You can see inside in addition to Lib there are other things, and then have a "Osgi-inf" folder. And whatever it is, it's enough to show that our eclipse is an OSGi container.

(4) Hot-deploy and hot-start
Let's get back to the point where we start, we don't stop, and then we stop one of the modules:

If we want to stop the Admin module:

Which is to stop the plugin with ID 22

Result:

Then refresh our website homepage:

found that our "admin" module was gone!

The disappearance of this module is not a JavaScript technology, but a server technology that we unload dynamically from within the server.

After our management module is removed, the other features of the site are unaffected. At this point our server did not make any pause or shutdown.

We'll stop the "Shopping cart" module:

Effect:

Other modules are still unaffected.

We shut down two modules, now enter SS to look at the operation of all plug-ins and modules:

We can see that our two modules are in the resolved state, which is the state to be resolved.

Of course, we can also deploy our modules in the server's open state:
If we start the shopping cart module:


Found the shopping cart back:


This is called hot deployment, that is, after the project has been placed in a Web container, we can take some of the functionality to it, and take it down without affecting other modules.


Through the shopping website This project lets everybody truly feel the OSGi this technology in the project development and the management some powerful functions.

To learn more about OSGi, you can view future summary articles.

Reprint please indicate the source: http://blog.csdn.net/acmman/article/details/50848595