再出色的女人，如果身边空空，就使人觉得凄凉。比如张爱玲，她的感情生活就像李碧华所说，是一口古井，任由后人来淘出的都是一地清冷月光。
夫唱妇随，才能交相辉映，。
  同样再出色的人（这次不分男女了哈），如果孤军奋战的话，也会使人觉得凄凉。不过我们就不一样了，我们是一个小家庭，不论是感情生活还是技术
生活都是一片汪洋，随你怎么淘，淘出的都是金色的阳光。
  呵呵，漂起来了。。。。。。
  提交作品了，心里的石头也放下了一块，回头看看这一个多月的时间，真的是成长了许多，无论是技术上的，还是团队合作和管理上的。技术上，
虽然写的文章总被人批评，不过至少有人对我的文章有兴趣，也算是另一种安慰啦。团队合作上，平时不觉得，真到了在一起做项目的时候，才发现每个人都和以前
不太一样啊。也是通过这次大赛，让我发现了每个人的另一面。团队管理上，呵呵，说来惭愧啊，没为大家做什么事，而且虽然只有3个人，不过这个队伍也不好带啊。虽然有争执，虽然有困难，可是我们还是坚持下来了，不是吗？
  怎么说呢，在这段日子里，虽然有一些事让我生气，但是，也有很多事情令我感动。是大家的坚持，我们才会走到今天，才会完成作品。
  所以，无论我是要哭泣着，还是微笑着与你道别
  人生本就是一场难分悲喜的演出，
  而当灯光照过来，
  我就要必须唱出那最最艰难的一幕，
  曲终人散后，
  无论我是要哭泣着，
  还是微笑着与你们道别，
  我都会庆幸曾与你们同台。

搞笑啊，因为每次都是默认的用户名，结果，前几天把用户名给忘了，怎么也上不来了，把我急的啊~~~
看着那么多批评我文章的话，我有话没地方说，更急~~~~
结果牙也肿了，眼睛还长东西，~~~~~~
现在好啦，事基本都忙得差不多啦，晚上提交附件，而且也把用户名给想起来啦，上来喊两声，嘿嘿，兄弟们，我又回来啦

共同工作：
查找相关资料
分析题目
讨论需求
业务流程分析
技术学习
个人分工
姓名 工作 备注
dubb CRM相关资料及接口分析
1.  
crazycy  
liuli 1.ERP 
1.2.2 整体分工：
姓名 工作 备注
dubb 协调工作
会议的组织
进度的安排
相关技术的学习 会议的纪要由每个人轮流整理
每次会议有一个主要的发言人
crazycy 相关团队消息的跟踪
相关网站的跟踪
相关技术的学习 相关技术的学习，liuli相对来说多一些
liuli 相关工具的掌握
相关会议的跟踪
相关技术的学习 
1.2.3 文档设计阶段
时间 任务 负责人 备注
2006.6.10至2006.6.18 业务模型的分析设计 liuli 这是个迭代的过程，与服务建模交互
2006.6.13至2006.6.20 服务模型分析设计 dubb ,liuli帮助修改了文档
2006.6.18至2006.6.23 系统架构设计 liuli，crazycy 用例模型分析和数据模型分析由liuli完成
2006.6.23至2006.6.27 组件设计 crazycy 以上过程均是迭代的过程
2006.6.23 项目综述 dubb 
2006.6.25 设计实施计划 dubb 
2006.6.27至
2006.6.28 整体文档的检查 全体成员 每个文档都是经过了数次迭代与修改，在所有文档完成后，大家由一起将所有的文档进行了检查，包括：
格式，内容，标点符号，图形等。

SOA相关资料查找分析
TurboCRM分析完毕
用友ERP分析完毕
题目要求的业务流程分析完毕
需求分析完毕
业务流程图分析讨论完毕
需要工具安装完毕
业务建模完毕   听说周六有IBM的技术讲座，哪能错过，赶紧注册。。。。 
  周六早上起了个大早，和liuli一起到体育馆门口等IBM的车，到了体育馆才发现，已经有n多xdjm在等了。看来同志们对soa还是很感兴趣的啊。不过，让人ft的是等了好久都不见车来，已经9点钟了，人群开始散去，这时候，我和liuli立刻做出了一个决定，不能再等了，自己做车去。于是我们俩跑到了知春路去做公交车。
   好不容易到了，会议已经开始40多分钟了，门口的IBM工作人员问了我们班车的情况，我们宣泄了一下不满，因为有好多人因为车没来就放弃参加了，如果不是之前IBM发信说有班车来接的话，然后早上等了一个多小时车没来，他们肯定会来的。
  听了一天，就IBM的产品来说总体感觉就是比较人性化，我指的是提供了图形界面的工具已经自动的代码生成工具。因为，在下午有个环节是拿微软和IBM比较，比较的内容是将已有的功能包装成服务并发布，两位博士一个负责用IBM的产品，另一个用的是微软的产品，同时进行。在大屏幕上可以清晰的看见IBM的执行过程全部是图形界面，其间并没有涉及到具体的代码；而微软的产品并没有图形界面，所有的操作看来就是一个程序员在写程序一样，结果可想而之，速度当然比不上IBM而且其复杂程度也对程序员有很高的要求，即必须知道底层代码及所有的环节才行。
  不过，我在想，如果微软也把同一套流程做成了图形界面，同时添加了代码自动生成的功能，那么那时候，两者再比较，结果会是什么样呢？
  ps：liuli在用WBI的时候，发现了不少的bug。

  经过以前的数次讨论，方案终于定了下来，在接下来的日子里，每个人负责不同的部分，开始进入各种文档的实现阶段。
  我负责写总体的需求文档，虽然以前写过类似的什么需求分析啊，概要设计啊，相信设计等等，但是，这次的需求文档还是花了我很多的心思。
在写之前特别又看了一遍《需求分析黄金法则》那20条，写了一个晚上，一气呵成，不过不知道是因为文笔退步还是别的原因，写出的文档，大家不是很满意，
咳，严重郁闷中。
        ·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

        ·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

        ·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

        ·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
这几项都有包括啊，回头问问差在哪里了。
  虽然大赛并没有要求提供需求分析文档，但是需求在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用，所以，就像软件工程的流程一样，一切从需求开始，一切文档化。
         接着修改。。。。。。。

评价成熟度后，建设SOA模型的2个方法学：
1.CBM业务组件建模，从企业整体，metrics结构
2.业务（组件）划分，核心价值链，组件如何对不同组件，不同业务目标进行划分
三.服务缄默，架构企业价值链业务流程------〉服务模型
1.服务发现（找到可能成为服务的几个候选者），包括三个方法：
  （1）顶级流程分解（粗粒度）
  （2）业务目标的建模（目标-----〉服务）
  （3）分析现有系统，划分，类比 （接口，形式。。。）
以上可以引出服务目录的概念。
服务目录：就是潜在的服务的集合
2.服务的规约
  从服务目录入手，分解属性，跟现有哪些业务关连在一起，决定哪些成为服务-----〉模型，书面specification
3.服务的实现决策
  哪些需要包装，哪些需要新方法
  与传统架构结合（用例等）
4.如何从服务模型映射到参考架构
  要与企业架构隔离开
  业务功能-----〉服务
  服务中介-----〉ESB
  非功能------〉服务监管
  可参考流程引擎
5.*服务监管
SOA灵活性{
          服务模型
          复杂性-----〉ESB
          }
监管方法：{
           服务模型
           参考架构
          }
方法学：{
         角色
         职责
         }
柔性架构快速适应变化
服务注册库------企业IT的生命周期管理
         
            

最近大家比较忙（实验室的项目要出新版本，论文快要截至了），再加上天气的原因，团队出现了一些不良的情绪。
但是我觉得既然参加比赛，每个人都要出力，不能指望别人看。当大家都没看的时候，要有紧迫感而不是互相指责。如果有人看的好，那就给大家说说，并不是你看得好，就要炫耀，就要鄙视别人。大家情绪都不好，在这种情况下更不能把个人的情绪带到团队里来。
为了更好的跟踪进度以及避免上面的情况再发生，我提议，每天大家报告一下自己的进度。无论做什么，刚开始都是有热情的，但是过了一个阶段，就会出现疲惫的心理，剩下的就是当热情散去的枯燥的工作。所以，同志们，做好打持久战的准备，调整好自己的心态，坚持下去，肯定没问题的。

IT面临的问题：架构的复杂性，具体表现在
      1.程序臃肿，据统计，70%的经费都用在了对已有系统的改造等方面，只有不到30%的用在了增加新功能上。
      2.脆弱性：
      3.迟钝：
企业架构：应用与应用之间的业务逻辑有重复
问题来源：接口问题
      第一家开发商对系统会对原有接口进行改造，随着时间的推进，又来了第二家，第三家，第四家开发商，每个开发商都对系统进行改造，结果原来的接口已经面目全非。
根源：没有人从全局对业务逻辑，实现，接口的定义等统一的考虑。
SOA可以很好的解决以上问题。
SOA原理：接口在现在应用之上构建抽象业务服务模型。由服务推出新的需求？构建应用有规范，标准？
由垂直应用到水平应用，公共平台上的服务串接，接口由服务模型解决。
架构：基于ESB柔性架构：
      优点：1.不需要了解别人的协议等细节，反问外部的信息都用自己本地协议来访问。技术依赖较小。
            2.业务流程与IT耦合度小。
       ESB起到服务虚拟化作用。服务在不同地区实现不一样，ESB通过服务中间隔离不相关因素，使上层业务看到的相对一致。
            3.数据模型。使应用访问数据时，不用考虑地域区别如北京，上海；不用考虑数据的格式如ORACAL，SQLSEVER等差异。
            -----〉企业数据模型+数据即成=一致的服务
认证模块剥离开企业架构------〉无序世界变成了有序的世界
思路：关于服务建模方法学，帮助企业构建SOA
      5个步骤：
      1.SOA成熟度模型定位企业现在，未来的成熟度，对比它们之间的明显差异，帮助实施转型。SOA更多的从业务角度讨论问题。
        分6个层面讨论
        （1）服务模型指导开发（业务改变，不单独，要全局）
        （2）监管
        （3）方法学
        （4）应用：越来越面向业务。组装，松架构，安全，性能，数据，集成，管理隔离开。
        （5）虚拟基础设施迁移
             现有SOA成熟度{service
                           component}
             公共服务模型引起组装。

            
这里有一个很好的关于SOA的过去，现在，将来的比喻。
SOA------〉城市的发展
初期：一个小村落，两个小村落，一些小村落
现在：城市，要规划哪些是商业区，哪些是政府，哪些是居民区等等，要有一个全局的规划
将来：虚拟的社区，在家里即可购物，等等。即虚拟化，动态的划分。
未完，待续。。。。。

    在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和Use Cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
      SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。AM的目标是仅仅创建用户想要的,AM的核心思想就在于其敏捷性－处理需求变更的敏捷性.
      那么，如何开始SOA呢？经过了几次讨论，大家已经度过了盲人摸象的阶段，实质性的进展是从5.30号晚上的那次讨论开始的。从那次后，已经逐渐的看清了方向。
      最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。

　　开始简单的SOA使我们可以在作出大的决定前之前先衡量，并在出现大的问题之前获得小改善的经验。
    所以，再次看到SOA的的第一条准则：“业务驱动服务、服务驱动技术”的时候，深有感触。这才是问题的本源，原来的几次讨论和想法，其实都偏离了轨道。