TurboEAI_whitepaper是个很好的资料
TurboCRM是基于TurboEAI系统的
TurboEAI系统提供标准接口，实现与企业的外部网站、财务等其他业务系统的实时数据交换。对外的数据接口服务由TurboEAIServer完成，而由导入工具来把外系统数据批量导入CRM系统。但用导入工具需手工干预，而用XML格式数据能够做到实时交换。
第三四篇就更让我兴奋了：
通讯协议，数据格式，认证机制，通讯流程。是我们系统设计时的很好参考

而在用友的资料里也很高兴地看到，xml也是用友ERP的标准数据交换格式。不过这篇 '如何写Java程序向NC外部交换平台传送数据' 写得一般。
此外，建议WB+文学去看TurboCRM_V4.2_whitepaper，除掉它们自己做广告的那块，功能模块一章可以做我们企业业务分析的参考，最后的案例也可借鉴

恩，xml是个好东西。豆丁我们借的那本j2ee的书里讲到：
eXtensible Markup Language, 可扩展标记语言，是一种独立于平台的数据表示方式。有专门用于xml处理的JAVA API，SAX用于解析xml数据，DOM则以树形模型表示xml文档，XSL及相关转换标准说明了xml文档的格式

so nice

时间：2006.5.31.
主题：怎样体现soa思想，初赛交付件各部分理解

一. soa理解

soa关键：从业务角度模块化，组件设计依据业务需要
SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。在目前，提供许多企业应用接口函数的j2ee就可说是初步的soa

二 初赛交付件理解
对前三项任务做一个分工，还有思路分析

2) 业务模型分析设计 (Business Model Specification Documentation)
字数不限,应当至少包括以下几个方面的详细描述,可以根据理解进行自由扩充。
 业务模型分析与展望         ：我们需要的业务，题中是最基本的，还需要进一步开发。WB和文学的重任
 业务模型对IT系统的挑战   ：我想主要是技术实现上的困难

3) 服务模型分析设计 (Service Model Specification Documentation)
字数不限,应当至少包括以下几个方面的详细描述:
 服务发现及其依据    ：blog中技术资料中第一篇提到了服务发现的三种途径：1)企业的业务用例，业务领域分解 2)分析现有系统体提供的API、事务和模块 3)目标服务建模，从目标发现服务。我想一三项你们做更有优势
 服务规约                    ：讨论见下
 服务实现分析

4) 系统架构设计 (System Architecture Documentation)
字数不限，应当至少包括以下几个方面内容的详细描述：
 用户需求描述(需求概述、业务环境描述、IT环境描述)      ：分析当前凤凰公司的情况，前两项WB和文学做
 用例模型分析           ：？？
 数据模型分析           ：建立数据流动模型，包括格式，流动方向，同步要求
 关键技术架构决策    ：j2ee/xml等
 系统架构分析

服务规约：１，首先关于对服务／业务的理解。我认为，符合它们的英文名字ｓｅｒｖｉｃｅ／ｂｕｓｉｎｅｓｓ，服务是系统中所具备的功能，比如我们提供客户资料记录与更新，业务是企业需要的东西，比如销售员在外需查询客户资料 ２　在这个基础上，我猜服务规约是指系统中这种功能的约束。比如谁拥有权限查询，在与其它信息交互时谁先谁后更新。也许更重要的是谁也决定和修改的权限。例如定单上交财务，财务查询库存后发觉不能生产，那么他就能决定是否接受定单 
不知对否，再议

然后还有两个部分　5) 组件设计　和　6) 设计实施计划。6) 好说，是最后做的事情。但组件设计很重要，我们把前三项做完了才能做组件设计。这个阶段将需要设计，反馈到业务中检验组件划分合理性，再设计，再反馈

三 其他信息
soa做得好的几家公司：ibm, hp, bea, sun
kedo推荐的网站：http://tech.ccidnet.com/pub/series/s627.html
整合生命周期，大概就是指用ｓｏａ使得其系统可扩展性加强

四 我们的计划
1 关于借书 有推荐的贴到blog里或群里。侧重有好的案例的书
2 凤凰是个制造企业，有生产有库存，还有物流。可有很多文章可做。而那原有的两个系统集成就有很多流程再造的问题
3 WB和文学有时间的时候希望你们第一个先做题目中要求的　订单更新整合功能　的　业务对ｉｔ要求分析　和　该业务的实现流程图



 

两种粒度实现SOA服务

可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。

在SOA中服务粒度有两种相关的意思，即服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。

细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以，粗粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。

组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量不是粗粒度服务和组合服务之间的区别。粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在CRM应用系统中创建客户记录。组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证订单、创建或验证客户，确认产品库存及为数据线分配资源。

通过一组有效设计和组合的粗粒度服务，业务专家就能够有效地组合出新的业务流程和应用程序了。

　　记者将这个问题抛给了在SOA方面拥有丰富经验的IBM软件中国区Websphere技术部经理聂华。聂华从技术的角度认为，SOA的技术优势主要体现在后台的开发。利用以前的各种整合技术，的确可以实现流程和信息的整合，但缺乏统一标准和灵活的架构，不具有开发的延续性，直接造成的问题就是后来的应用与以前的应用很难集成，而这正是SOA要解决的问题，也是SOA优势最重要的体现。

　　从体系架构上来看，SOA具有以前各种应用架构无法比拟的灵活性，但SOA的实现也不是一蹴而就，由此，IBM在这次整合实战大会上提出了“整合生命周期管理”的新概念，让SOA的实施变成阶段性的工作。

---------
这段话说得很泛泛。不过还是有点帮助。晚上一直在看j2ee的书，觉得j2ee开发平台应该就可以做到soa得很多功能了，看来还需要加深理解
---------
              提到生命周期管理，人们大都会想到近期很热的信息生命周期管理。针对整合，IBM也提出了生命周期管理的概念。

　　在IBM看来，整合是分阶段、循序渐进、逐步实现的。如果把企业的所有经营活动看作是一个个服务，那么整合就是要将企业内外部的各种服务有机地联结起来。在做好整体规划后，企业可以首先从梳理某一个关键服务入手，实施独立的Web服务，接下来以SOA的思路，对具体的整合对象，按照建模(model)、装配(assemble)、部署(deploy)、管理(manage)四个阶段实现整合。这样由小及大，逐渐在企业业务中进行整合扩散。随着整合业务的逐渐增多，企业的IT整合计算平台会一步步完善，形成整个企业的IT转型，最终通过全面整合实现随需应变的企业IT架构。

　　任何大型IT项目都很难一次性完成。整合，这一几乎会涉及到企业或组织所有IT应用的大手笔项目也是如此。分阶段实施是自然的事情，但由此也带来了兼容的问题。后期的SOA项目能否与前期的兼容？ 
---------
建模建模，嗯，这个概念甄宽泛
---------

我：对照参赛说明书，写出任务要求及分工表

我+豆豆：1 开始上手开发工具的使用
目标：能使用Websphere Process Server中的开发工具进行题中要求功能的第一步系统层和第二步服务层的工作
2 阅读大赛给的TurboCRM和用友ERP的资料，光盘来后好好研究那个用友的案例。（TurboCRM和用友ERP的资料WB+文学可能也要看下，我初扫后建议下你们重点看的部分。这样大家效率高些）
P.S. IBM效率太低了，居然今天还没寄出光盘

WB+文学：1 题中要求功能：业务机会与销售订单整合 的实现流程图
2  业务分析文档的基本结构
3 信息智能服务社区。题中的描述很不清晰，可否查/问下“注册的机构也可以使用平台上已有的信息处理服务来创建自己的增值服务，包括将已有的服务组合成新的特色服务，新的服务也可以发布到平台上去”，说的是什么，新的特色服务可能是什么样的？
三个任务的重要性依次递减

此外，还有两件事
1 WB和豆豆找到的资料链接及简要介绍，贴到blog里面来
2 我们的blog分了文件夹：技术资料，竞赛日记，和进来讨论。进来讨论是关于我们团队管理，事情通知，互相监督的。写时记得分下目录。

恩，端午将至，大家记得吃粽子:)