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

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

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

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

mmhehe @  ustc

SOAContest，您好！

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

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

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

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

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

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

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)主要系统结构图和数据流程