EA & IT Governance An open community to promote knowledge sharing of Enterprise Architecture and IT goverance, to be a good repository of relevant articles, papers, best practices and so on. Anything relate to Corporate Information Systems, Enterprise Architecture, IT Governance, System Integration are welcome. http://EnterpriseArchitecture.group.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 OpenCore:基于OSGi开发纯插件体系结构的WEB应用程序 erylee 作者: erylee  链接：http://EnterpriseArchitecture.group.javaeye.com/group/blog/50624  发表时间: 2007年01月26日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

随着OSGi/Equinox逐渐成为Java EE服务端的基础软件架构，OSGi上部署WEB应用程序的解决方案日渐成熟。这里介绍三种目前我们所知的解决方案，前两种是Equinox组织提出的方案，后一种是OpenCore平台采取的解决方案。

解决方案一: 部署OSGi/Equinox在Servlet容器中

具体实现: 把OSGi/equinox打包在WAR中，当Servlet容器加载WAR时，启动OSGi框架。
WEB-INF的目录结构大致如下(大致如此):
  1. * /WEB-INF  
  2.       o /web.xml (with one servlet entry assigning all incoming requests to the BridgeServlet)  
  3.       o /lib/servletbridge.jar (the classes associated with the equinox.servletbridge)  
  4.       o /eclipse (the eclipse platform directory)  
  5.             + launch.ini (contains framework properties that will allow override of any eclipse specific System Properties)  
  6.             + /configuration (contains config.ini which lists the bundles you want to have available)  
  7.             + /features  
  8.             + /plugins  

部署结构如下图(转载):




个人感觉这个解决方案使用价值不大。

解决方案二: Web服务器与Servlet容器嵌入在OSGi/Equinox

具体实现: 把Jetty当作一个插件嵌入到OSGi/Equinox中，并基于Jetty实现OSGi标准中的HTTP服务，其他插件可以通过该服务注册Servlet和静态页面。

OSGi标准中的HTTP服务接口如下：

 
  1. package org.osgi.service.http;  
  2.   
  3. import javax.servlet.Servlet;  
  4. import javax.servlet.ServletException;  
  5. import java.util.Dictionary;  
  6.   
  7. public interface HttpService {  
  8.     public void registerServlet(String alias, Servlet servlet,  
  9.             Dictionary initparams, HttpContext context)  
  10.             throws ServletException, NamespaceException;  
  11.   
  12.     public void registerResources(String alias, String name,  
  13.             HttpContext context) throws NamespaceException;  
  14.   
  15.     public void unregister(String alias);  
  16.   
  17.     public HttpContext createDefaultHttpContext();  
  18. }  


部署结构图(转载):



因为OSGi是最早为嵌入式系统设计，所以OSGi标准中的HTTP服务只提供了有限的Servlet与静态资源的发布功能，没有一个完整的WEB容器概念，这种模式更适合通过WEB方式暴露(Export)服务，不太适合开发展现层的WEB应用。

通过Equinox提供的扩展/扩展点功能可以简化这种方式WEB应用的开发，就是通过plugin.xml来配置Servlet和静态页面的注册。

解决方案三: 设计适合OSGi环境的Servlet容器，构建纯插件体系结构的WEB层

具体实现："插件"与我们通常所说软件"模块"的一个区别是：插件能自我描述，加载运行在插件容器中。那么，我们可以分层扩展一个插件的自我描述，用类似Decorator的模式为插件增加“特征”描述。 所以，我们在OpenCore中定义了三种特征的插件，如下图：



这三种插件类型间关系类似Decorator模式，从内到外增加"特征"描述：
  1. OSGi标准插件，自描述文件"META-INF/MANIFEST.MF"
  2. OpenCore插件，增加自描述文件"META-INF/opencore.xml"，实现符合OSGi环境的依赖注册(IoC)与动态扩展点
  3. OpenCore Web插件，增加自描述文件"WEB-INF/web.xml"(符合Servlet规范)，WEB特性的插件，可以部署在Servlet容器内

这样我们可以把一个应用的WEB层像业务层一样，分割为多个插件，部署在OSGi/Equinox的框架中.

部署结构图:






我 们觉得这种方式以合适的力度将WEB层分割为插件部署在OSGi框架上，充分的发挥了OSGi体系结构的强大之处，也提高了WEB层开发部署的灵活性。目 前，业界好像也有很多项目是采用这中方式部署。这种部署方式的缺点是，不得不修改Jetty容器的实现，以使其适应OSGi的环境，我们希望Jetty以 后能支持这个功能:)

Google Code上发布了一个基于OpenCore的示例项目linktalk，一个基于GWT、Equinox、OpenCore的Ajax聊天室。

项目地址: http://code.google.com/p/lintkalk

源码下载: svn checkout https://linktalk.googlecode.com/svn/trunk/project

程序下载: svn checkout https://linktalk.googlecode.com/svn/trunk/release

相关资源:

http://www.eclipse.org/equinox/server/http_quickstart.php

本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 26 Jan 2007 14:15:50 +0800 http://EnterpriseArchitecture.group.javaeye.com/group/blog/50624 http://EnterpriseArchitecture.group.javaeye.com/group/blog/50624 OpenCore: OSGi上实现IoC容器 erylee 作者: erylee  链接：http://EnterpriseArchitecture.group.javaeye.com/group/blog/43302  发表时间: 2007年01月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Martin Fowler有一篇文章里称：说一个面向对象系统框架或结构是基于IoC的，就好像说汽车有四个轮子一样。非常精辟 ，IoC或者DI更多的是一个设计原则，一个设计良好的面向对象的系统或多或少都有这方面的特点，这与是否有一个IoC容器的关系不大，IoC容器的作用 是简化开发，强制系统遵循IoC原则而已。

OpenCore在最初设计的时候，没有考虑IoC容器的问题，主要是解决服务端的WEB开发、数据库访问、与REST远程通信等问题，我们完全使用 OSGi本身的服务注册机制，在插件启动时用代码实现依赖注射。直到今年8月份左右，我们把依赖注射的职责分离出来，在OSGi上实现了一个分级的IoC 容器，以简化开发，避免在插件启动类写依赖注射的代码。

OpenCore IoC容器有下面几个特性：
  1. 完全基于OSGi的插件体系结构。
  2. 简单，远没有Spring IoC容器复杂，支持属性注射(Property Injection)与构造函数注册(Constructor Injection)。
  3. 分级IoC容器，分为插件级、应用程序级、网络级
  4. IoC容器管理的服务与OSGi框架管理的服务可以互访，这样保证了OpenCore IoC不会屏蔽OSGi本身的模型，使得基于OpenCore IoC的插件与大量第三方基于完全基于OSGi服务模型的插件可以协作。
  5. 支持通过动态扩展点实现1对多的依赖注册机制。
OpenCore IoC的实现机制：

1. 每个插件(bundle)增加一个IoC的自描述文件META-INF/OPENCORE.XML，例如org.opengoss.web.core中，该文件的配置如下：
xml 代码
 
  1. <plugin id="WebCore" version="1.0">  
  2.   
  3.     <service id="WebServerConfiguration" scope="application" class="org.opengoss.web.internal.WebServerConfiguration">  
  4.   
  5.         <interface name="org.opengoss.web.core.IWebServerConfiguration"/>  
  6.   
  7.     </service>  
  8.   
  9.     <service id="MarshallerRegistry" scope="application" class="org.opengoss.web.internal.MarshallerRegistry">  
  10.   
  11.         <interface name="org.opengoss.web.service.IMarshallerRegistry"/>  
  12.   
  13.     </service>  
  14.   
  15.     <service id="WSContainer" scope="application" class="org.opengoss.web.internal.WSContainer">  
  16.   
  17.         <interface name="org.opengoss.web.service.IWSContainer"/>  
  18.   
  19.         <property name="marshallerRegistry" ref="MarshallerRegistry"/>  
  20.   
  21.     </service>  
  22.   
  23.     <service id="WSExporter" scope="application" class="org.opengoss.web.internal.WSExporter">  
  24.   
  25.         <interface name="org.opengoss.web.service.IWSExporter"/>  
  26.   
  27.         <constructor>  
  28.   
  29.             <param ref="WSContainer"/>    
  30.   
  31.         </constructor>  
  32.   
  33.     </service>  
  34.   
  35.     <extension-point id="Marshaller" target="MarshallerRegistry"  
  36.   
  37.         bindMethod="addMarshaller" unbindMethod="removeMarshaller"/>  
  38.   
  39.     <extension-point id="WebService" target="WSExporter"   
  40.   
  41.         bindMethod="export" unbindMethod="unexport"/>  
  42.   
  43.     <extension-point id="Class" target="MarshallerRegistry"  
  44.   
  45.         bindMethod="addAliasClass" unbindMethod="removeAliasClass"/>  
  46.   
  47. </plugin>  


2. 插件的激活类(Activator)不是直接实现OSGi本身的"BundleActivator"接口，而是继承由OpenCore提供的 "org.opengoss.core.PluginActivator"，启动时，PluginActivator负责完成XML文件解析与依赖注射。 例如org.opengoss.web.core中的Activator代码如下：

java 代码
 
  1. import org.opengoss.core.IPluginContext;  
  2. import org.opengoss.core.PluginActivator;  
  3. /** 
  4.  * Plugin activator. 
  5.  * 
  6.  * @author Ery Lee(ery.lee@gmail.com) 
  7.  * @version 1.0 2006-11-20 
  8.  * @since 1.0 
  9.  */  
  10. public class Activator extends PluginActivator {  
  11.    
  12.     @Override  
  13.     protected void startPlugin(IPluginContext pluginContext)  
  14.             throws Exception {  
  15.     }  
  16.    
  17.     @Override  
  18.     protected void stopPlugin(IPluginContext pluginContext)  
  19.             throws Exception {  
  20.     }  
  21.    
  22. }   


3. 我们注意到上的的服务配置中有"scope"的属性，该属性定义一个服务的使用范围，确定一个服务注册到哪一级IoC容器。

4. 另外一点，我们在IoC基础上增加了动态扩展点功能，实现多对1的注射。

OpenCore整个项目代码发布在www.sf.net/projects/opengoss与code.google.com/p/opengoss下。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 05 Jan 2007 21:49:21 +0800 http://EnterpriseArchitecture.group.javaeye.com/group/blog/43302 http://EnterpriseArchitecture.group.javaeye.com/group/blog/43302