我们知道，集成领域是不断变化的。Web的影响以及敏捷实践的潮流正在挑战我们的关于“良好的集成由什么构成”的观念。集成（integration）并不是一种夹在系统之间的专业活动；与此相反，现在，集成是成功方案里的不可缺少的一部分。
然而，仍有许多人误解并低估Web在企业计算中的作用。即便是那些精通Web的人士，也常常要花费很大力气才能懂得，Web不是关于支持XMLoverHTTP的中间件方案，也不是一种简易的RPC机制。这是相当遗憾的，因为Web不是仅能提供简单的点对点连接，它还有更大的用处；它实际上是一个健壮的集成平台。
工作流（workflows）是企业计算的主要特征，它们基本上都是用中间件实现的（至少在计算方面）。工作流把一项工作（work）划分为多个离散的步骤（steps）以及触发步骤转移的事件（events）。工作流所实现的整个业务流程常常跨越若干企业信息系统，这给工作流带来很多集成问题。
Web若要成为可用于企业集成的技术，它就必须支持工作流——从而可靠地协调不同系统间的交互，以实现更大的业务能力。
Gregor是采用EAI技术（如面向消息的中间件）来讲解星巴克案例的，而我们将采用Web资源（支持统一接口的可寻址实体）来讲解同一案例。实际上，我们将展示Web技术何以能够具有跟传统EAI工具一样的可靠性，以及何以不仅仅是请求/响应协议之上的XML消息传递！
首先，我们很抱歉擅自设想了星巴克的工作流程，因为我们的目的并不是精确无误地描述星巴克，而是用基于Web的服务来讲解工作流。好的，既然讲清楚了这一点，那么我们现在开始吧。
因为我们在讲工作流，所以我们有必要理解构成工作流的状态（states）以及将工作流从一个状态转移到另一个状态的事件（events）。我们的例子里有两个工作流，我们把它们用状态机（statemachines）表达出来了。这两个工作流是并行执行的。一个反映了顾客与星巴克服务之间的交互（如图1），另一个刻画了由咖啡师执行的一系列动作（如图2）。
在顾客工作流里，顾客为了得到某种口味的咖啡而与星巴克服务进行交互。我们假定该工作流里包含以下动作：顾客点单，付款，然后等待饮品。在点单与付款之间，顾客通常可以修改菜单，比方说请求改用半脱脂牛奶。
图1顾客状态机
图2咖啡师的状态机
尽管这些看似跟基于Web的集成毫不相干，但这两个状态机里的每一个状态迁移，都代表着与Web资源的一次交互。每一次迁移，就是通过URI对资源实施HTTP操作，从而导致状态的改变。
我们节奏稍快了点。理解状态机和Web，不是那么容易一口吃个胖子的。所以，让我们在Web的背景下，来从头回顾一下整个场景，逐步慢慢深入。
我们将从一张简单的故事卡片开始，它启动整个流程：
这个故事里涉及一些有用的角色与实体。首先，里面有“顾客（Customer）”角色。显然，它是（隐含的）星巴克服务（StarbucksService）的消费者。其次，里面有两个重要的实体（“咖啡”和“订单”），以及一个重要的交互（“点单”）——我们的工作流正是由它启动的。
图3点一杯咖啡
图4POST饮品订单
星巴克服务创建一个订单资源，然后把这个新资源的位置放在HTTP报头Location里返回给消费者。为方便起见，服务还要把这个新创建的订单资源的表示（representation）也放在响应里。发给消费者的响应如下所示。
图5创建好了订单，等待付款
201Created状态表明星巴克已经成功接受了订单。Location报头给出了新创建订单的URI。响应主体里的表示（representation）包含了所点饮品及其价格。另外，这个表示里还包含另一个资源的URI——星巴克希望我们与这个URI交互，以完成顾客工作流；我们稍后将用到它。
注意，该URI是放在标签
星巴克很不错的一点就是，你可以按无数种不同的方式来定制自己的饮品。其实，考虑到某些高端客户极高的要求，也许让他们按化学公式来点单更好。但我们别那么贪心——至少开始的时候。我们来看另一张故事卡片：
回顾图4，显然我们在那里犯了一个错误：真正爱喝咖啡的人是不喜欢往浓咖啡里放太多热牛奶的。我们要改正那个问题。幸运地是，Web（或更确切地说，HTTP）以及我们的服务均为这样的改变提供了支持。
首先，我们要确认我们仍然可以修改订单。有时咖啡师动作很快，在我们想修改订单之前，他们就已经把咖啡做好了——于是，我们只有慢慢享用这杯热咖啡风味的牛奶了。不过，有时咖啡师会比较慢，这样我们就可以在订单得到咖啡师处理之前修改它了。为了知道我们是否还能修改订单，我们通过HTTP动词OPTIONS来向订单资源查询它接受哪些操作（如图6）。
图6看看有哪些选择（OPTIONS）
从图6我们可以知道，订单资源既是可读的（支持GET）、也是可更新的（支持PUT）。作为好网民，我们可以拿我们的新表示来做一次试验性的PUT操作，在真正PUT之前先用Expect报头来试一试（如图7）。
图7看好再做（Lookbeforeyouleap）
若我们不能修改订单了，那么对图7所示请求的响应将是417ExpectationFailed。不过，假定我们现在得到的响应是100Continue，也就是说，我们可以用PUT来更新订单资源（如图8）。用PUT方法来提交更新后的资源表示（representation），实际上就相当于修改现有资源。在这个例子中，PUT请求里的新描述包含一个元素，其中包含我们的更新，即外加一杯浓咖啡。
图8更新资源状态
如果我们能够成功提交（PUT）更新，那么我们会从服务器得到响应代码200，如图9所示。
图9成功更新资源状态
检查OPTIONS和采用Expect报头并不能令我们避免碰到“后续的修改请求失败”的情况。因此，我们并不强制使用它。作为好网民，我们会以某种方式来应付405和409响应。
尽管我们明智地使用Expect和OPTIONS，但有时PUT仍将失败；毕竟咖啡师也在一刻不停地工作——有时他们动作很敏捷！
若我们落后于咖啡师，我们在试图用PUT操作把更新提交给资源时会被告知。图10显示的就是一个常见的更新失败的响应。409Conflict状态代码表明，若接受更新，将导致资源处于不一致的状态，所以没有进行更新。响应主体里显示出了我们试图PUT的表示（representation）与服务端资源状态之间的差异。按咖啡制作的话说，加得太晚了——咖啡师已经把热牛奶倒进去了。
图10慢了一步
1.通过发送OPTIONS请求，查询服务是否接受PUT操作。这一步是可选的。它可以告知客户端，此刻服务器允许对该资源做哪些操作，不过这无法保证服务器将永远支持那些操作。
2.使用If-Unmodified-Since或If-Match报头，以避免服务器执行不必要的PUT操作。假如PUT后来失败了，那么你会得到412PreconditionFailed。此方法要求：要么资源是缓慢更新的，要么支持ETag；对于前者就用If-Unmodified-Since，对于后者就用If-Match。
3.立即用PUT操作提交更新，并应付可能出现的409Conflict响应。就算我们使用了（1）和（2），我们可能仍得应付这些响应，因为我们的“哨兵”和检查本质上都是乐观的。
在完成那些更新咖啡订单的艰苦工作之后，按理说我们应当得到额外那杯浓咖啡了。所以我们现在假定已设法得到了额外那杯浓咖啡。当然，我们要付过款后星巴克才会把咖啡递给我们（其实他们也已经暗示过了！），所以我们还需要一张故事卡片：
还记得最初那个针对原始订单的响应吗？其中有个元素。星巴克在订单资源的表示里面嵌入了有关另一个资源的信息。我们前面看过那个标签，但当时因为顾于修改订单就没有具体讲。现在我们应该进一步探讨它了：
关于next元素，有几点是值得指出的。首先，它处于一个不同的名称空间之下，因为状态迁移并不是只有星巴克需要。在这里，我们决定把这种用于状态迁移的URI放在一个公共的名称空间里，以便于重用（或甚至最终的标准化）。
元素里的uri指向的是一个付款资源。根据type属性，我们已经知道预期的资源表示（representation）是XML格式的。我们可以向这个付款资源发送OPTIONS请求，看看它支持哪些HTTP操作。
如果你一时不能理解，不要感到奇怪。这一模型的最不可思议之处在于：状态机和工作流不是像WS-BPEL或WS-CDL那样事先描述好的，而是在你经历各个状态的过程中逐步得到描述的。不过，一旦你想明白了，你就会发现，跟随链接（followinglinks）这种方式使得我们可以在应用的各种状态下向前推进。每次状态迁移时，当前资源的表示里都包含了指向可能的下一状态的链接以及它们所代表的状态。另外，由于这些代表下一状态的资源是Web资源，所以我们知道如何使用它们。
在顾客工作流里，我们下一步要做的是为咖啡付款。我们可以由订单里的元素得知总金额，但在我们向星巴克付款之前，我们想向付款资源查询一下我们应当如何与之交互（如图11）。
在设计与开发过程中，消费者会就表示和迁移的语义与服务器达成一致。但谁也不能保证服务在其演化过程中会不会采用一种客户端预期之外的表示和迁移（不过客户端还是知道如何处理它的）——那是Web松耦合的本质特性。尽管如此，在这些情况下就资源格式和表示达成一致超出了本文的范围。
我们下一步要做的是为咖啡付款。我们可以由订单表示的元素得知总金额，所以我们要做的就是付款给星巴克，然后咖啡师把饮品交给我们。首先，我们向付款资源查询我们应当如何与之交互（如图11）。
图11获知如何付款
图12付款
为成功完成付款，我们只需按图12进行交互即可。一旦经认证的PUT返回一个201Created响应，我们就可以庆祝付款成功、并拿到我们的饮品了。
幸运地是，Web可以帮助我们应付以上这些情况。对于前两种情况（假定连接问题是瞬间的），我们可以反复做PUT请求，直至我们收到成功响应为止。如果前次PUT操作已经得到了成功处理，那么我们将收到一个200响应（本质上是一个来自服务器的空操作确认）；如果本次PUT操作成功完成了付款，那么我们将收到一个201响应。在第三种情况中，如果服务器返回的响应代码是500、503或504，那么也可以做同样处理。
4xx范围的状态代码比较难处理，不过它们仍然指出了下一步怎么办。例如，400响应表明我们通过PUT请求提交的内容无法被服务器所理解，我们需要纠正后重新发送PUT请求。403响应则相反，它表明服务器能够理解我们的请求，但不知道如何履行（fulfil）它，而且服务器希望我们不要重试。对于这些情况，我们得在响应的有效负载（payload）里寻找其他的状态迁移（链接），换其他推进状态的路线。
一旦我们为自己的饮品买了单，我们这个工作流就算完成了，有关顾客的故事也就到此结束了。不过整个故事还没有完。现在我们进入到服务里面，看看星巴克的内部实现。
图13待制作饮品的Atom提要
星巴克是家相当繁忙的店，位于/orders的Atomfeed更新相当频繁，所以咖啡师要不断轮询这个feed才能保证掌握最新信息。轮询通常被认为可伸缩性很差；但是，Web支持可伸缩性极强的轮询机制——我们稍后会看到。另外，由于星巴克每分钟要制作很多咖啡，所以承受住负荷是个重要问题。
这里我们有两个相抵触的需求。一方面，我们希望咖啡师通过经常轮询订单提要，以不断掌握最新信息；另一方面，我们又不希望给服务增添负担、或者徒然增加网络流量。为防止我们的服务因过载而崩溃，我们将在我们服务之外，用一个反向代理（reverseproxy）来缓存并提供被频繁访问的资源表示（如图14所示）。
图14通过缓存提升可伸缩性
对于大多数资源（尤其是那些会被很多人访问的资源，如返回饮品列表的Atomfeed），在宿主服务之外缓存它们是合理的。这样可以降低服务器负载，提升可伸缩性。我们在架构里增设了Web缓存（反向代理），再加上有缓存元数据，这样客户端获取资源时就不会给原服务器增添很大负担了。
图13所示的响应对Atomfeed的Expires报头进行了相应的设置，令饮品列表在10秒钟后过期。由于这种缓存行为，服务器每分钟最多只要响应6次请求，其余请求将由缓存机制代劳。即便对于性能比较糟糕的服务，每分钟6个请求也属于容易处理的工作量了。在最愉快的情况下（对星巴克服务来说），咖啡师的轮询请求是由本地缓存响应的，这样就不会给增加网络活动或服务器负荷了。
在我们的例子中，我们只设置了一个缓存来帮助提升主咖啡列表的可伸缩性。然而，在真实的基于Web的场景中，我们可以从多层缓存中受益。要在大规模环境中提升可伸缩性，利用现有Web缓存的优点是至关重要的。
既然我们已经成功解决了可伸缩性问题，那么我们继续来实现更多的功能。当咖啡师开始为你制作咖啡时，应当修改订单状态，以达到禁止更新的目的。从顾客的角度来看，这相当于我们无法再对我们的订单执行PUT操作了（如图6、7、8、9、10所示）。
幸运地是，我们可以利用一个已经定义好的协议——Atom发布协议（AtomPublishingProtocol，简称APP或AtomPub）——来实现这一目标。AtomPub是一个以Web中心（基于URI）的协议，用于管理Atomfeed里的条目（entries）。我们来仔细看看Atom提要（/orders）里代表咖啡的条目。
图15咖啡订单对应的Atom条目
如果咖啡师要锁定订单资源、禁止它被修改，就可以通过该编辑URI来改变订单资源的状态。具体地讲，咖啡师可以用PUT请求把经修改的资源状态提交给这个编辑URI（如图16所示）。
图16通过AtomPub设置订单状态
服务器一旦处理了如图16所示的PUT请求，它就会拒绝对位于/orders/1234的订单资源做除GET以外的操作。
现在订单处于稳定状态了，咖啡师可以毫无顾虑地继续制作咖啡了。当然，咖啡师只有知道我们已经付过款才会把咖啡给我们，所以咖啡师还要查询我们是否已经完成付款。在真实的星巴克里，情况会略有不同：一般来说，我们是点单后立即付款的；然后，其他顾客站在周围，以免你拿走别人点的饮品。但在我们计算机化的版本里，增加这一检查并不麻烦，所以我们来看倒数第二张故事卡片：
咖啡师只要向付款资源（该资源的URI在订单表示里给出了）发送GET请求，即可查询付款状态。
这里，顾客和咖啡师是通过订单表示里给出的链接得知付款资源的URI的。但有时，通过URI模版来访问资源也很方便。
URI模版（URItemplate）是一种描述URI的格式。它允许消费者通过修改URI里的部分字符来访问不同的资源。
URI模版就像与消费者订立的契约，服务提供者须在服务演化过程中注意维持它们的稳定。由于这一潜在的耦合，有些Web集成工作者会有意避免采用URI模版。我们的建议是，仅当可推断的URIs（inferableURIs）很有帮助而且不会改变时才使用。
最终，URI模版是不是一个相对超媒体来说安全而有效的捷径，要由服务设计者来决定。我们的建议是：要保守地使用URI模版。
当然，不是人人都可以查看付款信息的。我们不想让咖啡社区里会动歪脑筋的人查看他人的信用卡详细信息，因此，跟其他敏感的Web系统一样，我们利用请求认证来保护敏感资源。
如有未认证的用户或系统试图获取一个具体的付款信息，那么服务器会质询（challenge）它、要求它提供证书。（如图17）
一旦咖啡师制作好、交出咖啡并完成收款，他们就要在待处理饮品列表中删除相应的订单。如同前面一样，我们采用一个故事来讲解这个回合：
图19删除已完成的订单
在条目被删除（DELETE）之后，再对订单提要做GET操作的话，返回的表示里将不再包含已删除（DELETE）的资源。假定我们的缓存工作正常、且我们已经设置了合理的缓存过期元数据的话，那么当你试图获取（GET）那个订单条目时将直接得到404NotFound响应。
也许你已经注意到了，Atom发布协议可以满足我们对星巴克这个问题的大部分需求。如果我们想直接把位于/orders的Atom提要暴露给顾客的话，顾客就可以用Atom发布协议来向该提要发布饮品订单、甚至修改订单了。
因为我们的咖啡店是基于自描述的状态机（statemachines）构建起来的，所以我们可以方便地根据业务需要改造我们的工作流。例如，星巴克也许会提供一种免费的网上促销活动：
成功进行演化的关键在于，服务的消费者们要能够预料到改变。在每一步，服务不是直接跟资源绑定（例如通过URI模版），而是提供指向具名资源（namedresources）的URIs，以便消费者与之交互。这些具名资源，有些是消费者不认识的、将被忽略的，有些是消费者已知的、想采用的状态迁移点。不管采用哪种方式，这种方案使得服务可以优雅地演化，同时还能维持与消费者兼容。
交付咖啡是我们工作流的最后一步。我们已经点了单、修改了订单（也可能无法修改）、付过款并最终拿到了我们的咖啡。在柜台另一侧，星巴克也已经同样完成了收款和订单处理。
我们可以用Web来描述所有必需的交互。我们可以利用现有的Web模型处理一些简单的不愉快的事（例如无法修改处理中或已处理完毕的订单），而不必自己发明新的异常或错误处理机制——我们所需的一切都是HTTP现成提供的。而且，即便发生了那些不愉快的事，客户端仍然可以向它们的目标迈进。
HTTP提供的特性起初看来是无关紧要的。但这个协议现在已经取得广泛的一致、并得到广泛的部署了，而且所有的软件与硬件都能一定程度上理解它。当我们看到其他分布式计算技术（如WS-*）处于割据状态的格局时，我们意识到了HTTP享有的巨大成功，以及它在系统间集成方面的潜力。
甚至在非功能性方面，Web也是有益的。在我们碰到临时故障时，HTTP操作（GET、PUT和DELETE）的幂等性质令我们可以进行安全的重试；内在的缓存机制既屏蔽了故障，又有助于灾难恢复（通过增强的可用率）；HTTPS和HTTP认证有助于基本的安全需求。
尽管我们的问题域是人为制造的，但我们所强调的技术同样可以应用于分布式计算环境。我们不会伪称Web很简单（除非你是天才），Web可以解决一切问题（除非你是超级乐观的人，或受到REST信仰的感染），但事实上，在局部、企业级和Internet级进行系统集成，Web是个健壮的框架。
本文作者要向英国卡迪夫大学（CardiffUniversity）的AndrewHarrison表示感谢，是他启发了我们就Web上的“对话描述”进行讨论。
1.ETag（EntityTag的简写）是资源状态的唯一标识符。一个资源的ETag通常是根据该资源的数据得到的MD5校验和或SHA1哈希值。
2.我们将从稍后的星巴克例子中了解认证的工作原理。
3.当然，如果安全性遭到威胁，我们只要防止事情不要错得更厉害就行了！但得到咖啡并不是一项攸关安全的任务，尽管每天早晨我的同事们可能会这么认为！
4.HTTP1.1提供了一些有用的请求指令，比如max-age、max-stale和max-fresh，它们允许客户端指出愿意接受缓存里多旧的数据。