精华内容
下载资源
问答
  • 微信企业号加密机制

    千次阅读 2017-07-31 22:46:04
    在实现企业号和企业应用实现消息互发之前,企业号会要求我们填写相应的URL,Token,EncodingAESKey三个参数。URL很好理解就是接收方的地址。EncodingAESKey用于消息的加密,就是秘钥。Token任意填写,用于生成签名。...

    AES加密算法是目前主流的一种加密算法,先通过一张图片来说明一下原理:
    这里写图片描述
    可以看到这个加密的外层原理比较简单。(底层还是比较复杂的),可以看到秘钥只有发送方和接收方知道。在不知道秘钥的情况下,任何人都不能解密,所以使用aes加密是一种非常好的数据传输方式。那么问题来了接收方如何知道秘钥。
    之前了解过微信企业号是使用aes加密算法进行数据传输的,那么也必然涉及到秘钥传输问题。接下来用微信企业号是如何进行数据安全转发的来说明一下aes加密算法的使用。简单说一下微信企业号,如下图:
    这里写图片描述
    我们讨论的是微信企业号和企业应用之间的数据传输,而不是微信用户和微信企业号之前的传输。不得不说腾讯在这一方面还是比较慎重的,在新版本的企业号中不仅要求配置的企业号链接要是https的,而且数据还使用了aes进行加密。
    在实现企业号和企业应用实现消息互发之前,企业号会要求我们填写相应的URL,Token,EncodingAESKey三个参数。URL很好理解就是接收方的地址。EncodingAESKey用于消息的加密,就是秘钥。Token任意填写,用于生成签名。如下:
    这里写图片描述
    这里有一个问题,既然已经有EncodingAESKey用于消息体的加密,为什么还需要token。这是因为它可以让公众账号服务器确认请求是来自微信后台还是恶意的第三方。
    验证原理:
    微信后台在向公众账号服务器发送数据的时候,会额外带上4个参数:timestamp、signature、nonce、echostr。其中timestamp是时间戳,nonce是一个随机数,signature是对timestamp、nonce和Token进行SHA1加密后的字符串。SHA1的加密过程是不可逆的,即不能通过timestamp、signature和nonce计算出Token是什么。在服务器端收到这4个字符串,先利用本地的token和imestamp、nonce进行SHA1加密,加密之后得到的结果与signature进行比较,如果正确就说明发送方不是恶意的第三方。所以这个token仅仅是用于验证数据来源是否是善意的。(这里简单说一下SHA1和md5的异同点,首先它们都是不可逆的散列算法,然后SHA1的强度更好,也就是更难暴力破解)
    当确定消息来源合法之后,消息得以正常传输。AES秘钥就用在消息体的加密上,所以AES秘钥也是企业应用和微信企业号共同知道的。而在我们的应用端,向企业号发送信息时,也是需要进行aes加密的,不然在企业号一端不会按照我们的要求将信息转发给微信用户。这里我们直接使用开源的aes加密解密的java架包即可。到此为止微信企业号消息转发的问题就解决了,其实微信企业号比较有趣的是如何实现带权限的访问企业应用。这里都是一些很好的设计思想,暂时到这,下次再写。

    展开全文
  • DevOps企业实践指南(8): 安全机制

    千次阅读 2017-08-28 19:37:57
    通过了解卡巴斯基实验室对于安全性相关的调查状况的解读,了解到了目前企业安全状况不容忽视的现状。同时阐述了随着DevOps持续集成和持续部署的加快,安全机制如何才能保证跟上快速的节奏,应该从那些角度着手,有...

    DevOps落地实践中,安全机制应该如何保证,这篇文章从当前安全状况调查解读开始,同时介绍了DevOps落地实践时应该遵循的原则。

    安全问题现状

    Kaspersky Lab对26个国家超过5500公司进行了安全相关的调查,结果发现,安全风险无处不在,付出成本相当昂贵。

    这里写图片描述

    项番 调查结果
    1 90%的业务曾发生过安全事故,而且,高达46%的业务由于内部或者外部的安全问题丢失过敏感的数据
    2 大型企业平均每个安全漏洞要付出551,000$的直接成本,而对于中小型企业这个数字是38,000$
    3 大型企业平均每个安全漏洞要付出额外的69,000$ 的间接成本, 而对于中小型企业这个数字是8,000$

    安全漏洞影响

    这里写图片描述
    风险无处不在,漏洞影响巨大,主要的三种影响为:

    项番 影响
    1 对公司信用的影响
    2 安全漏洞产生的额外的人员以及培训的费用
    3 关键业务不能服务或者错误服务导致的额外保险等费用

    安全漏洞类型

    这里写图片描述
    安全漏洞很多,在这其中,企业付出代价最大的三种类型分别是:

    项番 漏洞类型
    1 可以被木马等方式利用进行网络关键信息获取的漏洞
    2 整合第三方业务服务引入的安全漏洞
    3 网络设定相关或者容易被黑客进行攻击的安全漏洞

    数据丢失的威胁来源

    在一个数据变得越来越敏感和重要的年代,可能带来数据丢失的安全漏洞更加引起着广泛地关注。在这其中,以下三类严重威胁着企业的数据安全。

    项番 数据丢失的安全威胁
    1 恶意软件
    2 钓鱼式攻击
    3 内部员工导致的敏感数据泄露

    DevOps实践中容易忽视的一环

    安全,在DevOps实践中是非常容易被忽视的一环。所有人都认为安全非常重要,但是安全控制从那些角度着手,有哪些原则需要遵守,随着DevOps持续集成和持续部署的加快,安全机制如何才能保证跟上快速的节奏,这些都是我们在落地DevOps实践中需要考虑的问题。

    安全实践原则

    安全生产,重于泰山。落地实践,重在细节。如何落地,如下整理一些实际落地的实践原则:

    原则一:以终为始,分析被攻击的价值所在

    站在攻击者的角度,设身处地,将心比心,看看为什么会被攻击,然后便可以制定对应的应对措施了。

    项番 价值分析自测问题
    1 通过你的系统是否有可能接触到大量的用户私密数据,而这些数据在现在的时代具有重要的价值?
    2 通过你的系统是否能够接触到很多用户名/密码,这些具有不同权限的用户名和密码是否能给攻击者带来很多价值,比如身份盗用?
    3 通过你的系统是否能接触到用户的信用卡号码和账单地址等?
    4 通过你的系统是否能接触到用户行为习惯这些隐私性的数据,而这些数据能够使得算法更加聪明?
    5 通过你的系统是否能够接触到进行转账相关的关键性数据?
    6

    原则二:以客户为中心的安全策略

    安全策略的创建,一般方式有如下两种:

    项番 角度 安全策略
    1 安全专家 保护企业资产的安全角度的防护策略
    2 业务专家 满足客户的需求以增加收入的安全策略

    由于安全专家与业务专家着眼点的不同,会导致在决策上产生很大分歧和摩擦。安全专家着重在防守,但是当安全方案在支持DevOps的快速响应客户需求,推动敏捷实践和持续创新落地方面则会显得步履蹒跚。而仅着眼于价值的业务专家往往对一些安全必须要注意的事项会选择性的无视。
    而秉持以客户为中心的理念,使得安全和价值两者在实现时需要进行权衡和调整,安全专家采取一些不至于过于笨重的策略,保证安全的同时同时保障业务创新的敏捷性需求。

    原则三:安全策略的左移

    传统的方式下,开发团队/运维团队/安全团队各司其职,保证整个IT业务的整体实现:

    部门 职责
    开发团队 应用软件的开发和价值的交付
    运维团队 保证服务的可用性和连续性
    安全团队 负责安全保障

    在这种构成之下,开发/运维/安全部门各有各自的KPI,职能相互独立,目标不同甚至产生对立和冲突,而且往往在交付到生产环境之前才会确认安全相关的确认,而安全事件的对应越晚付出的成本越高。根据研究,产品上线或者在运维阶段解决安全问题的成本往往远高于设计阶段:

    阶段 修复安全问题的成本
    产品发布以后 是设计阶段解决成本的4到5倍
    运维阶段 达到甚至超出设计阶段解决成本的100倍

    DevOps实践之中,尽早融入需要确认的安全性因素到各个阶段:

    阶段 安全策略
    需求阶段 客户合规性安全需求
    开发阶段 代码静态分析,脆弱性检测
    测试阶段 安全相关的测试内容
    运维阶段 合规性和安全相关的监控

    这样,尽可能早地引入了安全相关的机制,保证了安全保障的确认不会拖慢DevOps实践的节奏。

    原则四:安全策略与工具的融合

    在原则三中,我们意识到了安全策略要提前融入,工具在这其中也扮演着一个重要的角色。工具的自动化保障了安全在DevOps落地实践的顺畅执行。比如可以在如下阶段使用如下工具:

    阶段 安全策略 工具融合
    需求阶段 客户合规性安全需求 Anchore
    开发阶段 代码静态分析,脆弱性检测 Sonarqube/Findbugs/Fortify
    测试阶段 安全相关的测试内容 Robot/Selenium/UFT
    运维阶段 合规性和安全相关的监控 Clamvn/Anchore/Clair

    工欲善其事,必先利器。融合开发/运维/安全是一个非常繁重的工作,引入合适的工具能够做到事半功倍,使得开发/运维/安全的融合更加顺畅。

    原则五:持续评估CI/CD的安全状况

    持续集成和持续部署加快了交付的速度,但是自动化机制处理的不得当可能会带来很多安全上的隐患,所以评估CI/CD的安全状况以便持续改进非常重要。这里整理了一些常见的问题以便能够帮助进行自测和评估。

    项番 安全评估自测问题
    1 开发者能够看到其他项目的敏感信息么?
    2 扩展问题1,各种用户的权限是否清晰,是否存在越权的风险?
    3 密码的信息是否是用明文的形式进行存储?
    4 匿名用户时候会取得过于宽松的权限比如可以执行所有项目的脚本?
    5 构建的机制是否容易或者可能被攻击?
    6 开发者是否可能轻易地删除其他项目的一些信息?
    7 是否使用了一些其他的不安全的服务或者机制进行CI/CD?
    8 是否存在上传脚本等自定义机制引入不安全的因素?
    9 安全相关的基线管理是否融入和CI/CD之中?

    原则六:创建适合DevOps的安全标准

    安全不是为了做出一个不明觉厉的复杂安全报表让人不知所措,安全报告是为了进行决策而产生的,而产生安全报告的安全标准更应该考虑到这样。我们在原则三中提出了安全应该融入软件生命期的各个阶段,所以针对不同的阶段和不同的角色,安全标准的侧重点应该有所不同。

    阶段 安全策略 安全标准侧重点
    需求阶段 客户合规性安全需求 侧重于整体性的业务资源相关以及企业资产安全相关的内容
    开发阶段 代码静态分析,脆弱性检测 代码的漏洞或者缺陷
    测试阶段 安全相关的测试内容 系统功能性的正确性和安全相关的测试内容
    运维阶段 合规性和安全相关的监控 基础设施和配置方面存在的缺陷和漏洞

    原则七:主动监控而不是被动应对

    如果先于攻击者发现安全漏洞并将其修复,而不是在遭受到攻击之后被动的应对,损失则能免掉很多。主动监控安全问题,尽可能早地的发现可能会被攻击者或者对手利用的缺陷,则能带来极大的好处。
    所以强化以上各个原则,达成融合安全和自动化于DevOps实践之中,在持续集成和持续部署中尽早地发现可能存在的隐患,主动监控,快速反馈,主动应对,对企业会很有帮助。

    原则八:自我攻击和验证

    依据DevOps环境一致性原则,Staging环境尽可能地与生产环境类似,可以在Staging环境中验证可能的各种攻击,先于可能的攻击者对自己的系统进行攻击和验证,以激进地发现可能的问题,降低了大部分潜在可能的简单外部攻击带来的影响。

    原则九:安全的持续评估&安全规则固化

    安全的对应是一个长期的过程,是企业在持续学习中应该不断保持的状态,同时更应该不断提升安全的等级以保证业务的连续性。通过不断的对安全进行评估,确定出需要强化的安全事项,不断将这些事项固化成最佳实践,然后标准化,最后自动化到整体的流程之中,以保证安全机制的整体不断增强和持续改进。

    总结

    安全是一个被所有人口头上非常重视,但是往往在实际的实践中选择性无视的一个话题。通过了解卡巴斯基实验室对于安全性相关的调查状况的解读,了解到了目前企业安全状况不容忽视的现状。同时阐述了随着DevOps持续集成和持续部署的加快,安全机制如何才能保证跟上快速的节奏,应该从那些角度着手,有哪些原则需要遵守,细节上如何落地的方式。

    展开全文
  • ESB 企业服务总线基本内容概述

    千次阅读 热门讨论 2016-10-09 15:26:18
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。整个架构体系里面分为三个组件或子系统,...

    ESB全称为Enterprise Service Bus,即企业服务总线。

    它是传统中间件技术与XML、Web服务等技术结合的产物。

    ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。

    这里写图片描述

    整个架构体系里面分为三个组件或子系统,即偏开发态的设计器,偏运行态的ESB核心引擎和SOA治理管控平台三个方面的内容。以上三者组合和集成形成一款完整的ESB服务总线产品。对于三者之间的关系可以简单的描述为:

    首先对于ESB总线引擎是一个完全相对独立的内容,即常说的ESB的Server端,一个完整的ESB引擎一般都会集成消息中间件的能力。类似ServiceMix的ESB可以看到核心是基于OSGI运行框架下的ActiveMQ+CXF组件来实现基础核心功能。没有设计器和管控平台,引擎也可以独立部署和运行,即可以自己写代码或写配置文件,将开发好的服务包部署到ESB引擎环境里面。

    其次是ESB设计器,设计器是属于开发和设计态的一个内容,重点则是对http,rest,已经服务+DB,消息等各种内容进行集成。

    最后一个内容是SOA管控平台,主要的作用是实现服务的全生命周期管理,包括服务的元数据管理,服务目录库,服务的申请,服务的开通和鉴权,服务运行日志审计和监控,服务运行分析,服务预警,服务SLA等各种功能。即SOA管控平台提升了对ESB引擎本身的管控和治理能力。

    一、ESB的五个基本功能:

      
    1)服务的MetaData管理:在总线范畴内对服务的注册命名及寻址进行管理。
     
    2)传输服务:确保通过企业总线互连的业务流程间的消息的正确交付,还包括基于内容的路由功能。   

    3)中介:提供位置透明的路由和定位服务;提供多种消息传递形式;支持广泛使用的传输协议。   

    4)多服务集成方式: 如JCA,Web服务,Messaging ,Adaptor等.   

    5)服务和事件管理支持: 调用服务的记录、测量和监控数据;提供事件检测、触发和分布功能。

    二、ESB的八个扩展功能:

     
    1) 面向服务的元数据管理: 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求,以及服务的提供者和他所提供的服务的描述;   

    2) Mediation :它必须具有某种机制能够完成中介的作用,如协议转换;   
    3) 通信:服务发布、订阅,响应 请求,同步异步消息,路由和寻址等;   

    4) 集成: 遗留系统适配器,服务编排和映射,协议转换,数据变换,企业应用集成中间件的连续等。   

    5) 服务交互: 服务接口定义,服务实现的置换,服务消息模型,服务目录和发现等。   

    6) 服务安全: 认证和授权、不可否认和机密性、安全标准的支持等;   

    7) 服务质量: 事务,服务的可交付性等;   

    8) 服务等级: 性能、可用性等。 ESB 中最常提到的两个功能是消息转换和消息路由。

    三、ESB的出现改变了传统的软件架构

    ESB 是传统中间件技术与XML、Web服务等技术相互结合的产物,ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。
    

    四、企业服务总线(ESB)的用处

    ESB 不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法。
    

    五、企业服务总线(ESB)的应用特征

    大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构(SOA)是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来,只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务,那么其他应用系统就可以很方便的使用这些功能服务。 
      
     支撑SOA的关键是其消息传递架构-企业服务总线(ESB)。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物,用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务协调运作,实现不同服务之间的通信与整合。
    
    展开全文
  • ESB-企业服务总线

    万次阅读 2017-05-18 13:53:08
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以...

    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    ESB的基本概念

    企业服务总线(EnterpriseServiceBus,ESB)从面向服务体系架构(Service-OrientedArchitecture,SOA)发展而来,是传统中间件技术与XML、Web服务等技术结合的产物。
    ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构,以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通,是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于:
    ①面向服务的架构—分布式的应用由可重用的服务组成;
    ②面向消息的架构—应用之间通过ESB发送和接受消息;
    ③事件驱动的架构—应用之间异步地产生和接收消息。
    ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为低廉的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    基本功能

    1)服务的MetaData管理:在总线范畴内对服务的注册命名及寻址进行管理。
    2)传输服务:确保通过企业总线互连的业务流程间的消息的正确交付,还包括基于内容的路由功能。
    3)中介:提供位置透明的路由和定位服务;提供多种消息传递形式;支持广泛使用的传输协议
    4)多服务集成方式: 如JCA,Web服务,Messaging ,Adapter等。
    5)服务和事件管理支持: 调用服务的记录、测量和监控数据;提供事件检测、触发和分布功能;

    扩展功能

    1) 面向服务的元数据管理: 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求,以及服务的提供者和他所提供的服务的描述;
    2) Mediation :它必须具有某种机制能够完成中介的作用,如协议转换;
    3) 通信:服务的发布/订阅、响应/请求、同步/异步消息、路由和寻址等;
    4) 集成: 遗留系统适配器,服务编排和映射,协议转换,数据变换,企业应用集成中间件的连续等。
    5) 服务交互: 服务接口定义,服务实现的置换,服务消息模型,服务目录和发现等。
    6) 服务安全: 认证和授权、不可否认和机密性、安全标准的支持等;
    7) 服务质量: 事务,服务的可交付性等;
    8) 服务等级: 性能、可用性等。
    ESB 中最常提到的两个功能是消息转换和消息路由。

    ESB架构

    ESB 是传统中间件技术与XML、Web服务等技术相互结合的产物,ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    ESB的发展

    在云计算应用时代,ESB将逐步发展到EBB(Enterprise Business Bus, 企业业务总线),国际范围内EBB尚处于发展初期,当然许多人也将ESB在业务上的应用,未作区分对待而统一作为ESB看待。事实上,ESB更关注IT服务,而EBB更关注业务执行,具有不同的属性。
    国内在2008年就有人就EBB的发展做了专题研究,并就潍柴动力与湘火炬汽车集团结成战略联盟后形成的集齿轮箱、变速器、发动机和整车为一体的汽车产业链实例,使用面向服务的架构SOA和企业协同理念,给出了协同服务平台的设计与分析。
    目前国内在EBB领域研究较为超前的,是由中国最年青博士后导师之一、协达软件创先人付勇,所指导的协同软件博士后工作站。该团队所研究的成果,已经在产业应用上有良好表现,并广泛应用在办公自动化OA、企业资源计划ERP、制造执行系统MES、客户关系管理CRM等领域。

    应用特征

    大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构(SOA)是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来,只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务,那么其他应用系统就可以很方便的使用这些功能服务。
    支撑SOA的关键是其消息传递架构-企业服务总线(ESB)。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物,用于实现企业应用不同消息和信息的准确、高效和安全传递。让不同的应用服务协调运作,实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途:
    电信领域:ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。
    电力领域:ESB能够在全方位支持电力行业EMS的数据整合概念,是理想的SCADA系统数据交换平台
    金融领域:ESB能够在全方位支持银企间业务处理平台的流程整合概念,是理想的B2B交易支撑平台。
    电子政务:ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。

    主要结构

    ESB提供了一种开放的、基于标准的消息机制,通过简单的标准适配器和接口,来完成粗粒度应用(服务)和其他组件之间的互操作,能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。
    通过使用ESB,可以在几乎不更改代码的情况下,以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口,并能够在部署环境中支持任何标准。更重要的是,充当“缓冲器”的ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑相分离,从而使得不同的应用程序可以同时使用同一服务,用不着在应用程序或者数据发生变化时,改动服务代码。

    7.1 Smart Service Bus

    Smart Enterprise Service Bus™是神州数码秉承SOA理念,结合十数年企业应用集成领域的最佳实践,研发的一套功能完善、高效稳定、灵巧开放的企业服务总线中间件。作为核心的交换平台,能保证7*24小时永不间断提供服务。提供最优的扩容方式,保证扩展线性度达到100%,为组织提供高吞吐量的优质基础服务。提供灵活的部署方式,支持集中部署、分布式部署及总分结构部署。最佳的IT架构治理平台,提供基于元数据的服务治理工具和系统监控工具套件。

    7.2 Oracle Service Bus

    Service Bus的前身是BEA的AquaLogic Service Bus,BEA AquaLogic产品家族交付了最全面的服务基础架构产品线,可以帮助企业成功部署SOA。作为首款完全针对SOA而构建的产品套件,它为IT提供了一组统一的产品来处理消息传递、服务管理、数据一致和安全需要。
    Oracle Service Bus为IT提供了一个理想的SOA基础,可以实现下列业务目标:
    通过动态配置异构共享服务之间的集成来节省时间。
    通过简单的集中式服务注册来减少维护工作。
    通过经济有效的服务部署和自动配置来降低成本。
    通过确保服务交互的正常进行和可用性来增加正常运行时间。
    通过使用服务元数据来简化共享服务的配置、集成和管理。
    提供支持基于SOA的业务解决方案所需的企业级可靠性和性能。[1] 

    7.3 IBM WebSphere ESB

    IBM 提供了三种 ESB 产品:IBM WebSphere ESB、IBM WebSphere Message Broker、IBM WebSphere DataPower Integration Appliance XI50。根据您的需求选择 ESB 来增强您的 SOA。WebSphere ESB 是一种基于平台的 ESB,作为集成的 SOA 平台,针对 WebSphere应用服务器进行了优化。WebSphere Message Broker 是跨平台的 ESB,是为异构 IT 环境中的统一连接和转换而构建的。WebSphere DataPower Integration Appliance XI50 是一种基于设备的 ESB,是为简化的部署和更强的安全性而构建的。客户面临着从简单到复杂的各式各样的 ESB 需求。

    7.4 Microsoft ESB

    微软通过其应用平台提供了全面的ESB服务,包括:Windows Server®2003,.NET Framework, BizTalk®Server 2008 R2. 应用平台提供了一个基础架构,基于此可以灵活和安全地重复使用架构和商业服务,并具有协调原有的服务整合到新的端到端的业务流程中的能力。
    微软通过一些列的产品Windows Server 2003, the .NET Framework 3.0, and BizTalk Server 2006作为对企业实现ESB的支撑,Microsoft ESB Guidance是基于BizTalk Server 2006一组应用,它提供以下公用的ESB组件:l Message routing (消息路由) l Message validation (消息验证) l Message transformation (消息转换) l Centralized exception management(集中的异常管理) l Extensible adapter framework(可扩展的适配器框架) l Service orchestration(服务的编制支持) l Business rules engine(业务规则引擎) l Business activity monitoring(业务活动监视)微软 ESB 指南提供了架构指导,模式和实践,以及一套BizTalk Server 和 .NET Framework 组件来简化基于微软平台的大型或小规模的ESB解决方案的开发。它还可以帮助开发人员扩展现有的信息和集成解决方案,包括的一些服务和组件。

    7.5 JBOSS SOA Platform

    JBoss Enterprise SOA Platform提供了一个基于标准的平台,用以集成应用、SOA服务、业务事件和自动化业务流程。这一SOA平台集成了特定版本的JBoss ESB、jBPM、Drools、和已得到验证的JBoss企业应用平台,把它们组织在一起形成一个单一的企业级发布。JBoss Enterprise SOA Platform打包了不少流行组件如:
    l JBoss ESB l JBoss jBPM jPDL l JBoss Rules (Drools) l JBoss Application Server l Hibernate l Hibernate Entity Manager l Hibernate Annotations l JBoss Seam l JBoss Web (嵌入式Tomcat 6.0) l JBoss Cache l JGroups l JBoss Messaging l JBoss Transactions l JBoss Web Services (JBossWS) l JBossXB l JBoss AOP l JBoss Remoting l JBoss Serialization l JacORB

    7.6 ServiceMix对ESB的实现

    ServiceMix是一个建立在JBI (JSR 208)语法规则和APIs上的开源ESB(Enterprise Service Bus:企业服务总线)项目。ServiceMix是基于JBI的ESB。它是开源的基于JBI语义和API的ESB和SOA工具包,以Apache许可证方式发布。 它是轻量的ESB实现,易于作为嵌入式ESB使用;集成了对Spring技术的支持;可以在客户端或服务器端运行;可以作为独立的ESB提供者,也可以作为另外ESB的服务组件; 可以在JavaSE或JavaEE服务器中使用;ServiceMix同Apache Geronimo以及JBoss服务器完全集成,并且在Apache Geronimo服务器中可以直接部署JBI组件和服务。Java Business Integration (JBI,Java业务集成)技术规范定义了SOA的服务导向集成的内核和组成架构。它对公共讯息路径架构、服务引擎与捆绑的插件程序接口,以及复合型服务描述机制等都进行了标准化,这样就将多种服务结合成为一个单一的可执行的和可审核的工作单元。JBI和ServiceMix关系图JBI并不是一个为开发者设计的一个接口,更准确的说它是在JBI容器里为集成商提供相互集成的一个体系和一系列的接口。所以人们能集合他们所需要的所有部分,做出一个总体解决。例如在理论你能从BPEL引擎上,EJB容器上或者是数据传输产品上集合一个基础设施,并且能够集成的很合适。 ServiceMix 中包含完整的JBI容器,支持JBI规范的所有功能要求:l 规范化消息服务和路由 l JBI管理Beans (MBeans)l 组件管理和安装的Ant任务l 对JBI部署单元的完全支持,支持JBI组件的热部署

    7.7 NEC WebOTX ESB

    WebOTX Enterprise Service Bus(以下简称WebOTX ESB)是灵活地结合基于SOA 的系统上的业务应用的,具有消息交换功能的服务运行平台的中间件,是在WebOTX Application Server 的Java EE 环境上动作的ESB 运行环境。WebOTX ESB 处于处理层和服务层中间的Hub产品的位置,使业务变更时系统能灵活对应。
    WebOTX ESB 遵循JBI1.0(服务总线的Java 标准定义),提供标准的对应了各种协议的组件,能实现与业务应用的无缝连接。此外,提供了丰富的适配器群以致能与大型计算机上的业务应用、EAI 工具等连接。而且,提供了能吸收服务间消息差异的高速XML 变换引擎,使得不进行任何变更就能灵活地实现系统的构筑。

    7.8 RES Infomatic Service Bus

    RES Infomatic Service Bus是锐易特软件信息整合解决方案中最为核心的企业级信息服务总线产品。该产品理念与核心技术跟IBM、Oracle等国际主流厂商的ESB产品同步,自2004年至今,经过了为期两年的国外产品原型设计和四年的国内本土研发与多行业重量级客户实践检验。广泛应用于金融、电信、政府、公共卫生等行业。它是由七款子产品构成的产品家族,包含了Universal Adapters 通用适配器、Message Broker消息代理、Service Monitor服务监控中心、Service Proxy 服务代理、Registry and Repository 服务资源注册中心、Configuration Manager 配置管理中心、Integration Tools 整合开发工具集,这些子产品相互支撑、协同工作,共同构成分布式信息服务总线的开发、部署、运行、管理的SOA全生命周期支持。

    7.9 Mule ESB

    Mule ESB是一种基于java的、轻量级的企业服务总线和集成平台,它允许开发者快速的、简单的连接应用,并能够实现数据的转换。
    Mule ESB的主要功能如下:
    服务的创建与管理(Service creation and hosting):用Mule ESB作为一个轻量级的服务容器来暴露和管理可重用的服务。
     服务调解(Service mediation):隐藏服务消息的格式和协议,将业务逻辑从消息中独立出来,并可以实现本地独立的服务调用。
     消息路由(Message routing):基于内容和规则的消息路由、消息过滤、消息合并和消息的重新排序。
     数据转换(Data transformation):在不同的格式和传输协议中进行转换数据。

    ESB以太网插板:

    ESB26 与ESB24 板的不同主要是在插板上提供的以太网接口的数量不一样ESB26 提供26 个接口,ESB24 上有24 个;另外ESB26 板前面板上有六个以太网接口一个com 口,ESB24 板前面板上有四个以太网接口一个com 口;通常构成EMB 的ESB 板也属于SWU 单元,还有LANU 上的ESB 板也是SWU单元。

    Apache synapse ESB

    http://synapse.apache.org/

    Apache Synapse企业服务总线(ESB)

    Apache Synapse是一种轻量级的高性能企业服务总线(ESB)。 Apache Synapse由快速和异步的中介引擎提供支持,为XML,Web服务和REST提供了卓越的支持。 除了XML和SOAP之外,Apache Synapse还支持多种其他内容交换格式,例如纯文本,二进制,Hessian和JSON。 适用于Synapse的广泛的传输适配器使其能够通过许多应用和传输层协议进行通信。 到目前为止,Apache Synapse支持HTTP / S,邮件(POP3,IMAP,SMTP),JMS,TCP,UDP,VFS,SMS,XMPP和FIX。

    Apache Synapse是Apache Software License 2.0下分发的免费开源软件。 最新版本的Synaspe是v3.0.0  此版本带来了大量新功能,错误修复,性能和稳定性改进。

    Apache Synapse,Synapse,Apache,Apache羽毛徽标和Apache Synapse项目徽标是The Apache Software Foundation的商标

    版本3.0.0中的新功能

    • 高性能PassThrough HTTP传输支持所有调解方案
      • 超快速,低延迟的HTTP请求中介
      • 同时支持大量入站(客户端 - > ESB)和出站(ESB - >服务器)连接
      • 使用共享缓冲区来智能地处理内置在引擎中的消息内容和内容感知,以处理数据
      • 在存在慢或故障的客户端和服务器的情况下,自动节流和性能下降
    • HTTP传输的OCSP / CRL证书验证支持
    • 响应中介者 - 调解人从中介流程中的任何地方回复客户端
    • Loopback Mediator - 从IN序列跳转到OUT序列的中介者
    • 标题中介者改进
      • 支持添加/删除传输头
    • 新的xpath函数
      • url-encoded xpath函数
      • 从get-property函数访问系统属性
      • base64解码功能
    • 消息处理器改进
      • 重新排序消息处理器
      • 新的阻止客户端实现
    • 消息注入任务改进
      • 支持向代理服务注入消息
      • 支持向命名序列注入消息
    • 标注调解员改进
      • 支持WS-Security
      • 内联终端支持
      • 能够使用'To'头动态设置EPR
      • NTLM支持
    • 脚本中介者改进
      • 支持删除属性
    • REST API改进
      • 运输级别访问限制

    主要特征

    • 代理服务 - 促进传输,接口(WSDL / Schema / Policy),消息格式(SOAP 1.1 / 1.2,POX / REST,文本,二进制),QoS(WS-Addressing / WS-Security / WS-RM) MTOM / SWA)
    • 用于快速HTTP交互的非阻塞HTTP / S传输,并支持数千个并发连接
    • 用于文件操作和与FTP,SFTP,CIFS和WEBDAV交互的VFS传输
    • JMS支持二进制,纯文本,XML和SOAP有效载荷
    • 邮件传输,广泛支持POP3,IMAP和SMTP
    • 支持业界推动的财务信息交换(FIX)协议
    • 内置注册表/存储库,便于动态重新配置和关联资源(如XSLT,XSD,JS等)
    • 内置支持使用Quartz调度程序调度任务
    • 负载均衡(带或不带粘性会话)和故障切换路由
    • 支持许多Web服务标准,包括WS-Addressing,WS-Security和WS-Reliable Messaging
    • 基于策略的消息限制和缓存(特别支持集群环境)
    • 消息分割和聚合
    • 使用数据库连接池进行数据库查找和更新支持
    • 针对序列,端点和代理服务的细粒度统计信息收集
    • JMX监控管理
    • 可以使用Java,Spring或BSF脚本语言(Javascript,Ruby,Groovy等)轻松扩展

    高级架构

    Apache Synapse的设计是轻量级和快速的。 非阻塞HTTP传输,多线程中介引擎和流式XML信息集合结合起来,以确保Synapse可以以最小的延迟和资源使用通过服务总线调解非常大量的消息。 Synapse还具有全面的日志记录功能,统计信息收集和JMX监视支持,这在生产部署中至关重要。

    Synapse使用Apache Axis2作为底层Web服务引擎。 因此,它对Web服务和相关标准(如SOAP和WSDL)有突出的支持。 经过测试的Axis2模块,如Apache Rampart和Apache Sandesha2,可与Synapse一起使用,无需配置开销。 使用这样的外部模块,Apache Synapse支持一系列Web服务标准,包括WS-Security和WS-Reliable Messaging。 Synapse还利用Axis2集群框架提供企业级集群支持。

    Synapse使用简单的基于XML的配置语言进行配置。 配置语言和相关功能组件的设计考虑了SOA最佳实践。 将配置片段存储在外部SOA注册表中并将其按需导入到中介引擎是微不足道的。 Synapse提供了大量的调解器,可用于实现即使是最复杂的企业集成方案。 如果需要,可以通过使用Java或您最喜欢的脚本语言开发定制调解器来扩展中介引擎。


    开源ESB方案:http://www.oschina.net/project/tag/333/esb

    展开全文
  • ESB 企业服务总线

    万次阅读 2013-08-24 10:36:41
    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾为@肖俊_David 。 @肖俊_David 恒拓开源架构师,热衷于JAVA开发,有多年的企业级开发经验。曾参和设计和开发基于FuseESB 企业级服务总线系统,对...
  • 软件企业研发人员激励机制研究

    千次阅读 2015-04-02 14:32:11
    软件企业提高企业技术能力、增强竞争优势的一个关键环节是充分发挥研发人员的积极性和创造性。然而,许多软件企业往往缺乏对研发人员的有效激励,从而导致企业对研发人员的吸引力小,研发人员积极性低,最终造成人才...
  • 几种ESB(企业服务总线)介绍

    万次阅读 2018-07-16 19:24:45
    ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有...
  • 五大预测Web服务中的安全机制

    千次阅读 2004-10-09 16:16:00
    但是,对Web服务安全机制的担心使得多数企业对其持观望态度,不断推迟部署计划。用户们纷纷表示,要等到Web服务的安全标准充分成熟之后,再部署Web服务。所以,在更多的信任和安全问题悬而未决的时候,Web服务不会...
  • 微服务系统中的服务发现机制

    万次阅读 2016-07-13 00:05:31
    我们可以想象一下,当我们需要远程的访问REST API或者Thrift API时,我们必须得知道服务的网络地址(IP Address和port)。传统的应用程序都是运行在固定的物理机器上,IP Address和端口号都是相对固定的。可以通过...
  • 企业服务总线ESB是什么

    万次阅读 2018-01-17 18:25:14
    在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级...
  • 企业服务总线Enterprise service bus介绍

    千次阅读 2013-06-28 10:27:35
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • 企业服务总线ESB

    千次阅读 2017-02-23 13:30:54
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • 基于企业服务架构的新一代企业管理应用软件 --在2007年中国开发者精英论坛上的演讲IT168耿英英: 企业发展离不开信息化,而信息化的关键是企业管理的信息化,新一代的企业管理软件,使得现代的企业可以达到一个更高...
  • 摘要:文介绍了现代企业在信息化建设过程中遇到的交互和耦合问题,阐述了面向服务构建企业应用的解决方案——ESB企业服务总线,对该解决方案给出了详细的设计,并举出实现例子。 关键词:面向服务;企业解决方案;...
  • 前言 基于Docker的容器技术是在15年的时候...希望给在创业初期探索如何布局服务架构体系的DevOps,或者想初步了解企业级架构的同学们一些参考。(PS:本来想一口气写完,但发现一个模块就写了太久,后续会持续更新。
  • 服务间的IPC机制 按照微服务的架构体系,解决了服务发现的问题之后。就需要选择合适的服务间通信的机制。如果是在Springboot应用中,使用基于Http协议的REST API是一种同步的解决方案。而且Restful风格的API可以使...
  • 企业全方位改进(CMMI)咨询服务

    千次阅读 2016-04-20 14:33:48
    要达到这样的目标,需要全方位的、根本性的改进,打造良好的组织架构、人才招聘及培养体系、绩效考核机制、软件研发过程、高战斗力的团队,积累核心业务及技术等,让企业具备稳定的并可持续进步的核心竞争力,可持续...
  • 某工业企业公共服务平台架构设计

    千次阅读 2011-01-26 14:51:00
    最近参与到的一个大的工业企业系统的架构设计,思路整理的过程记录下来
  • 企业微信第三方服务商和钉钉ISV开发对比项目本来是基于企业微信开发(之前叫微信企业号,现在统一叫企业微信),做为第三方服务提供方。最近需要支持钉钉,也体验了一把钉钉ISV(独立服务开发商)开发,对比一下两者...
  • 企业架构-数据服务总线思路

    千次阅读 2020-04-20 15:14:51
    在常规的业务系统中数据通常是分散存储,数据源的位置从同一个系统的不同服务,到不同系统的不同服务,以及到跨企业服务。直接导致请求链路增加,业务复杂度提高,系统稳定性降低。同时数据源分散也导致用...
  • 五类安全服务包括认证(鉴别)服务、访问控制服务、数据保密性服务、数据完整性服务和抗否认性服务。 认证(鉴别)服务:在网络交互过程中,对收发双方的身份及数据来源进行验证。 访问控制服务:防止未授权用户...
  • 前三篇主要介绍了微服务的服务发现、服务通信以及API Gateway。整体的微服务架构的模型初见。在实际的开发、测试以及生产环境中。使用Docker实现微服务,集群的网络环境会更加复杂。微服务架构本身就意味着需要对...
  • 企业服务总线架构介绍

    千次阅读 2014-10-24 09:48:35
    产品架构        Sm@rtESB系统架构图 ... Sm@rtESB构筑在总线服务框架基础之上,按照SOA架构理念,规划设计为系列产品线,包括SmartESB运行平台、SmartMonitor监控平台、SmartGovernance服
  • 前面两篇Docker微服务的服务发现以及Docker微服务的服务间通信机制。主要介绍了如何解决微服务的服务发现和通信问题。 在微服务的架构体系中,为了减少服务间的耦合,在划分服务间的限界上下文的时候。会尽量减少...
  • 企业服务总线(ESB)技术与革新

    千次阅读 2004-08-19 16:17:00
    企业服务总线(ESB)技术与革新(用异步消息传递和智能路由选择扩展Web服务)作者:Nigel Thomas和Robrert Dalies由于更大任务所带来的要求,消息传递技术现在正处于发展之中。为了给当今的实时企业提供其所需的灵活...
  • 目前企业邮箱领域提供免费服务的并不多,Chiefmore君主要为大家推荐腾讯企业邮箱与阿里企业邮箱。 腾讯企业邮箱 :各项基础功能完善,能绑定微信和QQ账号;但是用户不能选择反垃圾模式,只能统一使用腾讯的自动...
  • 目前公司的svn代码服务器已经运行超过9年以上,服务器老化严重,且无任何备份机制,存在重大风险,且svn运行在xp系统上,运维管理不方便,为了保护公司重大资产,申请购买了一台新的Linux服务器,将svn代码从...
  • ActiveMQ消息存储机制

    千次阅读 2016-04-27 10:09:49
    activemq的消息存储机制 转载自:http://longdick.iteye.com/blog/444632 ctiveMQ是当下最流行和强大的开源企业消息集成组件。 ActiveMQ性能优良,支持多种跨语言的客户端和协议,支持JMS1.1和J2EE1.4,...
  • Android内存管理机制详解

    万次阅读 多人点赞 2012-12-13 10:37:33
     次要服务(secondary server) 目前正在运行的一些服务(主要服务,如拨号等,是不可能被进程管理终止的,故这里只谈次要服务),举例来说:谷歌企业套件,Gmail内部存储,联系人内部存储等。这部分服务虽然属于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 273,132
精华内容 109,252
关键字:

企业服务机制