首先来了解一下什么是Profile，说白了，它就是用来规约服务的，它至少包括了所有服务之间默守的一种契约；又或者比作文档模版，具体的内容（服务本身）规约并不关心，它所关心的是使服务的表现形式是否能体现同一标准性，但Profile本身决不仅仅限于规约每个服务本身，它还有更大的用处，在了解它之前，既然是定义服务的，那么不妨拿它和WSDL作比较，应该会更加清楚它的产生的渊源、作用和意义之区别所在。

先来看WSDL中的元素定义和关系图

稍微了解WSDL的人都应该知道它是用来定义某一个具体服务的，包括它的位置、提供了哪些服务访问点、每个服务访问点的所绑定的通讯协议和数据格式规范、传递消息的组成形式及使用的数据类型等信息，仔细想来这些内容是定义在每个服务的设计层次上的，它关心的每个服务本身而不是服务之间的相互协作形成的软件系统架构，况且WSDL协议是针对Web Service这种服务实现形式定义的，这在SOA中并不具有通用性。也就是说WSDL所关注的粒度相对于SOA中的Profile是太细节了，WSDL关心的是Web Service的规范定义，Profile则更多的关心多个服务的划分、协作、连接等问题。可以说两者并不矛盾，因为它们各自定义粒度不同，所关心的内容也不同，那么这样一个Profile到底是什么样的呢？来看下图

这里先把关注点放在图的左下方的Specification部分，它应该就是我们所熟知的WSDL协议所规定内容（但不限于它，因为WSDL是针对Web Service而SOA并不规定具体的服务形式），注意这里Specification具有一个属性是published，这相似于制定说这个服务是否被发布到一个制定的服务库中，如果针对Web Service就是指是否发布到UDDI中了。Specification指明了包含哪些Operation，这与WSDL中每个PortType下可以包含多个Operation相类似，但应该注意在Profile并没有如WSDL中Binding的内容，因为它已经属于每个Service的设计细节与SOA架构无关。同时也应该注意的是在Profile中虽然也指定了Message，但并没有如WSDL中详细规定每个Message中包含哪些数据以及数据的格式，这个原因同样也是因为SOA并不关心这样的Service设计细节，Message与Attachment都只具有一个属性就是编码方式，一般来讲Attachment很少用到，只有在需要至少两种编码方式的时候才会被使用。在Profile中左下这些内容就已经涵盖了WSDL的定义范围，当然并没有WSDL规定的那么细节，那么右上方的内容是什么呢？

右上方的Profile内容才是真正体现SOA的地方，它关心的是系统架构而不是每个服务的接口设计细节。对他们的理解要借助于SCA才能更好的将如此抽象的内容理解清楚，这里先简要介绍一下：Service以端口的形式制定了服务本身，至于如何调用Service是Specification指定的；Provider是服务提供者，它作为类实体提供一个或多个服务，它具有属性指定允许的平台绑定机制和服务提供者自身位置，我们可以把它想象成为提供某种服务的集合（例如在服务模型中定义的信息服务、事件服务、传输服务、外部服务、系统管理服务等）；Partition是服务划分，它用来代表系统的逻辑/物理边界，一个Partition中可以包含多个Provider，当然站在更高的层次上来看这个问题，其实每个Partition都可以成为更高层的独立服务；Gateway是服务网关，它用来表示每个Partition中哪些服务是可以对外的，还是站在更高的层次上讲服务网关不仅屏蔽了底层不需要了解的细节，同时如果Partition被提升为独立服务，那么一个Gateway看起来就像一个Service了，而恰巧Service和Gateway的元类型都是Port，且Sepcification这个接口是可以通用与Service和Gateway的；Consumer是服务消费者，它可以是一个服务也可是其他的，一般来讲Consumer是高层次的概念，很少在这个层面给出很好的比喻；Connector是连接器，它用来指定服务之间的通讯绑定或服务与客户之间的服务绑定，属性binding指定服务产生时的平台绑定机制；Collaboration是协作，它指定一个服务的实现作为另一个服务的协作方式，换句话说就是使用了一种服务协作作为服务的行为，注意Collaboration仅仅限于Providers之间。

解释了这么多，相信大家已经有些概念了，不过这组概念还是相当难以理解，它们都属于原类型（stereotype），通用地合理解决关注点是是它们的意义，如果更加细节的了解，马上要介绍SCA和SDO。现在的理解程度应该是这样的：

1、Profile关心的是服务之间的关系，即系统架构，而不是每个服务的设计和实现机制；

2、Profile涵盖了以前WSDL中的内容，但由于其所关心的粒度不同，所以两者并不存在冲突反而是相辅相成的；

3、把Profile简单的看成服务规约是错误的，它所处的角度是系统架构师而不是设计实现人员；

未完待续……

SCA是一种新的与语言无关的服务组件编程模型，为所有服务组件提供统一的调用方式，使得客户可以把不同的组件类型采用同一标准进行封装。SCA的前身是WSIF（Web Service Invocation Framework），当然WSIF是Web Service领域的一个规范仅提供基于Java API调用各种服务的能力，没有形成架构模型，而SCA是在它的基础之上放宽了对实现细节的定义同时将关注点提升到系统架构层次。下图展示了SCA服务组件的基本结构，它是SCA的基本组成元素和基本构建单位，如图所示SCA服务组件的主要接口规范是基于WSDL的单同时部分服务组件也提供了Java接口，这样便于服务组件的客户端选择，服务组件提供的调用入口成为Interface，需要调用的出口叫做Reference。

SCA服务组件与传统组件的主要区别在于：

1． 服务组件往往是粗粒度的，而传统组件以细粒度居多。

2． 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API且大部分是二进制形式出现。

3． 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。

4． 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。

我们可以看到这个服务组件其实就是我们在Profile中提到的Service和Specification等，当然这里隐含了Message的定义，那就会想到这样一个问题——Provider或者Partition在哪里呢？在SCA中是不是有所体现呢？是的，在SCA中我们确实可以找到Provider和Partition原型所对应的技术模型——服务模块（Module）。

服务模块是由一个或多个具有内在联系的服务组件构成的，是SCA中的运行单位。服务模块包含多个服务组件，它体现了一种逻辑/物理上的组件服务分类界定，同时可以通过独立的地址进行访问，服务组件之间的调用关系在WebSphere Integration Developer V6.0中可以通过Interface和Reference的连线来声明不需要写任何代码。

那么多个服务模块之间如何调用呢？这就需要通过导入导出功能——导入的作用是使得模块中的服务组件可以调用模块外部的服务，导出的作用是使得模块外部的应用可以调用模块内部的服务组件，在IBM用于部署支持SOA的WebSphere Process Server V6.0中，为导入导出各自指定了包括目标服务和原服务的位置信息、调用方式等在内绑定信息，涉及JMS绑定、Web Service绑定、SCA绑定、无状态会话BEAN绑定四种绑定方式，对于同为SCA模块之间使用SCA绑定是最方便的，其他情况下可以选择其他绑定方式。

在SCA体系中还包括可以被多个模块共享的共享库（Library），它与服务模块不同的地方在于其不包含任何服务组件，这里不详细介绍了。

我们已经了解到了服务模块之间如何调用，但是必然还会涉及到与原有系统已经存在部分的沟通情况，例如外部Java代码、JSP/Servlet调用怎么样使用某个服务模块呢？模块中的服务组件不能直接被他们使用，只能通过Standalone Reference，它是一个只提供Reference不提功过Interface的端点，然后通过对Reference的使用就能调用它所连接的服务组件了，具体示例代码见IBM Developers网站。

这样就比较详细的了解了SCA，但是还有几个细节问题需要考量：1、服务组件的同/异步调用；2、服务组件客户端调用方式；3、异构数据源的数据获取问题。

对于第一个问题，显然在粗粒度的组件服务之间绝大多数情况都应该使用异步调用方式，因为从调用者角度来讲他可能面对的是一个需要长时间响应的事务，同时只有异步调用才更加良好地模拟真实环境，想想我们现实生活就明白了。SCA中提供了单向调用、延迟响应、请求回调三种异步调用方式。个人认为单向调用方式存在的情况并不多，而延迟响应显然对延迟长短的界定需要很强的领域知识和系统观念比较难以控制，真正符合我们各种情况下需要的就是请求回调这种异步方式了，这与许多编程语言中的回调机制相同，即通过将调用者接口传送给被调用者，期待事务完成之后通过事件触发由被调用者主动向调用者发送请求，这也就是所谓的回调。

对于第二个问题，客户端存在静态/动态两种调用方式，如果采用服务组件的WSDL接口进行调用就必须采用动态方式，而采用Java接口则两种都可以使用，显然采用动态方式更加灵活，但是它的Invoke在编译期是无法被检验的，在动态调用方式下所有参数都是通过DataObject方式进行传输的，这就涉及到了下面要谈的异构数据源的问题。

如何通过统一的方式来访问异构数据源，简化J2EE数据编程模型是一直以来困扰设计人员的问题，太多的底层数据访问细节让编程、调试和配置困难重重。SDO框架支持并集成XML，希望通过这种可自定义的语言标准来拟合各种业务数据并实现他们之间的无缝转化。SDO的前身叫做WDO，它包括三个概念上的部分：SDO客户机、Data中介服务、数据源，其中最重要的就是Data中介服务，简称DMS。以上三个仅仅是概念上的东西，不对应于任何一个具体的Java接口，而数据对象、数据图、变更摘要、属性类型等则分别对应了commonj.sdo.DataGraph、commonj.sdo.ChangeSummary、commonj.sdo.DataObject、commonj.sdo.Property，这些都在SDO1.0中提供了支持。数据对象就是结构话数据的SDO表示，它是通用的，SDO的客户机不需要了解它的细节，数据对象在属性中保存它们的数据，而多个数据对象按照层次就构成了数据图，同样数据图中也包含了变更摘要。数据图其实就是数据对象树的容器，SDO 客户机可以遍历数据图，读取和修改数据图中的数据对象，SDO 客户机与 DMS 和数据源没有连接，所以 SDO 客户机看到的只有数据图。当然数据图是在内存中的存在的，真正保留在磁盘或网络上传输的是序列化之后的XML文件，而数据图模型也就可以看作所谓的XML Schema，具体的程序例子参看IBM Developers网站。

有了以上这些，其实从数据访问层到组件构建层都已经很清楚了，加上良好的业务、服务模型设计和系统架构设计，那么真正实现SOA部署就不是什么难事了。

    感觉大家对SOA中的服务规约理解的都不是太好，这其中涉及到的问题很多，尤其是在服务和组件具体设计和实现的时候，下面这一周的时间我的计划是重点看这部分的内容，然后把心得发布到Blog上来并和大家一起讨论分享，晚上看了IBM的毛新生先生的视频讲座，感觉在具体实施部署的时候SCA（Service Component Architecture）和SDO（Service Data Objects）是至关重要的，因为它们不仅是行业公认的SOA设计标准，而且只要服务符合SCA规范、数据源符合SDO规范就可以直接挂接在ESB总线上。

WebSphere Business Modeler Advanced 6.0

WebSphere Integration Developer 6.0

WebSphere ESB V6.0.1

WebSphere Process Server 6.0

WebSphere Business Monitor 6.0

它们共同构成了IBM WBI（WebSphere Business Intergration）的产品系列，在这里可以找到这个产品系列的全部中文帮助文档。

我目前找到的东西就这么多，相信会对大家有些帮助，下面说说我的工作计划：

2006年7月12日之前给出自己关于服务规约的理解和大家讨论，之后利用一天的时间进行修改扩充，然后开始针对SCA和SDO进行进一步的理解和实验，在7月14日之前给出结论。

    以上是IBM公司公布的2006年“IBM 杯”高校 SOA 创新应用大赛的复赛名单，很高兴我们也能成为其中一员，但是发现自己在有些方面还是有很多差距的，应该更加努力的学习，虽然期望并一直朝着最好的结果努力，但过程中的收获才是最重要的。

作为教师，我一直苦恼于如何提高学生们的应用创新能力，特别是培养驾驭技术、超越技术的能力。IBM的SOA应用创新大赛给我们提供了一个很好的机会，在接近真实应用环境的大赛题目中，我们需要考虑很多超出技术范围的内容，从市场营销的服务过程、到核心业务的管理流程，从一系列新颖的IT技术概念、到我们不曾深究的企业管理理念，参加比赛的过程就是我们不断超越自我的过程。“他山之石、可以攻玉”，在和同学们一次次讨论的过程中，在不断充实丰富我们的团队Blog的过程中，我好像回到了曾经的学生时代，心中充满梦想和激情，在交流和协作中去克服一个又一个困难。两个月的时间的确很短，但是对51Start团队的每一个成员来说，这必将是一段让我们经久难忘的经历！

我们正处在一个不断变革和创新的时代，学习是认知世界的过程，而实践则是改造世界的过程，这个时代要求我们不断的在实践中学习、在学习中实践。IT技术的蓬勃发展和广泛应用给我们提供了一片无比广袤的天空，让我们的智慧和激情自由的飞翔！51Start是我们又一次启程的地方，也许前方充满荆棘和坎坷，但是勇敢的成长，是我们心甘情愿的选择！

二十一世纪是崇尚效率和创新的时代，对任何一个企业而言，提升核心竞争力是保持企业长久发展的关键所在。IT技术的精准应用对企业的健康成长有着举足轻重的作用，所谓精准应用就是指唯有提升企业价值产生效率、提高企业核心竞争力的IT技术才是最重要的，我曾经考察过很多企业的信息化历程，投入大量成本换来的IT系统平台并未给企业发展带来质的飞跃，究其原因，就是技术和业务的脱离、服务与价值的脱离。

对我来说，SOA是一个全新的概念，但是当我逐步深入了解它的概念后，我却觉得SOA竟然蕴含着那么多我早已熟知的企管理念。SOA让企业从繁琐复杂的IT技术中摆脱出来，能够站在业务和服务的高度来审视IT系统的建设，不去做技术的奴隶，而是成为IT的主人！

我很幸运能够加入这个团队，很幸运的和老麦、大伟、维维、史老师共同学习成长，每一次例会都能给我带来头脑风暴，每一次交流和讨论都能让我豁然开朗。我很惊讶他们作为IT人才对企管理念的把握，我更敬佩他们的勤奋和团结。51Start，是我们共同的团队，是我们梦想和激情飞扬的家园！

1.1          参赛历程

4.17 我和张维在校园网上看到IBM举办中国高校SOA应用大赛的消息；

4.23 由史广顺老师、卞晓青博士和我、张维、宫大伟组成的参赛团队正式成立；

4.24 团队博客（http://nksoateam.blogbus.com）创立，召开第一次小组会议；

5.10 前期调研工作基本结束，团队成员储备和查看了大量SOA背景资料；

5.14 团队名称正式确定，51START蕴涵了我们协作、奋斗、启航的美好愿望；

5.31 对凤凰公司业务流程的讨论基本结束，成员分工开始文档书写工作；

6.15 各份文档初稿基本完成，展开激烈讨论；

6.23－6.29 进入紧张的作品修改和完善阶段，史老师赴江苏出差，但小组成员坚持每天通过电子邮件交流讨论最新情况，作品质量有了大幅提升；

6.30 11:30 51START团队参赛作品正式提交，初赛工作告一段落；虽然是否进入复赛尚不得而知，但我们对于SOA理念的追寻和实践不会停止。

1.2          喜悦和收获

在两个半月的参赛时间里，我们付出了艰辛的努力，也收获了许多喜悦：

首先也是最重要的，我们真正体现了51START这个队名的深刻含义，5名成员协同工作、亲密无间。大家抛开了各自的身份差别，完全融合为一个统一的整体，我们为了一个目标共同努力。在参赛过程中，我们有过分歧、有过激烈的争论、也有过磨合的痛苦，但我们都坚持了下来，不论结果如何，起码我们作为一个TEAM战斗过！

第二个收获是我们突破了各自的专业限制，体会到了多学科交叉互助的优势，更增强了IT技术与企业应用结合的概念。在51START团队每周的工作会议上，我们开辟了“头脑风暴”环节，卞晓青会选择与项目相关的管理领域背景知识介绍给我们，而几位计算机专业的同学也站在技术的立场提出对企业整合IT资源的看法。通过不断的交流我们逐渐明白：在真实的企业应用环境中，任何一个单独学科的知识都不能独立和完整的解决应用问题，只有把技术和管理知识有效的结合起来，再辅以对应用的深刻理解，才能找到合理和长效的解决方案。这点正是IBM推广和普及SOA的主题思想。

第三个收获是我们对IBM和他为企业应用提供的一系列思想、方法、技术和工具有了全面的了解。在参赛之前，团队中只有张维参加过IBM组织的高校大赛，其他成员IBM接触甚少。通过这次参赛，我们忽然发现IBM在企业应用特别是系统和软件开发方面有许多科学和完整的思想方法。结合参赛交付件的书写，我们使用和熟悉了许多行之有效的软件设计、架构和实现工具。相信这些思想和工具将在51START成员未来的科研工作中发挥重要的作用。

今年后半年我将继续在南开大学开始我的博士阶段学习，希望能以这次的参赛为契机，在今后的科研工作中把对SOA的研究作为一个重要的方向进行更加深入和细致的工作。

       这次比赛的过程中学到了松耦合、自组织、基于消息的SOA模型应该是什么样的，应该怎样去构造，惊叹于IBM提供的各种大而全的工具，虽然上手的时候还是有些生疏，但是在IBM Developers网站的帮助下还是很快掌握了他们，也更多地认识到了自己的不足和差距，真的希望能有机会进入决赛现场去IBM看看，和那里的工程师交流，迅速提高自己。嗯，结果是要靠我们大家共同的努力的，庆幸自己是这样一支团结上进的团队中的成员。日后合作的机会还会有很多很多，珍惜现在，把握未来！兄弟们加油！！！

       SOA体现的理念是松耦合、自组织，而我们的团队恰恰是紧耦合、互相依赖的，史老师的组织和协调、卞师兄对于企业管理的理解、杨师兄对于系统架构的经验以及大伟那深入扎实的技术功底都让我感到震撼，每个人都有自己的特长并毫无保留的发挥着它，最终我们实现了51START的精神，我想我们团队本身就是对51START的最好诠释吧。随着社会的发展和分工的不断细化，团队合作成为了每个人必须具备的能力，与人合作其实不是那么简单，但当所有人拥有同一个目标和愿望的时候它又是显得那么顺理成章。比赛还没有结束，工作也依然每天在继续，但我想这段时间以来带给我的感动和震撼远远超过了其间所学到的知识，期待我们的合作能继续，不仅是这次比赛，而是日后一起面对更多……更多……

--6月13日

1.会议时间

6月13日，上午9：00~12：30

2.会议地点

实验室会议室

3.参加者

wordinsand，nkbxq，麦卡，SeraphZhang，flyingdonkeycn

4.会议主要内容

经过了这么长时间的积累，终于要讲自己的想法落到纸面上了。这次会议的主要议题是对每个人的模块进行分析。

wordinsand老师负责服务模型部分。

nkbxq负责业务模型部分。

麦卡负责系统架构部分。

SeraphZhang负责解释SOA思想和方法在本系统开发中的应用。

flyingdonkeycn负责组建设计部分。

在系统架构中，需要根据用户需求，进行需求跃升；建立用例模型，数据模型等；根据现有IT情况的原则。针对企业中的部门流程进行分析，根据现有IT环境进行分析。由“良好的需求分析”、“ESB设计”、“服务组件划分”和“系统维护与升级”几个方面入手，进行架构分析。

在组件设计中，需要明确的定义方法和接口，并采用UML类图等方式进行描述。组件的功能描述和接口定义一定要明确。

在业务模型描述中，需要考虑企业的层次结构，即“外部营销”和“内部约束”。在分析上可以采用PEST方法，体现业务中的“依赖性”和“规划性”。

各位，要开始加油了哦~~~