This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Why are Event Driven API's Difficult?
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
The public review of the Streaming API for XML (StAX) has been released. This is the standardization of a new kind of way of interacting with XML. The current ways are based on SAX and DOM. SAX is extremely efficient however it tends to be more difficult to program in a event driven style. DOM based api's tend to be more flexible however at the cost of creating the entire document tree. StaX is really a "pull" based API as opposed to the the "push" based SAX.
StAX and SAX performance I would expect should be roughly equivalent as evidenced by these benchmarks. The claimed advantages of a "pull" form is that it is easier to program in. However, I do find it very interesting that imperative languages make it difficult to write programs using "push" based or event driven programs.
The answer is that imperative languages are designed to express control flow explicitly. On the othe hand, for event driven API's the control flow is in a large part controlled by the event processor and the programmer is required to write code that's more reactive. Writing reactive code is definitely more difficult because you can never assume what will happen next. However, I'm going to go out on a limb to say that reactive code is actually more scalable and flexible.
I also have two thoughts on how to make programming to Event Driven API's easier. One is to make the specification of state machines much easier. The way to do this with a programming language is to introduce what is called Generators. Generators were popularized in the programming language Icon. It allows the definition of functions that can be called multiple times but return multiple results.
A second approach is to make the specification of grammars much easier. If you've taken Automata Theory in college you know that state machines are equivalent to regular expressions, and regular expressions is a language that is weaker than context free grammars. The approach then is to define state machines in terms of context free grammars. This is exactly what a tool like Joost is doing. Joost is an implementation of the Streaming Transformations for XML (STX).
STX is should not be confused with StAX. They both are designed to tackle the streaming xml problem however STX tackles it in a much high level way. STX however doesn't need to use a "pull" API. It leverages SAX and makes developing XML transformations as easy as XSLT. Actually, I like it better, since it gives an imperative flavor as opposed to the functional flavor demanded by XSLT. Matter of fact, if you're thinking about scalability, this is possibly the best way to fly. I had it crunch through a 29 mb file without the VM going over 8 mb, such a task will put a DOM based XSLT processor to its knees!
Event Driven API's also tend to be more loosely coupled. If you consult this table you realize that it supports two properties. That is asychronous and lazy evaluation. So even amidst the call away from "pull" driven API's as shown by (StAX), "push" driven API's will continue to become more prevalent.
In summary, Event Driven API's are more difficult to program in simply because imperative languages were not designed for them. The use of both Generators and Grammar based approaches make it much easier. The main benefit however is better scalability and a loosely coupled approach.
Previous Topic
