BizTalk用于实时消息传递

Question

My company is exploring using BizTalk for our messaging infrastructure and I was just curious if it would be a good candidate.

First off we are a .NET shop and do process medical transaction processing. Currently all of our products are written to do their purpose with really no common code. Most of these transactions come over a standard TCP socket (think HL7 using MLLP as a model). We then process these and may send them off to one or more 3rd parties for processing over a socket as well. Lastly we send the transaction response back to the customer. We have quite a few applications that operate like this we are looking to put on a uniform platform.

We need this to operate very fast (<6 seconds on some things) as well as being very fault tolerant while scaling. I have been told that this is where BizTalk excels.

My question is for you BizTalk experts, does this sound like something BizTalk could do well? And any other advice you can give for a migration like this?

Answer 1

FWIW, my take:

Biztalk Strengths wrt your requirements

• Mapping of messages is straightforward and you have the choice of visual mapping or xslt.
• Uniformity of Development - once your dev team has overcome the learning curve, it does allow for a centralized platform for most types of EAI work (ie you can keep adding new applications to your Biztalk servers, which can leverage existing messages and processes).
• Transactional reliability - you can pretty much pull the plug on BizTalk and it does a good job of recovering state without losing data.
• Protocol agnostic - internally everything is XML to Biztalk. You can deal with 'special needs' customers with a wide range of adapters available out of the box without rewriting your app.
• Low maintenance operation - once you've deployed and debugged your apps, tuned your production environment, and set up the SQL and Monitoring (eg SCOM) maintenance tasks, BizTalk can tick away like an appliance.
• Scalability (at a price) - BizTalk has plenty of knobs for scaling up, and multiple servers can be added for scale out. However, we've typically found the bottleneck to be the underlying SQL Server in most instances.

Weaknesses

• There will be some challenges to guarantee latencies / maximum processing time. eg Significant thought will need to be given when BizTalk is under extreme load to avoid throttling states which can cause a backlog of messages to queue up.
• Dynamic routing is a bit patchy on certain protocols / adapters - you will typically need to blend in some of your own code, if you get to the point where it becomes unwieldy to manage large numbers of static send ports with filters. eg if you have 100 3rd party destinations [say funds] - and 10 000 customers - [say doctors / hospitals], then routing message flows originating from funds to doctors isn't going to be fun. If you can keep your message flows originated from the 'many' side, and using a synchronous protocol, you can avoid the routing issues.

FWIW I have used BizTalk in a medical environment (but on the fund side, not a switch), without too many challenges (that said, we only needed to route to 3 different switches). I'm guessing that your <6 second requirement is for real time pharmacy auths etc. One thing I would do is split the real time processing and the batch processing (eg claims batches) onto different process hosts, or even different servers entirely. This should avoid the potential for delays in synchronous processing (eg pharm auths) caused by the arrival of a large batch (eg of claims) which may not have the same low latency requirement.