<mark>Gemini</mark> Web介绍

在OSGi标准中,HTTP Service是唯一支持Servlet编程模型的部分。HTTP Service主要关注于运行时(runtime),也就是构造应用的上下文(Servlet Context),但是不支持标准的Servlet打包、部署模型——WAR格式。将符合Java EE Servlet编程模型的应用部署到OSGi标准环境中的困难之大,可想而知。Web Application规范支持复合Servlet 2.5(及以上)和JSP 2.1(及以上)标准的web应用


Gemini <mark>BluePrint</mark>介绍

Gemini BluePrint融合了Spring和OSGi。使得我们在引入OSGi框架时不必把OSGi的API硬编码到原有的代码中,降低了耦合度,同时又保留OSGi的模块化特性。Spring能够生成松耦合的代码,这正是我们所需要的。通过Spring Dynamic Modules,我们在引入OSGi框架时就不必把OSGi的API硬编码到原有的代码中,而只需要创建一个Spring DM的配置文件


Equinox 介绍

OSGi是基于Java的服务平台的规范,本质是将Java面向对象的开发转向面向组件和服务的开发,具有服务组件模块化,动态加载应用等特点。Equinox 则是Eclipse所使用的OSGi框架,是Eclipse强大的插件体系的基础,是Eclipse著名的PDE开发环境的底层,Eclipse 的稳定可靠性也为该框架带来了声誉。 Equinox是EclipseRT工程的一部分,为Eclipse提供基于OSGi的运行时环境


Apache <mark>Felix</mark>介绍

作为[Apache][apache]旗下的其中一个项目,[Felix][felix]在2006年就拥有了自己的网站。不过一开始似乎进展并不快,直到2007年的七月,才发布了自己的1.0.0版本,其后他们发布了很多与Felix框架相关的[Maven][maven]插件,到了2008年初,开始对纲要标准(Compendium Specification)进行部分实现。此后Felix项目的发展壮大非常的迅速,那时候的OSGi标准也日趋稳定和完善。


Virgo 简介

Virgo项目Web服务器是EclipseRT项目的一部分,是一个完全模块化的Java运行时。Virgo自身就是设计为在标准OSGi框架实现(Equinox)之上的一个OSGi bundle集合。Virgo可以运行企业级Java应用以及基于Spring(Spring - powered)的应用,具有很强的灵活性和可靠性,它提供了一个支持企业级Java应用开发、部署和服务的简单而强大的平台。


Java应用架构读书笔记(1):物理设计与逻辑设计

几乎大部分帮助软件设计和架构的原则和模式主要都是关注逻辑设计。逻辑设计主要关于语言构造块,比如类,操作符,方法和包。识别一个类的方法,类之间的关系,系统包的接口等问题都是逻辑设计相关的问题。这一点并不奇怪,因为大部分的开发者都在花时间解决逻辑设计问题。当设计类及其方法时,我们正是在做系统的逻辑设计,比如 决定一个类是否应该是一个Singleton


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

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


Java应用架构读书笔记(3):模块化的两面

模块化包含两个方面:运行模型和开发模型。 现在模块化开发更多关注于运行时模型,比如现在已经出现一些运行时模块化支持的框架。 随着运行时模型的发展,最终开发时模型的重要性会为人们所认识。开发模型主要涉及开发者如何利用框架来开发软件应用。开发模型可以进一步分为编程模型和设计范型。除了运行模型和编程模型之外,设计范型需要被更多地关注。


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

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


Java应用架构读书笔记(5):处理复杂性

随着系统的演化,系统的复杂性会越来越大。每一次发布,系统的大小就会增加,从而复杂性也会增加。 Spring框架在2003年最早的发布版本中有一万多行代码,到了2.5版本时,代码数量大概翻了六倍。 系统维护和演化的开销大概站了总开销的百分之90以上。 技术债务是Ward Cunningham提出的一个隐喻,用来描述为了赶进度或者满足用户期望所做的设计上的折中。 债务需要及时的处理,否则系统的设计将会持续的腐化,太多的技术债务的积累最终会使得系统崩溃。


最受欢迎的文章

最新评论