2.1 SOA 设计原则
在 SOA 架构中，继承了来自对象和构件设计的各种原则，那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。关于服务，一些常见的设计原则如下：
（1）接口定义明确。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，不能随意更改；服务的定义应尽可能明确，减少不适当请求使用；隐藏私有数据。
（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
（3）粗粒度。控制服务数量，依靠消息交互而不是远程过程调用，通常表现为消息量比较大，但是服务之间的交互频度较低。
（4）松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
（5）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，也可以是与业务有关的语义方面的内容。
2.2 服务构件与传统构件
服务构件架构（Service Component Architecture，SCA）是基于 SOA 的思想描述服务之间组合和协作的规范，描述使用 SOA 构建应用程序和系统的模型。简化了使用 SOA 进行的应用程序开发和实现工作。SCA 提供构建粗粒度构件的机制，这些粗粒度构件由细粒度构件组装而成。SCA 将传统中间件编程从业务逻辑分离出来，从而使程序员免受其复杂性的困扰。它允许开发人员集中精力编写业务逻辑，而不必将大量的时间花费在更为底层的技术实现上。
SCA 服务构件与传统构件的主要区别在于，服务构件往往是粗粒度的，而传统构件以细粒度居多；服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体 API 形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供 QoS 的服务，而传统构件完全由程序代码直接控制。
2.3 关键技术
SOA 是一种全新的架构，为了支持其各种特性，相关的技术规范不断推出。与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的。
2.3.1 UDDI
UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成），是服务的信息注册规范，提供了一种服务发布、查找和定位的方法，以便被需要该服务的用户发现和使用它。
UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。
在 UDDI 技术规范中，主要包含以下三个部分的内容：
（1）数据模型。UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema。
（2）API。UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。
（3）注册服务。UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角色。
2.3.2 WSDL
WSDL（Web ServiceDescription Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义
采用抽象接口定义对于提高系统的扩展性很有帮助。服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。
服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应当使用怎样的消息调用模式来访问等。
2.3.3 SOAP
SOAP（Simple ObjectAccess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。SOAP 主要包括以下四个部分：
（1）封装。SOAP 封装定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必需的。
（2）编码规则。SOAP 编码规则定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
（3）RPC 表示。SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协议。
（4）绑定。SOAP 绑定定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。
SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的 SOAP 消息都使用 XML 进行编码。SOAP 消息包括以下三个部分：
（1）封装（信封）。封装的元素名是 Envelope，在表示消息的 XML 文档中，封装是顶层元素，在 SOAP 消息中必须出现。
（2）SOAP 头。SOAP 头的元素名是 Header，提供了向 SOAP 消息中添加关于这条 SOAP 消息的某些要素的机制。SOAP 定义了少量的属性用来表明这项要素是否可选以及由谁来处理。SOAP 头在 SOAP 消息中可能出现，也可能不出现。如果出现的话，必须是 SOAP 封装元素的第一个直接子元素。
（3）SOAP 体。SOAP 体的元素名是 Body，是包含消息的最终接收者想要的信息的容器。SOAP 体在 SOAP 消息中必须出现且必须是 SOAP 封装元素的直接子元素。如果有头元素，则SOAP 体必须直接跟在 SOAP 头元素之后；如果没有头元素，则 SOAP 体必须是 SOAP 封装元素的第一个直接子元素。
2.3.4 REST
REST（RepresentationalState Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操作（POST、GET、PUT 和 DELETE），这些操作适用于所有的消息。REST 提出了如下一些设计概念和准则：
（1）网络上的所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识。
（3）通过通用的连接件接口对资源进行操作。
（4）对资源的各种操作不会改变资源标识。
（5）所有的操作都是无状态的。
2.3.5 ESB
SOA软件架构有个显著的特征，即服务中心化思想。服务之间的所有连接，均需通过ESB总线通讯。ESB总线名称上是通讯总线，但我们认为，应该把ESB称之为SOA服务中间件更恰当，ESB总线实现了以下几个特征：
a）所有服务间禁止任何形式的直接连接，唯一许可的通信方式，就是通过网络调用服务接口。
b）网络调用的具体实现方式不做强制要求，可根据不同系统的特性选择最优解决方案，目前支持Http、Binder、ZMQ、VIWI等，但均需支持以下能力：同步请求、异步请求、订阅、发布。
c）服务接口设计以可公开作为设计导向，即，所有的服务接口，必须是可以对外部人员开发的，没有例外。
d）车云一体化软件组件
e）实现车端—云端服务对等且位置无关化
f）并针对不同车型配置，实现个性化配置管理及相应的服务管理
汽车服务架构(SOA)开发设计 -- SOA概念