2021-数据集成-web service
web service
1. 概述
1.1. A New Web Model
- 一般用户使用Web的模式
- 浏览互相链接的文档
- 通过手工操作处理采购等商业事务
- 下载文件
- Web Service是使用Web的新模式
- 通过程序自动启动和处理商务事务,而并非使用浏览器
- 能够在一个分布式的计算环境中动态地描述、发布、发现和调用
- 基于Web Service的新型应用
1.2. 面向服务架构的技术标准
- SOA (Service Oriented Architecture)
1.3. Web 服务
- 可以在组织内部或者公司之间的异构计算资源中被共享、组合、使用和复用的商业资产
- 是一个可编程的部件,提供一种易于通过Internet获取的商业服务
- 可以是独立的,也可以连接在一起向外部世界提供更强大的系统功能
- 是从分布式面向对象部件的系统向服务网络的逻辑演进,该服务网络提供一个能够跨企业集成的松散耦合的底层基础结构
1.4. What is a Web Service?
- 一个能够使用XML消息通过网络来访问的Interface, 这个Interface描述了一组可访问的操作
- 由SOAP+WSDL包装的Object
- 适应松散耦合的网络环境,可通过Web访问,手段是SOAP Message
- 服务的行为、输入/输出都可使用WSDL描述
1.5. Web services的特征
- 良好的封装性
- 松散耦合
- 使用标准协议规范
- 高度可集成能力
1.6. Web ServiceArchitecture Evolution
1.7. Web Service与其他技术比较
1.8. 考虑Web Services的理由
- 业务上:需要与外部客户通信
- 技术上:
- 应用需要与其它语言编写的客户程序通信
- 客户在防火墙之外
- 管理上:管理托管web service 应用
1.9. 不适用Web Services
- 客户程序与应用使用相同语言编写
- 通信开销大
- 序列化或者远程访问开销大
- Web Services/XML 处理开销大
- Don’t Use XML to Communicate Unless You Really, Really Have To –Floyd Marinescu, The Middleware Company
- Web Services/XML 是用于集成的
1.10. Web service应用场合
- 适用场合
- 跨防火墙的通讯
- 应用程序集成
- B2B的集成
- 软件和数据重用
- 不适用场合
- 单机程序
- 局域网的同构应用程序
2. web service 原理
- Web Service 是为其它应用提供数据和服务的应用逻辑单元
- 应用程序通过标准的Web 协议和数据格式获得Web Service,如HTTP、XML 和SOAP 等,每个Web Service 的实现完全独立
- Web 服务是一个URL 资源,客户端可以通过编程方式请求得到它的服务,而不需要知道所请求的服务是怎样实现的,这一点与传统的分布式组件对象模型不同
2.1. web service模型
2.2. web服务角色的相互关系
- "发布"是为了让用户或其他服务知道某个Web服务的存在和相关信息
- "查找(发现)"是为了找到合适的Web 服务
- "绑定"则是在提供者与请求者之间建立某种联系
2.3. 完整的web服务步骤
- Web 服务提供者设计实现Web 服务,通过Web 服务中介者发布,在UDDI 注册中心注册;(发布)
- Web 服务请求者向Web 服务中介者请求特定的服务,中介者根据请求查询UDDI 注册中心,为请求者寻找满足请求的服务;(发现)
- Web 服务中介者向Web 服务请求者返回满足条件的Web 服务描述信息,该描述信息用WSDL 写成,各种支持Web 服务的机器都能阅读;(发现)
- Web 服务请求者利用从Web 服务中介者返回的描述信息生成相应的SOAP 消息,发送给Web 服务提供者,以实现Web 服务的调用;(绑定)
- Web 服务提供者按SOAP 消息执行Web 服务,并将服务结果返回给Web 服务请求者。(绑定)
3. web service 关键技术
3.1. web service协议栈
3.2. Web Service的关键技术
- HTTP:基于文本的、“请求-响应”(request-response)型的协议
- XML:描述数据的标准方法
- SOAP:表示信息交换的协议
- WSDL:Web服务描述语言
- UDDI:通用描述、发现与集成,它是一种独立于平台的,基于XML语言的用于在互联网上描述商务的协议
3.2.1. HTTP
- HTTP/1.1规定一个客户打开到服务器的一个连接,然后以专门的格式发送一个请求,服务器进行响应,同时如果必要则保持连接的打开状态
- HTTP使用的普遍性及其固有的穿防火墙的能力使它成为主导的Web服务网络协议。
- 由于HTTP是基于文本的协议而缺乏表示远程过程调用(RPC)消息参数值的机制
3.2.2. XML
- XML允许数据被串行化为易于被任何平台解码的消息格式,提供了在网络应用之间交换结构化数据的机制
- Web服务需要一种方法定义Web服务消息中使用的数据类型:XML Schema 规范
- Web服务需要一种机制避免名字冲突,并允许一个程序只处理自己关心的元素:XML名称空间
3.2.3. Simple Object Access Protocol
- SOAP是在松散的、分布的环境中使用XML交换结构化和类型化信息的一种简单协议
- 本身并不定义任何应用语义,只定义了一种简单的以模块化的方式包装数据的机制, 可以使用任何底层传输协议,如HTTP、FTP、SMTP等,其中最常用的是HTTP协议
- SOAP=RPC+HTTP+XML
- 采用HTTP作为底层通讯协议;
- RPC作为一致性的调用途径
- XML作为数据传送的格式
- SOAP代表了xml-rpc的发展,已经被W3C作为一种Internet标准采纳
3.2.3.1. SOAP特性
- 为信息交换设计的轻量协议,用于在网络应用程序之间交换结构化数据,是一种基于XML的机制
- 设计目标是简单性和可扩充性,SOAP中省略了在其它消息系统和分布式对象系统中常见的一些特性
- 无用存储单元收集、消息批处理
- SOAP没有定义一种编程模型或实现,而是定义了一个模块化的包装模型,并在模块内定义了编码数据的编码机制
3.2.3.2. SOAP 与IIOP、JRMP
- 应用范围
- IIOP for CORBA
- JRMP for RMI
- Soap for Web Service
- 编码格式
- IIOP 和JRMP是二进制编码
- SOAP 使用XML封装信息
- 效率
- SOAP比较低
- HTTP不是有效率的通信协议
- XML需要额外的文件解析
3.2.3.3. SOAP的组成
- SOAP封皮(Envelope),定义描述消息所包含信息的框架结构,即消息中包含什么信息、由谁来处理,是必需的还是可选的
- SOAP编码规则(Encoding rules),定义了一个串行化机制,用于交换应用定义的数据类型的实例
- SOAP RPC表示,定义如何表示远程过程调用和响应
- SOAP绑定(binding),定义如何使用底层传输协议进行SOAP消息的交换
3.2.3.4. SOAP消息
- SOAP封皮(SOAP Envelope),描述SOAP消息的XML文档的顶点元素
- SOAP消息头(SOAP Header),可选的,用来扩展其它诸如安全、事务等服务的重要机制
- SOAP消息体(SOAP Body),定义了一个简单的机制来交换要发送给最终SOAP接收者的消息中的必要信息
3.2.3.5. SOAP消息交换模型
- SOAP消息是单方向的,从一个发送者到一个接收者
- SOAP消息交换模型要求接收到一个SOAP消息的应用程序执行下列操作
- 识别SOAP消息中意图供给本应用的部分,本应用可以作为SOAP中介将消息的其它部分传递给另外的应用
- 检验SOAP消息中指定的所有必须处理的部分,并进行相应的处理
- 如果SOAP应用不是消息的最终目的地,它应该在删除所有自己消耗的部分后将消息转发给消息要供给的下一个应用
3.2.3.6. SOAP Message structure
- Request/Response Message
- Request 调用远端对象的某个方法
- Response 返回该方法运行后的输出结果
3.2.3.7. A SOAP Request Message
1 |
|
3.2.3.8. A SOAP Response Message
1 |
|
3.2.3.9. SOAP隐藏了实现
3.2.3.10. 为什么SOAP会成功
- Internet环境下实现技术的多样性使得早期的分布式技术无法实现普遍的互相连接
- DCOM –需要每个连接点都使用Windows
- CORBA –需要每个连接点都有ORB
- RMI –需要每个连接点都使用Java
- SOAP是基于平台独立的选择
- 简单的XML格式
- 可以在任意平台采用任意技术
- 可以使用开放源代码资源
3.2.4. 消息协议
- SOAP本身没有严格地归入Web服务
- SOAP 可以作为一种对任何类型的远程对象或过程的访问机制使用,也可以只是一个简单的消息传递机制
- W3C创建的XMLP(Extensible Markup Language Protocol)
- 类似于SOAP的XML消息协议,包括封皮、对象串行化方式、HTTP传输绑定以及进行远程过程调用的方式几个部分
3.2.5. Web Services Description Language
- Web服务接口由WSDL定义
- 类似IDL, 不过是使用XML格式
- 描述了服务的操纵信息
- 描述服务提供了什么功能
- 服务位于何处
- 服务如何调用
- WSDL是早先技术的综合
- IBM’s NASSL
- Microsoft’s SDL
3.2.5.1. WSDL
- 以XML格式描述网络服务,将服务描述为在包含面向过程或面向文档信息的消息上进行操作的一组端点
- 操作和消息抽象描述,然后绑定到具体的网络协议和消息格式以定义一个端点。相关的具体端点被组合成为抽象端点(服务)
- WSDL 是可扩展的,允许描述任何端点和消息,而不考虑通信使用的消息格式或网络协议
3.2.5.2. WSDL文档结构
3.2.5.3. WSDL的元素
- 类型(Types):使用某种类型系统的数据类型定义的容器
- 消息(Message):对要传送数据的一个抽象定义
- 操作(Operation):对服务支持动作的抽象描述
- 端口类型(Port Type),一个或多个端点所支持的操作抽象集合
- 绑定(Binding):对特定端口类型的一个具体协议和数据格式规格
- 端口(Port):一个单独的端点,由一个绑定和一个网络地址组合在一起定义
- 服务(Service):一组相关的端点的集合
3.2.5.4. 操作和消息的抽象
- 一个Web服务由一组端口定义
- 端口由绑定到一个具体协议和数据格式规范的一组抽象操作和消息定义
- WSDL中端点和消息的抽象定义与其具体网络配置和数据格式绑定相分离
- WSDL定义了一个公共的绑定机制,将特定的协议或数据格式或结构连接到抽象的消息、操作或端点,从而可对抽象定义复用
3.2.5.5. WSDL Example
- OMG-IDL为:
1 |
|
1 |
|
1 |
|
3.2.6. Universal Description, Discovery and Integration(UDDI)
- 在哪里以及如何找到需要的信息?
- 一套基于internet为Web服务提供信息注册中心的标准规范
- UDDI规范在底层协议的基础上又定义了一层规范,使不同企业能够以相同的方式描述自己提供的服务和查询对方提供的服务
- IT业界和商业界的领导者的合作
3.2.6.1. Service Provider
- 提供e-Business Service
- 通过Service Registry发布(Publish)其提供的可用的Service
3.2.6.2. Service Registry
- 为Service的发布和定位提供支持
- 类似电话黄页
3.2.6.3. Service Requestor
- 通过Service Registry发现(Find)需要的Service
- 绑定(Bind) Service Provider提供的Service, 并实施调用
3.2.6.4. Where is SOAP and WSDL?
- WSDL:Publish的内容、Find的返回结果和Bind的信息都是WSDL描述的服务信息
- SOAP:Service Registry的访问(Publish/Find)、Service的访问都是通过SOAP Message实现
3.2.6.5. How UDDI works
3.2.6.6. Problems UDDI Solves
3.2.6.7. UDDI Vision and Process
- 从现有的标准(standard)开始
- TCP/IP, HTTP, XML
- Industry-specific schemas
- Shared vision of open protocols
- 通过Web Service的形式实施和拓展
- Common web services “stack”
- Shared implementation to avoid confusing customer
- Public specs, open service, inclusive process
- 将转变为一个标准实体组织
- Manage design process for 3 revs
- License control and IP to a 3rd party
3.2.6.8. 信息结构
- 商业实体(Business entity):描述商业信息,如名称、类型等
- 商业服务(Business service):已发布的Web服务的集合
- 绑定模板(Binding template):访问信息,如URL
- 技术规范(tModel):对服务类型的技术规格说明,如接口定义、消息格式、消息协议、安全协议等
3.2.6.9. UDDI的三类信息
- 白页,包括企业的名称、地址、联系方式和企业标识,并允许其它公司按照名称查找目录
- 黄页,包括基于标准分类法的行业类别
- 绿页,包括了关于该企业所提供的Web服务的技术信息,其形式可能是一些指向文件或URL的指针,而这些文件或URL是为服务发现机制服务的
3.2.6.10. 编程接口
- UDDI规范提供了编程接口,允许商业注册一个Web服务,以及查找指定Web服务的注册。一旦想要的Web服务被确定,将提供一个指向WSDL文档所在位置的指
- 查询API
- 构造搜索和浏览UDDI注册信息的程序
- Web服务出错处理
- 发布API:创建各种类型的工具,以直接与UDDI注册中心进行交互,便于企业技术人员管理发布信息
3.2.6.11. UDDI and SOAP
4. 大众点评第三方团购券案例
- 大众点评第三方团购券是在用户支付后,由系统实时请求第三方服务器生成券码而成的团购券;
- 第三方服务器使用了Web Service技术,大众点评券系统需要根据其接口实现信息交互;
- 本案例以阳光绿洲酒店团购举例
4.1. 系统分析
4.2. 开发环境与技术
- JDK1.5+Eclipse-jee
- Maven+Jenkins+GitHub
- 技术框架:Spring+Struts2+iBATIS
- Axis2
4.3. 阳光绿洲系统(服务端)开发
1、 建立服务端JavaEE项目,实现生成券码方法
1 |
|
4.4. 发布Web Service
- 打包Service,设定服务名称、所用类名和输出路径,并选择Apache Axis2的服务进行发布
- 浏览器打开服务页面,将会生成对应的wsdl
4.5. WSDL文档
1 |
|
4.6. 大众点评券服务生成券流程
4.7. 大众点评(客户端)发券流程
1 |
|
4.8. 通过axis调用webservice实现
1 |
|
4.9. 发布大众点评券服务
- 在Jenkins上构建项目
- 打包项目jar包,发布到服务器
2021-数据集成-web service
https://spricoder.github.io/2021/05/01/2021-Data-Integration/2021-Data-Integration-web%20service/