大多数软件架构师对应用的组件化、面向服务架构(SOA)和工作流或者服务总线流程非常熟悉，也对组合应用如何将这些基本元素结合在一起非常熟知。实现松散耦合和应用敏捷化或许存在一些技巧，这些是实现SOA和复合应用的主要目标。

如果正确使用业务流程执行语言(BPEL)，可以为你的企业组合应用制定开发战略框架。要想使BPEL发挥作用，就不要以太细粒度的方式来使用BPEL，不要将集成性写入组件程序中，当想到组合应用程序时不要考虑分层次的问题。要使它正常工作，重要的是从概念入手，然后采用有组织有计划的方法开发研究。

BPEL的概念

从通过标准化接口相连接的Web服务组件中形成了组合应用。这种从属关系非常好理解，但是组合应用的抵押关系也同等重要，却经常被忽视。

精心设计的组合应用可以被视为Web服务、组件以及用于构建高层次的流程。该连续性组合模型可以极大缓解组合/SOA开发以及应用生命周期管理(ALM)的负担。同时也可以应对BPEL最大的挑战——执行效率。

BPEL以聚合粗粒度元素而为大家所熟知，这就意味着其支持不需要许多工作流交换的业务流程。你越深入研究组件集成，越多地管理工作流，要实现BPEL较好的性能就越困难。

以下两种情况能够限制BPEL执行性能：

1）使用BPEL整合低级别的应用组件，这样的组件工作流非常频繁，性能也十分重要。

2）将互相有连接的组件写入整合系统中。

问题出现在业务流程粒度与软件组件粒度之间存在差异。

使用BPEL编辑Web服务应该要相当粗粒度的，以避免工作流程中产生惊人的费用，避免应用编排和ALM过程中产生复杂因素。许多情况下，这会与软件设计产生冲突，这种情况的组件化一直处在低级别的水平。为了避免此类事情的发生，记住BPEL服务的一般模型就是一种链接到下属功能服务的编辑组件。

甚至通过直接约束没有进一步BPEL流程的组件，使用更有效的技术也有可能建立编排组件。采用这种方法，多细粒度软件组件可以转化为粗粒度、适合BPEL的服务，然后工作流程中会获得最大的灵活度。

这个技术依赖于BPEL的递归或分层性质。正如其他编程语言一样，BPEL也可以创建服务。这就意味着，其可以创建BPEL中自定义的重用组件。即使你选择做BPEL服务中各层次的全面服务总线或者工作流引擎集成，从组件组中创建BPEL服务也有一定好处，因为不管它们是哪个系统的组件都可以确保以相同的方式进行编排和组织。

经验丰富的应用团队和企业架构师能够从服务和组件两个方面进行分析，从而创建最优化BPEL组件。首先特别是当制定了正式的联邦IT计划后，EA定义了业务流程标准。由于大多数业务流程并不期望每分每秒都进行协同操作，这种水平的定义对于使用BPEL和服务总线编排而成的粗粒度流程来说是一个很好的起点。

BPEL的开发

与此同时，为了实现基于重用目标、未来可用性以及敏捷性的最优化目标，应用架构师可以检查组件可用性和开发计划框架。这种细粒度组件几乎总是太过于细粒度化而不能直接映射到BPEL服务总线整合中。

然后团队可以进行会议讨论，定义如何实现中间对接。一个完美的EA计划对于创建工作流间的粗粒度组件来说是非常重要的。了解组件映射到粗粒度BPEL服务中的应用程序架构师可以确定，使用BPEL服务的组件工作流是如何能够得到有效地支持，从而足以维持任何直接绑定到BPEL工作流中的应用程序性能。

记住，直接绑定总会降低灵活性，但是使用编排组件而不是内部组件间的间接引用会有助于减少负面影响，你仅需要改变一件事就可以对BPEL服务内部工作流进行重组。那就是绝对不要直接从一个组件中引用另一个组件。

这与可能会将BPEL服务中移动的组件组作为一个单元的方法有相同之处。考虑采用创建绑定组件组的方法从这些组件组中创建高水平BPEL服务。BPEL会定义群组的接口和属性，在完全从组件中进行创建的开发人员面前隐藏了其复杂性。

你可以使用任何传统方式在该流程中执行ALM整合。在较高的水平上，使用联合IT的定义指导BPEL组件设计，并通过粗粒度服务调整ALM与EA间的管理，会使该过程变得更加容易。如果在组合应用设计阶段应用架构师定义了一套标准，那么无论从最高水平的EA还是到应用的开发及部署，对于政策及验证过程的实施都非常容易。