Reliable HTTP/HTTPS Messaging/Notification Product - asynchronous

I am looking for a product to solve a particular task and I'm having a hard time sorting out which product or type of product can accomplish the task. I am looking for something to handle POSTing notifications via HTTPS.
One of my use cases is a mechanical turk type scenario. A client will request a task be started via an API call. A human will get this request do the task, tell the system the task is complete, and the system will send a HTTPS POST to a subscriber. So it's a long-running async request.
I am looking for something that will take care of making this POST for me. I would like something that is reliable and durable. Of course I can write the POST myself, but all of the other niceties that come with a queuing application would be nice to have (and I don't wish to implement all that myself).
I have been looking at a number of queuing, MOM, and ESB products. From what I can tell the queuing products don't seem to push notify over HTTPS and the MOM and ESB are a little too heavy handed I think. For example I think BizTalk will do what I need but that has a lot of overhead. The one solution I did find was Amazon's Simple Notification Service, but that appears to only send from the amazon.com domain, but I want the messages to be sent from my domain.
Can anyone help identify a product that will help? Maybe I'm just overlooking something, not sure what I am looking for, or have to choose a different way of implementing this.

The answer I was looking for was webhooks. Here's a great presentation on what they are and how they can be utilized.

if you want a serverless way to do webhooks, check out IronWorker's webhook support, here's an article on it: http://blog.iron.io/2012/04/one-webhook-to-rule-them-all-one-url.html

nginx has a messaging module that may be just what you need.

Related

Send push notifications with PHP

I am thinking of trying to implement push notifications into my website. Essentially I would just need to message individual users of personal updates not everyone that has agreed. I have looked and researched a lot and its confusing where to start, what I need, what language to use etc.
I use 1and1.co.uk for my hosting and would like to use PHP to instigate the push. Is this possible from what they offer and if so where do I start?
All the paid stuff seems to offer just bulk notifications and that is not what I need and why should I pay for it if its possible to do myself.
Also how difficult and time consuming is the process?
If I get enough advice and manage to get it working, I will write a step by step tuition as there is nothing out there with a simple answer and instructions.
Thanks and regards
If you don't need it in time, you can do it using Ajax polling, which means executing Ajax requests every few seconds.

Receiving payment for email

I want to set up a consulting service on my blog (WordPress). It would be really simple:
Someone asks me a question
I give them an answer via email (or possibly Skype conversation)
However, I'm having trouble figuring out how to receive payment for such service. I can ask for payment up front using platform like Sellfy/Selz, but that doesn't seems like a good solution.
How would you recommend doing this in the least complicated/most effective way? I'm looking to collect payments by PayPal.
EDIT: It would probably work if there was some kind of an escrow in which case both me (seller) and the buyer would be protected. However, it's more tricky to set it up since we're not dealing with actual products.
you can seperate the auth and capture process with paypal. But i think there are extra fees on this so research it carefully.
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/authcapture/
You can look at getting reference transactions with paypal. They provide you a small deposit before the service. Depending on time of service you can use reference transaction with paypal to charge them the total afterwords. Then if they come back, within 365 days you dont need a deposit if they want to use the same payment method.
I opted for the following solution, which is the simplest in terms of what I'm looking for:
Set up Contact form on the website (someone asks a question)
I write a reply and package it as a downloadable PDF
Set up the reply on a service such as Sellfy or Sellz (with possibly a short preview)
Send notification that reply is available for download
That way, the person only pays once the question is answered and I minimize my risks.
Tip: I'm going to set up a short "Terms of service" to which people agree when sending their question. It will be used as a disclaimer and protection against possible misuse of the system.

What is a Webhook and why should I care?

Best I could find was this wiki entry
I I thought "surely there must be more to it than this".
Am I missing something?
From the doc:
What is WebHook?
The concept of a WebHook is simple. A WebHook is an HTTP callback: an
HTTP POST that occurs when something happens; a simple event-notification via HTTP POST.
A web application implementing WebHooks will POST a message to a URL
when certain things happen. When a web application enables users to
register their own URLs, the users can then extend, customize, and
integrate that application with their own custom extensions or even
with other applications around the web. For the user, WebHooks are a
way to receive valuable information when it happens, rather than
continually polling for that data and receiving nothing valuable most
of the time. WebHooks have enormous potential and are limited only by
your imagination! (No, it can't wash the dishes. Yet.)
Why should I care?
As integrated as we perceive the web, most web applications today
operate in silos. With the rise of API's we've seen mashups and some
degree of integration between applications. However, we have not seen
the vision of the programmable web: a web where you as the user can
"pipe" data between apps much like the Unix command line. Some say RSS
is the answer. They are wrong. The heart is in the right place, but
the implementation is wrong. RSS is still useful, but it is not going
to bring us the true programmable web.
We just need a simple way to get data out in real-time to let the user easily do whatever >they wantwith it. That means no polling, no content constraints, and no XML
parsing. That means no RSS. Using HTTP is simpler and easier to use.
PHP is a very popular and accessible programming environment, so it's
likely to be used often for writing hooklets... getting data from a
web POST in PHP is as simple as $_POST['something']. And making the
request to the user script is as simple as making an HTTP request,
something already built-in to most programming environments. In fact,
web hooks are easier to implement than an API.

PubSub between servers using HTTP

I have two asp.net applications, one of which is a publisher of data, one is a subscriber. It's possible there will be more subscribers too. The list is not anonymous, I know my applications.
What would be the best strategy to notify the subscribers when there is data in the publisher?
There are several message brokers and queueing systems on the internet, most are hard to implement and require code that I don't really find desirable (for instance running a service on the machines of the applications, where the services do the communication).
I don't mind running a server somehow that brokers messages, like a hub, but I would prefer a hub that offers an HTTP API I can call from my publisher, and that calls an HTTP page on the subscribers (kind of like PubSubHubbub but that appears to be very much about RSS feeds).
It's a bit unfeasable to write my own queueing system because there are some hard problems in that as well. Also calling the list of subscribers from publisher directly will cause some performance issues that I also want to avoid.
Do you know of solutions I can try?
PS: if this message is better suited for Programmers#StackExchange, feel free to move it!

List currently logged in users in BlazeDS

I really need some expert help here!. Does anybody knows of a way of getting the list of the users currently connected to a BlazeDS server? Is there any built-in mechanism of knowing this? or do I have to implement some kind of server side logic every time a user access my Flex application and store all logged in users details somewhere and retrieve them later?
The nearest thing I can think of, using BlazeDS, is to obtain a list of clients currently subscribed to a destination, but this won't solve the problem IMO.
First of all, you need to define a destination and make sure that all clients will actually subscribe to it (see BlazeDS documentation for this). Then, on the server, you can then get a reference to the message service
MessageService messageService;
messageService = (MessageService) messageBroker.getService("message-service");
and ask for all subscribers with the getSubscribersIds method on the MessageService instance, specifying the name of your destination. This will only returns a number of identifiers, internally generated by BlazeDS (they are also available on the client side of the connection).
To resolve the same problem, I used this approach in combination to a custom server-side logic to store logged-in users (explicitly invoked login/logout methods). Regularly looking at the subscribers can help to clean this store, because in my experience there's no way to be sure that a "logout" method will always successfully called, expecially from Flex client running in the browser, while BlazeDS will automatically take care of cleanup of the subscribers.
I don't like very much this approach, probably someone came up with a better solution..

Resources