Alright guys, I'm in a little over my head on this one and am hoping someone can point me in the right direction, as I'm not really sure how to implement this.
I've got a piece of hardware that exposes a c#.net API. Great. Works wonderfully. I want to collect data from this hardware using the API (so, a small c# app that does what I need) and then display the results on a web page. Currently, I have the c# app grab data I care about and stick it in an RRD file, then I have the web page load the relevant data and display it to the user.
My question, then, is what do I do when I want to expose some of the API functionality to the user? How do I go about making the 2 projects talk using .NET?
Some clarification: The reason there are two parts is due to modularity. The attached hardware and API can change, but as far as any client request is concerned, nothing's different, everything's just a web request to them.
Very little experience in big .net projects, so if you've got a better idea, let me know.
The easiest way I can think of would be to use something like NServiceBus to post a message to the other component which communicates with the hardware. The hardware piece would pick up the message from the bus, process it and put the response back on the bus.
It's not a perfect solution, but I think it's definitely workable.
You should be able to find everything for it here.
Left it here for a few days to see if anyone else had any ideas. I ended up scrapping the whole idea and consolidating everything into the web app. Not my initial preference, but it works okay. Thanks to Terrance for the brainstorming session under my question.
Easy. Create a class library for the device handler. Add a public class which exposes a nice interface for the web app. Add a reference to the class library. Create your class and use it.
Related
(First i just want to say i'm sorry if its not worded the best but i have been researching for hours and i thought maybe someone on here could clear this up for me)
Im new to creating web apis and i have been googling just doing some research and i have built a few MVC applications just to get exposed but i never really thought of making an API for it until today. One of the reasons its listed to be useful is it allows your application to be used across tablets and smart phones etc. What im not understanding is how you would do this as in would you just add something to the API so it makes it compatible for all browsers or if i need to re build it using Web API instead of MVC.
Thanks,
I think your looking at a Web API from the wrong perspective. It's not really about compatibility necessarily, but rather about the ability to reuse the code/back-end functionality.
So rather than having your dependencies all wrapped up in one MVC project, the references are external. This allows for essentially the same functionality across multiple projects as long as the request are being handled in the same manner.
I've got I admit that I'm probably too dumb to fully learn and understand WCF. :(
On the other hand I had learned and used xmpp pretty well ( using MatriX XMPP library ).
So I wanted to ask, maybe there are some other libraries that help passing data from one computer to another to make life simple?
i.e. a library that would open a port/connection and both listen to incoming commands from other computers, as well as be able to send such commands to other computers that are listening to it.
Thanks!
WCF is not a hard technology... there is a learning curve, but ultimately someone who has taken the time to learn how to do it can easily implement the functionality in a couple of minutes.
i.e. a library that would open a
port/connection and both listen to
incoming commands from other
computers, as well as be able to send
such commands to other computers that
are listening to it.
Not really. Most of WCF involves setting up your app.config files so that they work on both ends. And I doubt there are any libraries that can do that for you.
You simply HAVE to generate and implement a service contract and implement the endpoints/meta data.
MSDN actually has a very decent tutorial. Getting Started Tutorial
Even if you DID find a "helper" you should still take the time to learn the technology so that you are prepared to troubleshoot and fix it when it breaks.
And if:
I've got I admit that I'm probably too
dumb to fully learn and understand
WCF. :(
were true... you wouldn't be a programmer.
My journey to understanding WCF happened right here on Stackoverflow... you can check it out at : Cross Application Communication (C#).
It might help you understand a little bit better.
Two options come to mind.
If you want to use WCF, the check out ECollective from SOA Collective. Uses managed mode Discovery to create a config-free WCF client, abstracting all of the things that makes WCF hard like bindings and behaviors.
If you want to use something other than WCF, check out NServiceBus.
Try the Idesign Website ... they have a WCF library that you can download and use in your projects.
I'll explain breifly my situation and hopefully you will be able to advise if what im wanting to do is possible.
I have an existing java application that I am wanting to split into modules. To handle and control these modules Im going to write a module manager in C#.net. Due to the size of the existing program the bulk of the existing modules are not going to be rewritten in .net yet and remain as java modules.
Is it possible to call a java "module", pass it parameters and have the java module return a value ( other than an int )?
I apologise for not knowing much about this area.
Kind Regards
Ash
Hmm... maybe some kind of MessageQueues like MSMQ, Apache ActiveMQ or IBM WebsphereMQ can solve your problem.
On the queues you can store and receive XML-Messages with all the Information you need.
Some information about this can be found here:
http://msdn.microsoft.com/en-us/library/ms973816.aspx
Another approch can be to work with console output .. but IMHO this is not a good solution.
I would instantiate the Java as a separate service and call it using (say) web services, Hessian etc.
Alternatively, have you looked at jni4net ?
If everything's in Java, then why the effort in moving everything to C#? From what you've said it'd make much more sense to write the module manager in Java and just keep the codebase all in one language (unless of course I'm missing something, in which case ignore!)
If you really need to do this then I'd say a web service is the nicest way to go, there's other hacks and various tools around that you could use, but a web service would completely abstract the language away and makes things much easier to consume.
I haven't tried this either but hopefully reading this thread helps you... :)
Java - C# interop
You can expose your Java module as a soap web-service and consume it from C#.
Here you can read about Axis one of the Java Soap engines and quick tutorial how to create and call it from C#.
I created a Windows Form executable in .NET 3.5 that uses a dll to communicate with a machine that scans checks. I'm eventually going to need to move from an executable to a Web Form that can do the same thing. This will be months from now, but I wanted to start doing the research now as I have not done this before. I'm going to need to use ActiveX in order to communicate with the device via a Web Form. I've also not done this before.
I'd like to keep the functionality of my existing executable without having to rewrite most of it, although I do understand that some of it will need to be rewritten. I've done research on ActiveX and how to use it, but I wanted to know if someone has had a similar situation as this. What did you do to convert an exe to a web program? Are there good, specific sources out there that I'm overlooking that can point me in the right direction for this situation? Is there any advice that you can give from your experiences that can help me to reduce mistakes? The company that I work for does not have anyone else here that has done this before, so I've got to teach myself everything needed to do this.
Thanks in advance.
This is where separation of concerns and n-tier design shine through. Hopefully your UI layer is loosely coupled from your domain model. If this is the case, you can code a second IU layer for the web. And not have to change your domain model at all. Then you can compile for each scenario.
*note - In practical use I have always had to extend my business domain to account for some issues with the second UI, but those modifications have usually been minor, and have pointed out places where I had coupled too tightly anyway.
Another option you may consider is creating a web services layer over your business domain code. And then coding a web application that communicates with your domain model via those web services calls. This may have performance implications, and would not be my preferred method of accomplishing this. Though you may find it more manageable if you don't have a well designed application to start with.
"I'd like to keep the functionality of my existing executable without having to rewrite most of it"
In general if you extract as much logic as possible into its own assembly/dll, you can reuse that from whatever UI framework you want. Just make sure you're not doing anything UI specific in there (throwing up dialog boxes, etc).
Normally, converting winforms to webforms is quite possible, although typically a slow development process. Even if you've got the cleanest domain layer in the world, the fact that objects in your web page are thrown away every time means that a web domain layer is normally written very differently to a desktop domain layer.
However, in your case the device - server communication is going to be extra difficult.
Have you looked at xbap? It's basically a way to deploy WPF applications into a web page. It requires your clients to have the right version of .NET installed, but it's going to be the easiest path for you, especially considering that you can host winforms in WPF...
You may take a look at Silverlight 4,
http://silverlight.net/getstarted/silverlight-4-beta/
It contains many features that ASP.NET Web Forms hasn't.
If your team can accept something like ActiveX, why not Silverlight 4? The only disadvantage is that SL4 is still in Beta.
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.