Does the same principle holds good for Web Service calls? Apart from changing the Internal Server IP and port info with Reverse Invoke IP and Port info are there any changes do we need to do before providing the WSDL to the Partner.
Same principal would apply, but the directive should be /soap/default or /soap/rpc or soap/custom_processor_directive instead of anything having to do with TN.
WSDL’s generated by the Developer’s Generate Code wizard have several limiations including only being able to describe a single IS service (little “S”) rather than describing all operations for a Web Serice (big “S”).
You should use a web services testing tool such as CrossCheck Network’s SOAP Sonar to run WS-Interoperability tests on any WSDL that you produce to increase the probability that the consumers of your service will be able to successfully invoke operations described in your WSDL.
Yes, that should do it. Same thing applies if you want to have the endpoint in the WSDL point to a hardware load balancer or third-party proxy server in the DMZ.
BTW, an approach discussed WS-I is to break your WSDL into multiple physical files according to the level of abstraction in each section. This allows the more concrete portion that contains the protocal binding and the soap endpoint address to be maintained in a separate file from the more abstract types, messages and port type sections. At this time, WSDL’s generated by Developer do not support this “authoring style”.
I do have a question related to security? i.e by default we have SOAP/HTTP and I am sure this is not a secure way to do it and there is always an option of SOAP/HTTPS, given the fact that IS still don’t support WS-Security standards what are the alternative options?
Well, since setting up an HTTPS port is very simple, you should do that unless all of your service consumers are internal and trusted (given your specification of a Reverse Invoke server I assume that is not the case).
IS does support WS-Security because it supports XML and WS-Security is just XML after all. You just need to write the code to process the security tokens and deploy it in a custom soap processor which is simply a Flow or java service registered to listen on a specific IS directive (e.g. /soap/secure or /soap/mysoapprocessor).
Also, why are you using both a hardware load balancer and Reverse Invoke? Doesn’t that mean you need two Reverse Invoke servers in your DMZ pointed at two or more IS server’s inside your DMZ?
If your firewalls are configured to only allow inbound connections from your load balancer, content switch or secure proxy I’m not sure you gain much from Reverse Invoke.
Why not? The primary function of a Reverse Invoke server is to provide enhanced security over the out-of-the-box IS configuration using a proprietary protocol that involves internal IS servers creating outbound connections through the firewall to the RI server. In this manner the firewall can be configured to block all inbound connections.
However, I usually recommend leveraging an enterprise’s existing web server security components in the DMZ rather than adding an IS-only proprietary solution. Why re-invent the wheel for securing the HTTP/S portion of IS when your organization has most likely already done this for its existing web servers or other HTTP-accessible components.
If your organization has no other HTTP security approach (how could this be?) I still suggest acquiring a third-party secure proxy, load balancing or edge server that could be used for non-IS products (such as webMethods Portal for example).
Reverse Invoke was a critical component in the early days of B2B, but unless you are absolutely determined to have an IS-only HTTP security solution, I do not recommend it.