Jdon框架下一步架构构想

融合IOC + OSGI + REST + 异步HTTP。
这四个架构是当前热点，都是组件构件领域最先设计，如何把它们揉合在一起，形成一个轻量的方便使用框架，以下是我目前想法，欢迎大家讨论：

框架内部：
1. 将资源或服务以URI为名称注册到OSGI中。
2. 注册URI资源之前，首先要注册异步Http服务，可以挑选MINO xHttp等。
3. 注册总类如下，将上述两个组件注册到OSGI中，同时使用IOC依赖注射解决资源类之间的依赖。


 public class Activator implements BundleActivator
{
   public void start(BundleContext context) throws Exception
   {
      ServiceReference sRef = context.getServiceReference(RESTService.class.getName());
      if (sRef != null)
      {
         RESTService service = (RESTService) context.getService(sRef);
         //向OSGI注册一个资源，通过IOC依赖注射解决MyResource对其他类XXX的依赖
         service.registerResource("/resource", new MyResource(XXX), null, null);
      }
   }

   public void stop(BundleContext context) throws Exception
   {
      ServiceReference sRef = context.getServiceReference(RESTService.class.getName());
      if (sRef != null)
      {
         RESTService service = (RESTService) context.getService(sRef);
         service.unregister("/resource");
      }
   }
}

上述注册在框架被使用时，可以通过XML配置或Annotation实现：
<services>
<service name="/resource" class="xxx.MyResource.class"/>
</services>


@GET
@Resource("/resource")
Class MyResource{

...
}


客户端调用方式：
1.另外一个JVM或远程通过REST方式调用
http://localhost:8080/resource

2.同一个JVM中不同Bundle模块之间使用OSGI方式调用：
ServiceReference ref = bundleContext.getServiceReference("/resource");
try {
MyResource myResource = (MyResource) bundleContext.getService(ref);
...
} finally {
bundleContext.ungetService(ref);
}

3.同一个Bundle模块中以IOC依赖注射调用。

调用方式的粒度是不断从小到大，当然比REST更粗粒度的是SOA Web方式方式。提供各种粒度的对外开放接口，我相信这应该是未来轻量框架的一个目标。

沙发

关注

那个视图层用Struts已经不太合适了，jdon本来就是一个业务层的框架，把Struts集成进去太不习惯了。虽然也可以单独使用业务部分，但使用起来还是有些不友好。
JAAS本身是很不错的，但为了更好的普及，也不建议再用这个。关于权限这个问题，原来我一直觉得应该在业务层解决。实际上视图层也可以解决大部分问题，准确一点说，不涉及到数据库检测的都可以放在视图层解决。只是由于原来的框架对这方面的支持并不是很友好而已。如
@permitRole(name="administrator")
public class AdministratorAction{
.....................

JDON在这方面做得还不够，banq的理解主要在于业务，并没有重视视图层的一些解决方案，但却又集成了一个改良了的Struts（其实个人认为改良得还不彻底，当然这也是人力有限），与其这样，还不如直接放弃视图层，专心搞业务。
[该贴被Hqiu于2009-09-10 14:39修改过]

关注！
毕竟只有一个banq老师是不够的！
希望在不断理解中，能出一份力！

多谢大家讨论。

因为个人精力有限，现在是说得动，干不动了，所以，先在这里把想法说出来，不象以前，刚搞Jdon框架时，没有说，先搞，结果搞出来，大家一片愕然，你这是什么怪东东？

现在框架的状况是：Spring DM Server已经将OSGI + DI融合起来，但是它走了Server服务器的概念，其实我个人很不看好服务器，其实在Java世界，有一个JVM封装就可以了，其他都要透明化，当然，如果全透明了，脱光了，使用者眼睛也要花，都是白花花的屁股，有什么区分边界呢？所以，细分透明后，要适当再封装起来，是一种弱封装，框架可以起这个作用。

当然，MF等大师看好DSL语言这个作用，但是无论Scala或是Groovy动态语言，不能无缝和Java延伸，所以，Java框架还是有相当发展前途的，虽然Spring被收购了，一般被收购，意味着创新结束，但是我们还是可以把梦做下去，不必一定依靠新的DSL语言。

Spring DM Server使用服务器概念属于强封装，这个不好，没有和REST无缝结合，这也是它问题，当然现在APACHE有几个框架都是基于Spring进行REST服务配置的，但是这和无缝整合又有距离。

更重要的是异步Http，我们要把Servlet服务器作为一个组件整入我们的框架，以前是我们的框架基于服务器，可是多样的需求以及异步技术的不断发展，服务器软件包括tomcat Jetty已经不能跟不上步伐，那么把tomcat jetty拆了，作为我们的一个OSGI组件部件，未尝不是不可。

什么都可以拆？这是Jdon框架当初刚出来时标新立异的特点，什么阻挡我们应用就拆了谁？包括服务器，只要有强封装，就拆了它，用弱封装。

SOA?
tunscany?
[该贴被starfeng于2009-09-18 13:32修改过]

将 Struts 分离出来。。。另外，我觉得jdon应该使用maven，或者ant/ivy 来构建，既然是开源项目，jdon可以自己建一个集成站点，如使用hudson，每天构建，另外需要相关的bug tracker,wiki。。。要做成社区互动的。
不要每一次发布一个版本，扔到sf.net 就不管了。

多谢hantsy，hudson原来采用过，部署到jboss下会死机，内存耗尽，没查出原因。

将Struts分离出来，引入REST是一个方向，实现DDD + REST架构，将模型作为REST架构的资源暴露，这样DDD和REST完美结合。没有MVC框架，有的只是事件模式。

通过AJAX在客户端发出事件，服务器端领域模型直接响应事件，然后驱动其他技术架构，包括领域服务，持久化等完成任务，这应该是未来比较好的一个架构。

目前6.2版本已经强化DDD，使得Jdon框架从一个所谓快速开发框架象DDD框架更加靠拢，下一步向REST靠拢，Domain Events能够直接接受客户端AJAX的异步事件，再通过异步驱动技术架构完成持久化，这应该是一个高伸缩性的先进架构。

Banq你确定一定得用OSGi?

>你确定一定得用OSGi?
问得好，没有确定，还是觉得它的套子太紧，目前没有适合的地方。谢谢

虽然我研究得也不深入，但是始终感觉就Jdon而言，目前充分性和必要性不足。
是否有开销过大的嫌疑，就一个简单的third-party，想要完全找到与OSGi架构匹配的都很麻烦。


[该贴被lendo于2009-11-02 16:38修改过]