今天继续整理下Oracle SOA 12c套件中,涉及到OSB服务总线部分的关键技术特性。在讲OSB部分关键技术特性前,先整理下SOA 12c的一些新特性说明。
对于Oracle SOA产品套件SOA 12c版本,是Oracle本身iPaaS云平台战略的核心组成部分。特别是12c版本扩展了云端集成, 移动应用集成和物联网IoT集成三方面的重要能力。
新发布的版本中包括简化和缩短新集成开发时间以及大幅提高响应速度的特性。开发人员现在可以利用端到端的 JSON 支持提高性能,并可在集成流程中直接使用 JavaScript。新的内存中特性极大改善了事务性能,新的 B2B 优化进一步提升了事务处理速度,便于合作伙伴协作。在流分析领域,Oracle Stream Explorer 提供了简化的业务友好的方法以及先进的机器学习能力。
为了可视化集成流程可以访问的分析,还向 Oracle SOA Suite 的 Business Activity Monitoring 功能添加了新的自定义功能,以便更好地协调分析和客户特定的关键绩效指标。该集成平台还引入了一些新特性,可以最大程度提高正常运行时间,诊断和调优集成环境,并使 SOA 部署能更好地应对异常和过载。
对于云,移动移动,IOT三方面的核心能力增强可以描述为:
Cloud Integration - Rapidly integrate a growing list of cloud applications with existing applications
Mobile Integration - Mobile enable enterprise applications and services
IoT Integration - Connect Internet of Things (IoT) devices to existing systems
今天不打算对以上内容做详细介绍,主要还是想从企业信息化内部服务总线平台和SOA架构体系搭建过程中,采用Oracle SOA 12c带来的新特性能力提升。
1. 扩展了多Http Rest API 接口,Json数据格式和Open API服务接入能力的恶支持。这个不仅仅是移动和IOT应用,在企业内部信息系统集成也可以采用,同时增加了Http Rest接口和传统SOAP WebService接口间的接口协议转化能力,XML和JSON数据格式的转化能力。
2. 整个开发环境仍然是基于Jdeveloper,但是整个声明书,向导式开发更加完善,在这块11g服务设计开发方法在大步骤上没有太大变化,存在的是一些细节上的易用性调整。
3. 在OSB设计上有一个重大的变化就是,组件中增加了资源类别包括了Pipeline和Spit-Join,对于这块的能力原来是集成在Proxy Service里面的,现在单独剥离出来可以复用。
3.提升CEP复杂事件处理可视化设计能力,消息处理,EDN事件网络的可视化设计能力明显增强。
4.服务复用能力提升:SOA最大的一个作用就是服务共享和服务复用,因此在12c里面可以看到对于OSB和BPEL都增加了复用重用方面的能力。对于OSB设计增加了服务模版和基于模块开始新设计的能力,对于BPEL则进一步增加和完善了可复用的SubProcess子流程的设计和定义。
5. 调试和测试能力的增强,可以灵活的设置断点对服务设计结果进行Debug,并实时观察每个节点输出。与JavaIDE中的调试器相同,SOA调试器提供了诸如stepping into,out,over等,同时提供了变量查看器,也能实时修改变量值。
6. 各种对商用软件的适配器能力的增强,如SAP R3,JDEwards,MSMQ,也包括云端SaaS应用的集成和适配,如Saleforce集成和适配等。
7. 数据映射和适配能力的增强,包括Xquery Mapper,XSLT Mapper等。
8. 管控治理能力的提升,包括仪表盘,管理和监控,性能优化,服务运行实例查看等。提供统一的视图,对集成进行监控和管理,端到端的实例跟踪,一站式的系统和业务管理方案。
9.性能增强,Oracle SOA 12c引入了一个全新的特性称之为“构件延迟加载“。这是一个很棒的特性,允许资源文件或组件在第一次使用时才被真正加载,这能够极大提升服务器的启动速度特别是当SOA域中部署了大量服务构件的时候。
10.大文件传输能力增强,在Oracle SOA 12c中增加了Oracle MFT文件传输模块,可以实现对大文件多线程,并发传输,同时实现文件传输整个过程的可视化调度和任务管理能力。
11.云端集成能力增强,Oracle SOA 12c致力于简化、加速并优化与各种云端应用的集成,不仅会提供基于标准化的集成平台用于连接,更提供了强大的一整套解决方案用于解决审计、合规、安全和治理等。
对于一个用Java开发的Soap WebSerivice服务接口,我将这个WS服务通过OSB代理服务接入到OSB服务总线,但是在使用压力测试工具进行测试的时候,发现了一个奇怪的现象,即对OSB封装后的服务进行压测的性能还好于对原生服务进行压力测试的性能,而这里面的一个关键就是OSB本身的服务缓存策略起作用了。
Oracle OSB结果缓存的工作原理
具体的配置也很简单,即我们在通过OSB封装服务的时候,在创建完成Business Service业务服务后,在业务服务的高级设置和选项里面有一项就是Result Caching,我们把这项勾选为Supported就可以启用服务结果集缓存了。在缓存的设置中还有两个重要的项目,即:
缓存标记ID - 我们是以哪个ID作为缓存项目唯一标记。缓存过期时间设置 - 缓存的过期时间设置
通过以上步骤后,我们即完成了一个OSB服务的缓存设置。当我们在进行压力测试的时候,就会发现调用OSB上封装后的服务性能远好于对原生服务的调用。比如我们调用一个供应商查询信息服务,当指定了0001作为ID进行查询后,在缓存生效周期里面再有其它访问请求使用0001去查询供应商,则可以直接从缓存返回。
缓存项的监控和缓存数据浏览
Oracle Coherence 为有关缓存服务器的 JMX 和报表提供了很好的 API,这是监视巨大负载生产环境的必经之路。但对于开发环境和其他重要监视情形,可以使用 Coherence Console。
Coherence Console 是 Coherence 自带的一个命令行实用程序,可连接到特定的 Coherence 服务器。这是一个很好的工具,可以检查哪些服务器参与了集群,还可以浏览缓存数据。
启用进程外独立缓存服务器
现在,我们已经启用了服务缓存,因此具有更好的吞吐性能,并且可以在系统中应对更多用户。但要记住,我们仍在使用进程内策略,这意味着我们将相同的 JVM 内存用于缓存项、WebLogic 服务(如 JDBC 或 JMS),以及 Oracle Service Bus 对象(如转换、代理服务和业务服务)。
如果将缓存使用提升至一个很高的量,可能很容易出现内存耗尽的情况,这就会牺牲掉 Enterprise Service Bus 中的所有其他服务,甚至是未使用缓存功能的服务。
要解决这一问题,可以使用外部 Coherence 服务器,即拥有自己的 Coherence 服务器的专用 JVM。该解决方案可以提高整体架构的可伸缩性,支持更复杂的 Coherence 集群基础架构。Coherence 集群配置不在本文讨论范围之内,但本文对于可以针对自己的情形能实现哪些目标以及进行哪些调整提供了思路。
首先还是说下最简单的场景,假设有A和B两个业务服务,如果A的优先级高于B的优先级,那么在实际的业务调用过程中往往就存在如下场景。
1. 在资源出现瓶颈的情况下,由于B的并发调用量大导致B的TPS高,而A的服务响应反而慢。
2. 在资源没有瓶颈的情况下,由于B访问量的增加导致了A的实际响应速度变慢
不管是哪种场景都可以看到,在实际OSB处理业务或资源受限的情况下,其中包括了OSB本身的计算和JVM内存资源,也包括了实际的网络带宽资源。如何最大限度地保证高优先级的服务的快速响应?或者说如何在并发量增加的时候,为了保证平台的正常稳定运行,如何对低优先级的服务进行限流直至熔断。
传统厂商的产品中也可以设置处理的优先级,但是以消息优先级居多,通过控制消息的处理频率和密度,间接实现对处理资源的使用。Oracle OSB除了设置消息的优先级之外,更加重要的是可以调控不同SLA等级的服务请求在OSB上所占用的CPU和内存资源比例,真正实现了处理资源的分配和管理。
Oracle SOA套件中的OSB产品在前端接入和后端调用业务系统两个层面提供流量控制的能力,在配置前端接入的ProxyService和后端业务系统调用的BusinessService时可以指定相应的DispatchPolicy实现流量控制。OSB底层通过使用WebLogic中的Work Manager为流量控制提供最大并行执行数量、最大排队等待的请求数量、以及在所有请求超过系统处理能力的情况下按比例分配OSB的执行资源。具体核心步骤为:
1. 首先要创建WorkManager工作管理器组件,并进行流量控制策略标准定义。
2. 在进行服务设计的时候,在ProxyService或BusinessService的分派策略定义中选择第1步定义策略。
具体关键参数设置说明如下:
1)请求类-资源占比策略
2)最小线程数约束:为解决死锁问题而分配的最小线程数
3)最大线程约束:可以分配用来执行请求的最大并发线程数
4)容量约束:开始拒绝服务调用请求前可以排队或执行的请求总数
5)阻塞线程操作:如何检测阻塞线程,已经发生问题后需要执行的操作
从上面参数设置也可以看到OSB更多的是基于服务请求并发,SLA等级和资源分配三者进行流量控制,有效的保障服务和OSB平台的可靠性,提升高优先级服务的响应效率。但是实际上对于资源的占用,一方面是服务并发请求和访问量大会大量的占用资源,同时服务请求的消息体容量大也会大量的占用资源,对于第二种情况当前在OSB上是服务马上灵活配置的。
WebLogic JMS是集成在WebLogic Server中的企业级消息系统。WebLogic Server符合JAVA规范,并通过Sun Microsystems J2EE 认证。作为WebLogic的一部分,当然WebLogic JMS Server也完全遵从JMS规范,还支持集群,并可以应用于实际企业系统。
上图中可以看到WebLogic JMS Server主要组件有: WebLogic JMS servers(用于消息通信),, 后备存储(用于持久消息存储,基于文件或者JDBC数据库)。
对于WebLogic JMS Server 主要具备如下突出优势:
极大提高的性能
消息存储持久化
分布式Destination
Unit of Order
自动的透明客户端重连接
存储转发SAF
在WLS中,消息服务由JMS Server实现,JMS实现对消息的接收和发送。在Weblogic 中创建JMS Server的界面参考如下:
持久化消息订阅
持久化订阅是Weblogic JMS的另外一个重要功能,它可以确保即使消息接收者有时处于离线状态,也能正确的接收到消息。
对于消息订阅者是否在线是根据其Java对象是否存在来判断的,在缺省情况下,消息订阅者不是持久化的,但是管理员可以配置消息是否持久化,以及持久化到哪里。
对于消息持久化的应用场景主要是 应用开发需要用到持久化订阅,或者说需要保证消息订阅方服务器重启的情况下也不造成任何的消息丢失。
消息持久化的工作机制如下图,即如果消息订阅客户端是活动状态的,消息会正常发布;如果消息订阅客户端是离线的,当其再次处于活动状态时,使用其ID来重新获取和发布消息。
技术类适配器
技术适配器是最流行、最常用的与多个企业和自行开发应用集成的机制之一,投资最少,极易使用和维护。这些类别的适配器可实现与文件/FTP、数据库、JMS 目标、套接字等数据源的双向集成。
对于FTP类适配器当前更多是实现采集文件数据到目标,或者将源数据输出到文件,而并不是实现端到端的文件传输式集成,因此Oracle SOA 12c套件新增加了Oracle MFT文件传输管理来专门实现对于文件传输的集成。对于数据库集成,重点也是通过数据库适配后查询数据库数据或将输入写入到数据库表中,同时还支持对于存储过程的适配能力,这在老的版本中就已经支持。
对于大数据集成,在前面已经讲过,Oracle专门提供了ODI解决方式来实现大数据集成,ODI解决方案可以理解为ETL+WebService服务能力的集成,既实现的服务的管理监控和鉴权,又实现了大数据量下的高效数据集成和传输。
对于消息集成,当前的消息中间件实现包括了基于JMS标准和基于AMQP两种标准的,对于JMS标准的即实现都对Weblogic JMS,Oracle AQ和ActiveMQ等消息中间件的集成。而对于AMQP的则类似于RabbitMQ和Kafka,对于AMQP集成是否支持暂时还没有进一步研究。
在新版本中,SOA Suite 适配器可实现与 Microsoft MQ、Coherence Data Grid 和 LDAP V3 Directory 服务器的集成。
Oracle JCA Adapter for Files
Oracle JCA Adapter for FTP
Oracle JCA Adapter for JMS
Oracle JCA Adapter for Database
Oracle JCA Adapter for AQ(Oracle 高级队列)
Oracle JCA Adapter for MQ
Oracle JCA Adapter for Socket
Oracle JCA Adapter for MSMQ New!
Oracle JCA Adapter for Coherence New!(Oracle集群对象)
Oracle JCA Adapter for LDAP New!
云端应用适配器
为了让客户能够轻松、自信地将更多管道转换成无差错报价,然后将其推进成后端的订单,以及通过一组丰富的集成加强与客户体验系统中其他应用的协作,Oracle 推出了 Oracle Cloud Adapter for Oracle Sales Cloud。
作为 Oracle 领先的跨渠道营销解决方案,Oracle Eloqua 让营销人员能够计划和执行自动化营销活动。通过 Oracle Cloud Adapter for Oracle Eloqua Cloud Service,Oracle Eloqua 可与任何 SaaS 或内部部署 CRM 应用集成,从而实现统一的客户数据管理,更快地将营销线索发展成销售商机。
Oracle 人力资本管理云让组织能够找到、培养和留住最优秀的人才,管理工作与生活解决方案,并提高运营效率。Oracle Cloud Adapter for Oracle HCM Cloud 将帮助组织简化 HR 流程与其他人才管理、福利和薪资自动化、培训以及工时和项目管理系统之间的集成。
这些适用于 SaaS 应用的全新云适配器(Oracle 销售云适配器、Oracle Eloqua 云适配器和 Oracle HCM 云适配器)提供了丰富、直观的设计时功能以及运行时效率。Oracle 通过在领先的集成平台 Oracle SOA Suite 12c 上发布这些云适配器,将其云扩展到内部部署集成解决方案组合。
云端适配器简化和加速了企业内部应用和SaaS云应用的集成过程,企业可以用最小的成本和开发周期实现企业内外系统间业务和数据的协同,除了Oracle自己的SaaS应用,当然还提供类似Salesforce等SaaS集成。
云端集成最大的好处就是可以更好的实现企业将部分应用迁移为SaaS应用,同时通过云端集成很好的解决了SaaS应用和企业内部应用间的业务和数据交互问题,在整个企业业务域和端到端流程来看,任何一个业务系统都很难封闭孤立存在,而是和其它上下游系统之间存在大量的业务和数据交互。有了这种云端集成和适配能力,就能够很好的实现企业内外系统间的高效协同。
举个简单的例子就是当我们有一个销售人员入职的时候,我们在内部HR维护了人员后信息会自动同步到在线CRM应用软件中,同时对于在线CRM产生的销售订单信息会自动同步回我们的ERP系统,有了这种自动化的集成和协同将减轻我们大量的重复录入工作量。
对于当前云适配器主要包括了如下:
Oracle Cloud Adapter for Ariba
Oracle Cloud Adapter for Eloqua
Oracle Cloud Adapter for ERP
Oracle Cloud Adapter for NetSuite
Oracle Cloud Adapter for RightNow
Oracle Cloud Adapter for SalesCloud
Oracle Cloud Adapter for Salesforce
Oracle Cloud Adapter for ServiceNow
Oracle Cloud Adapter for SuccessFactors
对于这些集成器当前在国内企业内外集成中使用的并不多,但是也可以看到在12c版本对云端SaaS集成能力,服务开放能力的显著增强,从对传统的B2B应用集成能力已经提升到对主流的SaaS应用的云端适配。
传统企业商用套件适配
Oracle 集成适配器有助于通过产品目录中提供的各种企业适配器加快与内部部署的 ERP 系统和企业应用(如 E-Business Suite、SAP、Siebel 和 J.D.Edwards)的集成。所有这些适配器都是基于标准的行业级组件,具有丰富的设计时内省功能。
对于和Oracle ERP的适配对于SOA套件本身已经集成在里面,同时SOA套件还支持和各大主流的商用套件的适配,有自己已经收购的厂家,也有类似SAP ERP软件的适配。同时整个适配覆盖了ERP,CRM,HR,供应链等各类主流的企业常用商用套件系统。
在商用软件中,对于Oracle ERP本身提供接口表方式进行集成相对容易,而对于类似SAP ERP软件都是提供了自己私有标准的RFC或IDOC接口,同时底层数据还是以对象形式进行存储,在这种情况下就更加需要标准接口和这些ERP软件内部进行协同和交互。
Oracle Adapter for SAP R/3 提供了与 SAP R/3 系统全面、双向、基于标准的实时连接。该适配器同时支持 JCA 和 Web 服务标准,可用于创建开放、可重用的面向服务的应用 (SOA)。通过与 SAP 之间高速、低影响、非侵入式的访问公开 SAP 所含关键业务逻辑和数据以供重用,这是构建成功的电子商务应用或集成企业的关键。
当前对于企业应用软件适配主要包括了:
Oracle Adapter for E-Business Suite (PDF)
Oracle Integration Adapter for JD Edwards World New!
Oracle Integration Adapter for SAP R/3 New!
Oracle Adapter for J.D.Edwards OneWorld
Oracle Adapter for PeopleSoft
Oracle Adapter for SAP R/3 (SAP JCo 3.0)
Oracle Adapter for Siebel
对于ERP类的软件适配,当前遇到最多的仍然是和Oracle ERP,SAP R/3的适配,对于国内大企业ERP实施也是基本以这两类ERP软件为主。
大型机和CDC适配器
大型机和 CDC 适配器提供了与原有系统和事务处理系统(如 IMS、CICS、VSAM 或 Tuxedo)的实时连接和集成。它还支持从原有系统/大型机和其他流行数据源(如 Adabas、DB2、SQL Server 或 IMB/DB)捕获更改的数据。
这类集成应该在传统的金融行业使用的比较多,而实际在当前企业中应用的已经相当少,企业私有云推进中可以看到对于小型机都越来越少用,更多全部已经是X86服务器搭建的IaaS云化资源池。
Oracle? Application Server Adapters for IMS/TM
Oracle? Application Server Adapters for IMS/DB
Oracle? Application Server Adapters for CICS
Oracle? Application Server Adapters for VSAM
Oracle? Application Server Adapters for Tuxedo
这类适配是传统ESB服务总线的优势,即对大量遗留系统,遗留消息,交易,事务处理类中间件的适配。
Oracle BPEL设计器服务组件
Service components是使用BPEL构建组合服务或应用时候的重要构造单元。在BPEL设计器中,有如下的服务组件是可用的,具体包括了:
1)BPEL流程:提供对同步或异步流程的组装,编排和存储能力。
2)业务规则:基于业务规则来设计业务决策和分支路由
3)人工工作流:提供了人工工作流审核节点的集成能力
4)Mediators route events (messages) between different components
5)标准Java API接口的集成能力
在BPEL设计中还有一类Binding组件,该类组件建立了SOA组件和外部之间的连接,有两种类型:
1)服务:provide the outside world with an entry point,包括了SOAP/HTTP or a JCA adapter
2)参考:即该组件本身需要引用哪些内部组件或能力才能够最终发布服务到外部。
对于在BPEL设计器中可以使用的Binding组件,具体说明如下:
今天介绍下Oracle SOA套件中的API Management部分的内容,对于API Management按Oracle的说法更多是在12c版本大量增加了云端SaaS应用和移动类应用集成能力后,从企业内部系统暴露的需要和外部应用交互的接口本身的全生命周期管理角度出发,同时兼顾API接口本身的安全性管理而推出的一个产品。
对于Oracle API Management可以看到和当前互联网推出的Open API开放能力服务平台很类似,一个是更加强调了API从注册发布到最终能力开放的全过程,一个是进一步实现从SOAP服务到Rest服务的接口轻量化,同时结合企业安全策略和DMZ区部署要求,实现彻底的服务安全控制能力。
基于官方材料,Oracle API Management分为三个方面的子产品和内容,具体包括了API Manager,API Catalog和API Gateway,下面主要对这三个产品进行分开介绍和说明。
Oracle API Manager
对于Oracle API Manager简单来说就是实现API的创建和发布,后续的管理和健康,即API接口服务的全生命周期管理能力。随着API接口的增加,对API接口的统一管理就越来越重要,这里面不仅仅是实现API接口服务的后期统一管理和监控,也包括了可以将内部的API接口快速的注册并发布为WebService服务接口。
对于Oracle API Manager的关键能力包括了:
1.快速创建API服务:Allows users to easily create APIs
2.安全管理:Provides the ability to secure APIs
3.API的编辑和服务发布:Enables easy API editing and publishing
4.API的快速发现:Facilitates the discovery and use of APIs
5.API服务的访问和接入控制:Controls the access to APIs at runtime
6.API服务运行监控能力:Monitor and statistics about API performance and activity
7.同时支持SOAP和Rest服务:Supports both REST and SOAP APIs
Oracle API Catalog
对于Oracle API Catalog简单点来理解就是API接口的服务目录库,即需要实现对API接口服务的元数据管理,服务查询,服务视图查看,服务多维度浏览等关键能力。对于元数据管理可以详细的看到接口服务的输入,输入,消费方法,安全要求,使用样例等信息,这个和当前主流互联网发布的服务能力开放平台自服务和服务订购页面看到的内容很类似。
Oracle API Catalog (OAC)允许组织轻松构建其API的目录,以便为应用程序开发提供可见性。OAC包括一个用于API服务资产库的简单元模型,这个元模型可以通过API接口服务调用自动解析和计算,同时为用户提供通过检索OAC服务目录就能够清晰的了解服务输入,输出和详细定义信息的能力,以方便用户评估开放的API服务能力接口能否满足业务需求。
OAC通过各种自动化功能来简化流程和优化重用,以促进API服务的消费和使用,其核心能力包括:
1.提供通过API接口自动计算API服务元数据的能力
2.提供API接口服务的编辑和服务发布能力
3.简化了API接口在JDeveloper开发环境中的使用
Oracle API GateWay
Oracle API网关是一个基于标准的、策略驱动的、独立的API安全性和管理解决方案,它使组织能够通过连接所有相关系统之间的差异和管理交互来安全地和快速地采用云、移动和SOA服务。Oracle API网关保护、加速、集成和路由XML和其他类型的数据,以一种简单易用的方式来最小化集成成本、降低所有权成本,减少与SOA和云基础设施相关的部署风险。它是管理内部用户和应用程序资产如何公开的控制点,包括与Oracle融合中间件安全架构的其他方面的外围安全性和集成。
对于API GateWay可以看到Oracle更加强调了简单服务代理和安全策略设置方面的内容,在老的版本Enterprise Gateway产品中,同样着重介绍了安全方面的隔离能力,具体安全隔离如下图:
Oracle的SOA安全解决方案是围绕一个通用的、基于标准的安全模型(ws - policy)构建的。Oracle企业网关首先截取DMZ中的web服务请求。如果该请求被Oracle企业网关接受,它将传递给Oracle服务总线(OSB),它提供额外的安全性(如果需要)、web服务端点虚拟化、通信协议中介和数据格式转换。最后,OSB将请求重定向到适当的web服务端点,该端点由Oracle web服务管理器(OWSM)代理(最后一英里安全性)保护。
对于API GateWay的业务功能和用例场景,可以参考下图描述,其中主要包括了API安全和API管理两个方面的内容,除了安全外可以看到在SLA,Qos等方面的能力进一步提升和增强。
对于Oracle OSB服务总线上的大数据或大消息处理,可以采用Content Streaming或附件方式进行处理,这两种方式可以看到都是不去解析实际的消息体内容,而将其作为数据流进行处理。
1.利用Streaming Body Content处理大消息
OSB提供了一种解决方法,即是采用一种称为Content Streaming的方式来支持大消息的传输,要深入理解这个功能并不容易,作为第一步,你可以理解成body不XML解析,因此省掉了解析的时间,也省掉了内存上的大消耗。而方法你只需要在Proxy Service上设置Enable Content Streaming即可。
对于处理消息内容,您可以指定管道流内容而不是将其加载到内存中。当您为管道启用内容流时,您将指定是否将流内容缓冲为内存或磁盘文件,作为处理消息的中间步骤。这些临时文件的创建可能会影响性能。
当启用流选项时,内容流只应用于$ body变量。
通常情况下,对于Content Streaming内容流的启用一般用于以下场景:
a)当处理一个大的内容消息体的时候。
b)在使用情况下,服务总线访问有效载荷少量次数?
c)对于基于内容的路由无需转换; 由于部分解析可以获取更好的性能。
对于使用Content Streaming内容流处理方式的最佳实践
当你对大消息处理启用流模式传输的时候,你不能在$body消息体上面使用插入,替换,重命名,循环,验证,删除等操作动作。因为这些操作需要在内存中完全实现输入变量,并且完全实现与内容流选项不兼容。您可以使用XQuery或XSL转换的结果,从一个非常大的$Body消息体中采用下面的Pipeline管道操作。
a)Assign, insert, and replace actions
b)Java callouts:Use the results to pass input arguments
c)MFL transformations:使用结果来转换非常大的负载,而不需要首先将输入作为XML Bean实现
对于XSL转换,为了执行转换,所有输入都是完全实现的,因此,您必须确保输入足够小,以便能够完全地实现并由XSLT处理器处理。使用非常大的MFL输入,您应该使用MFL服务,而不是MFL阶段操作来执行MFL to XML的转换。不要使用测试控制台测试具有非常大内容消息的管道,因为内容将完全实现,可能导致内存异常,导致测试控制台窗口变慢。
在运行时,处理大型消息会受到底层传输的限制。例如,传输的消息大小处理限制。注意,JVM和RMI设置限制了传输接收大消息的能力。
2. 通过流模式来处理附件消息Streaming Attachments
对于处理消息附件,可以将服务总线页面MIME附件指定为磁盘,然后对内容进行流处理,而不是缓存内存中的附件,并将它们解析为XML。当使用大型附件时,这是特别有利的。使用这种方法,服务总线只缓存标头,并将消息有效负载的其余部分公开为一个流,其中较小的部分可以一次读取。通过消除对大内存缓冲区的需求,流传输可以提高服务的可伸缩性。
当启用管道时,设置应用于处理入站请求消息。对于HTTP业务服务,设置应用于处理出站响应消息。以下操作允许发送和支持流媒体附件:
a)路由,动态路由和路由表
b)发布,动态发布和发布表
启用流时,所有附件(包括二进制、文本和XML)都被处理为不透明的数据,这意味着您不能基于附件的XML内容运行XQuery或XPath表达式操作。
Inbound Message Handling
当服务总线接收入站消息并将其配置为流附件时,每个MIME附件的内容被保存到磁盘上的一个单独的文件中。然后将$Attachement变量的值设置为每个附件的标准MIME标头,包括内容id、内容类型、内容转换编码、内容描述、内容位置和内容配置,在附件元素下添加。
Outbound Response Message Handling
当服务总线处理出站消息并将其配置为流附件时,每个MIME附件的内容被保存到磁盘上的单独文件中。然后,服务总线以类似于入站请求的方式初始化$附件消息上下文变量(参见入站消息处理)。
首先要注意到Oracle MFT可管理的文件传输模块是在SOA Suite 12c里面新增加一个组件模块,主要就是用于企业内部门间以及企业和外部合作伙伴间的文件传输和交换。即高效,安全的实现端到端的文件传输,任务管理,调度和传输状态监控能力。
即使在当今动态的、面向事件的业务环境当中,对各类文件进行没有大小限制的高效传输都是任何集成策略的核心内容。通过一个统一的、可靠的受管文件传输解决方案来综合离散的合作伙伴的解决方案,能够帮助企业企业节省大量的时间和金钱。不断增长的文件大小和数量,尤其是在云环境当中,需要特殊的方式来处理文件的审核、重放和安全问题,以满足业务和监管的需求。
Oracle MFT与Oracle WebLogic Server、Oracle SOA套件和Oracle身份认证管理集成,为用户很方便的进行企业级文件传输平台的安装、配置和部署。
Oracle受管文件传输(MFT)为企业内部各个部门与外部合作伙伴之间提供安全的文件交换和管理。它在端到端的文件传输当中避免对不安全文件的意外访问。它非常易于使用,尤其是针对非技术人员,用户可以利用更多的资源管理文件的传输。MFT的报告功能使用户快速掌握文件传输的状态,在需要的时候进行重新的提交。用户也能够使用SSH/FTP反向代理保护DMZ中的数据。
注意MFT是端到端的文件传输解决方案,而不是简单的OSB或BPEL里面的FTP文件适配。要明白在没有MFT文件传输的时候,要实现两个FTP文件服务器之间的文件传输和交换,采用BPEL进行服务设计的时候仍然是相当麻烦的,首先要讲文件上传到中间存储,再讲文件从中间存储转发到目标服务器。而基于MFT进行设计,以上动作则变成最简单的端到端设计模式。
MFT文件传输本身具备的大文件处理特性,具体可以总结为:
1.端到端的审计、控制和报告
2.内置的安全、身份管理、LDAP和PGP加密
3.压缩、调度和全面的文件处理框架
4.轻量级、面向云平台的Web页面设计器和管理工具
5.可扩展的端点支持:嵌入的SSH、FTP、文件、SOAP
6与SOA和B2B的集成
7.高可用性和集群,包括DMZ反向代理
8.支持针对大文件的面向云平台的应用