Flash, Flex, Apollo -- Nice Bits

Via Blaine Buxton, the Omaha Dynamic Language Group will be discussing Flex and ActionScript 3.0.

Other programmers here have been diving into that the last few weeks. I've been reading in my down time from other things, but would like to write some code in the next few days. Flash 9 has a lot of general improvements as an environment for structured graphics applications, and Flex builds on that for GUI front end things that are not so oriented toward animation and graphics as the base Flash api.

Apollo just looks to be a leap ahead of other "Web 2.0" (if you will) front end environments. Busting out of the crappy browser that in spite of AJAX has been mostly languishing for years and years. We're not using Apollo yet here, but for some of the front ends we may need it could be. It's only in an initial alpha release currently. I want to play with "the bits" as they say at an Adobe rival that should be really concerned with the polish Flash, Flex, and Apollo are showing.

FIT Wiki Rules Spaces

Fuzzy writes about the work we're doing...

We beat our rules module into submission.

We're writing FIT tests in our Confluence wiki. A custom FIT runner grabs the tests using some specified label and the Confluence XML-RPC api.

We also have Bamboo up and running, and soon Jira. The Atlassian folks have some nice tools.

As Mike writes, the Javaspaces and JBoss Rules came together well. When I had looked at Drools some time ago I was turned off by its XML nature. Jess is not free, but not expensive, and has good Java integration. Jess also has a good scripting language in its own right (Lisp-based). Back then it would have been a no-brainer.

Since JBoss took on Drools they now have all but done away with XML. In fact none is required from what we've found so far. The Java integration and the rules language itself is not as good as Jess, but it is pretty good and it's free and open.

We've not tried the decision table mechanism. If we're lucky that takes care of most of the Java integration ugliness and if we're *really* lucky our business analyst can use it in whole or in part with little or no programmer intervention. She's very smart, but non-technical. That's the aim of the decision table, I believe. The Jboss site also has something on FIT and JBoss Rules, but we've not tried that yet either. Our FIT tests go through our own fixtures.

On the spaces side we dynamically update and make available all kinds of reference data and object prototypes via a space. When it came time for rules, we did the same thing. Rules are compiled and tested in the build scripts, and stashed away as release artifacts. When the environment is initialized the compiled bytes are sucked out of the files, wrapped in a RulesEntry and written to a space. The rules compiler has all kinds of dependencies but the compiled rules at runtime just depend on one core jar.

We have a mini-grid of sorts that run any kind of TaskEntry.execute() from a space. If such a task happens to need a rules engine, it makes one, takes *reads* (rules are shared, and so, read, not taken) the appropriate RulesEntry from the space, and squirts the bytes into the rule base. If the rules need to be updated then the new bytes in a new RulesEntry simply replace the old bytes in the old RulesEntry. The next time a task tries to read the entry, it gets the new rules. The TaskEntry objects and code can be updated the same way, no worrying about what is or isn't on some arbitrary JVM's classpath.

The "facts" needed by the task also come from a space. The task takes them from a space and assertObject(entry)'s them into the rule engine's working memory.

The "many, flat" nature of entry objects flowing through spaces and the ease of writing rules around "several, flat" facts makes these two mechanisms the good fit Mike describes.

I will repeat: in my experience, Jini and Javaspaces make Java applications as close to a concurrent, distributed, dynamic system experience as can be done. If you would like to use Erlang, but have to use Java, then try using Jini and Javaspaces.

We're just getting started with this experiment, but everyone's seeing the advantages over even the relatively flexible JMS products.

Meet the New Boss

Nati Shalom, not an unbiased, but still an accurate observer...

Oracle's acquisition of Tangosol is one more acquisition in a series that indicates Oracle has finally come to the conclusion that the relational database is no longer a sufficient infrastructure platform for a large class of applications, such as Extreme Transaction Processing (XTP) and real-time analytics.

Let's see how much gas Tangosol has, though. Prior to the acquisition, the head of Tangosol had speculated about the combined advantages of their data cache and the jini, or at least javaspaces, distributed architecture. Now are they back to square one with J2EE?

Massive

Massive.

Massive.

Massive.

Massive.

Delegation and Inheritance

In 1986 Henry Lieberman presented at OOPSLA a really simple object system based on delegation to any other object rather than on inheritance through some fixed tree of definitions.

Confused looks led to friendly arguments, led to the Treaty of Orlando a year later. And then Self, etc. expanded on this, Newton Script, and Javascript. (But the wonder of it has been lost along the way. Javascript is getting "serious" by adding classes and type checking and so on. Bah. Forgive them for they know not...)

As long as we still care about objects then, here comes Ian Piumarta with his new one(s), er, two, no, one: "Pepsi" and "Coke". In a recent addition to Pepsi, Ian has delicately spliced the two worlds together...

Compared to inheritance, delegation is the more flexible and general of the two techniques. However, they both have their place within an object model: inheritance for sharing of implementation state (and the methods that act upon it) for a single prototype (within a hierarchy of related prototype families), and delegation for sideways composition of (independent and previously unrelated) prototypes into a single logical composite object. This is the position adopted (and implemented) for sideways composition of Pepsi objects.