OSGi培训,免费!!!

好消息!除了4月25日晚的演讲,Tim Ward 和 Jeff Liu计划在24日下午在北大为大家带来一次免费的OSGi培训,欢迎大家通过邮件报名,并帮助扩散传播。人数足够培训将正点开班!前期报名参加25日晚Tim Ward演讲的童鞋,我们很快将跟你们进行邮件确认,告知大家具体时间和活动地点,谢谢关注!


OSGi入门篇:模块层

模块层是OSGi框架中最基础的一部分,其中Java的模块化在这一层得到了很好的实现。但是这种实现与Java本身现有的一些模块化特性又有明显的不同。OSGi的产生恰恰是为了弥补之前一些技术的缺陷。 模块化其实就是计算机科学中常见的一个概念: “将一个大型系统分解为多个较小的互相协作的逻辑单元,通过强制设定模块之间的逻辑边界来改善系统的维护性和封装性”。


Java应用架构读书笔记(2):模块的定义

市面上一直不缺少介绍面向对象设计和面向服务架构相关概念和技术的书籍,但是专门有关模块化的书籍却非常少。 一个模块可以认为是一个“软件块”(chunk of software),但是适用于这一定义的还可以是类,包,构件,服务,甚至是应用。 模块的精确定义: 一个软件模块是一个可部署的、可管理的、本地化复用的、可组装的且无状态的软件单元,为消费者提供了简明的接口。


Java应用架构读书笔记(4):架构与模块化

架构(或者称为体系结构)具有非常多的定义: 比如IEEE将架构定义为: 一个系统的基础组织,其中包含了构件,构件之间以及构件与换件的关系,以及指导它们设计和演化的原则。架构师和程序员之间通常有一道鸿沟。架构师主要关注应用和服务,程序员主要关注代码。架构师关注广度,程序员关注深度。


Java应用架构读书笔记(7):模块化与SOA

对于至上而下的社会化架构,模块和包填补了从服务到代码之间的空缺。 类易于在应用内复用,但是由于类不是部署单元,无法支持应用之间的复用。 服务可以在应用之间复用,服务的调用通常基于分布式的协议(比如SOAP,HTTP,RMI/IIOP)。服务通常是远程调用,因此出于分布式请求性能的考虑一般比较大粒度。但是如果只想复用服务中特定的行为该怎么办呢? 或者copy代码,或者暴露新的服务接口。而基于模块则可以得到一种更为优雅的解决方案。


模式3:Cohesive Modules

高内聚、低耦合是面向对象设计的一个原则。一个模块的内聚性是模块的功能强度的度量,指示一个模块内部各个元素彼此结合的紧密程度。 影响模块内聚性主要有以下两个关键因素: - 模块内类行为变化的速率 - 模块内的类同时被重用(即复用A的时候同时也会复用B)的可能性。一个模块的行为应该尽量只做一件事,而这个模块内部的行为在数据上和功能上应该有比较强的联系。


模式2:Module Reuse

模块复用:在模块层面上强调复用能力 面向对象编程范型为软件开发提供了一系列新的方法、原则和模式,其最重要的目的就是提高软件复用的程度。但是,随着软件系统规模的日益庞大以及越来越高的复杂度,强调类层面(class-level)上的复用的面向对象方法难免遇到了一些困境。 为了更有效的复用,就需要更高层次的复用单元——模块(module),在Java中就是JAR文件,代码被组织聚合在模块里并且可以被单独部署。


模式8:Independent Deployment

模块应该是可以被独立部署的单元。如果一个模块可以被独立部署,那么它就不可以依赖其他的任何模块。但另一方面,除去所有的对外依赖显然是不太现实的。我们希望能够尽可能的减少模块之间的耦合,但是另一方面各个模块为了能够一起协作实现某项功能,耦合又会不可避免的存在。


深入理解OSGI:第一章 Java模块化之路

Java可能是近20年来最成功的开发技术,因其具备通用性、高效性、平台移植性和安全性而成为不同硬件平台理想的开发工具。从笔记本电脑到数据中心,从游戏控制台到科学超级计算机,从手机到互联网,Java技术无处不在。


深入理解<mark>OSGI</mark>:第二章 模块层规范与原理(1)

在OSGi系统中,同一个名称的Package可能存在多个不同版本。假设Bundle C开发时引入了Spring 2.0版的Package,并且使用了某些只在这个版本私有的特征,而Bundle D开发时使用的是Spring 3.0版的Package,那么从这个系统中导出Spring的Bundle就必须明确指明Spring的版本号,以便导入时区分。


深入理解OSGI:第二章 模块层规范与原理(2)

OSGi的类加载架构并未遵循Java所推荐的双亲委派模型(Parents Delegation Model),它的类加载器通过严谨定义的规则从Bundle的一个子集中加载类。除了Fragment Bundle外,每一个被正确解析的Bundle都有一个独立的类加载器支持,这些类加载器之间互相协作形成了一个类加载的代理网络架构,


敏捷与结构性模块化(一)

敏捷开发方法论日益流行,然而大多数“敏捷”专家和分析师都在孤立地讨论敏捷,也就是说忽视了系统“结构”(Kirk Knoernschild是一个例外,他编写了一本名为《Java Application Architecture》的图书阐述这一理念)。考虑到“敏捷”是基础实体的一个重要特性或属性,那么,这种疏忽令人感到很惊讶。一个实体要具有“敏捷”的特性,它必须具有高度的结构性模块化(structural modularity)特征(参见Scott Page的《Diversity & Complexity》)。


敏捷与结构性模块化(二)

在上一篇文章中,介绍了结构性模块化与敏捷之间的关系,在这个系列的第二篇文章中,我们将会研讨OSGi™,在实现JavaTM的结构性模块化方面,OSGi扮演了核心的角色;OSGi与流行的敏捷方法论之间存在着自然的联系。软件行业花费了很长的时间才理解结构性模块化的重要性。特别是,结构性模块化可以提高程序的可维护性和灵活性,控制和减少环境带来的复杂性。


再看OSGi模块层——从在OSGi容器中引入Thymeleaf说起

Thymeleaf是一个开源的XML/XHTML/HTML5模板引擎,它的主要优势在于创建的模板可以被浏览器良好的支持并正确显示,非常适合于直接用于原型(prototype)设计。然而它的坐着一直没有添加OSGi支持,为了能够在OSGi环境下使用它,本文探究了将Thymeleaf的jar包转化为bundle的方法,并针对遇到的问题,根据《OSGi in Action》中内容给出了解决方案。