Aranea Blog

Todays online systems can be implemented in tons of technologies and they can be web 0.1 or web 3.0. There are some guidelines on how to do certain things.

Whenever you’ve given your username, email and a password to a site you can never know if the password was saved in plaintext or just a hash of it. If it was stored in plaintext you can think about the different security implications yourself. Whenever the password remainder sends you your password it was stored in plain text.

One more thing that systems should not do is store these passwords inside cookies in plain-text. See about Cross-site scripting from Wikipedia.

I was working on a project that was using WordPress as a CMS and there was a password protected todo list. As I was inspecting a cache issue I was checking the headers of static files with Firebug and I stumbled upon on some request/response fields. I noticed that one of the cookies had the password of the TODO item in plaintext.

I googled for it and found that it has been reported. The comment to the report is ‘Well it’s not like other sites can access the cookie or anything ’.

Whenever I use software that has been around for a while (at least a year) and it has a userspace I expect it to follow at least the most basic guidelines. I hope it gets fixed.

There has been some amount of discussion on the previous post. What was a bit surprising for me, is that a lot of people think that this isn’t really an issue for Java EE (they should really look at the comments here).

First of all let’s clear up some misunderstandings — we are talking about a development time approach, that allows to see the results of changes to code reflected instantly in the web application. This has nothing to do with production time hot swapping.

Secondly, nowadays compiling isn’t much of a bottleneck, since Eclipse (and similar IDEs) compile application incrementally on-the-fly. So the only thing we need is to actually reload this code in the JVM and we will get instant feedback that speeds up development.

Thirdly, web containers had for quite some time supported reloading classes while preserving the session state. However they do it by restarting the web application, which means all state outside the session (including business and persistence layer configuration, cache, stateful application-level services, compiled statements and so on) will be lost. To speak more specifically in a typical application based on Spring and Hibernate that is deployed to Weblogic (or Tomcat, or whatever else) such restart will take 30s to several minutes depending on the size of the application.

Now this is a really big issue — it means that averaging a restart every five minutes we get 96 restarts a day, which even 30s each gives us 48 minutes spent waiting for the application to reload. And the real numbers are even bigger, both because I chose optimistic numbers and because a developer who waits for a minute loses the context and might easily start reading Slashdot out of boredom. Thus companies are losing hell-of-a-lot of money on their developers just waiting for the application to restart.

So, to get back to the solution proposed in the original post. This was a way to get all of your web layer stuff to reload instantly. This by no means solves all problems, as the business and persistence layer are not covered by this approach. However since a lot of development happens in the web layer it does give a good boost to that (I don’t think I’d lie too much if I say that at least half of the restarts become unnecessary). Moreover there are some possibilities to get the rest of the stuff to reload as well, and Aranea team is working on them as well as some others.

Google Web Toolkit has captured the minds of many a web programmer around the globe with its promise to make AJAX web development easy. But how well does it deliver, and, more importantly, how much do we need that?

First of all a disclaimer — I find the Google Web Toolkit (GWT) sexy both as a developer and a framework architect. It’s a great piece of software, made by very talented people. The trouble is that sex appeal matters little in the field of enterprise software development. I mean custom-made software that has hundreds or thousands of use cases with complex interconnected business and GUI logic. This is the software that matters to the most of the programmers out there, as it is responsible for the most of the job places. And this is the kind of web application development I am going to talk about.

Let’s begin by summing up the innovation that GWT brought to the (Java) web development community:

• A Java-To-Javascript compiler with a java.lang API implementation — although the idea is great it is not exactly a new one. At least one more project (J2S) provides similar features and in fact provides a more advanced JavaScript generation facilities.
• A widget library that allows building UI without HTML. There are several similar efforts including Dojo, and the same J2S/RIA. Additionally there are several server-side frameworks that aim to provide the same functionality (e.g. Echo2, wingS)
• An RPC-over-HTTP implementation, which was available among others via DWR.
• A container that allows debugging the application in Java. J2S doesn’t really need it as it translates SWT/RCP code, which runs natively as a desktop application.
• Project kickoff scripts inspired by (or at least similar to) Ruby on Rails.

So Google basically went to this enormous trouble to reimplement all those available projects. Of course one can argue that they implemented a better designed, better working and better documented code (which frequently makes the difference between a successful and a failing project). But why didn’t they join the Eclipse project like countless others and lead the RCP/RIA stack?

My answer to this question is simple enough — Google wanted to solve their own problems. To understand GWT we need to understand Google motives in creating it. Google does not make business software — they make desktop software and put it on the web (e.g. GMail, Base, Spreadsheet, Calendar, etc). Such software has relatively few use cases, which usually are complex and must be very responsive.

Google needed a way to develop new applications for the web that would be

1. Highly responsive
2. Developed quickly
3. Sexy

The obstacle to the second goal was that to achieve a highly responsive GUI in web one needs to resort to a lot of hacks, and, what’s worse, to different hacks in different browsers. It is this issue that makes the development of an AJAX application cost much more than a usual one.

An obvious solution to this problem was to encapsulate the hacks behind a clean interface. A less obvious solution was to also encapsulate it in a statically typed language with a host of IDEs and debuggers and try to avoid JavaScript alltogether in the application itself. So GWT is a perfect solution to quickly develop AJAX desktop-like applications that will run on majority of browsers with considerably less testing.

But what about the rest of us (especially those who write large business applications)? My opinion is that it would be a great view technology, if it wasn’t based 100% on JavaScript. The problem with HTML and JavaScript is that there are at least 4 large incompatible implementations of the platform in the wild. We are talking about a language having 4 virtual machines that loosely correspond to a hindsight standard — James Gosling’s nightmare come true.

One of the main reason web is used so much for business applications is because it delivered on the Java promise to Write Once Run Anywhere (as web platform is much simpler than Java and less dependent on the client environment). And it also gave us the possibility of easy mashup, integration, retrofitting design, etc. But JavaScript makes this promise moot, browsers have:

• Restrictions on the size of the script
• Restrictions on the script memory consumption
• Restrictions on the running time of the script
• Cross domain access restrictions
• And a horde of other arbitrary restrictions, bugs and incompatibilities sent by Satan to torture web programmers

All of this means that you can only encapsulate so much — sooner or later some more resilient bug will crawl up or you’ll need to do more than possible with the standard toolkit and you’ll have to resort to JavaScript hacking. In fact I can almost promise that in any sufficiently large and complex application this will be rather sooner than later (and I mean bugs like memory leaks, which are next to impossible to debug on this platform). Indeed, HTML and HTTP were never meant for applications, they were developed to share knowledge among scientists. And although later the dynamic DOM, CSS, XML and other abbreviations were added on top of it they fit almost as well as a saddle on a cow — one can ride, but one doesn’t get very far.

Now let’s switch for a moment from AJAX to the business applications themselves. A typical large enterprise application has different UI requirements than a typical desktop one. Business application GUIs have large complex workflows, but only small part of them need to be highly responsive (typically some kind of lookup or searching). These requirements are easily satisfied with HTML and a little browser independent JavaScript slapped on. In fact if we examine what business customers want it is the software that

• Fits their needs
• Can be made quickly and for a reasonably price
• Does not tie them to a single vendor or partner
• Can be integrated with other software easily

It is badly analyzed software that plagues the business world, not the non-AJAX one. And it is high productivity and integration that is first of all needed from a web framework — perhaps this is one of the reasons why Struts is still so popular (the main being of course tons of legacy code written in it). And AJAX, if anything, makes integration harder and decreases productivity.

But does that mean that I am propagating simple web applications forever? Of course, not! I just think that simulating the desktop while depending on Intenet Exporer is something that a business client just can’t afford. Make already a normal rich GUI platform and I’ll be the first one to get on that train. Get Eclipse RCP polished or compile Java to Adobe Flash (which is at least a stable platform), perhaps even get Avalon to run on Linux. Just give me something that lets me write code in Java and doesn’t give me more trouble than web and I’ll sign on without another question.

So will Google Web Toolkit matter for the next years? I sure hope not, since this would mean that we build our next-generation applications on an intrinsically sabotaged platform. And no matter for my bias, I really want to see a better platform before the end of this decade.

JSF and Portlets promised to integrate the web, but in reality they just brought more confusion and lock-in. One of the main Aranea goals is to provide a viable lightweight alternative for web integration.

JSF promise was to be able to reuse web components among different frameworks that correspond to one standard. However the standard, as always, have left more things open than specified, and in reality we didn’t even come near to actually reusing components between frameworks (try using ICEFaces components with ADFFaces). What’s worse, JSF have imposed on us a highly complex and clumsy API, that one needs to follow to achieve even a little reusability and broke the familiar way of capturing logic in custom JSP tags.

While third-party options (like Facelets) do make programming with JSF easier, one still has to jump through hoops just to get simple reusable components. And since the components are not really Java objects, there is almost no good way to enforce a normal contract for their communication.

The trouble is that we already have a great tool for building and integrating disparate components—it is called the Java programming language. Object-oriented design have been proven to be a viable solution for already two decades, and it is just sad to see that the designers of JSF have ignored it to pursue type unsafe and hard to debug design that looks more than a bit like Struts, revisited.

Which brings us to our second offender—Portlets. Although Portlets were the first to achieve actual remote integration among different web applications, they also did that with a model that is limiting in every way possible. There is almost no communication between portlets, there is no way to embed portlets in other portlets, and some of the worst aspects of servlets (like static configuration and global contexts) have been carbon copied to the portlet spec. However instead we get modes, window states, persistent store and user profiles, which don’t have much to do with the integration itself and should really have been provided on top of that and not all in one spec.

In my mind these specifications share the same trouble as the infamous EJBs:

• They are designed by a committee
• They are not standardizing something existing, but creating a new solution on paper
• They are designed largely by and for tool makers, instead of developers

Now, selling tools is a great goal for those of us who make them. But tool-oriented specifications have insofar turned out to be less than successful. The EJB world is rapidly moving towards lightweight solutions like Spring and Hibernate, which instead of providing shiny tool support have a simple and clean design and just do their job well. The developers became so bitter from the tools, mappings and bytecode postprocessing, that Plain Old Java Objects became a buzzword that sells considerably better than MDA.

Now the situation is rapidly improving in the application server ecosystem, and with EJB 3.0 being a mix of Spring and Hibernate with a healthy dose of annotations, we are definitely looking to a brighter future (though the point of the rubber stamping perfectly good open source frameworks as a standard is still unclear to me).

However the situation in the web framework ecosystem is yet to achieve the same level of enlightenment. Currently we are looking at a large number of incompatible web frameworks that kill any hope of integration and reuse even before it appears. Many of these frameworks are really innovative (Wicket, Tapestry, RIFE come to mind and Seaside deserves an honorable mention), but there is no way to use their strength without also accepting their weaknesses.

It is our belief that different approaches are needed for different types of web applications. For example blog engines do well with a REST semantics, while complex enterprize applications do better with a component semantics and in some other cases one needs differently proportioned mix of the two or something altogether different. Aranea goal is to capture different types of these semantics in a simple and clean component model:

• Services capture REST semantics
• Widgets capture stateful component semantics

However to become actually useful you also need to connect the two, so we have Components that are a supertype of both and capture component lifecycle, communication and hierarchy. As a result we get a lightweight implementation of the Hierarchical Model-View-Controller pattern that allows to actually use both approaches at the same time.

What’s more, since service and widgets capture the essence of their semantics they should allow to host similar constructions from different web frameworks providing an interoperability layer with a simple and clean API (widget interface has 4 meaningful methods not counting the 4 more lifecycle ones and does not need any configuration). It is indeed our intention that the minimalistic Aranea core would be usable to integrate together different web frameworks, allowing to seamlessly use them together in one application combining (to some extent) different approaches when needed.

Next to that goal it becomes relatively simple to just reuse components between applications a la JSF or combine several subapplications into one a la Portlets. Remote integration is trickier, but it shouldn’t be too hard to host portlets or provide a WSRP adaptor.

Although we still have to talk in future tense about integrating the open source web frameworks (and possibly JSF), we have already achieved a lot of reusability and integration in terms inside and between applications, as well as with an internal legacy web framework. We hope that it will go just as smoothly with the other frameworks and we will be able to deliver on the JSF and Portlet promise.