2006年6月9日
#
JSP生成中使用了一般会使用表达式语言EL，语法和Freemarker是一致的，都是${...}，在模版中的<c:out value=$${subject.name}>这一类Jsp EL,很多时候这个${…}是不应该被FreeMarker解析的。但是正如
http://michael.nona.name/archives/75 中提到的，FreeMarker中又没有比较好的转义方法，我下午我也想了很久，突然想到一个方法，可以这样：
<c:out value=${'$'}{subject.name}>
即可以完成转义，解决这个冲突，还是比较好用的
由于yanghuan和shushu考试比较多，晚上我和小曹最终再次review了一下我们的作品，还真是发现了一个小细节的地方不妥，又修改了一下。把所有的word文档转成了PDF，相关文件打包成zip文件，通过email发送出去的一刹那，轻松了很多，两个多月的紧张努力和忙碌，终于可以完美的告一段落了。
从4月中旬中间件课程上杨欢、澍澍说起IBM的SOA大赛，对此都有兴趣的我们，当天去听IBM的SOA宣讲会，立即组织了现在的AccelerateSOA团队，并邀请我们的中间件老师绕老师作为我们的指导老师，从最初对SOA几乎仅仅停留在直觉地概念上，每周开一次会讨论，然后各自去学习相应的SOA资料，到我们每个人都比较全面的明白了SOA的内在思想、整体架构 并叹服IBM在架构上的广博与精妙，并在这将近一个月三两天开会，经常msn会议讨论，email交流，到现在整整两个多月了。这两个多月的合作，我们付出了很多，学到了很多，收获了很多，正如杨欢在我们团队blog上总结的，不管如何，我们已经成功了！
6月26日23：18分，我们的作品正式email提交给了IBM组委会。明天我们应该可以得到IBM的确认吧
现在已经陆续考试了，我们比较庆幸，时间安排得还是很合理，在大规模的考试来临之前，圆满地完成了我们的预定计划。接下来的一周，我们都该集中时间准备一下考试了；同时，在空余时间，我们还会继续SOA的学习和积累，备战复赛。
期待北京之行，五强之争，期待现实中与我们的SOA友队，同台交流、畅谈SOA！
在水木bbs上，都在讨论服务规约具体指什么，这个我也是很疑惑，看了我们伟大的模版设计师小曹同学的服务模型设计文档模版，豁然开朗，呵呵。鉴于很多团队也不明朗，特共享小曹同学的英明发现
中文：
http://www-128.ibm.com/developerworks/cn/rational/419_soa/原文：
http://www-128.ibm.com/developerworks/rational/library/05/419_soa/上面叙述得很详细的，尤其是中英文对照，就可以很快理解啦，摘要如下：
用于软件服务的 UML 2.0 Profile 概述
在IBM Rational Sofware Architect 上实现 profile 的目的是为描述服务提供一个共同语言，该 profile 包括了在开发生命周期内的很多活动并且为不同的涉众提供了视图。例如，该 profile 提供为架构师指定服务的能力――在生命周期的早期――使用逻辑划分来描述整个企业范围的服务组合。这个视图再由设计师来细化，设计师开发服务规约说明――结构上的和行为上的――这个服务规约说明担当服务的客户和实现者之间契约的作用。消息视图为设计师对于公共的服务数据定义提供重用信息模型的能力。
蓝色字体部分对应的是
This view is further detailed by designers, who develop the service specifications -- both structural and behavioral -- that act as the contracts between the services' clients and implementers.
可见：
服务规约应该是the service specifications ，也就是服务的契约、调用约定，担当服务的客户和实现者之间契约的作用，同时服务规约包括结构上的和行为上的，这个我的理解是结构上是指消息的类型，或者在SOA中，应该是SDO部分；行为上，就应该是调用接口了
这是我根据上面developerWorks上的理解
今天整理了一下架构设计概要文档，总算基本上写好了。天气实在太热了，上午出去了一会儿就热得有些受不了了。不过还好明天据说要降温。
然后看了一下原始的需求，发现我们到现在还有一个服务设计没有做，前面也一直没有提到。不过比较疑惑，其中的
l 服务规约
l 服务实现分析
这两项分别是什么意思呢？
期待小曹的服务设计模版，呵呵，有模版可以参照的日子还是很惬意的。
终于发现计数器到1000勒，用SnagIt记录下了这个时刻：
呵呵，上午去实验室的时候，老板说要加强和IBM的合作，我就在想，如果我们最终幸运的进入复赛，那么老板会同意的吧?不管了，先把必要的文档写好，过了初赛，到北京玩一圈再说，呵呵
前一段我们因为很多都是通过email群发的方式，来相互传阅文档，同时每个文档由一个负责人来具体控制，我觉得这样很好，不过我们前面的通过ftp共享的方式，我觉得还是需要坚持，前两次咱们总是需要文档的时候，不知道是在具体那封email里面的，就是这个问题。
我看到小曹晚上已经建立了一个docs_release目录了，我们的正式的文档，就ftp上该目录下吧。另外，每个人的文档，还是放在各自的目录下，同时email附件告知。
ps:这次抢到60了，不过看到我们的访问次数马上就要超过1000了。需要注意的是，我们的1000统计是比较精确的，同时没有计算通过RSS访问的，仅仅有Web访问的计数，所以还是挺可喜的。恩，shushu和yanghuan同学，你们多写写心得哦
推荐两篇文章：
介绍 IBM Rational Software Architect http://www-128.ibm.com/developerworks/cn/rational/524_rsa/
基于RSA实现面向服务的体系架构 http://www-128.ibm.com/developerworks/cn/rational/r-rsa-soa/
我们的组件设计，我看了一下水木上的消息，使用一般的软件画出来也可以，要是可能的话，我们也可以考虑使用RSA来画，或许要好看一些？
晚上又重新看了一下IBM的soa ppt，真的很欣赏一句中国古话了，叫“温故而知新，可以为师也”，呵呵，每次看看，都有一些不同的收获。陶潜曾言，“好读书，不求甚解，每有会意，欣然若狂”，大概也是这种意境吧
WEB1.0是以数据为核心，WEB2.0是以人为出发点的互联网
WEB2.0中的一些技术：
Blog： 用户织网，发表新知识，和其他用户内容链接，进而非常自然的组织这些内容。
RSS： 用户产生内容自动分发，定阅
Podcasting： 个人视频/声频的发布/定阅
SNS： blog+人和人之间的链接
WIKI： 用户共同建设一个大百科全书
WEB2.0中很多技术是为了使Web更加有序化，相互连接，有机组织起来
从知识生产的角度看，WEB1.0的任务，是将以前没有放在网上的人类知识，通过商业的力量，放到网上去。WEB2.0的任务是，将这些知识，通过每个用户的浏览求知的力量，协作工作，把知识有机的组织起来，在这个过程中继续将知识深化，并产生新的思想火花；
从内容产生者角度看，WEB1.0是商业公司为主体把内容往网上搬，而WEB2.0则是以用户为主，以简便随意方式，通过blog/podcasting 方式把新内容往网上搬；
从交互性看，WEB1.0是网站对用户为主；WEB2.0是以P2P为主。
从技术上看，WEB客户端化，工作效率越来越高。比如像Ajax技术, GoogleMAP/Gmail里面用得出神入化。
摘自
http://blog.sina.com.cn/u/4951ae02010003ug
昨天收到的快件，一上午就去拿了，呵呵，原来又是一个光盘，这次包括了一个TurboCRM的实施方案，还有就是一些用友ERP的资料，好像这个和上次的一样，奇怪。
仔细看了一下，TurboCRM的资料还是非常有用的，这次是完整的叙述了一个他们公司的一个案例，我觉得这个应该对我们的设计和架构影响比较大的吧，好好看看再说，正好晚上开会可以讨论一下
仔细看了一下，比较可喜的发现，原来TurboCRM软件是支持B/S模式的啊，原来一直以为不能支持的呢，呵呵。该文章详细的介绍了CRM要解决的问题，以及相应的解决方案，然后就是TurboCRM的一些数据资料的结构和构成，仔细看了倒是发现原来很多理解上的不深入。
具体的资料，放在我们的ftp目录SOA学习资料\用友&TurboCRM下了，大家抓紧时间看看，晚上我们看看可以根据这个把设计做什么改进。
我们已经忙碌了一个多月，现在就到最后的冲刺了，我们再加油一把，就可以到北京休息啦！
今天忙碌了一下，把部署视图写好了。前面大家一直讨论的架构设计的事情，现在经过几轮email讨论，我想我们现在也该是基本上意见统一了，就看明天的组件设计，再把这个写好，我们就可以来一个Review了。
下午收到了IBM寄过来的又一个快件，还没有去看，不过比较好玩的是，这次的收件人是我们的队名AccelerateSOA啦，明天去看看再说，好好奇的呢
加油，Accelerate！
摘要: 用友NC系统中外部数据交换平台的简单原理叙述，同时针对我们的soa大赛，做了一些介绍
阅读全文
BlueDavy的
关于Plugin Framework的关键因素 提到了几点
1、 Plugin的编写
一个好的Plugin System对Plugin没有任何编码上的要求，要求的只是其描述文件的编写
2、 Plugin的部署
如何更加方便的去部署一个Plugin，考虑中根据配置从相应的目录或网站搜索Plugin并注册到系统中
3、 Plugin的调用
根据Plugin的描述采取相应的方式调用Plugin，例如webservice方式、socket方式等等
4、 Plugin的交互
也许可以参考Maven的方式，比如需要调用其他的plugin，则采用类似这样的配置或调用<attain plugin=”pluginname” function=”sendmail”/>抑或采用IoC容器注入依赖？？
5、 Plugin的扩展
对于Plugin的扩展，这个Eclipse的扩展点完全值得参考
6、 Plugin的依赖关系的分析
这是我构思中的一个东西，希望系统所有的模块都基于此Plugin Framework，然后我们可以根据这些模块Plugin来分析整个系统中各模块的依赖关系等等，并进行监控，甚至在将来可以图形化的进行配置，图形化搭积木式的搭建自己的系统，^_^
我发现，这个插件体系结构，和SOA中的SCA体系结构，还有Spring中的Beans工厂，有很多相似之处的，如下：
1. SCA的编写：
需要继承SCA的接口。不过，我倒是更加喜欢spring的方式，使用bean来配置一套系统，对每个bean没有编码限制
2. SCA的部署
使用scdl.xml进行部署描述。如果scdl.xml存在于网络中，是否能部署成功这个倒是不清楚。spring中直接使用xml描述，主要是各个Beans的配置
3. SCA的调用
使用binding进行组合调用，现在支持的有SCA Binding、WebService Binding等等。spring中使用属性注入和构造器注入
4. SCA的交互
使用import/export来暴露具体的接口，然后进行调用。直接使用IOC，注入依赖，相互交互是依靠使用预定义接口，实现契约。
5. SCA的扩展
可以使用继承来修改原来的模块，并在运行时通过替换SCA模块达到目的。Plugin的扩展点（Extension Point）的概念到时值得仔细考虑，非常灵活的。Spring中，通过修改配置文件，使用不同的beans来扩展原有系统。
6、 SCA的依赖关系
好像现在ESB中还没有Service Register的实现，其实，分析SCA的配置文件，是可以找到这些依赖的。本来就是一个总线结构的啊。spring中beans工厂的配置文件现在倒是有很多基于eclipse的实现。
先写这几条，这几天在仔细研究这些技术
由于参加soa比赛，才采用了WBM作为商业建模工具，真正见识了IBM的软件有多么的不好用，联想到以前使用微软软件的舒适经历，突然明白了一点，这就是ibm整个软件思路上的一个特点，好象IBM从来就没有把软件的易用性放到开发计划的重要事项中去，从我上大三学习数据库，使用DB2，我就有这种很深的印象了，就是IBM的软件比较大和难于使用，一如它历史上所推崇的大型机。
微软公司的所有软件，在开发的过程中，都有易用性测试和用户反馈，效果也是非常明显的，也因此建立起了今日的微软帝国。同时，再看看google，令人称颂的也是他的简洁和高效。这些例子都说明，在我们今天的软件开发中，用户的需求和易用性是需要特别值得重视的，恰恰这种我们普通用户都可以体会到的好坏，IBM没有重视，也许还是在抱着它当年的大型机之梦在沾沾自喜吧，历史将证明一切！！
今天发本文主要是实在被IBM的软件气死了，由于WBM的cvs协作设计有问题，我们不能使用cvs进行团队开发，只能每个人都在自己的电脑上处理各自的部分。恰恰是这样，让我发现了WBM的又一个明显的问题，那就是使用WBM的import来合并不同的开发结果的时候，超级难用，而且容易出错。已经有无数次这种合并把我辛辛苦苦的成果覆盖了，今天又一次出现这种事情，实在让我气愤难当，我不知道IBM到底使用过WBM来做一个完成得商业建模没有，如果有，那这种显而易见的问题早该发现了！！
想想一个导入合并其实很容易做到很人性化，比如微软的word，合并文档功能就设计的很好，很智能友好；同时，sybase的PowerDesigner的合并也是，使用图形化的方式，一目了然；其实就是eclipse里面的cvs差异，也是显示的很好的嘛，为什么事情一牵涉到IBM，味道就变了呢？
想到了以前看SharpDevelop的开发日记，决策使用SharpDevelop来进行SharpDevelop开发；在Eclipse的开发中，也使用到了这种思想。当你真正来使用的时候，很多问题是显而易见的。
IBM真是想说爱你不容易啊，强烈建议IBM以后的软件设计中更加重视易用性，重视用户体验，这样才可以更好的发展