中国教育课件网-GOODPPT.COM
首 页教学教案课件下载
  首页 教学教案课件下载 | 语文| 数学| 英语| 物理| 化学| 政治| 生物| 地理| 音乐| 美术| 历史| 计算机| 课件素材| 其他课件| 考试题库 更多»  
 
热门标签:计算机(8)  Authorware(5)  课件设计制作技巧(1)
 
我要上传课件
共享您的课件,轻松获取积分!
 
当前位置:中国教育课件网课件下载计算机
 企业级软件架构技术_SOA引论
 
运行环境: Win9X/Win2000/WinXP/Win2003/
课件语言: 简体中文
课件类型: PPT - 计算机
授权方式: 共享版
课件大小: 13.4 MB
推荐星级:
更新时间: 2011-09-01 21:53:34
联系方式: 暂无联系方式
官方主页: Home Page
图片预览: 没有预览图片     论坛转帖
解压密码: 本站默认解压密码:www.goodppt.com
下载统计:
 

欢迎登录课件网

  课件简介
 


课堂思考与分析
基本概念
构件   组件   中间件   SOA  设计模式
软件架构   信息孤岛
分析与思考
如何开发大规模的企业级软件架构?
面向服务的SOA架构特点与优势?
新网络技术条件下催生哪些软件开发技术?
目      录

网络计算—企业计算、网格计算
网格和Web Services融合
Open Grid Services Architecture

企业级应用
企业级应用是指那些为商业组织、大型企业而创建并部署的解决方案及应用。这些大型企业级应用的结构复杂,涉及的外部资源众多、事务密集、数据量大、用户数多,有较强的安全性考虑。
作为企业级应用,其不但要有强大的功能,还要能够满足未来业务需求的变化,易于升级和维护。
网络时代分布式系统的发展
在网络时代出现了以网上传输为基础的大型分布系统,如税务的数据大集中,银行的通存通取、机票订票、电子商场等。如下图所示:
三层体系结构的缺陷
三层体系结构有力地提供了一种分布式系统的解决方案,实现了一种紧耦合的分布式系统,组成一个自成体系的单个应用软件。而如何将现有的多个应用软件,通过网络将其整合成一个集成系统,以能做更多更好的事。而早期的技术都无法解决。


Internet环境下软件基本形态
网络构件软件运行设想

网络条件下构件软件开发设想

No Application Is An Island
企业的信息系统
问题
信息孤岛
系统间的业务协作由手工完成
重复信息与信息不一致
缺乏完整的信息全貌
No Company Is An Island

新的问题
系统过于庞大而难于调整
无法面对新的改变而不得不开发新的系统
多系统的局面无法避免
如何协同多系统?
产品信息变化了,怎么办?
在现代企业中用户面临挑战
基于角色的个性化电子工作场所
信息烟囱的挑战
缺乏标准
信息分散
不一致的信息
基础架构建设缺乏合理规划
信息挑战 – IIS : 信息烟囱(Information in Silos)
烟囱现象的分析 - 重新审视数据和应用的关系
传统
数据从属于应用,应用流程决定了数据的产生,作用和消亡
不同应用的数据没有内在联系;
同一个对象在不同的应用中有不同的(甚至是矛盾的)”记录”

当前
数据从应用中松绑
建立企业级数据模型
数据正在成为价值超越具体应用的企业资产

未来
数据成为一种服务!
不同应用引用同一个数据记录
数据的意义在跨企业在公网上共享!
烟囱现象的分析 – 过度的分布式
分布式
应用和关系数据库的结合;
访问层,业务流程实现层,和数据库服务层的捆绑
数据服务器和存储的网络化分布部署
分布式的优点_为什么分布?
业务流程快速实现
灵活的应用部署
“本地化”建设、开发、运行,符合现有的体制
“入门”采购成本低
分布式的问题讨论
数据捆绑附属于流程,缺乏全局完整性
系统的复杂性(服务器/存储设备的数量),管理代价和RAS问题
垂直的业务流程之间的整合问题
烟囱现象解决 – 集中
集中式的特点
统一的访问接入 – 门户;
应用层整合 EAI和组件化应用开发SOA
数据大集中 – DCC – 物理和逻辑集中
集中式的优点_为什么集中?
回避技术风险,业务风险和道德风险
解决系统和数据管理问题,提高RAS
建立完整的一致的数据体系,提供准确的商业智能
便于系统的扩容
集中式的问题讨论
数据操纵和数据管理的职能分离
系统运行维护的要求
数据的私密性和服务性的矛盾
面临的挑战: 如何把相关人员/信息/流程集合起来
企业面临的挑战—整合IT资源


技术如果使用恰当可以成就业务创新
标准(全面的,包括开源组织)成就互操作性
支持自我定义和松耦合的基础架构也已经出现
现有的工具也可以通过自动化、虚拟化和整合来重用目前的资源
指令语义学等技术也成就自我定义、宣示式的编程技术的发展
类似面向方面的编程( Aspect Oriented Programming)等强大的分析和构建技术也使以前不可能的事情现在变为可能。

一个更为实际的业务转型之路
渐进式的实施
清晰的、可量化的业务回报
把业务功能不断地重新部署到那些最合适的地方 – 在公司内,给合作伙伴或完全外包
允许在不大范围停顿业务运作的前提下进行业务流程的转型和创新
IT 架构成为业务创新的”瓶塞”
孤立的系统和应用无法重用,每个项目都是一个小社会,但是整个企业/行业还是一片片的孤岛和荒漠
随机的整合建立了一些难以改变和维护的联结
标准的缺乏使得有意义的互操作性成为天方夜谭
僵化的基础架构使得在现有基础上渐进式的优化无法‘值回票价’
整合驱动创新
技术和业务的整合成就业务创新
技术创新必须转化为业务竞争力
业务和技术应该一起规划
架构必须具有灵活性,快速地适应不断变化的业务模式
业务竞争力必须差异化,而整合必须拥抱标准
开放标准
开放源码
整合驱动创新
整合资源形成自己的核心竞争力
不断优化流程,在行动中制胜
随需应变的运营环境: 整合
企业集团信息化管理集中战略依据
信息资源管理是电子政务发展面临的策略问题,过度的分布和数据与应用的紧密捆绑导致了信息烟囱和孤岛现象

网络和通信资源(带宽,访问速度和接入方式)、存储资源、计算资源的发展;SOA 、JAVA/J2EE/XML等软件技术的成熟为新的大集中模式确定了技术基础

业务创新,合规运行需要数据的集中管理

数据集中管理将使IT部门成为信息资源的运营服务提供者
更高的业务灵活性需要更高灵活性的IT架构支持
应用集成:让独立设计的应用共同工作
信息作为服务  ( IAAS : Information As A Service ) 破除数据孤岛,提供灵活的信息基础设施
数据不仅仅是用于跑业务  - 数据是战略资产,服务业务创新
应用整合之路 建立服务型的企业信息管理
走向集中的挑战与应对
解决方案与策略
信息资源管理是电子政务发展面临的策略问题,过度的分布和数据与应用的紧密捆绑导致了信息烟囱和孤岛现象
随着网络普及化,越来越迫功需要将现有多个应用系统集成,以能实现更强的信息处理功能。如电子商务的供应链、智能交通、电子政务、数字地球等。
网络和通信资源(带宽,访问速度和接入方式)、存储资源、计算资源的发展;SOA 、JAVA/J2EE/XML等软件技术的成熟为新的大集中模式确定了技术基础
业务创新,合规运行需要数据的集中管理,数据集中管理将使IT部门成为信息资源的运营服务提供者
SOA是当前最理想的解决方案。

多应用集成是当前迫功要解决的技术
随着网络普及化,越来越迫功需要将现有多个应用系统集成,以能实现更强的信息处理功能。如电子商务的供应链、智能交通、电子政务、数字地球等。
SOA是当前最理想的解决方案。
目      录
关于SOA
从程序员的角度,SOA是一种全新的开发技术,新的组件模型,比如说Web Service;从架构设计师的角度,SOA就是一种新的设计模式,方法学;从业务分析人员的角度,SOA就是基于标准的业务应用服务。
从概念的角度,IBM对SOA的定义是最为全面的,既SOA是一种构造分布式系统的方法,它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素:
     一个体系架构,用开放的标准将软件资产(Asset)化为服务
    提供标准的方法来表示软件资产及其交互
    单独的软件资产作为构造单元,被重复使用来开发其他应用
    将关注点从细节实现转移到应用(application)组装
    整合企业外部的应用(B2B)的方式
    开发(现在)和整合(未来)的统一

SOA – 软件构造方法的新发展
SOA出现的必然性
面向机器语言(Monolithic)的开发模式:需要根据不同平台的机器语言来开发代码。
面向过程(Procedure)的开发模式:独立于机器的程序语言(C, Pascal等)使开发过程变得简单了,用过程来代表一个抽象的代码集合,包装重用现成的代码。
面向对象(Object)的开发模式:用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk,Java等),提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射,更接近人类的自然思维方式。
SOA出现的必然性
面向组件(Component)的模式:随着软件开发规模的扩大,在涉及分布式、异构等复杂特征的环境中,代码级别的重用性差,可维护性差,效率低的弱点是不可逾越的,因此人们以架构运行环境(如.Net,J2ee等)来提供完善的支撑平台,从而把开发者解放出来,更专注于业务核心的开发。而这些业务功能(Business Function) 以组件的形式(DCOM, EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。
面向服务(SOA)的模式:当软件的使用范围扩展到更广阔的范围,往往会面对更加复杂的IT环境和更加灵活多变的需求。服务(Service)的概念出现了,人们将应用(Application)以业务服务(Business Service)的形式公布出来供别人使用,而完全不需要去考虑这些业务服务运行在哪一个架构体系上,因为所有的服务都讲着同样的语言。SOA体现了"变化就是永恒"的思想。SOA的核心体现在企业应用或者业务功能上的"重用"和"互操作",而不再把IT与业务对立起来。
面向服务的体系架构 (SOA) -  概念性的定义

SOA基本特征
面向服务体系结构特征:
自包含和模块化
互操作性
松散耦合
位置透明
可组合性
明确定义的接口
SOA基本特征
服务的封装(encapsulation)
将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变,使得用户远离具体实施上的变更。
服务的重用(reuse)
服务的可重用性设计显著地降低了成本。为了实现可重用性,服务只工作在特定处理过程的上下文(context)中,独立于底层实现和客户需求的变更。
服务的互操作(interoperability)
通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。
SOA基本特征
服务是自治的(Autonomous)功能实体
服务是由组件组成的组合模块,是自包含和模块化的。SOA强调提供服务的功能实体的完全独立自主的能力。SOA强调实体自我管理和恢复能力。
常见恢复的技术,如事务处理(Transaction),消息队列(Message Queue),冗余部署(Redundant Deployment)和集群系统(Cluster)。
服务之间的松耦合度(Loosly Coupled)
服务请求者到服务提供者的绑定与服务之间应该是松耦合的。服务请求者不知道提供者实现的技术细节,比如程序设计语言、部署平台等等。
服务请求者往往通过消息调用操作,请求消息和响应,而不是通过使用 API 和文件格式。
服务是位置透明的(location transparency)
服务是针对业务需求设计的。需要反应需求的变化,即所谓敏捷(agility)设计。实现业务与服务分离,就必须使得服务的设计和部署对用户来说是完全透明的。
SOA基本特征
明确定义的接口(well defined interface)
Web服务使应用功能得以通过标准化接口(WSDL)提供,并可基于标准化传输方式(HTTP和JMS)、采用标准化协议(SOAP)进行调用。
采用企业服务总线ESB
既为了建立所有这些信息的适当控制,又为了应用安全性、策略、可靠性以及会计方面的要求,在 SOA 体系结构的框架中加入了一个新的中间件平台。这个对象就是企业服务总线(Enterprise Service Bus,ESB),它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然 ESB 并不是绝对必需的,但它却是在 SOA 中正确管理您的业务流程至关重要的组件。
ESB 本身可以是单个引擎,甚至还可以是由许多同级和下级 ESB 组成的分布式系统,这些 ESB 一起工作,以保持 SOA 系统的运行。在概念上,它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。
如何做到随需应变?
除随松耦合功能外,每个需求用工作流方式描述(BPEL语言),您需要定义整个应用程序如何在服务之间执行其工作流。此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与不为您控制的外部合作伙伴进行的操作。将各应用的服务串起来,也可以通过自展的方式扩展新的服务,一旦用语言写出其工作流的业务过程后,通过编译自动实现,由此实现了随需应变。
目前IBM、BEA等企业提供了方案、提供了开发平台和运行平台、可以半自动地补充和增加新的业务流程。
SOA的优点
利用现有的资产 方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值,而不必重新从头开始构建。
更易于集成和管理复杂性 将基础设施和实现发生的改变所带来的影响降到最低限度。因为复杂性是隔离的。当更多的企业一起协作提供价值链时,这会变得更加重要。
更快地整合和现实 通过利用现有的组件和服务,可以减少完成软件开发生命周期所需的时间。这使得可以快速地开发新的业务服务,并允许组织迅速地对改变做出响应和缩短开发时间。
减少成本和增加重用 通过以松散耦合的方式公开业务服务,企业可以根据业务要求更轻松地使用和组合服务。

为什么要面向服务的架构?
面向服务可以封装和组件化流程和系统
有助于复杂度管理
允许受控的变更
支持持续性发展
业务能力和业务流程可以作为服务进行建模
企业把这些流程的接触点展现给企业内部和外部的使用者
有助于流程的自动化
有助于松耦合的解决方案
开放的访问有助于对业务流程的更深层次的了解
有助于解决异构问题
SOA不仅仅是技术上的革新,更是企业战略性的变化, 是实现业务敏捷性的关键
有助于降低软件系统总体成本的因素
任何整合要求采用基于开放式标准的方法(J2EE, JCA, web services …等)
适用于所有整合项目(功能,平台等)
建立并重用整合资产如应用适配器,数据实体,转型图及整合逻辑
与加入的应用隔离提高灵活性,易于变更并持续降低管理成本
整合中心应用独立,便于根据行业具体要求组合并管理可重用的整合逻辑
应用环境下快速应变并能经济高效地加以变更—引入新应用,替换原有应用,利用购并机遇等,以及采用现行标准和协议扩展互联网连通性
安全、可扩展和稳定整合架构保证所有应用之间交易的高度一致性
快速实施新的整合要求–加快关键效果的实现速度
通过集中式管理改善整个整合框架的管理和控制
采用基于开放式标准的工具,以标准化方法构建新的整合资产
关于SOA与WEB
软件的具体实现技术诸如Web 服务与SOA是两回事,SOA是一个概念,方法学, 或者用一个更时髦的词:一种模型。Web 服务呢?它是一种具体的实现技术,就像EJB一样。SOA ≠ Web服务。
客观讲,Web 服务是目前最适合实现SOA的技术之一,用Web 服务来封装业务服务是个不错的选择。因为Web服务是标准的,WS-I协议保证了来自不同厂商的Web服务即使运行在不同的平台上,底层的实现机理不同也可以顺利交互,这是以前的任何一种技术如CORBA,EJB,或DCOM都不能做到的。而且,Web服务的定义与实现是分开描述的,即松散耦合,因此,可以很方便地替换服务的内在实现而不会对现有的系统造成任何冲击,这也极大地促进了IT架构的灵活性。


SOA架构基本的要求
SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用;
服务间保持松散耦合,基于开放的标准, 服务的接口描述与具体实现无关;
灵活的架构 -服务的实现细节,服务的位置乃至服务请求的底层协议都应该透明;
企业集团商务整合的基础架构
SOA Reference Architecture
Summary – Products of the SOA Reference Architecture
目      录
Definition of an ESB
Definition of an ESB
什么是ESB ?
    全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。
    ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。
什么是ESB ?
ESB(企业服务总线)技术描写成“通过起到中间件的中间层作用而实现面向服务架构(SOA)的软件基础设施,通过这样的中间件,就能广泛利用一套可重复使用的商业服务。”
ESB不仅需要支持异构环境中的服务、消息,以及基于事件的交互,还被认为具有适当的服务级别和可管理性。
ESB定义
ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于:
    面向服务的架构 -分布式的应用由可重用的服务组成
    面向消息的架构 - 应用之间通过ESB发送和接受消息
    事件驱动的架构 - 应用之间异步地产生和接收消息

ESB定义
企业服务总线(Enterprise Service Bus,ESB)将事件驱动的方法和面向服务的方法结合使用,以简化业务单元的集成,从而在异类平台和环境间建立联系。ESB 充当允许不同应用程序进程之间进行通信的中间层。部署到企业服务总线的服务可以由使用者或事件触发。它同时支持同步方式和异步方式,可促进一个或多个参与者之间的交互(一对一和多对多通信)。因此 ESB 可提供 SOA 和 EDA 范例的所有功能。
企业服务总线是一种体系结构模式,可以采用许多不同的产品在组织内实现,并组装起来作为联合总线。
ESB在SOA架构中的角色
ESB就是在SOA架构中实现服务间智能化集成与管理的中介。ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构,它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。

ESB是特定环境下(SOA架构中)实施EAI的方式(一):
ESB系统中,被集成的对象被明确定义为服务,而不是传统EAI中各种各样的中间件平台,这样就极大简化了在集成异构性上的考虑,因为不管有怎样的应用底层实现,只要是SOA架构中的服务,它就一定是基于标准的。
ESB在SOA架构中的角色
ESB是特定环境下(SOA架构中)实施EAI的方式(二):
ESB明确强调消息(Message)处理在集成过程中的作用,这里的消息指的是应用环境中被集成对象之间的沟通。ESB系统由于集成对象统一到服务,消息在应用服务之间传递时格式是标准的,直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议,那么对消息的处理就完全不考虑底层的传输细节,而直接通过消息的标准格式定义来进行。
ESB中对消息的处理就会成为ESB的核心,因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。传统的EAI系统中,也曾经提出过信息总线的概念,通过某种中间件平台,如CORBA来连接企业信息孤岛,但是,ESB的概念不仅仅是提供消息交互的通道,更重要的是提供服务的智能化集成基础架构。
ESB在SOA架构中的角色
ESB是特定环境下(SOA架构中)实施EAI的方式(三):
事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式,一种是调用(Call), 即请求/回应方式,这是常见的同步模式。另一种为单路消息(One-way),它的目的往往是触发异步的事件, 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的,因此,这种异步服务之间的消息交互也是ESB必须支持的。
ESB的很多功能都可以利用这种机制来实现,例如,SOA中服务的性能监控等基础架构功能,需要通过ESB来提供数据,当服务的请求通过ESB中转的时候,ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。
ESB Solution Patterns  - EAI Infrastructure for SOA
The Role of the ESB in SOA
ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而,SOA 可能还有单独的业务服务目录(business service directory),其最基本的形式可能是设计时服务目录,用于在组织的整个开发活动中实现服务的重用。
Business Service Choreographer 的作用是通过若干业务服务来组合业务流程;因此,它将通过 ESB 调用服务,然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。 其在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。
The Role of the ESB in SOA
ESB服务
传输服务 必须确保通过企业总线互连的业务流程间的消息正确交付。传输还包括基于内容的路由功能。这意味着可以将消息定向到不同的目的地。作为任务关键型环境的一部分,这些服务采用事务处理方式,得到了相应的安全保证,并会对其进行监视。
事件服务 提供事件检测、触发和分发功能。这些功能与事件处理概念相关,事件处理是一种用于分析和控制事件驱动的体系结构 (EDA) 中相互关联事件组成的复杂系列。
中介服务 用于满足两个目的。首先,中介可确保提供必要协议,以满足集成异类系统的需求。由于两个不同的服务并不一定使用相同的传输协议,而中介服务可负责从一个协议到另一个协议的转换,因此可以进行此类通信。协议转换对于业务事务的所有参与服务是透明的。其次,中介提供了转换任何消息内容的可能性。这是业务集成的关键服务。它可确保任何进程都能理解通过总线传输的数据。
ESB服务
ESB Capabilities
ESB Capabilities
ESB 结构
ESB 有时被描述为分布式基础架构,这与其他的解决方案形成了对比,比如消息代理技术一般被描述为中心辐射型(hub-and-spoke)。然而,这并不是真正的差别。正在研究两个不同的问题:控制的集中和基础架构的分布。ESB 和中心辐射型(hub-and-spoke)解决方案都集中控制配置,比如服务交互的路由、服务命名等等。同样,这两个解决方案可能部署在简单的集中式基础架构中,也可能采用更复杂的分布式方式进行部署。
The Structure of ESB
The Structure of ESB
Centralization of control
Routing of service interactions
Naming of services
Service searching
Administration
Distribution of infrastructure
Client
Provider
Different locations
ESB Solution Patterns
Basic Adaptors
Service Gateway
Web services-compliant Broker
Enterprise Application Integration infrastructure for SOA (EAI Infrastructure for SOA)
Service Choreographer
Full Service-Oriented Architecture Infrastructure (Full SOA Infrastructure)
ESB Solution Patterns – Basic Adaptors
A simple point-to-point service integration using wrapper or adaptor technology rather than a true ESB
Enable integration through WSDL-defined SOAP access, or other interoperable technologies such as MQ
A native model for service interface definition, such as WSDL, a custom model will be needed to fulfill the principles of SOA
ESB Solution Patterns – Basic Adaptors
ESB Solution Patterns – Service Gateway
Often support client connectivity through SOAP/HTTP, MQ, JMS, and so forth
Support broader integration to service providers through the JCA or WebSphere Business Integration Adaptors
Act as a central control point
Service routing
Protocol transformation
security
ESB Solution Patterns – Service Gateway
ESB Solution Patterns – WS-Compliant Broker
Represent a sophisticated ESB implementation, providing all the capabilities of a full-fledged EAI solution using an open-standards model
The precise requirement of a specific situation defines
What level of EAI capability is required
Which EAI technologies are appropriate
ESB Solution Patterns – WS-Compliant Broker
ESB Solution Patterns – Service Choreographer
Consist of the implementation of a dedicated Service Choreography component
In some scenarios, such support might be sufficient to allow direct connectivity to service providers and service requestors
An ESB could be provided through any of the other solution patterns
ESB Solution Patterns – Service Choreographer
ESB的价值
基于标准的连接
作为很多异类应用程序间的集成中枢,ESB 必须提供很多不同的集成技术,并对大量供选择的标准技术加以利用。
消息传递集成通常支持 Java™ Message Service (JMS) API,而企业信息系统的连接则是由 J2EE Connector Architecture (JCA) 提供的。为了确保 Web 服务互操作性,ESB 支持 JAX-RPC 编程模型。不同的 ESB 组件间的集成可以通过 Java Business Integration (JBI) 规范进行标准化。
ESB的价值
渗透性集成
ESB 具有渗透性本质,因为它可以跨不同的部门、业务单元甚至业务合作伙伴进行应用程序集成。而且,它的核心体系结构原则还可以促进构建于异类开发环境上的应用程序之间的通信。例如,ESB 解决方案可以在不同的编程语言(J2EE、C++ 或 .Net)之间起到桥梁作用。
可靠集成
ESB 体系结构模式可提供系统安全性、可伸缩性或可用性。企业服务总线使用 SOA 和 EDA,可同时提供同步和异步功能。传输服务可确保可靠交付和事务完整性。因此,ESB 的每个特征都对其稳健性进行了增强,可尽可能减少集成或联合解决方案失败的风险。
部分ESB产品列表
IBM WebSphere ESB 提供了基于SCA的开发模式和完备的开发工具,并且提供了预先定义的元中介 (Mediation Bean)。这样用户通过工具WID (WebSphere Integration Developer),可以采用拖拽/配置的方式简单地开发中介信息流,实现ESB不再复杂
BEA AquaLogic Service Bus2.0 支持多种消息格式和传输协议,消除了消息之间的差距,发送方和接收方在不替换现有基础架构的 情况下,实现服务之间的快速集成和部署。可配置监控能力提供服务交互标准、消息跟踪事件和消息记录,并根据可配置的SLA设置界限和警告(不需要购买和集 成其他管理产品),支持有效的日常SOA运行,有在线建模能力。 
东方通 TongIntegrator3.0 有一个内在的伸缩性设计,保证了在系统规模扩大的情况下,不牺牲效率。这保证了能够迅速和容 易地连接新系统而不影响吞吐量。每个TongIntegrator的适配器都通过一个简单的配置文件来定义。提供了一套标准组件,构建一个适配器,甚至可以不用写任何程序代码。 

Enterprise Service Bus
WebSphere Message Broker  -- Today
WebSphere Message Broker  -- What’s Coming!
SCA (Service Component Architecture)概念
  SCA(Service Component Architecture)是一个基于SOA而实现的新技术,主要是用来简化应用程序的开发。使用SCA,客户能够更容易的创建新的服务或者是转换已存在的服务,以达到服务重用的目的。这样可以更加快速的适应业务需求快速变化。SCA技术极大的减少了与应用程序编程语言相关联而造成的复杂性,提供了一个良好的方法来统一这些服务,而不用关心使用的编程语言以及运行的平台的不同。SCA提供了一个与技术无关的方式定义接口、实现和引用的模型。

SCA的起源
基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法,但是往往对于不同语言我们有不同的组件模型,从而需要不同的调用方式。比如在J2EE技术领域,我们就有EJB,POJO,JDBC,JMS等,这对于开发人员来说是一个极大的挑战。为了给这些不同的接口提供一个统一的调用方式,IBM提出了WSIF (Web Service Invocation Framework,并将它贡献给Apache组织。
WSIF作为Web Service领域的一个规范,提供了一种基于Java API统一调用各种服务的能力。但是WSIF没有形成一个基于组件的架构模型,因此IBM在此基础上推出了一个面向服务的组件模型(Service Oritented Architecture, SCA)。这个模型不但解决了统一调用的问题,还提出了一个基于组件的构建模型,并提供了许多面向企业计算的QoS能力。因此,从技术的角度来说,SCA是WSIF的延续和扩展。
SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次,而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构,能够很好的分离应用的业务逻辑和IT逻辑,不但易于应用的构建,也易于应用的更改和部署。
SDO
Service Data Objects(SDO)被设计来简化与统一应用程序处理数据的方式。使用SDO,应用程序的编程人员能够以一种一致的方式访问和操作从异构数据源中获取的数据,如下图所示,这些数据源包括关系数据库,XML数据源,Web服务和企业信息系统(EIS)。
SCA/SDO技术规范作用
SCA就是在现有技术基础上,为SOA计算环境(松耦合计算环境)提供开放的组件及其服务描述。另一方面,它规定已经设计好的组件之间交互,以便组装服务来构造应用。
SDO则包含了连接器、协调器、对象图表、各种数据对象之间的联系信息以及这些联系信息中的描述方式。
SCA/SDO所构成的编程模型可以为程序员带来很多非常直接的好处,而且用它们来描述和实现业务模型,将会达到一种相比原有J2EE平台或者.NET平台更加简洁和通用的效果。
在面向服务的环境中,新编程模型最主要的特点就是从业务的需求出发,将一组松耦合的服务组合成业务流程,完成所需要的业务活动。但这种松耦合的服务组装是建立在开放的服务组件及其动态交互的基础之上的,因此,SCA定义能让整个业务架构有更大的灵活度,你还可以选择不同的方式来实现这些业务组件。
SCA/SDO规范对SOA的重要意义
计算环境维度,编程模型是整个计算环境非常重要的组成部分;
软件工程维度,用怎样的方法来标识这些服务,怎样描述它的接口、消息等细节;
设计原则维度,根据你采用的编程思想来设计软件结构和设计风格;
具体实现维度,怎样用你已经搭建起来的软件在SOA的计算环境下跑起来。
    这两个规范是IBM联合BEA、Oracle、IONA、SAP、Siebel、Sybase、Xcalia以及Zend公司IT技术主流的技术厂商支持共同发布的。它的建立为SOA计算环境下的编程模型打下了一个坚实的基础。
SCA module
SCA中的基本概念——服务组件

服务组件模型(SCA)中提出了一些新的概念,比如服务组件,模块,共享库,导入和导出等。下面将分别解释这些服务组件中的基本概念。

服务组件是SCA中的基本组成元素和基本构建单位,也是我们具体实现业务逻辑的地方。可以把它看成是构建应用的积木。可以容易地把传统的POJO,无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL(Web Service Description Language)的,另外为了给Java编程人员提供一个直接的接口,SCA的部分服务组件也提供了Java接口。因此,使用服务组件的客户端可以选择使用WSDL接口或Java接口。
SCA中的基本概念——服务组件
服务组件提供给别的服务调用的入口叫Interface(接口)。而服务组件本身可能也需要调用别的服务,这个调用出口叫Reference(引用)。无论是接口还是引用,其调用规范都是WSDL或Java接口。SCA服务组件的接口模型请参考图

WebSphere Process Server V6.0.1的架构环境
WebSphere Process Server 充分利用了SCA的这种组件架构,并在产品中提供了一些与业务联系比较紧密的组件,比如业务流程,人工任务,业务状态机,业务规则等。这样用户就可以直接利用这些服务组件,构建自己的业务流程或其它业务集成的应用。在WPSV6.0.1中,服务组件及SCA在架构中的作用如图
SCA服务组件与传统组件的区别

1. 服务组件往往是粗粒度的,而传统组件以细粒度居多。
2. 服务组件的接口是标准的,主要是WSDL接口,而传统组件常以具体API形式出现。
3. 服务组件的实现与语言是无关的,而传统组件常绑定某种特定的语言。
4. 服务组件可以通过组件容器提供QoS的服务,而传统组件完全由程序代码直接控制。
SCA中的基本概念——服务模块(Module)
服务模块(简称模块)由一个或多个具有内在业务联系的服务组件构成。把多少服务组件放在一个模块中,或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位,因为一个SCA模块背后对应的是一个J2EE的企业应用项目。
IBM在开发工具WID(WebSphere Integration Developer V6.0)中,通过业务集成透视图看到都是SCA级别的元素。但是当你切换到J2EE透视图你就会发现这些SCA元素与实际J2EE元素之间的对应关系。因此,在WID中构建一个模块就相当于构建一个项目。另外,由于模块是一个独立部署的单元,这给应用的部署带来很大的灵活性。
由于一个模块中往往会包含多个服务组件,在WID工具中,只要简单地通过接口与引用之间的连线,就可以指定它们之间的调用关系而不需要写一行代码。可以在这些连线上面设定需要的QoS要求,比如事务,安全等。
SCA中的基本概念——导入(Import)和导出(Export)
在模块中引入了两个特殊的"端点",一个是导入(Import),它的作用是使得模块中的服务组件可以调用模块外部的服务。另一个是导出(Export),它的作用是使得模块外部的应用可以调用模块中的服务组件。
由于涉及到模块内外的调用,因此需要指定专门的绑定信息。这些绑定信息包括了目标服务或源服务的调用方式,位置信息,调用的方法等。
目前,在WPS V6.0中,导入端点提供了四种绑定方式,包括:JMS绑定,Web Service绑定,SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式,包括:JMS绑定,Web Service绑定和SCA绑定。
Import
export
Refenence binding
SCA中的基本概念——共享库(Library)

当我们在构建了多个模块的时候,如果有一些资源可以在不同模块之间共享,那么我们可以选择创建一份可以在不同模块之间进行共享的资源,而不是在不同模块中重复创建。共享库就是存放这些共享资源的地方。
共享库可以通过与模块类似的方式在WID中创建,但是共享库包含的内容只有:数据定义,接口定义,数据映射和关系。与模块最大的区别使共享库不包含服务组件,因此也就不包含业务逻辑。
从包含的功能来看,我们可以把共享库看作是模块的一个子集。当一个模块需要用到共享库中的资源的时候,我们只需要使模块依赖于共享库即可。从部署的角度,一个共享库会对应一个JAR包。在部署的时候,模块所对应的J2EE企业应用会会自动包含所依赖的共享库JAR包。这里特别要注意的是,这里的共享库概念与WebSphere应用服务器中的共享库不是一个概念,它们之间没有任何联系。
Shared Lib: create
Shared lib:usage
服务模块总览图 Standalone Reference
模块中的服务组件是不能直接被外部Java代码使用的,为了外部的Java代码,比如JSP/Servlet使用模块中的服务组件,WID工具在模块中提供了一个特殊的端点,叫做Standalone Reference。这个端点只有引用(Reference),而没有接口(Interface)。只要把这个端点的引用连接到需要调用的服务组件的接口,外部的Java代码通过这个引用的名称来调用相应的服务组件了。

Standalone reference
SCA同步调用和异步调用
常见的方法调用都是同步调用,这种调用方式是一种阻塞式的调用方式,即客户端(主调用方)代码一直阻塞等待直到被服务端(被调用方)返回为止。这种调用方式相对比较直观,也是大部分编程语言直接支持的一种调用方式。但是,如果我们面对是基于粗粒度的服务组件,面对的是一些需要比较长时间才能有响应的应用场景,那么我们就需要一种非阻塞式调用方式,即异步调用方式。
SCA编程模式提供了三种方式的异步调用,它们分别是:
     1. 单向调用方式。
     2. 延迟响应方式。
     3. 请求回调方式。
Interface of SCA
Interface and implement
SCA components
SCA技术小结

SCA不但解决了统一调用的问题,而且提供了一个服务组件架构。这个服务组件架构将在构建面向服务的架构中起到举足轻重的作用,并在很多公司的产品中会有所体现。
SCA得到了业界几个主要软件厂商的支持。IBM、Oracle、BEA、SAP、Siebel、Sybase、IONA等厂商联合发布了SCA规范的0.9版本。
具体规范可参见IBM DW的网址:http://www.ibm.com/developerworks/library/specification/ws-sca/
BO/SDO
目      录


基础架构平台产品选型分析

基础中间件平台厂商产品对比
基础中间件平台厂商产品对比
基础中间件平台厂商产品对比
市场说话

 
  下载地址
  点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载  
点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载
·上一课件:软件质量与项目管理
·下一课件:IT规划与信息化流程优化
  课件评论
 

评论内容只代表网友观点,与本站立场无关!

   评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
 
  下载说明
  * 为了达到最快的下载速度,推荐使用网际快车迅雷下载本站软件。
* 请一定升级到最新版WinRAR3.80才能正常解压本站提供的软件!
* 如果您发现下载链接错误,请点击报告错误谢谢!
* 站内提供的所有软件包含破解及注册码均是由网上搜集,若侵犯了你的版权利益,敬请来信通知我们!
 
 
  本类热门下载
 
  • 1Authorware课件下载
  • 2Photoshop课件下载
  • 3第6章 用Director MX 11.0制作 演示多
  • 4Flash 8.0课件下载
  • 5第4章 用Authorware 7制作交互式多媒体
  • 6Flash 8.0ppt课件下载
  • 7网站建设流程.ppt
  • 8网络的利弊
  •  
      相关下载
     
  • 企业级软件架构技术_SOA引论
  •  
      下载栏目导航
     
  • 语文
  • 数学
  • 英语
  • 物理
  • 化学
  • 政治
  • 生物
  • 地理
  • 音乐
  • 美术
  • 历史
  • 计算机
  • 课件素材
  • 其他课件
  • 考试题库
  •  

    Copyright © 2005-2010 Goodppt.Com. All Rights Reserved .
    站长QQ:65036487 豫ICP备05024667号