0

I work in a software company that delivers a software product. Many times we must integrate with other applications. 70% of the time we integrate with a single application. Currently we do not use middleware (MuleESB, Biztalk, ...) in these situations: the data conversion, transport conversion, etc is handled inside the applications.

Wouldn't it be better to ALWAYS use a middleware solution? (no matter if your integrating with 1 or more systems) This way, all the customizations (data formatting, restructuring, transport conversions) of both parties, can be handled by the middleware, instead of by the applications.

Logically this seems to me the right approach. But I ask myself: Is middleware in the case of two applications justifiable?

sultanazzal
  • 11
  • 2
  • 1
    No it wouldn't be better to *always* do things in a certain way. I'm afraid that you won't get a satisfying answer that applies to all situations. The answer is "it depends". Think of other arguments like costs, complexity and so forth... – reto Mar 07 '14 at 07:51
  • exactly as @reto said. whilst it is good to think ahead, sometimes the time and effort is not worth it due to varying degrees. you need to look at it on a case by case scenario and see what happens. For example, I wouldn't use MSMQ all the time but only if needed. I wouldn't use AppFabric for caching if it is not needed. However I do use a service layer always in projects because that is the standard way of developing an n-tier SOA solution which is robust, separate layers of concern and reusability – Ahmed ilyas Mar 07 '14 at 08:02
  • @reto: sometimes I believe you can always do things in a certain way. for example, one should always use patterns when developing code, and to me, it appears that in enterprise integration, there are patterns too, e.g. message transform, message router, etc. I just think it would be better to have a fixed 'services layer' in our company product and have a seperate layer between the interfacing applications: integration middleware. I just want to keep all custom boilerplate out of the main product. – sultanazzal Mar 07 '14 at 19:31

3 Answers3

1

In practical terms, you will always be using a "Middleware" solution, either custom or packaged.

I'd look at it this way, rather than requireing a "middleware" package, I'd focus on making the app itself integration friendly by using a consistent and as-standard-as-practical API for exchanging data.

Then the decision on what "middleware" to use is more driven by the circumstance on site. If the customer has only one app to integrate, then a simple custom solution might be perfectly serviceable. If they have 5 apps and defined processes for each, then a package makes more sense.

I don't always use middleware, but when I do, I use BizTalk. ;)

Johns-305
  • 10,908
  • 12
  • 21
0

I found this to be a useful read when considering appropriate architecture. If you get a chance to see Richard Seroter's "Decision Framework" presentation, you should.

Jason Hyland
  • 744
  • 1
  • 8
  • 21
0

Wiki site on Publish subscribe pattern http://en.wikipedia.org/wiki/Publish/subscribe shows an interesting comparison between how publish subscribe relates to client server.

rupweb
  • 3,052
  • 1
  • 30
  • 57