David Nuescheler谈JCR和REST
在这篇访谈中，Day公司CTO和JCR规范组长David Nuescheler讨论了JCR（Java内容仓库标准）的优点、JCR与诸如Atom/Atom发布协议这种API之间的区别、JCR与REST的联系，以及一个新的Web框架——Apache Sling。
新闻
你的架构应该关注SOA，还是BPM？
作者 Steven Robbins译者 黄璜 发布于 2008年5月19日 下午8时40分
SOA在时髦术语标签云里面风光无限的同时，BPM的名气正变得越来越响。当组织逐渐明白想从IT投资中获得收益需要驯服组织间各种各样的流程时，BPM在IT圈内圈外正得到重视，认同和关注。对你的构架来说，哪一个更重要呢？以BPM作为SOA平台，又或是将BPM作为指导实现SOA的基本理念，这两个概念之间的联系正变得越来越紧密。BEA的Dain Hansen最近发表了“SOA整合的成功蓝图”，对如何在组织中实施SOA给出了详细的指导。在讨论过程中，Hansen指出了BPM-SOA整合的重要性。
我们在谈IT和ERP系统的整合的时候，也需考虑它们对业务分析师或业务部门（LOB）的影响，因为是他们真正使用这些数据和服务来完成日常业务。这两个往往看似矛盾的元素需要通力协作才能成为一个完整的整合解决方案。当SOA和BPM都表现良好时，我们才能看到巨大的收益。此时，不仅能使IT和业务部门中各角色协调一致，而且还能以两个阵营都能成功管理的最优方式实现流程……Quinton Wall，同样来自BEA，最近谈到了将BPM和SOA相结合以最大化业务的机动性。Wall认为组织可以在SOA基础上综合利用BPM工具来达到IT和业务的一致性：“技巧在于使业务端的改变以一种受管制的方式进行，并削弱它对IT的依赖性。” 这意味着，BPM能够让业务部门的执行者充分享用服务和服务组合好处的同时，减少了IT的介入。
一旦在SOA整合过程中实现了自动化的业务流程模型，业务分析师就可通过集成的业务活动监控功能获得运行时反馈，触发一个优化过程。这让业务使用者能实时观察到哪些流程需要改进。一旦识别了改进环节，业务分析师就能同时更新模型和业务，此时开发周期又进入了下一个循环。这种迭代式业务——整合循环实现了真正的业务转型与优化。
为了达到这样的收益，SOA和BPM需要以这样的方式来整合：组织里的用户需要有公共统一的工具来共享元数据、治理和管理信息，并最终优化业务流程与流程翻译方法（将它们翻译成后端整合）之间的互操作性。
BEA的建议是从“SOA优先”的立场所作出的，并假设组织已一定程度的面向服务化。其它几位则是以业务流程为中心的角度来考虑BPM和SOA的联姻。
Rich Seeley讲到了特拉华电力公司的SOA实施以及IT副总裁Gary Cripps是如何让它成功的。Cripps表示，业务流程分解方法在这一过程中发挥了巨大作用。
“我一开始就将所有的流程进行了分解”Cripps解释到，“我的发现是，参与这样级别的一个SOA项目，我们花了百分之五十五的精力在定义流程上。百分之五十五，这令我很吃惊。百分之二十的时间是用于编写代码的。剩下的百分之二十五花在了测试和实施上。”Seeley同时指出，在转向SOA的进程中，业务分析师的角色发生改变了。引用自iTKO公司首席科学家John Michelsen的说法，Seeley写道，在SOA实施中受影响最大的是业务分析师需求分析的职责，而不是IT部门开发组件的职责。
这对那些考虑SOA的中小企业来说是个好消息，Cripps说道。业务流程的界定和建模可以由包括部门涉众在内的核心团队来完成，百分之二十的编码工作则可以外包。
在内部，SOA团队成员转变了他们思考应用的模式，开始按照业务流程来思考，Cripps说。“当我们转为面向服务时，就我的团队成员而言，这真正地提升了他们的知识。因为理解一个跨多个部门的特定事务的业务流程和业务规则需要花相当大的努力。”他讲道。
“我认为说编码人员个体受影响最小是公平的。因为他或她所做的不外乎拿到需求，构建组件，测试组件，再将组件插入到更大的系统”他说到，“这和五年前所做的事没任何区别。所以，具有讽刺意味的是，开发人员也许成了受SOA影响最小的人。”在这两个例子中，Seeley都引出了在建设和实施SOA时业务流程管理和分析的重要性。
Dennis Byron指出BPM现已名副其实地属于软件堆栈的顶层。Byron的观点是，BPM已经不再是集成层的一部分——这是从IT立场出发的定位——而是上升到了整个软件堆栈的顶级。从业务角度来看整个软件堆栈，IT可以“将BPM视为一种建立在面向服务架构（SOA）方法学基础之上的‘新型开发范式’”。
为了找到“BPM还是SOA？”这个问题的答案，Neil Macehiter 和Neil Ward-Dutton阐述了在现代组织中这两个概念分别扮演了什么样的角色。抛开了“BPM是自顶向下，业务驱动的创新；SOA是自底向上，技术驱动的创新”这种传统观念，Macehiter和Ward-Dutton阐述了“‘面向服务同时面向流程；自顶向下同时自底向上’的立场是如何以一种更全面的视角来消除业务与技术架构的分歧。”紧接着这些陈述Macehiter和Ward-Dutton展示了流程和服务的概念是如何通过‘输出（outcome）’统一起来的:
输出（outcome）就是预期到的结果。一个最高层输出（outcome）可以是一个组织的核心价值，财务表现等等这样的东西。在这一层次，输出（outcome）可能和使命宣言直接联系。 再低一点的层次输出（outcome）可以是一些操作结果——比如“产品已经交付”。服务是对达到输出（outcome）的承诺。流程是完成输出（outcome）的手段。他们俩这样总结了对BPM/SOA的观点：“事实是，输出（outcome）是硬道理，服务和流程是达成目标的一体两面。”
查看英文原文：Should your architecture focus on SOA or BPM?
译者简介：黄璜，2007毕业于重庆邮电大学计算机学院。现从事Java Web开发，供职于成都ISSC,熟悉Struts,Spring,ibatis，关注语义网，SOA，云计算等领域。个人主页：http://www.chinacomputing.org， 联系方式huangh@cn.ibm.com。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。
BPM和SOA一点都不冲突，这个篇文章的标题明细带有煽动性。
发表人
Ming Yang
发表于
2008年5月20日 上午5时50分
Re: BPM和SOA一点都不冲突，这个篇文章的标题明细带有煽动性。
发表人
gem fox
发表于
2008年5月20日 上午8时2分
Re: BPM和SOA一点都不冲突，这个篇文章的标题明细带有煽动性。
发表人
Huang Huang
发表于
2008年5月20日 下午10时28分
Re: BPM和SOA一点都不冲突，这个篇文章的标题明细带有煽动性。
发表人
gem fox
发表于
2008年5月21日 上午12时45分
4 条回复
回复