- This topic has 20 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
-
WMQ and MSMQ are mostly equivalent technologies.
Advantages of MSMQ = Price!
Disadvantages = only works on Windows platform-
Thanks. yes exactly cost is the important factor here and obvioulsy MSMQ comes free with Win 2003 Server.
About the other disadvantage yeah it works on Windows but then we can always have Web Services sending messages to MSMQ and MSMQ will talk to Biztalk using the MSMQ adapter, I hope this can be done, please do share your thoughts on this.
Also, if there’s any artcile which talk about using MSMQ with Biztalk, please do let me know.
Howard
-
Using a web service to send a message to MSMQ is technically possible, but removes whatever benefit using MSMQ delivers. You use queuing software for guaranteed ordered delivery. As soon as you put a web service in front of the queue you lose these benefits. If guaranteed ordered delivery is a requirement then the remote application must talk directly to the queue. You might as well use a web service adapter (SOAP, WCF) on Biztalk and eliminate the queuing software.
MSMQ is the answer if all your remote applications are Windows based and can talk to MSMQ. Otherwise WMQ is the answer. There are gateway products that will connect WMQ and MSMQ but then you have the cost of WMQ plus the complexity of developing and maintaining two queuing infrastructures.
What is your driver for using queuing software?
-
Thanks for your reply.
My requirement is the remote application sends some 15000 to 20000 messaages to be processed and as you said if this remote application happens to be done using microsoft technology then the remote application can directly add messages to MSMQ and then using the MSMQ adapter of BizTalk the messages can be picked up for further processing.
As you said MSMQ is used for In-Order delivery but at the same time it does not require the other application to be online that is if the messages coming are too much as mentioned above then they can very well sit in the qeue and wait for it to be picked by the MSMQ adapter, so I guess my driver along with the ordered delivery messages it is also the number of messages coming and processing the same.
So, I was thinking of having MSMQ, so that the remote app can send the message to the MSMQ and the Biztalk would pickup the messages using the MSMQ adapter for further processing.
Also, about using Web Services to get rid of the queing software I guess when there are loads of messages comng in then store and forward capibility of the queuing software would be very crucial instead of having a Web Service… what is your thoughts ?
-
-
If you use an MSMQ independent client on the same machine as your application, then you will get the guaranteed delivery i.e. your application uses fire and forget and this will work even if Biztalk is down.
However, if your application is Linux based and must call a web service on a Windows machine before it hits the queue then you will lose the guaranteed delivery. What if your web service machine is down? You will need to implement some error recovery/retry capability in your application to handle this. In this case it would make more sense to just host the web service in BizTalk.Likewise with message order. If you use a local queue then the message will be delivered in the order they were written to the queue. With a Web Service in front of the queue you cannot guarantee the messages are written to the queue in the same order they were sent, unless you implement your own ordering mechanism across the web service interface.
If your remote application is running on a Windows server with access to MSMQ and you need ordered and/or guaranteed delivery then definitely use MSMQ. Otherwise consider WMQ.
-
Hi Greg, thanks for the reply …
I have mentioned my doubts/queries below inline:
If you use an MSMQ independent client on the same machine as your application, then you will get the guaranteed delivery i.e. your application uses fire and forget and this will work even if Biztalk is down.
Is this what you meant that my remote App which is a .Net based application is on Server A, should the MSMQ be insalled on the same computer that is Server A or it can be installed independently on a diff Server that is Server B and if we deloy the MSMQ on the different Server how would the remote App on Server A would send messages to the MSMQ which is on Server B and also If have my bizTalk application is on Server C which would consume the messages from MSMQ which is installed on Server B, how will this enviornment work, please do share your thoughts …
What if your web service machine is down? You will need to implement some error recovery/retry capability in your application to handle this. In this case it would make more sense to just host the web service in BizTalk.
So, over here probablu you meant is you create an Orchestration to subscribe the message and expose this orchestration as a web service which can probably easily have retry capability and this webservice can be called by passing the XML message itself as a parameter ??? or how will it work
Please do let me know the above 2 queries
Thanks.
-
-
MSMQ needs to be installed on Server A. You application would talk to MSMQ locally on the same server. This MSMQ software on server A is responsible for accepting the message, storing locally and attempting to send to the remote queue. The MSMQ software on server A will handle the remote queue being down and will retry the send.
If Server A is not a Windows server, then you cannot have MSMQ running locally. To use MSMQ in this case you need another protocol to connect to MSMQ running on a Windows Server e.g. a Web Service. You will need to write a web service that accepts a message and writes it to a queue. Your application will now need to handle this web service being down and implement logic to retry. In this architecture MSMQ provides no benefit over having a Web Service on the Biztalk Server connected to an orchestration. If you require ordered or guaranteed delivery then you will need to implement this yourself within your own code.
-
Hi Greg,
Thanks Again …
Well to summarize, I would have the environment as below:
- Windows Server A: Will have a Application, which would send messages to the local MSMQ queue, which means the Application and the MSMQ is installed on the same Windows Server A.
- Windows Server B: Will have BizTalk Server 2006, which would receive/send messages to the remote MSMQ queue which is on Server A, which I guess is the right approach but this means that Server B would also have MSMQ installed on it along with the BizTalk Server 2006 .
Please confirm if my undertstanding above is right …
-
-
-
-
-
-
-
-
-
-
-
You need to put the queue on server B (the Biztalk Server) For guaranteed delivery you need to use a transactional queue. Biztalk only supports local transactional queues.
Server A will have the MSMQ software and operate as an independent client i.e. it will store and forward messages if the Biztalk server is down.
You cannot use load balancing with MSMQ ( the queue can only exist on one server at a time). For fail-over you will need to cluster the Biztalk servers.
http://msdn.microsoft.com/en-us/library/dd897482(BTS.10).aspxDisaster recovery is added complexity – the assumption is the entire data centre is lost and you must move every server to a new location. There are many variables that need to be taken into consideration here – network topology, web server switching, DNS, logging shipping databases or geo-clustering, recovery procedures, etc,etc. Do you already have a disaster recovery strategy/plan?
-
Greg thanks again …
pobably I am repeating myself but just wanted to be sure …
So, ideally the MSMQ receive/send adpater on Server B is able to read as well as write messages to the remote Queue on Server A, I am talking about BTS 2006 and there is no need for any intermediate Web Service to read/write the messages and the BTS 2006 MSMQ adapter can do the same…
Also, for writing the messages to MSMQ server the Application on Server A would write the messages to MSMQ using MSMQ API’s available ….
Please do confirm the above 2 points . Thanks.
-
if we put the Qeue on Server B, the MSMQ adpater on Server B will have access the messages from the Local queue, which means MSMQ has to be installed on the Server B, which has BTS 2006 installed on it ?
And if MSMQ is intalled on Server B, then the remote Application on Server A will have to use web service to write messages to the queue which is on Server B …. please do clarify if I am missing out on anything …
-
I was reading the MSMQ best practices where it says “MSMQ is designed optimally for sending remotely and receiving locally“, that means If I have environment as below:
Windows Server A: Has the Remote Application running on it .
Windows Server B: Has MSMQ and BizTalk Server 2006 installed on it, where in the BizTalk’s MSMQ adapter can do transactional read using the local Queue.But then I would probably need to have a Web Service which would write messages to the MSMQ queue remotely which is on Windows Server B, but then I am not sure will it cater to the reliable messaging mechanism as I am adding one more layer on top of MSMQ…. I am bit confused here now whether I should use transactional reads or not
Greg Please share your thoughts on the same …
-
-
-
-
-
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.