论道WP(三):应用程序栏
作者通过具体翔实的例子介绍了Winodws Phone 7中应用程序栏的使用方式。
该内容已经被标记书签!
标记书签错误,请重试!

作者 Boris Lublinsky 译者 黄璜 发布于 2010年5月17日
Mauricio的新书《jBPM开发者指南》对Java开发者提供了完整的jBPM编程指导,其中包含了大量的现实案例。
这本书为Java开发者提供了非常详细的jBPM导引。Mauricio首先介绍了业务流程,业务流程管理和面向图编程,接着展示了这些概念是如何由jBPM来实现的。这本书展示了许多jBPM 实现的内部细节,并对开发者如何在项目中更好的利用jBPM提供了实际的建议。虽然这本书主要是基于旧的jBPM3版本而不是最新的jBPM4版本而编写 的,但其中许多讨论仍是适用于这一新发布的版本的。
对于那些不仅想要理解正式的jBPM语法,并且还想深入了解支撑jBPM的架构与实现的人们来说,这本书是一个很好的起点。而jBPM的开发总监Joram Barrez对该书的书评也值得参考。
Packt Publishing专为InfoQ读者提供了书摘,描述了jPDL语言的基本结构,这篇书摘是取自该书的《第4章:jPDL语言》。
InfoQ对Mauricio Salatino进行了采访,了解该书背后的创作动机以及他个人对于jBPM的使用经验。.
InfoQ:当谈论主流的业务流程管理时,你没有明确的谈到业务活动监控和流程仿真。你是否认为这些是BPM的重要元素之一呢?
MS:是的,对于所有的BPM实现来说,它们都是非常重要的概念和结果。我在这本书中没有包括相关的内容,是因为这本书是专注在当开发者转变到BPM模式这种思维的时候所走出的第一步。我这本书尝试解释一个开发者使用任何一个BPM框架时所要具备的所有概念。而我们运行了业务流程之后所进行的一切信息分析的工作实际上与业务分析和数据挖掘概念紧密的联系在一起。
InfoQ:在描述BPM历史的时候,你写到SOA的引入很大程度上对 BPM造成了混淆。你如何定义SOA与BPM之间的关系?
MS:我们可以将公共的BPM框架看作是编配面向对象架构内所有服务的一种粘合剂。我知道这种角度对于技术讨论来说是非常适合的。但如果我们将BPM作为一门学科来探讨,SOA与BPM毫无关联。我们必须明智的选择词汇,而不把术语与业务上下文混淆在一起。而这正是我这本书的一个根基之一:澄清BPM这一学科可用于任何地方,不管是使用不同的框架,或者仅仅使用纸和笔。
InfoQ:在你的书里你将BPEL定义为"一种支持异构系统以Web服务标准进行通信的集成语言。"这是否意味着你不认为BPEL是与jPDL类似的一种流程定义语言?此外,BPEL/SCA的绑定能简化了非Web服务部件的BPEL应用。你是否仍认为 BPEL是纯粹面向Web服务的呢?
MS:我认为BPEL是一种编配语言。它原本被理解为一种系统编配语言。BPEL是一种纯粹的技术语言,用于构建BPEL语言的语义与定义业务流程情况下的语义并不匹配。在这些业务情境中我们需要表达人们是如何进行日常工 作的;它如何实现没有关系,不管选用什么语言或者是否使用Web服务。
InfoQ:你的书中描述GOP与OO的区别,你提到了开发流程,三层架构等等。你认为最主要的区别是什么?
MS:再次强调,从技术层面来比较的,也许你不觉得两种范式有什么区别。但如果你想要使用流程图来表示人员的工作,你就会发现流程将能更准确地描述活动顺序。在书中我还提到,当我们使用OO范式的时候,要在 任何时间图形化地表示出我们的应用程序在哪里并不容易。而使用GOP,你可以明确的看到活动是如何地实时被执行的。当你需要向经理层报告所有的工作完成时,这一点非常重要。
InfoQ:在你的书中描述了几种实现决策句柄(decision handlers)的方案,包括决策句柄(decision handlers),表达式,等等。开发者在什么样的场合使用它们你有什么建议吗?
MS:在复杂的场景中我总是推荐使用决策句柄(decision handler)实现。这可让我们使用诸如JBoss Drools(一个接口引擎)这样的复杂工具来将传播流程执行的责任委派下去。责任的外部化将会使你的流程更容易维护并且保持其焦点。
InfoQ: 你在书中写到“记住jBPM是一个框架,而不是BPM引擎。它工作的方式与这一概念相去甚远”,但只给出了一个例子——持久化(它工作的方式又正好跟 BPM引擎相似)。你能不能说明一下jBPM与BPM引擎的不同?
MS:jBPM,如同其它的BPM框架一样(OSWorkflow,Drools Flow等等),是无状态的框架。我们不需要有一个庞大的机器和重量级的服务器运行在它们里面。每个想要使用业务流程的应用会在其自己所掌控的内存片段里 执行。对于长时间运行的流程,唯一的要求是一个可维护所有中间状态的数据库。通常,刚接触这一类框架的用户会认为他们将要在专门的机器上安装一个中心化的 业务流程引擎,但对于jBPM而言恰恰相反。我们只需要一个数据库来处理长时间运行的流程。
InfoQ: 尽管jBPM为用户表格定义提供了基本的支持,你在书中没有提及这一点。你是否不建议使用它?
MS:我通常建议定义和使用你自己创建的屏幕。这将提升用户交互和你的开发流程。基本上可以说这是因为你的UI开发者不需要去学习一种新技术,他们可以运用所熟知的东西,然后使用jBPM API来填充UI层所需要的所有信息。
InfoQ:你的书中也没有提及jBPM管理控制台。你觉得它是有用吗?
MS:我认为它仅对那些想要测试他们定义的流程的开发者而言有用。对于业务样例和生产环境我则一点 也不推荐。如同我在前一个问题里所提到的那样,我认为创建你自己的管理工具和为你的终端用户开发定制的UI才是良好的选择。
InfoQ:在人工任务(human task)里,你没有讨论用户指派(assignment)的泳道(swimlane),这样做的原因是什么?
MS:并非如此,我不得不删减一部分内容,否则这本书可能有上千页。泳道是一个重要的概念,但随着BPMN2这样的标准出现,解释jBPM3当中的泳道这样的概念可能会对采用新标准的人们带来误导。我试图只阐释会被应用到这一框架新版本当中的概念。这也是我在初始的章节宣扬创建你自己的BPM框架的原因之一。
InfoQ:你描述了在jBPM中处理信息的2种方式——对象变量和基本变量。对于什么时候两者之间某个更适用,你能提供一点帮助决策的参考吗?
MS:解释这两种处理信息的方式,其目的是给予用户其在特定情况解决问题提供决策的灵活性。以我个人经验,我注意到人们在已经有现有的使用JPA或Hibernate进行持久化的实体定义的数据模型时,通常会选择使用对象。所有的流程控制变量(通常是布尔标识)都会以普通的基本变量类型来保存。从高层次的规则来看,我通常会说:
InfoQ:你在书中描述了超级状态节点(Super state)和流程状态节点(Process state)。能否提供何时使用它们的参考意见?
MS:这很容易,“流程状态”节点让你可以创建非常高层次的流程。其定义可以被分解为更详细和低层次的流程然后再链接到一起。“超级状态”节点可以让你在同一个流程定义里对你的活动进行分组并有序地组织到一个逻辑组和阶段里。有了超流程状态节点你可以查询你所等待的流程阶段是哪一部分。
查看英文原文:Book Excerpt and Interview: jBPM Developer Guide。
感谢马国耀对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
精益软件开发方法因其对市场和交付的重视和在各种场景下体现出的适应能力正在获得广泛的关注。特别是在精益创业(Lean Startup)渐渐兴起和技术日新月异的今天,其"极端"的思想也变得越来越必要和可行。 InfoQ就此主题对他做了深入的采访。
3 条回复
关注此讨论 回复