Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
新闻
BPMN 2.0争论继续
作者 Boris Lublinsky译者 黄璜 发布于 2008年7月22日 上午8时42分
关于BPMN的未来之争还在持续中。OMG（负责BPMN以及其它的BPM标准）的BMI任务组联合主席Fred Cummins，就目前BPMN关于解决BPMN与BPDM之间差异的一个提交版本以及对BPDM复杂性的关注，发表了他的看法：
BPDM是OMG所领导发展的业务建模语言套件中的一员。例如，SBVR（Semantics of Business Vocabulary and Rules）支持对业务概念的语义以及对包含这些语义的业务规则的表达进行建模。BMM（Business Motivation Model）为捕获战略计划模型提供了框架支持。OMG的业务建模与集成任务组的一个战略目标就是发展一个完备的业务建模标准集以更加有效地支持企业计 划、分析、设计与提升。其结果就是，BPDM有着健壮的抽象元模型来支持BPMN建模概念。这一抽象元模型定义了基本的概念，其中很多概念在其它业务模型中也有，只是上下文环境不同而已。
在BPDM当中，这些概念构成了一个一致的基础来支持对业务流程建模而不用考虑特定的建模工具。粗略看来，Fred作出如下陈述：
BPDM元模型看似复杂。然而，应该理解的是，正是这一复杂性为具体元素提供了精确的定义。这些抽象概念不会表现为附加的BPMN图形，也不会作为附加的XML概念来表达... 总的说来，BPDM元模型的复杂性使得这一规范更加精准和健壮，并为未来开发一致的、互补的业务建模功能提供了支持。该复杂性并不会使得业务流程建模对于用户来说更加繁杂，也不会为工具的开发商带来不必要的限制。
Bruce Silver对Fred的此番言论回应到：
我必须要说在我对BPDM的一长串抱怨当中，元模型的复杂性并不是首要的。更为严重的是注解次之于元模型的这种看法，以及只要底层的元模型描述支持、用户就可以自定义语义这个事实。
Nick Malik讨论到高级的BPM语言/注解是否最终会实现业务流程创建和实现的完全自动化：
在那些“忠实信徒”看来，我们可以给终端用户那些漂亮语言中的一种（BPMN或BPEL），他们就会写出自己的软件来，IT开发者都可以裁掉了
Nick指出尽管这些语言常常能简化实现，但对于业务流程的实现来讲，它们却并不能完全取代IT开发者（以及一个恰当的开发过程）：
...BPM语言是对人类行为的建模。而“成为代码”的是对机器行为的陈述。我们对于机器必须要比对人类更明确一千倍，所以我们开发的代码就需要比为人类开发多出一千倍。
遗憾的是（尽管是出于好意），Nick将BPMN与BPEL——二个目标完全不同的语言——混为一谈了。因此马上引来了Bruce Silver的回复，指出了这一错误，但在总体的结论上却达成了一致：
让我们假设Nick对于BPM是什么还是有一定了解的，尽管BPMN本身并不能产出实现（它只是对活动流的建模）——BPEL却是实实在在的开发语言，并 不是针对“终端用户”的。（也许Nick认为只有Java程序员才算“真正”的开发者？）基于BPMN的BPM套件确实提供了一种敏捷的实现风格，业务人 员和开发者在流程的自动化上紧密地协作。
基于这些争论看来，显然，BPMN不管是在所扮演的角色上还是其自身的方向上仍然是不确定的，或者说至少是没有完全达成一致的。这一不确定性会显著的阻碍BPM在设计与开发上取得进步。
查看英文原文：The BPMN 2.0 Debate Continues
连接出错了
发表人
jie jeff
发表于
2008年7月22日 下午11时9分
Re: 连接出错了
发表人
Huang Huang
发表于
2008年7月23日 下午8时37分
2 条回复
回复