Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
新闻
为未来巩固BPM产品的功能
作者 Mark Little译者 刘涛 发布于 2008年11月9日 下午11时23分
据 Dennis Byron 最近的一项调查显示，所有BPM厂商都同意“业务流程管理（BPM）需要自动化地处理所有类型的业务流程。”工作流与直通式处理之间的区别，互联网与内联网的区别将会消失。这意味着...
[...]许多传统的ERP/ECM供应商为了提供BPM功能，已经将他们的工作流和集成特性展示给了所有人，而不仅仅是那些“知情者”。 即使你不购买他们的应用，许多供应商也愿意向你出售这些功能。这种心态变化的最好例子是SAP公司。他们作为ERP的巨人，认为将BPM限制为软件栈的一部分“就意味着限制其对真实业务的影响潜力”
正如Dennis所说，这些拥有集成服务背景的供应商，如Sun公司，正在将其旧式的整块程序分解为组合式的应用程序，以增加其覆盖范围和适用性。许多人均指出在过去几十年，迈向分布式系统（无论是服务组合或是对象组合）增加了对于编配的需求。如今，这更突显了BPM的关键性。这已不再是新闻，因为Joe McKendrick在2006年就提到:
需要提出的重要的一点是，SOA的不仅仅是一个IT项目。若要取得成功，SOA的所有权需要在企业内跨部门进行共享。迄今为止，还没能共享――它仍然主要是一个IT项目。作为一个IT项目，SOA将一败涂地，草草收场。IT在创建、维护、测试服务组件方面可以发挥作用，但SOA属于整个业务（而且必须由其来驱动）。SOA和BPM项目两者均需要从业务引导的角度来看待和管理，否则他们将陷入对立的筒仓...
回到原来的文章，Dennis相信：
IT部门应该将BPM看做是一个基于面向服务架构（SOA）的方法的“新的发展模式”。根据这种观点，其目标是为商业用户提供能够控制和可视化的功能，同时支持重用。在这种模式下，IT在提供数以千计的特定行业甚至企业生态系统的具体服务时不再成为系统瓶颈。
Tom Baeyens领导着jBPM，他在相关主题有如下观点：
我认为很多做BPM的人在谈到软件架构时缺乏对整体应用开发的洞察力。在我看来，应用软件是在筒仓内开发的。应用程序筒仓之间的连接可以由典型的SOA、WSDL、WS库得到加强。但是，BPM具有更加广泛的适用性，只能构建于服务之上。
Cordys在这个条目和相关文章中明显提到的是，推动下一代的BPM，如其业务层提供了某种程度的抽象和...
[...]从应用的控制中删除流程的方式与从中间件中删除数据类似。但是要把它做好，Cordys说，BPM必须支持业务流程的所有属性，其定义为
- 并行和串行地管理应用
- 管理人员密集型应用
- 从应用程序中分离流程
- 在防火墙内外均可工作
- 允许流程随着时间推移而改变
- 把流程交还给业务
正如我们之前所看到的，其他人可能在该列表中添加了不同的东西，或是删除了一些东西，例如对一系列的领域特定语言（DSL）的支持，更好的标准，和更好的分析工具。但是大多数似乎都同意的观点是，如何结合BPM与SOA是很重要的。 Gartner的分析师Mark Raskino在2007年是这样说的：
为了提高灵活性，多数公司需要有BPM附加之上的SOA架构。
但是， Steve Jones 指出，这往往是说起来容易做起来难：
要百分之分的一清二楚。如果你正在做BPM，然后只是说“步骤=服务”；然后你就开始做VISUAL Cobol，用服务替换掉函数调用。事实上，您使用WS-*或XML并不能将这些元素变成服务
从市场可以看到越来越多的SOA或BPM的厂商基于各种原因开始互相拥抱。但这导出了最后一个问题：在2004年，当被问及对BPM未来的远景时， Lanner Group的首席执行官Scott Dixon Smith说到：
在十年之内，他看到一个执行官在跟着PDA显示的重要步骤进行高尔夫练习。根据不同的结果，选择将是要么继续击球，去第18洞，或者致电另一位同事以寻求帮助。
查看英文原文：BPM Products Consolidate Functionality For The Future
刘涛，博士，毕业于西安交通大学，主要研究网络体系，现在主要从事多核环境下高性能算法的研究与开发工作。曾经进行过多个企业级软件的设计与开发工作。关心开源软件的发展动态，乐于使用开源软件。对前沿的系统软件与技术有浓厚兴趣。
没有回复
回复