I’m wondering if anyone has done any performance benchmarking of RI your transactions to your internal system vs. https your transactions to your internal system. IMHO, I think RI is a nifty invention, but a proprietary one at that. Also, is the polling a performance bottleneck? Why not use https? Or is it more a concern of someone else hopping on the line?
Jordon,
I use reverse Invoke every day. Our entire application has one Internal server and two proxy servers. HTTPS is defined for port 4443 and https is used because we use certs for our trading partners. No problems except every now and then we lose the reverse invoke connections and we have to re-connect. I wrote a service to reconnect automatically when connections fall below preset number.
Edward,
Would you mind sharing some specifics on how you created your reconnect service?
Thanks for the response. Couldn’t you have the proxy server send the transactions to the internal IS using solely https, and not use RI at all? Why use both https and RI to the internal server (from the proxy)? They are mutually exclusive, and I don’t see the need for both simulaneously from proxy –> Internal.
On a different note, how did RI effect the performance of your B2B transactions? How much overhead and latency did it introduce?
I think RI is a nice concept, but I am trying to weigh the pro/cons of https vs. RI, as I don’t see the benefits of using both.
Jordan,
In some situations there is no alternative to using an RI server. And RI server is best used in environments that dont allow inbound connections from the DMZ to the internal server. In such an environment you cannot HTTPS to send transactions from the DMZ to the internal server. So you have to use RI which works on outbound connections from the internal networks to the DMZ.
I agreee that RI is a persistent connection. I was thinking it was a performance bottleneck due to the “polling-nature” of the technology. Traditionally, pushing a transaction through middleware is faster, cleaner, more scalable, then polling for transactions…ie push vs. poll. Maybe I’m getting too conceptual with RI, but I can see where polling could slow down a high transaction environment.
Now, I can see only 1 scenario where RI is used: The security team absoloutely refuses to allow an inbound connection in the firewall from the proxy. However, if we educate the security team on SSL, Https, encryption, and access control, then they should understand that https is a viable alterenative to RI. Unless, they are really stuborn. Again, I can’t see any reason to use RI and Https simultanously on inbouond transactions to IS proxy and IS backend from the outside world. Sounds like no one has benchmarked https vs. RI, but I think it would be a nice exercise to determine the differences, pros, and cons, etc…wmUsers Ezine article? 
Jordan,
As I said earlier RI maintains a consistent connection between the RI (backend) and proxy server. All requests coming into Proxy (DMZ) server get forwarded/passed (pushed over) through this already open RI connection/channel. Can you please elaborate what you mean by the performance/polling involved in this flow.
This RI channel can also use the secured (SSL) layer.
-fA
RI connection is the best way of approach in DMZ zone,since it also involves https delivery and also security features to protect Internal servers and regarding performance polling ,even with heavy transaction flow it processes in a consistent way.And i have seen this performance using Rosettanet based exchanges.
HTH.
I wouldn’t necessarily say that using an RI server is the best approach overall. What happens if you need to use FTP or SMTP? Can the RI server be used then? No.
Did you know that the RI Server strips header information from the http/s transmission prior to proxying the data back to the internal integration server? Will this affect your web services?
I’ve worked in the mainframe comms arena and there aren’t very many choices. Just a few comments to get you thinking.
Push vs. Poll: ok, my understanding with RI, at least with earlier releases of the product, is that the internal IS (ie…the backend behind the firewally) “polls” the proxy IS to “pull” transactions off the proxy for inbound processing, hence leaving all inbound firewall ports closed. I re-read the 4.6.pdf and it doesn’t mention polling anymore, rather mentions “proprietary, asynchronos communication protocol”, so maybe I was wrong identifying RI as a “pull” technology? I’ll have to do more research on this…
FTP and RI: All you have to do is is create a flow that receives the files and submits the data from the file to itself using http to a reverse proxy port, then it goes through the regular http reverse proxy.
Performance #'s of https vs. RI: Looks like I’ll have to do my own testing on this scenario.
I agree that https from the outside world to the Proxy is necessary, but I still think using https in conjunction w/ RI from Proxy-> Internal IS is overkill.
Thanks for all the responses.
Jordan,
When you configure your integration platform to use an RI server, you are exposing only a small portion of your system to the outside world. Enabling FTP is not recommended, however your statement holds true regarding the workaround.
The idea of having the RI server is just to provide your backend system with a proxy server. The RI Server contains a proxy port that is visible from the outside in. The other port, registration port, is a SOCKS/SSLSOCKS port that is used from the inside out. The connection is persistent, so there is no polling.
Now, there are security issues. All of the security ACLs, groups, users are controlled by the internal server(s). The only user I enable on RI is the Admin (which I change from default.) The only flows or services I make available through the RI Server are the ones absolutely necessary. I conscientiously make sure that there is a partition between functions. For example, I would not allow a service that accesses a database directly from the outside, but, I would allow a service to receive a file. To enable your FTP service scenario, you would have to maintain ACLs, groups and users on the RI server which defeats the purpose. My recommendation is to use an industrial strength FTP server, since this is not once of WM strengths.
The checklist to configure your environment to use RI effectively and correctly is pretty long. It doesn’t mention firewall routing rules, IP Address exclusions, the use of multiple DMZs or any other number of security issues you may need to deal with.
Hope my comments help.
Ray
I agreee proxy servers are still necceessary to protect internal servers…but, I think you can do https from the proxy to an internal (behind firewall) server, so you have:
Outside world->https->Proxy Server->https->Internal IS Server
OR
Outside world->https->Proxy Server->RI->Internal IS Server
but preferably not both (although technically feasible, I think its overkill to have both sceanrios simulatanously.
Jordan,
>Outside world->https->Proxy Server->https->Internal IS Server
If you mean https from proxy to the internal server for each request into proxy then you may want to take into account the additional overhead of the https/ssl handshake for each request, whereas in RI it is once at the begining of the RI connection eastablishment.
-fA