做企业集成应该考虑什么问题 (.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就够了
