Thoughts of an IT professional

I developed some components that interacted with the server in an AJAX-like manner (posting to a servlet, registering a callback function that would process the output from the server). I ran into a few issues and spent some time thinking about AJAX development.

I noticed some tight-coupling for calls that returns HTML content which has Javascript due to not loading of JS libraries retrieved via AJAX. Some calls were getting some HTML content that required JS libraries for launching popups or DHTML manipulation. The HTML content came with the required JS libraries but the browser (IE 6) was not loading these libraries. As a result the calling page had to load the libraries that were used by the HTML content retrieved thru AJAX.
I didn’t like this because I wanted to be able to encapsulate my component in some form, shape or manner and then have it used without having to determine how are these components coupled and enforcing this coupling. It looks like at the current stage of development component encapsulation is not implemented in AJAX.
One problem this causes is that the component’s future development is pinned. You cannot add more functionality to it because the JS libraries which will implement this functionality will have to be imported in the pages using the AJAX component. You will have to document the dependencies between the AJAX component and the pages calling it, reload the libraries in the dependent pages and re-test them. Big effort…
Note: There is a work-around: getting the JS libraries and adding them to the document in a <script> tag. This would cause the browser to parse the JS required by the component. However this would require 2 calls: one to get the libraries, add them to the document in a <script> tag and another one to pull the component that uses these libs.
Also, it is possible that future browsers will determine if JS libraries are retrieved thru an AJAX call and parse them.

The concept of application on one page is a bit flawed. The problems posed by a browser’s refresh button will add to the problems of the back button and so on. The current AJAX client is missing some important functionality (it is not transactional for example) and probably due to the variety of JS implementations in browsers it will always miss this functionality. Drawing a boundary between what logic falls on the client and what falls on the server is an extra effort. App versioning and the browser’s JS cache pose some interesting problems too.

I wonder what will happen to an application written in AJAX and to its code base once W3C will put out HTML 4.01 (which among other things will separate the data from presentation and style)? Will these apps suddenly become obsolete? Probably yes.

The biggest drawback of AJAX is that AJAX is currently under-developed. Everything revolves around the return status of the http request. There are some libraries out there (such as DWR – Direct Web Remoting) and some frameworks are being developed but otherwise AJAX is under-developed. The plumbing is being developed by ear for now. It is possible that Microsoft will come out with their own plumbing for asynchronous client-server communication. It is likely the W3C will expand this technology as well. The danger that your current code base will grow obsolete is great. The danger that various independent AJAX implementations will emerge and require developers to code to 2 different implementations is also pretty big. Anyone remembers the Netscape-vs-IE wars?

The asynchronous nature of AJAX may pose some problems. Some ramp-up time is required for developing at ease in an asynchronous environment if you have not had to deal with asynchronous applications.

My opinion is that currently AJAX is pretty good for small tasks pertaining to presentation. Let’s say you have a result set presented in a list and you want to display detailed information about an object in that list without refreshing the page. You could do it in AJAX. You could share various presentation objects across a site with AJAX as well.
What you should probably not be doing right now is embark on large-scale projects revolving around this immature technology.

Cam asa arata o mare frectie

I am following the dynamic vs static debate and its by-product, the debate of Ruby vs Java, not really understanding what the fuss is all about.

I think we could say that the language used in the XML descriptors of a package using declarative programming (such as an EJB XML descriptor, a struts-config.xml or bean-definitions.xml for Spring) fits the definition of a dynamic language.
You can change the behavior at runtime, you can create new classes and call them from different points in your program, you can even pass invalid objects to your program and find out that your program is not working because you didn’t XML-program (I have to admit ‘XML-program’ is an atrocious name) it correctly.

Declarative programming and the descriptors that enforce the contracts specified declaratively could be viewed as the place where a Java app would act in a dynamic way. The language of the application would be Java + various XML descriptors rather than only Java and this language could be viewed as dynamic.

So far declarative programming has been used mostly for infrastructure (EJB, Struts, etc…) but it would be interesting to see what results if it is being used for describing an application. I am thinking particularly about organizations that write programs that have to be easily customizable (such as a B2C shopping cart, a content-management system, etc…). It would be a good thing if I could describe this application in a declarative way so that I could describe and incorporate a customized business-process easily into the application. My app would be changed dynamically, customized behaviour would be created and passed to the appropriate components, etc… It would be written in Java and described and assembled in XML descriptors. It would be dynamic.

For example when the user presses the submit order button on an e-commerce site I should be able to specify in a declarative fashion that the DB will get updated, the credit card will be charged and the back-office system will know to send the product to the user and ask for replenishment. I want to add this and other functionality and turn it on/off at run-time.

To go back to the debate of Ruby vs Java, I think that Ruby will not get much penetration into enterprise development. The reason is that by now a huge investment has been made in JEE applications, an investment of the size of a few millions line of code that have been developed and, more importantly, tested and debugged. Assuming that you need to add some dynamic behavior to your product you could do so by applying declarative programming to your existing code base rather than re-writing the application once more in the language that happens to be popular. The debate of Ruby vs Java is a non-debate, it debates the current Ruby development environment and Java’s development environment as it was 4-5 years ago, i.e. Java running on its own. However, today most applications written in Java are usually run in some container that allows for loading behavior dynamically. Ruby vs Java + some frameworks would seem a more rational debate, however I have not seen anyone taking part in it.

Un mare meserias

One big difference between Spring’s proxy-based AOP implementation (referenced from now on as Spring AOP) and annotation-based AOP is the fact the Spring AOP declares the advices outside of the code while annotations declare the advice in the code. This causes some side effects:

1) Spring AOP lets you apply different behavior to the same class in different instances (actually you can do this in the same instance). It would be possible to download an open-source JEE application (such as a B2C shopping cart) and customize it without changing code resulting in different instances of the same app. For example, you would be able to declare that various steps in the checkout are transactional, apply different security requirements from instance to instance without changing the downloaded code.

2) The fact that annotation-based AOP binds behavior to code implies some development coupling: you have to develop or at least design the advice before you develop the class being advised. Ideally you would develop the advice independent of the code it gets applied to.

3) Annotation-based AOP creates horizontal relationships between classes that are very hard to change. All the classes sharing the same advice are tied together. Suppose that you have a Transaction annotation applied to you account manager, user signup manager and checkout manager. It would be very hard (and would require quite a lot of code-juggling) to change the app so that only your checkout process is transactional. These horizontal relationships (which as far as I know have not been integrated into modeling tools) should probably not exist at the code level, but at the application-deployment level. Cross-functional behavior should probably be applied at deployment time when the user’s requirements are ready to be implemented.

4) Annotations may degrade portability. One example would be the core EJB3 annotations for persistence. These annotations are platform independent since they are part of the EJB3 spec, however, these annotations are probably insufficient for real-life deployment because they do not allow for application tuning (such as data caching for example). In order to add caching to an EJB we would probably have to add server-specific annotations, and these server-specific annotations ruin the portability between application servers. With Spring AOP we could write an aspect that would piggy-back on the server-specific cache and advise the DAO with this aspect at deployment time. We could change the cache pretty easily by creating a new aspect for a different cache and advise the DAO with this aspect at deployment time.

5) Spring AOP creates a new role in the product’s life-cycle: the application assembler role. This role (probably best fulfilled by a business analyst which has a relation with the customer) would allow for making the application more flexible to customer’s requirements. A business analyst should be able to look at an application, determine what type of behavior should be attached to, or detached from its various parts and attach or detach that behavior. Supposing that this behavior doesn’t exist the business analyst should be able to have it developed in an advice that is independent of the overall application and advise various parts of the application with this advise.

I think that Spring’s proxy-based AOP is a better proposition that AOP thru annotations. Annotations promote relationships that are hard-coded and unless are specified by the domain problem they should be better implemented outside of code.

Opa, hopa, Penelopa.