我需要从Java调用.NET编写的Web服务。该网站的服务实现了WS-Security的堆栈（无论是华尔街英语2或WSE 3，它不是从我掌握的清楚）。

I need to call a web service written in .NET from Java. The web service implements the WS-Security stack (either WSE 2 or WSE 3, it's not clear from the information I have).

这是我从服务供应商处获得的信息包括WSDL，一个policyCache.config文件，一些示例C＃code和一个示例应用程序，可以成功地调用服务。

The information that I received from the service provider included WSDL, a policyCache.config file, some sample C# code, and a sample application that can successfully call the service.

这是不是有用，因为它的声音，因为它不清楚如何我应该使用这些信息来编写Java客户端。如果web服务请求是不是根据那么它是由服务拒绝策略签署。我尝试使用Apache Axis2和我无法找到如何我应该使用policyCahce.config文件和WSDL生成客户端的任何指示。

This isn't as useful as it sounds because it's not clear how I'm supposed to use this information to write a Java client. If the web service request isn't signed according to the policy then it is rejected by the service. I'm trying to use Apache Axis2 and I can't find any instructions on how I'm supposed to use the policyCahce.config file and the WSDL to generate a client.

有，我发现在网络上，但在所有情况下的例子提交了双方的服务和客户端的控制，因此能够使双方微调，以得到它的工作的几个例子。我不是在那个位置。

There are several examples that I have found on the Web but in all cases the authors of the examples had control of both the service and the client and so were able to make tweaks on both sides in order to get it to work. I'm not in that position.

有没有人这样做成功的？

Has anyone done this successfully?

推荐答案

这似乎是一个普遍的问题，所以我就提供什么样的，我们在我们的情况做了概述。

This seems to be a popular question so I'll provide an overview of what we did in our situation.

看来，建于.NET服务下的旧的WS-Addressing标准（http://schemas.xmlsoap.org/ws/2004/03/addressing/)和Axis2既懂新的标准（http://schemas.xmlsoap.org/ws/2004/08/addressing/).

It seems that services built in .NET are following an older ws-addressing standard (http://schemas.xmlsoap.org/ws/2004/03/addressing/) and axis2 only understands the newer standard (http://schemas.xmlsoap.org/ws/2004/08/addressing/).

此外，所提供的policyCache.config文件是一种形式，Axis2的城墙模块无法理解。

In addition, the policyCache.config file provided is in a form that the axis2 rampart module can't understand.

因此​​，我们必须的步骤做，概括地说：

So the steps we had to do, in a nutshell:

阅读policyCache.config，并尝试去了解它。然后把它改写成政策壁垒可以理解。 （有些更新的帮助文档。） 在配置壁垒与这项政策。 您可以在.pfx文件中提供的密钥，并将其转换为一个Java密钥存储。有一种实用工具，自带的码头，能做到这一点。 在配置壁垒与该密钥存储。 在编写一个自定义Axis2的处理程序，向后转换成较新的WS-Addressing的东西散发出来的Axis2进入旧的东西预期的服务。 配置Axis2中使用的处理器上传出消息。 Read the policyCache.config and try to understand it. Then rewrite it into a policy that rampart could understand. (Some updated docs helped.) Configure rampart with this policy. Take the keys that were provided in the .pfx file and convert them to a java key store. There is a utility that comes with Jetty that can do that. Configure rampart with that key store. Write a custom axis2 handler that backward-converts the newer ws-addressing stuff that comes out of axis2 into the older stuff expected by the service. Configure axis2 to use the handler on outgoing messages.

在最后它是一个很大的配置和code的东西，应该是由厂商支持的开放标准。

In the end it was a lot of configuration and code for something that is supposed to be an open standard supported by the vendors.

虽然我不知道的另一种方法是什么？你能为厂商等待（或在这种情况下，一个供应商），以确保一切都将跨运？

Although I'm not sure what the alternative is...can you wait for the vendors (or in this case, the one vendor) to make sure that everything will inter-op?

作为后记，我会补充一点，我最终没有做的工作，这是别人对我的球队，但我觉得我得到了显着的细节纠正。我正在考虑（在我的队友接管），另一种选择是直接调用WSS4J API来构建SOAP信封作为.NET服务期望它。我认为这会工作了。

As a postscript I'll add that I didn't end up doing the work, it was someone else on my team, but I think I got the salient details correct. The other option that I was considering (before my teammate took over) was to call the WSS4J API directly to construct the SOAP envelope as the .NET service expected it. I think that would have worked too.