VJ,
I'm going to split the proposed architecture into two sections, a poll and publish:
Receive Data from Oracle Database
I see two possible options here:
1. Use your existing .Net assembly (I'm presuming a Windows Service) to poll the Oracle database, generate and FTP the CSV file to the remote BizTalk server for later processing.
or
2. Use BizTalk with the Scheduling Adapter (see http://www.codeplex.com/BizTalkScheduledTask) to poll the Oracle database at specified intervals and transform the message returned by the Oracle adapter into a CSV file and FTP to the remote BizTalk server for later processing.
I think that FTP-ing a CSV file at this point is beneficial as you will reduce the total size of the file being transferred over FTP when compared to Xml. Furthermore, if you plan on using BizTalk as the poller, I would suggest you look at either Branch or Standard Edition to reduce licencing costs (although you would lose relisiency).
Publish Data to Remote Oracle Database
Given that you are looking to have a single controller handle the 60 message types, I would suggest a simple custom ESB implementation. The CSV file can be disassembled and mapped (on the receive port) to a common (or set of common) canonical message formats that can be handled together rather than individually, allowing you to have just one orchestration (or maybe a small set of orchestrations) that handle message publishing to the destination Oracle database.
The CSV file would be received and disassembled (preferably generating a single Xml message per source database record, to ensure small units of work) and the resulting messages published to the Message Box. Using direct binding, the relevant orchestration would collect the message and promote routing information to aid subscription by the send ports (allowing the send port inserting records into table A to collect messages for table A and not table B for example) - this routing information could be based on message content and facts stored in the Business Rules Engine for example. The orchestration would then publish the message back to the Message Box via direct binding, allowing the relevant Oracle insertion send port to subscribe to the message based on its routing information. Given that the orchestration will be as generic as possible, the Send port will need to map (on the outbound stage of the port) from the orchestration canonical format to the format required by the Oracle adapter to insert into the relevant table. With Delivery Notification enabled, the orchestration will be notified of failed insertions and compensate accordingly.
I hope this helps get you started - the original architecture was almost there so only needed a little tweaking.
Rgds, Nick.