If I were the source system vendor I would be implementing webhooks if I cared at all about integration of my application.
http://www.entechsolutions.com/hooks-and-sockets-for-web-apps If I were you I would be asking for webhooks. But, maybe, that's just me. I would probably also look at using ZeroMQ if I were going to create middleware for disparate clients. On Mon, May 14, 2012 at 5:20 AM, Michael O'Dea-Jones <[email protected]>wrote: > 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**** > > ** ** >
