java wcf

通过写这篇文章，我冒着被.NET和Java社区拒绝的巨大风险。 这是为了说明Windows Communication Foundation的WCF用Java来解释。

从WCF到Java的映射并不简单。 我缺乏对WFC使用者应该了解的与服务通信类型的了解：请求/响应或异步消息传递。 我很难想象这对于用户来说是完全透明的……除非WCF框架“消除”消息传递的异步性并照顾等待响应消息。 如果最新发生，那么实际上没有异步消息传递！

像往常一样，使用Java（我真的很想念它与.NET一起使用），存在技术规范，并且这些规范有各种实现。 尽管通常使用这些应用程序进行测试，因此声称可以支持所用规范的显式实现，但是从理论上讲，最终选择是在部署期间或在应用程序启动之前完成的。

每当我们谈论服务时，我们都会拥有实际的服务及其消费者。

让我们从消费者开始。 为了发送异步消息，最好针对JMS （Java消息系统规范）编写它们。 JMS的使用者只需要知道目标队列或主题的逻辑名称即可。 对于请求/响应通信，应该针对普通的服务接口编写消费者。 该接口与服务端和传输层中使用的技术无关。 为了在运行时获得接口的显式实现，使用者使用外部可配置的Factory。 该工厂将为Web服务使用JAX-WS ，为RESTful服务使用 JAX-RS ，为远程EJB（企业Java Bean）使用RMI或为进程内服务使用纯对象（PO​​JO）。

你还在吗？ 然后，我们转到服务端。 如果服务使用消息，则可以直接使用JMS或将其作为消息驱动Bean（EJB风格）来实现。 最后一个选项为您提供了来自Application Server（类似于IIS）的所有事务性和可伸缩性。 如果服务应该提供响应（包括失败），则黄金法则是让它们实现一个简单的接口，即服务使用者将使用的接口。 然后，通过在接口实现代码中添加注释或通过在Application Server中使用外部配置，您的实现可以通过Web Service或Session EJB进行访问。 实际上，如今，大多数服务器都能够将会话EJB作为Web服务公开。 如果使用代理模式，那么您还将拥有接口的干净，完整的实现，供进程内使用者使用。

这是一个很冗长的解释。 “ 所有跨层实体都是WCF服务 ”的简短翻译是：

“所有实体均由其接口定义，并针对其他实体的接口编写。 实体的实现是普通的旧Java对象（PO​​JO），可能由EJB代理包装”

翻译自: https://www.javacodegeeks.com/2014/04/attempt-to-map-wcf-to-java-terms.html

java wcf