We are currently implementing a windows service which needs to publish information that a windows or web application can subscribe to. The information published should consist primarily of strings and will be used to log tasks that the service is performing, so there will be a constant stream of information being sent to subscribed applications.
I have been researching technologies such as MSMQ, WCF, and ESBs such as Nservicebus, but as I am very new to working with both windows services and application subscriptions, it has been difficult so far to get an idea of the strengths of each and which (if any) would be ideal for this type of project. Can anyone who is more familiar with these options offer some of the pros/cons that these technologies provide?
To better summarize my earlier paragraph, the project is expected to operate under the following conditions:
Messages are continuously published from the service to any subscribed applications
Communication is expected to be one-way (service to application), so downtime from any application should not affect the work of the service
The service must publish to both windows applications and web applications
New applications may need to subscribe in the future without disrupting the work of the service (seems like a given, but as I said, I am unfamiliar with the options)
The preferred language for the program is C#.
Thank you very much for your time, and any advice regarding these or more suitable technologies would be greatly appreciated.
There's a lot of options around MSMQ and WCF. There are a couple of different methods and frameworks that could help, depending on many factors.
If you would like to do it you self with a little guidance, i suggest that you take a look at Tom Hollanders great posts:
http://blogs.msdn.com/b/tomholl/archive/2008/05/17/building-a-pub-sub-message-bus-with-wcf-and-msmq.aspx
http://blogs.msdn.com/b/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx
There are other more "complete" options if you're into using an existing servicebus such as BizTalk, nServiceBus or MassTransit.
Another option is Multicasting wich is available since MSMQ 3.0, which is such a feature that will support scenarios where you have one publisher (your windows service) to multiple recievers (your windowsapp and webapp). Both sender and recievers can use the MsMqIntegration binding to interact with the queues.
I suggest that you take a look at: http://blogs.msdn.com/b/solutions/archive/2005/09/20/471615.aspx
Related
I am trying to build a service mechanism which should be add-on based and communicating through a publish subscribe system. It must be based on WCF services.
What I have right now is a concept which I can't get to work so I decided to ask you because maybe I am going at this the wrong way (I only just started using WCF).
What I want to achieve is making a single core service with session persistency which can be extended by linking an unknown number of add-on services. I want to set up the publish subscribe system at runtime, not at buildtime, so the core-service should be able to detect what add-on services are available (using the web.config?) and then bind them to the message bus.
From the front end (ASP classic) it must be possible to access any .svc file but, maintaining session, each .svc file must be connected to the message bus.
All is hosted in a single IIS active directory.
Can you give me some hints as to where to look?
I am especially interesed in:
WCF dynamic discovery
WCF to WCF communication on the same host (in the same active directory even)
Thanks in advance, hope you can help!
Update
Thanks for your answers, I'll read up at the links you send me. I'll post my final concept solution here in due time for future reference.
My 2 cents about Publish subscribe mechanism using WCF - WCF is not inherently built for pub/sub mechanism. It is built for Request/Response model of communication. Have a look at the NService Bus for pub/sub here
Talking about Add on services on top of core service, I am not able to get What you want exactly ? Is it the Routing service which you want ? WCF 4 now provides routing service For more information look here The link also talks in detail about the discovery mechanism in WCF 4.
Also have a look the Agatha framework which also have single WCF service and no. of request handlers where in the framework will decide which request handler to call based on each request.
Search for Agatha - Davy brion for more information
I was having a similar problem since I have one common WCF service but the implementation depends on the user's role so it was kind of difficult to do that at runtime.
I found this tutorial on the matter which runs great for my propouses: http://blog.micic.ch/net/dynamic-iis-hosted-wcf-service
I have tested in my env and is very powerful technique. Hope that helps you as well. Cheers.
I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.
Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.
As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.
Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.
The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).
Right now, our options as I see them are:
Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management
My basic question is this:
What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?
(I am working on the assumption that by "stateful" you mean session-based).
I guess one big question is: Do you want to use SOAP in your messaging stack?
You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!
Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.
You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.
What sort of state do you need to store in your sessions? Maybe there are alternative approaches?
1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless.
2) consider distributed caching, perhaps Windows Server AppFabric Cache.
I'm planning a project which will consist of a Windows Server Application programmed in .Net/C# and Clients programmed in Silverlight/C#, Windows Forms/C# and a MacClient programmed in Cocoa. My Question is, which Webservice technology will be the best for the communication between the Clients and the Server and is the easiest to program in all of those technologies? I've no experience in Webservices and since Time is running short I hope to get some opinions of developers who worked in such a kind of heterogeneous project.
On the back end, you will definitely want to run Windows Communication Foundation, using the WSHttpBinding or the BasicHttpBinding depending on your needs.
This will make it easier to have Windows Forms and Silverlight clients.
Also, because using WCF with those bindings conforms to established standards, you should be able to access the services from almost any other environment - there should be tools that you can just point it to your metadata endpoint and it will generate proxies for you.
Another option is to use WCF to create a REST service (with JSON encoding most likely). WCF does help you a little bit here, but if this is the design you want to use, then you will want to look at ASP.NET MVC on the back end as well, as it makes creating these kind of services very, very easy.
However, when using REST services, there isn't a service description through something like WSDL, so you will have to generate the proxies to call your services by hand (at least, in environments outside of .NET).
The current technology used to develop web services on .NET is WCF. For interoperability with non .NET clients you should consider using basicHttpBinding endpoint. You could even expose multiple endpoints with different bindings, for example expose interoperable endpoint for non .NET clients and some fast binding for .NET clients. Here's a nice article on MSDN covering the performance of the different bindings. Given those keywords you might checkout the tutorials.
I'm trying to create a feedback system which all messages get posted to then published back to the correct subsystem. We are using queues quiet heavily and i want to make the subscriber code as clean as possible. I want to switch based off the message id i get into the feedback system and publish to its specific subscriber. i don't want to make a service for each subscriber to listen for messages.. i was thinking i could set up a queue for each subscriber and trigger to invoke a com+ component.. but i'm looking for a more modern way..
I was looking into NServiceBus but it seems i'd need to make a service/executable/webservice for each listening system ( its a little less work to make a C# dll and invoke a method) and i'm not sure if NServiceBus can handle dynamic endpoints based off a preloaded config ( loaded from a db ). WCF is also a choice.. it can handle dynamic endpoints for sure..
what do you think is the best solution for the lease amount of code/ scalable for new systems to subscribe?
Thanks
In case you are ok with online solutions you could take a look at the latest .NET Services SDK for Windows Azure which has queue service bus http://www.microsoft.com/azure/netservices.mspx It relies on WCF messages and supports routing etc. Some blog posts about this here http://vasters.com/clemensv/default.aspx
Another framework you could try is MassTransit http://code.google.com/p/masstransit/
It seems you're looking for a service host, rather than a message broker. If so, Microsoft's recommended way is to host your WCF services in IIS. They can still use MSMQ as transport, but the services themselves will be managed by IIS. IIS has evolved significantly since its early days as HTTP server, now it's closer to an application server, with its choice of transports (TCP, MSMQ, HTTP), pooling, activation, lifetime policies etc.
Although I find WCF+MSMQ+IIS somewhat overcomplicated this is the price you pay to play on the Microsoft field.
For nice and simple message broker, you can use Active MQ instead of MSMQ, it will give you message brokering as well as pub/sub. It's quite easy to work with in .NET, check this link out: http://activemq.apache.org/nms/
I am interested in using a free library that has features similar to MSMQ to send/receive messages among 3 app domains in a win form application.
I only need the private queue functionality (No public queues or AD support)
Please provide links and some advantages/disadvantages . I am happy to open sub questions if you think you need more points for finer details.
Note: Unfortunately I have some users that do not have Windows XP professional edition (MSMQ is not available)
I saw Apache ActiveMQ and rabbit MQ but it seems a bit overkill for what I need to do.
http://activemq.apache.org/
http://www.rabbitmq.com/
It is possible to implement this feature using a singleton Queue protected by a named mutex, but I would not like to spend the time if somebody has already done it.
There is Rhino Queues. The author is considered to be a pretty good developer.
How about NServiceBus using the shared memory transport? The creator, Udi Dahan, is a well respected individual in the message based architecture space.
If it's all in the same application then sharing a synchronized queue is what you want, have a look at the Queue.Synchronized method in MSDN, that provides you with a thread-safe queue.
At some point, there is going to have to be some client specific code to accept messages. If the users need to accept messages on their machines, it sounds like a smart client situation. In the Windows world, there is a smart client which does messaging, and allows users to work with data in a disconnected way.
I can't imagine any one library which will allow messaging on different operating systems. Even if a singleton is used, there has to be some cross-platform way to send/receive the messages. It seems like the client end would always have to be OS specific.
It might be possible to try Mono on the non-windows side. There is a tool you can use to see if a third party library has dependencies which will not run in Mono. It was released with the Mono tools for Visual Studio. It is called the Mono Migration Analyzer (MoMA).
See also this system:
http://www.codeproject.com/Articles/193611/DotNetMQ-A-Complete-Message-Queue-System-for-NET
DotNetMQ is an open source Message Broker that has several features:
Persistent or non-persistent messaging.
Guaranteed delivery of persistent messages even in a system crash.
Automatic and manual routing of messages in a custom machine graph.
Supports multiple databases (MS SQL Server, MySQL, SQLite, and memory-based storage for now).
Supports don’t store, direct send style messaging.
Supports Request/Reply style messaging.
Easy to use client library to communicate with the DotNetMQ Message Broker.
Built-in framework to easily construct RMI services upon message queues.
Supports delivering messages to ASP.NET Web Services.
GUI-based management and monitoring tool.
Easy to install, manage, and use.
You might want to look at Retlang http://code.google.com/p/retlang/