Resources for IT Professionals >
Forums Home
>
BizTalk Server Forums
>
BizTalk Server General
>
Synchronous service intermediary in BizTalk
Synchronous service intermediary in BizTalk
We would like to use BizTalk Server 2009 as a service intermediary in synchronous scenarios. Today we use BizTalk as message-bus for typical asynchronous publish-subscribe scenarios, with big success. The reason why we will use BizTalk Server as a service intermediary is, that it give us possibility to do mapping of the requests/responses and use the broad variety of adapters and then of course monitoring using BAM.
We have made a proof-of-concept on synchronous scenarios and that works fine, but the latency in periods of heavy-load isn’t acceptable because of BizTalk’s pub/sub architecture, where synchronous messages aren’t prioritized. We have tried the following without success:
· Working with send port priority
· Assign the synchronous work to a dedicated host
· Make load-test with both small and big files, but with no differences on the result
Our main problem is that we can’t find any way to prioritize asynchronous communication over the asynchronous.
My question is now; does anybody have some experience or best-practices for setting up / using BizTalk in synchronous scenarios? Especially in environments that is also used to heavy asynchronous communication in periods?
Thank you!
Answers
- I've had a lot of success with BizTalk for synchronous services. I spend a lot of time tuning it to do this and use a separate Group from one that does asynch. The real issue is that you need to balance throughput and latency. Darren Jefford's book Professional BizTalk Server 2006 goes into this pretty deep. It is very good.
Tuning for BizTalk is something most people do not know very well, it is very intricate and takes a long time and careful planning to get right. It also takes knowledge of SQL Server, Windows OS, TCP/IP, and often SAN (just to mention a few of them). You should be able to get sub 100ms response times, but it's gonna take some work to get there and limit how many concurrent requests you can serve. Keep in mind though that in most enterprise applications you only have 1-2% of your users actually making requests at any given time.
Kind Regards,
-Dan- Marked As Answer byWen-Jun ZhangMSFT, ModeratorThursday, November 12, 2009 6:11 AM
All Replies
- Hi,
I think another but related question that you should first try to answer is; Is BizTalk acceptable for synchronous scenarios? A general answer to this question would be: it depends.
BizTalk is a very reliable system. This comes with a certain performance penalty however. When you have a "direct request response scenerio" where human users (using a web app) are waiting for the response from BizTalk before they can go on with their work you'll probably have a hard time keeping up with the performance requirements.
There are of course things you can do to enhance the response time. You can scale out hardware, tune the environment or use things like inline sends.
For other synchronous scenarios (where other systems (not humans) are waiting for the biztalk response) BizTalk might fit.
There are a couple of alternatives you might consider:
You can do the synchronous work using WCF services (outside of BizTalk). In this scenario you can still make use of mappings (like they in ESB toolkit) and BAM (using the BAM API). Of course this might not be as reliable as using BizTalk.
if you can send make the synchronous calls asynchronous by using callbacks. The client calls BizTalk and goes on. BizTalk processes the message and calls a service on the client when finished.
I really wonder what other community members answer will be to your question and also if they agree with me. So please comment :-)
HTH, Randal van Splunteren - http://biztalkmessages.vansplunteren.net - Please mark as answered if this answers your question. - Hi,
It is one of the common question being asked, if BizTalk is appropriate for synchronus solutions. I myself has asked this question in different BizTalk events. The answer I got is that if it is simple point-to-point service, then WCF should be preffered. In our scenario, we are moving our availability services out of BizTalk and moving them to WCF due to latency. But the booking services which interacts with many local and external services are well suited to BizTalk. Please see the article http://blogs.digitaldeposit.net/saravana/post/2009/03/04/SOA-where-will-BizTalk-Server-fit-in-the-technology-stack-(from-performance-perspective).aspx, this article is very close to the responses that I got from different BizTalk experts in our BizTalk group meetings as well as in Microsoft events.
As far as ways to prioritize asynchronous communication over the asynchronous is concerned, you can have different host set for different adapters (http://msdn.microsoft.com/en-us/library/aa577415(BTS.20).aspx) as well as for different orchestrations () and spread them accross different server. The exact architecture will depend on your applications, number of licenses etc.
Regards,
Tariq Majeed
Please mark it as answer if it helps- Edited byTariq Majeed Thursday, November 05, 2009 10:18 PM
- Edited byTariq Majeed Thursday, November 05, 2009 10:19 PM
- I would typically recommend that BizTalk is not really a technology I would equate with real-time responsiveness like where a user in an application is waiting for a response. Real-time responsiveness is similar to synchronous execution.
It is an interesting question about setting processing priority in BizTalk. As far as I know there isn't really that level of granularity.It sounds like specifying whether to run on a background thread. In MSMQ you have a queue priority which actually affects execution.
These capabilities are not available with BizTalk because you do not have this level of control over the BizTalk process. In a custom WCF service host you could handle the thread priority and better control the execution.
Thanks,
If this answers your question, please use the "Answer" button to say so | Ben Cline - Hi Tariq.
When you say, that your are moving services out of BizTalk and moving them to WCF, do you then mean, that you wrap the bakcend services in your own WCF services? - Hi Anders,We have some very simple availability web services. We will not be using BizTalk for them due to latency. We are creating regular WCF services (non-BizTalk) for them.Regards,Tariq Majeed
Please mark it as answer if it helps - I've had a lot of success with BizTalk for synchronous services. I spend a lot of time tuning it to do this and use a separate Group from one that does asynch. The real issue is that you need to balance throughput and latency. Darren Jefford's book Professional BizTalk Server 2006 goes into this pretty deep. It is very good.
Tuning for BizTalk is something most people do not know very well, it is very intricate and takes a long time and careful planning to get right. It also takes knowledge of SQL Server, Windows OS, TCP/IP, and often SAN (just to mention a few of them). You should be able to get sub 100ms response times, but it's gonna take some work to get there and limit how many concurrent requests you can serve. Keep in mind though that in most enterprise applications you only have 1-2% of your users actually making requests at any given time.
Kind Regards,
-Dan- Marked As Answer byWen-Jun ZhangMSFT, ModeratorThursday, November 12, 2009 6:11 AM
- Hi,
Well the basic thumb rules for improving latency are:
hardware: Scale Up (add more RAM, CPU)
software: Try to reduce message box touch points. (use .NET components wherever necessary)
others: follow the advice of Dan.
Please mark as answer if this helps you. Thanks and warm regards Ambar Ray EAI Architect - Microsoft Technologies
