I am aware of rails REST interface which allow me to access sources.
and I am aware of publish-subscribe strategy for message passing
Is it possible to implement REST client(not browser but ruby client works on arduino device) to access resource if resource (ex. server informed client that resource is now available you can receive) available via publish subscribe strategy ?
I am aware of Faye. is it possible to implement REST client using Faye to receive via publish-subscribe for ruby ? If it is not possible with Faye which can be other solution for Ruby REST client to build a publish subscribe communication ? How can Faye inform ruby client for resource notification ?
REST is based on HTTP, so it is Request-Response.
you can't make Pub/Sub service with REST.
If I were you, I would use Faye to notify client about new resources, or whatever you want to monitor.
And after notification you can make Ajax request to REST and get new record for example.
But the best approach is to use Faye for pushing changes to client.
Don't be aware, it is quite simple.
Related
From a Web Server running in Windows 2012, I would need to send messages to specific clients. These clients are Delphi applications, over 2000. Each message is for a specific client, no broadcast.
Which technology can I use? I am totally new on this issue.
I am seeing Websockets, SignalR (that is based in Websockets), MSMQ, RabbitMQ, ...
MSMQ: Seems a good solution. Cons: It only works in Windows. Maybe in a future, I need to add other platforms as clients.
RabbitMQ: It is also good,but I think that it provides too features for my scenario. Basically I only need to send messages from server to specific clients.
SignalR: I am confused. It seems basically for web browsers, not for client applications. It seems a simple solution.
Basically, I am looking a simple and basic solution that I can implement in Delphi to receive messages from a web server.
WebSocket (a HTTP upgrade) is a light-weight option and also available for Delphi clients:
WebSocket is designed to be implemented in web browsers and web
servers, but it can be used by any client or server application. The
WebSocket Protocol is an independent TCP-based protocol.
See WebSocket client implementations for Delphi
RabbitMQ and other solutions are useful for example if the client could be offline while the server wants to send the message. The message broker provides a store where the message will be waiting for the client, even if the server restarts. Also a message broker will reduce load on the HTTP server.
Is it possible to implement REST client ( not browser but ruby client works on arduino device ) to access resource if resource is available via publish subscribe strategy ? (for example: http server(rails application) informed client that resource is now available you can receive/download)
I want to build application for "communication directly between ruby client in arduino board to http server". I don't want to use middle layer like Rabbitmq, zeromq. If it is possible what can be the possible steps to follow ?
It is not possible to use HTTP for pub/sub.
If you don't want to use message queue(anyMQ), try using plain TCP/UDP sockets.
XMPP is not the best choice, it gives too much overhead.
I want to use Azure service bus in my iOS app to communicate with server i have went through the below link. its pointing to C#.Need suggestions to work on iOS.
http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/#next_steps
You may want to consider using WebHttpRelayBinding for your service so you can hit the Azure endpoint using HTTP / HTTPS.
WCF supports both RESTfull and classic SOAP style messaging but using lightweight json requests in a RESTfull service would be better from a mobile app.
read the following article for details. but you don't need to write custom autostarter if you are using IIS 7.5 or greater with appfabric, since it has autostart functionality in built.
http://msdn.microsoft.com/en-us/library/hh966775.aspx
if you don't need request-response messaging pattern then you can also consider service bus queues for persistence, and your on-premise process can pull and process the messages at its own pace.
So, I'm researching methods for building a client interface for existing EMRs. I've read tons of info on HL7, as well as the various coding schemes, but I'm still really clueless.
For anyone whose worked with an EMR before: is it possible to build a web interface that can use HTTP-POST and HTTP-GET requests to pull/push data to the server database? Or would you have a separate database for the client, say a web application, then use some interface engine like Mirth to communicate between the EMR database and the web application?
A web service API is definitely a way to go. One benefit to this is that you can get https almost out-of-the box for encryption of data in transit.
The way we have configured our EMR is that we have a tcp server accepting incoming hl7 messages from certain IPs which connects directly to our EMR database. This can be beneficial by separating emr and interface processes (You don't have to restart your whole EMR if the interface goes down, for instance).
Another good feature would be to have a token system for pseudo-authentication. This only works if you are going over a secure connection though.
If you aren't into writing your own tcp server (not that hard), an api-based server is probably just as good.
EDIT: What language(s) do you think you'll be using?
Other things that you might run into:
Some applications prefer file drops to direct calls (either url or tcp)
Some vendors will have their own software that sits on a server of yours
Don't forget the ACK.
I don't see why you couldn't do this. You would need to build the web service to handle requests with a specific Uri. When this Uri is called the web service uses the data sent with the request to make changes in the database.
Once you had the web service built, you could build some sort of front-end that displays your information to the user. And makes HTTP-GET and HTTP-POST calls.
There is a lot of flexibililty in what you are trying to do... so go with a plan for sure.
In general though you should be able to accomplish what you need to do by building your own web service and front-end application that is able to manipulate an EMR database.
It really depends on your architecture and requirements.
Architecture 1
If you want your client to be web based, but your client is a separated app from your backend, then the web sends the info using HTTP to your client app server side, and then, that will send info to your EHR backend (another app). That second communication might be written using a standard, that will help you on integrating more systems with your backend in the future. So that interface can be HL7 based, if HL7 v2.x is used, take a look at the MLLP protocol: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=55
This is the most performant way of communicating HL7 data. If you don't want to deal with TCP, there is a proposal for HL7 v2.x over HTTP. HAPI implemented that: http://hl7api.sourceforge.net/hapi-hl7overhttp/
If you don't want to use HL7 v2.x but HL7 v3 (a different standard, not really a version of 2.x) or CDA, you can use HTTP or SOAP.
Architecture 2
But, if you want your client just to be a UI on the user side (browser), HTTP POST will suffice to send info from the browser to the server. That means your EHR is a centralized EHR with a web iu.
In the 1st architectural case, first case you'll probably have multiple client apps (full EMRs apps) and a backend EHR server (centralized backend). On my developments I follow this second architecture.
Also there Mirth might help to manage all the communications between client apps and backend apps. In the 2nd case, using Mirth is nonsense, is just a web application and the client communicates directly with the web server. Of course, you can use Mirth as a web server, but that's not it's role, it is an ESB no a web server.
Hope that helps!
I'm working on a rails app that will primarily be exposed by an api to various mobile clients (iOS, android etc). The application involves users submitting data to the server (via api calls), but what I want to include is the ability to push this data down to other clients. The general concept is similar to a messaging app, where I submit a message to the server from me client and the receiver is pushed the message from the server.
The only method I know of at the moment is to constantly poll the server, but there must be better tech solutions than this. Any ideas?
I would look at using a websocket within the page to push the updates.
You could implement this using Faye, which falls back to long polling and other work-arounds for browsers without websocket support. Faye has a pure-ruby implementation, so you could probably work out access to your model layer.
Edit:
Also, this is a project that combines Faye with Rails. It is fairly new, but might do what you want. Faye-Rails
You should check out http://www.pusher.com
Pusher is a hosted API for quickly, easily and securely adding scalable realtime functionality to web and mobile apps.
If you need self-hosted solution, then you should check out slanger gem https://github.com/stevegraham/slanger which is server implementation for pusher client libraries. When you feel you need hosted solution, you just change URL's.
Slanger is an open source server implementation of the Pusher protocol written in Ruby. It is designed to scale horizontally across N nodes and to be agnostic as to which Slanger node a subscriber is connected to, i.e subscribers to the same channel are NOT required to be connected to the same Slanger node. Multiple Slanger nodes can sit behind a load balancer with no special configuration. In essence it was designed to be very easy to scale.
Ruby has it's own event-processing library, implemented like a gem:
https://github.com/eventmachine/eventmachine
Maybe it helps you
I prefer event machine over any other solution. It is somewhat more complicated that faye but you can write way more sophisticated code using event machine.
You might wanna check this peepcode screencast on event machine