I am trying to host WCF services on an on-premise Service Bus but I understand that relaying is not yet supported. Is there a scheduled release date for this functionality?
Thanks for your help.
Relay feature will not be supported in Service Bus Server in near future.
The customer segment for this feature is very less in Server space - closer to Zero as Relaying is primarily to get data/services out of Enterprise (firewall) with out having to do heavyweight solutions like VPN.
HTH!
Sree
According to Clemens Vasters, Architect, Azure Messaging: "If it's up to me then relay is also going to go into that new [Azure Stack] server". But it probably won't happen soon.
Reference: A May 12 Integrate 2016 talk titled Service Bus – Roadmap, What’s next?. This statement was made at about 46:19. You can listen to announcements related to Service Bus for Windows Server at about 40:35 and you can read some paraphrased transcripts here.
Related
sorry if now I can't provide all the details, but I'm trying to use NServiceBus on Azure Service Bus using the Basic configuration. NServiceBus fails on start because it tries to create a Topic and a Queue, and Basic mode of Azure Service Bus doesn't suport Topics. Any help or workaround? Thanks!
I think you're talking about Basic Tier (pay).
Not with the current version of the ASB transport. Current version of transport only has one topology QueueAndTopicByEndpointTopology which is creating topics by default. You have two options: switch to Paid Tier or implement an alternative topology and use that (not a trivial task). Next version of transport will support more topologies and allow better mechanism to plug custom implementations.
But have you considered the following: without Topics you cannot have pub/sub. This would be a severe limitation when using bus architecture.
As Sean outlined, basic tier is currently not possible out of the box. But I'm curious to know why prefer Basic tier over Storage Queues?
A decade and more in the past I studied and used IBM's MQSeries and Websphere MQ software. It seemed to be a great solution for connecting two applications in different companies at different locations: the app at each company could drop off a message with MQSeries on the local machine, MQSeries would transport it to the machine in the other company, and the app on that side would pick up the message locally.
Fast forward to today: I no longer work for IBM, but I'm trying to solve a similar problem. My app needs to send a few messages a day, each a few MB or less, to an app at a remote company, and receive a similar number of somewhat smaller replies.
Is message queuing middleware still a good solution to this architectural need? I've been trying to prototype this with RabbitMQ, but the above seems to be an abnormal thing to do with RabbitMQ. Am I barking down the wrong rabbit hole?
sure it can be - if the remote company intends to provide the same service for others and not just you.
perhaps WMQ low latency is what you need, since there is no server required.
- WebSphere MQ Low Latency Messaging varies from conventional WebSphere products such as WebSphere MQ, WebSphere Message Broker, and WebSphere Application Server in that there is no installed and configured product infrastructure such as queue managers, message brokers, or application servers. Thus, there are no specific product components to be monitored, measured, and managed.
http://www-03.ibm.com/software/products/en/wmq-llm
http://pic.dhe.ibm.com/infocenter/wllm/v2r5/index.jsp?topic=%2Fcom.ibm.wllm.doc%2Fintroductiontowebspheremqlowlatencymessaging.html
Of course, a simple RESTful web interface might be able to provide the same functionality.
I do not recommend writing TCP socket applications - why do all that mid-weight lifting when there are so many products out there that will do the heavy and mid-weight lifting for you? You want to only do lightweight lifting - Send the request, get the response - 6 2 and even, over and out.
You need to draw up your list of requirements reagrding:
- reliability - how critical is it if a request or response gets lost?
- recoverability - can in-flight messages be recovered and resent if the application(s) crash?
- round trip time - one side of latency
- 1:1 service? many-to-one?
I hope this helps.
Dave
WebSphere MQ can still solve your problem... I think the scenario is point to point communication with Request-Response scenario. You can use some relatively new stuff like JMS which integrate well with your application.
But if you are very sure that its only 2 applications that will communicate with each other and there is no network issue that will crop up, you can go in for simple socket communication.
The other way to solve the problem is to share a common database between the 2 applications.
I am sure that this is answered dozens of times, but I am at a loss as to what keywords to search for and thus I hope that someone can at least tell me where I should be looking given an explanation of my scenario.
I need two services (one can be just a client if that is easier) to talk to each other, but the client will be on a private network whereas the server will be on the internet. I want to be able to push jobs to the client, but the server obviously does not have an IP to hit the client. I'd rather not poll from the client every X seconds. I have read various topics all circling this issue and so I am going to throw out a few terms that I think are relevant, but I am not sure which to use or exactly how.
Comet, SignalR, WebSockets, XSockets, Publisher/Subscriber Pattern...
I have looked at each of these and I am not sure which is the right way to go. The client can certainly "subscribe" to the server on startup, so that should not be an issue. But the client should be either a console app, windows service, or WCF service. It seems Comet and SignalR are more for ASP.NET apps, where the client is JS in a browser. I just need "server(client)" to server connection where the client is behind firewalls.
Which of these terms (or none of them) is a good way to handle server -> client push notifications?
Pub/Sub architecture pattern with something like Azure Service Bus should help you create the solution you desire. This does require that service and the client are aware of the bus. For the plumbing of the client and the services use the WCF which has built in bindings to facilitate the use of this pattern.
Azure: How to Use Service Bus Topics/Subscriptions.
Azure SB has a counter part that works on-premises as well. There are other popular message bus tech (NServiceBus, MasTransit, etc.)
You can have a look at node.js together with socket.io.
This will give everything you need.
socket.io uses web sockets, and if the browser does not support web sockets, it gracefully falls back to other communication mechanism like xhr, flash, polling, aso.
I have explored the web on MULE and got to understand that for Apps to communicate among themselves - even if they are deployed in the same Mule instance - they will have to use either TCP, HTTP or JMS transports.
VM isn't supported.
However I find this a bit contradictory to ESB principles. We should ideally be able to define EndPoints in and ESB and connect to that using any Transport? I may be wrong.
Also since all the apps are sharing the same JVM one would expect to be able to communicate via the in-memory VM queue rather than relying on a transactionless HTTP protocol, or TCP where number of connections one can make is dependent on server resources. Even for JMS we need to define and manage another queue and for heavy usage that may have impact on performances. Though I agree if we have distributed and clustered systems may be HTTP or JMS will be only options.
Is there any plan to incorporate VM as a inter-app communication protocol or is there any other way one Flow can communicate with another Flow Endpoint but in different app?
EDIT : - Answer from Mulesoft
http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Yes, we are thinking about inter-app communication for a future release.
Still is not clear when we are going to do it but we have a couple of ideas on how we want this feature to behave. We may create a server level configuration in which you can define resources to use in all your apps. There you would be able to define a VM connector and use it to send messages between apps in the same server.
As I said, this is just an idea.
Regarding the usage of VM as inter-app communication, only MuleSoft can answer if VM will have a future feature or not.
I don't think it's contradictory to the ESB principle. The "container" feature is pretty well defined in David A Chappell's "Enterprise Service Bus book" chapter 6. The container should try it's best to keep the applications isolated.
This will provide some benefits like "independently deployable integration services" (same chapter), easier clusterization, and other goodies.
You should approach same VM inter-app communications as if they where between apps placed in different servers.
Seems that Mule added in 3.5 version, a feature to enable communication between apps deployed in the same server. But sharing a VM connector is only available in the Enterprise edition.
Info:
http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains
Example:
http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/
We are implementing a service/message-bus feature in our SignalR application and have been looking at Redis, with automatic fail-over using Redis Sentiel. We would like to maintain our own servers and have read SignalR powered by Service Bus. Since this is a Winddows Azure implementation, how can I accomplish this in our internal network with VM's with automatic fail-over similar to the Redis solution discussed above?
You may want to look at Service Bus for Windows Server:
http://msdn.microsoft.com/en-us/library/windowsazure/jj193022(v=azure.10).aspx
It has API symmetry between Azure Service Bus and the Windows Server API (particularly for messaging: queues and topics/similar to SignalR). It doesn't include the caching and ACS services. However, if you want the Azure Service Bus - Caching...you can get that in:
AppFabric for Windows Server
http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx