Continuations

I've been reading this morning about continuations on the JVM (Java Virtual Machine). Gilad Bracha posted a blog entry a while back, when he was still at Sun Microsystems, about adding continuations to the JVM and why he didn't want to do it. The part that stuck out was:

The other important point is that the future of web apps is going to be different. Ajax is a sign of things to come (though it’s only a symptom, not a real solution - but that is another story). In time, entire applications will be downloaded and provide a full GUI in the context of a single page. The primitive dialog we see today will return to the ash heap of history where it belongs.

I completely agree (and I can safely assume James does as well) on this point. Every time I look at modern web frameworks they are either in one of two camps:

1. Sessionless
2. Continuation based

The reason is that HTTP is not stateful AND HTML is not a language AND the browser doesn't inform JavaScript about every action a user takes (i.e. back button or new window or new tab). All of these conditions mean that you need to either hit the database every request and never keep anything in the session, or create multiple sessions for each window, tab, etc.

IAP and IAL address the problem that Gilad describes. IAP has the concept of state built into it. It is not connection-based entirely, but has concepts of connection-based protocols inside IAP transactions. However, it still maintains the concept of session within the protocol.

Second, IAP defines a simple principle of ultimate idempotence. Every time you request a view (HTML file is the HTTP equivalent) with a specific version (HTTP doesn't have versioning) it must be the same byte for byte. This rule means that views cannot be generated on the server. A view is the code that generates the GUI. It would be as if you were passing back to the browser the JSP file. This concept has wide spread effects but the main effect is that the server is no longer managing all the state. Instead the browser now manages state because when it executes the view code to create the GUI it must return to the server to request data for that view. That data is downloaded and then managed by the browser and can be manipulated client side without requiring requests to the server.

Lastly, IAP defines a requirement for languages built on top of it that any and all actions the user performs must be handled first by the view code running in the browser. This is a no surprises approach in that the browser cannot do something that would surprise the code on the server or the client. This means that if a user opens a new window or tab the application is the first to know. From there the application can decide how best to allow the user to control two windows into the same application.

In the end, continuations will not be needed on servers that run IAP and IAL. Instead, if anything, IAL could benefit from continuations by making multiple client side sessions simple to manage. Whether or not we will be adding continuations is still open for discussion, but the fact that they are not required on the server is a step in the right direction.

IAP and NexaWeb

I got a call from someone that I know over at NexaWeb and we got to talking about how and what NexaWeb is doing. I knew a little bit about their technology but nothing concrete. He sent me a link to their development portal so that I could take a look. I had a few quick thoughts about their approach overall.

• It seems that they are leveraging two technologies for rich client apps, Java applets and JavaScript (AJAX)
• They appear to have their own XML based protocol and at least for the AJAX approach this appears to be marshaled over HTTP.
• The UI declaration appears to be in XML

NexaWeb has built a good system it seems to work with existing infrastructure and not try to hassle with firewalls. IAP definitely takes a very different approach and I think this is valuable for a few reasons.

• IAP conversations reuse the same connection, which is somewhat the same as HTTP keep-alive, but clearly defines a transaction boundary between the client and server.
• Java applets allow multitudes of flexibility to the application once it has been delivered to the client, but support for Java applets on Microsoft operating systems looks doomed and a simplification of the language and UI construction seems ideal, not to mention that there should be no barriers to taking the next logical step into 3D UIs with IAL, which is difficult with Java applets unless a modern JDK is present with full Java 3D or JOGL libraries installed.
  
• IAP is binary all the way to the headers. No XML parsing, marshaling, conversion, anything. This means fast.
• IAP has a uniform security model for authentication except for SSL/TLS. The XML/HTTP based protcols have many layers including SSL/TLS, HTTP, and application specific within the XML.
• IAL will be a compiled language that is either a DSL or 4-generation type of language. XML is difficult to use when logic becomes complex and the key here is to move the UI logic from the server to the client.

One more quick thought about IAL, I believe that thin and powerless clients are the things of the past. Hand-held devices now contains more storage and processing power of the main platforms HTTP/HTML was specifically design for. Therefore, moving portions of the logic from the server to the client seems like the natural evolution of Internet technology. IAP and IAL are specifically design to be the next evolutionary step.

Welcome

This blog was created by the development team for IAP and IAL to share our thoughts about the web and how we are working to change it. For those that don't know about these technologies, IAP and IAL are revolutionary web technologies aimed at changing the face of the web. They are acronyms:

I.A.P. = Internet Application Protocol
I.A.L. = Internet Application Language

IAP is currently available as a early access draft specification and has nearly 2 years of development and research behind it. It is still being worked on and we have lots of new ideas about the direction for this specification.

IAL is still just ideas in our heads. We are looking to start formalizing these ideas here and then start working on the specification.