基于 SOA 的信息集成方案 初步探讨

1. 基于SOA的信息集成方案初步探讨 内蒙古工业大学 王钢 2007－11

2. 信息化建设的困难与困惑 • 内蒙古工业大学信息化建设现状： • 或多或少的信息孤岛 • 断断续续的资金投入 • 无奈的看到越来越多的信息孤岛 • 实施建设 • 领导、业务部门、我们自己的认识 • 组织实施的难度，利益再分配 • 学校要有有能力，有水平，有技术的一致专业的队伍，难点不是钱，不是理论和技术，是认识问题。 • 校内业务部门的信息化情况： • 每个业务部门都掌握着自己熟悉的小应用 • 尽管功能不强大，但很贴近部门内部需求 • 跨越业务部门的数据共享需求不断增多

3. “大一统”的解决方案 • 从各个角度通盘考虑 • 建立全域业务模型 • 做顶层设计 • 按照“标准”重新建立统一数据库 • 信息化或数字化已经不是写几行代码与设计一个普通的数据库，是整个高校运转的所有业务建模 • 我们自己有实力作吗？

4. 全域业务与数据共享模型

5. 顶层设计

6. 高校信息化协会标准

7. 不能做，只能买 • 方式1：购买全部设计、全部功能 • 肯定需要定制，实施周期最少1年，多则3年 • 可能刚刚做好了，用户需求已经发生了变化 • 大而统一的数据库已经有不恰当的地方（如果不能消灭地方的小应用，数据更新就成为问题；全盘重新替换原有应用的难度相当大） • 方式2：购买部分模块 • 共享数据肯定有缺陷 • 如何保证不是又新建了一个信息孤岛？

8. 投资保护问题？ • 相对与设备管理软件、财务管理软件，购买信息化管理类软件的风险？ • 成功的企业ERP有几许？ • 我们的管理体制人为因素较多 • 用户需求的多变要求设计团队、实施团队永远不能解散（蒋东兴：变是永恒的，不变是不可能的） • 否则我们将面临再一次的、全部的、更大的投入 • 还有集成测试、数据转换、员工培训……

9. 有没有其它的途径？ • 初期投入适度 • 先期投入能够做到投资保护 • 后期投入能够包容前期内容 • 适合普通学校，资金压力小、可持续发展纳？ • 这实际上不仅仅是学校遇到的问题，是普遍问题

10. SOA是解决之道吗？ • 面向服务的体系结构（Service-Oriented Architecture） • 2006年以来，SOA在国内外已经成为替代一度风靡的面向对象、B/S结构、三层结构等软件解决方案的另一个热门词汇 • 所有中间件厂商——IBM, Oracle, Microsoft, BEA, Sun, JBoss, 一些国内的厂商 • 2007年更是不得了，到处是SOA专题 • “炒概念”？是新发明的“轮子” • 不仅仅是炒概念，而且拼命的推出解决方案

11. 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)

12. Oracle的SOA套件

13. IBM的SOA套件

14. SOA有什么好处？ • 模型驱动的体系结构（Model-Driven Architecture，MDA），业务驱动也是清华选择的道路——贴近用户需求（蒋东兴教授提到的SOA是业务流程的集成的一种实现技术） • 适应系统改变的能力是最重要的部分——就是投资保护 • 架构师与开发人员的分工——让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，可以简化复杂度。

15. 基于SOA是不是可以这样？ • 基于SOA构架整体数字化模型 • 现有信息系统可以暂时保留，扩展支持SOA标准的服务接口 • 新建系统支持SOA，与旧系统整合 • 逐步替换旧信息系统 • 大模型不变，而下面的小应用系统可以轮替升级 • 业务流程改变不用重新全盘设计重建 • 我们自己可能有力量建立一个小服务，修改更新一个小服务 • 可以持续发展，不用一次性大量投资

16. SOA的路线图 • 可以“自上而下”或“自下而上”的方法 • 第一种方法是自顶层向下，从业务逻辑开始模型设计，再到具体业务设计与实现；（蒋教授的顶层设计） • 第二种方法就是从底层开始，直接去做代码的编写，然后再考虑如何在上层支持业务逻辑，最后再将其构建成为完善的SOA；

17. SOA的路线图 • 首先要根据企业的业务需要，通盘考虑需要的SOA架构； • 其次是从一个局部做起，以渐进的方式向SOA架构演进，避免大而全的SOA实施，这样可以最大程度地规避项目风险，降低初期投入； • 再次就是在局部成功实施SOA的基础上，构建完整的SOA架构系统。 “思于博，始于细，成其大”

18. SOA是不是灵丹妙药？ • 不能省略的整体模型设计 • 谁来做“思于博”，谁能评估这个“博” • 如何规划合理的服务粒度 • 粒度大——大的服务体就会丧失灵活性 • 粒度小——逻辑密集业务如何保证性能，安全与信任 • 是不是真的可以陆续小规模投入 • 100%的SOA解决方案提供商都希望用户采购他们的应用服务器，然后在这些应用服务器之上去构建用户的SOA体系。 • 标准是SOA的根基，谁的到底会是标准，厂商宣称的全兼容是真的吗？

19. SOA应该是一个值得考虑的选项 • 基于SOA的架构来进行信息化建设、进行信息系统集成、进行业务集成 • ——思路已经得到各方的认可 • ——针对性能、安全、实施路线的研究越来越多 • ——各大厂商正在博弈标准的制定

20. 工大网络中心的信息化 • 尽力“思于博” • 着手“始于细” • 提高自身的认识水平、管理水平、组织能力、技术水平，应对以后的数字化、信息化建设 • 网络中心自身管理与维护业务的信息化 • 也是源于系统的混乱与复杂 • 设备杂乱，厂家的网管软件只能做配置管理 • 用户管理、设备管理、软资源的管理没有完全适合的成品软件

21. 工大网络中心的信息化 • 接入用户信息维护 • IP地址、VLAN分配信息维护 • 设备运行监控与流量监控 • ARP病毒检测工具 • 设备连接情况、光缆连接资源 • 计费系统用户费用情况

22. 接入用户信息维护

27. 工大网络中心的信息化 • 各个系统还是独立存在的，没有联系起来 • 有想法依照SOA构建每个业务服务，灵活构成应用系统 • 例如关闭某用户端口是一个服务 • 昨天有因为用户欠费关闭其端口 • 今天因为有ARP病毒而关闭其端口 • 明天……也能够适应 • 信息的电子化管理的部分自动化业务层面的数字化——提高效率

28. 信息化的建设是永不停息的过程网络中心自身的信息化信息中心自身的信息化更有说服力、更能推动校园信息化的进展信息化的建设是永不停息的过程网络中心自身的信息化信息中心自身的信息化更有说服力、更能推动校园信息化的进展

29. 一家之言，谢谢大家！