评分项目链接	评审员	评审说明	评审员	评审说明	评审员	评审说明
SOA特点(40)	35	采用了SOMA方法学来建立服务模型,过程清晰，但对模型中如何满足KPI没有进行针对性分析。
创新性(30)	20	分析了医药行业状况，对题目中的部分流程提出了合理改进方案。
平台选择 (20)	10	采用了Modeler进行建模，但对其他环节没有阐述如何使用产品进行支持。
提案完整性 (10)	8	满足交付要求，但文档中有些地方内容空缺。
其他（最多加10分）	2	文档条理清晰，引用行业分析报告。
总分	75

遗憾啊，遗憾，居然没有进复赛啊，这下可以专心研究聚餐的事情，^_^。

走过的路和我们的期待

昨天，我们正式提交了我们的作品，听说北京昨天下了大雨，而此时此刻，我远在合肥。7月的校园，充满着夏末的翡翠的颜色。毕业班的同学，高呼着离别的曲调，走上自己的梦想。如果说，理想是一道光芒，那么我们只有奋力飞翔。

想起了一段句话：没有哪一座山，比人的攀登更高，没有哪一条路，比人的行走更长，没有哪一片天空，比人的视野更广阔。也许，在短短的初赛期间，我们只是向着自己的理想，迈进了小小的一步：正如，我们的名字：dribmsoa，dream realization ,必定还需要更多的付出和努力。但是，值得欣慰的是，我们走出了第一步，从0开始的第一步。不论结果如何，我们都应该为自己曾经付出的努力，为自己在这次比赛中的成长而感到欣慰！

我们的有3位组员在ibm的开发部门做过实习，有1位组员在ibm研究部门做过实习工作，应该说，这次比赛，对我们的引力十分大。大家从头到尾都热情饱满。回想我们每次开会时候的热切讨论，每次加班时候的全力投入，都让我感到十分激动，是这个小小的集体，给我了一份执着的力量。如此真实，如此向往。

我们期待着初赛结果的揭晓，期待着梦想成真，期待着我们的小组变得更好更强！同时，也期待着在后续比赛中，能够展现自己，锻炼自己，升华自己。为自我为IBM带来更多价值：）

 

mmhehe @  ustc

                                                

给组委会的信件

SOAContest，您好！

 

发信人: polaire (要看400个blog，疯了), 信区: IBMTech
标 题: 下面是还没有来得及整理，实在太累了
发信站: 水木社区 (Fri Jun 30 22:11:27 2006), 站内

已经收到了一下团队的交付件，但是我实在太累了，明天来加班整理~
看到这些名字的可以放心了

156 为所欲为
157 BlueOcean
158 天鹰
159 方正梦想
160 Winow
161 SOA之路
162 飞扬
......
215 十一号行星 *^_^*
216 F520
217 Logway
218 Pallas-Four
219 四结义
220 seven
221 Star-T
222 Pearl

^_^。项目综述已经完成草稿，组建文档在加紧完善中。river和dapeng的东西也就差不多了。pet和coonie的东西，今天晚上再refine一下吧。

这两天大家多碰头几次吧。把最后一些遗留问题解决了。我后天要去合肥了。估计提交作品和最后的润色工作要拜托大家啦～～～

 

SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。

服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。

图 3：SOA 层
500){this.resized=true;this.style.width=500;}">

对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的 SOA，你可能应该创建文档，由每个层相应的部分所组成。

这里是为你的 SOA 架构文档设计的模板：

1. 范围 <此架构适用于企业的哪个领域>
2. 操作系统层
   1. 打包的应用程序
   2. 自定义应用程序
   3. 架构决策
3. 企业组件层
   1. 企业组件支持的功能范围
   2. <这个企业组件支持业务领域、目标和过程>
   3. 关于控制的决策
      1. <作为这个客户端组织内部企业组件来选择某物的标准>
   4. 架构决策
4. 服务层
   1. 服务分类表
   2. 架构决策
5. 业务过程和合成层
   1. 业务过程可以表现为舞蹈编排（choreographies）
   2. 架构决策
      1. <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
6. 访问或者表现层
   1. <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
7. 集成层
   1. <包含 ESB 因素>
   1. <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
   2. 安全问题和决策
   3. 性能问题和决策
   4. 技术和标准的局限性以及决策
   5. 服务的监控和管理
      1. 描述和决策

现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。

层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP 打包应用程序，以及 较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。

层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。

层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。

层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。

层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA 将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。

……

我觉得我们需要提取的服务主要是业务逻辑服务
一、服务的类型
1． 连接服务 - 企业服务总线

2． 业务逻辑服务

a) 应用和信息访问服务 - 整合已有应用

提供与第三方应用程序（如 ERP 和 CRM）、大型机接口（如 CICS 和 iSeries）、自定义应用程序（通过消息传递、应用程序编程接口、数据处理程序之类的技术桥）和异构数据源（像 RDBMS、XML、非 RDBMS 数据源；例如，IMS、文本文件和内容管理系统）进行交互的能力。
此功能层提供到现有应用程序和数据的访问接口，同时支持数据库、消息传递系统及其他数据源的事务服务和连接服务。现有的基于主机的应用程序和企业数据都可以通过一组访问服务从 ESB 访问。这些访问服务提供遗留应用程序、预打包应用程序、企业数据存储（包括关系、分层结构和非传统、非结构化源，如 XML、文本和内容管理系统）和 ESB 之间的桥接功能。该层通过多个运行时解决方案模式（如面向 Web、通信级集成、消息传递和启用 Web service）提供大型机系统的集成。随着应用程序和数据实现演变为业务流程中更加灵活的参与者，其基础操作环境的增强功能将进一步得到开发利用。以下 是在这一层中隔离和启用的服务：
· 事件检测服务基于通过特定应用程序/数据源接口启用的事件框架提供事件通知服务。例如，在 CRM 系统创建新客户将生成一个事件，ESB 将该事件分发给这种事件类型的订户。
· On-ramp 服务允许应用程序集成模式（包括单向入站、请求-应答、恳求-应答消息模式）支持应用程序和数据包装程序功能（包括查询执行计划和数据检索），从而支持数据集 成。例如，如果业务流程中的一个步骤需要更新订单，一个带有订单数据的消息将通过 ESB 发送到大型机 CICS 应用程序，然后再从其返回一个确认。
b) 业务应用服务 - 整合新开发的应用

为集成组件提供 J2EE 运行时环境，这些组件使用 Java 编码作为自定义应用程序组件开发并在应用服务器环境中运行。这一层的服务可以为使用 J2EE、XML 和 Web 服务编程模型开发的自定义应用程序组件的管理提供框架和运行时操作环境。这些组件提供实现能满足当今业务环境需求的全新业务流程所需的新功能。这些组件在 WebSphere Integration Reference Architecture 中作为服务实现，允许通过新解决方案直接重用。业务应用程序服务包括传统编程人员重点用于构建灵活的可维护、可重用业务逻辑组件和运行时集成的功能，允许 进行更高级别的自动管理。此层中包含的服务功能有：
· 组件服务提供运行时容器管理服务，可以自动处理 J2EE 框架中的对象持久性、关系导航、对象查询和事务管理之类的问题。
· 核心服务作为 J2EE、XML、消息传递和 Web 服务编程模型的一部分提供运行时服务，如内存管理、对象实例化和池管理、性能管理和负载平衡、事件通知、可用性、目录，以及安全性。
· 接口服务提供与数据库、消息传递系统、管理框架和企业应用程序进行双向集成的服务。

c) 伙伴服务 － 整合客户和业务伙伴（B2C/B2B）
允许对商业合作伙伴通过不同传输和使用文档形式提供的服务端点进行集成。这一层的服务可以对具有外部合作伙伴和提供商的传统 B2B 合作伙伴集成解决方案提供支持。它是隔离了跨企业交互的体系结构的组件。这些服务提供高效实现 B2B 处理和交互所需的文档、协议和合作伙伴管理服务：
· 社区服务允许对交易中心的交易社区进行管理，并且允许合作伙伴进行自我管理。
· 文档服务支持诸如 RosettaNet、EDI、AS1/AS2 之类的业务协议，以及支持会话过程的相关状态管理。
· 协议服务提供传输级服务，包括身份验证、文档路由和用于自动化文档互换的边缘服务功能。

3． 控制服务
a) 信息服务－数据整合
b) 流程服务 - 流程整合
c) 交互服务 - 用户访问整合

4． 开发支持
5． 业务创新和优化
6． 管理支持

项目进行到现在，已经到了最关键的时刻了。看着我们6，7页的blog，一幕幕都展现在眼前。真的很开心和大家合作的过程。通过这个项目，感受到了

1）集体的智慧是大于个人智慧的简单叠加的。

2)  热情是尤为重要的因素，尤其对于这种自发的参与比赛的项目。朋友们，我们年轻，正是充满理想，并且充满了实现理想的可能性的时候，彭湃的热情会早就一个人的成功。有句话说，理性的人顺应世界，而狂热的人让世界顺应自己，所以，是狂热的人改变了世界。也许，这个项目，在我们的生命里程里只是小小的一幕，但是，如果大家能从中培养自己善于创新，充满热情的处事态度，相信，一定会给我们今后带来更多收获啊～

3）合作是制约性因素。大家都有热情了还不够。问题在于，我们的工作相互制约。需要协调。我觉得，基于个人的项目开发过程，是个分布式的算法～好似市场经济带来的便利一样，它使得我们的工作结果最终达到最好的平衡，而基于一个协调者的项目开发过程，是一个集中算法，它虽然可以节省很多开销，但是，未必会使得每个人都发挥最大能动性。那么如何平衡呢？这是个问题。

4）如何克服从众心里也是值得探讨的问题啊。有时候，少数不一定是错的哦。

5) 哈哈，总之，加油吧～～～～坚持到底，就是胜利～～～～～

peggy:

1.设计实施计划(Design Implementation Plan。

具体内容：包括以下几个方面内容的详细描述：(1)设计队伍的构成和分工; (2)需要用到的软硬件环境、平台和工具; (3)项目实施的任务分解和时间表(注意设计实施的时间不超过3个月); (4)设计风险分析; (5)设计验证和测试草案; (6)作品演示的初步方案和所需要的环境设备支持

2.整理IISC的介绍

3.在blog上发布soa大赛通知

4.项目综述.

具体内容: 项目综述不超过1000字（或类似篇幅英文）。应当明确简要说明参赛作品的题目，总体设计思路等要点，以及SOA在项目中的体现。特别要突出作品的创新点和技术要点；以及作品可能产生的市场影响等。

 

coolriver:

1.  服务模型分析设计 (Service Model Specification Documentation)，字数不限,应当至少包括以下几个方面的详细描述:(a) 服务发现及其依据;(b)服务规约;(c)服务实现分析

connie：

1.系统架构设计 (System Architecture Documentation).

具体内容：字数不限，应当至少包括以下几个方面内容的详细描述：(a)用户需求描述(需求概述、业务环境描述、IT环境描述); (b)用例模型分析; (c)数据模型分析; (d)关键技术架构决策; (e)系统架构分析

2.文章整理和最后提交工作，统一的文档格式，内容检查

dahong：

1. 增加我们的友情链接

2.和river一起完成服务模型分析设计

3.和connie一起完成系统架构设计

4.和mmhehe一起完成组件设计

mmhehe:

1. 业务模型分析设计 (Business Model Specification Documentation).

具体内容: 字数不限,应当至少包括以下几个方面的详细描述,可以根据理解进行自由扩充: (a)业务模型分析与展望 (b)业务模型对IT系统的挑战

2. 组件设计(Component Design Document)，字数不限。

具体内容：应当至少包括以下几个方面内容的详细描述：(a)设计的总体功能模块划分;(b)各个组件或者设计层次的功能描述，接口定义; (c)具体实现机制的分析; (d)主要系统结构图和数据流程