表格.1开源选择标准和总体原则
| 标准 | 说明 |
| 可行性 | 产品是否被广泛使用，是否有强大的用户社区?解决方案是否有详细配套文档?项目有没有足够的开发资源？ |
| 架构 | 产品的架构是否和其他我们在评估中的产品相辅相成？是否有详细文档并合乎逻辑，是否遵从通用的最佳时间和模式？ |
| 监控和管理 | 产品是否提供默认可直接使用(off-the-shelf)的监控和管理工具？y由于我们评估都是java产品，它是否支持用于测量和监控Java应用程序的JMX标准? |
| 扩展性 | 默认的解决方案是否能被扩展，增加新的功能？有没有可插拔的框架以增加功能？ |
| 真正的开源 | 这是个敏感的话题，不过我们只考虑那些用常见的开源协议，如GPL,LGPL、BSD、Apache或Mozilla Public License发布的产品。我们想尽可能避开那些对使用或修改有限制的”免费”或”社区版”。 |
表格.2 BPM评估标准
| 标准 | 说明 |
| 简单性 | BPM解决方案，尤其是那些商业厂商的产品，从历史上看，学起来通常很复杂，部署起来甚至更有难度。大量旁证显示，许多昂贵的方案最终都被”束之高阁”，从未实现项目预期的承诺。我们想要的学习、发布和管理起来都很简单地方案。 |
| 轻量/可嵌入 | 和简单性有一定的关联，这评判标准值的是如果需要，可以将BPM”引擎”直接包含到应用程序中，例如，你在构件一个新的贷款处理应用程序时，可能想直接将工作流引擎嵌在里面，而不需要在外部来管理。 |
| 流程节点 | 是否所有的标准流程节点都直接可用？这可能会包括决策/条件路由、人机交互任务支持、分支/分离、联接/合并等。有没有外调(callout)节点或能力去调用Java和Web服务？ |
| 事务相关需求 | 有没有审计、日志和回滚/补偿等特性?是否长时间运行的事务?是否支持角色和用户? |
时间： 2024-11-15 00:34:25