1. 2 why osgi
There is no technology that is all-powerful, and any technology has its own context and best practices. Osgi is not just a technology; it is more a tool and methodology for system architecture, and using osgi in a non-applicable scenario or inappropriately using osgi in an applicable scenario creates a structure level gap for the system as a whole. Therefore, knowing when to use osgi is as important as learning how to use osgi。
The operating environment for each system is different, and the author does not want to answer questions like “when to use osgi” or “why to use osgi” with an empirical statement, but rather tries to allow the reader to think about why these scenarios apply to osgi by discussing several issues and weighing the trade-offs. If the reader had first approached osgi through the book, it might have been confused by the content of some of the discussions, and the author suggested that the first reading of the section should be done as much as possible, either in the full book or in preparation for the real use of osgi in the project。
1. 2. 1 does osgi make software development easier
It is undeniable that osgi's entry threshold is relatively high in java's many technologies, and that a relatively steep learning curve can create additional complexities for developers who use the osgi development system for the first time。
Osgi is composed of dozens of sub-codes and contains thousands of api interfaces for different purposes. The main reason why osgi norms appear so complex is that “modularization” itself has a lot of problems to solve. Modularization is not just about tearing the system apart into different blocks -- this is what jar packages can do, and true modularization must take into account a range of issues such as export, concealment, dependence, version management, life-cycle change and inter-module interaction in the module class。
Given the high complexity of osgi itself, “the introduction of osgi will make software development easier” in any case, it does not make sense that the use of osgi in small systems may lead to higher development costs. But it is not entirely wrong to say that, as the system evolves, the additional costs of osgi are not the main concern after both code volume and developers have reached a certain scale, and the main contradiction at this time is the contradiction between the expansion of software and the consequent expansion of complexity. As shown in figures 1-3, the larger the number of codes and the more people involved, the higher the complexity of the software, the positive correlation. This view is correct from a macro-level perspective, and in particular to a particular system, good architecture and design can effectively slow down this ratio. The efficiency advantages based on the osgi architecture will be demonstrated at this point: modularization promotes the design of autonomous codes to a certain extent, allowing developers to code efficiently with knowledge of the current module, and also facilitating the interlocking reaction of code problems. Osgi relies on the ability to describe and restrain, and compels developers to comply with structural constraints that allow developers to be “unfree” and become a powerful driver of development efficiency when the system becomes larger。
A more specific scenario could be used to discuss the above views and to analyse how the osgi architecture has an advantage in development efficiency. Experienced architects feel that it is very difficult to design a system architecture with “self-restraint”. The most common situation is that of the designer, which is not the product produced by the developers at the time of realization. Most software companies ensure that the code achieved by the developers is consistent with the designer's intent through “development process”, “coding code”, “test drive” and even “human proficiency”. This makes it difficult to ensure that future maintenance staff can continue to implement the original design ideas, even if they are developed in a way that is consistent with the design needs; as the development takes longer, the system may eventually become more and more different from the original design. In software engineering, this phenomenon is referred to as “structure corruption”. The architecture's “self-restraint capacity” means that it is consistent in the way different developers are performing their functions, preferably with the only way to follow the design's will and the other way to an end. More commonly, programmers are kept from writing bad codes as far as possible。
To give one of the most obvious examples, if developers use dao to operate the database directly on the web floor, or if dal takes context information directly from httpssession objects, such codes may escape the tester's black box test, but are clearly not consistent with the basic theory of software development. The former may cause data security problems by bypassing service configurations in the service layer; the latter limits access to such daos to web and cannot be reused and tested. If such a code appeared in the project, the author believed that the primary responsibility lay with the architect, since the architect did not distinguish between the layers of dependence, and if the web layer relied only on the service level jar package, the programmer could not reach dao, and if the pal layer did not rely on the servlet api jar package, it would be impossible for the programmer to access the subject of httpssession, a manifestation of the lack of self-restraint in the architecture。
I don't think any of the architects would have made such a naive mistake. However, the reality is far too complex, and even some problems are caused by the shortcomings of the java language itself. For example, reliance on a jar package means access to all types and resources in the jar package, since the content of the jar package is not divided between public, private and protected and does not limit what users can and cannot access. What's more complicated about introducing different versions of the same jar package? What if relying on the package requires dynamic change? One of the important purposes of using osgi is to remedy the shortcomings in the fine allocation of resources in java and to strengthen the self-restraint of the structure。
While osgi originates in embedded areas where small software dominates, in the java se/ee area, the advantage of modularization using osgi is greater for larger systems. There have been successful commercial examples of using osgi to control the growth in complexity of software and slow the corruption rate of architecture, such as eclipse marketplace, which already has thousands of plugins, developed by people from around the globe, with wide variations in technical levels, and the functions performed by the plugins, which osgi has made these plugins largely consistent with uniform structural constraints, and which generally do not affect the quality of eclipse as a whole because of deficiencies in a plugin。
1. 2. 2 does osgi make the system more stable
The authors have encountered many problems caused by the osgi framework, such as the typical classnotfundexception anomaly, the death lock for the type loader, or the outofmemory error problem in a dynamic environment, which are common in software development based on the osgi architecture. In this respect, the use of osgi does increase the risk of system instability, so one or two members of the team in the development process need to know more about osgi。
However, the stability of the software is not measured by the number of anomalies that may arise during the development phase, and the “stability” of the software should be the result of a multidimensional combination. In addition to concerns about the stability of the development phase, there is also a need to focus on the accumulation of stable re-use codes, the ability to isolate chain reactions when problems arise, and the ease of repairing deficiencies. Osgi can bring considerable benefits in these areas, such as:
Osgi will lead programmers to develop software that can accumulate reusable. We cannot require that the program be fully stable just after it was developed, but in the process it can be used as much as possible to enhance the quality of the program by using a stable code. It is known that log4j can be used for log-writing and that orm will introduce hibernate. Java has many open-source projects that have been tested in long-term practice and that have been proven to be stable. The common feature of these open-source projects is that they are well designed and can be easily used in other projects. In relative terms, many people did not notice the cumulative design of their own projects. A typical phenomenon is the emergence of “one-size-fits-all packages” in projects, usually called xxxcommmons. Jars, xxxutils. Jars, etc., which contain codes that have been called repeatedly in projects, but which cannot be called reusable packages. When the packages are growing in size, category and function, the closer the interface with the project, the less likely it is to be used in other projects. In an osgi environment, modules in the form of “mixed” are difficult to survive, and if a module has a very large number of dependent items, no one is willing to bear the cost of these indirect dependences in order to use a small number of them. The designer must therefore treat each module as a commercial product by scalable design of the module, carefully selecting the interfaces to be published and the dependence on its introduction, in order to accumulate reusable modules and also to improve programme stability。
Osgi-based systems are easier to achieve. An ordinary car breaks a tire, but even if one of the engines is damaged in the course of the flight, the aircraft is generally able to maintain normal flight. For software systems, stability is also reflected in the ability of a module to operate independently of other functions if a problem arises. Most systems do not have the chain reaction of isolation defects when problems arise in a certain part of the system. Imagine removing common logging (or slf4j) packages from the project you've done, so that the system can only lose log functionality and the rest of the system functions? However, in the case of osgi-based architecture development systems, modular autonomy and dynamication will naturally be taken into account in their design, and how to deal with a certain part when it is not available is a matter of every moment, and if the software follows the design principles of osgi at the development stage, it will naturally become a powerful system。
Dynamic repair of defects can be achieved in osgi environments. For many systems with down limits requiring 7x24 hours of operation, the dynamic capability of osgi is very useful when problems arise, so that a function can be added or banned, a module updated or even a unified, up-to-date modular warehouse can be built to allow the system to upgrade automatically without interruption。
The two questions raised in sections 1. 2. 1 and 1. 2. 2 can be summarized as whether osgi could improve development efficiency and software quality. Osgi's role in both is very closely related to the rationality of the software design, when osgi is a magnifying lever for the element of “design”, and better designed to be more stable, more efficient, and more problematic than bad design。
1. 2. 3 osgi will make the system work faster
The purpose of introducing osgi into the system may be many, but generally does not include addressing performance issues. If it's hard to say what osgi can do for performance, it's probably to allow users who have a “systemic brevity” to assemble their own systems. The glassfish v3. 0 server, for example, is based on the osgi structure and consists of more than 200 modules, which can be removed if no ejb or jms features are required to obtain a more streamlined server and save some memory. Overall, the osgi framework has a certain loss of systemic performance, and we discuss it both in terms of implementation and memory。
First, osgi was achieved on the java virtual machine, which was not supported by a virtual machine and was modularized entirely through the java code, inevitably with some wear and tear in its implementation. For example, the level of osgi load is much deeper than the normal java application, which means that more sub-loading assignments are required to find the required category. When called between two interdependent modules, death locks may be created by locking each other in a type loader; in order to avoid a dead lock, a serialized loading strategy with lost performance may sometimes have to be chosen. At the service level, dynamic (expressed in the fact that services may not be available at any time) determines the application of non-quenchable clients, which must be searched before each use, and this frequent visit to the osgi service register also entails some costs. The use of specific osgi services, such as http service, may result in some performance depletion as a result of the required bridges and relays, compared to the servlet directly deployed in the web container。
Second, in terms of memory usage, osgi allows different versions of package to exist simultaneously, which is an advantage, but objectively more memory will be occupied. For example, one library may require asm 3. 0 and another library used in the same application may require asm 2. 0, which usually requires a change of code, while in osgi only a fraction of the java method area memory is needed to resolve the problem. However, the improper use of osgi dynamics may result in the incorrect possession of an example of a class of expired modules (modules that have been updated or unmounted) which would prevent the category loaders from being recovered, thereby rendering all classes under the class loaders impossible to recover from gc。
From a performance point of view alone, it is true that osgi allows for a slight decline in the system, but this is entirely acceptable. The impact of performance should be taken into account in the use of osgi development, but should not be used as the main basis for decision-making on whether to adopt osgi structures。
1. 2. 4 does osgi support enterprise-level development
Regardless of the outcome of the discussion on whether “osgi can support enterprise-level development”, one must face the fact that the capacity of osgi to support enterprise-level development is growing rapidly. Since the establishment of the enterprise expert group of the osgi alliance in 2007, the direction of osgi has gradually shifted to the area of enterprise-level applications. Companies and organizations such as ibm, apache and eclipse foundations are becoming more mature at the enterprise level。
Prior to the emergence of the enterprise-level osgi, the enterprise-level development was either a heavy-weight route for java ee or a light-weight route for ssh. The introduction of corporate-level osgi has not served as a “revolutionary” role, has not pushed back what has accumulated in java ee or ssh, and osgi is more like playing the role of an “organizer” by transforming various enterprise-level technologies into its modules and services, so that former enterprise-level development techniques can still play a role in osgi。
All types of java ee technologies such as jdbc, jpa, jmx, jta and jndi, as well as the application of non-java ee-standards such as sca, sdo, in the osgi environment, are defined in osgi enterprise level guidelines, and these packaging level services can be mapped for use within osgi packagings. And so far, the content of corporate-level normative definitions has gone beyond mere normative texts, and many have focused on the framework for achieving osgi-level services (e. G. Apache aries)。
On the other hand, the blueprint container regulation of osgi harmonizes the dependence injection (di) approach that is almost always used in the java large program, allowing for seamless migration of the osgi module based on blueprint within different di frameworks. This norm is strongly supported by organizations such as apache, springsource, which have now issued a number of blueprinters (e. G. Apache geronimo and equinox virgo, the predecessor of springsource, springdm 2. 0). In the last two to three years, osgi at the enterprise level has become one of the main directions of the development of the java community, which can be described as a state of affairs。
However, when we use osgi at the enterprise level, we also have to realize that it is young, and that many of these advanced ideas may not have been taken into account at all, and that many of the problems are resolved by design constraints. As a result, the use of osgi can be problematic if it is a migration of legacy systems, or if design is already poor. In the most common case of data access, if the previous legacy system used orm to access the database and moved to osgi without a single module being drawn from the entity category, it would be difficult to configure the orm module, which would have to use equinox buddy or even dynamiciThis is a very ingenious way to solve it. Another problem is the cluster, where osgi has a pro-distributive remote service code, while osgi is dynamic in the case of the single java virtual machine, so it is necessary to do something on its own to maintain the osgi dynamic in the cluster environment。
