BEA World 2007 SOA第一日手记

       前一阵子工作忙，去北京参加CSDN的web2.0的机会错过了，这次我正好处与服务框架第一阶段总结期，同时 测试部的资深总监受到BEA的邀请，可以带上 架构师一起去，所以有机会去上海参加BEA World 2007 SOA大会。说起来我们老大说这次会议的主题和我也算是“专业对口”，不是一直在说SCA让SOA落地么，那么就去看看BEA怎么让SOA走的踏踏实实的。

       会议一共分成了两天，这两天上午都是主题演讲，下午和其他的年度大会一样，分成很多分会场，自己可以根据自己的兴趣去选择所要听的主题。因为也没有太多时间去看电子邮件中的会刊，所以对主题都还不清楚，早晨起床就粗粗浏览了一下上午的主题，一共分成了四块：1.超越SOA：技术融合与动态应用。2.江苏电力SOA实践。3.基础架构新探索。4.铸就面向客户的英国航空公司。正好是技术与实践相结合，两个技术案例，两个商业案例。9点左右，大厅门一开，大家鱼贯而入，选了贵宾席后面的第二排，就开始了我这上午半天的BEA SOA之旅。我想看我 blog的多半是技术人员，我们就不讲关于BEA公司的宣传内容，直接进入主题，首先是总的谈谈这几部分具体介绍的内容，然后谈谈我这个半吊子的SOA学习者的一些感触。

       超越SOA ：技术融合与动态应用：

既然是BEA公司的SOA年度会议，那么自然会将BEA公司对于SOA的解决方案和产品推向我们每一个人。这次BEA推出的是他们的SAAS的平台Genesis（创世纪），SAAS今年很热，当然我们自己公司也是基于SAAS理念来构筑我们的电子商务平台，BEA是将三个热门的思想（WEB2.0 SAAS SOA）结合在了一起，放在这个创世纪平台上，这三部分任何一项都可以作为互联网应用开发的新理念来指导新一轮的互联网运动浪潮，不过结合起来是否能够达到想象的效果，这还需要实践来检验。BEA为我们演示了一个关于模拟汽车销售，服务，研发以及客户多角色共同参与的项目实践，在同一个业务系统中，角色的不同所看到的视图不同，同时不同角色可以相互沟通，更甚 者客户可以对于设计者提出设计需求，同时销售可以观察客户行为，主动地推荐产品。同时BPM的流程管理灵活性也在这个展示中成为了灵活适应需求的一个亮点。

江苏电力SOA 的实践：

一个感觉，画图的水平不错，满眼的线路图。

基础架构新探索：

这部分内容其实是对于第一部分的介绍做了部分的系统架构介绍，也就是对于刚在的Genesis平台作了一个总体的概述，以及一个远景规划。阐述了Genesis平台的层次结构设计，主要分成四个层次：

User Interaction

Business Process

Service Network

Hosting

最低下一层 叫作Hosting，并不是我们常规考虑的硬件Hosting，而是指的我们各个业务系统原来的各种实现，也就是我们常说的各种信息孤岛或者就是不同的遗留应用或者针对SAAS来说就是ISV的应用，这些Hosting常常技术实现不同，但是希望能够被融合起来，发挥更大的价值。Service Network是SOA概念中的Service Domain，这一层往往来说是我们现在比较关注去实现的一层，因为这层是SOA是否能够真正达到服务融合，服务复用的基础，如何让服务注册，路由，交互，为上层提供灵活组合的基础，是一个关键性的问题。Business Process层的作用主要是通过BPM来将下层的Service串起来，发挥服务 灵活响应需求变化的要求。User Interaction这层次属于比较高要求的层次，其实也就是结合了Web2.0的一个特性，那就是客户参与和贡献，使得产品更加具有活力。

英国航空公司的案例：

另一个感觉，好多数字展示了英航在互联网信息化的成就。

 

以上是我上午听了四个主题讲座的如实感受和介绍，后面把我自己的一些新的体会感悟说一下。

 

       前面说了，ASF（SCA-based Application Service Framework）第一期正好告一段落，其实在周二来上海之前，我正在画第一期的结构图以及后续需要规划和完善的功能图，当时其实有一些迷惘，作为我来说，不能和Tuscany一样做纯粹架构设计和实现，我需要关心业务部门的需求，根据需求来考虑框架功能实现优先级。根据首架的需求，我的第二期内容在年内暂时大部分内容是对于前期框架Web Service安全性能优化，多种分布式场景技术实现及测试，跨平台客户端兼容性的测试，最后一点就是ISV服务互通的架构支撑预研。总结了前期的工作，同时把一些新的功能点做了罗列（对于基础框架生命周期的维护和监测，扩展点的增加），同时也对性能优化方案作了初步的制定，但是总感觉好像有些迷失方向的感觉，难道按照现有需求就只需要完成这些就达到了我们ASF的阶段性交付了么，对于ISV服务互通采用什么策略呢？正好周二也要来上海，也没有再多想，不过虽然刚才说了早晨的演讲就这么些，但是对我脑子里那些问题倒是正好给了一些spark，下面就将这些spark 一一道来。

       SPARK One：DBA。不要误会，不是我们公司的DBA，呵呵，是Dynamic Business Application的缩写。这个词汇是我第一次听到，也是BEA公司给我的一个新的概念，叫做动态业务应用。它的概念其实就是指服务于服务之间组成了业务应用可以根据用户需求灵活变化，成为动态而非过去，由需求，建模，概要设计，详细设计，编码实现而产生出来的传统商业应用。应为传统应用最大的弱点就是固化和僵硬，面对现在互联网应用的多变性和客户化，传统的设计理念和模式已经很难适应这种应用场景，因此需要一种敏捷的开发模式，面向服务+BPM+ESB，可能这些技术早就都已经存在并且也都曾经被广为推崇，但是结合起来所能达到的效果确不是1+1+1=3的效果。同时结合Web2.0的特质，倡导参与贡献多于遵循使用，这种灵活的框架模式无疑成为应用平台很好的一个理念。此时我回顾了我这段时间SCA的一些工作，当前的服务框架已经能够做到让开发者不用过多关心业务逻辑以外的内容，业务模块化和面向服务交互的理念已经深入开发过程中，但是考虑一下提到的以后ISV应用的互通解决策略，就可以发现，其实由于当前我们所开发的系统首先都是新系统，采用同样的技术架构，虽然ISV和我们的交互已经是异构环境，但是我们系统之间处于业务流程相对来说比较固定，服务组装交互实现可以定义好的情况，也就是说是一种服务静态组装的过程。但是对于未来我们的ISV应用来说，首先都是异构的实现，然后就是在ISV之间串联未必可以通过静态配置和设计事先确定，同时针对用户行为分析是否可以及时动态调整服务流程，都是一个动态的过程，这也给我一个启示，那就是第二期的互通，需要量体裁衣（最后会提到为什么要用这个词），来构造适合的Service Network和 Business Work Flow。当然这个过程还是和我先前说的一样，按照需求的优先级逐步实现，按需而进。

       Spark Two：User Interaction。其实这个概念应该是我在我同事北京带回来程序员web2.0增刊中所看到的一个理念。我 想现实生活中其实这类工作老早开展起来了，就好比你去商场买东西给你一个反馈表，让你填写一下，那么那个产品会根据客户的反馈作一定的改进。只是今天BEA给我展示的时候，通过不同角色所看到的用户操作界面的个性化和专业化，让User Interaction这个概念在技术上有了实实在在的表现，同时在基于刚才提到的DBA基础上，客户的反馈在最最极端的情况下都可以直接主导流程（即客户可以修改流程），不过BEA也说了这还是需要安全策略的配置允许的。那么作为我们未来互联网应用的场景下，这种面向客户的交互其实对于互联网应用来说无疑是很有吸引力的。

       Spark Three：社会计算。这个词很新鲜，也是今天第一次听到，下午也在一个分会场站了50分钟（会场太小，走错以后再回来就只能站着了）。社会计算和Web 2.0中的Social networking有一定的概念上的类似，其实就是沟通，也就是团体的沟通，个体的沟通，通过什么样的有效手段来沟通， rss,mash up,blog，都是一种手段，在上面的例子里面，买车子的客户可以通过 blog反馈给Designer，Sales可以push给客户一个小短片来展示给客户看新的产品，这些都是一些很有效的沟通手段，其实沟通就是为了双赢，互联网贸易除了安全这个大问题以外，剩下的最大问题就是如何让买卖双方因为沟通问题导致交易受挫。同时社区化是应用的互通价值最大化的有效生态环境保证。

       Spark Four：客户行为分析。其实也是一种手段，不过指的是自学习的一种行为分析，类似于Google对于客户行为分析。如果留意一下，我们在日常搜索中如果搜索的内容经常会出现，那么Google就会智能化的提高客户体验。

 

       其实，对我最有启发的还是第一点，同时对于我来说有很多的问题需要去深入了解和分析，同时结合当前框架以及业务场景做量体裁衣，这么说的目的其实 在于听过了BEA的创世纪平台规划后，整个框架设计和理念都是让人觉得很有创新和价值的，但是BEA规划到了2009年，他的功能点和横向纵向切面都作了规划，但是这么一个庞然大物对于ASF来说并不合适，ASF也并不需要朝着这个方向发展。阿里的人都喜欢用武侠小说来打比方，我就打个比方，BEA为韦小宝提供了一套盔甲的解决方案，不论从外观和安全性上来说都是完美无缺的，不过 韦小宝其实需要的是一件金丝甲，轻轻薄薄的，跑路快，又可以刀枪不入。同时有什么问题随时可以修补增改。框架设计的敏捷性和框架问题相应的敏捷性是同样重要的，庞大的项目版本周期长，为了不同客户订制困难，那么就是另一个固化和僵硬的体现。当然设计框架几个关键点需要把握：扩展性，规范通用性（不要用私有的协议），学习基础上的创新。

       上面是上午的内容，其实为什么花了那么多字写了上午的内容，其实是下午的内容没什么好说了^_^

       下午一共参加了四个分会场，一个就是刚才提到的站了50分钟的社会计算和Web2.0的讲座，概念性的介绍，不过扩展了思路。Liquid Infrastructure for Enterprise Java Application，这个课程名字不错吧，流动性的框架针对企业及的java应用，结果去了一听，是谈到使用 vmware的产品，如何在服务器池中部署企业应用，提高效率和节约成本，晚上吃饭的时候和我们的 测试部老大谈起了这个，他刚进公司就做了这样的实施，得却对于效能有一定的帮助，不过对我原先的理解就偏差大了，早知道仔细看看简介了。最后两节课是SOA一个培训的联系课程，今天下午四节，明天下午4节，我今天下午就参加了两节，最后两节，一节是谈到了关于SOA的治理，一位香港的朋友介绍的，听了一节课，就知道他最后一句说出了他SOA治理的名言：SOA治理最难的就是搞 定内部关系，技术从来就不是问题。赫赫，这句至理名言好象在很多行业中盛行。第二节课是对SOA技术的一个汇总，讲师开始整一 个介绍了Web Service的框架，最后才提了一句孤立的Web Service不是SOA，真是画龙点睛啊，要是没有这句话，我真的要为他捏把汗了，不过他发的BEA对于SOA的最后几个领域模型介绍还是应该蛮有帮助的，不过因为时间紧迫，他没有讲这些重点，而是把时间让给了最后BEA认证介绍的讲师。我么，提起包包，吃晚饭去了。

       这就是我第一天BEA的手记，明天是否会下午全部听完，这就要看我们同行老大的安排了，不过还是期待明天上午的主题演讲能够有一些Spark，让我也能有所收获。这次也看见一些同行的朋友提问，有些是技术型的，但是听那两个SOA讲座的有不少还是理论先行的，这感觉SOA又开始在这儿“漂浮”起来。

       总的来说，其实参加这样的大会我也早就有心理准备，未必能够真的了解很多核心的解决方案，只是可以接触一些新的思想，新的碰撞可能会给自己的工作带来一些灵感和启发，后续周末或者下周就可以把第一阶段总结和第二阶段的思考再从新规划一下。转眼就11点半了，洗澡睡觉，期待明天的碰撞，不论是否有火花。