今天继续去参加了BEA开发者大会的第二天的会议,在上篇blog中有朋友留言说大会还不错,但人比较多 ,外边有点拥挤不堪,确实这次BEA大会参加的人比较多,今天从戴的胸卡上可以看到又有很多的学生朋友参加,但其实会议期间组织的还不错,也不显得拥挤,当然午餐的时候是可以说特别的拥挤了,两个自助用餐的地方人挤人的,这也没办法,吃饭嘛,当然积极性都很高啦,呵呵。
好了,言归正转,说说技术方面的东西吧。我在昨天的blog的末尾提到了一个问题,就是我们在采用SOA架构进行系统的整合时,对于数据处理,业务逻辑我们都可以提炼出service来整合重用,那我们如何做到各个portal系统的web page的整合,今天一去,我当然第一个就去问这个问题,结果答案和我昨天的想法很相似,就是我们要想把一个portal的page拿到另一个系统上去,这些系统中的pages都不是普通的jsp,aspx或html(当然前两者都是转成html,让浏览器去解析),都是比较特殊的页面,例如weblogic protal 9.2要做到门户联合的话页面要符合WSRP标准,虽然现在我不懂WSRP标准,但可以想象它肯定是一些对页面的显示的限制,比如标签应该怎么用等等这样的,所以我们才可以把页面或页面的一部分当成是一个component,来进行整合和重用,我感觉这个思想和velocity的思想很相似,都是把页面组件化,来达到重用,只不过velocity一般用在单个系统的view中,而前者可以用在不同portal的view的整合。
对于SOA的架构,它除了能够把各种不同技术的业务逻辑实现封装成service ,来实现松散耦合外,对于这些services的调用者Client端而言,我们采用ESB,可以让用户不在去调用具体的某个service的实现,这样就可以屏蔽掉Client端对某个具体service以及该service的某种具体实现技术的依赖,说白话点就是Client不用硬编码去调用RPC 或是EJB或是web service,它是去访问ESB,即使ESB提供的某个service的实现技术变l了,但Client端却不用变化。这是采用ESB的一个好处(当然这些都是对比较大型的应用来说 )。但在这里我又产生了一个问题,就是这样的话我的client会不会和你具体的ESB产品绑定起来,换句话说我要是在系统中换个ESB的实现产品,那我的客户端的代码要不要改变了?
这个问题我后来跟BEA的人交流了一下,自己也想了想,其实是不会的。因为client去访问ESB提供的一个接口,现在大多ESB都对某一个服务流提供一个专门的,它自己的web service做为client调用的入口,那这个web service的定义和调用形式,包括参数传递的形式,都可以是我们自己定义的,并不是ESB产品预先定义好的,所以这样的话客户端的调用应该不会和某种ESB产品邦定起来。
现在的SOA中我感觉最难的实际上是对系统,对业务中服务的定义和提取,就是什么需求我来封装成一个服务,我感觉这方面确实是不好说,至少我目前是没有什么经验,那反过来对于服务,我们又可以细分,分为数据服务(专门和数据存储之类交互的)和业务逻辑服务,相应的BEA有DSP,信息总线;ESB,服务总线;当然我们可以不用分这么细,就形成一个层次的服务也是可以的。
另外BEA在今年的大会中还有个real-time java的概念,咋听起来比较新颖,其实这就是基于BEA公司开发的一个JVM--JRocket,可能它在性能方面较其它的JVM的实现要好一些吧,所以叫"real_time java"。
另外还有一个比较有意思的是虚拟化java应用,实际上就是虚拟一个JVM,也就是说我们在一个启动的JVM上跑着程序了,这时候我能在另一台机器上clone一个现在跑着的JVM和其中的程序,让这个clone在另一台机器上跑起来,相当于有两个JVM在跑,只是这两个JVM在刚开始跑得状态完成一样。
本次BEA大会还有一些比较好玩的东西,但总的主题是SOA,所以这两天这方面的知识还是长了不少,在这非常感谢BEA举办这次的活动,当然也希望能有更多的公司在中国举办这样的活动,这中间有中国的公司就更好了,到时候一定去捧场,不过希望在午餐时记得多提供几个用餐的地点,哈哈!