“……一套针对JavaEE情况的服务，让使用程序开辟起来加倍复杂。WebBeans在已有的Java组件范例好比JavaBeans和企业JavaBeans之上，搭建了加强的性命周期和交互模子一层。作为针对传统JavaEE编程模子的增补，WebBeans服务供应了：
- 改良有形态组件的性命周期，并绑定到界说优秀的高低文上，
- 为依附注进供应范例平安的体例，
- 经由过程事务关照机制举行交互，
- 一个把拦阻器绑定到组件上更好的办法，并供应一个新型的拦阻器，也叫粉饰器（decorator），这对办理营业成绩加倍符合。”
WebBeans中的模子切实其实遭到了Spring、Guice和Seam的影响。可是，最最间接的影响来自于Seam的高低文形态办理模子和Guice的范例平安依附注进。Seam和Guice也影响了Spring的开展，好比Spring比来就增加了针对高低文bean和Guice作风的绑定范例的撑持。但是，WebBeans具有“成份明净”的上风，以是最初的了局只会是加倍洁净，加倍文雅，并且范例加倍平安。WebBeans还引进了很多立异性的头脑，好比粉饰器、原型、部署范例、范例平安事务/察看者绑定和拦阻器绑定注解，这些在其他办理计划内里是没有的。终极的了局就是更少的XML但更多的范例平安性。
SpringSource今朝其实不在JSR-299专家组中。
每个你用粉饰器能够办理的成绩，你也能够用拦阻器来办理，但拦阻器长短范例平安的，处置营业逻辑的体例也不敷天然。粉饰器供应了可以感知到正在被挪用的办法的语义的拦阻体例，并且能使用到特定的Java范例上。换句话说，拦阻器从手艺上办理了像把买卖办理和平安从营业逻辑中解耦出来如许的成绩，而粉饰器是在营业的角度供应了相似的办理计划。
这是由于我们想促进一种松耦合和强范例的编码办法；这类理念是该标准的基本。可是除此以外，我们还试图编写出既有形态又松耦合的组件。因为必要办理缓存着的形态，有形态的组件大概会在Web高低文中呈现成绩，好比，产生回滚时很多使用城市出成绩，由于形态并没有和事件绑定起来。因为这些范例的成绩一般只产生在使用程序负载很重的情形下，以是常常十分难以测试。因而，事务模子供应了一种把持这些范例成绩的体例。
WebBeans模子与Java的observer/observable形式的区分在于，察看者（observer）不必要晓得被察看者，由于这类依附在WebBeans高低文中其实不有用。WebBeans模子还撑持动静选择器及事务范例——一种事务范例有点像一个MOM主题，而动静选择器则像二进制范例。因而你能够以范例平安的体例在这一级别使用过滤。
我们仍在做一些这方面的事情——比方，IBM提出的一个成绩是以后草案中并没有撑持处置集群（cluster）的语义，因而，下一个草案也许将同意事务被发送到JMS主题或行列上，以供应一种文雅的体例将Java对象发送到一个行列。请拜见这个blog以取得更多信息。
WebBeans是一个依附注进框架。固然在某种意义上依附注进在手艺上并没甚么出格的；实践上DI框架所做的就是为对象之间的交互供应一其中枢。DI框架是如许一种中枢:不但能够供给用程序组件间交互利用，还能够供给用组件和基本举措措施间交互利用。JavaEE缺少把第三方框架集成进其情况的API，以是今朝你必要加一层像Spring或Seam如许的中枢。而WebBeans则供应了一种尺度的体例来做这件事，它是JavaEE的一部分。
我们正会合于四个年夜的用例，我想它们掩盖到了多半用例。首当其冲的是Web框架——应当很简单把WebBeans与别的Web框架相集成，我信任这一点。其次是营业流程办理（BusinessProcessManagement）引擎，好比JBPM或Oracle的BPM——它促使了分级办理模子的利用。第三是利用现有依附注进框架（好比Spring、Seam、Guice或其他DI机制）的人们必要可以把他们的现有代码与WebBeans相集成，第四是JAX-RS。
Seam3的中心引擎将是WebBeans。然后我们将要移植全套模块，整合JSF、JBPM、Hibernate、Drools、Groovy、Wicket和GWT如许的手艺，大概办理罕见的挂念如平安、展示PDF、email、Excel、RSS等等，把他们都移植到WebBeans中枢上。我还在思索怎样撑持那些利用Seam专有依附注进的现有代码，是经由过程一个Seam2的集成层呢仍是在WebBeans上从头完成这一API。
是的，我们订正大众草案必要办理的一个成绩就是为一切现有JavaEE资本范例供应WebBeans作风的注进，包含远程援用EJB，它已成为一个大众特征需求。
这切实其实是一个成绩，我们也正在办理。我不能不说，当JCP在办理跨多个专家组的成绩时就会掉控。
我不确信假如WebBeans供应一个EJB的替换品是不是可行，但我以为这不是一个真实的限定。人们在SE情况中利用的是一种供应了EJBLite和WebBeans的集乐成能包的产物。不利用EJBLite而只用WebBeans对我来讲仿佛没成心义，由于利用如许一个完整产物的用户不能不构建本人的非尺度的事件办理情况、耐久化集成等等。集成后产物的范围实践上会比Spring如许的工具更小（可是比Guice要年夜），并且不必要良多设置。
固然，在社区中也存在一种心态：非感性地害怕任何与EJB有关的事变，不外坦白地说，假如想使用WebBeans，就不能不克制这类心思。
良多JCP成员，包含IBM，品评WebBeans初期草稿，以为它是一种新的“组件模子”。因而在公然草稿中，我们从头把其功效定位成一套用于现存EE组件范例的服务。这类做法部分化决了品评成绩，可是很分明不敷，因而我们延伸了299的公然审校工夫，以对标准做更多修正。
比来我们消费了良多工夫与IBM和其他EE厂商一同事情以办理他们的挂念。IBM方才到场了299专家组，正在努力于订正公然草稿。今朝在次要EE厂商已告竣了共鸣——299应当包括在EE6中，只需在一月尾公布的修正公然草稿中打消了他们的挂念。EE平台终极将具有一种尺度的、先辈的依附办理计划。
| 欢迎光临 仓酷云 (http://ckuyun.com/) | Powered by Discuz! X3.2 |