现在的位置: 首页 > 数据库 > 正文

利用OSB (Oracle Service Bus)的Content Streaming处理大消息

2018年10月19日 数据库 ⁄ 共 2420字 ⁄ 字号 评论关闭

http://www.cnblogs.com/alfredxiao/archive/2010/09/16/osb_content_streaming.html

 

利用OSB (Oracle Service Bus)的Content Streaming处理大消息

   最近发现有人用OSB (Oracle Service Bus,即原BEA的AquaLogic Service Bus的后续版),传送消息的文本大小平均接近200K,最大有10M。这种消息大小看来不是常规的一些业务字段,而是较大的业务报文。这样大的消息,又是XML的,恐怕对OSB的性能有影响。

    这是你在OSB的代理服务里面使用了Message Flow,里面可能用到你的body的一些子元素的值做判断,然后调用什么服务云云,这些事情的背后的一个前提是你的报文XML是经过解析后成一个JavaBean的,否则其他地方何以读取其中的子元素(用XPath取值或者XQuery等等)。要命的是,如果XML报文很大,对内存的占用就也很大,而且你的系统肯定不是单用户单请求的吧。

    其实OSB提供了一种解决方法,即是采用一种称为Content Streaming的方式来支持大消息的传输,要深入理解这个功能并不容易,作为第一步,你可以理解成body不XML解析,因此省掉了解析的时间,也省掉了内存上的大消耗。而方法你只需要在Proxy Service上设置Enable Content Streaming即可(其实选项也有几个variation,后面再说),见下图。

    除此以外,有几个要点,是应当知道的。

    第一点必须知道的重要概念,就是当你为你的Proxy Service打开或者说Enable了Streaming后,你不可以再用修改body的那些Action,如Replace/Delete/Rename。原因不言自明,因为没有做过Parse,也就没有代表XML内容的相应的JavaBean,所以无法修改。

    第二点也很重要也应该知道,SOAP的Header还是会照常被Parse的,你可以读取或者修改header对象。因此,如果你想做所谓Content-Based-Routing的话,你更应当把这类Content放到Header中。

    第三点就是,如果实在必要,其实你还是可以读取body的一部分内容,但是这里要想不影响性能,就有不少要注意的东西和技巧了,否则,就跟没有用Streaming是一样的了,这里的内容分以下几点补充说明(很重要,这是理解streaming的关键):

    - 读取部分内容在OSB的术语上叫做Partial Parsing,即部分解析,只解析XML报文中的部分内容(你想要读的那部分)。

    - 可以用Assign这个Action来读取一个子元素,但是千万要注意你的XPath的写法了。假设你的body里面有子元素myElement,其下再有子元素mySub,那么你可能会用$body/myElement/mySub来读取你的子元素的值,但其实这个写法会导致整体XML被解析而不是Partial Parsing。等我给出正确的写法你就明白为什么了,正确的写法是$body/myElement[1]/mySub[1],它表示找到第一个myElement元素,然后读取它底下的第一个mySub子元素。或许你还以为这两者没什么区别,但在这里区别可大了。有了[1](英文术语叫做indexing)除了表示第一个之外,还表示就这一个(后面第二个什么的不要了);但是没有[1]就表示“所有”的这个名称的元素,也就表示了找到第一个还继续往后面找,直到全部的都找出来,换取话说,$body/myElement/mySub逻辑上可能返回多个mySub元素的集合;说到这里,应该很明了了吧。你或许还觉得,不怕,我的XML报文肯定只有一个myElement/mySub。没错,你没错,但是OSB并不知道,只要你没有写明[1],OSB就认为任务还没有完成,还要继续工作,继续找到报文最末段为止。

    - 上面这点很是费口舌,同时你或许已猜出,OSB是从body的开头就开始进行Parse,直到找到(找齐)你想要的结果为止才结束Parsing。所以,被Parse的那段报文就是body的开头到你的目标元素的这一段。因此,一般来说,你要读取的内容应当在body里面是靠前的部分,这样才可以尽可能减少不必要的Parsing。如果你要找的元素是出现在最后的话,那么就跟没有streaming没什么差别了。

    - 同时,应当减少对body的读取次数,如果可以,你尽量重复利用第一次读取的结果,如:

    Assign "$body/myElement[1]/mySub[1]" to "mysub"

    Assign "$mysub/ele1" to "value1"

    Assign "$mysub/ele2" to "value2"

    以上的写法对body的读取只有一次,但如果你读取ele1时写成是Assign "$body/myElement[1]/mySub[1]/ele1" to "value1",那么你就两次使用body了,这是不建议的。

    现在说一说设置Streaming时的选项吧,因为Reliability的缘故,OSB还是会把body的内容用一种串行化(Serialized,而不是XML对应的JavaBean,那个叫Materialized)的形式存放起来,选择Memory则是在消耗内存,但没有IO;选择Disk则是消耗IO,不占用内存。而选择Enable Compression则是消耗CPU,较少内存或者Disk的存量。

    最后,值得注意的是,消息体越大,使用streaming的价值就越大,反之亦然。所以,不要盲目在小消息体上使用Streaming。

标签:
OSB

抱歉!评论已关闭.