SOA复习手册

最新推荐文章于 2023-07-15 13:12:28 发布

csu_zipple

最新推荐文章于 2023-07-15 13:12:28 发布

阅读量486

点赞数

分类专栏： SOA 文章标签： soa 复习手册笔记

SOA 专栏收录该内容

0 篇文章 0 订阅

订阅专栏

感谢ICELEE大佬做的SOA复习笔记！

为什么要引入SOA？

需求拉动

Internet环境下的企业交互
- 现代企业已经不再是封闭的企业，市场分工的日益专业化使得企业之间可能存在大量频繁的交互行为，以发挥各自的竞争优势
异构系统的集成与互操作
- 不同企业所应用的软件系统是不同的(异构的)
频繁变化的互操作与集成需求
- 企业的业务是频繁变化的；
- 企业的IT应用系统要能够快速支持这种变化的需求。
技术推动

结构化设计

面向对象

面向构件

到面向服务

SOA三个核心要素

标准化封装
可复用
松耦合可编排

SOA的典型优势

分布式异构系统的集成与互操作
完全的松散耦合：位置透明，与具体的实现细节无关（通过接口调用），标准化的通讯协议（XML-based）
大数据量的方式一次性进行数据交换
基于文本的消息传递
独立于服务使用者的上下文：在设计阶段，服务不需要了解它们将来可能被复用的环境
大粒度复用体（效率高）

SOA的适用场景

协同—交互—异构—分布式环境—可能频繁变化

只要满足了这些条件之一，就可以应用SOA

点对点的服务发布与调用体系结构模式

“发布-查询-绑定”模式
角色：服务提供者、服务注册中心、服务客户端
服务提供者到服务注册中心进行服务注册

WSDL：Web服务描述语言
客户端到注册中心发现想要的服务

UDDI：统一描述、发现和集成协议
客户端与服务提供者进行绑定调用

SOAP：简单对象访问协议

企业服务总线

企业服务总线(Enterprise Service Bus)是一个整合应用和服务的灵活的连接基础组织，支持实现多个服务的编排。

ESB在请求者和服务之间实现了：

路由服务间的消息
转换请求者和服务之间的传输协议
转换请求者和服务之间的消息格式
处理分离资源间的业务事件

SOA的层次模型

功能部分由下至上分为可操作系统层、企业组件层、服务层、业务流程编排层和表示层

遗留系统
业务功能构建层
服务层
业务过程层（服务组合与协同层）
访问层（表示层）
集成（EBS）
服务质量（QoS）

SOA平台模型包含的组件和作用

基础设施服务：为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑
企业服务总线：由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为SOA提供的软件架构的构造物。企业服务总线ESB提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。
关键服务实现，是SOA在各种业务服务组件的分类。一般来说，一个企业级的SOA架构通常包括：交互服务、流程服务、信息服务、伙伴服务、企业应用服务和接入服务。这些服务可能是一些服务组件，也可能是企业应用系统（如ERP）所暴露的服务接口等等。这些服务都可以接入ESB，进行集中统一管理。
开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，涵盖服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。

面向服务的分析和设计SOMA

SOMA：Service-Oriented Modeling & Analysis (SOMA)

通过面向服务的建模、分析和设计技术与活动，构造SOA应用

各个阶段：

建立业务模型
识别对象

识别服务
设计服务（接口，内部）

设计服务编排
用编程语言实现服务
SOA系统的配置与运行

SOMA的核心是：识别、设计和实现服务(services)、用来支持服务的构件(components)、以及服务之间形成的协同(choreography)。

Web服务的概念

Web Service就是一个向外界暴露出接口的能够通过网络进行远程调用的应用程序。

Web Service的实质是一套标准，它定义了应用程序如何在Web上实现互操作。

Web服务的核心标准：

XML
SOAP
WSDL
UDDI

SOAP

简易对象访问协议(Simple Object Access Protocol)

基于XML

SOAP 是一种通信协议，用于应用程序之间的通信，是一种用于发送消息的格式，被设计用来通过因特网进行通信。独立于语言、独立于平台、简单易扩展。

SOAP是一个普通的XML文档，包含下列元素：
必需的 Envelope 元素，可把此 XML 文档标识为一条 SOAP 消息
可选的 Header 元素，包含头部信息：如果 Header 元素被提供，则它必须是 Envelope 元素的第一个子元素。
必需的 Body 元素，包含所有的调用和响应信息
可选的 Fault 元素，提供有关在处理此消息所发生错误的信息

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
  ...
</soap:Header>

<soap:Body>
  ...  
        <m:GetPrice xmlns:m="http://www.w3school.com.cn/prices">
             <m:Item>Apples</m:Item>
        </m:GetPrice>
        <m:GetPriceResponse xmlns:m="http://www.w3school.com.cn/prices">
              <m:Price>1.90</m:Price>
        </m:GetPriceResponse>
        <soap:Fault>
          ...
        </soap:Fault>
</soap:Body>

</soap:Envelope>

WSDL

网络服务描述语言(Web Service Description Language)

这种文档可描述某个 Web service，它可规定服务的位置，以及此服务提供的操作（或方法）

 <definitions namespace = “http://… ”>
    <types> //定义服务使用的任何复杂数据类型 </type>
    <message>  //调用者和服务之间传递的一条消息，要用到前面定义的数据类型 </message>
    <portType> //定义服务提供什么操作，要用到前面定义的消息
        <operation>//定义了输入与输出</operation>
    </portType>
    <binding> //定义服务如何被调用  
        //将一个抽象的portType映射到一组具体的协议（SOAP或者HTTP）、消息传递样式（RPC或者document）以及编码样式 
    </binding>
    <service> //描述服务位于哪里 </service>
</definitions>

WSDL规范：

服务接口：消息、操作、端口类型

服务实现：绑定、服务、端口

UDDI

UDDI是统一描述、发现和集成（Universal Description, Discovery, and Integration）的缩写。它是一个基于XML的跨平台的描述规范，可以使世界范围内的企业在网络上发布自己提供的服务。

实验1

如何开发自己的web服务？

在Eclipse下使用Axis2插件，将写好的类的class文件打包成web service，生成arr文件，然后发布到axis2，就可以访问到了。

如何调用web service？

使用axis2插件，通过WSDL文件生成代理类，导入相关jar包，编写测试类：

publicclass Client {

    public static void main(String[] args) throws RemoteException {
        // TODO Auto-generated method stub
        MyServiceStub myServiceStub=new MyServiceStub();//初始化桩模块
        SayHello sayHello=new SayHello();//初始化SayHello的方法
        sayHello.setName("SOA");//传入参数
        SayHelloResponse sayHelloResponse=myServiceStub.sayHello(sayHello);//调用sayhello方法传给服务的响应
        System.out.println(sayHelloResponse.get_return());
        }

}

REST是什么

Representational State Transfer 表象化状态转变

REST是一种设计风格。它不是一种标准或协议，也不是一种技术，而是一种思想。

使用URI定位资源；

客户端和服务器之间，传递这种资源的某种表现层；

客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。

REST特征：

采用URI标识资源
使用统一的接口
使用标准的HTTP方法
支持多种资源表示方式
无状态性

为什么要使用RESTful

RESTful可以通过一套统一的接口为多种平台提供服务，无需为每个平台单独写后台接口。
无状态请求可以由任何可用服务器回答，适用于分布式、缓存、云计算等场景

REST与MVC风格的关联与对比

MVC偏重于解决服务器端的逻辑分层问题，以及客户端是逻辑分层的延伸问题。但是MVC很难实现跨语言解耦。

REST风格偏重于统一接口，具体实现可以跨平台和跨语言。REST使用纯HTML作为客户端，没有服务器端和客户端的耦合。

REST式的API服务 V.S. RPC风格

RPC风格的开发关注于服务器-客户端之间的方法调用，是面向方法调用过程的，而REST是面向资源状态的。

REST API设计

统一接口

安全性与幂等性

HTTP请求采用的这些个方法，具有两个基本的特性，即“安全性”和“幂等性”。
安全性是指外系统对该接口的访问，不会使服务器资源的状态发生改变
幂等性（Idempotent）是一个数学上的概念，在这里是指外系统对同一REST接口的多次访问，得到的资源状态是相同的。在网速不够快的情况下，客户端发送一个请求后不能立即得到响应，由于不能确定是否请求是否被成功提交，所以它有可能会再次发送另一个相同的请求，幂等性决定了第二个请求是否有效。
只有GET方法是安全的
只有POST方法是不幂等的。

POST与PUT方法的区别：

POST一般用于添加资源，PUT用于更新资源

若都用于添加资源的时候，POST无需指定被添加资源的URI，而是由服务器指定。PUT则需指定资源的URI。

资源定位

REST使用URI实现资源定位

资源地址相同，但HTTP方法不同的两个方法是两个不同的REST接口。HTTP方法和资源地址结合在一起才可以完成对资源的定位。

@QueryParam

url体现为?key=value的形式

@Path("/testapi")  
public class HelloResource {  
  @GET  
  @Produces(MediaType.TEXT_PLAIN)  
  public String sayHello() {  
      return "Hello World!" ;  
  }  


  @GET  
  @Path("/student")    
  @Produces("text/plain;charset=UTF-8")  
  public String sayHelloToUTF8(@QueryParam("username") String username) {  
      return "Hello " + username;  
  }  

}

url:/testapi/student?username=ice

@PathParam

url里面没有问号，参数由正则表达式匹配出来

@Path("/testapi")  
public class HelloResource {  
  @GET  
  @Produces(MediaType.TEXT_PLAIN)  
  public String sayHello() {  
      return "Hello World!" ;  
  }  


  @GET  
  @Path("/{param}")    
  @Produces("text/plain;charset=UTF-8")  
  public String sayHelloToUTF8(@PathParam("param") String username) {  
      return "Hello " + username;  
  }  

  @GET
  @PATH("{from:\\d+}-{to:\\d+}")
  @Produces(MediaType.TEXT_PLAIN)
  public String getByCondition(@PathParam("from") Integer from,@PathParam("to") Integer to){
    return "from:"+from+" to"+to;
  }
}

url:/testapi/ice

上面两种可以同时混合使用

@FormParam

@Path("form-rs")
public class FormResourse{
public static final String USER = "user";
public static final String PW = "password";

   @POST
public String info(@FormParam(FormResouce.USER) final String user,
                @FormParam(FormResource.PW) final String password){
          return user +" : " +password;
}
}

@CookieParam

内容协商

@Consumer

@Consumer用于定义方法的请求实体的数据类型，只用于JAX-RS2.0匹配请求处理的方法，不做内容协商使用。如果匹配不到，服务器会返回HTTP状态码415（Unsurpported Media Type）

例如：@Consumer({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
@Produces

@Produces 表示类或者方法返回的MIME数据类型。

例如：@Produces({MediaType.APPLICATION_JSON})

可填写字符串：
- ”text/plain” 文本类型
- “text/html” Html类型
- “application/json” JSON类型
- “application/xml” XML类型

业务流程

BPEL规范

业务流程执行语言（Business Process Execution Language, BPEL, 发音为’bipple’或’bee-pell’），也叫业务过程执行语言，是一种基于XML的，用来描写业务流程的编程语言，被描写的业务流程的每个单一步骤则由Web服务来实现。

BPEL是基于Web服务的，并且依赖于WSDL。

一个BPEL流程可以发布为一个WSDL定义的服务，并像其它Web服务一样被调用。而且，BPEL希望一个Web服务合成所包含的全部外部Web服务，都是用WSDL服务契约定义的，这令BPEL流程可以调用其它BPEL流程，甚至可以递归的调用自己。

BPEL包含的范围

处理活动的顺序，特别是网络服务互操作。　
消息和处理实例之间的关系。
在发生错误和例外情况下的恢复行为。　
处理角色之间的基于网络服务关系的双面性

BPEL关键元素：

伙伴链接（PartnerLink）
变量（Variable）
活动（Activity）
关联集合（CorrelationSet）

部分关键元素之间的关系：

流程是由一系列的活动组成的；
流程通过伙伴链接来定义与流程交互的其他服务；
服务中可以定义一些变量；
流程可以是有状态的长时间运行过程，流程引擎可以通过关联集合将一条消息关联到特定的流程实现。

伙伴

一个流程可以调用其他服务，也可以响应来自客户端的请求
一个流程既可以作为服务的请求者，也可以扮演服务的提供者
BPEL把与流程交互的其他服务称为伙伴

伙伴链接

伙伴链接用于实现Web服务长期稳定的交互，描述伙伴之间的关联。
这种关联是通过\

BEPL引擎

BPEL设计工具（BPEL Designer）：大多基于Eclipse实现
业务流模板（Process flow template）：业务流模板遵守BPEL规范。它在设计阶段有BPEL设计工具生成，运行阶段由BPEL引擎执行。
BPEL引擎（BPEL Engine）：执行任何与BPEL标准相符的业务流模板，主要功能包括调用Web服务，数据内容映射，错误处理，事务支持，安全等等。通常BPEL引擎与应用服务器集成在一起。

ESB

企业服务总线（Enterprise Service Bus, ESB）是构建面向服务体系架构的中枢神经系统，它主要提供服务或应用的接入，服务或应用间消息的路由，消息的转换，以及保障消息安全可靠地传递等功能，从而在实现服务或异构系统间可靠交互的同时，保持它们的松散耦合关系。

核心功能：

服务接入
消息中介
消息传递
配置管理

csu_zipple

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
SOA复习手册

感谢ICELEE大佬做的SOA复习笔记！为什么要引入SOA？需求拉动Internet环境下的企业交互现代企业已经不再是封闭的企业，市场分工的日益专业化使得企业之间可能存在大量频繁的交互行为，以发挥各自的竞争优势异构系统的集成与互操作不同企业所应用的软件系统是不同的(异构的)频繁变化的互操作与集成需求企业的业务是频繁变化的；企业的IT应用系统要能够快速支持这种变化的需求。技术推动结构化设计面向
复制链接

扫一扫