A while ago I wrote a post about tagging. I was arguing that even if tagging was the buzzword du-jour when it came to Web 2.0 (another big buzzword) it had its limitations. Today I decided to compare it against the other Web 2.0 stalwart: HTML links. I decided to see which technique is better at creating relations between web-pages. Well, tagging is up to quite an opponent and doesn’t really live up to the fight.

Tagging’s first problem is that it has a very low cost: pretty much everybody can assign a tag to every type of content, it will cost you just a few seconds. This low entry cost makes it prone to abuse and/or careless use (I think careless use is a lot more prone than abuse)*. Linking, on the other side, is a very expensive operation: among other things it carries a pretty big risk (the risk of driving people away from your site) and is limited by the real estate of your page (you can fit only so many links on your page, this generates competition between links). This high cost of linking results in relationships of higher quality (when you pay a higher price you usually check the goods a lot more).

Another problem with tagging is that it enables very simple relationships between pages. Basically, all the pages tagged “California” are created equal. You may refine the “California” set into sub-sets (let’s say “Los Angeles”, “San Francisco” which can be refined themselves) but you don’t get very far, more often than not you end up with a pretty short and thick tree (the length of the tree is the number of common attributes and its width is the number of web-pages sharing these attributes). Linking, on the other side, results in very complex graphs which are a gold-mine to who knows how to exploit them (just think of how much money has Google made out of PageRank). The relationships between pages is much more complex when you link them rather than when you tag them.
* I actually have a problem because of this low cost. I have been maintaining a collection of bookmarks on del.icio.us which is categorized by tagging for the last year or so. The low cost of tagging URLs has resulted in a lot of URLs being tagged incorrectly because I didn’t realize that over time these tags will add up pretty quickly. Right now I have quite a few tags that I’m trying to get rid of, but it’s not too easy. BTW, del.icio.us’s functionality is very limited.

And this concludes this post…

Lately I have been involved in some extensive reverse-engineering, I needed to talk to a system and the guy who wrote it wasn’t there. What I learned is that it pays off to think of the other system as a series of blocks that you use in order to achieve what you need to. Thinking about the system in terms of functionality rather than programming paradigms helps you navigate between a system’s components and make better choices about which component is liable to service what request. You should choose the granularity of your knowledge of the system and decide what you find interesting and what not. Actually, you should take a view as “high-level” as possible and try not to get caught in small items (which is not always possible).
The good thing about this approach is that you are in control of it: you choose how deep to go in order to achieve your results. In some cases you may go as deep as an interface’s contract, in other cases you may need to go all the way to the database.

I really needed one thing today: inheritance between managed beans. Well, I didn’t find out how to implement it. I basically needed one managed bean (let’s say PersonList which has a List persons) to share its persons with another managed bean MortgagePersonList which subclasses PersonList and uses the persons List put together by PersonList during processing.

Java code:
public class PersonList{

protected List persons;
// some methods for manipulating persons (sounds pretty Orwellian, I know ;-))
}
public class MortgagePersonList extends PersonList{

// re-submits their mortgages application
public String resubmitMortages();

}

JSF code:

<!– set-up the PersonList managed bean –>

<managed-bean>

<managed-bean-name>personList</managed-bean-name>

<managed-bean-class>com.PersonList</managed-bean-class>

<managed-bean-scope>session</managed-bean-scope>

</managed-bean>

<!– set-up the MortgagePersonList managed bean –>

<managed-bean>

<managed-bean-name>mortgagePersonList</managed-bean-name>

<managed-bean-class>com.MortgagePersonList</managed-bean-class>

<managed-bean-scope>session</managed-bean-scope>

</managed-bean>
I was expecting that I could inherit one managed bean from another so that I could re-use the persons List transparently. No such luck. So I was left with saving the persons List in the Session in the PersonList bean and retrieving it from the Session in the MortgagePersonList object. I thought that I could use an environment-independent Session object, the only one that I could retrieve via FacesContext.getCurrentInstance().getExternalContext().getSession(false) was actually an Object which has to be cast down to HttpSession. It is pretty weird that the ExternalContext is modeled similarly to HttpServletRequest (just look at getRequestParameterMap, getRequestParameterNames, getRequestPathInfo, getRequestServletPath), it speaks a bit about JSF’s environment independence. It would be interesting to know the reasons behind not developing environment independent sessions (getSession should return an interface specifying the contract for a session and not an Object which can be cast down to a specific implementation like HttpSession), this could help when implementing dialogs.
One other thing that I hate about JSF is the amount of informal specifications, you know the fact that if your managed bean controller is returning a String than you should map that String to a navigation case and so on. It is pathetic, it would have been much better if this functionality would have been specified in a more rigorous way like defining it in an interface. But it looks like Sun didn’t feel quite up to the task of spec-ing out the user interaction (this is what JSP should be all about).
I really like the abstraction layer they created but it looks like it was fully finished. My 2 cents.

I’ll take a break from writing over here. I’m pretty busy and I don’t get much sleep, all this adds up. I’ll get back to writing somewhat later, when I’ll have more time.

… then you may want to read this, this, and this. They are pretty entertaining and miles away from the Web2.0, YouTube vs. Hollywood, Media 2.0, Content 2.0 stuff that keeps stuffing your feed readers. Some nice thought experiments, nothing more…

I can’t believe how much spam I’m getting lately, hundreds of spam messages daily. I try my best to scan it for valid comments, but there is a chance that some will slip by.
Sorry about it…

I was reading this post by Rod Johnson on the Interface 21 blog about Oracle Application Server and Spring when I came across this quote:
Because Spring provides a rich, portable transaction abstraction, it does the work under the covers of driving JTA and other APIs, so your code doesn’t need to know anything about the underlying infrastructure, and thus can take advantage of any proprietary APIs that give more control or greater efficiency. Spring supports both declarative and programmatic transactions, so you can layer transaction management onto POJOs that don’t know anything about it; or, if transaction management is part of your business logic, you can use a more elegant API that offers more features than JTA (*), isn’t tied to JNDI, and is much less verbose to work with.

Wow. Does this mean that Spring’s transaction semantics are starting to compete with JEE’s transaction semantics for mind-share, and ultimately, market share? In what DSL (**) should you model your transactions: the old way by declaring them in ejb-jar.xml or Spring’s way by declaring them in spring-conf.xml? Is there a danger that one of these languages will become obsolete? Is there a danger that the current transaction semantics in Spring could be forked in order to better utilize a specific app-server’s capabilities? Is there a danger that these new transaction semantics be irreconcilable with the ones in the next Spring version?

In an earlier post I likened the transparent container’s capabilities to LISP’s, particularly when it comes to defining new languages (**). Well, the transparent container may inherit one bad thing from LISP: language mush-rooming. LISP diverged into so many dialects that it became eventually impossible to use as a common platform. More and more DSLs could be created for various use cases, which will range from the very specific to the very generic. I think this is probably where the effort will lie in the future, in managing all these DSLs, in separating specificity from generic behavior in an efficient manner. The future announces itself to be pretty messy…

* It is an interesting exercise to muse on Spring’s lead in TX APIs. If the features they advertise are needed - and I think they are needed and, even more, they are tested by the market - you would expect the JTA people to include them in their spec, after all the spec would be missing good functionality which should be included. If the JEE body will not include these features it will pretty much admit to being irrelevant in this particular area and would be handing the baton to the Spring people. Or maybe the JEE body doesn’t see these features as being generic enough or not having broad appeal. Who knows…

** Spring 2.0 was released with this nifty feature: XML namespaces. This opens the door to defining your own specialized languages (let’s call it a Domain Specific Language, DSL) tailored to your needs and plugging them into Spring’s runtime.

I was reading this article in Business Week on a particular XML format (XBRL) for tagging financial information to various operations within a company so that it can be reported better. At first I wondered how this format will play out in the real world. Its main strong point is that it is a standard with some powerful backers behind it (the SEC is thinking about using it) which would make it well-suited for inter-firm communication. I wonder how it will play in the communication between various BUs within a company. It is not really transparent to attach functionality to an operation, you would rather delegate that functionality to a different system dedicated to it. Applying this new functionality (”reporting”) transparently would mean that an operation would get “reported” by an “reporting” system that would let it flow thru without any changes to it.
I don’t think that the approach of attaching some information to an operation in order to implement some functionality (reporting) scales well either: adding envelope 1 for functionality 1 and envelope 2 for functionality 2 and envelope 3 for functionality 3 at every processing point would generate a pretty thick envelope which at one point would dwarf the content itself.
Versioning could also pose some problems: if one systems tags information using the 2.1 version of the XBRL, another with the version 1.0 and you send it to an external party that is using version 3.0 and is not backward compatible you would probably have to reconcile all these tags to use the appropriate version, etc… Pretty ugly stuff…

Anyway, what really interested me in this article was that this was a new format in which Microsoft was involved. These guys seem to be doing pretty much everything to break out of the Windows/Office cage on which their company was built. You see MS pretty much all over the map when it comes to standards, you start wondering what they are doing in all these bodies. I would assume it is part of their strategy of breaking into the corporate world by being involved in how corporations communicate one with another. You could argue that if you control the communication channels between various systems you could actually sell MS-enabled endpoints to service these communication channels in order to gain some foothold in the corporate IT environment, but this is just speculation.
Couple the involvement in all these bodies with the fact that they seem somewhat serious about opening their organization to the outside world (in a very controlled manner as always), you could easily see Microsoft morphing into a brand new company.
It would be interesting to watch it unfold.

A while ago I wrote a post about a particular type of container that I called the transparent container (*), a container which basically binds various pieces of functionality to each other transparently.
Anyway, I was thinking today that this container exhibits features pretty close to LISP: easy binding between components, the ability to create languages pretty easily, dynamic typing to an extent, etc… I can hear a lot of people starting to complain that this is basically a new instance of reinventing the wheel, that we should all start developing in LISP in order to become more productive, etc… I think they are wrong, because there is one huge difference between this transparent container and LISP: the fact that you can isolate development between this LISP-style programming (programming in the container itself) and the regular Java programming (developing the beans that are bound together by the container developers). Which means that you can split your work-force much more efficiently according to what they do best: domain experts along with the architects would develop the application by binding it in the container, while the ‘regular’ (if you wish) developers would code the Java beans.
One strong point of the transparent container would be management: it lets you divide your tasks a lot more easily than LISP. In LISP you do not have a boundary which splits complexity, pretty much everybody is working in the same environment. If you don’t ‘get’ LISP you are pretty much an outsider, and getting LISP is pretty rare from what I remember in university. This container brings forward some of the powers of LISP and makes them available to a small team that is comfortable with this environment, it is a lot more flexible than the all-or-nothing proposition that LISP gives you.

* For however has any questions about the name, I picked it out of a hat. I need a name for it so I’ll call it this way. I could call it Spring, especially since Spring is the only container coming close to it, but I decided to go for an independent name.