面向服务架构（SOA）的核心是面向网络架构（WOA）以及以业务为中心的Web 2.0，我们称其为Enterprise 2.0，这是对企业mashups的称呼。它被定义为以Web为基础的用户接口环境中被治理以及被管理服务部分。尽管这样的应用在企业中范围相对有限，但企业mashups仍然可以成为SOA的主要驱动力量。

　　实际上，是mashups限制了这些程序的应用范围：使用一个mashups需要建立一个mashups，换句话说，就是让业务用户管理mashups的功能即准许用户在使用mashups的过程中创建应用。这个想法听起来不错，但是IT真正希望程序使用者建立并修改这些程序的时候有多少呢？

　　像这种“使用即创建”的应用，我们称其为情景应用。情景应用是为了满足一部分人群短期需求而专门设计的应用。短期内在某个特定的情景下可能会很有用，但是不会产生长期的效益。许多情景应用都是数据mashups，通过把不同的数据源信息混合在一起，用户在mashups中创建应用以便满足特定的业务需要。

　　情景应用和数据mashups的结合会影响企业mashups的全部力量，在SOA环境内编排服务的关键就是要支持灵活的业务流程。数据mashups主要是一个将数据混合在一起的流程：要保证其是一个有用的流程，不过它只是企业想要自动化的众多业务流程中一个有限的实例。我们可能把这样的流程看做是一个“流程mashups”，而不是一个数据mashups。那么什么是流程mashups，你为什么需要流程mashups，在企业环境下你如何实施流程mashups？

　　一个业务mashups实例

　　ZapThink在Licensed ZapThink Architect课程上一直在谈论流程mashups。我们在课上使用的是呼叫中心应用这个例子。由于“swivel-chair集成”问题，呼叫中心也是面向服务业务流程（SOBAs）诞生的地方，它是用于实施业务流程的的一整套服务组合。传统呼叫中心的代表需要访问多层系统才能完成工作，这些系统主要包括主机绿光屏，用于客户关系应用的客户/服务器接口，用于公共门户或者网站的网络接口，以及为手机系统量身订做的接口。为了满足呼叫客户的需求，CSR必须在两个屏幕之间不停旋转，这种方法很费时间，而且容易出错。

　　当然，使用SOA效果更佳，通过将应用抽取为服务，呼叫中心可以为CSR建造一个流线型的灵活接口，这样CSR就可以解决用swivel-chair集成问题了。实施客户服务SOBA支持这样的接口非常简单，现在许多呼叫中心都实施了SOA。

　　实施SOBA只是其中的一部分，因为CSR只是这个阶段的一个部件。如果我们看一下其它组件，就会发现一个更为复杂的应用布局图，正如如下的图表所示。

　　运转中的流程mashups

　　上面的图表向我们展示了单独的几个人是如何以不同的方式和客户服务SOBA发生交互作用的，这主要取决于它们的作用：

　　·执行程序（1）会对呼叫中心的关键效绩指标感兴趣，即呼叫时间（越短越好）客户满意度（越高越好）。这样关键效绩指标就可以通过管理仪表板和SOBA发生交互作用，通过管理仪表板，人们可以看到这些关键效绩指标。

　　·呼叫中心管理员（2）负责处理呼叫中心执行的业务流程。换句话说，呼叫中心管理员负责CSRs所执行的脚本，并且要注意SOBA是如何支持脚本描述流程的。管理员同时也要负责KPI仪表板，以及SOBA实施的流程流只读窗口。基于老板的意愿，管理员还要适时地调整呼叫中心流程，并将这些变动上报给业务分析师。

　　·在这个实例中，业务分析师可能是唯一有能力改变SOBA性能的人。换句话说，业务分析师是呼叫中心拥有mashups接口的人。按照管理员的指令，它会直接在SOBA mashups的接口中改变SOBA的性能。

　　·CSR（4）有可能是这个程序最高级的用户，因为在运行不同呼叫中心脚本的同时，它要求SOBA的全部功能都要满足客户的需要。应该不会改变应用的功能。

　　·但是，用户会和SOBA发生交互作用，这是因为它支持共有网站（5）或者是因为他们直接通过手机呼入了呼叫中心（6）。用户在网站上的阅读和写入权利是有限的，但是这仍然不能改变应用性能。