locked
Thoughts on an Enterprise Service Bus for this architecture RRS feed

  • Question

  • We will need to keep data between two applications synchronized.  I've done a lot of research on this and think a service bus that uses messaging is a great solution for this project, but I wonder if there is something I don't know about that may be better.  I believe the approach I'm considering is a good one, but I welcome any confirmation, clarification or additional thoughts you may have.

    We have an application hosted remotely and one that will be hosted in house. Certain data in these applications will need to be synchronized so they contain the same values.  The remote application provides a SOAP based API while we will be able to do direct inserts/updates to the db with the one in house.  Our solution must reside in house due to business requirements which excludes cloud based solutions.  Both of these apps are built on the .NET platform and have different data schemas.  

    We've considered ETL processes for this, but it seems like it would still require a lot of manual intervention and this may not be the best approach.  Another idea we've come up with is have a "Master database" that sits in the middle and use some sort of polling service every thirty minutes or so to see if one of the applications databases has stale data.  Some custom software created in house would then update the stale data.  This seems like a very monolithic approach with number of concerns such as being too tightly coupled in case another system is added in the future.  Plus, it introduces a single point of failure.

    I am new to the enterprise service bus(ESB) concept, but it seems like a great solution to our problem.  It provides things like the ability to "plug in" other applications in the future with greater ease.  It would reduce or eliminate existing code from having to be redone if something else, like a third application, is added in the future.  This would use the pub/sub concept and not be a hub/spoke type of thing which makes it more resilient should there be an outage of some type.  It would also prevent a single point of failure from sitting in the middle like the "Master database" idea we had or a message broker(hub/spoke solution) would create.  There are also other benefits of a service bus like the durable messaging which should prevent data from being lost should there be an outage.  We are a growing company and implementing an ESB now would allow us to move forward and be poised for growth more easily once it's been implemented.

    Does anyone have any thoughts or experience they would like to share? 



    Thursday, August 28, 2014 5:57 PM

All replies

  • Would the 'outside' application also publish its events to the ESB?

    http://pauliom.wordpress.com

    Friday, August 29, 2014 10:01 AM
  • I don't know if it publishes its events and haven't considered this. Would it have to for the ESB to work?It seems like it would have to for the ESB to know if something has been updated, inserted...etc. Is this how ESBs typically work?
    Sunday, August 31, 2014 8:21 PM
  • It's much nicer if the app publishes its 'events' to the bus too. 'Long Polling' would be a workaround if it doesn't.

    http://pauliom.wordpress.com

    Monday, September 1, 2014 6:46 AM
  • Also have a similar issue - have 2 .Net seperate applications that I want to merge to 1 product that both have a service layer.

    Rather than a db schema merge project, I am thinking the Service Bus route.

    New to ESB ... so currently looking at Biztalk, Service Bus 1.1, nServiceBus 

    Thursday, September 11, 2014 1:45 PM
  • BizTalk is more about converting from one to another, not really a service bus IMO

    http://pauliom.wordpress.com

    Friday, September 12, 2014 9:17 AM