如何获取传递到 JAX-WS 服务客户端的登录信用及其关联的策略集和 Rational/WebSphere 工具中的绑定
我专门使用 WebSphere Integration Developer V7，但我也可以使用 Rational Software Architect V 7.5.1（因为我两者都有）。
上下文： 我正在尝试创建一个 JAX-WS 客户端来调用 WebSphere Process Server V7 中通过 JAX-WS 公开的人工任务管理器和业务流程管理器服务。默认情况下，它们附加了策略集和指定某些 WS-Security 设置的提供程序绑定（因为这些设置未在 WSDL 中定义）。
我已经弄清楚如何使用动态 Web 项目使其工作。我已经能够从 WSDL 生成 JAX-WS 客户端代码。我已经能够从 Process Server 导出策略集以及提供者和客户端绑定，并将它们导入到我的工作区中。我已经能够将策略集和客户端绑定附加到客户端服务。我已经能够设置一个页面和一个 servlet 来调用我的 Web 服务（以测试客户端）。我已经能够在部署描述符和 websphere 绑定/扩展文件中设置安全设置以使其正常工作。
这一切都很棒，但实际上我们不希望只是为了将 Web 服务客户端暴露给我们正在编写的其他应用程序而引发战争。我们想要生成一个 Web 服务客户端 jar 并将其与其他应用程序打包。
鉴于这一思路，我已经能够弄清楚如何在 IDE 中使用常规 Java 项目并在其中生成 Web 服务客户端。我还能够将策略集和客户端绑定附加到客户端。
我的问题现在是如何调用它？我已经像以前一样使用我的页面和 servlet 创建了一个动态 Web 项目来测试我的客户端。我将客户端项目设置为 Web 库依赖项，以便它可以访问客户端代码。我什至可以像以前一样设置部署描述符来强制登录和身份验证。现在唯一的问题是，我无法弄清楚如何将凭据传递给我的 Web 服务，因为它位于自己的“jar”中。在我可以访问菜单来设置 TokenGenerator 和 CallbackHandler 之前。现在，我无法访问这些菜单，因为客户端不在动态 Web 项目中。所以现在我有一个“断开连接”，当尝试在服务器上运行它时它当然会失败。
必须有一种方法可以做到这一点。我应该能够生成一个客户端 jar 并传递它所需的内容。有人遇到过这个吗？
I am specifically using WebSphere Integration Developer V7, but I also could be using Rational Software Architect V 7.5.1 (as I have both).
Context: I am trying to create a JAX-WS client to call into the Human Task Manager and Business Flow Manager services in WebSphere Process Server V7, that are exposed via JAX-WS. By default they have attached Policy sets, and provider bindings that specify some WS-Security settings (as these are not defined in the WSDL).
I have figured out how to make it work using a Dynamic Web Project. I have been able to generate the JAX-WS client code from the WSDL. I have been able to export the policy sets and provider and client bindings from Process Server and import them into my workspace. I have been able to attach the policy set and client bindings to the client service. I have been able to set up a page and a servlet to invoke my web service (to test the client). And I have been able to set up the security settings in the deployment descriptors and websphere binding/extension files to get it work.
This is all wonderful, but in reality we don't want an ear with a war just to expose the web service client to our other applications we are writing. We want to generate a web service client jar and package it with other applications.
Given this line of thought I have been able to figure out how to use a regular Java Project in my IDE and generate the web service client into it. I have also been able to attach the policy set and client bindings to the client.
My problem is now how to I invoke this? I have created a dynamic web project with my page and servlet as before to test my client. I set up my client project as a web library dependency so it has access to the client code. I can even set up the deployment descriptors as before to force login and authenication. Only problem now is that I can't figure out how to pass the credentials to my web service now that it is in its own "jar". Before I had access to a menu to set up the TokenGenerator and CallbackHandler. Now, I don't have access to those menus as the client is not in the dynamic web project. So now I have a "disconnect" and it of course fails when trying to run it on the server.
There has to be a way to do this. I should be able to generate a client jar and pass it what it needs. Anyone encounter this before?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好的。我花了很长时间研究这个问题，阅读红皮书和developerworks 文章，用头敲击键盘，终于找到了一些答案。虽然不是一直到那里，但也差不多了。 （希望一些 IBM 的东西更容易找到……但是你要根据给定的东西进行工作。平心而论，根据我所读到的内容，它是有道理的，而且非常强大。）
无论如何，这里是解决这两个问题的技巧Rational 和 WebSphere 工具：您必须首先创建一个空的 Java 项目。这是制作可移植 Web 服务客户端的关键之一。
到目前为止，这就是：
精彩的！伟大的！现在您有了一个 Java 项目（又名 jar），您可以使用它来使其可移植。但是如何让 IBM 工具满意并将安全策略附加到客户端呢？
首先，我了解到最好将安全策略附加到 WebSphere Application Server/Enterprise Service Bus/Process Server 的管理控制台中。尽管 IBM 为您提供了 API 来完成这一切，但有太多的事情需要考虑安全性，无法尝试手动编码。相信我。在服务器上定义安全性然后将其分配给客户端会更容易。
无论如何......为了允许客户端对管理控制台可见以附加策略集和客户端绑定以实现 JAX-WS 安全，它必须位于“Web 级别”（由于缺乏更好的术语）命令它将 jar 作为 Web 客户端查看。这意味着将 jar 作为 J2EE Utility Jar 附加到 EAR 项目将不起作用。 EAR 不是“Web 级别”，而是“应用程序级别”。因此，要做到这一点，您需要将 Java 项目与 J2EE 模块依赖项屏幕中的 EAR 关联起来，但不是作为实用程序 Jar。相反，请选中“lib”框。这意味着它可以可见/安装到动态 Web 项目/war 的 lib 目录中（您也必须这样做）。令人惊讶的是，管理控制台现在会将您的客户端 jar 视为真正的 JAX-WS Web 服务客户端！现在您可以将策略集和客户端绑定关联到它，以满足您的安全需求！
乍一看这可能看起来很奇怪，但确实有点道理。毕竟您正在处理网络服务并且正在使用网络协议，因此在某些方面将客户端置于“网络级别< /em>”您的应用程序。
Ok. I've spent a long time researching this, reading redbooks and developerworks articles and pounding my head against my keyboard and I've finally gotten somewhere. Not all the way there, but almost. (Wish some IBM stuff was easier to find...but you work with what you are given. And in all fairness, with what I've read it makes sense and is pretty powerful.)
Anyway, here is the trick to both the Rational and WebSphere tooling: You have to create an empty Java Project first. This is one of the keys to making a portable web service client.
So here it is so far:
Wonderful! Great! Now you have a Java Project (aka jar) that you can use to make it portable. But how do you make the IBM tooling happy and attach security policies to the client?
Well first, i've learned that it really is best to attach the security policies in the administrative console of WebSphere Application Server/Enterprise Service Bus/Process Server. There are too many things to try to account for with security to try to manually code it all, even though IBM gives you the API's to do it. Trust me. It is easier to define the security on the server and then just assign it to the client.
Anyway....in order to allow the client to be visible to the Admin console for attaching policy sets and client bindings for JAX-WS security, it has to be at the "web level" (for lack of a better term) in order for it to see the jar as a web client. This means that attaching the jar as a J2EE Utility Jar to the EAR project won't work. The EAR is NOT "web level" but is "App level". So to do this, you need to associate the Java Project with the EAR in the J2EE Module Dependencies screen, but NOT as a Utility Jar. Instead check the box that says "lib". This means it can be visible/mounted into the lib directory of a dynamic web project/war (which you also have to do). Amazingly, the admin console will now see your client jar as a true JAX-WS web service client! And now you can associate policy sets and client bindings to it in order to meet your security needs!
This might appear weird at first but it does kind of make sense. After all you are dealing with a web service and you are using web protocols, so in some ways it makes sense to place the client in the "web level" of your application.