I have a C# form application that connects to a electronic device using the serial port.
The class "'SerialCommunicationManager'" hooks up to the serial port on application startup and handles the dirty business of talkning to the device.
What I would like is to expose the following methods.
Write()
SerialDataReceived event
SerialDataTransmitted event
Primarily a local website running on the same machine is the one I want to expose the methods for, but in the future I imagine the need for external applications as well.
What is the easiest way to expose the functionality?
TCPIP client server?
Web service? (Can I create a web service inside a WinForm?)
other?
Big thanks
//David
I would recommend self-hosting a WCF Service. This provides you a huge amount of flexibility in terms of how you serve and expose this information, including being able to change the method by which its served via configuration.
It seems to me, that if you would like to do it properly, you should break apart your forms app, and create:
a service that handles serial comm and has an API exposed through remoting
a Forms app that uses the API and makes a way with the service
Then, depending on the locality of your web site, if it will remain local (or near local - LAN):
web site should use remoting to call the service
else, if you plan to have multiple web sites:
web service hosted inside the IIS that will wrap remoting API
web site that will use web service
However, if it is too much work to do - just use remoting and expose needed methods to the web site.
In a recent project we did the following:
Write a Console application (or Windows Service, depending on your needs) that communicates with the electronic device.
Make the Console application host a .NET 4 WCF service.
Write a .NET 2 Windows Forms application to communicate through Web Services with the console application.
In this context, I could imagine the website you are mentioning to also use Web Services (WSDL) to communicate with the Console application.
Related
I'm developing a C# solution with .NET Framework 4.5.1.
I need to have a program (an object instance) running all the time waiting to receive commands. This program will have a state and depending on this state it will allow some commands or others.
For example, it will have an open and close command. If the state is not openned and the program receives the close command, it won't do anything.
I've thought to create a windows service or a ASP.NET MVC WebApi 2.2 app.
If I choose windows service, the program will be running always but I don't know how to communicate with it (maybe adding it a TCP/IP server).
If I use ASP.NET MVC WebApi 2.2 I can send the commands using POST or PUT messages, but I don't know if I can have an object instance running while the web service is up.
The program is a class that I have to instanced it. This instance will keep its state and a communication with a WCF service.
What do you recommend me?
Options from which to choose are strange a little.
You can self-host Web API in windows service, and communicate with service using HTTP. Note, that Web API is about stateless, so, if you need to preserve the state, this should be a persistable data.
As to a way for communicate with windows service, using something other, than Web API - there are number of ways to do this. WCF with TCP/Named Pipes, pure Named Pipes (without WCF), sockets, memory mapped files. You just need to select most appropriate for your requirements.
I need to write a client-server application. First of all, I'm going to write an application server. Also my app server should connect to database(MS Sql Server) and give data from it to client app. So, as I know, I should use WCF. Is it a good idea? Maybe I need to take a look for something else?
Lets start with client-server architecture.
Assuming you have finalized that you need client and server, but have you decided carefully the architecture? I mean what type of server and what type of client you are going to create?
Let's see the options here:
Server
1. What type of hosting you are going to use?
2. What type and how much load your server needs to handle?
Client
1. Type of consumer of your service
2. Do client need to be deployed on local machine or it should be web based?
There are obviously more concerns than above. Initial design should be as flexible as possible.
So, now lets look at some solutions regarding architecture.
Server:
1. Application Hosted WCF server: Each time you need to manage the server lifecycle. Also, this is not scalable. So if you are looking for scalable architecture, you need to look more.
2. IIS hosted WCF server: This might be a good idea along with some architecture concerns as per your need.
3. Web Method: Obviously this came after WCF, but WCF is still in its place. So the main difference is at What is the difference between an asp.net web method and a wcf service?
Now Client:
1. ASP.NET: This will enable to use a single client app for every platform obviously because of HTML
2. WPF/WinForms: This is going to bit tricky to use as client as you need to deploy the client app on user machine and here comes the data security problem. In former you can directly use SSL or some other way to send data to browser. While in this if you are not using WCF with HTTPS and there are some proprietary data going over wires, it may be concerns.
If you are looking for cross platform usage of your server you can use HTML.
Conclusion:
You can use Server as WCF hosted service (either in IIS or in self contained application) and client as ASP.NET.
-----------------------------If it is not big enough requirement then you can use ASP.NET as server and then browser as client (No need to create client).----------------------------
You can create server either as WCF as web methods and deploy the client on user machine.
----------------------------
WCF is nice enough and it can handle your proprietary data types as well.
WCF is a nice thing, but i would use ASP.Net Self-Hosted Web-API. It's more modern. And you have a full rest interface, which is much more popular.
Here is a comparison: WCF and ASP.NET Web API
Here is a good starting point: Self-Host ASP.NET Web API 1 (C#)
I'm currently evaluating the options for adding a web UI to a .NET 4.5 application that is installed and running as a Windows Service.
The basic idea is that the service application is running 24/7 and collects various data from network devices and persists them in a local data store (esentially, it monitors these devices)
The web UI interface is used for data presentation and analysis purposes and to send command & control messages to the backend (i.e. the service layer) which in turn fowards these commands to the network devices.
The big difference to a "classic" multi-tier web application is that the service part has to run even if no user has been interacting with it through the web UI (therefore the idea is to have it run as a Windows Service).
I currently do not know how to mix this web part (request/response pattern, short running) with the service part (polling on the network, long running, 24/7).
My ideas so far:
Embed IIS Core (or any other web server) into the service application: would probably work but the embedded web server would not know about any existing IIS configuration on the same machine which makes integration and configuration not straightforward (e.g. ports, authentication, SSL etc.)
Deploy an ASP.NET application on IIS and a separate service application: the ASP.NET application would then just act as a facade to the service and would need a proper and reliable way to communicate with the service application (two-way IPC?).
Currently it feels as if 2 is the best option.
If so, are there any IPC recommendations?
Thanks!
The simplest (and probably the worst) way is to embed all your logic to IIS and disable shutdown of your app (this way IIS app will run like a windows service).
I currently do not know how to mix this web part (request/response pattern, short running) with the service part (polling on the network, long running, 24/7).
You shouldn't. Regarding the second case I would suggest to decouple your service app and web ui app as much as possible. This way you minimize dependencies and IPC (therefore improve scalability and stability).
The windows service in this case may implement its minimal role: collecting various data from network devices and persists them in a local data store (the only feature that requires 24/7). IIS app may implement all UI-related features (data presentation and analysis roles) and user command. This way you don't need to delegate all presentation features to the windows service app. IPC is used just for sending command & control messages to the backend (i.e. the service layer) which in turn fowards these commands to the network devices.
I suggest using message queue model (ZeroMQ, MSMQ, RabbitMQ, etc) that is asynchronous IPC with its advantages. From the other hand it is possible to use the database itself for the IPC: e.g. push the messages to some table (or collection if using NoSQL) and read them by the win service app. This is an alternative to message queues but in most cases is worse than it.
I’m currently working on a web service application project which will run in IIS7 on Windows Server 2008. The web services will be invoked from various clients, from outside the server but also from other components from within the same server. (Other web services and windows services)
My view is that the purpose of web services is to expose functionality so that external clients can invoke it. I really don’t see much sense in a web service invoking another web service on the same server or a windows service invoking a web service on the same server. Please correct me if I’m wrong?
I’ve started looking into WCF, but I’m quite confused.
Would it be more appropriate to do the following?
Instead of a web service project implement a WCF service.
Expose two endpoints:
1)One, which will be exposed using traditional web service binding which will be invoked from external clients.
2)Another endpoint so that internal services, (other web services or windows services) can invoke them, supposingly more effectively, surpassing a security layer as these are aplications already running on the server.
Would my approach be correct or am I overcomplicating things?
Any suggestions or links which could point me in the right direction appreciated.
Thanks
A web service calling another web service?
If they have different responsibilities I think it's a good idea to separate them. You get better separation on concerns (easier to share with other projects / code bases), easier maintainability and independent deployability.
I would go with WCF and have two different endpoints for the different consumers, and for example use net.pipe for communication on the same server (if the client supports it) and http for external clients.
I think WCF gives you more power and flexibility that old xml web services, and the configuration part is really good.
BasicHttpBinding will give you most interoperability with external clients.
named pipes will give you the best efficiency when both services are hosted on same machine.
BasicHttpBinding is like old asmx & XML web services.
Exposing both endpoints is AOK!
One service calling another service is NOT unusual.
Hosting multiple services on same machine is common. In the enterprise, running multiple instances of SQL-Server is commonplace. Of course it depends on hardware, services & response times.
I am developing a smart device application, which is going to communicate with a wcf service over wi-fi. As there is no option to add a service reference into a smart device project I decided to use the NetCFSvcUtil.exe. Everything works great!
But...
In the end I understood that the application must interact with the service in the background.
Having read this article Microsoft .NET Compact Framework Background Processing Techniques. I decided to use the Asynchronous Web Service Call. There http://msdn.microsoft.com/ru-ru/library/aa347733.aspx I found the /async parameter, but it appeared to not work for the NetCFSvcUtil.exe.
What can I do to get the async proxy for my smart device application? Is there a way to generate it or I'm expected to add async methods to the interface with my own hands? Maybe it would be suitable for .Net CF to use SvcUtil.exe to generate the async proxy in my case?
A further more information like which platform you are using to build your Smart phone application would be helpful.
I have done Blackberry development and consumed web services. There are two ways you could build your web services
RestFul Service - Consumption of web services would be pretty easy. Posting data could be a little pain as multipart form data is posted as stream in Wcf - Rest Starter Kit
Soap Service - If you decide to use SOAP, then for blackberry and Android you have to use preverified KSOAP -2 to send and receive soap messages between your app and the web service. If you decide to use KSOAP -2 , go back ASMX services. Somehow WCF services does not communicate with KSOAP -2 (due to change in SOAP version or something) where as a simple ASMX service works pretty smoothly. There are dozens of article which you could use to learn how to use KSOAP
he original idea was to host it in a windows service...
Windows Services could never be web facing. If you want any thing to be web facing, you need a Web Server !
In the end it worked. The "Add web reference" tool created a proxy with Begin/End async methods and the proxy interacted with the wcf service hosted by a simple console application (later a windows service) through the URL property of the proxy.