设计规范
Prepared for:
北京航空航天大学
目 录
1 简介
1.1 目的
本文的目的是对”北航数字校园项目”各应用系统设计的目标、范围和要求进行说明，帮助开发商明确所需进行的工作和对工作成果的要求，并作为对开发商工作成果进行评价的依据。
1.2 预期读者
架构设计师、系统设计人员
北航的架构设计师、维护设计人员根据学校的业务要求和技术状况制定此设计规范。
开发商
“北航数字校园项目” 的系统开发商根据本文档描述的标准规范要求，进行相关系统的设计和开发。
1.3 适用范围
本文档描述的内容适用于“北航数字校园项目”中应用系统的设计和开发。
1.4 规范要求及约束
各参与的软件供应商，都应明确本规范的约束，并据此指导进行分系统工程
的统一设计和开发，完成本规范中规定的相关内容。
分系统工程中最终要提交的服务组件都必须经过严格的集成测试、审核和验
收，然后提交。
如对本规范有任何技术上的建议和分系统工程个性化的需要，请将建议和需
要以文字的形式提交，经过讨论、评审后修订、变更本规范，协调各分系统工程的开发，任何开发商不得单独修改本规范内容，并加以实施。
2 架构设计的目标
“北航数字校园项目”，按照统一化建设的要求进行总体设计，实现一个架构一致、管理统一、维护统一的“一体化的信息系统”。
为了实现这一目标，应当采取面向服务的构件化策略。也就是说，对应用系统进行总体规划，对业务需求进行全面统一的分析，对数据和功能进行统一的分层规划，将整个系统划分为不同层次的构件，构件的内部包含自用的数据和功能，构件之间通过标准的接口进行交互。
按照这种策略，应用系统可以实现最小化，可以按照需求组合各个构件，充分共享统一的可重用服务组件。数据和功能的冗余达到最低，应用系统的维护和实施的工作量最小，满足”北航数字校园项目”“总体设计、分步实施”的基本建设路线。
这种策略的关键在于总体框架的设计要充分和科学合理，特别是可重用服务组件的设计，必须保证：无论需求如何变化，应用核心不会变化，仅是外围组件的功能和组合方式在发生变化。
3 可重用服务组件的技术规范
创建可重用服务组件的原则为：
按照项目组总体设计要求的分系统工程承担开发并提供其他分系统工程
应用的组件必须创建为服务组件。
各分系统工程开发商，在系统内部，应本着提高可重用性的设计原则，
尽量创建可重用服务组件，并按服务要求进行说明和发布。
3.1 对服务组件的要求
开发成服务组件的应用系统访问接口，根据系统访问的频度、数据量的大小可以封装成webservice、EJB、JMS等的接口，这种类型的接口才能够注册到服务平台上，并提供给其它的应用系统使用；
服务集成平台能依据系统自己的配置信息将服务组件产生的异常或者错
误信息格式化成标准的XML格式消息，并且将该XML消息发送给等待同步响应的服务组件使用者；
对于服务组件使用过程中应用系统需要传输的大数据块可以采用SOAP with attachments消息类型进行传递，因此服务组件的提供者和服务组件的使用者都应该考虑到需要实现大数据块转换成SOAP协议的attachments和从attachments还原回大数据块的功能；
3.2 可重用服务组件的规范
分系统工程在开发过程中，只能将提供数据层面复用的组件开发成可复用
的服务组件，对于非数据层面性质的组件（如：界面展示组件）不应开发成服务组件进行复用；
开发成服务组件进行复用的组件必须进行web service、EJB等方式的封
装，才能注册和发布到服务平台上；
分系统工程的每个功能模块可能由一个或多个业务单元组成，这些业务单
元通过一定的业务流程组成该功能模块，在开发过程中分系统工程开发者应尽可能的分离出每个功能模块中存在复用情况的业务单元，并将其开发成服务组件注册到服务平台中，以便其它分系统工程进行复用； 分系统工程只能将服务组件注册到服务平台上中，且只能允许服务平台调
用，分系统工程应该提供服务组件的安全控制，提供用户名/口令的安全审核方式，并在注册组件是提供给服务平台；
分系统工程在开发过程中，如需要使用其它分系统工程提供的服务组件时
应调用服务平台上注册的服务组件，不允许通过其它的途径直接或间接的调用其它分系统工程对外公开的服务组件，且作为服务组件的使用者在调用服务组件时应该提供调用的用户名和密码；
分系统工程对外提供的每个服务组件应该有自己的事务控制机制，即每个
服务组件作为一个完整的事务单元对外提供服务，由于服务组件使用者传入参数原因或者组件内部原因导致的服务组件抛出异常、终止退出的，服务组件自身应该能回滚事务，保证数据的完整性；
作为服务组件的提供者应将服务组件中需要抛出的异常抛出到服务平台，
由服务平台根据配置信息将异常信息格式化后发送给服务组件的使用者；
3.3 可重用服务组件的注册和管理规范
服务平台提供基于Web的控制台，该控制台基于轻量级的WebLogic门户技术，能够提供所有的配置和监控功能。通过这个控制台，能够查看所有服务的运行状况、统计信息及服务水平告警信息，分系统工程开发的服务组件的注册和管理都应通过服务平台的Web控制台完成。 服务组件的注册规范：
分系统工程开发的服务组件，应填写“服务组件登记表”（下文） 提供者 中文名称 接口名称 版本 安全 接口的访问URL 是否异步 输入 输出 返回值 描述 XML格式 使用者 填写服务组件是否为异步调用（异步/同步） 填写服务组件的调用参数 填写调用服务组件时，服务组件在后台的输出信息 填写服务组件的返回结果说明 填写服务组件的功能描述、说明； 填写服务组件的wsdl描述文件片断 填写该服务组件的使用者，在服务组件登记时服务组件提供者可以不填写本栏，由服务使用者填写 服务组件的提供者在注册服务组件时应该按照“3.5 服务组件的命名规
填写服务组件的提供者名称 填写服务组件的中文名称 填写服务组件的方法名称 填写服务组件的版本号，用于跟踪服务组件的修改 填写服务组件的访问用户名和密码 填写服务组件调用位置的URL 范”进行服务组件的命名和注册到对应的名称空间中，不应自行改变命名空间，从而导致服务组件管理的混乱；
服务组件在提交注册前应进行完整的测试，以及相应的输入、输出数据
的格式检查，确认无误后提交注册；
服务组件在提交注册后，服务组件的提供者不应再对该服务组件进行任
何的改动和变更，如需要改动和变更需要依据“服务组件登记表”（上文）中使用者的记录信息，统一通知所有的使用者，并得到改动方案确认和认可方能进行更改，服务组件更改后应及时修改该服务组件的“服务组件登记表”；
3.4 可重用服务组件的使用规范：
服务组件在提交注册后，服务组件的服务组件的使用者即可通过“服务
组件注册登记表”中的登记信息使用，服务组件的使用过程中需要的任何信息都以“服务组件注册登记表”为准；
服务组件的使用者应该及时在“服务组件注册登记表”中的使用者栏目
中登记使用者名称，以便在服务组件改动时进行跟踪管理和测试、检查等；
服务组件的使用者如为异步调用，应登记自己的回调服务组件接口，用
于进行交互服务；
3.5 可重用服务组件返回数据格式的规范
服务组件使用者的传入参数以及服务组件返回结果不应含有过分复杂
的数据结构（如，返回结果为一个对象类型的XML数据体，但该对象的某一个属性值又是一个小的对象）；
服务组件的调用参数传递格式（重点看结构，下文中的USER_ID和
MENU_ID等是参数名称）如下： xmlns:e=\"ld: 项 目 组 DataServices/sample/ \"> 服务组件返回值传递格式（重点看结构）如下： 3.6 面向采集的数据服务组件命名规范 服务组件命名应该以直观明了的方式进行，让服务组件的使用者能够顾名思义的识别服务组件的名称，如“学生＃基础信息”服务组件按照拼音第一个字母命名为“XSjcxx”； 学籍服务组件存储命名空间为“XJ” 3.7 可重用服务组件说明的规范 可重用服务组件的描述分为接口和实现两个部分，应该满足以下的基本原则： 1. 接口尽可能使用业界具有规范性和/或普遍适应性的标准； 2. 实现应该完全遵循接口的规范，并能提供多种可用的实现供选择。 可重用服务组件的描述划分为以下的几个部分： 1. 服务组件描述： 描述按照标准的格式明确： 服务组件的名称（中/英文）。需要遵循服务组件的命名规范 服务组件的编号。编号的规则为：C*###，其中C表示Common（公 共），*可为字母F/G/D中的一个（表示服务组件所处的专业/通用/领域的分层），###为3位的序列号，不足位数在左边补零（注意可重用服务组件的序列号是局唯一的）。 基础服务组件，这里特指ALDSP生成的基础数据服务类组件 通用服务组件，例如数据格式转换，数据类型转换，文件读写等服 务组件，日志，异常等。 领域类组件，服务于某业务应用，如测井曲线的数据处理 服务组件类别。可为字母F/G/D中的一个（表示服务组件所处的基础/ 通用/领域的分层）。 服务组件提供方式。表示服务组件的提供方式，一般来说可以是以下各 种中的一种或多种的组合： 规范（Speciafication）：表示对接口和实现机制的描述，以及对实 现的规范和指导性原则。据此可以设计出符合一定标准的可重用服务组件接口和实现。 Java/C/C++/其他库（Java/C/C++/Misc Library）：包含完整的 特定语言实现的库，以Java库为例，应包含完整的可运行的Java程序（JAR文件）、标准Java文档（javadoc）、完整的源代码包（可选）、创建脚本（可选）等。 服务（Service）：可重用服务组件提供为一种服务，应包含服务的 描述文档、使用文档（用户手册和程序员指南，如果需要的话）等。 其他（Misc）：其他类型。 服务组件功能描述：简要描述可重用服务组件的功能、范围，必要时提 供完整的需求文档。 其他要说明的问题。 2. 接口描述： 描述可重用服务组件提供的接口信息。 3. 接口用法： 描述应用软件使用可重用服务组件的方法和注意事项，规范化可重用服务组件被使用的方式。 4. 附件和参考资料： 引用重要的附件和参考资料。 4 服务设计流程 4.1 什么是服务设计流程? 给一个特定的整合用例，解决方案设计者将首先中止用例到一组服务，他们一起来迎合需求。然后服务设计流程是一组行动，他们将为每个服务设计。服务可以或不可以存取任何远程系统，例如数据转换可以作为一个可重用的服务来实现是可行的。 4.2 什么是服务设计流程的输入? 典型的，为任何给定的整合用例所作的服务设计流程的输入如下所示。请注意尽管时间表，资源约束和价值约束能影响流程，他们不包含在这部分中，这部分集中讨论设计流程的技术方面。 功能需求 这将包括数据输入，数据输出和用例需求的行为，特别根据企业 中任何受影响的状态更新。所有被包含的系统将被列出，还有他们之间所有被要求的交互。服务所需要的有条件逻辑和任何其他的逻辑流也是功能需求的一部分。理想的，功能需求将包括任何所需管理的描述。 非功能需求 这将包括所期望的测定体积的，需要的响应时间，可用的需求， 安全需求和服务需求的质量。 最佳实践和设计模式 这将包括用WLI8.1产生的任何类型的最佳实践和设 计模式，包括文档。 解决整合问题的前车之鉴 这包括设计人员的经验集合。 现存解决方案库 这将包括任何现存的解决方案和服务的文档。 Non-Functio服务设计流程的输入 Functional nal Requireme当为用例看一个非功能的需求，为需求考虑以下SMART标准是有用的： 具体的：不模糊，用一致的术语，简单并且在内容适当的水平。 Service Design Designer(sService Design Process 可测量的：验证这个需求已经被满足是可能的。什么测试必需被执行，或什) with Solution 么标准必需被迎合来核实需求被迎合？ 可得到的：典型可行的。什么是你的需求可行性的专业判断？ WLI 8.1 Design 可实现的：现实的，特定的资源。你有雇员吗？你有技术吗？你对所需的开RepositDocumentatPatterns 发架构有存取吗？你对所需的运行时架构有存取吗？你有充足的时间吗？ ory of 可追踪的：通过对系列设计，实现和测试的详述从概念链接。 高层次的设计构架 非功能需求应该执行SMART标准。 更进一步的细节 经常是这样的情况，你有许多需求相互矛盾，或者那被描述的太一般来保证成功的实现。 4.3 服务设计时的步骤是什么？ 根据特定服务的需要，服务设计流程能被分解为下列行为： 1. 解决通信和连接问题 这定义了已发布服务接口，任何从服务消费者到 SOA平台的连接，任何从SOA平台到BES的连接，还有SOA平台内部组件间的连接。 2. 解决数据处理问题 一旦通信和连接问题已经被确定，这将提供需要通过 数据翻译和转换来解决的数据处理需求。 3. 设计流程 这讲述了有关同类逻辑，任何步骤顺序，有条件的逻辑和任何 其他执行规则的设计。 图 1: 整合服务设计重复流程 我们推荐按顺序执行这些步骤，因为通信问题有充分的理由表面化数据处理和流程设计的需求，并且数据处理问题有充分的理由表面化流程设计的需求。 早先观察连接需求的另一个原因是有时候它将为得到或者开发展现一个需求，然后为新架构接受测试——例如控制或者适配器。这必须尽快被确认来使风险管理能够有希望的减少服务传送时间。 如果有不少人投入到服务的设计中，则在这个流程里可能得到平行系统，但是事实上任何阶段的需求将由其他需要入帐的活动产生。 上面的流被重复的显示，因为它看完数据处理问题之后，再次访问通信问题通常是值得的，并且流程设计能够影响为通信和数据处理所作的决定，也在这两个领域介绍了新的需求。在没有验证接口文档和标记而进入开发已经是一个非常大的项目风险，因为这些适合多流程的第一步。 高水平设计向导 我们推荐这些步骤按顺序执行。 详细内容 通信问题有充分的理由可以表面化需求，适合数据处理和流程设计，并且数据处理问题有充分的理由表面化需求来适合流程设计。这也确定了任何组件需要在项目早期产生和发展。 4.4 一个服务的主要特点是什么? 假设一个端到端的整合用例，这样一个用例可能被分成更多的服务，每个都需要适当的设计。这个端到端的服务和任何组件服务都是服务。一个服务将有一定数量的特点，这对服务的设计将是十分重要的。对于一个特定服务的设计者它将是非常重要的，能在这些区域里分类这些服务的特点。首先，基于它的设计，一个服务有一定数量的属性: 1. 复杂性: 基本的——被定义为一个对其他组件进行一次调用的服务 合成的——被定义为一个对其他组件进行多于一次的服务 2. 调用范例： 同步的——当服务完成时这种服务的用户将阻塞来等待回应 异步的——当服务完成时这种服务的用户将不阻塞来等待回应 混合的——这将是一个同步部分接着异步部分的服务. 3. 交换范例： 双路——需求/应答 单路——激活和忘记 上面描述了服务属性，它被服务设计者决定，服务有很多特点来自非功能需求： 4. 5. 体积： 高——每秒超过100个服务调用 中——每秒1到100个服务调用之间 低——每秒少于一个服务调用 QOS（可靠性）： 至多一次——这种服务保证只执行一次。这典型返回给用户一个失 败，为他们处理错误/重试。 至少一次——这种服务保证至少执行一次，因此允许复制的可能性 确实一次（也叫一次且仅此一次）——这种服务保证执行一次且仅此 一次。这典型用于确认，重试和复制探测和消除。在此处服务包含更新多个系统，关于更新的次数我们有两种选择。 他们都能够在同一分布式事务中被更新——所有或都不 他们相互能够更新——JMS存取和促进 6. 持久性： 非常短——0.1到10秒之间 短——1秒到60秒之间 中等——30秒到1小时之间 长——60秒到一个月之间 5 通信和连通性 5.1 何谓连通性问题？ 在一个集成的用例中考虑的首要问题应当就是如何解决通信和联通性问题： 1. 后端系统连通性 － 特指后端系统（BES）需要被调用的情形，需要如何来做呢？ 2. 请求连通性 － 前端系统（FES）或服务接收者如何调用服务？ 3. 内部连通性 － SOA结构的平台需要具备那些内部连通性来应对端到端的用例？ 注意连通性的核心特征包括： 所支持的协议：如RMI，HTTP，IIOP等 连通性的方向。 连通性所需的调用标准场景： o 同步 － 服务的调用者在得到服务返回结果之前，一直处于阻塞等待状态。 o 异步 － 服务的调用者不会一直阻塞等待返回结果。 o 混合 － 这类的情形是指同步调用之后跟随异步调用的一类服务。 交换的范例： o 双向 － 请求/应答。 o 单向 － fire and forget。 事务性支持。包括对传递性事务性的支持。 数据格式支持，如XML，FML32，后者会在下文中描述服务数据处理的部分有所提及。 5.2 发布的接口 发布的服务接口是指为SOA平台外部的服务请求者发起请求暴露的接口，依据不同的流程设计提供发起请求适用的协议选项。请求首先初始化服务。注意，发布接口是为实现松散耦合和可维护性的考虑结果。 服务请求应当可以使用多种相异的协议或技术。下文中将围绕于此进行各种相关技术的讨论。 高层次的设计构架 需要为现有的发布接口形成一套资源库 更进一步的细节 这套资源枯中需要包括描述服务的文字，尤其是一些副作用，升级等的描述。对内部服务的描述也应包括在内。 在资源库中存在的所有服务应当以一种标准的方式进行描述 包括服务设计的需求，实施特点，核心的设计考虑等。 5.3 哪些工具可以帮助更好的解决连通性问题？ 以下的平台 特性都是与连通性有关的： Web Services JMS，Messaging Bridge 适配器，应用视图 控件 Event Generators，Message Broker 纯HTTP. B2B (ebXML, RosettaNet). 下表中有关连接特性技术列表将为您提供一个可能选项的高级视角，3.3中针对下列使用逐个讨论每个特性： 访问者连通性 后端系统连通性 内部连通性 3.4中包含部分推荐使用的特性。 同步/异步 事务性 不支持 安全性 支持 备注 基于HTTP的均可支持 Web Services Web Services/ 于JMS 基异步 支持1 支持 Connection pooling through MDB pool size for the JMS destination. JMS Messaging Bridge 适配器和应用视均可支持 图 控件 均可支持 支持 支持2 Connection pooling 支持 支持 和 异步 支持 支持 Connection through size. pooling pool MDB 1 事务不包括 Web Service的发起者。 2 流程的安全信任的对象可以使用控件。 dependent on resource control is accessing, e.g. JDBC. 纯HTTP 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）绑定很紧，或是表现为一个组件模型（如CORBA）；相反的，WSDL是与语言和模型无关的。类似于接口与实现的分离，接口定义也理应与底层的实现技术分离开来。您可以在任何SOA环境中使用WSDL定义。” 因此，Web Services具备为服务描述发布接口的能力，而且由于使用了WSDL，此种描述是基于标准的，它使得服务可以被处于任意环境中的客户轻松访问。一般来说，现代客户系统将有能力以WSDL作为一种服务并且产生对Web Services产生需求的代码，ORACLE Workshop可以为Weblogic Web Services产生Web Services代理类。 5.3.1.2 后端系统连通性 对于那些从SOA平台到暴露了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 Bridge JMS是一个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访问对于客户端都是本地的。Messaging Bridge的存储转发能力解决了本地流程不能访问远端消息提供者的问题。因此，Messaging Bridge成为了本地与外部消息队列通信的典型配置。 5.3.2.1 请求连通性 一个服务请求者可以利用JMS和Messaging Bridge作为SOA服务的异步调用，前提是系统可以向JMS请求目的提交消息。如果需要服务响应，那么服务的请求者必须监听JMS响应目以获取产生的消息，同时还必须能够将获取的响应与请求相关联。这种关联的实现要求请求者和SOA平台服务具有相同的数据格式，无论是以报头或是报文的形式来完成。 5.3.2.2 后端系统连通性 为了完全实现SOA平台和一个BES之间削弱联系和松散耦合的异步消息机制，可以采用JMS和Messaging Bridge的方式。对于松散耦合的消息机制，例如当需要回应时，就会相应产生监听JMS响应目的服务，同时还必须有能力关联请求与响应。这种关联的实现要求请求者和SOA平台服务具有相同的数据格式，无论是以报头或是报文的形式来完成。 5.3.2.3 内部连通性 在平台中，JMS是实现流程间松散耦合消息机制的主要手段，JMS还可以用来缓存服务请求和/或服务响应。对于域之间的消息通信，Messaging Bridge是一个可以实现之间消息通信的方案，它支持所有可能的服务质量（QOS）选项。对于需要最多一次（At-Most-Once）的服务，可以采用非持久性的消息队列。 JMS可以实现位置无关性，这是因为JMS目的的位置是部署时确定的。 5.3.3 适配器，应用视图 ORACLE服务平台包含对标准J2EE CA1.0适配器的支持，也包括支持ORACLE私有的应用集成（WLAI）扩展的适配器。 标准J2EE CA 1.0适配器可以用于在企业信息系统（EIS）中暴露功能，但是不具备EIS向其它服务发起请求的功能。J2EE CA 1.5规范包含了事件的支持，同时也支持EIS通过J2EE CA适配器向应用服务器发起同步和/或事务性调用。 相对于J2EE CA 1.0适配器，WLI8.1适配器包含对ORACLE的WLAI扩展的支持，扩展包括： 支持事件。 在应用视图中图形化定义适配器连接配置，适配器服务，以及适配器事件的能力。 支持异步调用服务。 适配器的编写可以利用任何的与特定BES进行接口的机制。这意味着与BES的通信和连通性将受制于BES的集成能力。 依据不同的事务性环境，适配器会有所区别，这点类似于对BES安全传递性的支持。适配器服务和事件支持的前提是，EIS是事务性的且适配器支持其事务性。 如上所述，WLI8.1适配器包含对应用视图的支持。应用视图在适配器之上提供了一层抽象视图；虽然适配器本身是与EIS的具体函数紧密相连的，应用视图却是与业务流程相关联的，应用视图的设计需要客户端来完成。应用视图将业务流程中的步骤转化为适配器中的操作。 应用视图控件允许您的Web Services和业务流程通过应用视图访问一个企业级的应用。 5.3.3.1 请求连通性 在平台中，一个服务的请求者可以使用事件适配器来异步调用SOA服务。如果需要服务响应，服务请求端需要监听JMS响应目的来获取消息，或者暴露一个回掉服务。在两种情形中，都需要服务请求者可以关联响应和请求。当然还需要请求者和SOA平台服务统一数据格式，可以通过统一报文或报头的方式实现这种关联。 5.3.3.2 后端系统连通性 适配器应用的最重要的一个场景是服务和BES的连通性。抛开了BES具体业务机制，WLI中的WLI适配器通过XML-in，XML-out服务接口暴露服务。这一功能是通过应用视图来完成的。之后通过ORACLE WLAI架构就可以同步和异步调用这个服务。WLI事件同样可以用来完成BES和一个SOA服务实施之间的通信，例如异步响应的传递，或者为一个长的BES流程传递一个被动的更新。 5.3.4 控件 控件是可重用的Workshop组件，它提供了可在一个或多个流程定义中使用的公共接口。这是一些位于SOA层之间或一层内的各个组件之间的接口，例如数据转换控件。可以在一个流程定义中使用控件来发起对BES系统的调用，例如数据库控件允许一个流程通过JDBC连接池向RDBMS发起SQL。 以下是可用的控件列表，以支持事务或不支持事务作为分类标准。其中部分在词汇表中可以查到。这些控件事务性的本质对于流程开发者来说是非常关键的。 事务性控件 数据库 非事务性控件 文件 JMS WLI JMS 应用视图 （如果JCA适配器是事务性的) 定时器 EJB Message Broker Transformation Process Control E-mail Service (JWS) Service Broker3 RosettaNet EbXML4 HTTP (dev2dev) 应用视图 （如果JCA适配器是非事务性的） 上述的控件列表可以参考Workshop的帮助文档： 如果Using a transactional control against a non-transactional resource will mean that the work done against the resource will be outside of the transaction. 可以编写客户定制的Java控件。这些控件可以是已有控件的一个封装，也可以编写以实现新的功能。 对于客户端来说，这些客户定制的控件在使用上与上述列表中的控件没有任何区别。 5.3.4.1 请求连通性 WL平台的请求者使用这些控件非常频繁，他们利用Service Control、Process Control等来访问服务。Message Broker控件支持将应用视图的事件发布到一个Message Broker渠道中去，这样就可以异步的启动一个服务。 5.3.4.2 后端系统连通性 这同样是一个控件的主要使用领域，尤其是数据库控件、EJB控件、Tuxedo控件、文件控件、HTTP控件以及应用视图控件，最后提到的应用视图控件可以支 3 如果请求被缓存起来，那么缓存部分是事务性的。 4 底层通过 JMS来完成，在这一点上可以确定其事务性机制。 持流程调用通过适配器定义的BES服务。 5.3.4.3 内部连通性 这是一个使用控件非常频繁的地方，主要是Message Broker控件，WLI JMS控件，流程控件，Service控件，他们在各种情况中完成WLI8.1中流程间的通信。 5.3.5 HTTP HTTP是多数FES和BES用来实现outbound和/或inbound联通性的方式。这项技术主要的局限性在于其对于事务性的支持。一个HTTP客户端将阻塞等待回应，但是又无法保证一定有响应返回。举例来说，一个已经发出给客户端的回应可能由于网络或其它等问题传输失败了，一旦超过预设的时间，这在表面上即看似是客户端的失败，但事实上请求已经成功发出了，所以在客户端来说是成功的。为了克服这个问题，您需要实现idempotent服务或是实现类似于B2B协议提供的某种确认传输的机制。 这部分所描述的HTTP是一个纯的HTTP，区别于应用于以WSDL定义接口的SOAP HTTP Web Services。 5.3.5.1 请求连通性 HTTP Event Generator是WLI8.1中支持FES通过纯HTTP来访问服务的手段，现在支持异步调用，不过在未来的版本中这种方式也将支持对架构于WLI8.1之上的SOA服务的同步调用。 5.3.5.2 后端系统连通性 HTTP控件是WLI8.1中支持对BES系统纯HTTP访问的方式。 5.3.5.3 内部连通性 纯的HTTP不能用来完成WLI8.1服务之间的通信。 5.3.6 B2B B2B用来完成业务伙伴的集成，ORACLE服务平台支持B2B协议和标准： ebXML 1.0 和2.0，参考Introducing ebXML Solutions. RosettaNet 1.1 和2.0，参考 Introducing RosettaNet Solutions. 利用SSL实现传输层安全，利用数字签名和加密实现消息一级的安全，这些标准保证了交易伙伴之间私有、安全、一节可靠的HTTP（s）商业消息交换。 纯HTTP存在的最大问题就是无法对发回给请求者的HTTP响应进行监控。对于一个服务而言，当发出响应以后服务就结束了，而不会关心这个响应是否顺利的传到了客户端。在那些响应没有顺利传送到请求方的情况，请求者会发生超时或进行重发请求，但此时服务已经结束了，重新执行会存在一定的风险。下图展示了一个B2B双向异步消息交换的样例： B2B双向异步消息交换机制示例 Buyer向Seller发出（1）PurchaseOrder请求，并收到一个响应，通常是HTTP200。Seller将验证并保持PurchaseOrder document，同时回应一个ReceiptAcknowledgment HTTP消息（1.1）。仅当Buyer收到ReceiveAcknowledgement 且 Seller 成 功 传 输 了 ReceiveAcknowledgement，双方才能确认PurchaseOrder已经成功发送了。这样的做法确保了双方都清楚消息已经被传输和接收，因此保证了一次性的传输。底层的B2B协议为每一步添加了超时，唯一的会话/消息ID允许重试以及自动删除重复发送的消息。 5.3.6.1 请求联通性 使用B2B需要请求与响应双方都实现其标准，从而了可以使用这种连通性方式的系统数目。由于标准实施的严密程度，标准的B2B应用仅对于一些对安全/私有以及建立于HTTPS上的可靠性消息传输等有严格的要求的应用是必须的。一些更加实用的场景是当请求者位于企业级安全边界之外的情形。这样的情形允许忽略安全传输部分，转而采用纯HTTP，既保证仅一次的传输，避免SSL（HTTPs）带来的对性能较大影响。 5.3.6.2 后端系统连通性 由于通常情况下，BES处于较少安全隐患的环境中，安全性不是非常重要的考评因素，同时还有一些标准本身的因素，B2B很少应用于后端系统的连通性领域。 5.3.6.3 内部连通性 可以用来保证WAN中HTTP消息的安全性。虽然传统的观点认为这些协议会占用较多资源（SSL安全机制的实现是其中部分因素）。如果您需要实现可靠的信息传输但又不想使用安全传输，可以选用非SSL（HTTPs）实现方式。 5.4 推荐方案 5.4.1 请求连接性 高层次的设计架构 对于异步发布服务接口，使用JMS或JMS上的Web Services。 对于那些无法适应发布异步的发布服务接口的FES，需要由一个临时的服务来作为其可以访问的服务，并将他们映射到发布的接口上。 对于同步来说，最佳的发布服务接口方式为采用利用HTTP的Web Services。 对于那些无法适应发布同步的发布服务接口的FES，需要由一个临时的服务来作为其可以访问的服务，并将他们映射到发布的接口上。 更进一步的细节 由于JMS是基于标准的技术，多种客户端平台都可以写入或监听JMS队列。 一些FES不能向JMS写入信息： 在很多情况下可以使用Event Generator － 文件、Email、HTTP、RDBMS、MQ。 为一些EIS设计的适配器Event。 由于Web Services是一种基于标准的技术，多种客户端平台都可以对Web Services 发出请求。 一些FES不能通过HTTP调用Web Services： 对于基于Java的FES，JPD Proxy是一个同步调用服务的可行方式。 在下一个版本的J2EE CA标准 － 版本 1.5 [2] － 将包含对于EIS利用适配器向应用服务器发出同步调用请求的支持。同时还将支持EIS通过适配器向应用服务器发出事务性调用。 对于同步，一次且仅一次的发布服务几口，可以利用B2B或双向异步调用加以实现。 当网络在应答时出现失败时，阻塞协议不提供一次且仅一次的实现。这一点可以由B2B（ebXML，RosettaNet）协议来克服，双向异步发布接口也可以解决类似问题。 确信请求对于发布几口没有响应之后再设计一个consumer层服务。 在某些时候，通过整个团队的仔细讨论，可以在consumer应用层就可以解决没有响应的问题，而不需要再增加一个Consumer层服务。 5.4.2 后端系统连通性 High level design guideline高层次设计架构 请参加如下的程序框图。 更进一步的细节 程序框图说明了在考查BES连通性时需要进行的考虑步骤。 当一个特定的BES可以以多种不同的连通性选项来暴露服务，就可以选择上述consumer联通性推荐方式中的一种。 如果企业应用中已经存在了一个联通性解决方案，新战略的兼容性问题也要被纳入到考虑的范围中来。 由于接口的匹配成都了集成的进行，最好的方式总是BES可以提供附和SOA发布接口的接口。 一些旧的连通性解决方案会随着时间的推移变为不可用的，另一些会被整体的企业战略排除在外。 现有的针对旧版本Weblgoic的连通性解决方案应当得到自动升级。 在新的Weblogic发布版本中新的或修改的功能应当提供更好的连通性解决方案。 在任何的BES联通性解决方案选取过程中，都需要听取BES所有者的意见。 尤其是当BES是一个COTS包，选取联通性解决方案时需要参考BES的供应商的建议，即COTS包也应纳入到考虑范围中来。对于即将进行设计实施的BES也是如此。 图 2：BES连通性决策流程图 5.4.3 内部通信 高层次的设计架构 对于不同域中流程间的异步通信，我们推荐使用JMS和Messaging Bridge，同时配合使用JMS EventGenerator和基于JMS的Web Services。 对于同一域内流程间的双向异步通信，相比较MessageBroker而言，我们更加推荐使用Process Control。 更进一步的细节 Messaging Bridge支持不同域之间异步通信的所有QOS选项。Messaging Bridge存储转发的能力使得本地流程可以方便的访问远程服务端。 使用process control或Message Broker启动一个流程在性能上差别不大，但是获取process control回调比获取message broker订阅要快的多。Message broker订阅过滤机制需要使用一个数据库来对应过滤值和流程实例。Porcess Control回调则直接路由给相应的流程实例。 在处理大消息时使用纯的JMS。 对于同一个域内流程间的异步通信，如果需要在流程间传递事务上下文，或者性能不是最主要的问题，推荐使用process control，service control和service broker control则不是适合的选择。 对于不同域内流程间的同步通信，必须使用Service control，service broker control或JPD Proxy。 较web services对于大消息的编解码过程，JMS更加高效。 Process control是事务性控件，而且可以避免类似于SOAP编解码的机制。service control和service broker controls都是非事务性的。 Process control仅适用于同一个域内。JPD Proxy提供事务上下文的传递机制，是紧耦合的。service control和broker不提供事务传递，同时他们是松耦合机制。 如果需要数据依赖路由功能，使用service broker control，Service control依靠数据路由提供配置服务service control不能完成此种功能。 调用到多种服务实现的功能，但是是非事务性的。 5.4.4 通常的做法 高层次的架构设计 控件的重用性 更进一步的细节 所有的控件在设计使用使用时都需要关注其在流程定义间的重用性。对于控件的定义需要保存在SOA组件库中。 在客户定制控件时需要充分利用WLI8.1自带的控件。 请在着手设计客户定制控件之前最大化的使用WLI8.1自带的控件，仅当必要性和自身可重用性的问题非常明显时定制自己的控件。 客户定制的控件在重用性上优于客户Java代码。 用控件来封装客户Java代码可以带来多个不同流程定义间的可重用性。EJB也可用于设计可重用的业务逻辑。 在版本控制中记录控件的版本。 Workshop中的每一个应用项目中都应当具备一个的控件项目。 每个流程都应该使用一个标准的日志控件来完成流程日志记录。 应视控件为Java代码，并进行适当的版本控制。 应当从SOA组件库中引入项目所需控件。这样可以使控件在整个应用中可用。 这样可以使日志记录于不同的位置，并且具备不同的日志级别。 6 数据处理 6.1 数据处理的问题是什么？ 当通信和连通性的解决方案确定下来之后，下一个服务设计的重要步骤就是解决数据处理问题。 这一阶段中设计的主问题包括： 服务发布接口需要采用何种数据格式？ 服务请求者可以使用服务发布接口所采用的数据格式吗？ SOA平台和BES间的调用和事件需要采用何种数据格式？ SOA平台的内部应当使用哪种数据格式？ 用例中存在哪些数据集成需求？ 如果在一个服务的执行过程中需要多种不同的数据展现方式，就需要合适的数据映射和/或数据转换操作。一些情况下，数据映射需要包含主键映射的功能。数据转化使得FES和BES对数据模型设计的需求减弱。 高层次的设计架构 用例中数据集成的需求一般可以在流程一层解决掉。其中包括的问题诸如数据同步，值映射和特殊的事务性需求。 更进一步的细节 在流程一层解决的原因在于通称情况下有多种资源需要配合使用，同时需求都和特殊的用例绑定较紧，不具开发的通用性。 6.2 数据处理的工具有哪些？ 以下特性可以用来解决WLI8.1中的数据处理问题： XQuery XSLT Format Builder, MFL XML Oraclens 数据模型 6.2.1 XQuery 在WLI8.1的流程中，利用XQUERY可以获得以下类型的数据转换： 多种类型的变量 => 一种类型的变量 变量的种类包括： 用XML Schema定义的XML消息（定义工具可以选用XML Spy或其它的类似工具）。 MFL格式定义的非XML消息（利用Format Builder进行定义）。 用Java类定义的复杂类型的Java对象。 Java向量，例如String类型。 图 3: WebLogic Workshop 数据转换 在WLI8.1中，所有类型的变量都的内部表现都是一个标记流，因此可以更好的映射和转换为其它的类型。 需要注意的是，依照上图所示，您可以将多个变量作为数据转换的输入，但是仅产生一个输出变量。这意味着可以可用通过一个转换控件方法中实现数据合并，数据映射和数据转换。而需要获得数据的分块则需要调用多个转换控件方法。 如果需要使用图形化的Xquery映射工具来处理以DTD作为格式定义文件的XML document，需要把DTD文件转换为一个W3C标准的XSD文件（借助于类似于XML Spy企业版的工具），然后再将此XSD文件导入你的项目。 6.2.2 XSLT 适用于XMLXML数据转换，WLI8.1支持XSLT。注意这里提到的对XSLT的支持仅限于对旧版本的WLS/WLI的向下兼容需要。 使用Java API调用也可获取XSLT支持。 6.2.3 Format Builder and MFL 非XML数据可以利用MFL进行展示（Message Format语言），MFL是提出的XML语法标准，用来实现将非XML数据格式映射到XML Schema格式中。Weblogic包含格式编辑器图形化工具来创建和测试MFL格式定义。注意任何以MFL进行展示的格式不外乎两类 － 或者非XML格式，或者XML等同格式，这两中格式在Workshop工具中可以进行交换。当MFL文件被引入到Workshop工程的Schema项目中后，将产生一个XML Schema来展现XML部分（既同时产生了XML Oraclen）。所以您可以在流程中使用依附于Schema的XML变量，也可以使用依附于MFL格式的非XML变量。 6.2.4 XML Oraclens ORACLE提出了XML Oraclen技术，并将其提交给Apache（org/xmlOraclens/）组织是流程开发、Web Services和其它一些面向服务 平台开发的关键技术。XML Oraclens技术预集成在WL Platform 8.1中，也可以从Apache网站下载XML Oraclens： rg/xmlOraclens/sourceAndBinaries XML Oraclens可以在ORACLE服务平台服务开发中直接使用，同时也可用于非Weblogic的java开放平台。XML Oraclens可以使XML document在Java程序员开来就是一些可以使用的Java对象。任何的添加到WebLogic Workshop应用Schema项目中的XML Schema都可以编译成为XML Oraclens，可以使用GUI操作这些以schema定义类型的变量。这就意味着可以以图形化界面操纵这些XML documents，更加简化进行业务流程，Web Services以及Java Page Flow的开发过程，您也可以在代码视窗中直接利用XML Oraclen提供的方法来操纵XML Document，完善代码的编写。 6.2.5 数据模型 很多名称中都会带有数据模型的字眼，如通用数据模型、规范数据模型、协作数据模型、企业级数据模型等。 忽略那些为了标识各种企业级和集成解决方案的数据模型名称，数据模型的意义就是在于数据必须尽早映射为“标准形式”。如果得到正确的实施，数据模型将提供中立于EIS的服务接口。它定义如何映射引用，将EIS数据格式化为“标准格式”，减弱服务端数据模型与接受端数据模型之间的关联。 通用数据模型的成功实施依赖于企业级“buy in”和严格的实施过程。如果不能确保上述两点，工期延误，多种版本并存，甚至实施后没有回报的情况会接踵而至。即使勉强实施了，后期的沉重维护费用也是令人头疼的。 我们推荐创建标准的服务接口，这样可以获得最快、最直接的回报。这样做意味着强制数据类型和实体在这个企业应用中的一致性。例如，我们通常会保持日期、数目、邮编、地址的一致性。当然，增加一个数据头是一种有效保持一致的方式，正如在各种集成Hub解决方案中所作的一样。 6.3 推荐方案 高层次设计架构 对于创建新的数据转换，我们推荐采用Xquery而不是更进一步的细节 Xquery有很多优于XSLT的地方，包括更多XSLT。 使用数据模型（EDM or CDM）时需要比较慎重，需要确定获取的收益可以补偿额外的费用以及实施复杂性，且组织设计完全可以满足其实施和维护的需求。 实施数据模型会导致大量的资金投入和业界质疑，最直接的投入回报取决于接口的实现是否基于标准。 的新功能，以及更好的性能。 采用数据模型会导致耗费大量的资源，且没有实质的收益。如果可以采用一个业界验证的数据模型，可以节省数据建模过程的耗费。 必须确定在所有服务接口之间有一致的数据表现形式。例如日期、邮编、地址在各处都有相同的表现形式。 这种一致性也应包括标准的消息头等实现。 如果合理实施了数据模型或标准服务接口，消息接收者是无需了解发送系统的数据格式的。 括FES的直接调用）。 消息的组织结构对于消息接收者来说是透明的。 任何可重用的转换组件都需要有一个无状态流程的包装。 这样的封装允许其它组件以类似调用服务（包由于Xquery可以带来控件一级的可重用性，所以应当尽可能的使用Xquery。 XML Oraclens与Xquery在功能上有所覆盖，但是XML Oraclens同时也是多数流程实现的源端。 7 架构设计的基础和约束 7.1 非功能性需求 本章列出对总体架构设计提出的非功能性需求。 7.1.1 性能 系统应具备快速的系统响应能力，主要体现在以下几个方面: 1. 业务操作访问本地数据时应具有的响应速度； 2. 业务操作访问远程数据时应具有的响应速度； 3. 对本地业务数据进行简单查询时应具有的响应速度； 4. 对本地业务数据进行复杂查询时应具有的响应速度； 5. 对远程业务数据进行简单查询时应具有的响应速度； 6. 对远程业务数据进行复杂查询时应具有的响应速度； 7. 对本地业务数据进行报表统计时应具有的响应速度； 8. 对远程业务数据进行报表统计时应具有的响应速度。 所要求的“快速响应能力”应从以下两个方面去把握标准： 1. 响应速度在用户心理所能忍受的范围内； 2. 响应速度不致影响业务工作、造成业务工作的低效率。 通常情况下，事务处理响应时间<3秒，查询处理响应时间<5秒。 7.1.2 可扩展性 具有适应业务变化的能力，当系统新增业务功能或现有业务功能改变时尽可能的保证业务变化造成的影响局部化。 7.1.3 易用性 系统的可使用程度，从用户的角度考察系统界面功能实现程度等方面对易用性进行约束。 7.1.4 伸缩性 系统应该能够容纳在未来指定的时期的用户增长而不需要改变应用和应用架构.硬件的升级不能影响到系统的运行，系统不能停运。 7.1.4.1 可靠性 系统在各种极端情况下能够一致无误的执行业务操作。 7.1.5 可用性 系统对可用性的要求，避免由于单点故障或系统的升级而影响整个系统的正常运行。可以对某些重要的用例进行7x24的可用性要求。 7.1.6 可移植性 系统架构的跨平台能力。针对不同地区的技术支持技能，应用架构可以支持不同的硬件和操作系统平台。 7.1.7 可管理性 系统管理的能力，具备系统部署和升级、运行维护、运行监控、系统用户管理等机制或工具。 7.1.8 可重用性 软件架构和公共构件可以在金税三期项目中广泛的重用。 7.1.9 可维护性 软件能够被简单方便的修改和升级。包含可读性、可修改性、可测试性等。 7.1.10 安全性 能提供门户访问安全、服务组件调用安全等多种安全控制手段。
因篇幅问题不能全部显示，请点此查看更多更全内容