SOA Service-oriented architecture 面向服务架构
see also:
* Service-oriented architecture wikipedia
* Microservices
In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design.[1]
By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network.
A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.
SOA is also intended to be independent of vendors, products and technologies.[2]
在软件工程中,面向服务架构 (SOA) 是一种专注于离散服务而不是单一设计的架构风格。 [1]
因此,它也应用于软件设计领域,其中应用程序组件通过网络上的通信协议向其他组件提供服务。
服务是一个离散的功能单元,可以远程访问、独立操作和更新,例如在线检索信用卡对帐单。
SOA 还旨在独立于供应商、产品和技术。 [2]
Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.[1]
面向服务是一种在服务和基于服务的开发以及服务结果方面的思维方式。[1]
A service has four properties according to one of many definitions of SOA:[3]
根据 SOA 的众多定义之一,服务具有四个属性:
- It logically represents a repeatable business activity with a specified outcome. 它在逻辑上表示具有指定结果的可重复业务活动。
- It is self-contained. 具有完备的特性(self-contained)
- It is a black box for its consumers, meaning the consumer does not have to be aware of the service’s inner workings. 它是消费者的黑匣子,这意味着消费者不必了解服务的内部运作。
- It may be composed of other services. 它可能由其他服务组成。 [4]
Different services can be used in conjunction as a service mesh to provide the functionality of a large software application,[5]
a principle SOA shares with modular programming. Service-oriented architecture integrates distributed, separately maintained and deployed software components.
It is enabled by technologies and standards that facilitate components’ communication and cooperation over a network, especially over an IP network.
不同的服务可以作为服务网格结合使用,以提供大型软件应用程序的功能,[5]
SOA 与模块化编程共享一个原则。面向服务架构集成了分布式的、单独维护和部署的软件组件。
它由促进组件在网络上(尤其是在 IP 网络上)的通信和协作的技术和标准实现。
SOA is related to the idea of an API (application programming interface), an interface or communication protocol between different parts of a computer program intended to simplify the implementation and maintenance of software.
An API can be thought of as the service, and the SOA the architecture that allows the service to operate.
SOA 与 API(应用程序编程接口)的概念相关,API 是计算机程序不同部分之间的接口或通信协议,旨在简化软件的实施和维护。
API 可以被认为是服务,而 SOA 是允许服务运行的架构。
In SOA, services use protocols that describe how they pass and parse messages using description metadata.
This metadata describes both the functional characteristics of the service and quality-of-service characteristics.
Service-oriented architecture aims to allow users to combine large chunks of functionality to form applications which are built purely from existing services and combining them in an ad hoc manner.
A service presents a simple interface to the requester that abstracts away the underlying complexity acting as a black box.
Further users can also access these independent services without any knowledge of their internal implementation.[6]
在面向服务架构(SOA)中,服务使用描述元数据来传递和解析消息的协议。
这些元数据描述了服务的功能特性和服务质量特性。
面向服务架构旨在允许用户将大块功能组合成应用程序,这些应用程序完全由现有服务构建,并以临时方式组合它们。
服务向请求者呈现一个简单的接口,将底层复杂性抽象出来,充当一个黑盒子。
此外,用户还可以在不了解其内部实现的情况下访问这些独立服务。[6]
Defining concepts 概念
The related buzzword service-orientation promotes loose coupling between services.
SOA separates functions into distinct units, or services,[7] which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications.
These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.[8]
相关的概念“服务导向”(service-orientation)提倡服务之间的松耦合。
面向服务架构将功能划分为独立的单元或服务7,开发人员通过网络使其可访问,以便用户在应用程序的开发中组合和重用它们。
这些服务及其相应的消费者通过以明确定义的共享格式传递数据,或者通过协调两个或多个服务之间的活动来进行通信。[8]
A manifesto was published for service-oriented architecture in October, 2009. This came up with six core values which are listed as follows: 2009年10月,面向服务架构发表了一份宣言。该宣言提出了六个核心价值,列举如下:[9]
1. Business value is given more importance than technical strategy. 商业价值 比技术策略更重要。
2. Strategic goals are given more importance than project-specific benefits. 战略目标 比项目特定的收益更重要。
3. Intrinsic interoperability is given more importance than custom integration. 内在互操作性 比定制集成更重要。
4. Shared services are given more importance than specific-purpose implementations. 共享服务 比特定目的的实现更重要。
5. Flexibility is given more importance than optimization. 灵活性比优化更重要。
6. Evolutionary refinement is given more importance than pursuit of initial perfection. 渐进的改进 比追求最初的完美更重要。
SOA can be seen as part of the continuum which ranges from the older concept of distributed computing[7] [10] and modular programming,
through SOA, and on to practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).[11]
SOA可以被视为一个连续体的一部分,该连续体涵盖了更早的分布式计算[7] [10] 和模块化编程的概念,
通过SOA,延伸至混合体(mashups)、软件即服务(SaaS)和云计算的实践(一些人将云计算视为SOA的产物)。[11]
Principles 原则
There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these[12] [13] [14] include the following:
关于面向服务架构的确切组成,目前没有相关的行业标准,尽管许多行业来源已经发布了自己的原则。其中一些包括以下内容:
Standardized service contract 标准化的服务契约 [15]
Services adhere to a standard communications agreement, as defined collectively by one or more service-description documents within a given set of services.
服务遵守标准的通信协议,由一组给定服务中的一个或多个服务描述文档共同定义。
Service reference autonomy (an aspect of loose coupling) 服务引用自治(松耦合的一个方面)
The relationship between services is minimized to the level that they are only aware of their existence.
服务之间的关系被最小化,它们只知道彼此的存在。
Service location transparency (an aspect of loose coupling) 服务位置透明性(松耦合的一个方面)
Services can be called from anywhere within the network that it is located no matter where it is present.
无论服务位于网络的哪个位置,都可以从网络中的任何地方调用服务。
Service longevity 服务生命周期
Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.
服务应该设计成长期存在的。如果不需要新功能,服务应该尽量避免强制消费者进行更改。如果你今天调用一个服务,明天仍应该能够调用同样的服务。
Service abstraction 服务抽象
The services act as black boxes, that is their inner logic is hidden from the consumers.
服务充当黑盒子,即其内部逻辑对消费者隐藏。
Service autonomy 服务自治
Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.
服务是独立的,并且从设计时和运行时的角度控制其封装的功能。
Service statelessness 服务无状态
Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.
服务是无状态的,即要么返回所请求的值,要么返回异常,从而最小化资源使用。
Service granularity 服务粒度
A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.
确保服务具有足够规模和范围的原则。提供给用户的服务功能必须是相关的。
Service normalization 服务规范化
Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done.
These are the cases where performance optimization, access, and aggregation are required.[16]
服务被分解或合并(规范化),以最小化冗余。在某些情况下,可能不会执行规范化。这些情况需要进行性能优化、访问和聚合。
Service composability 服务组合性
Services can be used to compose other services.
服务可以用于组合其他服务。
Service discovery 服务发现
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
服务附带有沟通元数据,通过这些元数据可以有效地发现和解释服务。
Service reusability 服务复用
Logic is divided into various services, to promote reuse of code.
逻辑被划分为多个服务,以促进代码的复用。
Service encapsulation 服务封装
Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.
在面向服务架构下,许多最初未计划的服务可能被封装或成为面向服务的一部分。
Patterns 模式
Each SOA building block can play any of the three roles: 每个面向服务架构构建块可以具有以下三种角色之一:
Service provider 服务提供者
It creates a web service and provides its information to the service registry.
Each provider debates upon a lot of hows and whys like which service to expose, which to give more importance:
security or easy availability, what price to offer the service for and many more.
The provider also has to decide what category the service should be listed in for a given broker service[17] and what sort of trading partner agreements are required to use the service.
它创建一个Web服务,并将其信息提供给服务注册中心。
每个提供者都需要考虑很多问题,例如要暴露哪个服务,哪个更重要:
安全性还是易用性,提供服务的价格是多少,以及其他许多问题。
提供者还必须决定将服务列入给定代理服务的哪个类别,并且使用该服务需要什么样的协议。
Service broker, service registry or service repository 服务代理、服务注册中心或服务仓库
Its main functionality is to make the information regarding the web service available to any potential requester. Whoever implements the broker decides the scope of the broker.
Public brokers are available anywhere and everywhere but private brokers are only available to a limited amount of public.
UDDI was an early, no longer actively supported attempt to provide Web services discovery.
它的主要功能是将有关Web服务的信息提供给任何潜在的请求者。无论是实现哪个代理,都会决定代理的范围。
公共代理可在任何地方都可用,但私有代理只对有限的公众开放。
UDDI是早期的、不再得到积极支持的提供Web服务发现的尝试。
Service requester/consumer 服务请求者/消费者
It locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services.
Whichever service the service-consumers need, they have to take it into the brokers, bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
它使用各种查找操作在代理注册中心中定位条目,然后与服务提供者进行绑定,以调用其Web服务之一。
服务消费者需要哪个服务,就必须将其带入代理中,与相应的服务进行绑定,然后使用它。如果服务提供多个服务,消费者可以访问多个服务。
The service consumer–provider relationship is governed by a standardized service contract,[18] which has a business part, a functional part and a technical part.
服务消费者和提供者之间的关系受到标准化的服务契约的约束,该契约包括商业部分、功能部分和技术部分。
Service composition patterns have two broad, high-level architectural styles: choreography and orchestration.
Lower level enterprise integration patterns that are not bound to a particular architectural style continue to be relevant and eligible in SOA design.[19] [20] [21]
服务组合模式有两种广泛的高层架构风格:协同和编排。
与特定架构风格无关的更低级别的企业集成模式在面向服务的设计中仍然是相关和合适的。
Implementation approaches 实现方法
Service-oriented architecture can be implemented with web services or Microservices.[22]
This is done to make the functional building-blocks accessible over standard Internet protocols that are independent of platforms and programming languages.
These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.23
面向服务架构可以通过 Web服务 或 微服务 实现[22]。
这样做是为了使功能构建块可以通过独立于平台和编程语言的标准互联网协议访问。
这些服务可以代表新应用程序,也可以只是包装现有遗留系统,使其具备网络功能[23]。
Implementers commonly build SOAs using web services standards.
One example is SOAP, which has gained broad industry acceptance after recommendation of Version 1.2 from the W3C[24] (World Wide Web Consortium) in 2003.
These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software.
One can, however, also implement SOA using any other service-based technology, such as Jini, CORBA, Internet Communications Engine, REST, or gRPC.
实现通常使用Web服务标准构建SOA。
一个例子是SOAP,在2003年由W3C(万维网联盟)推荐1.2版本后,已经获得了广泛的行业认可[24]。
这些标准(也称为Web服务规范)还提供更强的互操作性,并对专有供应商软件的依赖性提供一定的保护。
然而,也可以使用任何其他基于服务的技术来实现SOA,例如 Jini、CORBA、Internet Communications Engine、REST或gRPC。
Architectures can operate independently of specific technologies and can therefore be implemented using a wide range of technologies, including:
架构可以独立于特定技术运行,因此可以使用各种技术来实现,包括:
– Messaging, e.g., with ActiveMQ, JMS, RabbitMQ 消息传递、MQ,例如ActiveMQ、JMS、RabbitMQ
– RESTful HTTP, with Representational state transfer (REST) constituting its own constraints-based architectural style
RESTful HTTP,其中采用了基于约束的REST(Representational State Transfer)作为其自身的架构风格
– Web services based on WSDL and SOAP 基于WSDL和SOAP的Web服务
– OPC-UA
– Internet Communications Engine Internet通信引擎
– WCF (Microsoft’s implementation of Web services, forming a part of WCF) WCF(微软的Web服务实现,是WCF的一部分)
– Apache Thrift
– gRPC
– SORCER
Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data following a defined interface specification between processes conforming to the SOA concept.
The key is independent services with defined interfaces that can be called to perform their tasks in a standard way,
without a service having foreknowledge of the calling application,
and without the application having or needing knowledge of how the service actually performs its tasks.
SOA enables the development of applications that are built by combining loosely coupled and interoperable services.
实现可以使用这些协议中的一个或多个,例如,可以使用文件系统机制按照定义的接口规范在符合 SOA 概念的进程之间传递数据。
关键是具有已定义接口的独立服务,这些接口可以被调用以标准方式执行其任务,
而无需服务预先知道调用应用程序,并且应用程序无需知道或不需要了解服务如何实际执行其任务。
SOA 支持开发通过组合松散耦合和可互操作的服务构建的应用程序。
High-level programming languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services,
which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals.
BPEL 等高级编程语言和 WS-CDL 和 WS-Coordination 等规范通过提供一种方法来定义和支持将细粒度服务编排为更粗粒度的业务服务,进而扩展服务概念,
架构师可以反过来合并到复合应用程序或门户中实施的工作流和业务流程中。
Service-oriented modeling is an SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets.
The Service-oriented modeling framework (SOMF) offers a modeling language and a work structure or “map” depicting the various components that contribute to a successful service-oriented modeling approach.
It illustrates the major elements that identify the “what to do” aspects of a service development scheme.
The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative.
SOMF also provides a common modeling notation to address alignment between business and IT organizations.
面向服务建模是一个 SOA 框架,它确定了指导 SOA 实践者概念化、分析、设计和架构其面向服务的资产的各种规程。
面向服务建模框架 (SOMF) 提供了一种建模语言和一种工作结构或“地图”,描述了有助于成功实现面向服务的建模方法的各种组件。
它说明了确定服务开发计划的“做什么”方面的主要元素。
该模型使实践者能够制定项目计划并确定面向服务的计划的里程碑。
SOMF 还提供了一个通用的建模符号来解决业务和 IT 组织之间的一致性问题。
Extensions and variants 扩展和变体
- Event-driven architecture 事件驱动架构
- Application programming interfaces
- Web 2.0
- Microservices 微服务
- Service-oriented architectures for interactive applications 交互式应用程序的面向服务架构