识别服务的十种方法(二)

日期: 2009-04-08 作者:Jan-Willem Hubbers翻译:杨君 来源:TechTarget中国 英文

方法3:业务实体对象   这些服务背后的目的是为了处理业务信息。按照业务对象模型模拟服务,我们可以识别建立在业务实体基础上的服务,这个过程需要CRUD-类功能。这个方法需要使用规范数据模型(CDMs),这些数据模型可以标准化服务间传递的信息。因此,你可以将其看做是以供应为驱动的方法。

  规范服务要依靠技术资源,这些技术资源使用的是自己独特的数据模型。通过在应用数据模型和CDM之间达成映射,可以实现数据连贯性。因此我们可以通过许多不同的应用来管理数据要素,这些数据要素中包含了单一的CDM对象。几乎所有非ESB产品都支持CDM。

真正的问题是要在定义共同项目时达成共识。   这个方法关键性的一点就……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

方法3:业务实体对象

  这些服务背后的目的是为了处理业务信息。按照业务对象模型模拟服务,我们可以识别建立在业务实体基础上的服务,这个过程需要CRUD-类功能。这个方法需要使用规范数据模型(CDMs),这些数据模型可以标准化服务间传递的信息。因此,你可以将其看做是以供应为驱动的方法。

  规范服务要依靠技术资源,这些技术资源使用的是自己独特的数据模型。通过在应用数据模型和CDM之间达成映射,可以实现数据连贯性。因此我们可以通过许多不同的应用来管理数据要素,这些数据要素中包含了单一的CDM对象。几乎所有非ESB产品都支持CDM。真正的问题是要在定义共同项目时达成共识。

  这个方法关键性的一点就是要在早期的建模阶段关注服务语义。当项目接近生产阶段时,可以最大限度的降低设计中出现的不良变化。

  这一方法的一大陷阱就是对标准化数据模型的需求。依靠SOA项目的规模,这个要求会导致“分析瘫痪”,尽管在交换数据(需要模拟的数据)时,只有业务对象发挥作用,基于域上的服务远景图可以帮助我们克服这些问题(有关建立全球数据模型的问题)。

  方法4:所有制与责任

  这个方法并不是一个“真实”的方法,但是在考虑提供何种服务时,强烈推荐这个方法。在SOA决策过程中,明确地为流程分配了角色、为服务分配了责任,这个决策过程也需要一个明确定义的结构。在标识服务时,责任方要确保某些必须功能的可行性,这个过程将最决定最终提供哪些服务。

  当然,系统的设计方法在这个流程中起到了一定的作用,但是在最后的决策阶段还要考虑很多方面:开发成本、维护费用、基础应用和平台的生命周期管理、优先顺序、人力资源的可行性等。

  这个方法最大的好处就是明确规定了服务的所有权。在其它方法中,这个问题往往成为争论的焦点,有时甚至会产生不良后果。另一方面,不同域的服务最终会叠加在一起,因为其各自的所有权结构。此外,机构还要拥有一个功能治理平台,这表示还缺乏普遍的成熟度。

  方法5:以目标为驱动

  利用这个方法,项目小组可以将公司的目标分解为不同层次的服务。在这种环境下,单个服务被看成是某个可以通过自动化支持[REF-5]而执行的目标。例如,一个像“增加客户保持力”的目标,这样可以产生一个叫做“为了忠诚方案注册客户”的服务。

  这里明显的优势就是服务和公司策略之间形成了很强的关系。但是,这个方法还有两个明显的问题:目标的主观性似乎很强,IT很难与业务目标相吻合。

  主观性可以将两个业务目标分解为不同的服务,尽管所需的功能是相同的(这意味着最好使用一个单一服务)。同样,很多IT功能并不是直接和业务目标直接联系在一起的,许多潜在的有用服务可能被忽略掉。

  方法6:建立在组件上

  使用组件的目的是为了将IT功能划分为不同的单位,这些单位通常带有最大的内部连贯性和最小外部耦合性。组件是自含功能单位。在基于组件开发领域内,先后引进了许多识别组件的方法。这些方法的指导原则是:每一个组件只有一个所有者,每个组件的职责得到了最大限度的确定,我们可以将这些职责作为识别服务的出发点。

  理论上讲,基于组件上的开发会产生一个建立在功能上的IT企业。你可以自定义编码这些组件,也可以离岸购买它们。此外,还需要将组件提供的服务分解为复合服务。目前,大型单片机应用供应商(例如ERP和CRM)都倾向于用模块的方式组织自己的应用,并且要确保能够在服务范围内能够使用这些应用。模块和组件大致上相互对应。

  将服务建立在组件上可以简化识别流程。许多分析工作不过是基于组件开发方法的一个组成部分。但是,在现实中,这样会引发一些问题,现今,服务和传统组件很少拥有共同目标、要求和期望。要创建一系列细颗粒服务,能够反射基础组件,在实现战略目标的过程中这些组件一般都包含一个SOA措施。但是在最初设计组件时,并没有考虑到战略目标。

  方法7:现有供应(自下而上)

  快速定义服务的一个较为实用的方法就是在对信息和功能的直接需求上定义服务。在这种情况下,要从由现有旧应用所提供的功能性着手。这时需要选择能够提供自动化支持的系统,业务流程往往需要这样的自动化支持。

  本质上来说,这一经典的自下而上方法是由供应所驱动的,它并不关注被识别服务的可重用性或者(重用性)。因此最好将功能性集中起来,通过将相似服务结合成一个单一服务(通常是单片机服务)去除功能叠加。

  自下而上交付有一个好处,它所要求的最初定义服务的时间很短。如果这是一个合适的方法,如果目前急需现有应用,足够支持现在和未来的业务流程。这个方法的负面影响是,使用这种方法的环境中,可供使用的流程和功能模型往往十分有限。

  但是,我们不推荐用这种方法定义服务,支持服务定向。在不良应用中,问题守恒定律就显得丑态百出,我们经常利用这个定律来改变环境(该定律紧密的和业务流程耦合在一起),这样便更难设计可重用以及不会过时的服务,最后,使用这种方法总要创建新的应用栈。在当前这种情况下,栈本身也是服务。

相关推荐

  • 给云质疑者的忠告:不要误解Dropbox

    我们的IT部门很少陷入新的IT产品或者服务,特别是像云计算这种古里古怪的的东西。他们把全部精力放在公司的生意和运营上。但是有时,一些新的事物的到来,使得所有人不得不重新思考原来的做事方式。

  • 松散耦合的七个级别

    在软件领域,“耦合”一般指软件组件之间的依赖程度。那么,什么是依赖?各种依赖对耦合度和松散度有多大影响?软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中,为了确定系统的耦合程度,必须分析各个级别。下面我们就来具体看一下。

  • OSGi中间件平台集成SOA组件

    把新的组件整合到一个中间件堆栈中是一种耗费时间的考验,中间件厂商WSO2试图通过发布Carbon 3.0平台解决这个问题。

  • 从画皮SAP看国际IT厂商的内幕

    上周,一篇《画皮SAP——世界最大软件公司的中国真相》在IT业界掀起了轩然大波,一场围绕SAP、管理软件的大讨论激烈的展开,各方观点莫衷一是……