应用JSF、Ajax和Seam开发Portlets（1/3）
.gif)
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目，怎样配置一个JSF应用去使用JBoss Portlet Bridge，以及JBoss Portlet Bridge所具备的功能。
新闻
论SOA中仲裁的价值
作者 Hartmut Wilms译者 胡键 发布于 2007年5月29日 上午12时44分
Nick Malik的文章“仲裁在SOA中的价值”引发了一起有趣的讨论。在关于这个主题的第一篇博客帖子中，他问道：“如果消息不能被仲裁，那它还是面向服务的吗?”。
Malik认为仲裁能力是任何SOA的关键益处之一，“能够拦截从A点到B点去的消息，并对那条消息做出反应而不通知那个管道的任意一方”。以他的观点，仲裁以技术中立的方式共同工作，它要求“我可以用一套完全不同的技术系统替换系统A，并且只要消息是一致的就不影响系统B”。
按照Nick Malik所说，“SOA是用于企业应用集成的架构”。仲裁通过它的替换原则支持集成。通过比较架构性的仲裁和面向对象设计中的工厂模式，Malik解释了这一观点，并引用了Liskov替换原则：
能够增加仲裁，为我带来了一些相当特别的便利。就像在OO设计中，工厂给与我Liskov替换原则的便利，在消息传递设计中，仲裁为我带来了替换的便利。仲裁能够观察到从一个贸易伙伴传递到另一个贸易伙伴的消息，并基于消息的内容采取行动（假设我已经正确地获取了它）。
Udi Dahan并不同意Malik的EAI话语，以及他关于通过仲裁编排服务的想法：
尽管我非常同意Nick所说的OO仲裁是依赖注入变种的观点，以及在消息传递方面扩大那些相同的概念是正确的做法，我还是对仲裁领域中的编排有疑问。这些“战术变化”需要在顶层（即业务级服务策略）的上下文中完成。这意味着所有逻辑应归入一个服务。服务间的“网络”只是一个“哑”网络，没有任何业务逻辑，只剩下技术能力，如知道将消息路由到哪个物理服务器去。
JohnCJ在Malik博客帖子的评论中表达了对于仲裁价值的看法，认为仲裁不应该被视为面向服务的通用需求。他认为：
- “要求仲裁会鼓励消息携带更多的上下文信息”。
- “除了请求-响应和发布-订阅，仲裁使消息交换模式极大地复杂化了”。
- “仲裁要求仲裁系统对于它所拦截的消息的语义至少有些理解”。
在再论仲裁的价值中，Nick Malik就这些观点一一做出了回应。他指出上下文的信息并不会使消息膨胀，而是“为了表示我们在企业EAI场景中所传递的中立规范的业务文档，从而必须增加单条消息大小的这个做法，只是取得业务敏捷性的小小代价”。关于第二个争论，Malik给出了一个非常好的类比：Joe是银行职员，他拿着他的休假申请表去找他的老板并等待批准。他的老板只是这个申请到达最终接收人那儿整个过程中的众多仲裁者之一。Joe并不知道也不关心这些仲裁中的任何一个。他只关心结果——他的申请是否被批准。批准过程可以在任一步被修改而不改变这一过程的业务语义。因此，Malik认为“几乎所有有价值的长运行事务都必须能够仲裁，这是为了让它们可以被组合、被再组合，以及被编排”。最后，他认为共享消息的语义需要依赖仲裁功能。在任何情况下，他都把那个点声明为“风险，而不是成本。它是在任何项目中都会出现的风险。在定义良好的SOA基础设施中，这个风险比起我们试图通过在3个计算机系统中输入数据来组合一个手工业务过程要低得多”。
Nick Malik总结说：在他的观点中，仲裁并不是所有服务都必须的，但是“它是被设计交付可组合性（即业务敏捷性）的面向服务架构所必需的”。
查看英文原文：On Intermediation in SOA。译者简介：胡键，自2000年西安交通大学硕士毕业后一直从事软件开发。2002年开始使用Java，在项目开发中经常采用OpenSource工具，如Ant、Maven、Hibernate、Struts等，目前正在研究信息集成方面的规范和技术。可以通过jianhgreat AT hotmail.com与他联系，或访问博客：http://foxgem.javaeye.com/。与InfoQ中文站分享内容，请邮件至china-editorial@infoq.com。
没有回复
回复