Well, the story is not necessarily “bad news”, but it’s certainly a mixed bag.
First, a bit about your requirements. You stated that you need to support soap-rpc style messages AND web services security. That might be a particularly difficult thing to do in Integration Server, because IS doesn’t support working with the soap headers of soap-rpc style messages. But before we get into how you might go about addressing that, you should be really, really sure that you’re understanding the requirement correctly.
The state of the market and the best practices for building interoperable web services as described by the Web Services Interoperability (WS-I) Basic Profile 1.0 and WS-I Basic Security Profile 1.0 would not lead to the combination of soap-rpc and WS-Security. Not that the two can’t be combined, but that it is less well-accepted and less interoperable to do so. (See these posts from an earlier thread today for more thoughts on WS-I Basic Profile)
So assuming that you are being asked to support WS-S using soap-rpc messages, how can you do this in Integration Server 6.x? I would start by creating a custom soap processor that handled soap rpc messages. As covered elsewhere in this forum, custom soap processors are just Flow or java services that intercept a soap message after the content handler processes it but before the target service is invoked. With document/literal services this is the perfect place to put “out-of-band” processing of soap header elements like the ones required to support WS-Security.
What you’ll have to find out is whether you can do something similar with soap-rpc messages. If you can’t do this as a custom soap-rpc processor you’ll have to back up a layer and determine if there is a way to replace the soap-rpc content handler. Before doing that I would probably examine other options such as implementing webMethods ServiceNet 6.5 to act as an intermediary that could process the soap-rpc messages and process the security tokens in the header to perform the required authentication and authorization tasks before IS ever receives the message.
So, in summary, the combination of soap-rpc or more specifically rpc/encoded style and WS-Security is uncommon, non-conformant to WS-I Security and not well supported by many tool vendors (including Microsoft Visual Studio .Net). You will find this difficult to do easily or, perhaps, even at all using Integration Server and Developer 6.5 or earlier. Another good option may be to deploy ServiceNet 6.5 as an intermediary “upstream” from Integration Server.
Mark
#soa#webMethods#API-Management