Later edit: A REST application is probably best used for distributed computing where various nodes talk to one another. In this scenario the concept of a REST client and a REST server doesn’t exist, basically the REST client is emerged in the network the REST server(s) are running. You cannot have an external (at least I don’t think so) REST client, the REST client is similar to a spider that goes from node to node carrying out certain actions at each node and finishes by becoming part of the network. I think it is for this reason that trying to connect an external system to a REST-network fails, because the external system is to intimately tied to the REST network that it finishes by becoming part of it.
Comments welcome!!

* I am not sure about this, please drop a comment if you want to talk about it.

Now, if we look at it from a “historical” point of view, the above doesn’t seem so bad for a first try. One cool thing about EJBs that resonates well with me is the fact that EJBs promoted the use of interfaces. One very good use of this would have been the abstraction of a business process behind interfaces, unfortunately this didn’t take off, most of the implementations were going the other way around, from concrete class to interface, XDoclet-style.
The “mistakes” that this operational environment made would be that it was advertised as “enterprise” and that it was too inclusive. Trying to address every issue important in enterprise computing on your first shot is prone to failure. The fact that this was done in a “democratic” fashion with each industry vendor pitching in his customers’ needs didn’t make defining the spec easier.

Some people look at EJBs as an abject failure. I look at it as the first step on the road to something new, a first step loaded with mistakes as all first steps are. Currently everything is running in a container, in a managed environment if you wish, which you get to define and tinker with if you wish. The lessons learned by working with EJBs provided valuable when the current successful containers were designed. It’s an evolution if anything else.

Let’s take an architect that spent the last 10 years architecting video games. It probably has its head filled with design patterns, UML diagrams, tricks, frameworks, etc… that enable it to do his job very well. Suppose that the same person is given the task of designing an application in the insurance industry. After collecting a mountain of use cases will it be able to see points of change in the application he’s building, will it be able to abstract the business process that it is implementing so that the application changes easily as the business process changes itself? I’d be surprised. That architect will go thru its collection of use cases and come up with a platform independent model and from it design the whole application. And he will probably fail to capture quite a few assumptions that the domain expert takes for granted and create a system that deviates from the original intent. It would have to adapt itself to the domain and then start to make some assumption about it in order to model it better.

UML can be used as a tool for communication between the business analysts and developers, but we should not expect too much from this tool. I think that the potential for errors and the noise is pretty big for this communication channel. Once things start to get complex these diagrams will not be able to translate efficiently the process described by the domain owners to the system architect. Instead of relying on various meetings with the business analysts, the architect should be able to understand the process, should be able to ask question meaningful to the business owners about the process that it is implementing and then it should start modeling it. It would help a lot if the business analysts would have some sort of a manual that distils the business and that the system architect can read before engaging with them.
I, for one, treat use cases and collaboration diagrams mostly as documentation needed for bringing a developer on board, rather than a way to pull information out of a domain.

As a final note I would say that the ability to adapt to a new environment is becoming a requirement for a developer. In order to be able for a developer to function efficiently across a wide array of industries that developer should learn how to adapt to a new business environment, and pretty easily. A developer should scratch beyond the surface of a industry in order to make meaningful decisions.

P.S. I’ll give an example from my experience.
I was designing an e-commerce application that had to support multiple customers and had to be industry-agnostic. What was the functionality that was most prone to change from one customer to another and which had to be abstracted first? Navigation? Layout? No. It was/is the prices. Every customer has its internal pricing structure (tiered, contract-based, rebates, etc…) that has to be reflected in the application. I learned it the hard-way, and it is a valuable lesson. When I designed a B2B application the first interface that I wrote was the interface for handling prices because this was one piece of functionality that I knew the customer cared about and that was prone to change. Do you think that this need ever transpired from the various interactions I had with the customers and various use cases I walked thru? No. The prices were the functionality that were the most prone to change and there was nothing out there to tell me that, most customers would assume that their price schema is what everyone is using. It was the interaction with quite a few customers that showed me that what is really prone to change is the pricing module.
P.P.S. In the above application the next thing that had to be abstracted was the interaction with their back-office systems, but it is a lot more obvious that it has to be abstracted.

I am more interested in RSS’s behavior and the way you could apply to various problems.
One of the first uses would be to use RSS for broadcasting events in a group. Let’s say that you are a MySpace user and want to send a message to a group of people. MySpace could broadcast the message to your group by using RSS: each group member would have access to the group’s feed and any member could write to this feed. The result would be that each member could send a message which is guaranteed to be received by the rest of the group as long as the RSS server is up. Setting up this messaging infrastructure in a web application could be as easy as getting an RSS AJAX client and mapping it to the appropriate feed.
Let’s go to some exotic uses of RSS. The fact that RSS is a platform-agnostic broadcasting protocol means that it could be used for managing the interactions between various services in an SOA environment. To go back to the tax example: you have to apply a service (taxation) across a wide array of applications deployed on different platforms in a financial institution. You could have each of these application broadcast events (such as a stock have been traded, a commodity has been bought or sold, etc…) in an RSS feed and the tax program would listen to all these events and take appropriate action. The messaging infrastructure would be pretty simple to implement on both sides, I assume that there are quite a few clients written for various platforms.
You could use it for pushing deltas in a cluster if guaranteed delivery is not mandatory. A company could consolidate its messaging infrastructure using RSS: the email client would be replaced with an RSS client that is mapped to a specific feed, various groupware software could work off RSS feeds.

Various client-server interaction could be implemented easily with RSS: I wrote a desktop application that had to connect to a server and get the latest updates for catalogs, accounts, etc… This could have been done very easily using RSS. The changes in a catalog would have been published in an RSS feed and the client would have just had to connect to this feed and get its updates. Gone is the proprietary protocol which cost me a few nights, instead you get a tried, tested and true RSS client and plug it in your application.
An anti-virus or a patch manager could get a list of the latest virus definitions or patches and their location in an RSS feed and proceed with installation based on the information published in the feed.

I don’t want to be misunderstood. I am not suggesting to gut out MOM and replace it with RSS, I’m suggesting to consider RSS when you need an infrastructure for passing messages with a certain reliability rather than build it in-house. You could have various parts of your application talking to each other literally in seconds. I hold the conviction that code-writing is an error-proce process which has to be minimized as much as possible. In order to do this we have to start thinking in processes, we have to look at various technologies in an open way, realize their potential and use it.

P.S. Along with the Web 2.0 buzz some sort of a revival in UI is taking place. It looks like interacting with users is being thought about again. Martin Fowler’s GUI Architectures is worth checking out.
P.P.S. When writing this I kept thinking about the launch of Google Talk and the spartan user interface it had at the time. I was wondering how would an user of this product find its various services if the interface was kept simple.
P3.S. This article is concerned with UI management on desktop applications. I think these UI management requirements apply to web-based products but the implementation would be very different. A web application would be transformed into a portal that is easily to be managed by the user. For example, I would like to go to Yahoo’s page and have in the upper right corner some stock quotes, next to them press releases or news about those stocks and in the middle of the page general news. When I’m planning my vacation I would like the middle of the page to be a list of various trip packages rather that the news I usually have. I would like to put up these components and shut them down very easily.

* As far as I know Eclipse’s plug-and-play architecture is intrusive, you have to implement various interfaces, etc… Using Eclipse as a skeleton for building desktop apps would couple your application strongly to Eclipse unless you abstract the interaction between your UI components and create a bridge which will be used for having Eclipse boot-strap your application’s UI. This way you could use other plugable UI frameworks, such as Firefox, for assembling your application’s UI.

In the words of late Peter Drucker: People tend to concentrate on the word "Technology" when faced with the term "Information Technology". It is time to concentrate on "Information".
It is time to do something with this information. Handling it has become a piece of cake.

P.S. A lot of open source usually stands for developing infrastructure software; think about Sendmail, various web-servers, application servers, etc… So when you see that whole applications are getting open-sourced (think CMS, shopping carts, catalogs, CRM, etc…) it is a good bet that these applications are actually infrastructure, that they are the building blocks for something bigger and more valuable. It means that while previously you were supposed to work at a very low-level with database tables, triggers and Java code, from now on you may have to work with whole application stacks. Of course, not all development will be like this, someone will have to create these applications. But more and more of the work will consists of integrating these applications in order to create something of value.

To give an example for the above ideas: let’s say that you have a client that connects to a web-service. One way to implement this would be to use a code-generator (such as the one supplied with Apache Axis) and generate the stubs that connect to this web-service. Well, it is possible that the web-service would change in the future. In order to adapt to this change easily you could generate the web-service connection classes in a super-class (that would implement the infrastructure) and create a sub-class that would be called from your application (that would implement the business-logic). Changes in the web-service would result in changes in the super-class (which is not used by your application) and would not require big refactoring on your application.
Once again, I am not a big fan of code-generation. I was using the above as an example of the benefits of separating infrastructure from business-logic. You could use this separation for implementing generic behavior in a Template for example, but it is important to notice this separation and enforce it.

One more thing. SOA is considered the domain of business analysts, the business analyst driving most of the interactions between different services and applications in an enterprise information system. Given the similarities between SOA and AOP it would seem that AOP would be best effective when the interactions between aspects (or services as they are known in SOA) and methods (or applications as they are known in SOA) are managed by business analysts rather than developers…
Good food for thought…

Later edit: I understand that currently the advices used mostly in AOP are concerned with infrastructure issues (concurrency, security, transactions, etc…). However, AOP leaves the door open to assembling applications so that you can bind a piece of functionality to another piece of functionality like the above example with taxes. In this case the usual pointcut semantics will probably not suffice (unless you use annotations) because the advices will not be applied to objects which are related by infrastructure issues (such as persistence or concurrency) and are grouped together by namespaces (such as package names), but rather to objects which are related by business-logic issues (such as manipulating funds). This grouping is probably harder to translate into pointcuts.
Anyway, I think the interesting development in AOP lies with applying advices because of business-logic affinity rather than because of infrastructure needs.

P.S. I wrote this post on the most horrible coffee I had in a long time. If it had an effect on the post itself I am sorry.
P.P.S. Separation of concerns resembles the division of labor as well.

P.S. The involvement of businesses in the creation and management of business-oriented JSRs benefits the IT corporations backing JEE a lot. The effort made by a business thru-out this process will translate in some form of a commitment to the JEE platform which would benefit the IT corporations involved and ultimately JEE. The JCP process could (and should) act as a communication channel between big-business and JEE.

CORBA is probably the first communication protocol that noticed the  variety of systems that were trying to communicate with each other and presented a solution to this problem. SOA is concerned at its foundation with this problem, but rather than solving it it assumes it is solved and moves on to determine what should happen once the systems do start communicating one with another.

Later edit: SAX is a parser really close to the metal begging to have some extension layered on top of it in order to make it more developer-friendly. The fact that no such extension exists or is not popular (I, for one, do not know of any) leads me to believe that SAX is not so widely used. Probably the reasons for which it was conceived (small memory footprint being the most important one) are not important anymore or the XML documents that are usually manipulated do not require a lot of resources.
Even later edit: It looks like the size of the XML documents and the number of formats grow pretty rapidly as SOA matures. A SAX-based OX mapper would not be a bad idea after all…

I have started my SCEA certification process and for the first exam I had to revisit the EJB architecture. I read EJB 2’s spec and at the end I was left in wonder. I could not believe that a corporation like SUN came out with such a spec.

The first (huge) surprise was the fact that there are interfaces that go against their contracts is a first (as far as I know) for SUN. For example, the MessageDrivenContext interface extends EJBContext and as a result it provides the MDB with access to its home. Except that an MDB has no access to a home since it is not referenced thru a home. Accessing the home thru a MessageDrivenContext would throw a system exception. I was in shock when I read this. You just have to wonder, what other methods are invalid in what interfaces? An API should provide a bullet-proof contract with no room for ‘buts’ or ‘maybes’. Well, this time SUN took a short-cut.

One thing that attracts developers to the so-called light frameworks is the fact that these frameworks do not make any assumptions about the applications getting built with them. Instead, they provide a way to assemble applications and bind behavior to various parts of an applications. They let you integrate outside components more easily into your application.

I think this is a more sensible approach to enterprise computing than trying to create this solution that tries to solve all the issues important to enterprise computing.

Finally, another failure of the EJB model is the collaboration between different technology providers. The EJB model was supposed to encourage application assembly: you would get some beans from a provider, put them together with some beans from another provider and create an application. I do not know of a successful application which got assembled this way.
However, the level of integration the lightweight frameworks have with outside technologies (such as the Acegi security framework) puts them in huge contrast with the EJB architecture. It looks like the IoC containers are much better applications assemblers than an EJB container.

The EJB spec leaves behind the image of an elephant mired in the moors of enterprise computing, trying to provide a solution for every conceivable problem, ending up with no clear answer to anything.
Looking at the picture that the EJB spec presents today it is not clear how another version – even the annotation-enhanced, transparent, lightweight version 3 – will fix the systemic problems that this bloated technology poses. I am skeptical that the on-going effort for refining EJBs will ever bear the fruit it was supposed to.

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.

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.

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.