I'm writing a windows service that will be used for some data processing. The service will connect to an OPC (KepWare) service and will monitor specific items through event handlers. It will also have to write back to the OPC data item when necessary; however, the data to be written back will have to come from a windows mobile handheld device.
I'm just getting perplexed on the design aspect of this system. I'm trying to make sure that I design this in an abstract manner in order to make it scalable and easily maintainable. However, I'm just stuck on how to communicate with the service in order to tell it write this value to the OPC server. I'm thinking WCF is the way to go but I'm not exactly sure how to write it where I can obtain a reference to my connected OPC object when the client makes the call? Should I be writing a WCF library and host it inside the windows service or should I be going down a different route?
Thanks in advance
You should read up on the fundamentals of OPC-DA and OPC-Xi (also known as OPC .NET 3.0). The OPC Foundation has simple documentation available for free: look for the "specifications" that are available to non-members.
The KepWare server should support both (depending on the KepWare server you are using). OPC Xi is WCF-based and will be the easiest way for you to talk to it. However, that particular communication channel needs to be open and enabled for it to work.
If you don't have that, then you need to fall back to OPC-DA which is DCOM based. You can find .NET OPC client libraries that will help you with this. There are some free and some commercial ones out there from different companies.
Related
I want to create a program for my desktop and an app for my android. Both of them will do the same, just on those different devices. They will be something like personal assistants, so I want to put a lot of data into them ( for example contacts, notes and a huge lot of other stuff). All of this data should be saved on a server (at least for the beginning I will use my own Ubuntu server at home).
For the android app I will obviously use java and the database on the server will be a MySQL database, because that's the database I have used for everything. The Windows program will most likely be written in of these languages: Java, C#c C++, as these are the languages I am able to use quite well.
Now to the problem/question: The server should have a good backend which will be communicating with the apps/programs and read/write data in the database, manage the users and all that stuff. But I am not sure how I should approach programming the backend and the "network communication" itself. I would really like to have some relatively easy way to send secured messages between server and clients, but I have no experience in that matter. I do have programming experience in general, but not with backend and network programming.
side notes:
I would like to "scale big". At first this system will only be used by me, but it may be opened to more people or even sold.
Also I would really like to a (partly) self programmed backend on the server, because I could very well use this for a lot of other stuff, like some automation features in my house, which will be implemented.
EDIT: I would like to be able to scale big. I don't need support for hundreds of people at the beginning ;)
You need to research Socket programming. They provide relatively easy, secured network communication. Essentially, you will create some sort of connection or socket listener on your server. The clients will create Sockets, initialize them to connect to a certain IP address and port number, and then connect. Once the server receives these connections, the server creates a Socket for that specific connection, and the two sockets can communicate back and forth.
If you want your server to be able to handle multiple clients, I suggest creating a new Thread every time the server receives a connection, and that Thread will be dedicated to that specific client connection. Having a multi-threaded server where each client has its own dedicated Thread is a good starting point for an efficient server.
Here are some good C# examples of Socket clients and servers: https://msdn.microsoft.com/en-us/library/w89fhyex(v=vs.110).aspx
As a side note, you can also write Android apps in C# with Xamarin. If you did your desktop program and Android app both in C#, you'd be able to write most of the code once and share it between the two apps easily.
I suggest you start learning socket programming by creating very simple client and server applications in order to grasp how they will be communicating in your larger project. Once you can grasp the communication procedures well enough, start designing your larger project.
But I am not sure how I should approach programming the backend and
the "network communication" itself.
Traditionally, a server for your case would be a web server exposing REST API (JSON). All clients need to do http requests and render/parse JSON. REST API is mapped to database calls and exposes some data model. If it was in Java, it would be Jetty web server, Jackson Json parser.
I would really like to have some relatively easy way to send secured
messages between server and clients,
Sending HTTP requests probably the easiest way to communicate with a service. Having it secured is a matter of enabling HTTPS on the server side and implementing some user access authentication and action authorization. Enabling HTTPS with Jetty for Java will require few lines of code. Authentication is usually done via OAuth2 technique, and authorization could be based on ACL. You may go beyond of this and enable encryption of data at rest and employ other practices.
I would like to "scale big". At first this system will only be used by
me, but it may be opened to more people or even sold.
I would like to be able to scale big. I don't need support for
hundreds of people at the beginning
I anticipate scalability can become the main challenge. Depending on how far you want to scale, you may need to go to distributed (Big Data) databases and distributed serving and messaging layers.
Also I would really like to a (partly) self programmed backend on the
server, because I could very well use this for a lot of other stuff,
like some automation features in my house, which will be implemented.
I am not sure what you mean self-programmed. Usually a backend encapsulates some application specific business logic.
It could be a piece of logic between your database and http transport layer.
In more complicated scenario your logic can be put into asynchronous service behind the backend, so the service can do it's job without blocking clients' requests.
And in the most (probably) complicated scenario your backend may do machine learning (for example, if you would like you software stack to learn your home-being habits and automate house accordingly to your expectations without actually coding this automation)
but I have no experience in that matter. I do have programming
experience in general, but not with backend and network programming.
If you can code, writing a backend is not very hard problem. There are a lot of resources. However, you would need time (or money) to learn and to do it, what may distract you from the development of your applications or you may enjoy it.
The alternative to in-house developed of a backend could be a Backend-as-a-Service (BaaS) in cloud or on premises. There are number of product in this market. BaaS will allow you to eliminate the development of the backend entirely (or close to this). At minimum it should do:
REST API to data storage with configurable data model,
security,
scalability,
custom business-logic
Disclaimer: I am a member of webintrinsics.io team, which is a Backend-as-a-Service. Check our website and contact if you need to, we will be able to work with you and help you either with BaaS or with guiding you towards some useful resources.
Good luck with your work!
*If you think I should ask this question elsewhere, please let me know.
Background:
I need to build an application for converting weights into piece counts. The weights currently come from scales that are connected to PCs via serial ports. I am replacing PC based applications that connect to the scales via a serial connection. I am considering the feasibility of making the next generation of these applications into a web based solution. However, I do not want to do this if it is not a better solution than building an application that runs on the client. In addition, I do not want to use any sort of browser specific technology (ActiveX).
FYI, we currently run a Windows based environment.
What I have so far:
I am currently thinking that I will need some sort of client side “service” to allow the scale data to be retrieved by the web application. I have looked into creating a WCF service for this task and have determined that it would probably work. This would require that the scale be connected to some sort of Windows based computer that is on the network. I would then interface the WCF service (running as a Windows Service on the PC) from an ASP.NET web application running on an IIS web server. This would minimize the footprint on the client and allow us to use a web application.
I am looking for any constructive thoughts and ideas. I am open to reviewing any feasible option that would make this solution as simple and reliable as possible.
Answering my own question per request #honeycomb.
I discovered two viable options for this purpose. Following are high-level overviews of the techniques we leveraged.
Develop a scale reader to be run on a PC connected to the weigh scale device via an RS-232 connection. This reader will forward any information received from the scale into a database. Combined with technologies like change notifications and server-side push notifications, this option will allow data from a weigh scale to be pushed into a web page with little effort and no additional cost. (This option has performed well during testing but is not yet in production)
Invest in converting weigh scale devices to use ethernet connections and connect them to the network. Use an OPC server with a driver that can connect to the weigh scales you are using to read the data from these devices. Consider KEPWare's offering for this purpose. Use KEPWare's tools to forward this data to a database or wherever it is needed. Once again, you can leverage change notifications and server-side push technologies to push this data into web applications in near real-time without polling. (This option is currently working in a critical, production environment)
The second option is probably better in the long-term, but this may vary based on your specific situation. It has some up front costs and would be better suited to new implementations. For my system, I am using the first option because it will ease the transition between the new and old systems.
Note: I am not in any way associated with KEPWare. I am only suggesting their product because it is the only one I am aware of that supports this functionality. I am sure there are other OPC servers that support this type of device.
I am searching for a good method to transfer data over internet, and I work in C++/windows environment. The data is binary, a compressed blob of an extracted image. Input and requirements are as follows:
6kB/packet # 10 packets/sec (60kBytes per second)
Reliable data transfer
I am new to network programming and so far I could figure out that one of the following methods will be suitable.
Sockets
MSMQ (MS Message Queuing)
The Client runs on a browser (Shows realtime images on browser). While server runs native C++ code. Please let me know if there are any other methods for achieving the same? Which one should I go for and why?
If the server determines the pace at which images are sent, which is what it looks like, a server push style solution would make sense. What most browsers (and even non-browsers) are settling for these days are WebSockets.
The main advantage WebSockets have over most proprietary protocols, apart from becoming a widely adopted standard, is that they run on top of HTTP and can thus permeate (most) proxies and firewalls etc.
On the server side, you could potentially integrate node.js, which allows you to easily implement WebSockets, and comes with a lot of other libraries. It's written in C++, and extensible via C++ and JavaScript, which node.js hosts a VM for. node.js's main feature is being asynchronous at every level, making that style of programming the default.
But of course there are other ways to implement WebSockets on the server side, maybe node.js is more than you need. I have implemented a C++ extension for node.js on Windows and use socket.io to do WebSockets and non-WebSocket transports for older browsers, and that has worked out fine for me.
But that was textual data. In your binary data case, socket.io wouldn't do it, so you could check out other libraries that do binary over WebSockets.
Is there any specific reason why you cannot run a server on your windows machine? 60kb/seconds, looks like some kind of an embedded device?
Based on our description, you ned to show image information, in realtime on a browser. You can possibly use HTTP. but its stateless, meaning once the information is transferred, you lose the connection. You client needs to poll the C++/Windows machine. If you are prety confident the information generated is periodic, you can use this approach. This requires a server, so only if a yes to my first question
A chat protocol. Something like a Jabber client running on your client, and a Jabber server on your C++/Windows machine. Chat protocols allow almost realtime
While it may seem to make sense, I wouldn't use MSMQ in this scenario. You may not run into a problem now, but MSMQ messages are limited in size and you may eventually hit a wall because of this.
I would use TCP for this application, TCP is built with reliability in mind and you can simply feed data through a socket. You may have to figure out a very simple protocol yourself but it should be the best choice.
Unless you are using an embedded device that understands MSMQ out of the box, your best bet to use MSMQ would be to use a proxy and you are then still forced to play with TCP and possibly HTTP.
I do home automation that includes security cameras on my personal time and I use the .net micro framework and even if it did have MSMQ capabilities I still wouldn't use it.
I recommend that you look into MJPEG (Motion JPEG) which sounds exactly like what you would like to do.
http://www.codeproject.com/Articles/371955/Motion-JPEG-Streaming-Server
I need to implement simple file watcher utility. I have decided to implement this in a simple windows service which will internally use FileSystemWatcher. The purpose is to monitor given directory path (or ftp) and copy the file to some other server wherever new file comes in after checking some predefined logic
As I am using .net 3.5; client suggested me to use WCF. I have very less experience in WCF.
I am not sure how I can create WCF service which will function like WindowsService and can be deployed in services on windows server.
To be a futuristic is it a good idea to create WCF service instead of windows service, or I should insist on window service.
Windows Service != WCF
You can't create a WCF service that acts functions like a windows service. A WCF service waits for messages from third parties and acts on them, a windows service is a process that is always running in the background. WCF tries to solve the problem of separating out the communication mechanism (transport protocols such as Tcp, Http, Named Pipe, etc) from the service interfaces.
File Watcher Utility
While in theory it's possible to create a new Flat-File binding in WCF that "could" have it's address set to a file system location, one does not exist directly in the .NET framework. Looking at the Custom Bindings article on MSDN it's not immediately obvious to me how one would construct a File System binding. These are the defined transport options available:
TCP
HTTP
HTTPS
Named Pipes (IPC)
Peer-to-Peer (P2P)
Message Queueing (MSMQ)
Custom
If communication must be done through file drops, then WCF does not solve your problem.
Where WCF Might Work
What the client might have meant is to create a WCF endpoint that does the copy the file to some other server wherever new file comes in after checking some predefined logic, but you would still want to have a windows service with a FileWatcher monitoring the input directory.
If you have multiple clients that need to be able to perform that same logic and then send the output to that other server then it might make sense to make the WCF service, otherwise it's over-engineered at this point.
You should choose the simplest option until you find a need to change, with the simplest option being a Windows Service.
There is a coding principle call YAGNI (you ain't gonna need it) that applies in this case as simply wrapping something up in a WCF service would do nothing but add unneeded complexity for the majority of cases. Simply put do the minimum viable solution and extend only when you need to.
PS. If you are using the FileSystemWatcher over network shares note that there are documented problems with it and you should use a combination of a poll + FileSystemWatcher. There are lots of explanations on Stack Overflow about it.
In your use case, the Windows Service makes a lot more sense and I think that to be the more appropriate solution. You need something that is always running and monitoring a directory and thats exactly the use case which Windows services are very good at.
I would consider talking to the client and explaining the Windows Services are the more appropriate solution to this kind of use case. Also, windows services are not old hat, they are there to solve exactly these kinds of use cases and WCF / windows services complement each other.
Both features have Service in their names by they have virtually nothing in common.
A Windows service runs constantly on a single machine.
A WCF service is code than can be called remotely by other machines.
It simply depends on what you need to do. A Windows Service and a "WCF service" have little in common.
The question here is whether you need a HTTP endpoint or not. If you do, you could even host a WCF service in your windows service to provide that. Keep in mind that a WCF is only used as a way to communicate between applications.
Reading your description, though, it doesn't seem like you need it.
WCF Service in a Managed Windows Service
First of all thanks for taking the time to read my question. Here is what I am trying to accomplish followed by what I have so far on this.
What I want to do is create a Windows application (or server of sorts) that would listen for requests from an ASP.NET application. The windows application would be installed and would listen for messages from ASP.NET application and then do some processing. The flow is like this:
A user downloads the desktop application and registers their IP address on my web site. After downloading the desktop app, the ASP.NET application can then send requests to that particular desktop client for further processing. I think further processing is independent of the resolution in this case that's why i have skipped over details on what processing would be done. But if you think it is important, please let me know and I will add those details as well.
I have looked into creating a TCP server that would listen for requests. Because the user has already registered their IP address on my web site, my web site assigns them a unique identifier and stores the ID alongwith IP address in database. Now, the ASP.NET site can send requests to that desktop application.
I have looked into creating a TCP server for this purpose. While researching I also came across PNRP and it seems something like what I am trying to do.
Can you guys recommend some solutions or where I should be looking at for this scenario? Should I create a simple TCPLISTENER or may be go with PNRP approach? Or something else?
The basic requirement is for a web application to be able to communicate with a desktop application. The web application would be servicing numerous users and each user would have a desktop application installed. Which user for which desktop client question would be addressed by the web application that would maintain a database of unique user id's and their corresponding IP Address.
Thanks in advance for your help.
You could use .NET remoting or a web-service in the desktop app. Use WCF or WSE for the latter. You can use COM to add windows firwall rules.
Whatever you do, take firewalling/NAT into account. It might be easier for the client application to poll the server (initiate the connection) otherwise you open a can of worms by trying to have a remotely-accessible server in your user's computer without having to do some very manual configurations on the user's networking equipment.
Once you have that part sorted out, what I used in your situation was .NET Remoting. At the time WCF had not come out and when it did it was to crippled for my needs. TCP IP sockets were too raw (I had to write too much code) and so Remoting solved my problem ideally (a hand full lines of code to set up the connection, and everything was automatic from there on).
EDIT: I use an excellent third party library that makes Remoting even more flexible (flexible enough that I am still waiting for WCF to catch up with the featureset so that I stop using Remoting, and no luck yet!). Check out http://www.genuinechannels.com/ to see all the features they have. It includes making calls from server to client, and that sounds exactly like what you need to do. Check it out.