做企业集成应该考虑什么问题 (.NET / J2EE 视角)

 

.NET视角

keep it simple, but not simpler (——爱因斯坦)

是便于开发人员实施

明确集成范围和待集成目标系统/应用/流程

梳理调用关系,明确每个集成目标的边界以及边界间的信任关系

是否有一个规范的开发环境

是否可以尽快实施完成(实施——见效——下一阶段实施)

是否已经将下层技术环境与上层业务处理抽象并剥离出来,否则集成徒增复杂性

是否有适合P&P系列Integration Patterns中提到的Message BrokerMessage BusP2P Connection的情景

将集成工作分解,采用Portal集成?数据集成?功能集成?还是建立一个独立的数据中心(对于安全性集成,还需要考虑是否建立一个PKI中心,比如用AD作为CA或是第三方的CA,并在此基础上提供SSO、证书边界映射之类的支持)

是否需要增加新的Endpoint

是否可以通过增加存储过程、配合JDBC访问的方式,而非直接修改基于CICS COBOL等平台开发的业务逻辑

是否考虑通过统一的WCF/BizTalk/SQL Service Broker技术实现对遗留平台、异构平台的分布式调用

是否业务处理可以在完全不知道下层技术系统的情况下完成交易(即,是否有效隔离了下层技术服务与上层业务处理)

如果变更后端处理,到底会对上层业务流程、应用带来哪些影响,(尤其是企业里那些牵一发动全身的“Core”流程或应用),是否需要对下层进行重构

选择哪个.NET语言?或哪个.NET语言为主?

您的企业到底受用何种技术? ODBC/OLE DB/ADO.NET/LINQ & Entity Framework MSMQ/IBM MQBEAMessageQ除非必须就别考虑了,省得还要为它再集成)?WCF/.NET Remoting/Enterprise Service/Socket/WS-*?

是否采用EntLib 3.1/4.0替换到部分 “半新不旧”系统的公共组件平台?

是否考虑采用SharePointWeb Part

Java/J2EE视角

keep it simple, but not simpler (——爱因斯坦)

是便于开发人员实施

明确集成范围和待集成目标系统/应用/流程

梳理调用关系,明确每个集成目标的边界以及边界间的信任关系

是否有一个规范的开发环境

是否可以尽快实施完成(实施——见效——下一阶段实施)

是否已经将下层技术环境与上层业务处理抽象并剥离出来,否则集成徒增复杂性

是否需要增加新的Connector

是否可以通过增加存储过程、配合JDBC访问的方式,而非直接修改基于CICS COBOL等平台开发的业务逻辑

是否业务处理可以在完全不知道下层技术系统的情况下完成交易(即,是否有效隔离了下层技术服务与上层业务处理)

如果变更后端处理,到底会对上层业务流程、应用带来哪些影响,(尤其是企业里那些牵一发动全身的“Core”流程或应用),是否需要对下层进行重构

您的企业到底受用何种技术? J2CJDBCJSMWS-*BPEL还是Socket就够了

posted @ 2008-06-19 10:48  蜡笔小王  阅读(419)  评论(0编辑  收藏  举报