|
这个主题共有 5 回复 ／ 1 页 [
]
|
|
|
|
|
|
对于jmservice 的几点设想
|
发表: 2007年03月13日 16:44
|
回复
|
|
对于jmservice 的几点设想
1: 介绍Jmservice 是一个面向服务域编程的架构(SOP),下面我们将介绍一些它涉及的概念!
1.1 什么是服务?
我们为什么要访问服务器呢? 望文生意,那是因为服务器能够提供一些有用的应用供客户端访问,这些应用能够处理来自客户的请求. 这一现象在客户端/服务器模式中非常普遍, 可能我们每天都好在享用这样的应用,但并没有关心它的内部运作.尽管它们务看上去非常复杂和异样, 但是如果你再细心点,也许你可以发现它们的一个共同点: 每个应用可以用代表一个领域(Domain),并对它的外界产生影响,如:处理来自外部的调用或者为外部完成一些用的任务.我们建议用”服务”这个词表这些具有共同点的应用. ”服务”是一个逻辑概念, 在它里面,一些其他对象可能会集成到一起去完成某些协作.从逻辑观点看,这些对象是逻辑集成,物理分离的.尽管有时”服务”没有出现在一些应用系统中,但从事实的角度上来看,它们都在做类似的概念.我们已经把”服务”抽象成一个接口了,并定义它在我们的框架规范中.
1.2 服务与域驱动
服务被设计用来帮助我们处理某些问题的. 一般来说,每个服务表达和处理某一个方面的问题,我们把这个方面定性为域,也就说,一个服务可以匹配一个域.服务的定义依赖于域,这个只是一个处理方式而已. 事实上,我们可以称成服务为逻辑方面,这点与面向切面的AOP有区别的.通常情况下,服务并不是孤立存在的,我们可以让一些组件运行在服务域中,并成为服务的组成部分.
1.3. 服务与客户端
如果可以供访问的服务是存在的,那么客户端是有可能可以访问它们.当然一些服务对客户端是不可见的,因此而无法访问到它们.例如: 我们定义一个初始化的内部服务,主要负责装载一些系统参数,它作用于其他服务.因此服务的存在不一定是为外部调用.服务的具体行为依赖它所的域,设计者可以自由设计它们的具体行为.
1.4. 服务与生命周期
服务的周期可能会不一样,比如有些是完成某些事情之后就死掉了,也有些可以一直伴随系统的而存在的..因次它们的生命周期有不定性..设计者可以自由设计它们的周期..
1.5. 服务与服务之间
服务被设计用来处理域问题,,因此从一个服务的外部来看,,它是有可能被其他服务所调用,所以服务之间是有能处在依赖关系.
1.6. 服务与组合
一些服务是可以组合在一起形成一个更大的域服务.
1.7. 服务与组件
服务是可以用来支撑一些组件的. 在软件业，服务与组件的技术目前非常流行:开发员可以设计开发他们自己的组件去完成某些业务操作的。仔细观察，这些组件还是可以划分到某些域中去,我们认为这就是服务域. 当我们调用这些组件的接口,事实上我们隐式使用它们的域服务.服务的概念是抽象的，不容易捕获。当然没有组件的服务也是可行的,具体完全决定于设计者。
1.8 组件与容器
服务如何去持有组件呢？容器是被期盼用来管理组件的,例如池化和生命周期。但是容器是如何感知组件的呢？我们觉得应该提供一种描述手段来让容器感知组件.
1.9. 组件与描述
在当前普遍的情况下，我们使用物理文件去存储组件和它们的描述,这些描述可能是XML的格式，也可能是properties 文件,还可能是EJB3.0所才采用的Annotation等等，不管采用何种方式，它们都属于描述的范畴。我们可以描述组件的名字,事物,安全等。但是组件一旦被需要装载到系统中，那么这些描述将发挥至关重要的作用。在我们框架中，我们定义了一个描述对象，采用对象描述对象方式，并将其他类型的描述方式转换为该方式：其他描述方式存在多样性，而这个对象描述只存在一个样式,我们认为这是可行的。尽管描述是一种好手段，但是它们毕竟有存储位置。
1.10 组件与部署
组件不会无缘无故跑进了服务的容器中的.我们需要将包含组件的源部署到制定的位置,这样服务才会装载这些外部的组件.在访问组件之前,它们应该是已经被装载了到容器中了，由于有各种各样的服务，那么它们的部署组件过程应该存在差异的。当部署组件时,组件描述是非常重要的。很多时候，我们可以把部署看成是组件的开始，很多其他事情都是包含在它的下面。
1.11. 组件源与发现机制
一旦组件源被部署到制定位置，那么我们应该提供一种机制去发现这些部署的组件源。例如：
部署，重部署. 一旦发现，那么该机制应该存在一种通知手段去通知部署控制器，这样控制器就可以决定部署的Happy-path.
1.12. 组件源与辨别
包含在组件源中组件是需要部署到某些service上的，由于service的差异，那么它们的组件描述是否也存在差异呢？一旦发现组件源,那么应该召集所有可以部署组件的服务来辨认这些source.如果找到匹配的服务，则该服务将部署这个组件源.
1.13. 组件源与解晰
当组件源应用到服务上时，它们应该被解晰:比如获取组件描述.我们定义了一个基本接口:Parser 去做这方面的事情。
附：jmservice是由一些没有定性的规范接口构成。
2 : 应用的探讨：
我们对jmservice进行了扩展,并形成一个微内核框架，主要应用于j2ee的服务,并在该微内核框架之上，我们尝试去架构一个简单的j2ee server(jmin),以此显示它的特性。
1：组织结构
2：部署控制
3: 容器的探讨
详细信息，请访问http://jmin.dev.java.net ,希望有您的参与！
Chris liao
2007年3月13日于深圳！
|
|
|
|
|
|
re:对于jmservice 的几点设想
|
发表: 2007年03月15日 10:39
|
回复
|
|
非常有意义的探索和学习。让大家了解了服务和组件的一些概念。
由于文档不是非常丰富，好像还没有看到与J2EE服务器及其一些框架的区别和特点，定位需要更清楚一些。
|
|
|
|
|
|
回复:re:对于jmservice 的几点设想
|
发表: 2007年03月15日 11:04
|
回复
|
|
部分已经更新!
 JmService-cn.rar
[该贴被chris.liao于2007年03月15日 16:37修改过]
[该贴被chris.liao于2007年03月15日 16:37修改过]
[该贴被chris.liao于2007年03月15日 16:37修改过]
|
|
|
|
|
|
回复:回复:re:对于jmservice 的几点设想
|
发表: 2007年03月16日 10:04
|
回复
|
|
来在美国Sun的Cheng Fang 对Jmin service 的评论
Hi Chris,
你分析的很好。好多想法都是和 JavaEE, JBI (Java Business家Integration) 一致的，也是以后 JAVAEE 服务器应该支持的。我的基本想法是，实现一个服务器是 一个巨大的工程，哪怕微型的服务器或框架。这些服务器或框架都是给企业级应用的，如果足够的市场或 ISV 支持，许多好的想法都不能起飞。如果是我，我会通过一些已经很成功的开源项目来逐步实现这些想法。如果愿意加入 glassfish 的话，我们会非常欢迎。
我是在美国，所以打中文不熟练，不能写太多，还请原谅。
-cheng(Cheng.Fang@Sun.COM)
|
|
|
|
|
|
回复:回复:回复:re:对于jmservice 的几点设想
|
发表: 2007年03月16日 10:30
|
回复
|
|
非常棒！
我以前在一篇文章里说过：现在Java走在两个方向上：一个是简单易用的透明框架；一个是继续庞大的分布式服务器；
所以，你必须确定你的方向，如果你决定走SOP/JBI服务器，那么单个力量肯定不够，需要加入glassfish队伍。
方向很重要，否则后果很严重噢....呵呵。
|
|
|
|
|
|
re:对于jmservice 的几点设想
|
发表: 2007年03月29日 17:00
|
回复
|
|
SOP是什么东西?
SOA - services origned architecture!
我没有专门专注过!但是SOA从设计角度和j2ee的初衷是一样的,只是j2ee单纯从软件角度建模,而SOA结合需求建模!
|
|
|
|
注册
登陆
上一主题
下一主题
