I am working on a C# application that contains multiple windows services that will need to communicate with each other to pass data around. These services may be on the same machine but they could be remote. I looked into using WCF for this purpose but it seems like WCF is too heavy and has a lot of extra configuration that, to me, seems unnecessary (.NET 3.5 is a requirement here, I know that .NET 4 simplified this)
So my question is, what would be the best replacement to WCF, besides the deprecated .NET Remoting that provide this functionality?
I have been using PInvoke to access the Windows RPC runtime for nearly 8 years. It's wicked fast and very reliable as far as a transport goes. When combined with a fast serializer like protobuf-csharp-port the resulting communications are rock solid and very fast.
So to build this from the ground-up this requires three parts:
Google's Protocol Buffers (protobuf-csharp-port) for serialization.
My own CSharpTest.Net.RpcLibrary for the transport.
A bit of glue code to put them together from protobuf-csharp-rpc.
These are all available on NuGet in the following packages: Google.ProtocolBuffers, CSharpTest.Net.RpcLibrary, and Google.ProtocolBuffers.Rpc.
The following is a quick run-down on getting started:
define a set of messages and a service using the Google Protocol Buffer Language.
Once you have that defined you will run ProtoGen.exe to generate the service stubs and messages in C#. Be sure to add the "-service_generator_type=IRPCDISPATCH" to generate the correct service code.
Now that you have the generated source files add them to a project and reference the three assemblies from the packages listed above.
Lastly take a look at the sample client/server code on the protobuf-csharp-rpc project page. Replace the "SearchService" with your service name, and you should be ready to run.
Optionally change the configuration of the RPC client/server. The example shows the use of LRPC which is local-host only; however the DemoRpcLibrary.cs source file show TCP/IP and Named Pipes as well.
You can always email me (roger # my user name) for any further information or examples.
Update
I wrote a quick startup guide: WCF replacement for cross process/machine communication.
You may want to look into ZeroMQ, it's very lightweight and effective and comes with good C# bindings. (Typing this on my mobile so you'll have to google for it yourself for now, sorry).
Look at NFX Glue.
It is way faster than WCF for coupled systems.
Interprocess communication with Glue Blog
Benchmark
Code: https://github.com/aumcode/nfx
Related
is it possible to invoke function which is written in Java using WCF or any class application written in C# .net
Can it be possible by using webOrb..
i can't find enough information about Java to .Net remoting..
If you want to communicate between C# and Java you have a couple of options.
The cleanest: Build a service.
This assumes you have access to the source code of both your C# component and your Java component. In the case that you want to call a method within Java, you can build a service that allows a connection from your C# client, to your Java service, and the service then executes the desired functionality, and returns a value back to the C# client. Some easy ways to do this is by building a RESTful service or using Thrift. I recommend you choose a solution similar to this one.
The most complex: Corba
Corba is a standard defined to communicate amongst different computer languages. Most mature languages have support for it, but it is a bit unusual, and the use of it has declined in favor of building service. This also assumes access to both source codes.
You'd have to independently look for the information regarding how to use Corba on both Java and C#. I would really advice against this.
The dirtiest but quickest: Execute as process and parse output
I really do NOT recommend you to do it this way unless you really have no choice. This would entail executing a Java program from within C#. This is only a good choice when you have no other option, because all you have is an executable. If that were the case, you can use the Process class to execute the external program, sending it parameters, and then reading the output. See the example mentioned here:
How do I start a process from C#?
This has many downsides though, as you'll have to think of every exceptional cause, determine the output for those cases, and then determine how to parse that output. If the program has any level of complexity, before you know it, you'll end up with hard to maintain code.
Conclusion: Build a Service
That's probably your best bet. Build a service that exposes an API that the C# client can call on.
We are using JCOBridge package: it is able to create a bidirectional invocation of Java API from C# (.NET Core/6/Framework).
The templates available on Templates was our good starting point for the needs we had. We reach the goal in few lines of code.
UPDATE 2022: the JNet project on GitHub can be used as a starting point. Another project is KNet, hosted on GitHub and based on JNet, that is a gateway for Apache Kafka Java API.
I have an old MFC app written in Visual Studio 6. This will at some point be rewritten in C# .NET. However, before then I have to write a couple of new Windows services for the existing application. The others were written in ATL. What I would prefer to do is write these new services in C# .NET so that when the rest of the application is rewritten, these don't need to be.
Is it going to be possible to call the interfaces on the libraries hosted in a .NET windows service from the old application? If so, could you please explain how.
Absolutely. You're looking for a feature of .NET called COM-Interop.
http://msdn.microsoft.com/en-us/library/kew41ycz%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/magazine/cc163494.aspx
The second link has an ATL example.
EDIT:
Based on your feedback in the comments, let me expand on this...
Ah - you're right about the sample on that page.
The first link is really where you want to start for all the details. If you follow the links, you'll find this page:
"Exposing .NET Framework Components to COM"
http://msdn.microsoft.com/en-us/library/zsfww439%28v=vs.71%29.aspx
Essentially, it's just a matter of applying a series of attributes to your classes and properties, and then generating the appropriate registry entries on the client machine (which .NET has a tool to do - see: http://msdn.microsoft.com/en-us/library/bctyca52%28v=vs.71%29.aspx)
I've done this several times myself for .NET projects people needed to call from VC++ and/or VB6.
Some other links that might be of interest:
http://www.codeproject.com/KB/COM/nettocom.aspx <-- Perfect example of what you're trying to do.
http://www.codeproject.com/KB/COM/Universal_CCW.aspx
I've done this exact thing with an MFC-based C++ application in Visual Studio 2008 and a .NET-based C# Windows service.
First, if you have not created the C# Windows services yet, I've got a couple of tutorials for creating the basic framework. The first tutorial provides a step-by-step procedure for creating the service and writing events to an application-specific event log. The second tutorial shows how to modify the service to install and uninstall itself from the command line, which I find of great use.
Second, you need to decide how you are going to communicate between your MFC application and your Windows service. Any kind of inter-process communication (IPC) model will work - sockets, pipes, shared memory, WCF, etc. Since you are wanting to migrate to .NET anyway, I would recommend using Windows Communication Foundation (WCF), which is the way I've done it. Specifically, I chose the named pipe aspect of WCF for my communication method based on the chart shown here.
If you go down the WCF route, you'll benefit from the fact that the communication between application and service is .NET-based. Thus, when you move your application to .NET, the communication mechanism won't have to be rewritten. The trick in the meantime is getting your MFC application to use the WCF code. To do this, write the WCF client code in a .NET assembly using C#. Then, use a C++ dll to bridge the gap between your MFC code and the .NET assembly. I've got another tutorial with step-by-step instructions for how to do this.
Hope this helps.
Yesterday I asked about what technology should I use to create dynamic web content here:
PHP, AJAX and Java
The suggested methods were JSP, JQuery, etc. But I thought maybe because I'm a .Net developer and I don't have any experience in web development but I have experience in WPF and C#, maybe I should go with Silverlight but the main problem here would be how can I communicate with the core part of my system which is implemented in Java?
So the main question would be: What is the best [and easiest to learn] method to send a piece of data to the Java part, get the result and use it in silverlight? A tutorial or simple example would be nice.
Thanks a lot in advance.
You should use Java Web Services as stated. Use WCF to invoke the Java WS by adding a Service Reference in Visual Studio by its url, then use the proxy classes generated automatically (located in Reference.cs) to invoke the WS. This is easy but remember SilverLight WS invocations are always asynchronous, so you must cath the OnCompleted event to get the results of the invocation. WS are slow but if the machines are in the same LAN, invocation could take a few milliseconds.
I think pipes are not your solution as SilverLight executes in a Sandbox and have many restrictions on what you can do.
This will depend on many factors, however a relatively easy approach would be to use Java Web Services. On the .NET side, WSDL will be picked up and transformed into proxy class by WSDL.exe from the Windows SDK. If, however, these two systems are on the same server (and intend on staying this way), you may decide to use pipes.
Vaguely remember seeing some discussions on this quite a while back but haven't heard anything since. So basically are you able to subscribe to an IObservable on a remote machine?
You can use IObservable.Remotable to use observables directly from other machines via .NET Remoting.
Another possible solution could be to use named pipes.
There is an excellent NuGet package NamedPipeWrapper, see the source on GitHub. It would be easy to write a thin RX wrapper over this, i.e. subscribe to the RX stream and push the messages out to other .NET listening processes using this library.
As this solution uses named pipes, it would be a true pub/sub solution which would support multiple subscribers in different processes.
Update
It is indeed very easy to write simple RX bridge code over the named pipes library. Use an RX Subject and insert the RX bridge code into the event handlers. Its not more than 4 lines of additional code at both ends. I can post the code if anyone is interested.
Update
For more information on named pipes, see .NET 3.5 Adds Named Pipes Support and Interprocess Communication Using .NET 3.5 Named Pipes IO. The aforementioned NuGet package NamedPipeWrapper is a much nicer version of the built-in support for named pipes that .NET 3.5 introduced.
Found this cool video on Channel 9 which an example of using IObservable.Remotable as Paul pointed out:
http://channel9.msdn.com/posts/J.Van.Gogh/Whats-different-about-the-3-versions-of-Rx-Part-3-NET-35-SP1/
Very interesting stuff, gonna spend a bit of time playing around with it now! :-D
Yes.
RX has built in support for using .NET Remoting to cross process boundaries.
If you install the NuGet package rx-remoting, it will install the assembly System.Reactive.Runtime.Remoting.dll which provides support for cross-process RX messages.
For demo code from Microsoft, see RX Across Processes. I've just tested the code on this page, and it works nicely. In order to get it to compile, you will need to add the following references:
NuGet: Reactive Extensions - Main Library (search for reactive extensions main)
NuGet: Reactive Extensions - .NET Remoting Support (search for reactive extensions remoting)
System.Runtime.Remoting (add as a normal reference, this assembly ships with .NET)
The Channel 9 video mentioned by #theburningmonk is also interesting to watch.
Update
Unfortuantely, this solution has one large limitation: you can only have one client process listening (all subsequent clients cannot connect). Pushqa solves this problem (see my other answer). Essentially, any library which implements RX on top of a pub/sub signalling bus should do the trick.
Yes.
Check out Pushqa.
Its easy to use. I was up and running in about 5 minutes.
It works with C# .NET, WPF, ASP.NET or Javascript. SignalR is built into ASP.NET, but it works for any C# .NET project if you add the right NuGet package.
It is superior to RX over .NET remoting (see my other answer), as we can have one server and many subscribers (it is a true pub/sub model, just like RX).
The queries are compiled into expression trees, and executed on the server (which minimizes network traffic, as only relevant results are returned from the server).
If we want queries to be filtered client side, then its easy - just do a client side filter on the results returned from pushqa.
Its literally 1% of the pain, 1% of the boilerplate code, and 10x the usability of Tibco. I wrote RX wrappers for Tibco and it was a nightmare to get it correct (Tibco has more corner cases than a tub of dodecahedrons). Unless you need to connect to legacy mainframe clients, or want to multicast to hundreds of clients over UDP, or want to waste a kings random in licensing fees, this solution is far superior to Tibco.
Its free.
Its open source.
There's no reason that a framework couldn't be devised for doing that. The framework would have to provide a means to address remote objects, generate proxies for them, then marshal the activity of the remote object across the application boundaries (i.e. through socket communication). .NET Remoting may be a suitable option for implementing this. WCF would be even better.
Are you specifically bound to using Rx as the solution to your problem? WCF provides duplex services, which have the ability for clients to register callback endpoints to a service. The service may then initiate calls back to its clients as necessary. It is effectively a remoted observer pattern. If RX is a must, then it should be fairly strait forward to wrap WCF duplex services with an RX support framework, allowing your clients to "transparently" observe service behavior with IObservable.
Is there a product (ideally open source, but not necessary), that would enable a zero dependency deployment? every service bus or queue library I've been able to find has a dependency on one of the queue apps (like msmq), or a database. I would like a very lightweight solution that I can just add a reference to my application, build it, and deploy it with as little configuration as possible.
In an ideal world, the queue/service bus would run on IIS, and allow web and rich clients to talk to it.
Such a tool would be ideal for fast prototyping of large distributed systems on a local development machine.
Rhino Queues from Ayende is exactly what you are looking for, this is the blog post introducing it:
http://ayende.com/Blog/archive/2008/08/01/Rhino-Queues.aspx
I think that all of the limitations mentioned in this post have been fixed since then.
From the blog post, what rhino queues is:
XCopyable, Zero Administration, Embedded, Async queuing service
Robust in the face of networking outages
System.Transactions support
Fast
Works over HTTP
In a similar vein to ShuggyCoUk's suggestion, you could rig up a queue (or queues) using the Windows built-in ESENT database (comes already installed with Windows). There is a managed code access library (open source): http://www.codeplex.com/ManagedEsent. If you stick with writing / reading CLOBs or BLOBs, it should work just fine. If you want to be really clever, you can use NServiceBus and write (contribute?) ESENT-flavored subscription storage and transports. There are some forays into using ESENT on Ayende's blog as well (you'll have to poke around his SVN repository for the juicy bits).
If you're happy to be:
Windows specific
Limited to the local domain
Seriously limited in the message size supported
Wrap the underlying win32 calls in P/Invoke
Deal with the polling yourself
Deal with the hacks needed to allow back and forth communication
Deal with the shared config needed to keep the names in sync
Then a quick wrapper around the windows MailSlot API might be sufficient.
This simple example is a reasonable basis to start.
This article has some further information but assumes the use case is via a control (rather than a Component as it should be) as well as some poor WinForms integration so should be considered for incidental reading rather than a basis for any library.
This article is C++ but is of a higher standard (and a commenter has extended it to support the batching of larger messages into several smaller ones).
You get 424 bytes (so with .Net 212 chars) you may want to drop to ASCII to double your useful message length if you are talking text.
Note that despite its simplicity, limitations and lack of features it does provide multicast delivery, something often complex to layer on a point to point protocol yourself.
This ayende post provides and interesting comparison of three service buses. We use NServiceBus and think if it's not clear that Udi Dahan would respond to how you'd plug in non-dependent queue.
We work using MSMQ happily but there are other options and in theory it should be open to practically anything, given that you may lose some reliability and durability depending on your choice.
Why not Amazon's message service Simple Queue Service?
We moved our projects from MSMQ to ActiveMQ. its really better :)
ActiveMQ is open source queue ,based on Apache web server.
We used him in production on high frequently data workflow, where msmq have a lot of problem (we work with msmq a year)
The csharp implementation is nms
I'm currently working on an open source WCF based service bus. You can find it here: http://rockbus.codeplex.com/. It supports dynamic (#run-time) subscriptions, subcription repository (database), pluggable transports, XPath based content-based routing, transactional delivery over wcf protocols, roundrobin delivery, pluggable subscription evaluation, and more. Have a look!
Have you thought about using a service like IronMQ by http://Iron.io?
You wouldn't have any dependencies, could quickly prototype apps without setting up any queue infrastructure, and it's highly available and fast.
There is not currently a locally installable version but it's based on the upcoming OpenStack protocol so there will be.
Btw I work for Iron.
Try https://github.com/mcintyre321/PieQ - this is my attempt to write a threadsafe, persistent, zero-config, embedded work queue. It probably needs a little love, but I think it might be the kind of tool you are looking for.
I have developed an InMemory JMS library which can be used to in testing JMS applications without really connecting to JMS providers/server (Think of hsqldb). You don't have to deal with connection or protocol or anything, all you need to do is to send and receive messages.
https://github.com/Dhana-Krishnasamy/InMemoryJMS