Hi Michael,

 

Have you considered SQL Server Service Broker? It would provide you with a
transacted queue between the SQL Server databases.

 

Regards,

 

Greg

 

Dr Greg Low

 

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax


SQL Down Under | Web:  <http://www.sqldownunder.com/> www.sqldownunder.com

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Michael O'Dea-Jones
Sent: Monday, 14 May 2012 1:21 PM
To: ozDotNet (ozdotnet@ozdotnet.com)
Subject: Application Interface Options for Integration

 

Hi all,

 

Scenario: 

 

1.       Two systems need to be able to communicate via middleware

2.       Source System is ASP.Net 4.0 web application

a.       Has SQL Server Database

b.      Exports via Export tables in SQL database

3.       Destination System is not a .Net application

a.       Has SQL Server Database

b.      Imports via control tables in SQL database

4.       Middleware is .Net 4.0 system with WCF services

a.       Customised .Net plug-ins will be written to ETL from source to
destination systems

 

Current ETL is via SSIS packages and there are issues with sequencing,
performance and lack of business rules, logging and alerting. Source System
Vendor is happy to implement WCF services to push data to middleware though
they need time to upskill. 

 

Could I have an opinion on this idea:

 

Developer supply Source System Vendor with .Net library which they integrate
into the source system. Library has a couple of method calls that submit
messages from source system to middleware via WCF. A provider pattern could
be implemented in the class library so other clients could supply their own
"export" providers.

 

Pros: 

 

Easy for source system vendor to implement as they don't have to research
and develop WCF solution

Costs client less because fewer changes are required to the source system

Client gets update quicker

Client has the flexibility to update Export Provider any time they like

Other Clients could implement non-WCF Export 

 

Cons:

 

Architecturally it might be better to implement WCF from the start

Might reduce operational calls and issue complexity for the Vendor if there
is only one way to export data

 

 

Regards,

 

Michael O'Dea-Jones

 

Reply via email to