Is there a way, using MQ 7.5, to get MQ WCF to place "raw" messages into an MQ queue? It seems to be limited to SOAP-JMS formats.
By raw, I mean non-SOAP, non-JMS, non-XML, just a simple message.
MQ 8 provides this feature with WmqStringMessage as per here, but I'm wondering about a good way to get just a standard MQSTR-type message into an MQ queue.
Short of IBM back-porting changes from later versions of MQ to MQ7, there is no easy way to achieve this.
In the end, we ditched the use of WCF since most of the features we used are also implemented in MQ itself, such as durable transactions and guaranteed delivery.
WCF is good if you want to be able to chop and change the underlying delivery mechanisms but, if all you're using is MQ, it's easier to just code directly to that API.
Related
I need confirmed delivery to a remote queue and according to MSDN Exists() method does not support remote queue check.
According to me message delivery can fail in the following two scenarios
Remote machine is not reachable.
Queue on the machine does not exist or was deleted.
I am using transactional queue. Setting AdministrationQueue and UseDeadLetterQueue ensures messages are not lost.
But I want a synchronous way to send message to remote machine queue. Does MSMQ supports this and how is it possible even if it's not supported by design?
Does MSMQ supports this and how is it possible even if it's not
supported by design?
The MSMQ service does not have any built-in way to support duplex messaging.
In order to achieve this, you will need to code on both ends of the queued channel. However, this is generally complex at best.
The following link describes how to achieve this by using System.Messaging:
https://www.codeproject.com/Articles/999238/Efficient-Message-Correlation-in-MSMQ
It is based on using the CorrelationId header with the ReceiveByCorrelationId() operation, which is notoriously bad for performance reasons.
Another way of doing this is by using WCF, however, this still relies on a manual response using System.Messaging:
https://msdn.microsoft.com/en-us/library/ms751435(v=vs.110).aspx
A further approach uses WCF and a helper library called Duplex MSMQ:
https://www.codeproject.com/Articles/41907/WCF-Duplex-MSMQ
However, none of these methods is very nice and all introduce unwanted complexity.
I need confirmed delivery to a remote queue
I guess what we need to understand is what you mean by "confirmed". If you use a transactional queue, then this provides a guaranteed delivery semantic on a message transmission from one application to another.
If, on the other hand, you require a real-time response, then using message queuing is probably not the right technology for your purposes.
If you're forced to use MSMQ, then you could do worse than using a commercial product. I have used NServiceBus extensively, which uses MSMQ but adds powerful message exchange patterns such as request-reply. It is a pay-for product, but if you only require a single threaded operation, then you could use the free version.
What I needed was real-time response for success and fail messages..
If I understand this correctly, then your requirement is acknowledgement, which MSMQ does support. See:
https://msdn.microsoft.com/en-us/library/ms978430.aspx#bdadotnetasync2_topic4
https://msdn.microsoft.com/en-us/library/ms707129(v=vs.85).aspx
I need help with implementing IBM WebSphere MQ for a system where the queue is supposed to send the XML messages to a SQL database. May please help me with resources and video tutorials for the matter in hand. The system will be in C#
Thanks!
Message Service Client for .NET a.k.a XMS .NET is now part of WebSphere MQ v701. You can find latest documentation on XMS .NET here. XMS .NET gets installed along with MQ Client from v701 on-wards.
How are you wanting to access MQ? Are you using JMS or MQI?
There are a couple different ways to access MQ from .NET. The first way is through the native MQ interface known as MQI. The second way is through a JMS implementation created by IBM called XMS.
The queue is not going to write anything into a database for you. You are are going to need to create a listener application that does that.
EDIT:
If you want to use JMS then you should take a look at the doc link that Shashi posted below. here
You will want to look at the docs under "Message Service Client .NET, Version 2.0.0" --> "Developing XMS Applications" --> "Writing XMS .NET applications"
Also take a look at the sample applications that are packaged with the client.
Essentially what you are going to end up doing is creating a connection to the queue manager (either remote or local depending on your use case), creating a destination object that will represent the queue you are trying to work with on the queue manager, and then creating a listener to receive messages from the queue (either sync or async depending on your use case).
In college we studied IBM's MQ Series which was middleware that you could send messages to that would be persisted in a Queue. MQ Series had what was called Guaranteed Message delivery, meaning that if you got the message sent to the Queue, the Queue would be persisted even if the server containing the queue message was turned off and turned back on again.
Does Microsoft have a similar technology that works with C# and Sharepoint?
Yes, it is called MSMQ (Microsoft Message Queuing).
Here is the official Microsoft FAQ for MSMQ.
If you'd like to go open-source, have a look at ActiveMQ from Apache Foundation.
ActiveMQ is cross platform. Libs are available for C# and other languages: http://activemq.apache.org/cross-language-clients.html
Since you're talking about Sharepoint, it implies your back end is SQL Server. SQL Server has it's own reliable messaging technology, namely Service Broker. The main advantage over MSMQ is that is completely integrated into the database engine, which means one single product to deploy and maintain, consistent backup/restore, integration into the SQL Server based high-availability/disaster recoverability (mirroring, SQL clustering), language/API integration with the database (you can run SELECT over your queues!) etc. Because it eliminates the need to engage in two-phase-commit DTC between MSMQ and your database to precess each message, it offers Significantly higher throughput. Also the scalability and capabilities are significantly higher (MSMQ has a 4GB queue limit, SSB has 2GB message limit and queue limit is the (total) disks capacity, basically database limits). The main drawback is lack of a client side programming API like WCF MSMQ channel. With SSB you have to program T-SQL using verbs like SEND and RECEIVE.
I'm trying to send a message to a java server over a Websphere MQ which uses JMS as the transport protocol. I can happily drop messages on the MQ using the IBM supplied libraries, but the server rejects them. I'm assuming (hopefully correctly) that this is because I'm missing various JMS specific headers/properties on the MQ message.
I have ensured the payloads for the messages are the same by inspecting the queue (they are both map messages if that helps), but don't want to fully implement the JMS Websphere MQ protocol just to get this to work.
I'm wondering if anyone has managed to get this to work, and if so what's the minimum amount of information you need to specify in the JMS header? Are there any alternatives to doing this directly on the MQ (I've seen some about using java interop, but this is something I think would be overkill).
Any help would be greatly appreciated!
Can you paste the Java code you are using to read the message. Is that code assuming that the message is a "MapMessage". Normally something put into a Queue from a non-java client will appear as either a TextMessage or a BytesMessage.
The WebsphereMQ JMS api is normally fine with reading those messages without the JMS headers as long as you read as a TextMessage / BytesMessage as put.
In my server code, my content is normally put to the queue as bytes, and so appears as a BytesMessage, but just in case i get a message that was manually put on the queue, i catch the classcastexception, and test to see if it is in fact a TextMessage.
Are you trying to use MQI to send JMS messages? Take a look at the XMS libraries from IBM. They will provide everything that you need. The libraries provide a .NET implementation of JMS that works with WebsphereMQ. I have used these libs many times over the past year, talking between java and .net systems, and have been very happy with the functionality.
XMS .NET Library Download
WebSphere MQ doesn't have very clear error messages. The things I suggest to check when something went wrong are:
Exception details and their recursive causes.
MQ error logs.
Event logs sourced by MQ.
.FDC files.
I think I had the same problem and I couldn't get XMS to work. In case it's still a problem to you, this might help
Regards Kristoffer
I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?
Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.
If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.
Remoting
If all development is done in .NET 2005, Remoting is the best way to go.
MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.
The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.