做企业集成应该考虑什么问题 (.NET / J2EE 视角)
.NET视角
l keep it simple, but not simpler (——爱因斯坦)
l 是便于开发人员实施
l 明确集成范围和待集成目标系统/应用/流程
l 梳理调用关系,明确每个集成目标的边界以及边界间的信任关系
l 是否有一个规范的开发环境
l 是否可以尽快实施完成(实施——见效——下一阶段实施)
l 是否已经将下层技术环境与上层业务处理抽象并剥离出来,否则集成徒增复杂性
l 是否有适合P&P系列Integration Patterns中提到的Message Broker、Message Bus、P2P Connection的情景
l 将集成工作分解,采用Portal集成?数据集成?功能集成?还是建立一个独立的数据中心(对于安全性集成,还需要考虑是否建立一个PKI中心,比如用AD作为CA或是第三方的CA,并在此基础上提供SSO、证书边界映射之类的支持)
l 是否需要增加新的Endpoint
l 是否可以通过增加存储过程、配合JDBC访问的方式,而非直接修改基于CICS、 COBOL等平台开发的业务逻辑
l 是否考虑通过统一的WCF/BizTalk/SQL Service Broker技术实现对遗留平台、异构平台的分布式调用
l 是否业务处理可以在完全不知道下层技术系统的情况下完成交易(即,是否有效隔离了下层技术服务与上层业务处理)
l 如果变更后端处理,到底会对上层业务流程、应用带来哪些影响,(尤其是企业里那些牵一发动全身的“Core”流程或应用),是否需要对下层进行重构
l 选择哪个.NET语言?或哪个.NET语言为主?
l 您的企业到底受用何种技术? ODBC/OLE DB/ADO.NET/LINQ & Entity Framework? MSMQ/IBM MQ(BEA的MessageQ除非必须就别考虑了,省得还要为它再集成)?WCF/.NET Remoting/Enterprise Service/Socket/WS-*?
l 是否采用EntLib 3.1/4.0替换到部分 “半新不旧”系统的公共组件平台?
l 是否考虑采用SharePoint的Web Part?
Java/J2EE视角
l keep it simple, but not simpler (——爱因斯坦)
l 是便于开发人员实施
l 明确集成范围和待集成目标系统/应用/流程
l 梳理调用关系,明确每个集成目标的边界以及边界间的信任关系
l 是否有一个规范的开发环境
l 是否可以尽快实施完成(实施——见效——下一阶段实施)
l 是否已经将下层技术环境与上层业务处理抽象并剥离出来,否则集成徒增复杂性
l 是否需要增加新的Connector
l 是否可以通过增加存储过程、配合JDBC访问的方式,而非直接修改基于CICS、 COBOL等平台开发的业务逻辑
l 是否业务处理可以在完全不知道下层技术系统的情况下完成交易(即,是否有效隔离了下层技术服务与上层业务处理)
l 如果变更后端处理,到底会对上层业务流程、应用带来哪些影响,(尤其是企业里那些牵一发动全身的“Core”流程或应用),是否需要对下层进行重构
l 您的企业到底受用何种技术? J2C、JDBC、JSM、WS-*、BPEL还是Socket就够了