软件架构师一直在争相利用多连接组件去创建可分解的应用。这一模式的开发经济性更好，应用生命周期管理（ALM）也更容易，但却会引起软件模型组件化的问题。

　　应用应该给予轻量Web模式的表述性状态转移（REST），还是该基于经受住商业考验的面向服务架构（SOA）？答案取决于开发从哪里开始，组件的属性如何，以及应用与瘦客户应用的联系紧密到何种程度。

　　REST和SOA应用的关键区别

　　REST和SOA应用最大的区别也许在于控制状态（即在工人事务或请求的整体流程中给定消息的上下文）的机制。需要支持这两类状态控制策略的软件设计是很不一样的。架构师首先要问的问题是软件是否默认已经做出REST或SOA的选择。在SOA中，状态控制往往驻留在每一个组件上。组件之间的关系必须通过逻辑流程维护以便消息个体不在上下文以外进行解释。而REST中状态则是作为消息的一部分从一个组件传给另一个组件。

　　REST和SOA应用的第二大区别是后者在描述组件间接口、基于接口的绑定，以及功能性方面往往有着更强大的工具。尽管通过RESTful流程管理组件绑定还是有可能的，甚至还可以进行浏览和动态绑定，但是这些工具限制更多，远未标准化。这意味着对于高度动态的组件工作流来说，SOA也许会更好。

　　基于遗留设计的应用适配

　　最近的2010年，公司报告说自己大部分的业务应用是从至少5年前的设计和代码演变而来的。这些软件实践在执行上是模块化的，但尚未组件化，因此并未对组件化和工作流控制之类的问题给予特别的考虑。甚至在一些后来做了组件化和工作流的地方，公司报告说基本的应用逻辑大体上仍原封不动。

　　只要应用基本上是基于遗留设计的，几乎就可以确定该应用是用有状态组件编写。这意味着想让应用与REST适配会困难很多。反之，SOA很容易就可以适应有状态组件。

　　在不需要大规模重做的情况下，可以用遗留应用来搭建有状态Web服务。如果某个应用相对成熟，则可假定应采用SOA进行组件化，除非存在明显的应用重设计需求。

　　如果你正在开发新应用或新组件，那么遗留设计对你选REST还是SOA的负担就没那么重了。此处的问题可能是组件间交互的性质如何。有两点要看一下：水平伸缩或云爆发的需求，以及多阶段提交或可靠事务处理的需求。

　　实现REST和SOA应用的混合设计

　　既然组件间的RESTful接口在消息中携带了必要的状态信息，很容易就复制多份组件以适应工作负载的变化，或者在工作量变少时减少拷贝数。在SOA中，此类伸缩会更加复杂，因为新的组件不一定能正确继承流程状态，并因此在错误的上下文中处理消息。一般而言，应用越类似Web或云化，用RESTful接口来开发的可能性就越高。

　　然而，在事务需要对多个数据库进行更新的情况下，SOA就能大放异彩。SOA处理多阶段提交（事务仅在所有对数据库的影响均已更新的情况下才结束）就很容易，但是REST就需要一些设计策略。没有一些有状态组件的情况下进行可靠事务处理是不可能的，因此REST和SOA混合应用起码是必要的，甚至可能还需要一个完全的SOA实现。

　　对于任何要走REST还是SOA决策流程的人来说，混合都是一个有用的概念。用这俩种方法搭建组件化应用都有可能。实际上，这往往是在Web服务器前端采用更为传统的应用服务器时使用的办法。

　　而计算性任务和数据库访问则可以做进RESTful组件里面，这样可以随需伸缩。在有严格的事务可靠性要求的地方，工作流可以转移到基于SOA的接口上，以便在甚至组件或网络失败时仍能对状态进行精确控制。

　　确定动态绑定的需求

　　应用中的动态绑定需求很难评估。有些用户说自己很少需要或使用SOA设施来描述集合目录中的接口，而有的则说感觉这是一项有用的功能。在以下情况下，SOA绑定定义在ALM中可能是有用的：

　　·工作流跨公司边界的应用

　　·预期会高度组件化

　　·预期会进行组件的该层重用

　　·许多开发者可能要一起工作于一组共同的组件

　　对于一般的应用，必须考虑组件绑定的改变频度如何。

　　最后的问题是数据表示问题：应用是否支持动态客户识别，如移动授权这样的情况。移动连接的可靠略低。

　　对事务进行小心的控制很重要，但SOA与移动设备的接口很少用到。这创造了一种独特的REST-SOA前后端模式。如果应用开发是在前端（或表示层），那么REST就是优选。但如果是这样的话，SOA或某种形式的事务恢复在后端将至关重要。

　　最佳实践也应该对当前实践表示认可。有着可观SOA经验而RESTful接口经验很少的公司对于转向一个单独的应用前应三思，反之亦然。团队技能是最终的决策者。