* 生命周期管理：使IT系统能更精确地追踪服务及其属性，并同时提供生命周期工具来发现、组合、安全、部署和更有效地管理服务。
* 消息代理：使服务骨干网能提供松耦合的连接，而不是过去那种令众多企业痛苦不堪的手工编码的、紧耦合的、脆弱的点对点连接。通过将自定义的逻辑（例如安全规则）从应用中剥离出来，并放入服务骨干网中，就可以将它们作为独立的策略在企业范围内很方便地管理它们。
* 数据服务层：提供了一个公共的基础设施，它可以使应用程序很方便地访问、转化和更新存储在多个异构数据源中的数据。
* 安全服务层：服务基础架构可以将安全作为服务传递，从而使业务流程或应用组件可以通过公共框架使用公共的安全服务（例如验证和授权服务）。
* 可伸缩性：服务基础架构可提供元数据级的复合框架，从而允许您无需经过冗长的编程过程就可以改变业务策略，而在过去的企业IT环境里，业务策略的改变通常都无法避免冗长的编程过程。
服务基础架构的演进
服务基础架构的出现实际上是企业应用基础架构的自然演进。20世纪90年代初期，企业若想定制网络操作系统的功能，就需要自己对系统进行编码。基于HPUX、Solaris或AIX的应用或扩展都包含在各自的系统代码中，这就形成了不具有重用性的孤岛系统。这种方式带来的必然结果是企业IT系统变得越来越依赖于同种设备，久而久之就会导致厂商垄断。
同样的一幕在若干年后随着企业应用软件的出现再次重演。企业为使其SAP供应链应用系统或PeopleSoft人力资源系统适应内部业务流程而进行相应定制时，开发人员需要在SAP或PeopleSoft应用系统内部进行编码。如果企业需要将Siebel CRM解决方案和Oracle数据库进行集成，那么集成代码必须被包含到Oracle或Siebel应用中。企业自己的业务逻辑再次成为了厂商专有软件的内部“财产”。
为了将业务逻辑从樊篱中解放出来，企业应用基础架构应运而生。最初的企业应用基础架构是分布式事务处理系统。1995年，BEA推出了Tuxedo平台，它提供了在异构环境中构建和集成C、C++和COBOL应用的框架。通过使用API和集成服务，Tuxedo对技术的底层复杂性进行了有效抽象，从而将功能从底层编码中提取出来。随后，Internet的广泛普及要求企业应用能够与基于浏览器的前端协同工作。应对这一挑战，BEA WebLogic Server 和BEA WebLogic Platform为此类应用的开发、集成和管理提供了业界第一个统一框架，使企业能够从容构建对业务成功至关重要的企业应用。
有了用于扩展操作系统和企业应用的平台之后，企业应用开始向面向服务的架构转变：将一个系统表示为一整套可重用的服务，使其他系统能够对该系统进行访问。这种方式产生了一个全新的应用类别——复合应用——它定义了跨越多个应用的业务流程，并允许流程间的功能共享。然而，复合应用的推进面临着很多现实的阻碍，企业IT环境由于多种应用平台（IBM、BEA、Microsoft、SAP、Oracle等）和异构环境（J2EE、.NET、原有大型机等）的并存而变得复杂和混乱。这些因素都对复合应用提出了挑战，因为“组合”过程需要大量的编程，从而加大了系统集成的成本。
文章来源于领测软件测试网 https://www.ltesting.net/
