创建OSGI主程序2020-03-29 08:45:38
勇哥2021/7/21注：现在发现vs2015已经不支持手里的iOpenWorksSDK。于是在网上搜索了一下，如下：1 iOpenWorksSDK对VS2013-VS2017的支持插件https://files.cnblogs.com/files/baihmpgy/iOpenWorksSDK.vsix.zip2 iOpenWorksSDK对VS2010的支持https://files.cnblogs.com/files/baihmpgy/iOpenWorksSDK2010.vsix能不能用，等
面向服务支持简介在该平台，一个服务由服务契约+服务实现组成。服务契约为服务接口，而服务实现则是实现服务接口的类。一般来讲服务契约由一个模块或者一个通用的程序集定义，服务实现模块和服务使用模块则都依赖于服务契约模块或者程序集。服务实现模块在激活器的Start方法中，利用传入该方法的参数context的AddService方法来注册服务，而服务使用模块则利用其激活器Start方法中的context的GetService或者GetFirstOrDefaultService来获取服务并使用。面向服务设计
Sample 01：一个简单的模块1 新建一个名为SimpleModuleShell的“控制台宿主应用程序”项目。2 添加一个新建项目，名称为SimpleModule项目，其项目路径指向SimpleModuleShell项目的bin\plugins文件夹，这样一个默认的模块便创建完成。3 新建的SimpleModule模块由Activator.cs文件和Manifest.xml文件组成。4 Manifest.xml是模块的配置信息，默认创建的内容如下。<?xml version=
这应该是每次我们打算使用模块化框架来创建新的解决方案或者将已有程序重构时首先面对的一个问题。这里我们不谈详细的需求与功能点的探讨过程，直接拿假设的功能点作为讨论基础。比如我们现在准备实现一个简单的B/S的留言板程序，它需要如下功能1） 留言信息展示2） 增加留言信息3） 管理员登陆4） 管理员回复、删除留言传统的三层架构划分大概是这个样子，一种典型的横向划分。你可以将他们放在一个解决方案里完成并发布现在我们来看看，如何将他们拆分成OSGi.NET所
所谓的多环境支持，官方是这么介绍的 1） 支持控制台应用程序。 2） 支持Windows窗体应用程序。 3） 支持WPF应用程序。 4） 支持Windows服务应用程序。 5） 支持ASP.NET应用程序。 6） 支持Windows Mobile应用程序。 7） 支持UIOSP平台嵌套。 这个理解起来不难，主要是因为OSGi.NET是基于.NET框架且与语言以及类型无关，也就是说.NET能支持什么环境，OSGi.NET也就能支持什么环境，他能适应各种.NET生产和装配环境。
“热插拔和动态支持”应该算是OSGi.NET最有趣，最Cool的一个功能，官方文档是这样介绍的 1） 热插拔：所有的模块都可以被动态的添加和卸载。 2） 生命周期：模块生命周期状态由“已安装、已解析、正在启动、已激活、正在停止、已停止、已卸载”组成，每一个生命周期状态下，模块提供的功能都可能不同。 3） 动态：当模块执行任何生命周期操作时，模块会动态的想外界暴露或者隐藏它提供的功能，比如动态提供服务、扩展或者其它功能。 4） 远程部署：支持模块远程部署，比如远程安装、启动、停止和卸载
通过上面的实例，我们可以具体体会到模块与模块之间的“动态信息注入”方式。这种方式的好处是 1） 首先，被注入方不需要知道将会被谁注入，保证了逻辑的单一性，易于横向扩展 2） 其次，注入的协议的可配置型，基于XML的描述，可实现很方便的修改和维护 3） 结合“接口加实现”的服务模式，可以快速整合各个模块的资源，实现了有效的“服务化” 上面的代码只是实现了注入，也就是当具体业务模块被运行环境加载后的被相应的处理模块识别并解析，但OSGi.NET也同时支持某个业务模块的动态抽离，在这里就是从
目前为止我们已经了解了模块化的隔离策略，面向服务的交互策略，现在就该来看看更高级的模块扩展策略，这里的“可扩展”在官方文档是这么介绍的 1） 扩展点：通过标准XML节点<ExtensionPoint>来定义一个模块向其它模块暴露的扩展点。暴露扩展点的模块会监听并处理其它模块对其的扩展。 2） 扩展：通过标准XML节点<Extension>来定义一个模块对暴露扩展点的模块的扩展。这个XML节点会通过扩展点变更事件传递到暴露扩展点的模块。 3） 动态扩展：模块在启动和
这次我们继续延续“模块化和插件化”那个实例来做展示。 现有的代码，主程序依赖接口和接口实现的Calculator.Demo1程序集，也就说主程序不仅得知道具体的接口定义，还得知道这个接口具体实现的定义。理论上说，这是面向对象，但也是紧耦合。如果你要替换成另外一个接口实现，你就得重新修改、编译、发布主程序。如何避免这种修改呢？可以通过服务总线来重构它、隔离它、松耦合它。 好在OSGi.NET的“服务总线”功能是以服务的形式发布的，有两种注册服务方式 1） 一个是在激活器当中，通过IBun
面向服务的体系结构，SOA，也是OSGi.NET中一个重要功能，主要是为了各个模块可以以一种统一和通用的方式进行交互。官方文档是这么说的 1） 服务绑定模型：支持典型的“服务注册 – 服务搜索 – 服务绑定”的服务绑定模型。服务提供商想服务注册表注册服务，服务消费者搜索服务注册表并绑定需要的服务。 2） 接口与实现隔离：每一个服务由“接口 + 实现”组成，接口相当于服务契约，而实现则是实现服务接口的具体类的实例。 这里的“服务绑定模型”，像是一个服务总线，用来存储和检索各种服务。而SOA就