IBM Cast Iron and ESB

4
votes

I'm trying to define the integration architecture roadmap for my company and I'm looking for some guidance on my approach.

Most (90-95%) of our applications are based on .NET with Microsoft SQL Server 2008. We have sales cloud in Salesforce and planning to migrate more applications (to Force.com platform) Salesforce in the coming years. We bought IBM Cast Iron for integrating our on-premise applications with Salesforce and possibly within our on-premise applications. Now after analyzing the existing applications and the existing integration (ad-hoc - SQL jobs, windows services,...), I felt that we needed an ESB as I realized that we have multiple ways that we use to talk with the applications (FTP, Web Services, CSV/Excel, SQL). Though Cast Iron can take any type of formats and can talk Web Services, FTP, etc..., I'm concerned about positioning the Cast Iron as the core integration platform as this will become a broker architecture (similar to Hub and Spoke) that follows traditional EAI approach which may suffer from single point of failure and performance issues as the orchestrations increase.

By introducing ESB, I think I'll achieve at least the following benefits:

  • Scalability
  • Reliability
  • High performance

The attached diagram reflects a simplified version of this scenario. This architecture can also be expanded in future by providing SOA over the ESB.

enter image description here

Now my concerns/questions are:

  • Since Cast Iron is an orchestration tool, which one should I use for orchestrations? Is it Cast Iron or the ESB?
  • Cast Iron can only talk to JMS/IBM MQ and cannot talk to Microsoft Messsage Queue. So, should we go with java based ESB like Mule (with Active MQ) or Service Mix?
  • What are my options for .NET based ESB (other than Microsoft Biztalk and NServiceBus), which is reliable and most widely used?
  • What's the best practice on bulk data movement? Usually, this can be done through SSIS. In our case, we may have to move bulk data to cloud on periodical basis.
  • What's the best way to publish messages to JMS based message store from .NET applications?

I know I have asked many questions here and may or may not have direct answers. I would be glad to hear the views from the gurus.

1
.netmessage-queueesbmessagebroker

1 Answers

3
votes

1) It depends. Cast Iron is good for rapid on/off premiss integrations/orchestrations. Orchestrations concerning external/SaaS services would be natural to orchestrate in CI. There is no clear answer, "it depends".

2-3) Since you have WebSphere components already, a good solution I tried integrating with .NET and Messaging (IBM WebSphere MQ) is WebSphere Message Broker 8. It has built in support to run embedded .NET code. For instance, you could fire up Visual Studio and then import a service reference, and just invoke it straight away, while still having a full scale (java compatible) ESB. The express edition is a bit cheaper, but somewhat limited. Using the underlying WebSphere MQ would give you .NET client support and very good integration with Cast Iron. You also mention ServiceMix, which essentially is an OSGi container around ActiveMQ and Camel. It's a powerful open source ESB. Mule ESB CE + ActiveMQ would be rather similar, it's not really a deal breaker which of those you choose. ActiveMQ have support for .NET clients as well and is often underestimated as enterprise JMS broker.

4) Bulk data. My experience is that this is a very complex topic that there is no best answer to in all scenarios.

5) There is no generic solution for JMS -> .NET connectivity. It does not work, without bridging components running on JVM. However, most JMS implementations offer similar, but non standard, APIs for .NET clients. Both WebSphere MQ (XMS) and ActiveMQ (NMS), this goes for most other vendors as well.