NET与J2EE应用程序的互操作性.pptVIP

.NET与J2EE应用程序的互操作 曹严明 软件专家 微软(中国) 议程 背景介绍 互操作性选择 互操作性最佳实践 移植还是互操作 问答 为什么需要互操作性? 满足客户的需求 异构已成为事实 完全的中央控制不切实际 大多数大企业拥有混合的系统 企业合作, 收购, 兼并 企业要求互操作性 CIO已经把集成列入IT方面第一关注的事项 误区 套牢(Lock-in)还是开放(Open) 跨平台还是互操作性 Windows .NET 和互操作性 从 Windows Server 角度来看，互操作性 (通过 Web 服务, XML, 以及许多其它的方法) 是 .NET 的重点 .NET 使你能用 Windows 平台搭建跨系统的松耦合的解决方案 解决方案的一部分可以本地运行 另一部分可作为服务在别处运行 服务也可以调用其它的服务 互操作的目标 保护现有的投资 与新模块无缝结合 访问到任何平台上的业务逻辑 通过标准接口访问到数据层 充分发挥平台的优势 .NET与J2EE技术对照 J2EE 与 .NET 两个平台提供等同的服务 选择”较合适”的方案 .NET与J2EE技术对照 .NET与J2EE技术对照 .NET与J2EE技术对照 .NET与J2EE技术对照 应用程序流程 互操作 - Web 层方案一 利用客户端功能在 web 应用程序间共享信息 使用客户端 cookie 不是一个灵活的, 可扩展的方案 互操作 - Web 层方案二 创建一个 ASP.NET fa?ade 层 从 fa?ade 层访问 Servlet 和控制器 用 XML 描述符来定位服务 Fa?ade 代理请求和响应 性能问题 ASP.NET Fa?ade 互操作 - Web 层方案三 在 web 服务器间共享会话信息 定制状态管理 在 ASP.NET 和 J2EE 应用程序服务器中定制会话管理模块 共享会话状态 互操作 – 业务层 集成 EJB 集成应用程序服务器 考虑: 事务处理 错误处理 可伸缩性, 安全性, 性能 互操作 – 业务层 互操作 - 业务层方案一 互操作 - 业务层方案一 RMI - .NET Remoting 桥接 优点 接线层级的性能 缺点 紧耦合 特定的厂商和版本 紧耦合的桥接 例如 Intrinsyc 公司的 Ja.NET 互操作 - 业务层方案二 互操作 - 业务层方案二 消息队列 (MSMQ, MQ Series) 优点 松耦合 支持N到N的场景 支持事务，安全性，可靠的消息传递 缺点 不能同步操作 可能出现端口或防火墙问题 消息队列跨越互联网? 互操作 - 业务层方案三 互操作 - 业务层方案三 Web 服务 优点 松耦合 同步 (或异步)操作 跨防火墙 产业界推动 可扩展 缺点 Web服务标准在事务处理，可靠消息传递方面缺少支持 安全性如何? Web 服务 基本的标准 (XML, XSD, SOAP, WSDL, UDDI) 没有涉及安全性 现在可以使用点到点基于传输层的安全措施 (比如, HTTPS) 将来的版本将包含 WS-Security 对于其它互操作机制 自己完成加密, 数字签名等 互操作 – 数据层JDBC 集成 J# 对JDBC的支持 托管的接口 访问相同的数据源 将 java.sql 软件包映象到System.Data.OleDb 在转换后的程序中使用离线的模式 为集成而设计可连接的应用程序 松耦合 可编排 基于标准 跨平台 性能最佳实践 较少的对话 松耦合系统 独立系统相联结 独立的基础架构 独立地开发, 部署, 管理 彼此之间没有信任关系 目标 少数的, 定义明确的连接点 各系统实现没有依赖性 任何一端的修改都可以适度容忍 集成应用程序 SOAP XML Web 服务 跨语言集成 COM+ (企业服务) BizTalk 互操作建议 可能的情况下使用XML Web 服务 转移到一个面向服务的体系结构 使用 XML Schema XML Web 服务包含了XML Schema 也适用于消息传递, 文档交换, 及其它情形 只有在绝对必要时才可以不遵循这些约定 XML Web 服务 适合于任何一个方向: .NET - Java 各种各样的可与.NET互操作的 Java 方式 Apache AXIS The Mind Electric Glue IBM WebSphere ** BEA WebLogic 7 (“Cajun”) 异步会话是可能的 比如, 通过 .NET Delegates 问题: 特定平台的数据类型 比如, ADO.NET DataSet 比如, Java Vector 集成调度员超越点到点的连接 集成调度员 超越点对点连接 总结 桥接.NET和J2EE不仅