web服务（电子服务系统设计）知识点汇总
前言
第一章 WS基础
第二章 分布式计算基础架构
第三章 XML概览
第四章 SOAP简单对象访问协议
第五章 描述WEB服务
第六章 WEB服务的注册和发现
第七章 WEB服务的寻址和通知（未完成）
前言
本文档原意为考试复习所用，基于 《web服务：原理与技术》 课本。但是，自学的同学也可以以此文档为参考文档。博主是西工大软院学生，此文档为自己总结，对工大的学子肯定更有用一些。
另，工大的学弟学妹们，陈勇老师的考试真的不难，xml的格式和概念是重中之重。希望大家合理利用时间，后面的网络与分布式才是令人怀疑人生，博主本年大题只有一个SOA结构图解释和Schema手写代码。祝大家学习顺利，考试通过。
第一章
什么是WS:
当服务使用因特网作为通信手段以及使用基于因特网的标准时，即为Web服务
Web服务是一个可通过因特网使用的自描述、自包含软件模块，这些软件模块
可完成任务、解决问题或代表用户、应用程序处理事务
既可以是进行简单的请求，也可以是需要访问和综合多个数据源信息的完整的
业务应用程序
WS完整定义：
Web服务是一个平台独立的、松耦合的、自包含的、基于可编程的Web应用程序，
可使用开放的 XML标准描述、发布、发现、协调和配置这些应用程序，并用于开
发分布式的互操作应用程序。
- Web服务的特性
- Web服务的类型
- 简单服务（信息型服务，无状态web服务），通过请求/响应序列交互
- 复合型服务（功能是粗粒度的，有状态），在进入操作和离开操作间协调
- 服务描述
- 功能性描述，非功能性描述
- 状态属性
- 松耦合
- 服务请求者无须了解服务提供者实现的具体技术细节。服务请求者通常使用消息来调用服务，服务提供者也通过消息进行响应
- 服务粒度
- 同步特性
- 同步或RPC方式
- 异步或消息（文档）方式 文档类型服务或消息驱动类型服务
- 良定义
- 服务间的交互是良定义的
- 服务使用环境
- 可替代的服务
- 关键任务服务
- Web服务的类型
服务接口和实现
对接口和实现具有明显的区分
服务实现可包含服务接口规范以及具体组件的实现
服务之间进行交互的唯一方式是通过它们的接口
SOA面向服务的体系结构
可通过接口向终端用户应用或网络上的其他服务提供服务
使得已有的技术间具有通用的互操作性，并使得未来的应用和体系结构具有可扩展性
SOA是一种体系结构类型，使用面向服务的方式进行计算，从而增强了互操作性
SOA模型：
三个角色：服务提供者，服务注册中心，服务请求者
三个操作：
发布：服务描述、注册
查找，绑定
SOA层次
三类不同的SOA入口点：
实现企业服务编配、
提供给整个企业的服务、
实现端到端协作型业务流程
六个层次：
业务领域
业务流程
业务服务
基础架构服务
服务实现
运营系统
Web服务的技术架构
（最好把书上技术架构的图背过，后面的章节都是对这个图的拓展）
信息交换：SOAP，简单对象访问协议
服务描述：WSDL
服务发布：UDDI
Web服务的优点
既能支持常见的业务问题，又能根据市场需要的变化做到随需应变。
不断发展，从而能够包容电子商务、企业应用集成、传统的中间件以及web技术。
Web服务的不足
事务标准还很不成熟
缺乏表达业务语义的手段
不同标准之间相互重叠或相互冲突
第二章
异步通信：
消息存储转发：
发送程序可将消息发送到一个消息队列，接收程序可根据需要从消息队列中接收消息
唯一做的就是以某种方式注册到或连接到消息队列子系统
存储与转发排队机制是多对一消息传送
消息的发布和订阅
可伸缩性稍大一点
消息服务器负责向订阅了主题的订阅应用发送被发布的消息。
所有订阅者都有一个消息事件侦听程序
消息的发布者不期望回复
事件驱动的处理机制
客户端：兴趣对象，通知的生成者；
当事方，通知的使用者
事件通知服务通过“选择”处理来确定发布的消息与哪些客户端的兴趣相一致，
并且仅路由和发送那些符合客户端兴趣的通知
点到点排队
客户端通过队列发送和接收消息
请求/应答的消息传送方式
同步，Web服务客户端会因同步响应堵塞或等待
异步，请求者认为应答会稍后到达，并会继续它的其他工作
集成代理
集成代理完成内容和格式转换，将收到的消息转换为目的系统能够理解和利用的形式。
集成代理是一个应用之间的中间件服务，可进行一对多、多对一及多对多的消息分发
第三章
Xml（可扩展标记语言），用于网络上电子标记文本的描述和发送
XML被设计为传输和存储数据，其焦点是数据的内容。XML旨在传输信息
Xml特点：
Xml是不作为的
Xml仅仅是纯文本
可以发明自己的标签
Xml是独立于软硬件的信息传输工具
XML文档 = 命名容器+命名容器所包含的数据值
XML 文档必须包含根元素。该元素是所有其他元素的父元素
XML 文档中的元素形成了一棵文档树。
在起始标签中添加属性，属性不可以嵌套
尽量使用元素来描述数据。而使用属性来提供与数据无关的信息
在WWW中，统一资源标识符(URI)是标识资源的基础
XML命名空间使得不同的元素可以具有相同的本地名
XML Schema的作用是定义XML文档的合法构建模块
XSD(重中之重)：
<schema> 元素是每一个 XML Schema 的根元素
一个元素假如包含子元素和/或子属性，则该元素为复合类型
简易元素：仅包含文本的元素
复合元素`<xs:complexType>`：（我们考了两题）
空元素
包含其他元素的元素，
仅包含文本的元素<simpleContent>，
包含元素和文本的元素`<xs:complexType mixed=”true”>`
元素组，用group声明、引用
<xs:group name=”xx”>
<xs:group ref=”xx”>
属性组，用attributeGroup声明，引用
<xs: attributeGroup name=”xx”>
<xs: attributeGroup ref=”xx”>
<xs:any/>未定义元素扩展
<xs:anyAttribute/>未定义属性扩展
第四章
一条SOAP消息就是一个普通的XML文档，包含可选的Fault元素，提供有关在处理消息所发生错误的信息
SOAP的Envelope元素是SOAP消息的根元素。
SOAP信息可以规定编码规则集，该规则集将所定义应用的XML数据串行化
SOAP<Header>元素
<Header>元素包含一些信息块，主要关于如何处理消息
`<Header>`元素包含了与端点或中间传输点相关的所有处理线索
`<Header>`的目的是对扩展的消息格式封装，且无须与有效载荷发生关联，
也不需要修改SOAP的基本结构
直接子元素称作“头块”，并表示为一个数据逻辑分组
每一个头块都应当有自己的命名空间，帮助SOAP应用标识头部以及分别处理这些头块
actor属性可被用于将Header元素寻址到一个特定的端点 soap:actor=”URI”
mustUnderstand属性可用于标识标题项对于接收者来说是强制的还是可选的（0/1）
许多头部涉及其他SOAP处理节点（称作SOAP中介）的参与，中介既可以接收也可以
转发SOAP消息
SOAP消息传送的模块性使得处理SOAP消息的代码页可以模块化
SOAP<Body>
具体应用的XML数据（有效载荷）存放在SOAP体中
<Body>元素的直接子元素都必须有合适的命名空间
<Body>元素包含具体应用的数据或一个出错消息，不能同时携带这两类信息
<Body>元素和根元素的一个区别是它既是请求对象又是响应对象
SOAP优点：
简单性
可移植性
与防火墙的相容性
使用开放标准
互操作性
被广泛接受
适应变化
SOAP缺点：
采用了并不适合所有情况的请求/应答体系结构
SOAP是无状态的
SOAP为基于值的串行化，而不支持基于引用的串行化
第五章
为何需要服务描述：
为了开发基于服务的应用和业务
实现SOA松耦合，将服务提供者和服务请求者的应用集成在一起，减少定制程序
的开发以及更好地理解相关知识
WSDL描述的三个基本属性：
服务做些什么，
如何访问服务，
服务位于何处
WSDL本质：
告诉服务的使用者如何将请求消息格式化，通过何种通信协议在何处访问web service
<portType>描述一个web service、可被执行的操作，以及相关的消息
<message> 元素定义一个操作的数据元素
<types>元素定义web service使用的数据类型，WSDL使用XML Schema语法来定义数据类型
<binding>元素为每个端口定义通信协议细节
<service>元素，此元素可把若干个web services的定义组合在一个单一的WSDL文档中
服务请求者能够描述Web请求的基本格式或者编码
WSDL规范事实上分成两部分：
服务接口定义（抽象接口）
服务实现定义（具体端点）
服务客户端通过调用操作与Web服务进行交互，在Web服务接口中，可以将相关的操作进行分组
WSDL指定了描述Web服务的语法和句法，可将Web服务描述为通信端点的集合
Web服务接口定义描述了消息、操作和端口类型，并且具体的描述保持了平台独立性和语言独立性
WSDL中，<types>、<message>、<part>、<portType>、<operation>元素描述了Web服务的抽象接口
WSDL的目的就是首先抽象地定义Web服务，然后规定WSDL开发者如何实现这些服务
WSDL的服务实现部分包含元素<binding>、<port>和<service>，并描述了服务提供者如何实现一个特定的服务接口
服务实现描述了服务位于哪里
通过<import>元素，服务实现文档可以包含对多个服务接口文档的引用(考了)
WSDL消息交换模式
两类基本的消息接收和发送版本
单个的消息接收传送操作和对应的发送操作
同步双向消息交换
第六章
在服务注册库中发布一个Web服务，需要两个同样重要的操作：Web服务的描述和注册
电子商务注册通常有两类：
基于文档的服务注册，基于元数据的服务注册
UDDI：统一描述、发现和集成
UDDI是一个跨行业的注册标准草案
UDDI的目的是供开发工具以及使用Web服务标准的应用使用
UDDI是一个包含轻量级数据的注册库
目的是提供它所描述的资源的网络地址
核心概念是UDDI业务注册库，用来描述业务实体和它的Web服务的XML文档
UDDI业务注册提供的信息包含三个相关的组成部分：
白页：包括地址、联系方式以及其他的一些联系信息
黄页：基于行业分类法对信息进行分类
绿页：关于服务的业务能力和相关信息，包括对于Web 服务规范的引用和指向各种基于
文件和基于URL的发现机制的指针
UDDI是按标准化方式设计的，并不受限于任何技术
UDDI提供了按照分类法对业务和服务进行分类的一种机制
UDDI用例模型：
角色：产业联盟、标准化组织/UDDI注册库/服务提供者/服务客户端
行为：
服务客户端（基于不同的标准发现服务类型定义和服务）UDDI注册库
服务客户端（获取服务类型定义细节）产业联盟、标准化组织、服务提供者
服务客户端（调用所发现的服务）服务提供者
UDDI注册库都供了对Web服务分类、编目和管理的机制，从而可以发现和使用那些Web服务
UDDI的主要目的是Web服务的数据和元数据表示（目的到底是啥？）
四类核心信息类型：
业务实体
业务服务
绑定模板
服务规范（tModel）
在UDDI数据结构中有一个层次关系 （考了）
业务将发布包含一个或多个业务服务的业务实体 `<businessEntity >`
服务都有一些描述性的信息 `<businessService>`，并且这些服务都能有一个或多个
绑定模板`< businessTemplate >`
tModel指向服务的规范或者接口定义
tModel和bindingTemplate之间的关系通常是多对多的
businessEntity包含了特定业务单元（服务提供者）白页信息，支持业务信息的发布和发现
businessEntity包含businessKey属性，具有唯一性的业务标识符
categoryBag元素对服务的分类标识
businessService结构对这些Web服务进行分组
包含在businessService元素中的信息映射到有关公司的黄页信息
每个bindingTemplate表示了一个不同的Web服务port或binding
绿页数据是Web 服务的技术描述，它驻留在bindingTemplate元素中
bindingTemplate元素必须包含下列两者之一：
一个特定服务的接入点
通向接入点的间接途径
定义bindingTemplate 结构时， 可声明<accessPoint>或<hostRedirector>，但不能同时声明这两者
tModel提供了描述服务的技术细节的绿页信息
当描述Web服务如何与它的客户端进行交互时，tModel的主要作用就是提供一个技术规范
WSDL到UDDI的映射模型
WSDL到UDDI的映射模型可帮助用户发现那些实现了标准定义的服务
当发布服务时，第一步就是创建服务接口定义
UDDI API
UDDI API是一个接口，可以接受封装在SOAP信封中的XML消息
所有的UDDI交互都使用请求/响应模式
查询API
浏览 比较宽泛的查询标准的进入点、服务或者技术特性
下钻 获取更具体的功能部件
发布API
授权 客户端可以获得相应的访问权限、获取授权令牌、终止会话和授权令牌
保存 客户端可以在UDDI中添加或更新信息
获取 可以获取所发布的数据结构的概要数据
删除 客户端可以在UDDI中删除信息
随着所开发的应用的类别不同，可以在设计/构建或者运行时查询
查找业务实体
通过名字来查找业务实体
通过类别来查找业务实体
查找tModel
所有的WSDL服务接口都作为tModel发布
使用UDDI find_tModel可以检索到已分类的tModel，返回一个键的列表
使用下钻get_tModelDetail，能检索到一个具体的服务接口描述
UDDI用例模型与部署的多样性
UDDI用例模型假设了一些不同的业务信息提供者角色
注册库运行者，
标准组织和行业协会，
服务提供者
部署方式：
电子交易市场UDDI
业务合作伙伴UDDI注册库
门户UDDI
内部UDDI
扫一扫
282
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
