基于soa的信息集成方案初步探讨.pptVIP

基于SOA的信息集成方案初步探讨 内蒙古工业大学 王钢 2007－11 信息化建设的困难与困惑 内蒙古工业大学信息化建设现状： 或多或少的信息孤岛 断断续续的资金投入 无奈的看到越来越多的信息孤岛 实施建设 领导、业务部门、我们自己的认识 组织实施的难度，利益再分配 学校要有有能力，有水平，有技术的一致专业的队伍，难点不是钱，不是理论和技术，是认识问题。 校内业务部门的信息化情况： 每个业务部门都掌握着自己熟悉的小应用 尽管功能不强大，但很贴近部门内部需求 跨越业务部门的数据共享需求不断增多 “大一统”的解决方案 从各个角度通盘考虑 建立全域业务模型 做顶层设计 按照“标准”重新建立统一数据库 信息化或数字化已经不是写几行代码与设计一个普通的数据库，是整个高校运转的所有业务建模 我们自己有实力作吗？ 全域业务与数据共享模型 顶层设计 高校信息化协会标准 不能做，只能买 方式1：购买全部设计、全部功能 肯定需要定制，实施周期最少1年，多则3年 可能刚刚做好了，用户需求已经发生了变化 大而统一的数据库已经有不恰当的地方（如果不能消灭地方的小应用，数据更新就成为问题；全盘重新替换原有应用的难度相当大） 方式2：购买部分模块 共享数据肯定有缺陷 如何保证不是又新建了一个信息孤岛？ 投资保护问题？ 相对与设备管理软件、财务管理软件，购买信息化管理类软件的风险？ 成功的企业ERP有几许？ 我们的管理体制人为因素较多 用户需求的多变要求设计团队、实施团队永远不能解散（蒋东兴：变是永恒的，不变是不可能的） 否则我们将面临再一次的、全部的、更大的投入 还有集成测试、数据转换、员工培训…… 有没有其它的途径？ 初期投入适度 先期投入能够做到投资保护 后期投入能够包容前期内容 适合普通学校，资金压力小、可持续发展纳？ 这实际上不仅仅是学校遇到的问题，是普遍问题 SOA是解决之道吗？ 面向服务的体系结构（Service-Oriented Architecture） 2006年以来，SOA在国内外已经成为替代一度风靡的面向对象、B/S结构、三层结构等软件解决方案的另一个热门词汇 所有中间件厂商——IBM, Oracle, Microsoft, BEA, Sun, JBoss, 一些国内的厂商 2007年更是不得了，到处是SOA专题 “炒概念”？是新发明的“轮子” 不仅仅是炒概念，而且拼命的推出解决方案 SOA是什么？ 应用级组件（服务组件）：对象的升化 标准化的组件（服务）接口：独立于实现服务的硬件平台、操作系统和编程语言 松耦合：业务之间的松耦合，业务流程可以重组，有更强的灵活性和适应能力 SOA原型—通用对象请求代理体系结构CORBA （Common Object Request Broker Architecture），分布式计算，网格 伴随一些新技术的成熟，XML、 WEB Service、 WSDL（Web Services Definition Language）、SOAP（Simple Object Access Protocol）、UDDI（Universal Description, Discovery and Integration）、ESB（Enterprise Service Bus）、BPEL (Business Process Execution Language For Web Services) Oracle的SOA套件 IBM的SOA套件 SOA有什么好处？ 模型驱动的体系结构（Model-Driven Architecture，MDA），业务驱动也是清华选择的道路——贴近用户需求（蒋东兴教授提到的SOA是业务流程的集成的一种实现技术） 适应系统改变的能力是最重要的部分——就是投资保护 架构师与开发人员的分工——让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，可以简化复杂度。 基于SOA是不是可以这样？ 基于SOA构架整体数字化模型 现有信息系统可以暂时保留，扩展支持SOA标准的服务接口 新建系统支持SOA，与旧系统整合 逐步替换旧信息系统 大模型不变，而下面的小应用系统可以轮替升级 业务流程改变不用重新全盘设计重建 我们自己可能有力量建立一个小服务，修改更新一个小服务 可以持续发展，不用一次性大量投资 SOA的路线图 可以“自上而下”或“自下而上”的方法 第一种方法是自顶层向下，从业务逻辑开始模型设计，再到具体业务设计与实现；（蒋教授的顶层设计） 第二种方法就是从底层开始，直接去做代码的编写，然后再考虑如何在上层支持业务逻辑，最后再将其构建成为完善的SOA； SOA的路线图 首先要根据企业的业务需要，通盘考虑需要的SOA架构