Scribble on a Pull-turns-push architecture based on http – registering web applications as event listeners

6

Today in the car I had some thoughts on applications working together, across the boundaries of technology and organizations. I tried to find an easy, cheap way for for example web applications to keep tracks of events of interest happening around it. No need for expensive, fancy or complex SOA, JMS, ESB etc. infrastructure.....

I came up with this fairly simple architecture where a web application publishes a Servlet that can be called with event-notifications. These are simple, almost fire-and-forget messages that are replied to with minimal responses. The notifications are plain old Http(s) get and/or post requests that contain simple properties like type of event, category, timestamp and data attributes. A notification can signify a new entry in an rss feed, the reception of an email or IM message, the change in a piece of data, a development in a business process (BPEL sensor output) or sporting event, change in an application parameter or anything the application may find of interest.

The servlet passes the data on to a singleton object (and/or an object in the application scope of the web application). Sessions may have registered listeners on this singleton event dispatcher, that will be notified of the events received through the servlet by the dispatcher that satisfy their criteria.

The servlet can be called by any event publisher anywhere in the world, either in plain Http or in secure Https.

One interesting option would be to enlist the help of a CIA – a Central Intelligence Agent – that listens/polls for events on behalf of interested parties. The CIA could repeatedly listen to for example RSS feeds (pull model) and upon discovery of a new entry turn it into a push event by calling web applications that registered their interest with the CIA. Any event that the CIA can discover by itself – or is notified of by event publishers – can be sent to Http-based listeners.

Note that the Oracle Database can be such an Http listener – through its PL/SQLGateway using for example DBMS_EPG (http://technology.amis.nl/blog/?p=1628) – that is notified of external events. The database can also publish events – using the supplied package utl_http. This means that this architecture could be used as a way of exchanging event information between databases, across http(s) and through most firewalls.

 

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

6 Comments

  1. Marco Gralike on

    By the way, I hereby would propose to use the Oracle 11g Native Database Web Service (“XMLDB”) functionality, instead of the DBMS_EPG/PL/SQL Gateway, because it has the advantage that it is kernel build-in (buildin C, instead of based on a database servlet): http://tardate.blogspot.com/2007/08/revisiting-11g-native-web-services.html . Another alternative, which is probably even easier to use (it is already buildin functionality), is using DBUri’s and/or XDBUri’s (http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14259/xdb15dbu.htm#sthref1873). It is possible to create a fast and easy HTTP/REST endpoints this way (http://forums.oracle.com/forums/thread.jspa?messageID=1884992&#1884992).

  2. Marco Gralike on

    I really like the “Scribble” stuff, keep it up (or should I hope for a lot of Dutch traffic jams :-) )

  3. P3t0r
    Thanks for your comment. Of course you are right. It was just a brainstorm of sorts. The most useful point probably would be to have a central component doing the pulling – collecting events from pull sources such as RSS feeds, HTML pages etc – and turn them into push events to listeners who have registered.The other thought is that almost anyone can implement an HTTP interface – from the simplest Servlet container, PHP engine to the Oracle Database – that can accept such pushed events. Setting up an ESB or even a JMS topic is considerably more complex for many organizations and/or developers. So basically what I was thinking was getting a very simple way of pushing events into any technology stack, without having to worry about the infrastructure or firewall.
    regards,Lucas

  4. This is basically the same as building your own ESB/Messaging solution… most ESBs (if not all) do have HTTP/REST-style endpoints, with or without HTTPS. And since most ESB’s are build arround a messaging infrastructure you get reliable asynchronous messaging for free…

    I probably just don’t get what you’re trying to do ;)