1、基于SOA架构的设计规范1 简介1.1 目的本文的目的是对”北航数字校园项目”各应用系统设计的目标、范围和要求进行说明，帮助开发商明确所需进行的工作和对工作成果的要求，并作为对开发商工作成果进行评价的依据。1.2 预期读者 架构设计师、系统设计人员北航的架构设计师、维护设计人员根据学校的业务要求和技术状况制定此设计规范。 开发商“北航数字校园项目” 的系统开发商根据本文档描述的标准规范要求，进行相关系统的设计和开发。1.3 适用范围本文档描述的内容适用于“北航数字校园项目”中应用系统的设计和开发。1.4 规范要求及约束 各参与的软件供应商，都应明确本规范的约束，并据此指导进行分系统工程的统一设
2、计和开发，完成本规范中规定的相关内容。 分系统工程中最终要提交的服务组件都必须经过严格的集成测试、审核和验收，然后提交。 如对本规范有任何技术上的建议和分系统工程个性化的需要，请将建议和需要以文字的形式提交，经过讨论、评审后修订、变更本规范，协调各分系统工程的开发，任何开发商不得单独修改本规范内容，并加以实施。2 架构设计的目标“北航数字校园项目”，按照统一化建设的要求进行总体设计，实现一个架构一致、管理统一、维护统一的“一体化的信息系统”。为了实现这一目标，应当采取面向服务的构件化策略。也就是说，对应用系统进行总体规划，对业务需求进行全面统一的分析，对数据和功能进行统一的分层规划，将整个系统
3、划分为不同层次的构件，构件的内部包含自用的数据和功能，构件之间通过标准的接口进行交互。按照这种策略，应用系统可以实现最小化，可以按照需求组合各个构件，充分共享统一的可重用服务组件。数据和功能的冗余达到最低，应用系统的维护和实施的工作量最小，满足”北航数字校园项目”“总体设计、分步实施”的基本建设路线。这种策略的关键在于总体框架的设计要充分和科学合理，特别是可重用服务组件的设计，必须保证：无论需求如何变化，应用核心不会变化，仅是外围组件的功能和组合方式在发生变化。3 可重用服务组件的技术规范创建可重用服务组件的原则为： 按照项目组总体设计要求的分系统工程承担开发并提供其他分系统工程应用的组件必须
4、创建为服务组件。 各分系统工程开发商，在系统内部，应本着提高可重用性的设计原则，尽量创建可重用服务组件，并按服务要求进行说明和发布。3.1 对服务组件的要求 开发成服务组件的应用系统访问接口，根据系统访问的频度、数据量的大小可以封装成webservice、EJB、JMS等的接口，这种类型的接口才能够注册到服务平台上，并提供给其它的应用系统使用； 服务集成平台能依据系统自己的配置信息将服务组件产生的异常或者错误信息格式化成标准的XML格式消息，并且将该XML消息发送给等待同步响应的服务组件使用者； 对于服务组件使用过程中应用系统需要传输的大数据块可以采用SOAP with attachments
5、消息类型进行传递，因此服务组件的提供者和服务组件的使用者都应该考虑到需要实现大数据块转换成SOAP协议的attachments和从attachments还原回大数据块的功能；3.2 可重用服务组件的规范 分系统工程在开发过程中，只能将提供数据层面复用的组件开发成可复用的服务组件，对于非数据层面性质的组件（如：界面展示组件）不应开发成服务组件进行复用； 开发成服务组件进行复用的组件必须进行web service、EJB等方式的封装，才能注册和发布到服务平台上； 分系统工程的每个功能模块可能由一个或多个业务单元组成，这些业务单元通过一定的业务流程组成该功能模块，在开发过程中分系统工程开发者应尽可能
6、的分离出每个功能模块中存在复用情况的业务单元，并将其开发成服务组件注册到服务平台中，以便其它分系统工程进行复用； 分系统工程只能将服务组件注册到服务平台上中，且只能允许服务平台调用，分系统工程应该提供服务组件的安全控制，提供用户名/口令的安全审核方式，并在注册组件是提供给服务平台； 分系统工程在开发过程中，如需要使用其它分系统工程提供的服务组件时应调用服务平台上注册的服务组件，不允许通过其它的途径直接或间接的调用其它分系统工程对外公开的服务组件，且作为服务组件的使用者在调用服务组件时应该提供调用的用户名和密码； 分系统工程对外提供的每个服务组件应该有自己的事务控制机制，即每个服务组件作为一个完
7、整的事务单元对外提供服务，由于服务组件使用者传入参数原因或者组件内部原因导致的服务组件抛出异常、终止退出的，服务组件自身应该能回滚事务，保证数据的完整性； 作为服务组件的提供者应将服务组件中需要抛出的异常抛出到服务平台，由服务平台根据配置信息将异常信息格式化后发送给服务组件的使用者；3.3 可重用服务组件的注册和管理规范服务平台提供基于Web的控制台，该控制台基于轻量级的WebLogic门户技术，能够提供所有的配置和监控功能。通过这个控制台，能够查看所有服务的运行状况、统计信息及服务水平告警信息，分系统工程开发的服务组件的注册和管理都应通过服务平台的Web控制台完成。服务组件的注册规范： 分系
8、统工程开发的服务组件，应填写“服务组件登记表”（下文）提供者填写服务组件的提供者名称中文名称填写服务组件的中文名称接口名称填写服务组件的方法名称版本填写服务组件的版本号，用于跟踪服务组件的修改安全填写服务组件的访问用户名和密码接口的访问URL填写服务组件调用位置的URL是否异步填写服务组件是否为异步调用（异步/同步）输入填写服务组件的调用参数输出填写调用服务组件时，服务组件在后台的输出信息返回值填写服务组件的返回结果说明描述填写服务组件的功能描述、说明；XML格式填写服务组件的wsdl描述文件片断使用者填写该服务组件的使用者，在服务组件登记时服务组件提供者可以不填写本栏，由服务使用者填写 服务
9、组件的提供者在注册服务组件时应该按照“3.5 服务组件的命名规范”进行服务组件的命名和注册到对应的名称空间中，不应自行改变命名空间，从而导致服务组件管理的混乱； 服务组件在提交注册前应进行完整的测试，以及相应的输入、输出数据的格式检查，确认无误后提交注册； 服务组件在提交注册后，服务组件的提供者不应再对该服务组件进行任何的改动和变更，如需要改动和变更需要依据“服务组件登记表”（上文）中使用者的记录信息，统一通知所有的使用者，并得到改动方案确认和认可方能进行更改，服务组件更改后应及时修改该服务组件的“服务组件登记表”；3.4 可重用服务组件的使用规范： 服务组件在提交注册后，服务组件的服务组件的
10、使用者即可通过“服务组件注册登记表”中的登记信息使用，服务组件的使用过程中需要的任何信息都以“服务组件注册登记表”为准； 服务组件的使用者应该及时在“服务组件注册登记表”中的使用者栏目中登记使用者名称，以便在服务组件改动时进行跟踪管理和测试、检查等； 服务组件的使用者如为异步调用，应登记自己的回调服务组件接口，用于进行交互服务；3.5 可重用服务组件返回数据格式的规范 服务组件使用者的传入参数以及服务组件返回结果不应含有过分复杂的数据结构（如，返回结果为一个对象类型的XML数据体，但该对象的某一个属性值又是一个小的对象）； 服务组件的调用参数传递格式（重点看结构，下文中的USER_ID和MEN
11、U_ID等是参数名称）如下： string string string 100 100 服务组件返回值传递格式（重点看结构）如下：ns:ArrayOfESTUDENT 183divStudent11433.6 面向采集的数据服务组件命名规范服务组件命名应该以直观明了的方式进行，让服务组件的使用者能够顾名思义的识别服务组件的名称，如“学生基础信息”服务组件按照拼音第一个字母命名为“XSjcxx”；学籍服务组件存储命名空间为“XJ”3.7 可重用服务组件说明的规范可重用服务组件的描述分为接口和实现两个部分，应该满足以下的基本原则：1. 接口尽可能使用业界具有规范性和/或普遍适应性的标准；2. 实现
12、应该完全遵循接口的规范，并能提供多种可用的实现供选择。可重用服务组件的描述划分为以下的几个部分：1. 服务组件描述：描述按照标准的格式明确： 服务组件的名称（中/英文）。需要遵循服务组件的命名规范 服务组件的编号。编号的规则为：C*#，其中C表示Common（公共），*可为字母F/G/D中的一个（表示服务组件所处的专业/通用/领域的分层），#为3位的序列号，不足位数在左边补零（注意可重用服务组件的序列号是局唯一的）。 基础服务组件，这里特指ALDSP生成的基础数据服务类组件 通用服务组件，例如数据格式转换，数据类型转换，文件读写等服务组件，日志，异常等。 领域类组件，服务于某业务应用，如测井曲
13、线的数据处理 服务组件类别。可为字母F/G/D中的一个（表示服务组件所处的基础/通用/领域的分层）。 服务组件提供方式。表示服务组件的提供方式，一般来说可以是以下各种中的一种或多种的组合： 规范（Speciafication）：表示对接口和实现机制的描述，以及对实现的规范和指导性原则。据此可以设计出符合一定标准的可重用服务组件接口和实现。 Java/C/C+/其他库（Java/C/C+/Misc Library）：包含完整的特定语言实现的库，以Java库为例，应包含完整的可运行的Java程序（JAR文件）、标准Java文档（javadoc）、完整的源代码包（可选）、创建脚本（可选）等。 服务（
14、Service）：可重用服务组件提供为一种服务，应包含服务的描述文档、使用文档（用户手册和程序员指南，如果需要的话）等。 其他（Misc）：其他类型。 服务组件功能描述：简要描述可重用服务组件的功能、范围，必要时提供完整的需求文档。 其他要说明的问题。2. 接口描述：描述可重用服务组件提供的接口信息。3. 接口用法：描述应用软件使用可重用服务组件的方法和注意事项，规范化可重用服务组件被使用的方式。4. 附件和参考资料：引用重要的附件和参考资料。4 服务设计流程4.1 什么是服务设计流程?给一个特定的整合用例，解决方案设计者将首先中止用例到一组服务，他们一起来迎合需求。然后服务设计流程是一组行动
15、，他们将为每个服务设计。服务可以或不可以存取任何远程系统，例如数据转换可以作为一个可重用的服务来实现是可行的。4.2 什么是服务设计流程的输入?典型的，为任何给定的整合用例所作的服务设计流程的输入如下所示。请注意尽管时间表，资源约束和价值约束能影响流程，他们不包含在这部分中，这部分集中讨论设计流程的技术方面。 功能需求 这将包括数据输入，数据输出和用例需求的行为，特别根据企业中任何受影响的状态更新。所有被包含的系统将被列出，还有他们之间所有被要求的交互。服务所需要的有条件逻辑和任何其他的逻辑流也是功能需求的一部分。理想的，功能需求将包括任何所需管理的描述。 非功能需求 这将包括所期望的测定体积
16、的，需要的响应时间，可用的需求，安全需求和服务需求的质量。 最佳实践和设计模式 这将包括用WLI8.1产生的任何类型的最佳实践和设计模式，包括文档。 解决整合问题的前车之鉴 这包括设计人员的经验集合。 现存解决方案库 这将包括任何现存的解决方案和服务的文档。服务设计流程的输入当为用例看一个非功能的需求，为需求考虑以下SMART标准是有用的： 具体的：不模糊，用一致的术语，简单并且在内容适当的水平。可测量的：验证这个需求已经被满足是可能的。什么测试必需被执行，或什么标准必需被迎合来核实需求被迎合？ 可得到的：典型可行的。什么是你的需求可行性的专业判断？可实现的：现实的，特定的资源。你有雇员吗？你
17、有技术吗？你对所需的开发架构有存取吗？你对所需的运行时架构有存取吗？你有充足的时间吗？可追踪的：通过对系列设计，实现和测试的详述从概念链接。高层次的设计构架更进一步的细节非功能需求应该执行SMART标准。经常是这样的情况，你有许多需求相互矛盾，或者那被描述的太一般来保证成功的实现。4.3 服务设计时的步骤是什么？根据特定服务的需要，服务设计流程能被分解为下列行为：1. 解决通信和连接问题 这定义了已发布服务接口，任何从服务消费者到SOA平台的连接，任何从SOA平台到BES的连接，还有SOA平台内部组件间的连接。2. 解决数据处理问题 一旦通信和连接问题已经被确定，这将提供需要通过数据翻译和转换
18、来解决的数据处理需求。3. 设计流程 这讲述了有关同类逻辑，任何步骤顺序，有条件的逻辑和任何其他执行规则的设计。图 1: 整合服务设计重复流程我们推荐按顺序执行这些步骤，因为通信问题有充分的理由表面化数据处理和流程设计的需求，并且数据处理问题有充分的理由表面化流程设计的需求。早先观察连接需求的另一个原因是有时候它将为得到或者开发展现一个需求，然后为新架构接受测试例如控制或者适配器。这必须尽快被确认来使风险管理能够有希望的减少服务传送时间。如果有不少人投入到服务的设计中，则在这个流程里可能得到平行系统，但是事实上任何阶段的需求将由其他需要入帐的活动产生。上面的流被重复的显示，因为它看完数据处理问
19、题之后，再次访问通信问题通常是值得的，并且流程设计能够影响为通信和数据处理所作的决定，也在这两个领域介绍了新的需求。在没有验证接口文档和标记而进入开发已经是一个非常大的项目风险，因为这些适合多流程的第一步。高水平设计向导详细内容我们推荐这些步骤按顺序执行。通信问题有充分的理由可以表面化需求，适合数据处理和流程设计，并且数据处理问题有充分的理由表面化需求来适合流程设计。这也确定了任何组件需要在项目早期产生和发展。4.4 一个服务的主要特点是什么?假设一个端到端的整合用例，这样一个用例可能被分成更多的服务，每个都需要适当的设计。这个端到端的服务和任何组件服务都是服务。一个服务将有一定数量的特点，这
20、对服务的设计将是十分重要的。对于一个特定服务的设计者它将是非常重要的，能在这些区域里分类这些服务的特点。首先，基于它的设计，一个服务有一定数量的属性: 1. 复杂性: 基本的被定义为一个对其他组件进行一次调用的服务 合成的被定义为一个对其他组件进行多于一次的服务2. 调用范例： 同步的当服务完成时这种服务的用户将阻塞来等待回应 异步的当服务完成时这种服务的用户将不阻塞来等待回应 混合的这将是一个同步部分接着异步部分的服务.3. 交换范例： 双路需求/应答 单路激活和忘记上面描述了服务属性，它被服务设计者决定，服务有很多特点来自非功能需求：4. 体积： 高每秒超过100个服务调用 中每秒1到10
21、0个服务调用之间 低每秒少于一个服务调用5. QOS（可靠性）： 至多一次这种服务保证只执行一次。这典型返回给用户一个失败，为他们处理错误/重试。 至少一次这种服务保证至少执行一次，因此允许复制的可能性 确实一次（也叫一次且仅此一次）这种服务保证执行一次且仅此一次。这典型用于确认，重试和复制探测和消除。在此处服务包含更新多个系统，关于更新的次数我们有两种选择。 他们都能够在同一分布式事务中被更新所有或都不 他们相互能够独立更新JMS存取和促进6. 持久性： 非常短0.1到10秒之间 短1秒到60秒之间 中等30秒到1小时之间 长60秒到一个月之间5 通信和连通性5.1 何谓连通性问题？在一个集
22、成的用例中考虑的首要问题应当就是如何解决通信和联通性问题：1. 后端系统连通性 特指后端系统（BES）需要被调用的情形，需要如何来做呢？2. 请求连通性 前端系统（FES）或服务接收者如何调用服务？3. 内部连通性 SOA结构的平台需要具备那些内部连通性来应对端到端的用例？注意连通性的核心特征包括： 所支持的协议：如RMI，HTTP，IIOP等 连通性的方向。 连通性所需的调用标准场景：o 同步 服务的调用者在得到服务返回结果之前，一直处于阻塞等待状态。o 异步 服务的调用者不会一直阻塞等待返回结果。o 混合 这类的情形是指同步调用之后跟随异步调用的一类服务。 交换的范例：o 双向 请求/应答
23、。o 单向 fire and forget。 事务性支持。包括对传递性事务性的支持。 数据格式支持，如XML，FML32，后者会在下文中描述服务数据处理的部分有所提及。5.2 发布的接口发布的服务接口是指为SOA平台外部的服务请求者发起请求暴露的接口，依据不同的流程设计提供发起请求适用的协议选项。请求首先初始化服务。注意，发布接口是为实现松散耦合和可维护性的考虑结果。服务请求应当可以使用多种相异的协议或技术。下文中将围绕于此进行各种相关技术的讨论。高层次的设计构架更进一步的细节需要为现有的发布接口形成一套资源库这套资源枯中需要包括描述服务的文字，尤其是一些副作用，升级等的描述。对内部服务的描述
24、也应包括在内。在资源库中存在的所有服务应当以一种标准的方式进行描述包括服务设计的需求，实施特点，核心的设计考虑等。5.3 哪些工具可以帮助更好的解决连通性问题？以下的平台 特性都是与连通性有关的： Web Services JMS，Messaging Bridge 适配器，应用视图 控件 Event Generators，Message Broker 纯HTTP. B2B (ebXML, RosettaNet).下表中有关连接特性技术列表将为您提供一个可能选项的高级视角，3.3中针对下列使用逐个讨论每个特性： 访问者连通性 后端系统连通性 内部连通性3.4中包含部分推荐使用的特性。同步/异步事
25、务性安全性备注基于HTTP的Web Services均可支持不支持支持Web Services/ 基于JMS异步支持支持Connection pooling through MDB pool size for the JMS destination.JMS 和 Messaging Bridge异步支持支持Connection pooling through MDB pool size.适配器和应用视图均可支持支持支持控件均可支持支持支持Connection pooling dependent on resource control is accessing, e.g. JDBC.纯HTTP同步
26、不支持支持B2B异步支持支持连通性特性的技术列表5.3.1 Web Services最新的Web Services标准不支持事务，应该说这个领域的标准正处于一个酝酿时期。Web Services安全和Web Services可靠性是另外两个正处于萌芽期的标准内容。Web Services多数都是架构在HTTP协议之上，籍此可以获取最佳的传输或累次操作，并利用JMS获取可靠的传输。5.3.1.1 请求连通性Gartner的Daryl Plummer写道，“Web Services最有价值的地方在于在发布接口时利用了WSDL作为接口定义语言（IDL）。大多数接口定义语言都与语言（如Java）绑定很
27、紧，或是表现为一个组件模型（如CORBA）；相反的，WSDL是与语言和模型无关的。类似于接口与实现的分离，接口定义也理应与底层的实现技术分离开来。您可以在任何SOA环境中使用WSDL定义。”因此，Web Services具备为服务描述发布接口的能力，而且由于使用了WSDL，此种描述是基于标准的，它使得服务可以被处于任意环境中的客户轻松访问。一般来说，现代客户系统将有能力以WSDL作为一种服务并且产生对Web Services产生需求的代码，ORACLE Workshop可以为Weblogic Web Services产生Web Services代理类。5.3.1.2 后端系统连通性对于那些从S
28、OA平台到暴露了Web Services接口BES的调用，Web Services是连通性的一个选项，但是考虑到对于可靠性，事务性以及Web Services之间的安全性传递的缺陷，这一领域当前仍然是非常不成熟的。不过逐步的，BES也正在向暴露成Web Services的方向发展。5.3.1.3 内部连通性对于SOA平台内部的交互性，尤其对于一个分布式架构，采用Web Services会变得越来越重要。考虑到Web Services栈对于编解码过程来说是相当昂贵的，而且无法在通过一个Web Services调用来传递事务，后者是更加主要的限制。5.3.2 JMS，Messaging Bridg
29、eJMS是一个J2EE子系统，用来实现减弱消息处理。WL平台还包括一个Messaging Bridge的特性，用来桥接本地和远程消息队列。利用Messaging Bridge，远程队列可以是远程的WLS域中或非WLS域中的JMS消息队列，甚至可以是远程非WLS域中的非JMS消息队列，如MQ Series。在支持连通性方面，JMS可以作为访问任意J2EE平台，或多种具有JMS接口的MOM产品的方式，因此受到广泛支持。通过配置，JMS可以支持上述质素不同的多种服务（QOS），包括最多一次（At-Most-Once），仅一次（Exactly-Once）等，当然，接收系统的能力也是其中的一个影响因素。在需要连接远程消息队列必须选择Messaging Bridge，因为任何的JMS访问对于客户端都是本地的。M
