减少了存储 POS 的设备并且更好地利用了不太昂贵的工作站和大众化设备。
在传统存储中的软件堆栈被转换成了中央托管环境（如图 1 和 2 所示）。
不太强大的、非常有成本效益的内部存储的服务器仅被用于数据引用及其它设备和位置之间传递信息。
增长客户的存储经验，因为销售事务是非常有效的，并且客户的需求能适合于更多的服务、销售代表和其它设备（例如，手持和不太昂贵的工作站）。
更多的资源被定向到核心策略业务指导。
下两图描述了基本的 IT 基础架构以及传统存储与细存储之间操作上的差异：
图 1. 当前系统的上下文
图 2. 今后系统的上下文
约束
SoT 项目必须处理下面的主要问题和约束：
细存储概念的存在需要被确认及验证。
组织中文化变迁的影响：客户端需要被调整以适合于现有的 COTS 业务流程和规则，以便优化未经优化的 COTS 应用程序组件及新技术的使用效果，并且为了今后的功能及技术停留在已更新的路径上。
需要评估 COTS 供应商的能力来配置必要的基于极度挑战性的时间线的资源（Gartner Group 评估，2004 年 9 月和 11 月）。
部署日程安排，需要适合于季节性的销售日程。
需要将存储的部署配置的数目降到最小。
SOA、服务和组件的概述
面向服务的体系结构的更新及集成
正如 Albert Einstein 所提出的，“事情应当处理得尽可能简单，但是不能太简单。”许多过去已建立的软件系统没有通过该测试，因为它们太复杂、太昂贵，或走向另一个极端 —— 太简单以至于不能完成实际的业务需求。达到恰当的简单化水平好像是不现实的。将事情变得更加困难的是，在 SOA 出现之前，不存在有效的机制来消除业务需求与 IT 功能之间的隔阂。
SOA 是一种体系结构样式，它努力实现交互的软件组件之间的松耦合。通过使用 SOA，服务集通过简单传递的数据或调整业务活动（包括两个或更多的服务）来彼此传递信息。它通过一套简单通用的接口（在接口上仅编码通用的语义）实现了交互软件组件之间的松耦合。所有提供者和客户都应当能够使用该接口。此外，SOA 采用了描述的消息，该消息受可扩展的通过接口传递的 schema 的限制。这样的 schema 限制了消息的词汇和结构，并且允许在不破坏现有服务的条件下引入服务的新版本。即便要也是非常少的，系统行为通过描述的消息来指定。以这种方式，您可以有效地建立一套服务，它有明确定义的接口，并且能够在多重业务上下文中潜在地被复用。使用 SOA，应用程序是松耦合的，并且可以在服务/接口（协议）级被集成，而不是在实现级，如同过去的实践一样。这使得在 IT 满足任何业务需求的变更时更加灵活、机动、可扩展。
SOA 不是新概念；Common Object Request Broker Architecture（CORBA）和 Distributed Component Object Model（DCOM）早就提供了类似的功能。然而，这些对于服务定位的解决方案受一些问题的困扰，如紧耦合场景和所有权设计及实现。
服务与组件
什么是服务？服务只是一些应用程序功能，它们被发布成业务流程的组件。同组件一样，它提供了独立的构建模块，这些模块共同代表业务应用程序环境。服务是明确定义的、独立的工作单位，不依赖于上下文或其它服务的声明，由服务提供者执行来完成服务客户所需的最终结果。提供者及客户都通过代表他们自己的软件组件来承担职责。使用 SOA，所有的业务任务或流程都可以被设计并作为互联网（或其它任何网络）上使用的服务来构建。
文章来源于领测软件测试网 https://www.ltesting.net/
