Orchestra Designer项目来源于2009年OW2 开源比赛题目,目标是为OW2上的开源BPEL引擎Orchestra提供一个基于Flex技术的在线工作流编辑工具,并与Orchestra的Web 2.0管理控制台集成。该建模工具针对非技术人员,采用一种比BPEL更面向业务、更直观的图元作为建模基础,生成的模型可以在后台转换成BPEL输出,并部署在BPEL引擎上运行。开发人员希望本项目不仅仅是为Orchestra引擎定制开发,而是可以依托实验室在中间件应用领域积累的丰富经验,对电子政务、电子商务、遥感卫星和生物计算等领域的业务工作流建模进行支撑。
Orchestra Designer项目于2009年5月通过获得OW2开源软件比赛第一名与法国BULL公司建立合作关系,并在Trustie平台(可信的国家软件资源共享与协同生产环境)上作为开源项目且依照LGPL V3标准发布至今,已成为最活跃项目,并凭借12666次的下载量(数据截止日期:2011年3月21日)项目中排名第一。
==================================================================
2011年3月19日 Orchestra Designer 3.4版本发布
1.细化了新建向导;
2.增加三类图元,分别为xx,xx,和xx
3.重写协同部分,增强协同稳定性,减少了协同中数据传输量。目前新的协同模式支持以下操作:
添加图元、删除图元、修改图元大小、图元移动、修改连线标注、修改图元名称、图元复制-粘贴
4.增加了传输数据完整性校验功能,完整性校验指,会对比数据发送时和接收时的MD5码,若不一致则请求重新发送。
5.添加了用户关闭浏览器时自动注销功能。
6.优化了界面布局
PS:
由于项目原因,后期更新的版本可能不再提供源代码,仅提供可运行版本。另外由于人员以及需求调整,项目暂时进入休整期,暂停进度。
-------------------------
版本历史:
2010年9月16日 Orchestra Designer 3.2版本发布
功能更新:
新版本更新分三大部分:
界面部分:
添加了界面登陆、注册
添加了双击标签最大化的功能
添加了协同参与者列表
可以通过Menu-Option-Views里的选择栏来控制功能标签的显示与隐藏
建模部分:
添加了操作回退
添加了操作重做
本版本新添加了实时协同建模功能,具体为:
协同令牌机制
普通协同模式
标注协同模式
比较协同模式
-------------------------------------------------------------
2010年4月20日 Orchestra Designer 3.0.3版本发布
Updates:
新版本增加了多用户协同建模的功能,当多个用户对同一个流程模型进行操作时,某个用户的保存操作会将流程模型的修改同步到其他用户的显示界面上。此外,新版本还增加了BPMN的视图(由法国BULL公司提供)。
-------------------------------------------------------------
2010年1月7日 Orchestra Designer 3.0.2版本发布
Updates:
新版本增加了用户下载BPEL文件,以及与JUDDI服务器交互的功能。
-------------------------------------------------------------
2009年11月26日 Orchestra Designer 3.0.1版本发布
Updates:
此版本为服务器版,所有工程、文件夹以及文件都存储于服务器的目录中,因此多个建模用户可以共享相同的模型文件
-------------------------------------------------------------
2009年8月24日 Orchestra Designer 3.0版本发布
-------------------------------------------------------------
2009年7月20日 Orchestra Designer 2.8版本发布
Updates:
1、MVC代码框架的重构
2、工程、文件夹和文件的重命名
3、图元的全选、复制和粘贴
4、流程图形到BPEL转换的优化
5、图元属性的补充
6、图形文件与BPEL文件的关联
7、BPEL元素与属性的颜色区分
-------------------------------------------------------------
2009年7月1日 Orchestra Designer 2.4版本发布
Update:
1、工程、文件夹和文件的创建及修改
2、资源树的实时刷新
3、图元的拖拽、移动、删除和重命名
4、流程图形到BPEL的转换
5、新增BPEL视图
6、解决本地不能运行的问题
-------------------------------------------------------------
2009年6月18日 Orchestra Designer 2.0版本发布
Updates:
1、界面重新布局,改变整体风格,添加工具栏,工程视图和UDDI视图
2、支持流程的图形视图和XML视图
3、支持新建工程、新建文件夹和新建流程文件
4、支持画图布局栅格
5、将BPMN的图元替换为三类不同层次的图元:Basic、Business和BPEL
6、程序架构根据Cairngorm MVC框架重构
-------------------------------------------------------------
2009年5月27日 Orchestra Designer 1.0版本发布
Updates:
最基本的建模功能实现
To have people successfully develop or use your package, you need to ensure that all the necessary files are checked into your source control system. Required Files The following files must be checked
项目落户GitHub后,一定希望有越来越多的人能参与其中。GitHub提供了包括传统的问题追踪系统、维基,还包括了分布式版本控制系统特有的协同工具。 4.1. Fork + Pull模式 4.2. 共享版本库 4.3. 组织和团队 4.4. 代码评注 4.5. 缺陷跟踪 4.6. 维基
要想团队协作使用Git,就需要用到Git协议。 3.1.1. Git支持的协议 首先来看看数据交换需要使用的协议。 Git提供了丰富的协议支持,包括:SSH、GIT、HTTP、HTTPS、FTP、FTPS、RSYNC及前面已经看到的本地协议等。各种不同协议的URL写法如表15-1所示。 表 15-1:Git支持的协议一览表 协议名称 语法格式 说明 SSH协议(1) ssh://[user@]ex
如果没有Topgit,就不会有此书。因为发现了Topgit,才让作者下定决心在公司大范围推广Git;因为Topgit,激发了作者对Git的好奇之心。 4.3.1. 作者版本控制系统三个里程碑 从2005年开始作者专心于开源软件的研究、定制开发和整合,在这之后的几年,一直使用Subversion做版本控制。对于定制开发工作,Subversion有一种称为卖主分支(Vendor Branch)的模式。
分布式的版本控制会不会造成开发中的无序,导致版本管理的崩溃?对于习惯了如Subversion这类的集中式版本控制系统的用户,脑子里一定会有这个疑问。 作为分布式版本控制系统,每一个Git克隆都是一个完整的版本库,可以提供一个版本控制服务器所能提供的一切服务,即每个人的机器都是一台服务器。与之相反,像Subversion那样的集中式版本控制系统,只拥有唯一的版本控制服务器,所有团队成员都使用客户端与
项目的版本库某些情况下需要引用其他版本库中的文件,例如公司积累了一套常用的函数库,被多个项目调用,显然这个函数库的代码不能直接放到某个项目的代码中,而是要独立为一个代码库,那么其他项目要调用公共的函数库,该如何处理呢?分别把公共函数库的文件拷贝到各自的项目中,会造成冗余,丢弃了公共函数库的维护历史,显然不是好的方法。本节要讨论的子模组协同模型,就是解决这个问题的一个方案。 熟悉Subversion
Android是谷歌(Google)开发的适合手持设备的操作系统,提供了当前最为吸引眼球的开源的手机操作平台,大有超越苹果(Apple.com)的专有的iOS的趋势。而Android的源代码就是使用Git进行维护的。Android项目在使用Git进行源代码管理上有两个伟大的创造,一个是用Python语言开发名为repo的命令行工具用于多版本库的管理,另外一个是用Java开发的名为Gerrit的代码
在本篇的最后,将会在另外的一个角度上看Git版本库的协同。不是不同的用户在使用Git版本库时如何协同,也不是一个项目包含多个Git版本库时如何协同,而是当版本控制系统不是Git(如Subversion)时,如何能够继续使用Git的方式进行操作。 Subversion会在商业软件开发中占有一席之地,只要商业软件公司严格封闭源代码的策略不改变。对于熟悉了Git的用户,一定会对Subversion的那种