dubb，团队老大，唯一女性，和我们走在路上曾言“方圆十米内没有女生”，发现忽略了自己，嘿嘿
不过说实话，咱们的老大还真是拿的出手的，人很pp的说，待人又好，常常觉得能有这样的好朋友或者这样的“老大”实在是人生一大幸事。
这不，参赛过程中，我遇到了很多棘手的事情，老大一如既往的支持着我，简直就是精神力量，嘿嘿
老大，最近惨了，眼中长了一个包包，嘿嘿，女孩子喜欢说的“包包”，长在眼中可不是好事了，老大要动手术，为了参赛，为了继续战斗，为了团队，老大一直推延手术进行时。我考，就冲这个，小力和俺还不赴汤蹈火，在所不辞，高举冲锋号令，倒下老大，还有我们。
老大，今天你倒下了没有？
嘿嘿
走了一圈弯路，居然发现最开始坚持业务侧重点的基本正确，虽然起点有点脱离提供的ERP和CRM产品，严重赞美自己一个，yy一个，嘿嘿。也充分认识一下说服其他人时，必须有很有力的说服证据，这一点还是做的不够的；给自己一个理由就是还年轻没有经验；为什么要给自己找理由呢~人呢~为啥非得给自己找理由呢 但是对别人一定要理解并接受其提供的理由 所谓的“严于律己宽松待人”
嘿嘿
IISC实际上可以认为是一个UDDI，具有一些基本服务，也可以由第三方注册服务，使用者来查询、订阅服务，并需要付出一定的使用费用，而IISC组织提取一定的提成用以维护运转。
IISC提供的基本业务是基础设施，在本题目中，销售人员、财务人员都可以使用其提供的基础设施，出于自己从事的业务和目的。同时对于公司来说，也可以充分利用这些基础设施。这个也是角色决定的。呵呵，不多说了。
另外，公司可以把自己的一些可以公开的服务注册到IISC，为自己使用，也提供给别人使用。提供给别人使用有两个好处，一个是可以利用服务的介绍起到介绍公司提高知名度的作用（正所谓的生活中广告无处不在），另一个是可以利用提供的服务收取一定的利润，这也可以弥补使用IISC带来的额外支付。
6.12小组碰头，介于场所不便，于是到了室外，讨论正酣之际，老天也凑了热闹一把，哗哗的大雨，不过就一阵。我们在搂檐下坚持讨论完毕，并明确各自的任务，我依然享受照顾。
6.14我们再次讨论，首先积极检讨了过程中走的弯路，并充分认可这些摸索过程的价值。其次我们明确了下面每一天应该干的事情以及分工。
在基本业务方面，基本完全确定。在可扩展业务方面，也达成了前所未有的理解和新提议。同时提出了一些创新点。甚至还提出了对ERP、CRM本身的一些可改进的地方。
收获可谓甚丰，这里概要记录一下会议情况，具体细节待继续展开。
评价成熟度后，建设SOA模型的2个方法学：
1.CBM业务组件建模，从企业整体，metrics结构
2.业务（组件）划分，核心价值链，组件如何对不同组件，不同业务目标进行划分
三.服务缄默，架构企业价值链业务流程------〉服务模型
1.服务发现（找到可能成为服务的几个候选者），包括三个方法：
（1）顶级流程分解（粗粒度）
（2）业务目标的建模（目标-----〉服务）
（3）分析现有系统，划分，类比 （接口，形式。。。）
以上可以引出服务目录的概念。
服务目录：就是潜在的服务的集合
2.服务的规约
从服务目录入手，分解属性，跟现有哪些业务关连在一起，决定哪些成为服务-----〉模型，书面specification
3.服务的实现决策
哪些需要包装，哪些需要新方法
与传统架构结合（用例等）
4.如何从服务模型映射到参考架构
要与企业架构隔离开
业务功能-----〉服务
服务中介-----〉ESB
非功能------〉服务监管
可参考流程引擎
5.*服务监管
SOA灵活性{
服务模型
复杂性-----〉ESB
}
监管方法：{
服务模型
参考架构
}
方法学：{
角色
职责
}
柔性架构快速适应变化
服务注册库------企业IT的生命周期管理
今天进行了第7次小组讨论。原定的讨论内容是个人划出业务流程图，大家一起整合。但是，liuli在咨询了他的学财经的同学之后发现，我们上次讨论
存在的一些问题，所以，这次讨论主要集中在解决这些问题已经下次讨论的任务。特别提出的是，liuli发现了我上次学习crm的一些遗漏点，呵呵，值得表扬。
本次讨论是在户外进行的，中途还下起了大雨，可谓条件艰苦。
马上就要进入艰苦的阶段了，大家加油！
这两天专门找一些在公司工作，比较熟悉企业业务流程的同学谈过了，发现我们团队在分析业务的时候，有很多地方的理解存在偏差，对有些业务流程的分析是想当然的，导致在一些无谓的问题上浪费了时间。
发现问题总是好的，亡羊补牢，犹未晚也。前一段时间的弯路不能白走，这将变为我们宝贵的经验，后面的工作将更坚定的从实际业务的分析出发。需要的时候，向在企业管理方面和销售方面的朋友取取经，这些宝贵的人力资源可不能浪费^_^
如果能进入下一轮，咱们团队的优势就能充分发挥出来，呵呵，咱们实验室主要的方向就是Web Service、中间件技术，这两年咱们没少和XML、Web Service、J2EE打交道，这些都是SOA的主要技术。当然，闯过第一关再说，否则，一切都是白搭...
业务分析咱们现在已经进行得差不多了，就等着进行业务建模了，现在业务建模最重要的工具WBI还没有，今天花了不少时间也没找到，郁闷中...实在不行，只有赶紧联系IBM了。
上次刚刚写过一个《前有追兵后有拦截》的文章；小组在今天（06.06.12）提议对我进行特别的关照，暂时不用我投入过多精力备战，更多的关注一下私己之事。
在严重传达兵临城下之紧急同时，格外的照顾，着实感动.....无奈之际，祝福团队走的更好...
不过今天刘力表达极其干净利索，不由得让我刮目相看一把。小力本来就应该这样的。
危机就是好像几天没有准备，思维已经有些被动了。记得某某人曾经说过“三天不学，比不上***”，的确说出了持续努力的必要，伟人都如此，况我等。
不知道是IBM效率低，还是学校办事效率低，都过去快三周了，IBM提供的软件到今天还没有收到，看着其他队伍早用上了，急啊。上网找找看吧，功夫不负有心人，还真有人把IBM.Rational.Software.Architect6.0共享了，不过只有RSA，其他都没有找到。没关系了，就从RSA开始吧，再说RSA也是IBM提供的SOA的主要工具之一。RSA整整四张盘，折腾了一上午，终于下载并安装完了，平时最烦这种安装配置工作了，没技术含量还挺费时间:(
粗略了解了一下RSA，发现功能非常强大，系统提供的帮助也挺详细的，但是不知道是不是真的实用，不多说了，抓紧时间学习使用......
会议比原定计划推迟了两天，这段时间大家一直比较忙，各种事情接踵而来，希望这几天忙完了，大家有更多的时间放到比赛中来。
讨论集中在对用友的ERP软件和TurboCRM软件的分析上，在这几天里，crazycy主要分析题目和ERP的物流部分，蓝凝分析TurboCRM，我分析ERP。
无论是ERP还是CRM，比赛主办方给的东西都很多，讨论的时候每个人也都带来了一大叠资料。会议开始初期，初步确定了讨论进程，先是蓝凝给大家讲解CRM，然后我讲解ERP，最后大家再对CRM和ERP进行综合分析。
蓝凝对CRM的准备很充分，CRM讲得很具体，在她讲CRM的过程中ERP的内容也时不时穿插进来，结果对CRM和ERP进行综合分析也同时进行了。讨论进行了大约三个小时，取得了不少结果，具体内容这里就不详细说了。
最后，我们确定了下一步工作，三天之后，也就是周六晚上进行第七次讨论，下次每个人必须把对业务模式的分析画出来，再把三个人的分析进行综合，业务模式分析和设计到那时候就应该差不多了。
最近大家比较忙（实验室的项目要出新版本，论文快要截至了），再加上天气的原因，团队出现了一些不良的情绪。
但是我觉得既然参加比赛，每个人都要出力，不能指望别人看。当大家都没看的时候，要有紧迫感而不是互相指责。如果有人看的好，那就给大家说说，并不是你看得好，就要炫耀，就要鄙视别人。大家情绪都不好，在这种情况下更不能把个人的情绪带到团队里来。
为了更好的跟踪进度以及避免上面的情况再发生，我提议，每天大家报告一下自己的进度。无论做什么，刚开始都是有热情的，但是过了一个阶段，就会出现疲惫的心理，剩下的就是当热情散去的枯燥的工作。所以，同志们，做好打持久战的准备，调整好自己的心态，坚持下去，肯定没问题的。
摘要: IT面临的问题：架构的复杂性，具体表现在 1.程序臃肿，据统计，70%的经费都用在了对已有系统的改造等方面，只有不到30%的用在了增加新功能上。 2.脆弱性： 3.迟钝：企业架构：应用与应用之间的业务逻辑有重复问题来源：接口问题 第一家开发商对系统会对原有接口进行改造，随着时间的推进，又来了第二家，第三家，第四家开发商，每个开发商都对系统进行改造，结果原来... 阅读全文
为了更好的活着，基本开始逃避团队事务了，呵呵；
今天(2006.6.6)晚上将针对6.2的计划安排展开讨论,却发现身在外边的我既没有word套装,也没有已分析的资料,尴尬的很,还好电脑里有写字板和windows自带的绘图工具(突然觉得miscrosoft很体贴可亲了),完成了题目分析的全图,唯一缺少的就是上次讨论的总结部分,只能讨论前再附加上了.
呵呵,还有"ERP中物流的分析",.......
现在就是这么觉得，许多事情要做，有紧急不重要的，有紧急重要的，有不紧急重要的，有不紧急不重要的但是还得做的；
罗列在一起一大堆；逐渐明白，却发现明白了，却忽略了事情的轻重缓急，有点本末倒置的感觉“（逐渐明白，那份爱已不再）”。为此唯一的就是承受后果，可能会很惨，买个经验值，交点学费。
这个在准备竞赛过程中又淋漓的展现着，而且即将到来的更猛烈的炮火紧逼，正所谓“前有追兵，后有拦截”（韩老师）。
希望就希望一点，基础建设的一些物化的证明不要作为一个硬性的指标，毕竟物化是一个证明，没有证明也不意味着不是良民啊...
还有我的目标就是我的blog量要达到这样的目标：me's > 刘力's + 蓝凝's。在这么严峻的考验下，为了更好的活着，活着，目标要降一降，责任要自我减负，事情要自我减量。
尤其今天阅读同路朋友blog，阅读水木同专题，却觉得很是心力不及，常看评论如果发生战争中国能同时支付几条战线的分析，一个泱泱大国都有这样的问题，一个小小的我用正在经历的，可深深感觉其难。不是能力不够，而是...综合综合因素啊。
这次讨论crazycy又迟到了，我和蓝凝在会议室等了半天，crazycy，下次再迟到，就该罚你做俯卧撑了:)。
现在我们讨论的周期差不多是三天一次，看来第一次讨论制定的两天一次的计划不够现实，不过还好了，我们一直有一个固定的泡泡群，几乎每天都有小讨论，平时一些看法在群里面都很快能够得到统一。
讨论的主要内容还是对业务的分析，大家都觉得上次的讨论有点偏了，讨论了很多ERP和CRM中已经实现的功能，而不是两个系统之间的交互功能，以后咱们对业务的分析都应该建立在对实际实现的分析之上，一切从实际出发嘛，咱们可都是唯物主义者啊。
之后，大家就具体的业务分析图，进行了审核，每个人都给出了自己的意见。此外，我们还对使用到的技术、采用的软件工程方法以及工具进行了交流，讨论的内容比较丰富，效果也是显著的。
最后，我们对下一步工作作了一下简单的分工：我负责ERP的分析，蓝凝负责CRM的分析，crazy负责对题目的整体分析以及ERP中物流的分析。
刚刚看了水木的统计，截止到今天，也是报名的最后一天，差不多有320左右支SOA队伍了，呵呵，好有压力哦。还看了一些兄弟团队的BLOG，有些开始建模了，报名早的队伍，已经使用上IBM提供的软件了，看来咱们得加快进度了，呼呼的赶啊。
在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和Use Cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。AM的目标是仅仅创建用户想要的,AM的核心思想就在于其敏捷性－处理需求变更的敏捷性.
那么，如何开始SOA呢？经过了几次讨论，大家已经度过了盲人摸象的阶段，实质性的进展是从5.30号晚上的那次讨论开始的。从那次后，已经逐渐的看清了方向。
最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。
开始简单的SOA使我们可以在作出大的决定前之前先衡量，并在出现大的问题之前获得小改善的经验。
所以，再次看到SOA的的第一条准则：“业务驱动服务、服务驱动技术”的时候，深有感触。这才是问题的本源，原来的几次讨论和想法，其实都偏离了轨道。
最近发现大家好像很久都没去水木了，觉得还是建议大家经常去看看。一方面，即使的了解相关的信息，另一方面，看看各兄弟队伍的情况，是否有些可借鉴的东西。可以参与一些讨论，广开言路很重要啊。
同时，也欢迎个兄弟队伍来我们的blog做客，多提宝贵意见，共同进步嘛。
首先，需要明确的是，SCA还没有成为正式的标准，尽管SCA目前已经有比较稳定的规范，有些文章错误地将SCA作为标准来看待。
SCA目标：基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，比如在J2EE技术领域，就有EJB，POJO，JDBC，JMS等。这对于项目初期分析和设计人员来说，是一个很大的挑战，导致在初期就需要选定具体的语言和技术。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。
SCA和WSDL
WSDL是Web服务描述语言，但它只定义了服务接口，并不提供描述一个服务所依赖的其它服务，以及这个服务所需要使用的配置策略和服务之间的依赖关系。单独通过WSDL很难实现服务之间的组合调用。SCA比WSDL走的更远，SCA定义了服务组件模型以及服务组装模型。服务模型允许服务开发者不但定义服务的接口而且还定义了这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略，还有服务潜在的配置等功能。服务组件是SCA中的基本组成元素和基本构建单位，也是我们具体实现业务逻辑的地方。我们可以把它看成是构建我们应用的积木。
SCA和JBI
SCA和JBI其目的有很多相同之处：JBI在JSR 208中被定义，已经成为使用Java语言把服务容器组装为合成应用的标准；SCA是被推荐标准，为在不同平台不同语言解决组装问题的提供了更广泛的方法。SCA关注是的SOA开发者最初看到的和接触到的，SCA并不关注SCA各个模块最后是如何实现的。如果把SOA分成三个抽象层次的话：业务、服务、技术。那么SCA对应的就是服务层的规范。JBI提供了一系列的API，用来建立开放、可扩展和模块化的企业服务总线。可以说，JBI已经触及到具体的技术层面。SCA没有局限于具体语言，而JBI仅限于用Java，因此JBI的应用范围更严格，在SOA未来的标准体系结构中，可能成为其中的一部分Java实现标准。
摘要: BEA的"SDO简介"中讨论了SDO设计的动机并从动态数据API、数据类型自检API、数据跟踪变化API三个角度展开。动态数据API主要是因为Java是静态（强类型）语言，不能在运行时将额外的字段或者方法添加到对象的实例中。==============针对这个问题其提出DataObject概念 DataObject do = new DataObjectImp(); do.set("name","... 阅读全文