【发布时间】：2011-03-21 21:07:56
【问题描述】：
在我的工作中，我必须与公开基于 Java 的 Web 服务的第 3 方系统集成。我可以解析服务 WSDL 定义并生成代理类并在 .NET 世界中与它们进行很好的交互。但是，这些服务并不是很“干净”，因为 Java 应用程序的对象模型中的属性名称非常复杂，并且托管 Java 环境的服务器有时会出现故障，并且点对点，我的客户端当 URI 没有响应时，应用程序不喜欢它。我还不想将服务实现逻辑直接包含到我的 Web 应用程序中，因为这些 Java 服务有很大的重用潜力，因为业务经常要求使用相同数据的新事物。
所以，我不久前所做的是编写一些“包装”WCF 服务来处理属性映射并为我们的开发人员提供更好的开发接口。但是，这个解决方案感觉不太好，因为我想实现一些路由和一些其他功能，并摆脱 1:1 包装器 WCF 到 Java 服务。有没有什么好的方法可以使用 WCF 4 功能更动态地处理这个问题？我认为最大的障碍是我无法访问 Java 服务以进行更改，并且支持该方面的开发人员除了 Java 之外并不熟悉其他东西。即使试图解释 ESO/SOA 概念通常也是徒劳的。
还有其他人使用 WCF 作为第 3 方服务的伪服务网关吗？如果是这样，您如何以更动态的方式处理从 WCF 数据对象到第 3 方服务的字段映射？您是否使用来自 3rd 方服务的 WSDL 在您的 WCF 层中生成绑定合同和代理类？
谢谢。我知道这是一个非常广泛的问题，没有 100% 正确或错误的解决方案。只是在寻找有关此架构的一些反馈。我看到很多关于 WCF 服务作为路由服务与其他 WCF 服务交互的信息，但 WCF 路由或充当基于 Java 的服务的网关的情况并不常见。
再次，这是我目前的架构..
.NET 客户端 -> WCF 服务（映射、属性清理和一些小业务逻辑） -> 基于 Java 的 Web 服务 -> 源数据（大型资产管理系统）
【问题讨论】：
-
对此的更新。一年多过去了，我创建的解决方案似乎相当可靠，使用 WCF4 作为 Java Web 服务的外观。我为公司内的 .NET 消费者创建了具有“更清晰”属性名称的 POCO 实体，将 Java WS 逻辑的任何冗余部分移至公共程序集，并使用 AutoMapper 将响应数据从 Java 集成映射到 . NET poco 类。在 WCF 方面，我将外观服务的接口和实现分开，以分开提供给 .NET 消费者的程序集，以便他们只使用接口。