e="ld:
项目组DataServices/sample/">
S_INFO>
string
string
string
--Optional:
-->
100
--Optional:
-->
100
S_INFO>
●服务组件返回值传递格式（重点看结构）如下：
ArrayOfESTUDENT
S_STUDENTxmlns:
ns0="ld:
项目组DataServices/sample/E_STUDENT">
183
divStudent1
143
S_STUDENT>
ArrayOfESTUDENTDocument>
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++/MiscLibrary）：
包含完整的特定语言实现的库，以Java库为例，应包含完整的可运行的Java程序（JAR文件）、标准Java文档（javadoc）、完整的源代码包（可选）、创建脚本（可选）等。
✧服务（Service）：
可重用服务组件提供为一种服务，应包含服务的描述文档、使用文档（用户手册和程序员指南，如果需要的话）等。
✧其他（Misc）：
其他类型。
☐服务组件功能描述：
简要描述可重用服务组件的功能、范围，必要时提供完整的需求文档。
☐其他要说明的问题。
2.接口描述：
描述可重用服务组件提供的接口信息。
3.接口用法：
描述应用软件使用可重用服务组件的方法和注意事项，规范化可重用服务组件被使用的方式。
4.附件和参考资料：
引用重要的附件和参考资料。
4服务设计流程
4.1什么是服务设计流程?
给一个特定的整合用例，解决方案设计者将首先中止用例到一组服务，他们一起来迎合需求。
然后服务设计流程是一组行动，他们将为每个服务设计。
服务可以或不可以存取任何远程系统，例如数据转换可以作为一个可重用的服务来实现是可行的。
4.2什么是服务设计流程的输入?
典型的，为任何给定的整合用例所作的服务设计流程的输入如下所示。
请注意尽管时间表，资源约束和价值约束能影响流程，他们不包含在这部分中，这部分集中讨论设计流程的技术方面。
●功能需求这将包括数据输入，数据输出和用例需求的行为，特别根据企业中任何受影响的状态更新。
所有被包含的系统将被列出，还有他们之间所有被要求的交互。
服务所需要的有条件逻辑和任何其他的逻辑流也是功能需求的一部分。
理想的，功能需求将包括任何所需管理的描述。
●非功能需求这将包括所期望的测定体积的，需要的响应时间，可用的需求，安全需求和服务需求的质量。
●最佳实践和设计模式这将包括用WLI8.1产生的任何类型的最佳实践和设计模式，包括文档。
●解决整合问题的前车之鉴这包括设计人员的经验集合。
●现存解决方案库这将包括任何现存的解决方案和服务的文档。
服务设计流程的输入
当为用例看一个非功能的需求，为需求考虑以下SMART标准是有用的：
具体的：
不模糊，用一致的术语，简单并且在内容适当的水平。
可测量的：
验证这个需求已经被满足是可能的。
什么测试必需被执行，或什么标准必需被迎合来核实需求被迎合？
可得到的：
典型可行的。
什么是你的需求可行性的专业判断？
可实现的：
现实的，特定的资源。
你有雇员吗？
你有技术吗？
你对所需的开发架构有存取吗？
你对所需的运行时架构有存取吗？
你有充足的时间吗？
可追踪的：
通过对系列设计，实现和测试的详述从概念链接。
高层次的设计构架
更进一步的细节
非功能需求应该执行SMART标准。
经常是这样的情况，你有许多需求相互矛盾，或者那被描述的太一般来保证成功的实现。
4.3服务设计时的步骤是什么？
根据特定服务的需要，服务设计流程能被分解为下列行为：
1.解决通信和连接问题这定义了已发布服务接口，任何从服务消费者到SOA平台的连接，任何从SOA平台到BES的连接，还有SOA平台内部组件间的连接。
2.解决数据处理问题一旦通信和连接问题已经被确定，这将提供需要通过数据翻译和转换来解决的数据处理需求。
3.设计流程这讲述了有关同类逻辑，任何步骤顺序，有条件的逻辑和任何其他执行规则的设计。
图1:
整合服务设计重复流程
我们推荐按顺序执行这些步骤，因为通信问题有充分的理由表面化数据处理和流程设计的需求，并且数据处理问题有充分的理由表面化流程设计的需求。
早先观察连接需求的另一个原因是有时候它将为得到或者开发展现一个需求，然后为新架构接受测试——例如控制或者适配器。
这必须尽快被确认来使风险管理能够有希望的减少服务传送时间。
如果有不少人投入到服务的设计中，则在这个流程里可能得到平行系统，但是事实上任何阶段的需求将由其他需要入帐的活动产生。
上面的流被重复的显示，因为它看完数据处理问题之后，再次访问通信问题通常是值得的，并且流程设计能够影响为通信和数据处理所作的决定，也在这两个领域介绍了新的需求。
在没有验证接口文档和标记而进入开发已经是一个非常大的项目风险，因为这些适合多流程的第一步。
高水平设计向导
详细内容
我们推荐这些步骤按顺序执行。
通信问题有充分的理由可以表面化需求，适合数据处理和流程设计，并且数据处理问题有充分的理由表面化需求来适合流程设计。
这也确定了任何组件需要在项目早期产生和发展。
4.4一个服务的主要特点是什么?
假设一个端到端的整合用例，这样一个用例可能被分成更多的服务，每个都需要适当的设计。
这个端到端的服务和任何组件服务都是服务。
一个服务将有一定数量的特点，这对服务的设计将是十分重要的。
对于一个特定服务的设计者它将是非常重要的，能在这些区域里分类这些服务的特点。
首先，基于它的设计，一个服务有一定数量的属性:
1.复杂性:
●基本的——被定义为一个对其他组件进行一次调用的服务
●合成的——被定义为一个对其他组件进行多于一次的服务
2.调用范例：
●同步的——当服务完成时这种服务的用户将阻塞来等待回应
●异步的——当服务完成时这种服务的用户将不阻塞来等待回应
∙混合的——这将是一个同步部分接着异步部分的服务.
3.交换范例：
●双路——需求/应答
●单路——激活和忘记
上面描述了服务属性，它被服务设计者决定，服务有很多特点来自非功能需求：
4.体积：
●高——每秒超过100个服务调用
●中——每秒1到100个服务调用之间
●低——每秒少于一个服务调用
5.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单向－fireandforget。
∙事务性支持。
包括对传递性事务性的支持。
∙数据格式支持，如XML，FML32，后者会在下文中描述服务数据处理的部分有所提及。
5.2发布的接口
发布的服务接口是指为SOA平台外部的服务请求者发起请求暴露的接口，依据不同的流程设计提供发起请求适用的协议选项。
请求首先初始化服务。
注意，发布接口是为实现松散耦合和可维护性的考虑结果。
服务请求应当可以使用多种相异的协议或技术。
下文中将围绕于此进行各种相关技术的讨论。
高层次的设计构架
更进一步的细节
需要为现有的发布接口形成一套资源库
这套资源枯中需要包括描述服务的文字，尤其是一些副作用，升级等的描述。
对内部服务的描述也应包括在内。
在资源库中存在的所有服务应当以一种标准的方式进行描述
包括服务设计的需求，实施特点，核心的设计考虑等。
5.3哪些工具可以帮助更好的解决连通性问题？
以下的平台特性都是与连通性有关的：
∙WebServices
∙JMS，MessagingBridge
∙适配器，应用视图
∙控件
∙EventGenerators，MessageBroker
∙纯HTTP.
∙B2B（ebXML,RosettaNet）.
下表中有关连接特性技术列表将为您提供一个可能选项的高级视角，3.3中针对下列使用逐个讨论每个特性：
∙访问者连通性
∙后端系统连通性
∙内部连通性
3.4中包含部分推荐使用的特性。
同步/异步
事务性
安全性
备注
基于HTTP的WebServices
均可支持
不支持
支持
WebServices/基于JMS
异步
支持
支持
ConnectionpoolingthroughMDBpoolsizefortheJMSdestination.
JMS和MessagingBridge
异步
支持
支持
ConnectionpoolingthroughMDBpoolsize.
适配器和应用视图
均可支持
支持
支持
控件
均可支持
支持
支持
Connectionpoolingdependentonresourcecontrolisaccessing,e.g.JDBC.
纯HTTP
同步
不支持
支持
B2B
异步
支持
支持
连通性特性的技术列表
5.3.1WebServices
最新的WebServices标准不支持事务，应该说这个领域的标准正处于一个酝酿时期。
WebServices安全和WebServices可靠性是另外两个正处于萌芽期的标准内容。
WebServices多数都是架构在HTTP协议之上，籍此可以获取最佳的传输或累次操作，并利用JMS获取可靠的传输。
5.3.1.1请求连通性
Gartner的DarylPlummer写道，“WebServices最有价值的地方在于在发布接口时利用了WSDL作为接口定义语言（IDL）。
大多数接口定义语言都与语言（如Java）绑定很紧，或是表现为一个组件模型（如CORBA）；相反的，WSDL是与语言和模型无关的。
类似于接口与实现的分离，接口定义也理应与底层的实现技术分离开来。
您可以在任何SOA环境中使用WSDL定义。
”
因此，WebServices具备为服务描述发布接口的能力，而且由于使用了WSDL，此种描述是基于标准的，它使得服务可以被处于任意环境中的客户轻松访问。
一般来说，现代客户系统将有能力以WSDL作为一种服务并且产生对WebServices产生需求的代码，ORACLEWorkshop可以为WeblogicWebServices产生WebServices代理类。
5.3.1.2后端系统连通性
对于那些从SOA平台到暴露了WebServices接口BES的调用，WebServices是连通性的一个选项，但是考虑到对于可靠性，事务性以及WebServices之间的安全性传递的缺陷，这一领域当前仍然是非常不成熟的。
不过逐步的，BES也正在向暴露成WebServices的方向发展。
5.3.1.3内部连通性
对于SOA平台内部的交互性，尤其对于一个分布式架构，采用WebServices会变得越来越重要。
考虑到WebServices栈对于编解码过程来说是相当昂贵的，而且无法在通过一个WebServices调用来传递事务，后者是更加主要的限制。
5.3.2JMS，MessagingBridge
JMS是一个J2EE子系统，用来实现减弱消息处理。
WL平台还包括一个MessagingBridge的特性，用来桥接本地和远程消息队列。
利用MessagingBridge，远程队列可以是远程的WLS域中或非WLS域中的JMS消息队列，甚至可以是远程非WLS域中的非JMS消息队列，如MQSeries。
在支持连通性方面，JMS可以作为访问任意J2EE平台，或多种具有JMS接口的MOM产品的方式，因此受到广泛支持。
通过配置，JMS可以支持上述质素不同的多种服务（QOS），包括最多一次（At-Most-Once），仅一次（Exactly-Once）等，当然，接收系统的能力也是其中的一个影响因素。
在需要连接远程消息队列必须选择MessagingBridge，因为任何的JMS访问对于客户端都是本地的。
M
升级会员 