Osgi.net Study Notes-Application

about Osgi.net, presumably we have heard that the following is their own in the process of learning osgi.net the content, for everyone to learn to participate in the use. 1. osgi.net with the Uiosp

OSGi is a The abbreviation for Open Service Gateway Initiative is defined by the wiki as: on the one hand it refers to the OSGi Alliance organization, which is an OSGi Alliance group of International IT giants such as IBM, Oracle, BEA, SAP, etc. , on the other hand, refers to a Java-language-based service specification (--OSGI service Platform) developed by the organization. The OSGi service platform is a dynamic, modular framework that supports modularity and plug-ins, hot-swappable and dynamic features, support for SOA, support for module extensions, and security support.

The osgi.net plug-in framework provides modular and plug-in, service-oriented architecture, and module extensions for the console, WinForm, Windows Services, WPF, ASP. NET and mobile platforms, and any. NET application environment.

The osgi.net is a service specification ported to the. NET platform by the OSGi specification. Uiosp is a XAUI Open service Platform abbreviation, namely haiyou Open Services Platform , it is the implementation of osgi.net specification, provided by Xi ' an Haiyou Information Technology Co., Ltd. UIOSP full implementation of the OSGI specification porting, providing modular and plug-in, service-oriented architecture support, module extensible support three major functions. UIOSP improves the various operating environments that support console applications, Windows Service Applications, Windows Forms applications, WPF applications, and ASP. NET applications, and supports Windows Mobile.

This article will give you an experience using Visual Studio.NET SP1 + SQL Server 2005 Express how to build an ASP. NET plugin Application step-by-step based on UIOSP. Currently UIOSP supports the VS2005 sp1+/vs2008+/vs2010+ development environment and supports the. NET Framework 2.0

1.1osgi.net plug-in program structure:

The application architecture based on the Osgi.net plug-in framework is shown. Here, the application consists of the main program and the plug-in. The main program is the entrance to the specific application environment, which is used to launch the Osgi.net plugin framework and enter the entry point exposed by the plugin framework, and the application plug-in is the business module that implements the different functions of the software.

1.2 Osgi.net Plugin Framework Benefits:

1. Open, standardized, unified: modules that conform to the specification can be loaded by the Osgi.net plug-in framework.
2. Rapid Integration: The module is placed in the plug-in module to achieve functional integration.
3. Highly reusable: It can be reused only by copying, without modifying any code.
4. Hot Swap and Dynamics: Each module can be dynamically installed, started, stopped, and uninstalled.
5. Standard modularity and Module physical isolation: Modules are unified and independent of each other.
6. Service-oriented Programming support: Provides a programming model based on service-oriented architecture to support module communication.
7. Dynamic scalability: Dynamic scaling by exposing extension points.
8. Multi-Environment support: support various. NET application environment.

2. osgi.net Modular and plug-in

2.1 modularity and plug-in features:

1. Physical Isolation: The module developed based on UIOSP is a physically isolated, individually deployable module that has separate folders, type spaces, resources, and ClassLoader for each module. The modules are isolated from each other and are not affected by each other.
2. Highly reusable: The reuse of the module does not require any further changes to the code, it is only necessary to copy the module to the UIOSP specified plug-in directory, and its function will be exposed to other modules.
3. Normalization: The module has the unified standard, each module's directory structure, the module configuration are unified, the development method is also completely consistent.
4. Fast integration: Simply copying the modules to the specified plug-in directory enables quick integration of module functions without any need to change any code.
5. Easy to deploy and upgrade: Deploy and upgrade with a copy.

The core idea is encapsulation, which is both logical and physical. Logic encapsulation, the thing that OOP does, package changes, interface-oriented programming. It takes a bit of effort and practice to really apply to specific business logic, and is especially important for OSGi best practices.

Physical encapsulation, or "physical isolation", is a low level of isolation to a specific entity file. First of all, it's not like normal. NET programs, such as WinForm, by default, the feature assembly file must be in the Bin directory, and the main program together, such as the Web, the files are in the same directory hierarchy, the core logic is also in this boot path bin directory, they are closely linked, can not be stored separately. The directory structure of OSGi can be customized, and of course these paths are within a defined range, where assemblies can be accessed anywhere in the range. For example, you can put the main program on the C drive, the function module file on the D disk. In principle, osgi.net changes the. NET default load order and mechanism, allowing the program to dynamically load the assembly for the specified path.

Second, is the physical level of "package change", for a program, each sub-function module, according to the requirements of the different, for the whole is variable, but also constantly changing, before just the logic encapsulated in an assembly, then can be more than one association assembly in a "module"? Previously internal encapsulation, it is now encapsulated inside and outside, more abstract encapsulation. The representation of a logical package is an assembly, usually a DLL of a specific name, where the physical package is a folder of a specific name, in which the folder contains the many basic assemblies he needs. Theoretically, the best scenario should be logically, physically separate from and isolated from other encapsulated modules, so that we can easily extract the relationship between the modules from the file structure and the entire software functionality, which brings benefits for future updates, maintenance, deployment, and even reuse. For example, a packaged data access module on a WinForm can be copied directly to a web without changes, which is called "highly reusable", "Fast integration" and "easy to deploy and upgrade", they rely on a good logical and physical package, as well as a configurable loading path

3. Service-Oriented architecture support hold

Service-Oriented Architecture: SOA, which is also an important feature in Osgi.net, is designed to allow each module to interact in a unified and common way. The following is an official document description:

1. Service binding model: A service binding model that supports a typical "service registration – Service Search – service binding". The service provider wants to service the Registry Registration service, the service consumer searches the service registry and binds the required services.
2. Interface and implementation isolation: Each service is composed of "interface + implementation", the interface is equivalent to the service contract, and implementation is an instance of the specific class to implement the service interface.

Here the "service binding model", like a service bus, is used to store and retrieve various services. SOA is the use of different functional units of the application through well-defined interfaces and contracts, called services, it has a neutral interface definition, does not force binding to a particular implementation, loosely coupled.

System bus in hardware:

In Osgi.net, which is similar to the hardware system bus, it is almost the same purpose, but more focused on the interface and the physical isolation of the implementation, the so-called "use on Demand", combined with the "Plug and Play" will be mentioned later, will make the whole software more flexibility and configuration to adapt to the future of the different "change" , either externally or internally.

4. osgi.net "Service Bus" the implementation

Osgi.net's "service Bus" functionality is published as a service, and there are two ways of registering a service:

1. One is in the activator, with Ibundlecontext.addservice to add a specified interface and an instance of this interface implementation.
2. One is done in manifest.xml, by adding the editor.

After the service registration is complete, the GetService can be used to obtain all instances of this interface implementation of the specified interface type, or to obtain the first or default instance of this interface implementation by Getfirstordefaultservice for a specified interface type. These two methods can be obtained through the ibundlecontext in the Activator and the runtime environment Bundleruntime.

The Osgi.net service bus can be implemented with an IoC container, and the base effect may be better, OSGI. NET currently offers only a lighter-level solution, and does not introduce an IoC container.

The following is the implementation code for the key part of the service bus:

5. modules can be expanded to support hold

The osgi.net supports a more advanced module extension strategy, which has the following meanings (official documentation):

1. Extension points: Defines the extension points that a module exposes to other modules through a standard XML node <ExtensionPoint>. The module that exposes the extension point listens and handles the extension of other modules.
2. Extension: Defines the extension of a module to a module that exposes an extension point through a standard XML node <Extension>. This XML node is passed to the module that exposes the extension point through an extension point change event.
3. Dynamic expansion: When the module starts and stops, it registers and uninstalls the corresponding extension points and extensions to the platform, which exposes the extension point change events to handle dynamic extended information through the module context.
4. 0 Coupling: The expansion of the module does not have any coupling and is configured only through standard XML.

Osgi.net extension points and extensions are defined in the Mainfest.xml file of the corresponding module and are very easy to maintain and change. Extension points and extensions can be done between modules and modules, although the runtime environment that is launched in the main program can also handle the extensions of the specified extension point directly.

Definition of extension point, configured with <ExtensinPoint> node;

<?xml version= "1.0" encoding= "Utf-8"? ><bundle xmlns= "urn:uiosp-bundle-manifest-2.0" Symbolicname= " Workspaceshell "initializedstate=" Active "><activator type=" Workspaceshell.activator "Policy=" Immediate "/ ><runtime><assembly path= "WorkspaceShell.dll" share= "false"/></runtime><extensionpoint Point= "ToolBar"/><extensionpoint point= "MainMenu"/><extensionpoint point= "Navigation"/></ Bundle>

Extend the extension point and configure it with the <Extension> node:

6. hot-swappable and dynamic support hold

Osgi.net supports hot-swap and dynamic support, as follows () official documentation):

1. Hot swap: All modules can be dynamically added and uninstalled.
2. Life cycle: The module lifecycle State consists of "installed, resolved, starting, activated, stopped, stopped, uninstalled," and each lifecycle state, the module provides different functionality.
3. Dynamic: When a module performs any lifecycle operation, the module dynamically exposes or hides the functionality it provides, such as dynamically providing services, extensions, or other functions.
4. Remote deployment: Supports remote deployment of modules, such as Remote installation, startup, stop and unload modules, or module changes and synchronization in the subscription module repository.

7. about Remote Deployment

Osgi.net Deployment Related content:

1. It is online, not offline, that is, you do not need to close the program, users can use the normal situation, the deployment module
2. Because of the special nature of ASP, the "runtime" needs to be restarted, but the web itself is a non-persistent connection, which, if properly handled, does not affect the end user very much. WinForm not affected

Osgi.net's handling of modules is not as simple as installation and uninstallation, its life cycle is as follows:

Here "Stop (stopping)" and "Unload (uninstalled)" need to explain a little bit, stop is the module to return its own life process to the last state before the runtime environment, and unloading is the runtime environment will be the last state before the end of the module. To put it simply,

Installation, resolution, and uninstallation can only be managed by the runtime environment, while the boot, activation, stop is the module itself can participate together; The stopped module is still in the run-time environment management, but the module can no longer manage its own state, but other modules through the runtime environment to control it; unloaded module, before next reboot and delete , still in the run-time environment management, installation and startup, similar to unloading and starting, parsing and specific module loading process, you can refer to the previous "modular and plug-in" instance section.

Complete process of plug-in operation (dynamic)

8. plug-in startup configuration ( manifest.xml )

1. "Start Bundle as soon as the framework is activated", if checked, then the module (bundle) executes in the order of installation, parsing, startup, activation. If unchecked, it stops after installation and if the module is also dependent on other modules, it will ignore this configuration and run directly to activation. It is also important to note that each time you change this option, you must remove the Persistent.xml in this module, or you will not see the effect. The persistent.xml is used to record the last initialization state.

1.1 You can, of course, start it up in a coded way, for example

2. " late activation, that is, when the bundle class is loaded is re-activated." This is a bit like. NET late activation policy, when there is an " activator", it is said that if checked, the module will be stopped from installation to resolution , When another module needs to reference one of its classes, it automatically resumes startup and activation, which in theory can reduce unnecessary consumption

9. Remote Deployment

1. Delete this folder after compressing the entire plug-in folder to be deployed into a zip package. The compressed package is placed in a location that can be accessed later, such as D:\

2. Run the entire main program, the default ape option will not appear. Then we open "Remote management tool", enter the letter L, then there is no OSGi.NET.APEDecoderPlugin. Keep the main program and don't close it.

3. In the Remote management tool, enter I "OSGi.NET.APEDecoderPlugin" "D:\OSGi.NET.APEDecoderPlugin.zip" "D:\cnblogs.com\OSGi.NET\Demo4\ Osgi.net.audioplayershell\osgi.net.audioplayershell\bin\plugins\formattypes\lossless\osgi.net.apedecoderplugin "and enter, you can see the prompt has been installed successfully

　　　　　　

4. Activate, OSGi.NET.APEDecoderPlugin is installed (installed), not active (active), also need to start it, continue to enter S 6

10 . Module Extension Support

Dynamic information injection, advantages:

1. The injected party does not need to know who will be injected, which guarantees the uniqueness of logic and is easy to scale horizontally.
2. Configurable type of injected protocol, XML-based description for easy modification and maintenance
3. Combined with the "interface plus implementation" of the service model, can quickly integrate the resources of each module, to achieve an effective "service"

How to remove the injected information from the module when the extension is removed In addition to? Full code:

osgi.net High-level topics

11.1 Osgi.net Environmental Support (official documents):

1. Support for console applications.
2. Support for Windows Forms applications.
3. Support for WPF applications.
4. Support for Windows Service applications.
5. Support for ASP.
6. Support for Windows Mobile applications.
7. Support for UIOSP platform nesting.

Osgi.net is based on the. NET Framework and is independent of the language and type, that is, what environment the. NET can support and what environment osgi.net can support, and he can adapt to various. NET production and assembly environments.

Design principles and best practices of 11.2 osgi.net

1. As far as possible logical isolation, physical isolation. Logical isolation is required, low-coupling, cohesion, physical isolation is the best, replaceable
2. Try to handle logical dependencies in a "interface + implementation" manner, and the smaller the dependencies between modules, the better
3. As far as possible the interface and implementation of logic in different modules, combined with dynamic implementation can be maintained, updatable
4. Try to handle resource dependencies between modules in the form of "extensibility points and extensions", such as icons on the UI, as much as possible to place shared assemblies in a shared module, avoiding repetitive dependencies and version confusion, and reducing module volume
5. Try not to invoke the service implementation in the start function of the Activator (Activator) to avoid the possibility that the service may be empty due to the module boot order. Other places, if needed, try to use
6. Uishell.osgi.servicetracker<t> to handle it.
7. Try to handle the critical lifecycle state of a module with logical or resource dependencies, such as installation, stop, unload, etc., so-called "keep the system dynamic"
8. Rely on shared assemblies of another module rather than the entire module for faster load times
9. Try to package the existing module package into a unified deployment platform that facilitates sharing, testing, publishing

UIOSP Official website: http://www.iopenworks.com/

Osgi.net Official website: http://osgi.codeplex.com/

Reference: http://www.cnblogs.com/zhaojudi/archive/2013/02/26/2933788.html

Http://www.cnblogs.com/shalahu/archive/2013/02/21/2921306.html

Sample Source: Http://osgi.codeplex.com/SourceControl/latest

Osgi.net Study Notes--application article