SOA案例：敏捷性在实践中的应用

　　这个问题的研究源自于ING信用卡，一个荷兰国际集团的分支。他描述的是面向服务的架构执行方式的第一阶段，这种服务要求为固线 (hard-wired)服务而不是动态发现的服务。他阐述了面向服务的架构如何提供更敏捷的适应业务需求的服务，并且还包括一些有益于面向服务架构执行 的内容。

　　ING 信用卡是自动化方式的一个里程碑，它连接了新的互联网，包含新的产品特色并且已空前的快捷有效的的方式保存了信用消费纪录。这是通过应用三个建设性原则而 获得成功的，而他的前瞻性在于它是面向服务的。这个案例的研究详细描述了SOA的应用方式，并且指出SOA如何帮助客户达到商业目的和挑战，以及主要金融 机构的信用卡问题分配。

　　挑战

　　信用卡业务包含两种金融服务：支付和消费者信用贷款。这种通过一张小小塑料卡片进行支付的方式之所以能够被世界广泛接受，要归功于大范围支付网 络的支持。它主要包括例如MasterCard and VISA等的信用卡方式。信用卡发行者经常会提供周转性的信用便利，它允许延期偿还。这种完整的产品经常被称作是“周转式信用卡。”

　　2002年 ，ING信用卡作为荷兰国际集团的一部分被推出，目的在于树立ING信用卡业务的中心位置并且将其推向欧洲市场。ING信用卡在复杂的信用卡交易链中扮演了重要的角色。

　　ING信用卡使用两种商标，MasterCard and VISA，他们通过读卡设备提供世界范围内的支付网络并且提供成百万的购物机会(商店、旅馆、饭店和汽车租赁公司等等)。合同通常通过申请者处理，机构 (银行)使得商人和信用卡之间的交易更加便利。另一种连接则是通过分理者形成的：处理实际的交易组织在申请者、信用卡和发行者卖出和实施交易时提供了信用 卡的权威性。

　　图1 ：信用卡世界里扮演的角色。

　　一开始，ING信用卡在IT偿付的选择过程中面临着特别的具有重要影响的挑战。

　　第一个挑战是解决那些当前没有ING账户的消费者。先前，信用卡只是为那些具有ING账户的消费者提供服务，而且只用于每月的支付。现在，新用 户可以在任何一家荷兰银行拥有一个流通账户。在荷兰所有ING消费者系统均被确认并连接到ING消费者账户;然而，这些系统却不能被ING信用卡使用。现 在需要一个完全新型的客户管理系统。

　　第二，消费将会通过直接的网上账户渠道被汇总(互联网、呼叫中心和邮件)，这种便利能够提供给客户有关他们每日交易的有关信息。并且，客户能够修改他们每月的支付账户(受限制)，通过直接渠道要求信用限制上调。

　　市场战略意味着：

• 　　互联网是基于客户需要的在线账户管理。
• 　　呼叫中心必须需要信用卡深情和客户问题
• 　　所有的进入便利必须支持所有的渠道以便通过所有渠道获得同样的信息
• 　　客户管理过程必须连接到信用卡信息处理机;信息处理机用于管理信用卡的发放，实际账户和所有的交易。

　　下面是面临的第三个挑战，这是所有发行面临的核心挑战：信用记录，这存在着管理风险。系统必须计算所有信用卡的使用价值和欺诈行为。

　　第四个挑战是有关将来发展的地改进。ING信用卡正全面推出一个跨国的包括不同产品的计划。这个系统需要具有很大的伸缩性能够支持多种地域部署，这样处理器，产品和信用记录将被迫改变。

　　对于IT崛起的最后一个挑战是由于ING信用卡在所有存在的信用卡投资组合的商业责任，在荷兰(商标)他们拥有多余一百万的用户。这意味着新系 统必须适用于所有的处理机和组织。这意味着信用记录必须扮演中心角色，并且为其他ING信用卡系统提供便利，从而为信用业务规则确立一个单一的来源。

　　简而言之，需要满足以下要求：

　　功能性

• 　　客户管理
• 　　客户网上便利
• 　　多渠道支持
• 　　信用记录
• 　　支持跨国服务
• 　　支持多种产品

　　系统特色

• 　　不同处理机的灵活性
• 　　不同产品特色的灵活性
• 　　基于同样业务逻辑的处理机

　　解决方案

　　一项为了建立初步系统的决定在早期被作出。同时决定这项措施就会被建立在ibm互联网和平台上，并且命名为“新型信用卡系统”。

　　这种灵活性需求水平最终获得了三方面的基础性建设作用：

• 　　1.分层结构(即灵活性、安全性、可扩展性和高实用性的电子商务构架N层构架)
• 　　2.面向服务(我们也定义为服务概念)
• 　　3.选择业务阶层的参数化

　　三种传统的纽带(介绍，业务逻辑，数据)通过服务层的介绍和业务模型被面向服务所加强，他们都归业务逻辑所有。同时，所有的数据链被来自于数据存储层的数据通路而分割。这一分层在图形2中用技术和技巧的手法被描述。

　　图2：全国通信系统的结构

　　显示层沟曾了外部系统，组成了一系列支持自动业务处理机的显示器。NCS通常拥有以下步骤:

• 　　众多公共互联网提供申请新信用卡的界面(www.ingcard.nl and www.ingcard.de)。这些显示屏从服务层面调出具体的申请过程。
• 　　一个紧密的安全的网络环境使客户所需要的。在这里客户可以输入指令，回顾交易和月报告，并且管理他们的账户。他们为信用限额的提高，改变每月的支付数额，二次申请信用卡和进行个人信息修改(如客户住址)提供便利。
• 　　进入呼叫中心的数据在客户方面具有同样的功能，同时在客户档案和历史数据等额外功能方面也具有相同的作用。
• 　　数据进入系统支持信用卡的申请过程。

　　根据分层建设原则，业务层只是通过显示层而变得易操作。这使得显示屏的设计要独立于业务逻辑。

　　业务模型层单纯通过服务层变得得易于操作。服务对于业务来说是具有功能性意义的。服务自身并不管理这些功能，他们只是一个表面现象，在他们后面的真正功能是业务模型层的管理。

　　一个服务能力的例子就是寻找信用注册个人，这需要在信用署的系统内找到正确的人(bkr是荷兰的信用署)，请看表格1全部内容。

　　表1：服务定义的范例

　　显示层可以和业务层相联系，“在BKR找到这个人，在这里就可以找到你所需要的数据”显示层正是依赖于这种需要和获取答复。这种设计具有三个优点：

• 　　1.显示层不需要考虑技术因素(例如，在使用前他并不需要知道所需数据的转换)
• 　　2.所需服务的次序可以被轻而易举的改变，并且不需要任何业务逻辑层的变化。
• 　　3.当执行结果改变时服务需求并不需要改变，例如，当信用卡注册个人阶层改变时，寻找信用卡注册个人却不需要改变。和传统的三层设 计模型相比，显示层独立于业务逻辑的独立性正在不断增强。例如，任务命令能够改变，或者当从外部输入客户信息时，可以利用有限的信息选择而添加网络。当 ING 信用卡在其他国家被使用时，查询信用卡注册个人的服务将会在另一个信用部门拥有另一种技术执行过程。在显示层的对话同样不需要改变，因为姓名和所需服务是 相同的。

　　第三个分类参数的建设原则在业务上被应用。这一层面包含真正的业务逻辑，像执行业务目标模型一样在这里被施行。业务目标模型决定了语言并且组成了一系列的内部关系，并通过JAVA的形式执行，如图3所示(注意里面的一些参数)

　　图3：UML (Unified Modeling Language)矩形图示中的业务对象模型

　　当分类账户，参与者和信用卡(他们只代表账户，客户和信用卡)，分类需求，规则和产品将会拥有更多的具有灵活性的参数结构。当多种多样的产品出 现在市场中时，只有数字产品分类需要改变，并不是分类结构本身。这可以通过定义一般的属性需求特点使之成为可能，其中包括产品的任何可能的特点，并且使产 品分类符合所需结构。

　　例如一种“一年免费”的特色服务可以不需要在开发而被轻易添加。真正的执行的特点在NCS并没有被执行，但是却被信用卡处理机所处理;NCS只 需要将正确的数据输入处理器。需求和规则分类也是通过同样的方式而确定的。对于规则分类有一种分离的规则，它能够使信用规则的数据具有灵活性。

　　简而言之，业务层为显示层提供服务，并且以反映信用卡管理的方式管理业务模型层的交易。业务模型层通过简单的参数分类建立。参数分类改变产品特色，信用记录规则并且不影响整个系统而完成任务。

　　结果

　　NCS通过确立自己的客户管理责任而满足需求。另外，客户可靠的服务的实现在网络上被提供(例如变更地址或者要求提高信用限制)，最后NCS也会完成信用卡申请的评估，从而降低各种信用欺诈风险。

　　设计层的三项建设原则，服务起源和分类参数在个体和集体方面对完成最初的需求举起到了建设性作用，特别是在灵活性方面。(表2)

　　表2：满足原则的需求

　　分层建设需要多渠道支持。如果相同的信息(部分功能相同)需要通过互联网向客户展示，呼叫中心或者员工，然后是在显示层和业务层之间的分离是避免完全相同的操作功能所必需的。分级参数将会被用来传送所需的时间市场的新产品介绍，并且分析信用记录和欺诈测试。

　　服务起源是三个原则中德的最重要原则。建立业务逻辑表层能够轻易的在其他国家使用NCS。同时，服务表层能够在不改变系统的前提下完善整个过程，并且和其他进程和系统灵活连接。

　　服务层所提供的最好最有力地阐述来自于国际。现在它能够相对简单在其他国家利用NCS使用ING信用卡，甚至是存在不同环境。

　　检查国家信用署，例如，需要不同位置的实施。建立连接的任务是不变的，但是所需检查的服务也不需要改变。

　　另一个例子是呼叫中心利用自身支持多种信用产品的系统的能力。当呼叫中心正在处理信用请求，使用界面和进行对话时，这个系统只需要调取合适的NCS服务。在很多情况下服务层都标表现出了特的独立性，具体如图4所示：

　　图4：不同的服务消费者再不同的情节中使用不同的服务

　　并不是现今所有的SOA都已经载NCS被实现。例如，NCS通过J2EE目标保持联系，并不是信息。因而就不存在信息载体和网络技术(SOAP, WSDL和 UDDI)，通常网络服务也不被使用。服务合同在文档中已经被确定，并且这些服务的管理是一个手动过程。

　　从表面上看，这项方法与传统方法并没有太大的区别，基于API申请。然而，这却存在重大的不同。服务并不需要特定的逻辑。换句话说，他们自己并 不执行任何工作，因为它们主要的责任是在正确的结果上完成正确的业务功能。这些服务-有服务所构成-起源-确立了一个相对独立的身份，发展了他们在传统 API基础设计上的功能。

　　NCS的SOA实施正在被分阶段所认识。在第一阶段，NCS作为一个拥有有限数字表现层的系统而存在。这就是服务为什么不需要公开化，并且能够 在不使用标准化议定书的情况下而被运用。但是当NCS的服务在其他申请中被需要时，这就需要通过正式的渠道使用他们(如网上服务)，同时提供标准机制。因 此，NCS是一个潜在的参与到互联网的复杂系统，它能够有益于增强业务的灵活性。

　　经验教训

　　虽然建设原则在NCS的发展前被选择和使用，但是在发展过程中会出现很多问题而需要新的原则和方法。

　　下面将指出一些有益的教训：

• 　　IT管理者必须为新的服务分类做好新角色的准备。SOA需要灵活的集中管理和密集的服务，以便于当随后的项目产生新功能时，相同的功能能够被长期避免。
• 　　所有参与者都必须熟悉服务起源。这包括业务赌金保管者、申请管理者和软件开发商。当任何参与者脱离这个圈子，将会有巨大的误解的风险，而且，随之而来的，将会是错误的决定的作出。例如，传统的教育的设计者他们只知道目标起源，可能过分倾向于双向服务而忽略实际功能。
• 　　服务表面化的问题(例如每项服务的逻辑省略)应该在设计过程中被解决而不是提前解决。如果不和实际功能相联系，有关表面化的讨论将会变得难以管理和无意义。
• 　　业务模型层只能够通过服务层而进入(同时被分离)，这将成为一项规定。这使操作者直接从显示层需寻求业务分类，特别当系统是独立并 且不能够和其他申请和操作层相联系时。从长远看，服务层将会受到大量的和典型的压力，同时最后的界限将会使开发商作为一个战术上的捷径而绕过服务。然而， 这种捷径在将来时间市场中将会受到巨大的影响，这将需要依赖于通过服务建立的标准化内部连接。
• 　　所有和工作相关的功能都会远离服务层。当一系列服务指令取决于系统所不能提供的外部信息时，他将会建议将这些请求输入到工作流动层。这保留了作为不可知资源的服务，使其能够在将来被重新使用。
• 　　在模型之间持续使用这项工具的能力被高度称赞。在NCS的发展项目中，为分类使用单独的工具，灵活性和结果曲线证明是能够充分节省时间的。

　　结论

　　服务架构是一个不同的建设方法。因而，SOA的概念只是一个系统的定义，特别当这个系统需要和其他系统或者是显示层共享功能时。服务架构跟随着 作为下一代分配计算的组成基础设计。服务能够被确定为对于业务具有一定意义的表面化服务，同时是抽象的技术组成部分和应用方式。面向服务的架构能够帮助组 织获得他们所需要的灵活性和机动性，并且在ING信用卡的使用中已经被证明。