OSGi.NET 学习笔记 [面向服务架构支持][概念]

【目录】- 面向服务架构支持】-【概念】

　　面向服务的体系结构，SOA，也是OSGi.NET中一个重要功能，主要是为了各个模块可以以一种统一和通用的方式进行交互。官方文档是这么说的
　　1） 服务绑定模型：支持典型的“服务注册 – 服务搜索 – 服务绑定”的服务绑定模型。服务提供商想服务注册表注册服务，服务消费者搜索服务注册表并绑定需要的服务。
　　2） 接口与实现隔离：每一个服务由“接口 + 实现”组成，接口相当于服务契约，而实现则是实现服务接口的具体类的实例。

　　这里的“服务绑定模型”，像是一个服务总线，用来存储和检索各种服务。而SOA就是将应用程序的不同功能单元通过定义良好的接口和契约联系起来，称为服务，它具有中立的接口定义，没有强制绑定到特定的实现上，松耦合。理解起来没什么难度。

　　相比较而言，在硬件领域，“总线是构成计算机系统的互联机构，是多个系统功能部件之间进行数据传送的公共通路。借助于总线连接，计算机在各系统功能部件之间实现地址、数据和控制信息的交换，并在争用资源的基础上进行工作。”
　　

　　在OSGi.NET，差不多是同样一个目的，但更侧重于接口和具体实现的物理隔离，即所谓的“按需所用”，结合后面将提到的“即插即用”，将会使整个软件具有更好的灵活性和配置性，以适应未来各种不同的“改变”，无论外部或者内部。

　　延伸一下，从行业软件领域来说，将自己的积累通过面向服务暴露出来无疑是 “滚雪球”式的进步，便于管理，检索，分类，甚至交易。服务化的过程实际就是一种自我提炼、萃取的过程，好东西还得有好的使用方法，才能真的好。现在市场竞争激烈，如何将自己的行业积累转换成一种可用的服务，将是现在和未来一个重要的商业筹码。

　　现在的“云”计算也是比较火热的话题，虽在某些点上，看起来是硬件界“零碎变整“，却和软件领域的SOA有着异曲同工之处，只是可惜软件现在很难做到硬件那么清晰分明，一是复杂度和使用环境决定，还有就是合理的隔离策略。不过照此思路，如果结合硬件和软件，基于OSGi.NET的云计算平台还是很有潜力可挖的，官方貌似已经有了这样的方案，有兴趣的话可以自行咨询。

　　好了，回到主题。照例，我们将通过一个具体实例来说明这个面向服务。