I have a receive only endpoint as a azure worker role listening to topics on ASB transport. This receive only endpoint is automatically creating receiveonlyendpoint.queue, receiveonlyendpoint.topic etc which i dont want. I just need a subscription to publisher.events and auto subscription works fine. How to control this in NServicebus 6 and NSB Asb transport 7
With ASB transport version 7 you need to choose the topology. Documentation on topologies goes into details how those operate.
Note that endpoint is either a normal endpoint (sends and receives) and send only (doesn't receive). There's no receive only type. Therefore your endpoint is a full endpoint and will create necessary queues.
Related
As I have previously mentioned, I am using ServiceStack Messaging API (IMessageQueueClient.Publish) as well as the more low-level IRedisClient.PublishMessage.
I use the Messaging API when I need a specific message/request to be processed by only one instance of a module/service, so even though I might have several modules running that all listens for MyRequest, only one service receives the message and processes it.
I use the IRedisClient.PublishMessage when I do a broadcast, a pub/sub situation, sending a request that everyone should receive that listens on that specific Redis channel.
However, I am in a situation where it would be useful to use the Messaging API, but do a broadcast, so that all instances that are listening to a specific message type, gets the message, not just the one.
(The reason for this is to streamline our usage of Redis and how we subscribe to events/request, but I will not get into details about this now. A little more background on this is here.)
Is there a "broadcast way" for the Messaging API?
No, the purpose of ServiceStack Messaging is simply to invoke ServiceStack Services via MQ. Any other MQ features is outside the purpose & scope of ServiceStack MQ, you'd need to instead develop against the MQ Provider APIs directly to access their broadcast features.
Server Events is a ServiceStack feature that supports broadcasting messages to subscribers of user-defined channels, but its a completely different implementation that serves a different use-case for sending "server push" real-time events over HTTP or gRPC, e.g. it doesn't use MQ brokers and pub/sub messages aren't persistent (i.e. only subscribers at time messages are sent will receive them).
is it possible to implement following concept with WSO2 ESB:
http listener for webservices with a method to be called (SOAP)
java routine to process message
same routine to put message to MQ queue Q1
same routine to get answer message from MQ queue Q2
return with processed answered message to webservice caller
or it's better to go with J2EE server and handle messaging part fully through java code?
Regards, Nikola
Well now usecase is much more clear so that we can go ahead and implement it. There are two ways of doing this.
First Approach
Write a Proxy(HTTP to JMS) service which accepts HTTP requests and
place it in JMS Q1 using the jms sender.
Then write another proxy (JMS to JMS), which picks the messages from
JMS Q1, process it and place it in JMS Q2.
Finally create another proxy (JMS to HTTP) to get the message from
JMS Q2 and send it back to the client using the respond mediator.
Second Approach
Create a proxy service (HTTP to JMS) and use store mediator to store the message into JMS Q1.
Create a Forwarding Message Processor to listen to Q1 and pick the message, process it, place it in Q2.
Then create another forwarding message processor to listen to Q2, and send it back to the client using a reply sequence in the message processor.
Choose which ever the way you like and let me know how it goes.
You can use ESB to implement this. But your usecase is not that clear to me. Appreciate if you can explain your usecase in functional perspective. Anyway you have HTTP(S)/JMS listeners and senders with ESB . You can't listen to a SOAP web service using ESB. What you can do is listen to HTTP traffic. Create a proxy that listens to HTTP traffic and send the message to JMS queue Q1 ussing JMS end point. Then write a JMS listener proxy to listen to the answers in Q2. Once it is received you can call the endpoint web service using send or call mediator. This is how I understood your usecase. I have no idea on transformation of data in Q1 and place it in to Q2 due to wired requirements specified above. It looks simple HTTP to JMS switching usecase to me.
I have an application that places messages on MSMQ, than I have a WCF service that I want to automatically read these messages from MSMQ.
I do not want to trigger my WCF service but I want it to be notified whenever a message is pushed on MSMQ. I have found some stuff related to WAS and netMSMQBinding, but the details seems a little unclear about automatic notifications from MSMQ to WCF.
Any help/direction in this regard? Thanks.
What is it that you're trying to achieve?
There is really no such thing as "be notified when a message is pushed on MSMQ". MSMQ uses a pull model to retrieve messages from a queue, so there always needs to exist some kind of "listener" that reads messages from the queue and processes them.
In this case, this "listener" is provided by the WCF NetMsmq or MsmqIntegration bindings automatically, so the programming model for a WCF service that is exposed over MSMQ is just like that of a regular one-way service.
As you state, you can either host that WCF service using your own custom host (such as a Windows service), or, in many cases, the preferred method will be to host that service in IIS 7.X/8.X through WAS.
The following sample shows how to host an MSMQ service in WAS: http://msdn.microsoft.com/en-us/library/ms752246(v=vs.110).aspx
Notice that you do need some specific configuration in IIS to be able to host non-HTTP services, which includes enabling the "Non-HTTP Service Activation" feature. The following articles will be useful to get this done:
http://blogs.msdn.com/b/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/07/13/msmq-wcf-and-iis-getting-them-to-play-nice-part-2.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/07/14/msmq-wcf-and-iis-getting-them-to-play-nice-part-3.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/05/17/building-a-pub-sub-message-bus-with-wcf-and-msmq.aspx
I have a wcf service and handle a lot of client (server document generation). This service should receive a lot of request and should be handle in queue. It also have a callback. (callback will return successfully generated document). I am still using PIA and will implement OpenXML in the future.
Is it wcf msmq is the way to implement this?
Is there any samples might be related? Previously its running in local machine but now want to change it as a so called "Server generated"
WCF MSMQ doesn't support callback directly - it supports only one-way operations. But for example this article discuss how to add this support. With default configuration you can send message back to original sender but it is not a callback. To support responses every client will have to expose queue and pass address of its queue as part of the request to be able to receive the message from the service. More about responses in MSMQ is in MSDN magazine.
I am looking at various options for a WCF based publish subscribe framework. Say I have one WCF web service that will be the publisher and 1000 clients registered as subscriber. For some published messages all clients will be interested but at the same time I wish the ability to notify a single client with a specific message. On receiving notification the client will call other web service methods on the web service.
Is NServiceBus suitable for this kind of scenario ?
If I use MSMQ for transport does it mean that every PC where the client is installed requires a queue to be created ?
Some of the challenges include how you want the publisher to behave when a given subscribing client is down - do you want that message to be available when the subscriber comes back up? If so, then some kind of durable messaging is needed between them - like MSMQ.
Your question about notifying a single client, is that as a result of a request sent by that client? If so, then standard NServiceBus calls in the form of Bus.Reply will do it for you. When using WCF, if the response is to be asynchronous you'll need to use callback contracts.
NServiceBus can do all the things you described, and has the ability to automatically install MSMQ and create queues so that greatly simplifies client-side deployments.
You also have the ability with NServiceBus to expose messages over WCF so you can support non-NServiceBus clients if you need to as well. It also has its own http gateway and XSD schemas which can allow clients on non-Windows platforms to interoperate even without using WCF.
Hope that answers your questions.