参加BEA开发者大会_续

       今天继续去参加了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举办这次的活动，当然也希望能有更多的公司在中国举办这样的活动，这中间有中国的公司就更好了，到时候一定去捧场，不过希望在午餐时记得多提供几个用餐的地点，哈哈！