1

We need to send an XML messages between a point of sale system and a java webservice (outside of our network). the messages contain very sensitive data. The messaging has to be secure and transactional and highly available (24/7) with failover. The solution requires the developement of a broker that does the following:

  • Poll messages from the POS of system (3 types of messages)
  • do some transformation to the messages
  • forward part of the message to the java webservice
  • store part of the message in a database
  • notify the POS system of the result

Based on these somewhat simplified requirements, do you believe that Biztalk would be overkill? would MSMQ/WCF do the trick here?

Thank you for your help

Amine

Amine Zegl
  • 71
  • 2
  • 8

3 Answers3

4

IMO if you have the ability to receive and deliver messages asynchronously, then MSMQ (or other Message Oriented Middleware) would be an obvious choice for reliable, transactional transport, irrespective of the rest of the solution. MSMQ's journalling can also be used for audit and debugging purposes (but you will need a strategy for archiving the journal).

For the Polling, Routing, Mapping / Broker and Auditing requirements you then have the choice of BizTalk, other ESB and EAI products, or a DIY solution.

As you've suggested, it is difficult to justify the cost and learning curve of BizTalk on a single message exchange scenario such as this - you could probably knock up a .NET Windows Service (e.g. using WCF, Workflow Foundation, Transaction Scopes, some XSLT for mapping and a data access layer) in a few days.

However, if this isn't a one-off integration scenario and the need for additional integration arises (more applications to integrate, more services, additional listeners, different communications technologies etc), then it would be advisable for your company to take a long term view on EAI and ESB technologies. IMO the main challenge in integration isn't the initial development work, but is instead the ongoing operational management requirements - e.g. security, auditing, failover, monitoring, handling of bad messages and other exceptions - where products such as BizTalk are really worth the outlay.

StuartLC
  • 104,537
  • 17
  • 209
  • 285
  • Could you please answer http://stackoverflow.com/questions/9631349/what-is-outbound-transaction-in-layman-terms ? – LCJ Mar 09 '12 at 09:16
3

Do you want to and have the bandwidth to develop, monitor, and maintain your own custom solution? If you don't mind doing that, then going the route of a custom .net-based, MSMQ/WCF solution might work well.

BizTalk will also cover all of the requirements you have listed. There is a learning curve but it is certainly not insurmountable. The initial ramp-up may be lengthier than would a custom-code solution, but there are considerable benefits, particularly the benefit of having all your requirements reliably met:

  • secure
  • transactional
  • reliable (messages aren't lost)
  • highly available (24/7)
  • failover
  • adapter architecture (includes polling adapters)
  • transformations
  • working with external web services
  • returning correlated responses back to the source system (i.e., orchestrating the end-to-end process)
  • use a broker (you specifically listed this, and BizTalk is a broker; custom MSMQ and WCF means using no broker)

If BizTalk needs to poll the POS system, then you do not need to worry about using MSMQ. BizTalk can handle transferring messages reliably (they're persisted to SQL Server, while MSMQ persists messages to disk).

Note too that the only way to make MSMQ highly available is to cluster it. So either way you'll need to cluster something.

A BizTalk solution will be easier to maintain over time, particularly if you just want to update your transformations. With versioning you can do so in a way that doesn't require downtime. It'll be tough to update a custom solution without downtime.

Some people have had difficulty in the past with monitoring BizTalk for failed messages, but I have found it to be easier, especially with a tool like SCOM or BizTalk 360, than trying to monitor message queues, which often requires even more custom work to monitor. Just make sure to include monitoring in your cost estimates for the life of your solution.

If you do need auditing, then BizTalk also has you covered. MSMQ Journaling will keep a copy of each message for you, but without significant transaction details and with no out-of-the-box way to search through or archive the data.

Building your own .NET client code to work with a Java web service will likely take a good bit of work regardless of which way you go. With BizTalk that means running a wizard against the endpoint or against the WSDL. With WCF it means doing everything by hand or with the assistance of the svcutil tool.

schellack
  • 10,144
  • 1
  • 29
  • 33
1

You should go with MSMQ transporting either way.

If you use MSMQ from .NET you should know its limitation: 4 MB on a message size.

BizTalk on the other hand has MSMQ adapter which overcomes this limitation (if a second BizTalk server listen on the other side of the channel).On top of that BizTalk gives you features like: easy configurable message tracking, visual transformation maps. It can be set up in cluster too (Ent. version only).

But the question is can you (or do you want) afford biztalk licenses and hardware for it servers (it's slower then custom .net solution).

Dmitry Golubets
  • 570
  • 5
  • 13