First off the JBoss Microcontainer is a big step forward for JBoss. It will hopefully let the meaty parts of the appserver unhinge from the gooey stuff that is the API. However, I can't help but not think that it is that big of the deal for the rest of the world. First off, since Spring added annotations as seemingly first class citizens, I think the only profound step forward for the JBoss Microcontainer is:

• Hibernate Annotations/EJB3 as first class citizens (you can even scan a directory for them with an ant task from a plain Java application)
• Designed rather than organic. This is like "gee if we had it to do all over today we would..." This is especially apparent when you DO write XML. Spring's XML has always made me gag. The JBoss MC ones only make me slightly sick to my stomach.
• Persisted attributes. This was most of the point really. Somewhere this was supposed to be configurable to different stores. This seems under documented.

Springy people are going to comment and tell me how wrong I am about even these things and that is fine, but I've actually looked and at least run both where they'll just run around looking for anything that is positive about anything else and "correct" (I only like one "evangelist" in the world and think the rest of you are techno-scum and worse the kind that aren't paid to do it are messed in the head to boot) :-).

For JBoss users the Microcontainer is probably going to be a snoozer. They're probably going to find more third-party reference material and tutorials on Spring and even Guice. There probably will be better Eclipse tools and other tool integration for Spring. For JBoss internals this will probably be a big deal. For users of OTHER appservers, this is a biggy as JBoss is developing some really good stuff that will no longer be strictly bound to JBoss. In some ways I hope this along with OSGi support shrinks JBossAS and allows it to finally be right-sizable by dumb people.

For Meldware this misses the mark because it still "by Java developers and for Java developers". It doesn't abstract configuration from Java. Meldware users don't as a whole care much about Java. The developers mostly whine about it as it is a means to an ends and not all that interesting in itself.

<javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.test.javabean.support.SimpleBean">
    <property name="ADouble">3.14e12</property>
    <property name="ADate">Jan 01 00:00:00 CET 2001</property>
    <property name="ABigDecimal">12e4</property>
    <property name="ABigInteger">123456</property>
    <property name="abyte">12</property> 
</javabean>

JBoss MC "javabean" descriptor

How many system administrators do you think really want to think about WHAT class we implemented the SMTP Protocol in? How many do you think want to know what class we implemented the socket listener in? Probably pretty few. They may want to declare another socket bound to the same SMTLSSL service they defined but I can't imagine that they want to type all this org crap. Secondly try writing a tool that can not only read, write but update this!!! (I did for JBossMX the MC predecessor and it hurts my head)

For us we want a way to use Java to define a service "smtp" and then configure the service:

exampleService {
  type           = example
  setting        = "settingValue"
  anotherSetting = 4
}

bkernel prototype out of a unit test

Where did all the Java crap go? It is behind the definition of "example" which is either an annotation or in another file somewhere. It probably never changes so WHO CARES. It is a "type" of thing to be configured. Indeed this may also look like:

...
dn: ou=Services,dc=buni,dc=org
objectClass: organizationalunit
objectClass: top
ou: Services

dn: cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelService
objectClass: top
setting: o=setting,cn=Service,ou=Services,dc=buni,dc=org
setting: o=anotherSetting,cn=Service,ou=Services,dc=buni,dc=org
cn: Service

dn: o=setting,cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelServiceSetting
objectClass: top
value: settingValue
o: setting

dn: o=anotherSetting,cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelServiceSetting
objectClass: top
value: 4
o: anotherSetting

LDIF from one of Andy's nightmeres

That looks like something logical exploded and its guts were left on the road but that is not intended to be written by hand but generated by tools or processes inside of LDAP. The advantage is that you can centralize configuration in a directory with replication and all that cool stuff. Moreover this stuff is poorly expressed in a relational database as the stuff is really more of a tree and walking a tree in ANSI SQL is at least horrible.

The point is that the microcontainer is still just Spring reloaded. For me it isn't very useful because I can't abstract the Java out of my configuration. For Java Application developers who do not work with non-Java programmers, "who cares". For me...it's just another flavor of the same stuff we've all been smoking for a few years now. Let's have some config files that don't look like throw-up and don't expose your guts to the world. For JBoss...when is JBossAS 5 coming out again (okay I'm a hypocrite but it is still a good question)?

Technorati Tags: jboss jboss microcontainer spring meldware bkernel

The other day I wrote on Sun's dirty tricks re: the apparently not quite open source OpenDS. Sun's new "OpenDS Community Leader" Ludovic Poitou has posted a response that more or less calls all the developers Sun let go -- for their not being French* and then subsequently forced out of the project -- liars. *(this is the only explanation that has been given up until now). Following this I posted that I didn't really feel the response was all that satisfying. To which the Distinguished Engineer posted a challenge to suggest a response that would be satisfying. I replied:

The license is not enough to create open source. Your governance model is de facto shared-source if not de jure.

The obvious:

• 1. Restore all developers who were forced to resign
• 2. Restore the governance to the state prior to your recent reversion
• 3. Discuss the proposed changes with the full community.
• 4. Management apology for this behavior and a promise that it will not happen again.

The ideal:

• 5. Rehire those developers who want to come back in their previous positions.

Not surprisingly he didn't like that response and since Sun has done something dirty they'd like to "move on" (read: get away with it and admit no wrong doing, free to do it again in the future). So he reiterated that all the former Sun employees whom myself and others had come to respect technically and believe had a sincere desire to do REAL open source were liars who had dirtily sneakily made Sun's project open.

Shockingly one of the other OpenDS developers, Trey Drake (who was fired and then pushed off the project), didn't like being called a liar and evildoer and clarified:

Enough. I have attempted to stay out of the fray as I find the whole thing embarrassing as I initiated the governance change. As the previous OpenDS Community Leader I was deeply involved in the community and was the primary advocate for making OpenDS and the broader Identity Management community more open, transparent and independent. The change in question was the result of months of discussion amongst the owners, myself, and the eventual Identity Management community owners (which included me). To say that it wasn't "Sun approved" is incorrect. There were no less than 2 Sun officers irectors), an engineering manager, a principal engineer, and the previous Sun appointed Project Lead involved in the change. As an advocate for the community, I wanted to take these changes further to ensure that there were non Sun users on the ownership board and explicitly state that community participants represent themselves not their employer. The adopted change was a first, conservative step in that direction. The idea behind this and other changes was inspired by Jonathan's vision for Sun's growth and credibility in the OSS community. The "doacrcy" is nothing new and based on very successful OSS communities; i.e., Apache, Eclipse...

As for the broader community - I personally bounced the change off a select group of OpenDS users, but not the entire community on the public mailing list. In hindsight, I suppose this change should have been sent out over the public alias, but to what end? Would anyone, in the OpenDS user community have disagreed with a freer, more open project? The change was not swept under the rug nor done in secret. Ludo, you and others may have "just discovered" the change because you were not involved in the OpenDS project until shortly before we were laid off. Please don't attempt to cast a negative shadow over our previous efforts as OSS advocates.

From the preceding thread and claims by Neil, it appears that Sun requires ultimate authority over projects it deems critical to their success. There are many java.net projects initiated and entirely staffed by Sun employees with weaker and, in fact, no governance whatsoever. Current Sun employees may claim that they didn't see nor approve the change and that may be a true statement. It is also true that there was no clear need to consult these employees on the change. So, what's your point?

Lastly, I haven't seen any public discussion or legitimate reasoning for reverting back to the post April governance. Reasoning that "we didn't approve" and hence this is a correction implies there was a previous wrong. You have chosen to change the governance as you see fit. As the only project owners you have that right, but don't discredit the previous leadership and claim the moral high ground in doing so.

I do think that Trey made some mistakes here. The changes should have been vetted publicly. It isn't that you agree or disagree -- and he's right -- it is hard to imagine anyone in open source disagreeing with more openness (though it does happen). However it isn't that you agree or disagree. It is that you showed everyone the respect for their input. Do that enough and you get an open source project. If you don't, you get a shared source project. Sun is demonstrating this very clearly now. Trey breeched some etiquette, not more. Sun burned the house down. It isn't the same thing.

After 1.0 we'll probably migrate away from OpenDS. It makes me sad though, it is a technically excellent but dysfunctional non-open source project. I was duped. I thought that so long as the OpenDS developers were sincere about the desire to do this as real OSS that the details would work themselves out. I didn't anticipate just how much control Sun intends to exhibit. My imagination doesn't allow me to see the long term benefits for Sun to exhibit this much control and simultaneous pretend that it is open source. I think they'd be better off just keeping it proprietary or shared source and giving up the pretense and headache if they don't give a damn what anyone else thinks unless they immediately agree with Sun. If you don't get to vote with your hands, vote with your feet.

Update: Simon Phipps who is kind of a PR Sock-puppet for Sun's open source misadventures, has commented. Basically whenever Sun gets caught with their hands in the cookie jar they get Simon to act as a "voice of reason" and try and convince people it is okay. Simon views himself as a "man on the inside" but in reality rarely reads from a different script. Oddly he's "still looking into it" but is PERFECTLY voiced in Sun's talking points...lame as they are. What is good for Sun (in their shortsided view) is good for the community!

Another Update: Thanks to Ken Coar for mentioning this excellent summation of how Sun often misses when it tries to grok open source.

Yet another Update: They are in full fire control and have either shutdown the list archive or have put me in "a sandbox". I can't tell which. It was BEFORE this blog post too. Meaning this message looks like I was just peachy with regards to if you're not watching carefully. Since they're only interested in feedback from those that auto-agree with them, I think I'll vote with my feet. I encourage you to look very dubiously on Sun's "open source" projects as even if the developers are great nice guys who really believe and "get it"...they work under the sword of Damocles and it doesn't matter what they say/think/do.

More coverage: LinuxWorld, and Neil's followup to Simon's talking points (which seem to have been written mainly by Sun's HR). So Sun is going to set up a central governance committee for all of Sun's projects for the sake of "consistency". They have the right to do this... it is there code. It just isn't open source...where consistency is of course not exactly job #1. ;-) BTW my post was swallowed too. After Trey told more of the story Sun started moderating the list. I'm sure a "technical issue" will be discovered after the media coverage dies down a bit. BTW link to the articles. Google news wants to know ;-). Meanwhile Sun's tactic is to make this look like he said/she said though they don't address the facts just repeat talking points.

Kudos to Dave Johnson..... for not just repeating the talking points...now if the underlying issue of "Does Sun think Open Source == Just licensing" (which was a Simon Phipps aka WebPRmink talking point some years back "development vs distribution")... Governance makes this sound like some committee issue...and distracts us from the meat.

Another post: with a great quote. Note that eduard/o is making sure the Sun talking points are disseminated widely. Again, eduard/o this isn't a 'perception problem' to be fixed with PR, it is a problem with Sun's behavior. If you haven't changed that and are instead running around calling ALL of the former OpenDS developers liars (what did they all get together and start a lying club?) then you're creating an even BIGGER 'perception problem' and your PR effort will double backfire on you. For instance some JBoss developers got tired of a dedicated band of fools who trashed JBoss in every JBoss-related post -- often anonymously and under aliases. Since gracing them with a response would lend such folks credibility, they came up with fake names and addressed them under aliases. Which part do you remember, that JBoss was unfairly stalked and trashed by some individuals with competitive falsehoods or that JBoss "Astroturfed"? Do you think anyone will give a damn about the details of your talking points or that Sun once again has managed to be "not so open" and "controversial". Next, by aggressively repeating talking points that seem overly consistent to be self-authored what do you think will happen in your after career? There were times at JBoss where I couldn't defend what JBoss was doing (for instance the horrible JBoss ON proprietary mess that was a top-down management thing but didn't address what customers REALLY wanted which was an admin console!)... Privately when asked I referred people to JBoss sales and said "I have no opinion to share really" (which most people read between the lines) and kept my mouth shut. I liked Rich and most of the guys on the product but really couldn't stand behind it. There is an art to not being a total tool and keeping your job.

It seems that someone at Sun has made a bad decision on how to handle this project once many of the key members of the community were laid off when Sun's Directory Engineering effort moved to France. I haven't seen any type of response from Sun. Hopefully cooler heads will prevail. Some of the recent halo Sun has is due to it's efforts in open source. A blunder like this could really tarnish what their executives are trying to accomplish.

Technorati Tags: open source OpenDS Sun

I'm totally going to buy one of the new Android phones when they come out. Today in less than 5 minutes I managed to get the SDK, Eclipse plugin installed and create the Hello, Android application. I managed to write an app for their emulator and run it before the phone even came out whereas it took me an entire day just to figure out how to get my palm to work with bluetooth on Linux. Better yet, it looks like they're licensing the important parts under open source licenses. It looks like these will be real open source licenses that we're familiar with already (not just some license sanctioned in a secret meeting by a closed and non-representative body pushed by some VC afraid that open source will screw up his "enterprise upgrade" strategy). Contrast this with the Palm where they freaking make it hard to even do hello world with their horrible SDKs or the iPhone which is a monstrous "all your data are belong to us" plan by apple. I think Android is probably going to do for phones what the IBM PC did for microcomputers. The evidence is there. When something doesn't matter, no one comments on it. When something matters they comment on why and how much it doesn't matter.

Technorati Tags: android open source google mobile palm

This is a pretty disturbing read. Early on I voiced my concerns that maybe OpenDS was only pseudo-open source. This seems to confirm that. Maybe we made the right technical choice in using it, but maybe we do need to consider the community aspects a little more closely in our technology choices. Alex K. can laugh at me now...if only the ApacheDS build and config process wasn't ass.

PS. Who in their right mind would relocate open source development to Europe right now...from a financial standpoint the move seems...stupid (anyone notice the Euro vs Dollar right now)...not to mention the "IK" factor...Sun never seems to miss an opportunity to shoot themselves in the foot.

UPDATE: my original post had a broken link (ref is not valid ;-) )... This is fixed. The "IK" factor is a Marc Fleuryism that explained why...a certain company...got it wrong...if I recall correctly. JBoss did not need "Intellectual Property" IP because we had "Intellectual Knowledge". Meaning we had all the guys who wrote the thing and had been working in it and knew RIGHT where the ins and outs of the code were without having to even look at it. Building a new open source developer is really actually very expensive. Losing a good one for no reason is not cheap. I say "no reason" because Sun is doing this to...SPEND EUROS as opposed to DOLLARS? Where is THAT business sense. The importance of co-location is greatly diminished in open source. It might not be 0 but certainly isn't worth the loss of IK, relationships and good will. I'm hoping Marc picks this up and expounds on "IK" a bit.

Technorati Tags: Sun Open Source OpenDS

Last night TriLUG hosted Pat Patterson (the identity expert and not the wrestler) on identity. This was what many, including myself, thought was one of the best talks we'd attended. I could tell Pat was sweating it as the announcements and time ticked off (I'd promised him close to 2 hours as our announcements and AV setup usually take less time). He managed in 90 minutes to bring over 60 people up to speed on the whole of the "Digital Identity" space, at least from a high-level perspective. You can find the slides: here and the audio: here. I'm the guy who asked all the stupid questions (as usual).

My only complaint is that Pat is a "Font Sinner". He used "Arial Narrow" on his iMac which renders differently on my Ubuntu box. Ideally, he'd have used a free and multi-platform font like: Red Hat's Liberation fonts or the BitStream fonts. This is less of a problem with his PDF rendering, but initially he gave us ODP files which rendered poorly. In essence, when distributing a PPT or ODP or whatever, use a free/multi-platform/unique named font set like Red Hat's Liberation Fonts or the BitStream fonts. When distributing PDF it only matters ideologically (my issue is that stuff doesn't render right rather than the ideological issues).

Technorati Tags: identity superpat OpenSSO OpenDS open source trilug

I'd hoped to do a release today, but a few things that we're working on just aren't ready and I'd like to wait until the next Sunbird/Lightning release. Meanwhile things are really moving forward with some great contributions from the community in the IMAP area. I've nearly finished with global addressbook integration (using OpenDS) including in the webmail side. The pieces remaining are:

• Personal Addressbooks (working out how the security works)
• Addressbook administration
• Administration cleanup
• Documentation

searching for addresses in a global addressbook hosted by Meldware/OpenDS

This work is moving ahead now and we should be ready for its release shortly. Meanwhile, we've seen a lot of uptake in interest since you-know-who was acquired. I think people are really starting to see the difference between real open source and trial-ware/shareware.

showing an address

I never can help myself from looking ahead. I think there is a real need for better mobile integration in the calendar space. Particularly with scheduling. However, targeting multiple mobile devices is still a pain. With SuperWaba going closed source and already basically violating its GPL license (from what I can tell), I don't see any great solution.

I kind of think a scripting approach makes sense. That being said I'm not altogether sold on JavaME. One, who needs another proprietary platform (JavaME is not open source, or even apparently free as in beer or whatever). Secondly, it doesn't seem to have much in the way of ubiquity. My Treo doesn't even have it. I wonder if a scripting language geared for mobile devices and a set of widget peers might not work? Something like TCL/TK but not. The idea would be a tight subset for internet connected handheld devices, buttons, windows, grids and essentially sockets or http... I look at stuff like SynchML and it is a bit depressing to be honest. Why can't I have as robust of an experience on my phone as I have on my desktop (screen realestate aside) without selling my soul to any one vendor's "platform strategy"?

Technorati Tags: meldware buni groupware mobile javame j2me OpenDS flex Addressbook PAB LDAP

As I alluded to, without letting the cat exactly out of the bag, OSI approved two MS license. I liked Microsoft's blog statement on the matter and I have to say that I didn't care for Matt Asay's statement. Matt's posts frequently trouble me in that they confuse Open Source licensing with open source. Meaning you can use an open source license...and produce non-open source. The simplest way is to patent some technology or knowingly produce software that uses a (valid) patent by someone else and restrict how that patent is licensed in a way that is incongruent with open source. The cool thing about Microsoft's licenses is that they appear to confer such patents (where owned by MS). On the other hand, you can also do things like SuperWaba did and shut down your community site. The tough thing here is that it is less obvious in some ways. On one hand, the source to SuperWaba isn't readily available or developed in the open nor is it indeed easy to get at the binaries. It has the look, feel and smell of a proprietary product (they even make you register to download it), but is GPL. No way that is open source. Microsoft may end up throwing binaries over the wall, make the source hard to get at and potentially even license the binaries under other licenses. They might open source license that without actually doing open source development or distribution per se. This wouldn't be unique to Microsoft, so don't pick on them here, I'm just saying don't do what Matt Asay does, occasionally in his writing, and confuse open source licensing with open source.

Technorati Tags: open source OSI Microsoft Ms-PL Ms-RL

First of all, I'd like to thank whoever stole my Blackberry that I left on the Helsinki to Kuopio train (my camera that my stepson left on the way back was returned). That dang thing never actually worked. That made me get off my butt and buy a new phone. My crackberry never worked. It crashed on the way home on the day I bought it, but I figured that was an update or something (which crashed my previous phone on its first startup without fail), but that dang thing crashed randomly all the time and often times without switching to the JVM error screen so that I didn't know it had crashed.

I thought about buying an iPhone, but I just don't want to be associated with those suckers, besides I was mad at Apple for disabling my MacBookPro from running Linux (this I fixed). Frankly Apple's advertising annoys me. I'm beyond caring about being cool. I leave being cool to emaciated 20 year olds that shop at the GAP. If I want to be that cool I'll buy my own 20 year old to do it for me, sheesh....two if I want to be doublekool. I also resent locked phones. Like I want to pay some ridiculous amount to use my phone abroad. No way dude, I'm buying a pay as I go GSM card so bite me! There is also my theory that the reason my MBP runs so hot is that Steve Jobs wants to solidify his position as Alpha male...

I didn't really think about another Blackberry. As much as I wanted to get Meldware working with it, I had enough time getting the freaking Internet to work with it. No cool telnet or ssh or whatever! All the dreams I had about checking server logs from the train never came true. So that was out. (if you don't have a dud then it should work with IMAP)

Instead I walked into the Palm store while I was in the Atlanta airport with time to kill and saw a bunch of phones that weren't locked for relatively little. With a 30 day no-risk return policy, I was doing that. The only problem was that Versa Mail was a piece of crap. It insisted on loading THE ENTIRE MAILBOX INTO RAM and thus threw an OOME since my mailbox is a few gigs over the 8mb. Today while waiting for Billy (12) to get a turn at the soccer ball, I downloaded another app and it worked with Meldware right off. I was pleased. It even let me decide not to download my whole mailbox but stick to newer mails (essential cause it couldn't hold it). The only problem is that a certain open source diva sends email in embedded apple-encoded mime format which it doesn't seem to like much.

Now I just have to find a better calendar app for it.

Technorati Tags: palm mobile meldware apple iPhone open source

I've been appointed as a board observer for OSI. To be clear, I do not back away from my earlier statements, I've just been called to help do something productive with them. While I'm only an observer, my goals continue to be:

• encourage and pursue an opening of OSI's board and processes and general transparency
• encourage accountability for board members and their delegates
• pursue some form of representative voting for electing board members and officers

Meanwhile, Microsoft has submitted the "Microsoft Permissive License" and the Microsoft Public License for approval. These are pretty short and well-written licenses and on their face look like the MPL and BSD licenses that they were fashioned after with the added benefit of patent terminations similar to those in the Apache and Gnu Public License. The only semi-credible technical objection I've seen are mainly that Microsoft isn't giving an explicit trademark license regarding that license name itself. However, if I understand correctly this exemption is granted by US trademark law . The same exemption covers book titles. For instance I can call a book "Professional JBoss Development", without trademark license because trademark law in the US and other countries permits this and thus it does not need to be explicitly granted. I would assume that I can make non-commercial statements like "License: Microsoft Public License" so long as I don't misuse the trademark deceptively. I'd assume that titling our software "Microsoft Public License Meldware" would run afoul (speaking purely hypothetically we do not use MsPL, we use LGPL) where noting that the software is released under the license as a factual statement on a webpage would not.

Less credible objections, in my opinion include those that Microsoft is collectively a "poopy-head". I think a potential one is that these are kind of "vanity licenses"; however, I think that the benefit of approval outweighs this. Basically Microsoft participating in open source and SCO's defeat means that we have won Saratoga. there is always a threat of "Embrace, Extend and Extinguish" but engagement (China) has shown more general success than estrangement (Cuba). Especially given the relative sizes of Open Source vs Microsoft/non-Open Source.

Still to win the ideological war, so to speak, OSI needs to continue to move in the direction of openness, accountability and representation (including representing more working slobs and less of the "gentry") in order to lend to its own legitimacy. I think there is a genuine desire to do so, albeit it is some ways off. The "silent majority" may not be saying anything, but they haven't been asked anything either.

At todays meeting I mostly just asked that the last meeting's minutes be approved and published. Guess what my main issue will be at the next meeting? Ultimately, the point is that secrecy is not the default state but a special circumstance that can be called for when needed. To represent all of open source....you must be open.

Meanwhile in the more mundane department of "get things done" OSI has posted the "Mr. Execution" position. Think of the OSI board as Picard, and the Program Manager as Riker. The board is to say "Number One, Engage." and he's supposed to "Make it so".

Technorati Tags: OSI open source Microsoft

So after my macbook pro fried (which is also a large part of why I haven't been on), I sent it back to get it repaired. It came back and OS X boots fine but Ubuntu won't boot, even off of a CD (I suspect there is still a hardware problem but doubt they'll fix it 'because Linux won't boot anymore'). In the meantime I got a Toshiba which has all Intel graphics, etc and an atheros card (although I have to use the ndiswrapper until they finish up support for N cards). I'll probably give it to my stepson and use my new Toshiba instead. It has however marginally inferior resolution :-(.

Meanwhile I'm working on something cool for Meldware (that I kid you not no less than 12 people IM'd me)...stay tuned to find out what :-). As for Yahoo buying Zimbra. I'm so happy. I was afraid we'd have a real competitor eventually in Zimbra once they abandoned their "Open Source is the toy version, please buy the Man's version" model (inevitable). Now...they'll end up like most other "we acquired something outside our core business model". So it is how it is meant to be -- ultimately -- Us vs Exchange.

A few months ago I was at LugRadio Live where I attended a talk by Michael Sparks from the Kamaelia project. Kamaelia is a python-based component framework for building concurrent applications. The core of the Kamaelia system is called Axon. The main concept of Axon is the Microprocess. A Microprocess is simply a class that implements a generator method. For those unfamiliar with Python, generators are Coroutines, i.e. a method where instead of executing and returning a value when called, it returns an object that can generate values. For example the following code will print 3 integers 1, 2 then 3.

def generate_ints(N):
    for i in range(N):
        yield i

gen = generate_ints(3)
print(gen.next())
print(gen.next())
print(gen.next())

The interesting part of this is that each time the next method is called control is returned back to just after where the last yield was called, restoring the state of all of the local variables. It is this feature that Axon exploits to implement its concurrent behaviour. In some ways its reminiscent of Java's green threads or SEDA

One thing that really stood out about Axon, is the getting started tutorial doesn't go through contrived use cases for the framework. Instead it starts with a tutorial that walks you through building cut down implementation of the framework. By implementing the system from the ground up (albeit a very cut down one), you get a much better understanding of the system when it comes to using it. It also demonstrates that the system is built on simple clear concepts.

One of the goals for Kamaelia was to support scalable network servers (although it is much more broadly applicable), which is interesting for implementing a mail server. I decided to run through the Mini-Axon tutorial but implementing it in Java rather than Python. The first issue is that Java does not support Coroutines. It is possible to simulate the behaviour by using an inner class that stores all state as fields rather than local variables. This was the basis for my initial implementation, but the implementation was clunky and intelligent. I then stumbled upon a library called Yielder. Yielder provides Coroutines through byte code manipulation of class files. To implement the above Python example in Java:

Iterable<Integer> gen = new Yielder<Integer>() {
    public void yieldNextCore() {
        for (int i = 1; i <= 3; i++) {
            yieldReturn(i);
        }
    }
}
Iterator<Integer> i = gen.iterator();
i.next();
i.next();
i.next();

To allow this behaviour the '-javaagent=lib/yielder.jar' is required so that subclasses of the Yielder class can be identified and modified. To implement Mini-Axon using Yielder a Microprocess is a direct subclass of the Yielder. The next most important class in the Axon framework is the Component. Functional areas of an application extend the Component class. In order to support safe concurrent applications Components behave according to a specific pattern, where each Component will have only a single reader or writer at one time. Each Component is initialised with a number of boxes (or queues, or buffers, or whichever term you prefer to use). In a typical situation, within the main method (yieldNextCore), the Component loops reading requests from its Inbox, processing them and writing responses to its Outbox. The Component should yield processing at an appropriate point during its execution. Components are not restricted to single inbox/outbox combinations. It is possible to implement aggregation or multicast by reading or writing from multiple boxes. Communication between Components is handled by wiring their boxes together. This can be done in a number of ways, a simple example is the a Postman which copies items from the outbox of one component into the inbox of another. It is also necessary to have a mechanism to actually run the components. This is handled by yet another Microprocess which can schedule the running of other Microprocesses.

Because everything in Axon is a Microprocess including scheduling components, there are all sorts of ways that Components can be wired together. It shows that the model that Axon uses is very flexible. I will probably do some experimentation with using Axon in Meldware. I am currently envisaging a solution using Apache MINA or Grizzly to generate events that would drive an Axon scheduler. The incoming data would be partitioned, either into commands (single text lines) or parts of a larger message request (e.g. the message part of an SMTP DATA command) and passed as messages between Components. Components would handle activities such as command parsing, retrieving mail data from the folders and the streaming the bodies of messages from the store. One of the trickier aspects of moving to an event based approach to building a system like Meldware is how transactions should be handled. Declarative transactions (such as those using in JBoss AOP) generally rely on a single thread processing the entire transaction. However if we want to move away from blocking I/O and use an event based approach, it will be necessary to have transactions that span multiple threads. To handle this case it looks like I will need to suspend and resume transactions manually via the JTA API. It should be possible to implement some sort of transactional Component that handles the suspension and resumption of transactions around the yield call. This class could be extended by Components that need transaction behaviour. How this would work with multiple components sharing the same transaction is something I still need to work through.

This is all still speculative. I am yet to implement any useful behaviour with my implementation of Axon, so I will see how it goes. There are still some bugs in the Yielder library (doesn't work with ecj and requires debug to be enabled), which I am working with the author of Yielder to resolve. If you are interested in the Java implementation of Axon it is available here.

I'm in Finland this week and Switzerland next week, but I wanted to point everyone to an interview that James Ward and I gave to the WebDevRadio podcast. James gave me his cold shortly before and I was feeling ornery that day so I may have implied that say a certain browser developer needs to get off of its behind....possibly not the one you think...

Technorati Tags: buni meldware webdevradio podcast open source flex flash ajax

Man, if you're not here in San Francisco around LinuxWorld...you are in a far quieter place with a lot fewer people carrying Apple LCD display boxes around. The Marriott SFO is packed and if you go downstairs to the lobby there is like a 24 hour cocktail party. In short, this place has been overrun by geeks and so I'm right at home. For various reasons, I had a few last minute fixes in time for my preso tomorrow, so I hadn't slept in 24 hours (BTW this means that Meldware's webmail actually has autocomplete support now for the embedded LDAP server...well at least in the HEAD ;-) ), because I had to fly Delta (which I avoid at great expense) which has the oldest most dilapidated planes and the most uncomfortable smallest seats. Thank god for room service. There is a pretty good article on some of the controversy surrounding LinuxWorld and some of the ideas behind the NGDC here and here if you missed it. I wish I could stay for more of the conference, but I've got a pretty wicked schedule this month with massive bouts of coding and talking to prospective customers and a trip to Europe in a few days so I'm here today, speaking tomorrow and flying out right after. Being around this much energy, it is hard not to be sucked in (and I normally hate these things) and feel like I'll really be missing something.

Technorati Tags: meldware linuxworld buni open source ngdc next generation datacenter virtualization conferences

Another month has gone by since I posted about the Apache-JCP situation. Sun has added "Field Of Use" (FOU) restrictions to the licensing terms of the TCK for Apache Harmony. The situation has implications well outside of Harmony which is rendered somewhat less important by Sun's partial open sourcing of the JDK (portions are covered by a proprietary license. Running and passing the TCK (also known as CTK and various other names) is required in order to have the right to distribute implementations of JCP specifications with regards to patent licenses. Moreover passage is required in order to call your implementation "EJB3" or "Java Servlet" container, for instance. This has brought up the question as to whether a standard developed under NDA, with a proprietary/closed TCK is really an "open standard". The FOU restrictions that Sun is requiring would mean Apache's software would need to be distributed under a different license that would not meet the definition of open source. Since I wrote last, Apache has not decided to do anything of substance other than vote negatively protesting that Sun is in violation of the JSPA and should therefore not be able to lead specs in their Java Community Process (JCP) standardization committee. This move has been seen as ineffective and possibly embarrassing by a number of members inside and outside of Apache especially since Apache is alone in its negative vote.

A boycott, or no show, of the JCP seems a more dignified approach. I'm an ASF supporter and agree with you on the underlying issue, but voting no on the merits of a JSR because of your issues with the JCP in general seems childish to me also.

Matt Giacomini, TSS commenter

Some at Apache have called for Apache to sue Sun, which for various reasons. I made an alternate proposal that if Apache is unwilling to withdraw from the JCP, it should create a new project for not-quite-open-source at Apache such as http://sharedsource.apache.org. However, this admittedly somewhat of a modest proposal was not taken seriously. While Sam Ruby continued to express a need for action, Geir Magnusson, speaking for the de facto if not de jure power base at Apache, expressed more of his infinite patience and outright ignored Sam Ruby's call for an "exit strategy".

I think that our participation in the JCP is beneficial, assuming we get this problem w/ Sun squared away. Our years of engagement have shown that, IMO.

Our FOU problem is a big test for the JCP - will it be able to govern itself to the degree that it can?

Geir Magnusson, Jr.

Sun is busy on OpenJDK. Those that are waiting on Sun to provide us what the contract that they signed said that they would are also "blue in the face". This month, the conflict will enter into its second year. We are in a war without an exit strategy. As unpopular as it might be, we need to establish a timetable for withdrawal.

Sam Ruby

So I'd expect to see more "childish" "sandbox" votes on JSRs at least until the next Apache board is elected. However, the board elections have not, in the past, been an very effective measure for change. Moreover the Java side of Apache is fairly large by comparison to the open source side and individuals wishing to protect their positions on the JCP committees are unlikely to change the makeup of the board unless their Apache-JCP membership becomes a career problem for them. So...I'd expect many more months if not years of the same. In the future, I'd also caution you to investigate the exact legal propriety of the Apache project that you may use as Apache will not be labeling the project's entangling legal encumbrances (I actually was serious, preferring a properly labeled closed-source project at Apache to the current unlabeled stuff) nor negotiating them. For instance, if you run Harmony today you likely run awry, among others, of Kodak's patent on dynamic linking with objects that Sun licensed the other year. Yet there are no warnings that Apache has not obtained the licensing from Sun to distribute Harmony or that it is currently more likely shared source and not open source.

Technorati Tags: apache harmony sun jcp patents java open source

I won't be going to the AIR Bus tour. It hardly seems relevant since they don't really plan a Linux version any time soon -- and then only as an afterthought. I'm hoping instead to see if I can get one of the Moonlight developers to come talk to TriLUG.

Technorati Tags: adobe ria air silverlight moonlight mono linux open source