Maybe I am missing something here, but it seems like the point of doing Merge Replication via IIS is so that you do not have to expose your DB server directly to the internet (i.e. all your clients), rather you expose a webserver to the internet and the webserver handles the replication keeping your DB server closed to direct internet access and thus keeping it more secure.
However, to set up Internet Merge Replication using IIS a client has to have direct internet access to the DB server as a stored procedure needs to be run on the publisher.
So Internet Merge Replciation using IIS makes it so your DB does not have to be directly exposed to the internet except your db needs to be exposed directly to the internet so every client can execute a stored procedure against it. How does this make sense? Yeah, I can write a webservice or something that gets the SP from the client and executes it against my db server but why should I have to? Why isn't the dll that the "Configure Web Synchronization" wizard puts into place capable of doing this?
Using web sync not only "hide" your sql server from the client, but also extends the merge replication to devices as well as PCs in anywhere that has the internet access. the later is actually the main reason to have this new sync type.
Sure, one can write their own web services to do the sync ( in fact, I believe there are some companies doing that already ), but this will not fully utilize the merge replication's functionalities to the web client subscriptions as it was to the fully connected subscriptions.
hence, the "Configure web synchronization" wizard means to provide some walk throguh steps to help users to set up the IIS server for replication and not to intend to setup the webservices.
thanks
Yunwen
|||Thank you for your reply, but your reply...parts don't make sense and other parts don't answer what I asked.
>> but also extends the merge replication to devices as well as PCs in anywhere that has the internet access. the later is actually the main reason to have this new sync type.
That is NOT the "main reason" of doing web sync via IIS. Since for a client to do merge synching offsite, they have to have internet access to the sql server location, synching could be accomplished quite nicely without IIS by merely poking the appropriate holes in your firewall to allow the needed direct sql connections to be made. Thus IIS is not what facilitates merge synching over the internet. It still seems to me that the ONLY point of doing merge replication via IIS is to hide your SQL server from direct internet access.
>>Sure, one can write their own web services to do the sync
I never said this. What I said was that to set up Merge replication a client needed direct access to a sql server because a SP (Stored Procedure) has to be run against the Publisher that registeres the subscriber with the publisher. If you are using IIS to accomplish your merge replication, then you do not have your sql server directly exposed to the internet which makes it rather hard for your subscriber to connect directly to the publisher to execute a SP. What I said was that I could write a Webservice that could facilitate the subscriber sending the SP to the publisher but that I shouldn't have to as the replisapi.dll should be doing that. I said nothing about writing a webservice to do the sync, just that as things stand now I would have to write a webservice to facilitate setting up the sync.
So again, it seems like the point of using IIS to do merge replication is to hide your SQL Server publisher from the internet. However, part of setting up a subscriber involves running a SP (Stored Procedure) against the SQL Server Publisher. If your SQL Server publisher is hidden from the internet, it makes it rather impossible for your subscriber to connect to it to run a SP against it. It seems that currently the only work around is to make your own webservice that can access the SP arguments from the subscriber and run the proper SP with the proper arguments against your publisher for you. It seems sort of silly that you would have to set that up yourself, that MS hasn't built that in to something that already exists.
The situation is analguous to the Exchange RPC over HTTPS problem that occured when Office 2003 first came out. RPC over HTTPS allows Outlook to run against an Exchange server without having to have direct port 135-139 access. However in order to set up RPC over HTTPS your computer FIRST had to be able to connect directly to Exchange on ports 135-139 (which was a problem for me since I use Comcast and Comcast blocks these ports). The only work around was to lug my computer into the office, put it on a lan with the exchange server, setup RPC over HTTPS, then take it back home.) MS has since fixed this problem. However, this seems like the exact same problem. Doing merge replication via IIS makes it so that clients do not have to connect directly to the SQL Server, however to initially set up each client, that client has to connect directly to the SQL Server. Is there a way around this?
Thank you
|||Many people may not have ability to connect to publisher directly through port 1433. That is one of the main motivation to support https (port 443) replication. IIS server is needed to understand the https protocol.
|||Yes, that is right along the lines of what I have been saying.
Why is this so hard to understand? I will try to make it simple.
I have a sql server that is acting as a publisher. This publisher is not directly accessable via the internet. I have set up Merge replication using IIS and https on a server running IIS. The IIS server is accessable to the internet on ports 80 and 443. Ok? Simple enough.
I want to connect a subscriber to this publisher. The subscriber is somewhere on the internet. In order for the subscriber to successfully set up its subscription, it needs to execute the Stored Procedure named "sp_addmergesubscription" ON THE PUBLISHER!
As you so aptly pointed out "Many people may not have ability to connect to publisher directly through port 1433" that being the case, how then is a subscriber supposed to run the stored procedure "sp_addmergesubscription" on the publisher?
|||You have two choices:
1. Add the subscription at the publisher before subscriber connects. Meaning an administrator at the publisher will need to add this information, not the subscriber since the subscriber does not have access.
2. Connect as an anonymous subscriber. Meaning if subscriber cannot have their subscription added to the publication, then connect as an anonymous subscriber, which will add the info for you on your first connect.
No comments:
Post a Comment