I have been thinking of using AIR, but without the ability to easily connect to Oracle, it's not as likely I'll us it. I am in need of a way to push a simple alert to users on an enterprise system. Currently they want something in a browser window, but I don't think it is the best option, plus it looks terrible. AIR looks great with the transparent floating window.
Anyhow... Any suggestions on what to do?
Push or pull ?
If it is a pull, I'd have the database generate a simple RSS feed through a web-service. 10g or later has a built-in webserver (XDB protocol server) that can publish this. Then you leave the whole client thing up to them.
If it really HAS to be a push, then I'd have to be thinking about UTL_HTTP, though any push technology requires a port open and listening on that PC. You'd be making the end-user's machine a 'server/webserver' of some sorts which seems pretty dangerous.
You can send emails from the database too, and some people who have made a twitter publisher for Oracle, though both would technically involve a pull from the client.
Couple of ideas - take a look at Growl For Windows - it's a notification system that started on OS X, that has a published protocol (GNTP).
The nice thing is that it is very easy for the client to change the form of client-side notification.
Examples :
http://www.growlforwindows.com/gfw/displays.aspx
There's even a Flash/AIR library, if a 'native' install would not be allowed.
Equally, with Growl you can plug in forwarding to SMS, IM systems, Twitter, and whatever else they invent next week, and plug-in subscriptions to similar systems.
I think the advantage of this approach is that it would reduce the development to simply writing an app that looks at the DB on one side, and pushes notifications out of the other.
If you want to 'push' all the way from the DB then you should also look at Oracle AQ (with messages being fired by triggers, if you don't have direct access to the code modifying the DB).
Given that there is a JMS interface to AQ and a Java Growl library, it feels to me like this would be the 'least work' option - the server application would be something that subscribes to the JMS channel and forwards each received message as a Growl message. Alternatively, you can interface to AQ via PL/SQL functions using other languages.
The other approach would be something similar, but rather than using Growl/GNTP, using a more widely accepted messaging standard - we've written a Flash based app that requires 'push' messaging from the server using AMQP as the protocol, and RabbitMQ as the messaging server.
The disadvantage of this approach is that you have to also write the client.
Either way - what you want is a server that sits inbetween your client and the d/b and converts 'events' into an easily consumable messaging protocol.