SOA(service-oriented automation 面向服务架构)对于企业的循环发展,以及企业的协同工作是非常有利的,因此SOA被视为组织化的自动管理方法。SOA已经不仅仅局限于对某一个问题的处理。通过适用性实践证明,我们产生了一些不同的想法,即为各个不同领域的企业提供定向的阶段性服务。人工编制和筹备那些具有约束性和预定性的核心设计说明,管理计划报告和包含所有应用功能的基本服务工作统计。
其实,很难想象将技术接口应用于业务服务中去。一般来说,人们习惯于将Web服务视为在某些自动化领域的技术延伸和辅助应用。但是,如果有一个IT小组对应于业务服务,设计了一组服务接口,并且强制将其应……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
SOA(service-oriented automation 面向服务架构)对于企业的循环发展,以及企业的协同工作是非常有利的,因此SOA被视为组织化的自动管理方法。SOA已经不仅仅局限于对某一个问题的处理。通过适用性实践证明,我们产生了一些不同的想法,即为各个不同领域的企业提供定向的阶段性服务。人工编制和筹备那些具有约束性和预定性的核心设计说明,管理计划报告和包含所有应用功能的基本服务工作统计。
其实,很难想象将技术接口应用于业务服务中去。一般来说,人们习惯于将Web服务视为在某些自动化领域的技术延伸和辅助应用。但是,如果有一个IT小组对应于业务服务,设计了一组服务接口,并且强制将其应用于各个项目中去,那么将技术接口应用于业务服务的可能性就变成了SOA模式下的实践工作了,这是很值得关注的。
这篇文章将为您具体讲述和说明,在建立一个SOA的应用结构体系中,我们是如何进行具体的实践工作和分析工作的。建立一个全球性的SOA模式的路标图,不仅需要做非常多的实践工作,还是一个难度很大的命题,因为不同优先级的组织又是不一样的。但是被提及的方法中首先应该先将其视为同等级别的,然后再集中定义业务需求,风险和战略目标以及所有其它因素为专门的路标。
SOA实例:
首先,定义一些关键性部分,这些部分是我们在完成SOA编制过程中是具有战略意义的。
第一:服务追踪。
第二: 例外处理。
第三: 译本管理。
第四: 服务管理和调配。
第五: 安全机制。
第六: 权限和级别管理。
第七: 服务目录。
根据所定义的这些关键性部分,建议使用如下的方法和思路:
服务追踪
适用性 | 一项服务及其同等级别的服务(SLA)的激活条件定义,一般都需要考虑的问题,如下: 1. 什么时候激活此项服务,需要为此建立激活调度公式表和时间顺序表。 2. 在某项服务被激活时,判断这项服务的所有依赖的因素是否被激活。如果这些依赖因素没有被激活的话,那么此项服务依旧是未被完全激活的。 |
日志系统 | 系统的底层服务应该对每一项服务的访问和运行模式进行记录。这些记录数据对错误查询和追踪,及安全控制都是很总要的。外部的事务会滚进程需要能顺利的读取日志。统计日志系统中的数据,还可以知道系统的各项服务使用的频率,这为对系统底层服务,特别是安全性和定量测量服务,进行改进是很重要的。 |
审核系统 | 所谓审核系统就是对日志信息的分析和报告。这个阶段的数据采集及分析主要用来解决以下问题: 1. 服务运行的正确性如何。 2. 什么用户使用了某项服务。 3. 都交换了些什么样的请求和回应信息。换句话说就是最能满足交流的摘要信息是什么。 另外,通过审核还可以更好的了解一项服务是如何运行的。那些由系统生成的报告,还可以反映出系统运行性能。 |
运行标准 | 制定针对每一项受限Web服务的运行标准和规则是为了使每一项服务能够被侦听,以防止潜在超时运行,如存在网络瓶颈和发生计数错误的时候。因此,一般都需要有自动警告机制系统来收集和处理统计数据,使其能在进行底层服务检查前得到处理。 |
调试和追踪 | 在开发过程中及在以后的功能拓展过程中,优化和追踪服务的活动都是很重要的,特别是对后期的维护。在关注平台的工作性能时,当存在服务与一般的报告特征不符时,其可以提供前端工具来对指定的目标服务或其子服务进行跟踪和记录。 |
综合事务处理 | 综合事务处理功能可以为开发,测试和调试提供相应的使用环境。其还可以依据先前的服务设定来周期性的发送服务请求。 |
例外处理:
错误捕捉 | 运行时间错误需要尽可能的被记录和报告。举例说明:错误捕捉需要记录响应时间和超时设定,这些都要被追踪纪录从而保证相应的SLA请求串行执行。 |
错误根源分析 | 一般来说SOAP的错误是没有什么价值的。但是一个SOA体系结构是需要对一个服务为什么失败来进行深入分析的。这些错误经常揭示出编码错误或是硬件不兼容等问题。使用合适的工具,那么一个真正的错误根源分析就可以完成了。 |
错误告知服务 | 这项服务主要是,当某个特殊事件被触发时,来发送警告的。而这个警告机制是可以用来进行配置的,从而可以分别符合个人和大众的使用需求。 |
译本管理:
数据协议 | 网络数据交换使用先前约定好的基于XML规划下的数据模型进行通信。将数据使用公共协议打包封装,然后发布。如果不遵守这个协议,那么将会对所有在线的服务对象造成危害。如果数据协议必须修改的话,那就需要做一些与之相匹配的版本控制工作。这主要要考虑XML的主要形式经常会做一些维护和来自服务层的更新。 |
消息和操作协议 | 服务对象和服务商通过服务接口紧密联结。不过,现在如果再添加新的服务协议而不影响现存的用户是可以实现的。存在着一种约定俗成的模式化步骤,即使要将操作加入已存在的WSDL协议中。 |
终端 | 服务对象被约束在服务终端处。如果服务终端发生变化,那么所有的激活服务都将受到影响。因此设置一个独立的终端或者是地址管理器是很有效的。 |
规则 | 缺乏工业化的表述性语言,文档和关于标准技术服务协议的附属规则,虽然有过WS-Policy,但其离实际应用还很远。一般的观点认为,应依据伴随性SLA来设置规则。虽然规则的制定是需要的,但是SLA服务经常需要用户遵守规则。强制执行规则有时候就不得不让服务享有者签署保证协议或SLA文档来确认所有的规则都被遵守。 |
内部依赖 | 一项服务的运用,会使用包括众多私人组件,数据库和其他系统资源。改变这些依赖都可能引起运行时间意外。因此,内运行需要确保每一项单独的服务级别的技术体系结构具有独立性。 |
请求权 | 服务商可能会提供一般的身份验证技术,例如说一个活动角色和用户目录。任何安全体系上的改动都会影响所有使用此项服务的用户。对已确定的安全管理进程和实例进行修改,需要慎重的考虑,可能的话还需要由委员会进行外部回滚。 |
注销服务 | 服务不是永远进行的。当某项服务不再被使用了,那么服务对象需要及时通知,从而改变其系统环境。服务业务的改变经常要经历一个平滑的适应期,这个期间新旧两种版本的服务协议会同时存在。有时候这个时期可能长达6个月。 |
依赖性分析 | 服务对象可以被分为可预知型和不可预知型。将所有的用户与其相关的服务类型相联系,建立一个表单。依靠这个表单,就可以很简单的有组织地完成某些版本变更通知。 |
服务目录:
操作方法 | 在操作方法中,以Thomas Erl主流SOA操作为例,需要定义一项服务在整个运行周期中是如何运动的,同时要建立与之相关的支持SOA的各个需求阶段是怎么建立的。除了为了要执行服务,要对其进行逻辑划分,这些外部形式进程同样要支持管理系统对其进行标示,从而使管理系统可以有效的对其进行管理和拓展 |
标准服务传输周期 | 需求分析、业务流分析、服务模式分析及在整个服务周期中的各传输阶段都要被串行列入定向服务模式中去。这不一定会取代定向对象模式的方法,但是服务的运行和完成需要反映设计的理念,即在各服务阶段需要完成什么样的目标和后台服务程序是怎么运行的。 |
安全机制:
身份存储 | 身份存储主要是对用户及其相应的认证和运行参数的存储。为了在服务运行中保证安全性,用户需要验证自身的身份正确。很多的方法被尝试过,例如活动目录和数据库存储。比较理想的方法是标准中央式底层验证机制,但是这要求这个方法一直被合理使用着。 |
验证和许可 | 由于需要对用户的身份进行验证,因此要产生很多需要考虑的因素,包括怎样有效的完成安全请求。 |
通信协议 | 这一部分需要解决协议是如何在服务端,用户端和用户持有者之间运行的。 |
网络边界安全 | 当服务要面向由复杂的网路和延伸的Web服务时,这就与防火墙和外部服务器接口有关了。实际情况中,经常需要对安全性进行度量,并且还要对一些无法预料的访问进行处理,有时候可能要对外发布这些更新的信息。 |
控制和测量的使用 | 出于很多因素的考虑需要理解服务的使用方法。例如,要让用户明白服务的每一项基础功能,最终学会使用服务。 |
安全传输 | 要解决网路通路安全,经常要涉及到SSL部分及少量的WS说明,这些一般都要经过讨论。 |
数据平衡 | 当服务需要承载多数据和不可预知的数据量时,这就需要利用多线程服务来将数据进行分散平衡处理。有很多的数据平衡算法,因此服务要能判断哪一种算法是最适合数据平衡运算的。有时候由于重新利用和重新编写工作的增加,服务的数据平衡算也是需要更新的,来应对新的使用要求。 |
地域划分 | 在实际工作中,在一个企业内部往往存在着某个服务群体本身就离的很近。 例如,一些用户需要各种服务,但是其用户所在地还离的很近,因此要尽量减少服务的潜在溢出。 |
Web服务的协同工作 | Web服务本身就是能进行网络化的操作,其中强制使用WS-I的基础外模式(Basic Profiles,BP),这是唯一的方法保证各项操作可以跨越不同系统平台和组织分界线的方法。当建立一项新的WS技术协议,特别是有不同的企业买主,不同的扩展和不同BP分类用户时,尽管这些方法很可能会限制网络和控制环境。 |
服务水平
质量 | 服务供应商经常会向服务对象承有高质量的服务。同时存在有服务质量担保人和服务质量规则。 |
记录表 | 无论一项服务是否在内部公司或外部其他组织内受欢迎,都须要建立一份服务记录表,毕竟服务的供应者应当得到回报。一般,每项有着专利的服务都会向其客户所要大量的服务汇报。 |
结构管理 | 每一项服务因为不同的环境,就要进行改进,因此需要再进行注册和测试。当存在很多项服务的时候,管理全部的服务的注册的工作就可能变得很复杂,很可能需要外模式进程。对服务的结构管理可能比传统的工作模式要有效的。因此,新的工作模式会很快德得到发展和推广,而结构管理会在SLA中得到展现。 |
服务目录
已知内容 | 服务的用户必须知道服务的供应商和协议地址。在一个公司内部这些已知信息将会大范围传播。UDDI发布了所必需的工业化标准。当然,只是知道这些服务的信息并不代表就可以使用。 |
发布工作 | 一旦要使用某项Web服务,那么就需要在本地进行服务注册。外模式进程需要保证注册和元数据资料结构一致。 |
订阅 | 让每一个服务用户订阅服务目录纪录是一个很好的主意。如果对服务的协议进行了添加或消减,包括一些与服务有关的事项,例如改变了目录频率,用户程序很容易的就可以提示用户注意这些变化。 |
联系咨询 | 享受服务的用户或者是设计客户服务的设计师可以与服务商和管理员联系,从而了解更多的关于此项服务的问题并且提出建议和意见。特别是对大型的组织,最好将协议信息与服务目录一起发布。 |
说明 | 服务注册时同时配发说明,这样可以使那些未来的服务使用者更好的了解服务的功能。这些内容将被独立的发布,并作为技术服务协议的附件说明。 |
评估 | 为了保证质量目标,每一项服务都应可以让用户进行评价并提供反馈结果。特别是在SLA中,对安全性和承诺的评估,可以作为对真实服务运行时间表现的定量测量。 |
SOA 执行监察表模板
没有一个固定的顺序规定以上的那些项目那些需要进行,那些不要进行。每一个组织机构都有自己的一套方法,这些方法都是基于自身情况来进行转变或移植。一个简单的Excel模板都需要经历很多的个人实践。你可以使用以下的一个SOA模板来检验你是否已经将所有的因素考虑了进去。
这个模板所提供的列如下:
1.阶段:
要将某个实例加入到某个阶段中去,那么就要参考这个组织的优先权和风险度。在缺省的状态下,我们就用四个阶段来定义这个模板。一些实例可能和早期的阶段相混淆,例如说,我们习惯上认为应该将所有的一些或所有的动作都与安全尽可能早的莱西起来比较理想。
2.产品:
可以从来两个方面来介绍实例,分别是应用技术和使用方法及步骤。应用技术因素可能会同时涉及到产品和客户的自行开发。而使用方法及步骤则需要融合技术理念,从而能坚定不移的执行和贯彻。使用方法及步骤需要在实践中得到体现。这一列提供了如何参考与应用和推广相联系的技术。
3.习惯拓展:
有一些实例可以允许用户进行开发。例如,鉴别一个服务对象是否和现有的一个对象库存在冲突,这就需要在客户端进行一些拓展开发。
结论:
我们在完成SOA模式的路标图的过程中,共得到了37种实例和思路。当将其以传统的SOA方式汇总后,再添加其余的项目。每一个组织都有其各自不同的需求,这些需求与自然或者是先前使用的伴有强制约束性的SOA系统有关。总之,完成SOA模式的路标图总是从一个简单的列表开始的,就好像只有一个支持者在使用,再一步步确定中心思想,这是完成外部实例的第一步。
作者
相关推荐
-
SAP收购CallidusCloud 与Salesforce竞争
一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。