I'm looking for the best way to use a Windows Service to manage a group of objects for use by several different client programs. The service must
create the list of objects corresponding to physical or virtual devices,
maintain information about what process is currently using a given device and what devices are available to be used,
manage requests to use a given device by a process,
return devices to an unused state.
When I look at the Windows Service examples, though, there is very limited communications to Services. OnCustomCommand doesn't return any information to the caller.
So is there a recommended way to establish information exchange between a service and various clients?
For background - I am replacing a Win32/COM app with a .Net app. The current device manager is a COM server with the clients being COM clients.
You could always implement a WCF service inside your Windows Service to communicate with the outside world. It would do so using either HTTP or Net/TCP (in a corporate LAN environment) or other transports (like MSMQ message queueing, if appropriate).
When the Windows Service spins up, you could also bring up a WCF ServiceHost to handle those communication needs.
See:
MSDN: How to host a WCF service in managed Windows Service
Self-hosting WCF services
WCF Essentials - hosting the service
Just an option - MsgConnect library for transparent communications between applications on the same or different systems. Designed specifically with your task (service-GUI communication) in mind. With MsgConnect you can send and receive messages (much like you do in Windows) which carry custom data. On local system messages can be transferred using MMF or sockets, for remote communications TCP sockets or HTTP can be used.
Related
I am new to storage domain .can Some one please help me in understanding the below things
Can a storage sever be connected to Application server?
1.How storage servers are different from applications servers
2.Can multiple application servers connect to storage serves over the network
3.what kind of files will be served by NAS and SAN severs
Firstly this question belongs on server-fault stack exchange still it is a good conceptual question...
So the answers are~~
Yes storage servers can connect to application server (app servers are in fact software frameworks or specific portion of a server program implementation). Application servers communicate with storage server to store / retrieve / process data.
Apart from high disk space, what else is different about storage servers you may ask ? In many cases, they come with a host of specialized services. This can include storage management software, extra hardware for higher resilience, a range of RAID (redundant array of independent disks) configurations and extra network connections to enable more users to be desktops to be connected to it.
Where as, application server is a software program that handles all application operations between users and an organization's backend business applications or databases. An application server is typically used for complex transaction-based applications. To support high-end needs, an application server has to have built-in redundancy, monitor for high-availability, high-performance distributed application services and support for complex database access. For mobile computing, mobile app server is mobile middleware that makes back-end systems accessible to mobile applications to support Mobile application development. Frankly speaking, application servers lie in the territory between database servers and the end user, and they often connect the two.
Multiple application servers CAN and in reality DOES connect to storage serves over the network or even directly. but for concurrent access to data there must be guaranteed reliability of data between transactions. Something like ACID properties.
Cming to the third one, NAS, it turns out, is NOT really storage networking. Actual network-attached storage would be storage attached to a storage-area network (SAN). NAS, on the other hand, is just a specialized server attached to a local-area network. All it does is make its files available to users and applications connected to that NAS box — much the same as a storage server. To further conceptualize the difference between a NAS and a SAN, NAS appears to the client OS (operating system) as a file server (the client can map network drives to shares on that server) whereas a disk available through a SAN still appears to the client OS as a disk, visible in disk and volume management utilities (along with client's local disks), and available to be formatted with a file system and mounted.
I have an embedded device that can be controlled by JSON over UDP. I am currently performing this via an iOS App, and everything works great.
I am now wanting to be able to also control my device from a remote location. And am wanting to use Azure to perform this task. I envision that I will set up an Azure Website which will enable me to select options which then send the JSON to my device, which is behind a firewall.
My question is which of the Azure Services should I be looking into? Also, what is the best way to get the JSON packet to the device behind the firewall (I do not want to use port forwarding).
In general, to avoid an attack surface from outside your LAN (where you have your embedded device), the better solution is to open and output connection from embedded device to the cloud and to leave it open so that it can send and receive data/command.
In this case, on Azure you can use the Service Bus (queue, topic/subscription or event hub) to send/receive with AMQP protocol but it is strictly related to your device and capabilities.
Can you share more information on it ? How much it is a constrained device or a more power device with an high level OS (Linux, Windows, ...) ?
Paolo Patierno
About using Amqp on devices running android is very tedious. The java implementation in dalvik is missing a lot of required apis to be there.
By the way, do you know where we can find information about related path segments to use in amqp pure syntax in Azure, to interact with IoT-Hub end-points. Like for queue for example, we can have :
amqps://:#.servicebus.windows.net/
Thanks
Please read before tagging as duplicate.
I'm creating a set of applications which rely on smart cards for authentication. Up to now, each application has controlled the smart card reader individually. In a few weeks, some of my customers will be using more than one application at the same time. So, I thought maybe it would be more practical to create a service application which controls the authentication process. I'd like my desktop applications to tell the service application they are interested in the authentication process, and the service application would then provide them with information about current user. This part is easy, using named pipes. The hard part is, how can the service tell the desktop applications that an event has occurred (UserLogIn, UserLogOut, PermissionsChanged, ... to name a few). So far I have two methods in mind. CallBack functions, and Messages. Does anyone have a better idea? I'm sure someone has.
You want do to IPC (Inter Process Communication) with Delphi.
There are many links that can help you, Cromis IPC is just one to give you an idea what you are after.
A similar SO question to yours is here.
If you want to go pure Windows API, then take a look at how OutputDebugString communications is implemented.
Several tools can listen to the mechanism and many apps can send information to it.
Search for DBWIN_DATA_READY and DbWin32 for more information on how the protocol for OutputDebugString works.
This and this are good reading.
When it gets into IPC, some tips:
Do not be tied on one protocol: for instance, if you implements named pipe communication, you would later perhaps need to run it over a network, or even over HTTP;
Do not reinvent the wheel, nor use proprietary messages, but standard formats (like XML / JSON / BSON);
Callbacks events are somewhat difficult to implement, since the common pattern could be to implement a server for each Desktop client, to receive notifications from the server.
My recommendation is not to use callbacks, but polling on a stateless architecture, on the Desktop applications. You open a communication channel with the server, then every second / half second (use a TTimer in your UI), you make a small request asking for what did change (you can put a revision number or a time stamp of your last retrieval). Therefore, you synchronize your desktop data with pending events. Asking for updates on an existing connection is very fast, and will just send one IP packet over the network back and forth, if nothing changed. It is a very small task, and won't slow down nor the client nor the server (if you use some in-memory cache).
On practice, with real application, such a stateless architecture is very responsive, from the end-user point of view, and is much more easy to deploy. You do not need to create a server on each desktop application, so you don't have to open firewall ports or such. Since HTTP is stateless, it is even Internet friendly.
If you want to develop services, you can use DataSnap, something like RemObjects or you can try our Open Source mORmot framework which is able to create interface-based services with light JSON messages over REST, either in-process, using GDI messages, named pipes or TCP/HTTP - for free, with unbeatable performance, build-in security, and from Delphi 6 up to XE2. For your event-based task, just using the Client-Server ORM available in mORMot could be enough: create a table/class storing the events (you can even define a round-robin in-memory storage - no need to use SQLite3 engine nor a DB here), then ask for all pending events since the last refresh. And the server can safely be a background service, or a normal application - some mORMot users even have the same executable able to be either a stand-alone application, a server service, an application server, or a UI client, just by changing the configuration.
Edit / announcement:
On the mORMot roadmap, we added a new upcoming feature, to easily implement one-way callbacks from the server.
That is, add transparent "push" mode to our Service Oriented Architecture framework.
Aim is to implement notification events triggered from the server side, very easily from Delphi code, via some interface definitions, even over a single HTTP connection - for instance, WCF does not allow this: it will need a dual binding, so will need to open a firewall port and such.
It will used for easy Event Collaboration, via a publish / subscribe pattern, and allow Event Sourcing. I will try to make it implement the two modes: polling and lock-and-wait. A direct answer to your question.
You can use a simple TCP socket connection (bidirectional) to allow asynchronous server to client messages on the same socket.
An example is the Indy TIdTelnetClient class, it uses a thread for incoming messages from the server.
You can build a similar text-based protocol and only need a Indy TCP server instance in the service, and one Indy Client instance in the application(s).
I'm building a system with some remote desktop capabilities. The client is considered every computer which is sharing its desktop, the server is considered a central server with a database which receives the images of all the multiple desktops. On the client side, I would like to build two projects: A windows service application and a VCL forms application. Each client app would presumably be running under a different user account on the computer, so there might be multiple client apps running at once, and they all send their image into this client service, which relays them to the central server.
The service will be responsible for connecting to the server, sending the image, and receiving mouse/keyboard events. The application, which is running in the background, will connect to this service some how and transmit the screenshots into the service. The goal is that one service is running while multiple "clients" are able to connect to it and send their desktop image. This service will be connected to the "central server" which receives all these different screenshots from different "clients". The images will then be either saved and logged or re-directed to any "dashboard" which might be viewing that "client".
The question is through what method should I use to connect the client applications to the client service to send images? They will be running on the same computer. I will need both the abilities to send simple command packets as well as stream a chunk of an image. I was about to use the Indy components (TIdTCPServer etc.) but I'm sure there must be an easier and cleaner way to do it. I'm using the Indy components elsewhere in the projects too.
Here's a diagram of the overall system I'm aiming for - I'm just worried about the parts on the far right and far left - where the apps connect to the service within the same computer. As you can see, since there are many layers, I need to make sure whatever method(s) I use are powerful enough to accommodate for streaming massive amounts of image data.
Communicates among processes, you can use Pipe/Mailslots/Socket, I also think while sending a stream file Shared Memory maybe the most efficient way
I've done this a few times now, in a number of different configurations. The key to making it easy for me was using the RemObjects SDK which took care of the communications part. With a thread that controls its state, I can have a connection to a server or service that is reliable, and can transfer anything from a status byte through to transferring many megabytes of data (it is recommended that you use small chunks for large data so that you have more fine grained control over errors and flow). I now have a set of high reliability templates that I can deploy to make a new variation quite easily, and it can be updated with new function calls without much hassle (first thing I do is negotiate versions between the client and server so they know what they can support). Because it all works at a high level, my code is just making "function calls" and never worrying about what the format on the wire is. Likewise I can switch from their binary format to standard SOAP or other without changing the core logic. Finally, the connections can be local, to the same machine (I use this for end user apps talking to a background service) or to a machine on the LAN or internet. All in the same code.
I have an embedded device that runs WinCE with wireless capabilites.
I'm looking for advice on technologies I can successfully use that will allow me to easily create a web service on the WinCE device and be able to serve content to my iOS device.
I'd prefer that the web service running on the WinCE device support REST as opposed to SOAP.
A REST Web Service can really be created with anything that can listen and respond to HTTP requests, so a simple socket listener could effectively fulfill your requirements.
Service over wireless and the fact that the client is iOS is actually irrelevant, as the service simply has to know how to respond to HTTP requests, probably (though not certainly) on port 80. If a PC can consume the service, so can iOS, Linux, Andoid, OD/2 or anything else. That's the whole point of a web service.
I assume, however, that you're after something a bit more feature-rich than just rolling your own socket listener. Windows CE has an optional HTTP server that can serve up basic HTML as well as a subset of classic (i.e. 3.0) ASP and some ISAPI. They all tend to be painful to use and debug, but they are included in your OS license and therefore essentially free.
There is also at least one commercial solution that I'm aware of, and that's the Padarn web server. It uses a subset of the IIS object model, so you can easily create IHttpHandlers for URIs and handle requests with compact framework assemblies. As full disclosure, I'm the creator and purveyor of Padarn, so I'm obviously biased toward it.