SOA解决方案中涉及的遗留系统的设计策略(4)

　　要考虑的设计策略

　　为了构建支持总体企业遵从性的可靠信息管理体系结构，可能考虑采用针对此问题的各种设计策略与原则。

　　在业务流程分析中对范围变更进行规划

　　在转换项目进行期间，经常遇到这种情况，通过系统分析和设计发现了一些不希望出现的数据处理场景。可能需要将之前在范围之外的业务操作纳入范围中，以便能够对其进行修改，以接纳一组新系统。新的基于SOA的系统甚至可能需要提供内部应用程序，供这些已经更改的业务操作使用，如用于更新某些客户详细信息的外部处理步骤。

　　发布和订阅遗留实体变更

　　当作为服务者参与的遗留IT系统中已得到一致认可的实体和属性数据发生变更时，需要开发外部处理步骤来告知SOA。理想情况下，这应该是实时的，但此工作实际经常以计划批处理活动的形式进行。在旧式非结构化应用程序中，向遗留IT系统应用指令代码来检测数据记录发生更改的时间的做法可能开销非常大。

　　您的企业必须进行的一项工作是，要评估遗留系统所拥有的数据以及系统通知更改的相关方的能力。如果频繁更改对SOA非常重要的数据，而遗留系统又无法生成记录级别的事件触发器（以便最好地进行日常批量提取工作），则可能会需要进行再工程，或替换遗留系统。确保业务服务的QoS与计划的工程工作一致。说明在进行事先计划的增量工程改进工作（如从关键服务数据每日批处理的方式过渡到实时的消息驱动处理）的情况下，QoS将如何随时间的增加提高。

　　信息服务查询Facade

　　信息管理服务的操作应该提供能够应用于数据或内容的简单操作。查询Facade隐藏了如何访问和操作信息以及如何跨多个物理IT系统的细节。基本上来说，查询Facade可以实现两个模式来实现数据集成。由于企业中存在很多方案和遗留系统，很可能将同时使用这两种方法来实现服务：

　　·将数据带到查询中。将变化慢的信息整理到承载数据存储区（例如，仓库），并在其中对数据进行操作。可以在此处使用提取、转换和加载（Extract, Transform, and Load，ETL）技术。
　　·将查询带到数据中。对于快速变化的事务数据，操作必须进入物理源中对其进行操作。可以使用连接器和适配器技术来进行此类访问（例如读取和更新）。

　　在SOA中，实际查询Facade可以使用各种模式实现，如联合与填充（有关更多信息，请参见参考资料中的“数据集成应用程序模式”），还可以使用服务数据对象 (Service Data Object) 和数据访问服务(Data Access Service)等技术（请参见参考资料）。各个服务实现的总体设计模式将影响这些决策；有关更多信息，请参见“Toward a pattern language for Service-Oriented Architecture and Integration, Part 1”（developerWorks，2005年6月）。但在此问题中，将需要对实现设计进行扩展，以让服务更为智能化。假定已经为遗留系统配备了发布实体数据变更的解决方案（达到认可的QoS水平），信息服务需要订阅变更（哪些数据和频率如何）并将变更应用到相应的基础物理系统，如执行数据同步的物理系统。

　　而这正是在体系结构的此处做出主要实体决策。哪个遗留IT系统应该视为主系统，在哪些事务场景中应这样处理？主数据管理技术可在此处为您的实现提供帮助，不过这些选项及决策（与遗留系统的集成能力进行权衡）应该是体系结构定义中非常重要的部分。

　　业务规则放置

　　到SOA的转换引入了新IT基础设施，其中包括集成中间件和新组合应用程序以及其他实体。业务规则不再包含在应用程序中。状态通过业务规则的执行有效地进行管理。作为开发信息管理设计的一部分，必须了解业务规则逻辑的类型和位置。

　　SOA中的业务规则的类型包括：

　　·引用完整性规则
　　·应用程序行为规则
　　·跨应用程序完整性规则
　　·事务处理业务逻辑规则
　　·数据实体处理规则，如存储过程

　　应该重用此类策略，而不是重新生成业务规则。随着SOA的引入，必须仔细地考虑现有业务规则和新业务规则的执行（以支持服务的可靠执行）。规则逻辑本身（无论其位于上下文中任何位置）可能需要作为服务公开，以便能调用来维护特定处理场景的完整性。

　　潜在设计策略影响

　　做出这些决策时必须考虑的解决方案的潜在影响包括：

　　·双密钥处理。通过引入SOA而获得的业务领域的效率需要与额外的数据输入任务（从而增加了数据输入错误的风险）进行权衡。但这可能是用于处理数据同步时间确定场景的唯一选项。通常并不会轻视这些场景。您的企业需要建立人头计算来执行事件驱动的双密钥生成，从而避免由于夜间批量更新造成的时间延迟。需要通过在系统中开发自动接口来帮助进行数据同步，以抵消此成本。这个循环分析应该评估实现自动化接口（特别测试）所需的时间是否对总体交付时间表造成影响。
　　·不必要的反馈循环。对CRM系统中的客户记录的更新之后紧跟对SOA的手动或自动调用，以告知其他应用程序这个意外的客户数据变更。为了更新客户，SOA将调用其信息服务，该服务本身将调用原始CRM系统并更新客户数据。根据用法模型不同，信息服务体系结构需要实现不同样式的update customer操作。
　　·范围渐变。定义SOA范围声明时，缺乏遗留IT系统的知识，不了解哪些流程和信息管理功能一定将更改。服务模型的派生对遗留分析起到促进作用，只会发现需要更多的SOA基础设施实现。在定义业务服务和工程计划的整体范围前，需要考虑发现阶段的预算和规划。

　　结束语

　　本文列出了一些重要领域，您需要关注这些领域，以便成功交付引入SOA的业务转换项目。业务转换对SOA的挑战非常重要。大部分企业都通过引入SOA基础设施（能以此为基础构建组合应用程序）以增量的方式进行转换。他们使用遗留IT系统实现服务提供者。

　　为了让企业在所有操作上保持可靠性和一致，转换项目必须开发企业信息管理解决方案，而此方案中包括SOA（但涉及的内容并不限于此范围）。此解决方案应该在SOA中跨IT系统处理数据和内容的一致性和同步问题，以便能将信息服务公开供使用。

　　负责交付SOA转换的解决方案架构师还必须在考虑总体受控的企业体系结构和预算的情况下，对遗留IT系统的功能与SOA的需求进行权衡。信息管理解决方案的实现策略中的数据集成技术和主数据管理因素。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-406864/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14780828/viewspace-406864/