本文主要是翻译
RailCo最初的目标是升级其自动化系统，以便保持竞争力，并继续与其主要客户TLS的业务关系。当竞争对手设法以较低的价格提供空气制动部件，同时还与TLS的B2B系统接口时，RailCo失去了TLS的客户身份。RailCo匆忙赶上来，生产了一对仅用于TLS系统的Web服务。这使得RailCo重新获得了TLS供应商的地位。
这两个最初的Web服务是
发票提交服务
订单履行服务
（稍后添加了另一个服务以与TLS通知服务交互。）
然而，尽管RailCo已经成功地与TLS重新连接，但它已经失去了它的独占关系。现在，它发现自己处于这样一种境地：它必须对每一个发出的采购订单都与一个咄咄逼人的竞争对手进行竞价；因此，它仍在损失收入。
Railco公司避免大规模裁员的唯一办法就是找到新客户。为了实现这一目标，RailCo需要继续与其他提供B2B解决方案的运输公司一起寻求在线供应商市场。很明显，RailCo目前的一组Web服务不足以达到这一目的。因为它们是专为与TLS一起使用而设计的，所以它们对于与其他要求不同业务和事务需求的客户进行交互是没有用处的。
RailCo当时面临着一个重要的决策，要么为每个新客户开发一组定制的服务，要么从头开始，构建一组通用的标准化服务，以方便多个客户。它选择了后一种选择，并决定实现这一目标的最佳方法是彻底检查其现有环境，以支持SOA。
RailCo的两个主要业务流程是：
订单履行（接受和处理来自客户的订单）和
发票提交（向客户发送发票）。
RailCo进行了面向服务的分析，将其业务流程逻辑分解为一系列候选服务。这表明需要以下潜在的服务和服务层：
由两个以任务为中心的业务服务组成的业务服务层。
由四个应用服务组成的应用服务层。
RailCo没有技术或预算来投资能够提供编排的中间件。因此，它选择不在编排服务层中追求业务逻辑的集中化。
相反，它决定用以任务为中心的业务服务来表示每个业务流程，该服务将充当应用程序服务层的控制器。对以下服务进行了建模和设计：
o发票处理服务（以任务为中心）
o订单处理服务（以任务为中心）
o遗留系统服务（应用程序）
o轮询通知服务（应用程序）
o转换服务（应用程序）
o元数据检查服务（应用程序）
在应用服务的设计中特别强调了可重用性和可扩展性。RailCo希望其初始的SOA由支持其当前业务流程的服务组成，同时具有足够的可扩展性以适应未来的需求，而不会产生太大的影响。
为了实现发票提交流程，RailCo能够将这些服务组合成一个两级层次结构，其中父发票处理服务协调所有应用程序服务的执行（图a.1）。
图A.1。RailCo的服务组合，使其发票提交过程自动化。
订单履行流程现在可以通过PO处理服务实现自动化，该服务重用发票提交流程使用的两个相同的应用程序服务（图A.2）。
图A.2。订单履行过程由一个由两个可重用应用程序服务组成的订单处理服务自动化。
面对一些坏消息，包括负责交付其原始Web服务的.NET顾问的离职，RailCo能够很好地利用内部资源。经过培训，新的SOA被创建为J2EE解决方案。
RailCo通过生成支持两个面向服务的解决方案的SOA来实现其最初的目标。RailCo现在可以继续与TLS进行在线交易，同时自信地寻找新客户。引入新需求的其他客户可以以最小的影响来适应。它的标准化应用服务层可能会继续提供可重用的功能，以满足新的需求。任何功能上的差距都可能通过扩展服务来解决，而不会对现有的实现造成严重的干扰。
此外，如果RailCo决定在未来用编排服务层取代其以任务为中心的业务服务，则由现有应用服务层建立的抽象将保护应用服务不必进行重新开发。
完成此项目后，RailCo发现了其新解决方案环境的一个附带好处。通过将遗留系统服务（本质上是其会计系统的包装服务）作为其应用程序服务层的一部分建立起来，它打开了一个通用端点，可以促进集成。
这为RailCo提供了在其会计系统和联系人管理应用程序之间实现互操作性的潜力（在第2章中首先介绍）。通过允许这两个环境共享数据，RailCo可以更有效地利用协调的联系人和财务历史档案来接纳和服务新客户。
考虑本文中介绍的RailCo案例以及课堂和召回服务的设计原则。根据松耦合评估RailCo解决方案。陈述并捍卫你的观点。