BPM迁移到SOA和Web Services，引入了一个服务层，如图2所示。服务层包含支持特定业务域的业务服务线、可以跨多个业务域共享的可复用技术服务以及Web Services平台。该平台允许以各种独立于底层服务和技术平台的方式定义和利用服务。

　　服务层为业务处理层提供了理想的平台，如图3所示。原因如下：

　　1.业务服务线提供粗略(Coarse-grain)的业务功能，该功能能够映射到业务处理中的业务任务。

　　2.业务服务线的服务协议为访问服务提供明确的接口，因此,业务处理不负责理解底层应用程序和技术平台的任何细节。

　　服务层提供的服务注册和服务发现设施确保业务处理层能够根据需要自动定位和访问服务。

　　3.服务级数据模型是基于业务域定义的，并且独立于任何特定应用程序使用的数据模型。此外，XML是在业务处理任务之间和业务任务调用时交换数据的规范格式。因为XML是底层应用程序使用的独立于内部数据格式的格式。

　　4.服务级安全模型提供单点登录和基于角色的访问控制，以确保处理任务是授权给用户服务的，并且它能让服务处理层无需再处理底层应用程序和技术平台提供的各种安全接口。

　　5.服务级管理模型可以生成有关服务使用的运行时数据，这些数据可供业务处理层中的业务活动监控(BAM)工具使用。

　　过去的大部分系统都不支持基于SOA和Web Services的服务层。没有服务层的BPM复杂且脆弱，因为处理层需要直接访问底层业务应用程序，如图4所示。

　　该方法更加复杂，因为处理层必须使用一个或多个应用程序(例如API、消息或数据库表)定义的接口直接访问既有应用程序。这需要实现者学习这些应用程序接口，并且需要向业务处理添加一些步骤，供定义不佳的应用程序接口使用，或者用于将特定应用程序的数据转换为服务处理可以使用的规范格式。

　　该方法也更加脆弱(即更容易被破坏)，因为处理是与特定应用程序和应用程序接口紧密耦合的,这意味着像安装应用程序新版本之类的操作都可以破坏访问它的处理。这种紧密耦合也让该方法很难更改。例如，用另一个供应商的新应用程序替换既有应用程序,需要修改访问原应用程序的所有处理。

　　实现不带服务层的处理层限制了BPM的选择范围。

　　图1 典型的应用程序和技术结构

　　图2 基于SOA和Web Services的服务层