java soa_简单的JAVA和.NET SOA互操作性

java soa

有关REST的讨论以及一种简单的，低依赖性的解决方案，可以在线进行Java和.Net之间的互操作。

在本文中，我们打算展示如何在不使用专有中间件或Web服务堆栈复杂性的情况下，将简单技术与以文档为中心的方法相结合来提供有价值的业务服务。 我们从REST架构风格以及通过HTTP移动XML的能力中获得灵感。

Web服务方式

引入这种方法的最佳方法是将其与一个简单的Web服务示例进行对比。 想象一下一个简单的Weather Service，它公开了一个称为“ WeatherQuery”的Web方法，该方法返回包裹在对象中的温度和压力。 在大多数情况下，人们使用现有代码并使用工具来公开方法并生成一些WSDL。

如果您相信炒作，那么我们现在要做的就是将等效的Java工具指向WSDL并生成存根方法。

不幸的是事情还不是那么简单，WSDL是一个广泛的标准，实际上已经足够广泛以供解释。 在我们的案例中，我们发现.Net实施了一种文档方法，而我们的java工具则采用了相反的方式，即RPC。 我们还发现了名称空间混合，包含架构和将WSDL分成不同部分的工具的问题。 简而言之，技术开始分散我们正在尝试解决的实际问题。

为了解决这个问题，我们还发现Web服务工具内部存在不一致之处。 例如，对于自动发布的WSDL文档，Internet信息服务器和Web服务增强功能的版本仅彼此部分兼容，或者它们的Java等效版本仅部分兼容。

对于可能今天无法正常工作的某些事情，我们变得非常厌倦，但是如果更高版本的服务中需要更复杂的Web方法，则明天可能会中断。

更加REST风格

上面的方法有两个关键的假设：首先，公开现有的方法调用将为我们提供有意义的服务，其次，工具将使通过Web服务获得该服务变得微不足道。

无需考虑请求的参数和返回的类型，我们可以将请求视为体现请求的类型及其参数的文档。 将该文档视为代表您要建模的业务流程合同一部分的内容。 如果我们采用相同的WeatherQuery方法，并以普通XML元素对其进行描述，我们可能会看到类似-

同样作为文档，返回类型可能类似于-

现在，我们可以定义一个简单的类设计，该设计表示与文档相同的字段-

关于这两个文档的有趣之处在于，它们在.Net和Java中都相对易于序列化和反序列化。 对于.Net，内置XML序列化（带有一些注释）可以很好地完成工作。 这是相同类的C＃-

Java并不是那么幸运。 它没有内置的XML序列化工具：但是，有一个名为XStream的开源工具（ http://xstream.codehaus.org ）非常适合此工作-

当前，我们的Weather服务仅促进文档交换，因此，我们可以使用纯HTTP代替Web服务。

通过这种转变，我们能够使用系统中的同一入口点来考虑多种文档类型，从而为我们提供了一种更可扩展的方法。

编码Java服务器

我们选择将服务托管在Servlet中时，用于服务的Java实现的技术是序列化库XStream的技术以及任何Servlet容器。 XStream是开放源代码：servlet容器可以是WebLogic，WebSphere，JBoss，Geronimo，Orion中的任何一个，也可以是Resin，Tomcat或Jetty，如果J2EE中所需的E较少。

我们的servlet应该实现doPost（）而不是doGet（）方法。 我们没有为XML使用名称/值对：我们只是使用了整个POST正文，而这超出了HTTP规范。 不过，这是一个优先事项-只要在客户端和服务器上相同即可。

收到请求时，我们使用XStream将XML反序列化为命令对象并适当地处理它。

编码.Net服务器

.Net的服务器技术更简单-我们仅使用Internet信息服务器（IIS）和.Net的内置XML序列化。 内置序列化要求C＃属性将字段标记为XML元素，而不是XML属性。 XStream有一个.Net端口，它使事情变得更简单，但是我们还没有尝试过，而且我们听说过另一个端口即将在开源世界中启动。

编码Java客户端

对于XStream之外的Java客户端，我们使用Apache的HttpClient库（及其依赖项）。

参见http://jakarta.apache.org/commons/httpclient

HttpClient库使用起来非常简单，并允许在执行之前以编程方式构造POST操作。 记住，POST主体完全是XStream作为名称/值对或整个请求（不带HTTP构造）传递的XML。 如果您想为该服务创建测试Web表单，则前者可能很有吸引力。

编码.Net客户端

对于.Net客户端，您只需要框架，它可以是1.1版或2.0版。

对于POST操作，我们可以使用内置的WebRequest类和内置的序列化。

使其可扩展和兼容

简单地发布代表命令的XML的好处是，我们可以稍后添加更多命令，而无需更改消息的实现。 服务器可以在运行时决定是否可以处理XML-

解决多种潜在类型的一个好方法是为每种类型注册一个处理程序，以帮助避免较大的if / else或switch / case块-

使用XML时，往往会过度依赖相关的架构，因此我们必须小心了解架构验证与使用者可能实际需要的信息之间的区别。

如果在运行时执行模式验证，则会给开发人员带来不合适的安全感。 仍然可能发生故障-可能发送了错误的XML。 但是会发生什么呢？ 将出现架构无效异常消息。 或者，将XML映射到类的设计中，则可能是正确的对象，或者缺少某些字段。 在这种情况下，可能会由于真正的原因而引发真正的异常，很容易将其转变为针对消费者的清晰XML回复消息。 关键区别在于，仅当缺少所需信息时才会引发异常-其他任何事情都可能发生变化。

在此设计中固有地，有可能将元素添加到XML（类的字段），从而有可能使API从概念上向前移动一个缺口。 通过一些仔细的测试，该服务可以支持消费者发送旧版本的请求文档。 API的更改以及“额外字段”级别的影响也可能更大：

不过，最好将版本号编码到URL中： http : //x.com/weather/WeatherQuery/2.0

将其包装在Web服务中

没有什么可以阻止您在同一服务器上安装第二个服务来接受对同一服务的正式Webservice请求。 您只需要一个WSDL指定的方法，例如-

您可以选择用于.Net或Glue的WSE 2.0 /3.0、AXIS、JAX-WS的工具，或用于Java的J2EE容器之一的某些内置适配器。 SOAP编码的方法可以简单地委托给为纯REST实现开发的相同demarshal-execute-marshal代码。 您可能正在这样做，以避开企业标准警察。

将其扩展到消息传递

利用Tibco Rendezvous，我们能够发送请求的相同XML表示，以针对隐式异步服务执行。 我们没有尝试MQ系列，但是它也应该工作。

对于我们的示例，这意味着对天气详细信息的请求将不会立即得到满足。 取而代之的是，一段时间后，响应可能会回来。 这是一个巨大的转变，可能意味着更改或放弃了API可能需要的一些简单设计。 例如，可能需要使用以下facade方法：

用两个接口代替每个接口可能是合适的-

关于消息传递模式，有很多东西要学习，我们将不在这里讨论。 但是，值得注意的是，有两个通用设计要考虑。 第一种是队列设计，其中来自您的请求将仅收到针对您的响应。 第二个是多播概念，其中线路上有事件正在发送给许多订户（发布/订阅）。 同样，隐式地，您可能会设计一个队列，以便随着时间的流逝继续流式传输修订后的详细信息。 如果您熟悉JMS，则Rendezvous在这方面的工作会稍有不同。

威瑟尔WSDL

我们编写的生产者/消费者设计以一种简单的设计来交易XML。 但是，我们的正式Web服务设计的发现阶段固有的规范检查是缺失的。

我们建议它不是真正需要的。 取而代之的是，与敏捷思维完全一致的是，拥有一套全面的持续集成套件的集成测试。 您的服务不兼容性将在部署到实际运行之前被发现。 因此，您可以使用一系列的单元测试，而不是从复杂的WSDL规范中，从提供者和消费者的角度对服务进行断言。 无论如何，当恢复非常困难时，WSDL仅在运行时标记不兼容。 这样是假神吗？

Schematron是一种以平台无关的方式创建此类测试的方式。

为了帮助调试和编写文档，您可能希望托管一些样本文档：

您还可以使用XML Schema（XSD）控制文档格式：

静态地同时为XSD和示例XML提供服务可能是一个好主意（作者在XSD上会有所不同）。 静态投放意味着可以通过Web浏览器查询该API，

http://x.com/weather/xsd/WeatherQuer

http://x.com/weather/sample/WeatherQuery

请记住，XSD和示例文档都是可选的，也可以轻松生成。

总结和关键信息

这里的妙处在于使用Codehaus的XStream通过HTTP-POST操作而不是GET来与.Net进行元素常规文档交换。 几乎所有其他内容都已经过博客和白皮书。 选择XStream意味着消息的“规范”是Java和/或C＃，而不是WS- *规范通常遇到的基于XML的设计。

此外，传统的REST智慧表明HTTP-GET更适合于对命令进行编码...

http://x.com/weather/WeatherQuery?locn=芝加哥

...尤其是当结果可通过Web服务器缓存时。 也许我们的风格最适合没有缓存的通信。 我们已经失去的GET方法还有其他优点。 凭借完整的URL，它更加优雅，并且可以被浏览器的人测试。 但是，它缺乏我们通过POST获得的多功能性，而POST不仅允许参数的名称/值对存在，还具有更多的功能。 XML有效载荷可以任意复杂。 当然，在较大的解决方案中，还有GET和POST的空间。

在撰写本文时，我们向XStream团队提出了一个建议（通过修补程序），这将使其能够在适当的地方支持属性。 他们实现了必需的功能，将来的XStream版本将能够支持XML属性，以便与.Net进行更加无缝的转换。

我们还建议该方法适用于Tibco RV等异步传输。 在这方面，当前的WS- *规范工具几乎没有能力。

最后，我们不确定这是POST-REST（PREST）还是只是良好的旧REST，而没有太多的缓存和URL简单性，也没有新的术语。

翻译自: https://www.infoq.com/articles/REST-INTEROP/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

java soa