I need a biometric (RFID or FINGER PRINT or face recognition) system which could consume web api directly - being independent of third party. I got some CAMS biometric unit and ZKTECO K20 pro model these could send data to server but we must go through their data server and need to expose the API. I want biometric system that could send activity data to my server.
This is required to develop a system to control attendance of branches from cooperate office. Here I need some suggestion of biometric system. I got
You can install a biometric device with its default software on your computer. The software stores the attendance data in your local database. You can develop a software to read the data from the local database and update your server on a schedule.
Online SDK is restricted from the manufacturers as it may lead to the security issues. As it is online based, anyone can access the anyone's biometric device if the online SDK has been exposed. So it is kept as confidential by the manufacturers CAMS and ZKTeco.
You can make your CAMS devices to communicate with your server directly, Below is the text snippet taken from their API documentation link: http://camsunit.com/application/biometric-web-api.html
Want to receive data without coming through CAMS Dataserver?
Yes. We provide the windows lite version protocol engine which should be
installed at your windows server. Once its installed, You web api
endpoints will start getting triggered whenever attendance is
registered at the device
You could say I am a fan of the Realm Mobile Platform. I'm using it and it seems to be working well.
However I am confused with how to operate it going to production. It seems to be deployed only to one server, and even the professional and enterprise editions are working on my single server.
Assuming Realm have thought of this (as Enterprise edition supports 'enterprise scaling) - how does this work if all clients point to my owned server URL?
Another question is how to monitor the load on that server.
Thanks!
The Professional Edition and the Enterprise Edition emit statsd compatible metrics which allow you to track the usage and load on each node in a Realm Object Server cluster. These metrics are also used internally inside the cluster in order to display statistics about the health of the cluster.
We are obviously still adding metrics as we understand more about our customer's use-cases, and fine-tuning the ones that we have.
With regards to the way the clustering works, we are currently implementing this according to an iterative process, where we add more and more features, and more and more resilience to the system with every passing day.
Basically, we have a logical load balancer process, which receives the incoming client connections, and then dispatches that to a node inside the cluster. This logical load balancer can be HA'd and LB'd itself as well, just like you would any regular WS connection handler. Handling many connections these days is easy. It's handling the quadratic merge algorithms that is expensive on the Realm Object Server, which is why the clustering is required for deployments at scale.
I am trying to develop a cross application model/view scheme using Qt. What I mean attempting is to have:
Data: SQL Server
Model: Server Application
View/Controller: Client Application
This is for security reasons so that the Client App does not communicate directly with the server. Instead the communication between the model and the data server is handled via proxy Server App which runs on the same server as the database. Communication between the latter two is easy since Qt has the classes to handle it already and they are relatively easy to sub-class.
The problem for me is how to establish the connection between the model (based in the remote Server App) and the view (in local Client App).
I will present my ideas I gathered from researching the topic if it is the right direction but I would really appreciate some guidance. So first I will establish the network socket-based connection between the two apps. But what then? Is it possible to simply "link" the model in the Server App in the Client App as if they were part of the same app? Or should there be the model in the Client App as well and the connection would be used for synchronization between the two models? Or something different?
Thanks for help!
You definitly will have to implement some kind of protocoll. There is no benefit in security if you just link the complete model from server to client. More you will have a local copy in your applications cache for repesenting the data. You need to define what to sync and when to check for new data or send data back to the server. After that start implementing the most basic protocoll options and start sending some data across. On top of that start implementing any more features you need.
is there a way for a server to push some data to a client, wirelessly and seamlessly, which may be Windows(Phone), iPhone, Mac, or Android device, without any OS integration?
If so, what's the best design pattern to do this, and what are the best technologies to go about this?
Push technology is simply a methodology of the server initiating the transfer of data, rather than the client asking the server for it.
Apple makes push technology relatively easy to use by providing such functionality built-in on the OS. As well as Android through the Google Cloud Messaging for Android. Windows, however, does not.
Apple push notifications and Google's messaging for Android is seemingly magical and/or functionality that the OS needs to handle; however, this isn't necessarily the case. The advantage of having it "integrated" in the OS, is the same as having a framework handle the functionality for you.
Speaking in technical terms, push technology is a long-lived connection from the client to the server that accepts messages. These messages would be considered pushed messages, since the client did not make an individual request for them.
The main thing to keep in mind when implementing push technology yourself, is that the client is in charge of keeping that long-lived connection alive as much as possible. Because client IP addresses can change between disconnects, servers are not guaranteed that a client's address will be persistent across disconnects. Moreover, clients can be connected from behind a firewall, making it impossible for a server to reach the client.
For comparison, pull technology is the more traditional process of a client connecting to a server and requesting data.
Your best bet for Apple iOS will be using their push notification service.
For Android devices you should use the Google Cloud Messaging for Android. Alternatively, you can create your own background service to handle the messaging; here's a guide.
For Windows (desktop at least), you will have to create your own service to perform such duty. Here's an MSDN guide explaining how to create a Windows Service using Visual Studio (VB and C#). There might be frameworks already built that handle such messaging on Windows, however, I don't know of any.
Use WebSocket (with or without socket.io).
In the future, you could use WebRTC.
With Websockets, the setup is really simple. The client (a user agent, like a browser or a WebView) connects to the Websocket server, over http(s) (less problems with firewalls) and that's it. There's a bidirectional socket with an event-based API.
If by "OS integration" you mean "write special code for each platform" then the answer is no.
As you mentioned, you would like file system access, and background processing. That combination is not available in a cross-platform way at this moment.
If by "OS integration" you meant "without having to wait for apple/google/ms to provide the ability" then the answer is yes/maybe.
All the popular platforms have Push notifications and background processing support, as long as you code it the way each particular platform expects it.
But file system access will be limited to what restrictions the platform places on you. For instance in ios and win8(phone) there is no wy to write or read a file outside of your own apps private file structure. For security reasons, you cannot access the file system of other apps.
UPDATE:
The general pattern here is to release an app for every platform you want to support.
The app will register itself with its respective platform's push notification service.
You will write generic server side code to accept the data you want to push to all your client devices. Then you will invoke the respective push API's for each platform you support, causing the client devices to wake up and trigger the app that you provided to respond.
When the app opens, you get the app to contact your server and download the full data "the push notification being just the wakeup call for your app"
This way you can easily tell how which of your devices have received the data.
Each platform specific app must save the data to its own local storage and provide a way for the data to be shared via the methods supported by its respective platform.
On IOS it can be as simple as supporting the "Open In.." paradigm.
On W8Phone, you'll have to publish the data via one of the available "sharing contracts"
And so forth for every platform you want to support.
This is the general pattern at the moment. There are some caveats. On IOS, the app will nt automatically start when a push notification is received. This means your app will only download the whole of the data when the app is opened by the user.
A mobile app also cannot generally run indefinitely in the background. This means that once the app is started, you have a limited window for push notifications to be automatically processed by your app. After the allowed "background time". The app will close and any push notifications beep on the device, but wont open the app until the user taps on one of the notifications or opens the app directly.
Technically you could use XMPP Libraries, it is meant for implementing chat system (msn, gtalk, facebook chat, etc...) but this could work well as a push message system because it is opensource and well built to handle all the cases you never thought of. Also you could host your own server and send push message that way...
Why not use a webservice? In my previous project I used webservice to deliver data from mysql database. The webservice I used was nusoap. On the client side I used kSoap library for Android. Hope this helps.
if you want to receive and send real time communication between a server and client (irrespective of the device or OS), i would highly recommend you use XMPP technology because it is designed for the sort of things you're asking for.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP‑CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces.
http://xmpp.org/rfcs/rfc6121.html#intro - that is the latest RFC which will give you a good starting point.
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.