|
|
知识路径： > 软件架构基础知识 > 面向服务的架构 >
|
|
相关知识点：2个
|
|
|
|
|
从概念上讲，SOA有3个主要的抽象级别，分别是操作、服务和业务流程。其中位于抽象最低层的操作代表了单个逻辑单元的事物。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA操作可以直接与面向对象的方法相比，它们都有特定的结构化接口，并且返回结构化的响应，完全与方法一样。位于第二层的服务代表了操作的逻辑分组。最高层的业务流程则是为了实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。在SOA术语中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。其中操作的排序、选择和执行成为服务或流程的编排，典型的情况是调用已编排服务来响应业务事件。
|
|
|
|
从建模的观点来看，SOA带来的主要挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。针对这个问题，Olaf Zimmermann和Pal Krogdahl综合了OOA、OOD、企业架构（Enterprise Architecture，EA）框架和业务流程建模（Business Process Modeling，BPM）中的适当原理，将这些规则中的原理与许多独特的新原理组合起来，提出了面向服务的分析与设计（Service-Oriented Analysis and Design，SOAD）的概念，OOAD、EA和BPM分别从基础设计层、应用结构层和业务组织层3个层次上为SOAD提供了理论支撑。其结构如下图所示。
|
|
|
|
|
|
|
|
（1）底层设计层。采用了OOA和OOD的思想，其主要目标是能够进行快速而有效的设计、开发以及执行灵活且可扩展的底层服务构件。对于设计已定义的服务中的底层类和构件结构，OO是一种很有价值的方法。但是目前与SOAD有关的OO设计在实践中也存在着一些问题：OO的粒度级别集中在类级，对于服务建模来说，这样的抽象级别太低。诸如继承这样的强关联产生了相关方之间一定程度的紧耦合。与此相反，SOAD试图通过松耦合来促进灵活性和敏捷性。这使得OO难以与SOAD架构保持一致。
|
|
|
|
（2）架构层。采用了EA的理论框架。企业应用程序和IT基础架构发展成SOA是一个庞大的工程，其中可能会涉及众多的业务流水线和组织单元。因此，需要应用EA架构，以努力实现单独的解决方案之间架构的一致性。在SOA中，架构层必须以表示业务服务的逻辑构件为中心，并且集中于定义服务之间的接口和服务级协定。
|
|
|
|
（3）业务组织层。采用了BPM规则。BPM是一个不完整的规则，其中有许多不同的形式、表示法和资源，其中应用较为广泛的是UML。SOA必须利用所有现有的BPM方法作为SOAD的起点，同时需要服务流程编排模型中用于驱动候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD中的流程建模必须与设计用例保持同步。
|
|
|
|
SOA是一种企业系统架构，它是从企业的业务需求开始的，但是，SOA比其他企业架构方法更具优势的地方在于SOA提供了业务的敏捷性。业务敏捷性是指企业对业务的变化能更快速和有效地进行响应，并且利用快速变更来得到竞争优势的能力。要满足这种业务敏捷性，SOA必须遵循以下原则：
|
|
|
|
（1）业务驱动服务，服务驱动技术。在抽象层次上，服务位于业务和技术之间，业务处于主导地位，业务的变化需要服务的重新编排和组合，服务的编排和组合可能会带来实现细节的变化。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系；另一方面，同样要理解服务与提供这些服务的底层技术之间的关系；最后，需要设计良好的服务动态组合来应对多变的业务逻辑，这也是SOA最核心的问题。
|
|
|
|
（2）业务敏捷是基本的业务需求。SOA考虑的是提供响应变化需求的能力是新的“元要求”，而不是一些业务上固定不变的需求。系统整个架构都必须满足敏捷需求，因为在SOA中任何的瓶颈都会影响到整个系统的灵活性。因此，架构设计师需要将敏捷的思想贯穿在整个系统设计中。SOA的目的就是应对变化，其最高准则是“以不变应万变”，也就是以尽量少的变化成本应对不断变化的业务需求，具体来说，就是通过现有的可重用性服务的重新组合来应对新需求。
|
|
|
