GlassFish Osgi-javaee (II.)

Deep understanding of OSGi Web application specifications and GlassFish osgi/web containers

Related articles: GlassFish osgi-javaee (i) GlassFish and enterprise-class OSGi development

Http://www.bianceng.cnhttp://www.bianceng.cn/Programming/Java/201312/38601.htm

In Part1, we mentioned that Enterprise OSGi has developed a set of specifications for integration with Java EE, where the most representative specification is the OSGi Web Application specification, which leads to an in-depth understanding of OSGi Web application specifications and GlassFish osgi/ Web container. This article will be divided into the following sections:

Understanding OSGi Web Application Specifications

Building an OSGi Web application

Deploying an OSGi Web application using GlassFish 4

Deep analysis of GlassFish osgi/web containers

Thinking

Understanding OSGi Web Application Specifications

Why do I need OSGi WEB

With the development of information and networks today, Web applications have become popular and pervasive, with some mission-critical (mission-critical) Web applications running at a high load every day, with little disruption because a casual outage can result in a massive loss of data, And the loss of large sums of money has serious consequences. These mission-critical web applications often appear in related financial sectors such as securities and equities. Now, let's start thinking about a scenario where a Web application's client or provider wants to add some new modules or features to the Web front-end in a few weeks or months or even years, but we can't stop web apps to add these new modules. And you don't want to refactor or change the existing architecture and modules of the Web application again. This sounds incredible, at least for such a scenario, you should stop the instance of the application service. However, the customer will not agree. On the other hand, in today's big data age, there is a lot of data coming into our application every second. So, how do you solve such a scenario?

A workable answer is to use the OSGi Web to build our applications.

The core of Wab-osgi web

Simply put, the OSGi Web Application Specification (chapter 128 in the OSGi Enterprise Release 5 specification[1]) defines the entire contents of the OSGi Web. For OSGi Web applications, typically, it consists of a Web application Bundle (that is, Web application Bundle, called WAB).

So first we need to understand the difference between WAB and war.

WAB Brief Introduction

In Part1, we have mentioned that bundle is the basic deployment and management entity in OSGi. So, first of all, WAB is a Bundle that must provide OSGi metadata that becomes Bundle (e.g., Bundle-symbolicname, bundle-version ...), and second, WAB, like the war in Java EE, Still serving Web applications and being able to use servlet 2.5 or later servlet specifications, WAB must contain accessible Web content, specifically, Java The servlet specification defines the structure of a Web application and defines a jar-based file format (war) that WAB must contain static and dynamic content in the WAR.

Further, to become a WAB, it is necessary to describe its dependencies by import-package in the MANIFEST.MF file, for example: By importing Javax.servlet to use the functionality of the servlet, and if you need to provide services to the outside world, it also uses export-package to export the package where the service resides.

We can install WAB in different ways, for example, by invoking the command line console provided by an application server that supports enterprise OSGi (e.g., the GlassFish Admin CLI), or by calling the OSGi underlying API programmatically to install the WAB (e.g., Bundlecontext.installbundle). Either way, when WAB is installed, its lifecycle management is like the other bundle of OSGi runtime. Only the WAB lifecycle is tracked by a Web extender, and once WAB prepares a service Web request, the Web extender needs to deploy the Web content that is accessible in WAB to the Web runtime. When WAB no longer serves Web requests later, the Web Extender also needs to uninstall these accessible Web content from the Web runtime.

With regard to the installation of WAB, it is important to note that a Web application can be packaged into WAB and then installed in the development phase by means of a tool (for example, the MAVEN plug-in), or that the Web application can be used at the bundle installation stage via a Web URL Handler transforms the standard war to transparently create WAB. GlassFish 4 has implemented the latter mechanism, which I will elaborate on later chapters.

About Web Extender and web URL Handler, they are all part of the OSGi Web container, which we'll elaborate on later in this chapter.

From the above description, we have seen the obvious difference between installing WAB and installing ordinary bundle: In addition to installing WAB to OSGi Runtime, you also need to deploy the Web content that is accessible in WAB to the Web runtime. In this connection, the OSGi Web Application specification defines the lifecycle state diagram of the WAB,

Graph 1:wab life cycle state diagram

Excerpt from: OSGi Enterprise Release 5 specification

We'll delve into each of the phases in Figure 1 in a later chapter.

WAB definition

The WAB itself is an OSGi Bundle, so the definition of standard OSGi Bundle is also applicable to WAB, but the difference between WAB and standard OSGi Bundle is: WAB needs to define the Web-contextpath attribute in MANIFEST.MF. The Web-contextpath property defines the contextual path (context path) [2] accessed by this Web application, and on the Web server, all accessible resources in this Web application are relative to this context path. For example, if the following Web-contextpath properties are defined in MANIFEST.MF,

Web-contextpath:/uas

The URL to access this WEB application is always relative to Http://host:port/uas, and note that the value of the Web-contextpath property always starts with a slash '/'.

When WAB is installed, unless the Web-contextpath property appears in MANIFEST.MF and the Web-contextpath value is a valid value, Web Extender considers this to be not a WAB, but as an ordinary bundle.