|
Hi. We have the following scenario: A backend server, running a database in SQL Anywhere 12. A frontend server, running IIS 7. We would like to create webpages that can access data in the backend server, without opening ports or using webservices - ergo using SQL select commands. It would also be great if our customers could use their Windows Application (PowerBuilder) outside of the company LAN, connecting to the database through this frontend server. I've looked in the documentation and found a bit about the Relay Server and Outbound Enabler. Do we have to setup an MobiLink server at the backend server, or can the Relay Server talk directly to the SQL Server through the Outbound Enabler? And if so, how do we connect a webpage (or the windows application for that matter) to the Relay Server so that we can select on the backend SQL Server? Is it possible to use an ODBC, and that the Relay Server does the magic of connecting? Maybe we're thinking wrong here, so what is the best practice for this approach? And is there any conflicts in running an IIS webserver and the Relay Server on the same physical computer? It looks like both are using ports 80 and 443 for communication, and that might cause problems. Regards, Bjarne Anker AKVA group Software Norway banker@akvagroup.com |
|
It would also be great if our customers could use their Windows Application (PowerBuilder) outside of the company LAN, connecting to the database through this frontend server. SQL Anywhere does not support direct client connections (e.g. ODBC/DBLib/OLEDB/ADO.NET/TDS) via an HTTP 'relay' - we only support them over a straight TCP link. However, SQL Anywhere does support hosting 'web services' (e.g. the database server acts like a web server), which you could make HTTP requests to using a simple reverse-proxy set up via your IIS server (e.g. IIS' "Application Request Routing" feature). These HTTP requests against the SQL Anywhere web services are translated into executing "stored procedures" on the database, which you could then craft to respond to queries/URLs of your design. What is the best practice for this approach? The SQL Anywhere server itself can also act as a client to these web services (e.g. make web service calls, return results), so that is 'the way' to communicate to the server across HTTP. You can certainly use other web client technologies as well. Do we have to setup an MobiLink server at the backend server, or can the Relay Server talk directly to the SQL Server through the Outbound Enabler? The Relay Server is essentially a slightly more complicated version of an HTTP forward-proxy. It is used to maintain 'channels' for MobiLink (and other technologies') synchronization (e.g. Copying data from a central 'Microsoft SQL Server' down to a remote 'SQL Anywhere' database). If you are not already using MobiLink technology, then you probably do not need the Relay Server technology in your solution. And is there any conflicts in running an IIS webserver and the Relay Server on the same physical computer? It looks like both are using ports 80 and 443 for communication, and that might cause problems. The relay server is an ISAPI extension that "plugs-in" to IIS - it will not consume a TCP port. There is a separate process (rshost.exe) that the extension talks to, but this process also does not use a TCP port for communication, so there will not be a conflict. If you wish to run the Outbound Enabler (RSOE)/MobiLink server on the same server that is hosting IIS, you can use the 'mlsrv12 -x' start-up parameters to choose which port the MobiLink server will start on. |
|
Ok, I understand. Could eg. OpenVPN be a alternative way to let the ODBC-connection through to the backend server from the webserver in the DMZ? Is it "safe enough"? The webserver is a standard Windows 2008, without RRAS or ISA installed. If you can make a direct TCP connection to the database server (over whichever connection technologies you need to employ to get this up and running), this should work. "Safe enough" is an evaluative term that is different from person-to-person; if you require security for your communications, it is recommended to encrypt your database connections using strong encryption technology.
(02 Sep '11, 09:46)
Jeff Albion
|
|
OpenVPN should do the trick. it would be best if you can get the info direct from someone who understands some of the details better than I might, but we are using OpenVPN on the advice of our computer support company and after seeing that we have a secure tunnel to the database server and can connect to our database by non-routable (192.168.x.x) ip address. We use it for testing and support, not for 24x7 production access. |
