ORM / WCF best practice for pushine data from server A to B ?

Can someone help me with deciding the best way to do the following?

I have a business table in 2 separate SQL databases on 2 different websites/servers.
Both websites use ORM for data access.
On server A, I display a grid of business and allow the user to check which businesses are active and allow 3rd party access.
All that so far is working fine...
When you click update on that page I want to push the active records that allow 3rd party access to a different page on server B and update the business table there. Basically I just need to send the grid dataset to Server B web page and do some processing of the data:
On Database B I need to:
-Update Active status on all rows
-Update Allow 3rdParty access on all rows
'insert all businesses that are not already there
(or I could simply delete all business in DB B and reinsert all from DB A)

I am unsure what I should be using...
SImple form post using serialized data / JSON???
WCF, RIA or what?

If WCF, I found lots on the WCF data services wizard to create WCF from my ORM but can't find much on how to consume the WCF on server B.
It looks to me like RIA is better for querying data using a formatted URL but which technology is best suited for mostly pushing large dataset.
I will have about 2500 business with about 12 fields each.(to start)

Any pointers appreciated.

Hi Bill,

You are describing a typical system integration scenario that can be solved in numerous way depending on your scenario details. I will try to give you some options:

1. Create 2 web services (Plain WCF or WCF Data Services) one for Site A and one for Site B. Call both services when applying an operation on your business objects in your web form. This scenario should be used in case the operations are independent from each other both in time and in data consistency.
2. Create 3 web services (Plain WCF and 2 Data services for example). One service for Site A, one for Site B and one integration service that will call Service A and Service B, wrap them in transaction and provide any necessary validation or synchronization logic. You can host the integration service in either sites or even in a new dedicated site. Your client should call the integration service and should not know that Service A and B exist at all. My personal choice will be this option even if it has a bit of overhead because of creation of an additional service.
3. Create 2 web services (Plain or Data WCF services). Consider one of you web application the parent (lets say Site A is parent). Create one service for Site A and one for Site B. Call Service B in the implementation of Service A. Put there  your validation, synchronization and transaction logic. In you client application call Service A only. This option is similar to option 2, but leaves the web site B as a sub-system of Site A. So any changes made to Site A will most probably affect Site B too.

Regards,
Viktor Zhivkov
the Telerik team