One interesting development is the appearance (re-appearance?) of EDAs and the traction they are gaining in the developers mind-share. I see the interest in EDA to be an extension of the interest in asynchronous processing, EDA is asynchronous processing taken to a higher level. It is interesting because it is a pretty novel technology which (as far as I know) has not been tested in large scale systems (large scale in terms of number of nodes which receive and process events). So far the examples which are given out on sites such as infoq are toys and I find this very telling for the level of adoption on this architectural style.
Nevertheless, the concept is bubbling all over the place and the seeds for the next architectural atrocities and miserable failures are being sown right now: posts such as this are already advocating “event patterns”. Event patterns is a pretty pompous name for an architectural construct which appears to be in process of development right now. You need a bit of experience before starting to lay out some guidelines and a few EDA applications don’t give you this. Let’s wait a few more years and see something emerge. The famous GoF design patterns were written quite a few years after C++ became widely used, I’d say we should take the same approach for events.

So far I see events being used either as gateways into larger applications or the infrastructure for implementing simple, one-way, non-circular work-flows. In the infoq example the main hard problem resolved around circular flows: a parent sends a message to a child which sends it back to the parent which sends it again to the child. The solution advocated was pretty simplistic, if I remember the presenter suggested keeping track of the nodes a message has visited and do something in case it is visiting the same node twice, probably inserting the messages in an envelope which gets sent from node to node, hopefully in a transparent manner that would allow for different algorithm for detecting and resolving circular flows depending on the nature of the application using EDA.

Applications using event-driven-architectures are essentially message-passing applications and fall pretty easily within the distributed computing domain. Distributed computing problems are very hard problems and the interactions between distributed components are pretty hard to follow. I don’t think that we are currently in a position to use EDAs on a large scale because I don’t see the modeling tools and frameworks that could solve the hard problems invariably generated by a large number of nodes passing messages to one another (mind you, this need could be turned into a business case). However, most of the world would beg to differ: take a look at the example given here. It is pretty interesting to see a problem being solved by slapping the tag EDA on it. The article brings together a complex web of interactions, states EDA and assumes that this solves the problem.

Another problem that I see with EDA is the fact that you couple systems indirectly. With EDA you need the whole picture of the systems, you cannot really say that you will send a message to a system thru a web-service and you finished with it, it is possible that this system will get back to you in such a way as to create a circular flow. Given the fact that this flow spans different systems it could be very hard to implement algorithms that would detect the fact that a message has been sent multiple times because of a circular flow (such as in the infoq example. In the infoq example you could implement such a detection mechanism because you had control over the whole system). This scenario should be considered when implementing inter-system flows.

So I would conclude this post by saying that for the time being EDA is a technology which is at its beginnings and, as a result of it, which has a lot more fluff than stuff. It may evolve into something bigger in time, but it poses very hard problems once the number of nodes involved in a particular event chain increases. Also, as far as I am aware, there are not good modeling tools that can be used for applying EDA on a large scale.

Later Edit: From this article it sounds like TIBCO (a well-established distributed computing vendor) offers a solution called BusinessEvents for event processing. Judging from a podcast with some guy from TIBCO I would not be surprised if it turns out a pretty good product.

Later Edit: With Complex Event Processing and Event Stream Processing it looks like the industry is moving towards processing event streams at a single point in a network rather than trying to manage the events at the level of the whole network. Maybe this is what is needed by the market. It is also part of the push towards asynchronous processing that we are witnessing. Maybe I was too harsh on it…

A Romanian wave spent over Cannes this year:
Cristian Mungiu got the Palme d’Or and Cristian Nemescu (may he rest in peace) won the Un certain regard prize.
Congratulations and keep up the good work!!!!

Sometimes your application requires customization which is quite complex. This would be an example:
Suppose that you have a B2C application which is selling shoes. The business decides that in order to promote business in New York the app should detect users from NY and give a 15% rebate to these users. Also the app should use a tiered-pricing schema for users from the Midwest and a 10% rebate to users from California. (I know that this is a pretty bad example but I have some requirements that would beat this in complexity quite easily. This example is actually pretty simple.)
So far I have seen these approaches to implementing requirements similar to the one above:
1) Create a whole set of relationships between the various entities of your application and use these relationships for implementing custom functionality. This has the downside that you are creating a big complex system that is pretty hard to follow and has all sort of weird code appearing all over the code base in order to service these customization requests.
The above example would be implemented in the following way (I am assuming that the relationships are stored in a database):
a) Add a table that maps regions to price schema IDs.
b) Extend the user table and assign it a region.
c) Change the pricing module to take in a user, to get the user’s region and from the user’s region get the pricing schema.
d) Change the pricing module to work off a pricing schema.

2) Do this transparently by creating custom implementations for the interfaces which define your application’s business logic. You can use inheritance for accessing shared behavior between a new custom implementation and an already existing class and configuration for setting up the custom implementation easily. Again, configuration can be shared if necessary. This approach has the advantage that is a lot leaner than the previous one and is easier to read.
The above requirement would be implemented this way:
a) Change the pricing module to work off a pricing schema (this is similar to step d) above).
b) Create a mapping in Spring which maps regions to pricing schemas.
c) Create a mapping in Spring which thru scoping retrieves the user from the web app, retrieves its region (possibly thru geo-targetting) and populates the pricing module with the correct pricing schema.
As you can see the second approach is not intrusive at all, it doesn’t touch the code base at all. More importantly it doesn’t couple the pricing module to the user as it was the case with the first example.

One problem which appears with the 2 approaches is the one that arises when a support team (likely not close to the developers) is doing support for this application.
In the first case the support team has to know all the entities which are tied to a particular failure in the application which can be very hard to do. As the complexity of the system and the number of short-cuts increase the support team will have a pretty hard time to determine what went wrong where.

In the second case the support team can have a more subtle problem: since the customization is done transparently it doesn’t really know what could possibly go wrong in the customization (was a new region added in Spring.xml and mapped to the appropriate pricing schema, was there something else). In the first case it could have gone thru the maze of relationships which make up the customization, in the second it cannot do much if the error occurred in the customized part of the application, because that part is hidden away from it. The only thing it may have access to is the configuration of these customizations as well as to the functional spec of the customization.
It would not be a bad idea to think about what could go wrong with a custom implementation when you are creating it and create a trouble-shooter which could be available to the support team for identifying errors occurring within a customized implementation. This trouble-shooter would, ideally, be integrated seamlessly into the support process. In the above case the trouble shooter would have been exposing the mapping mechanism (which maps a user all the way to the pricing schema) to the support team, who could use it in order to determine if the mapping has problems (does a user from Alabama get assigned to Midwest pricing schema?) because what is hidden from it is this mapping. Once the support team determines that the mapping is done well it could look at possible problems with the corresponding pricing schema.

The idea here is that customization can be done explicitly (by using a complex system of relationships between various entities) or implicitly (transparently thru configuration). Either way, the support team should have access to it.

Later edit: It would be really neat if in the above example the user-to-pricing schema mappings would have been tested to the point where they would have been bullet-proof before putting in prod. Then the problems would have occurred in the various pricing schemas. A support person should have been enabled to determine quickly what pricing schema was used and resolve problems related to them.
Mappings management, or bindings management as I called them in a previous post, will gain importance as the relationships between various components will increase. These mappings will create a few problems on their own once they become too many…

I think it is obvious, but I have not seen it mentioned anywhere: you need to test an application which has been AOP-ed (which has been built using AOP). Suppose that you wrote an advice that re-prices a shopping cart. You should unit-test the advice on its own, unit-test the application on its own, but you should also unit-test the advice applied to the application (just to make sure that the advice has been applied properly and is well integrated into the application). The application which has been enhanced by aspects is a brand new thing (well, maybe not) which needs to be unit-tested as well (especially if the advice is modifying its state as the shopping cart re-pricing advice does).

I wonder if you could/should compose unit-tests (let’s say JUnit tests) similar to the way you compose applications. The new unit-test (the one that tests the application as it has been modified by the advice) could probably be derived from the 2 unit-tests, it would be interesting to see if you could compose the new unit-test with the same ease with which you compose the application. One problem with unit-testing an AOP-enhanced application that I see is the difference between the ease of use with which an advice can be applied to a code-base and the ease of use with which you can create a unit-test which can test the new application. Very likely the advice is applied in configuration while the AOP test is written in code, there is a pretty big difference in the time spent on creating the new application vs the time spent on creating the tests for the new application. I wonder if testing platforms should not be tweaked in order to allow for unit test re-composition.

It would be interesting to know why nobody is talking about this. Could it be because AOP is being used mainly for infrastructure issues which do no inject significant behavior into the application (I see unit-testing AOP-enhanced applications being very important for weaving business-logic advices into an application)? Could it be because of the difference in the costs of creating an AOP-enhanced application and testing it? Once again, time will tell…

P.S. This post is pretty much a collection of various thoughts that I have about AOP and unit testing. I realize that it is not very well structured, but I didn’t have the time to dwell too much on it.

The need for diff-ing and merging designs doesn’t necessarily appear during the design phase, it is possible to solve differences in design thru team-work such as discussing together any design changes.
The need for diff-ing and merging designs is more pressing later in the application life-cycle when design is used as documentation and when you need to change something documented in the design, let’s say a component. In order for the design to properly document the component the design may need to be changed as well. But it could happen that multiple people are working on the same component. These people have no problem CODING together on the same component, at the end of the day they would reconcile their code differences the usual way (by using CVS file comparisons for example). But they would have a problem CHANGING THE DESIGN at the same time, because if you cannot diff and merge a design you would have problems reconciling all the design changes.There are some work-arounds to this deficiency: one would be to assign a person in charge of maintaining the design up to changes in code, but this is not really pretty.
When people complain about the problems of diff-ing and merging in design what I hear is pretty hilarious: it is stated the fact that since you work with images (those blocks on your UML diagrams) you would have to diff and merge images and this cannot be done ;-). Well, those images are actually representations of some concepts such as class relationships, class names, method names, etc… These concepts can be represented in an ASCII format which could be diff-ed and merged pretty easily.

I think that we should be able to diff and merge design documents such as UML diagrams. I would like to check out the Eclipse Modeling Framework and see how they save an ordinary UML diagram to disk (and I hope that they use an ASCII format and not a binary format). If an ASCII format is chosen for this it is possible to create a component that could diff and merge various UML blocks.
Now I have to find the time to inspect this. Not going to happen for a while.

Later Edit: I find it ludicrous that UML diagrams produced by one system (let`s say Microsoft Visio) cannot be consumed by another system (such as free-ware Poseidon). It`s like code written on JBuilder could not be opened on Eclipse. Pathetic. These walls should come one one way or another. The wide range of free UML editors are worth nothing if they cannot communicate with other UML editors.

I was watching this rather boring infoq presentation on SOA when Gregor Hohpe, the guy giving the presentation, asked this question:
“We went from client-server development to thin client and now to services. The CIO, the guy paying for your IT implementations should ask you: What is next?”
Gregor Hohpe went on, but it left behind a pretty interesting question: why did we move from client-server to thin client and next to services? To be honest with you I don’t think the proper answer could possibly come from IT person, because I think that IT has been changed (at least till now) by the the economics of hardware rather than anything else.

I get the impression that client-server started to become main stream once the price for PCs started to drop and it became worth-while to start using these PCs rather than dumb-terminals. The alternative to rich-clients back then was ASCII-only dumb-terminals, it was obvious that the work-force would become a lot more productive if they switched to these rich-clients. I wonder why the rich-client was chosen rather than the thin client in the post-dumb-terminal IT environment. My impression is that this was done in order to minimize the traffic between the client and the server, at those speeds chatty applications were not possible.
Once the PCs prices started to drop the next barrier was the network. This took a while to go down, but once reasonable network speeds could be achieved this opened the door to a new concept: that of the application stored in a central place and of thin clients whose functionality it making requests to this application. One advantage to this approach is that by consolidating the application in a central place it obviates the versioning hell lived thru during the previous period. This was first massively used for pushing new applications (such as Amazon.com, eBay.com, yahoo.com, etc…) thru the web to consumers. Another advantage to the thin client was that it lowered the barrier for accessing an application by not requiring the customer to do anything (no download, no clumsy set-up process, no clumsy removal process, etc…). One potential problem with the rich client is the PC’s real-estate: you can fit and efficiently manage only that many applications on your PC, this puts a barrier of entry on the applications that can be run on a PC (how many would have installed an Amazon-type book browsing application on their PCs in the 90’s?). With the thin client this barrier goes away. I would argue that the drop in telecommunications costs drove the thin-client model and the economics behind it.
As telecommunications costs continued to drop the applications started becoming more and more chatty, leading to the point where the interactions behind them had to be managed efficiently. SOA comes to the rescue. End of story.

It appears that events in the CONSUMER’s market actually drove the ENTERPRISE IT environment. I guess the effects the consumer’s market has on the price of various computing devices (by effectively turning them into commodities) creates cost-savings which are recognized and used by enterprise IT. It would be interesting to muse over what the future factors of change for IT in an environment that has already seen massive price decreases. With rock bottom prices both in hardware and in telecommunications the next thing to decrease in price is probably software itself (and the open-source community is busy working on that).

There are a lot of complains that all these migrations (which are true paradigms shifts) are costing the companies lots of money. I agree with this, but you should consider that they also save a lot because otherwise nobody would do it. My .02$.

P.S. Another thing that I see happening right now is the re-emergence of the rich-client model. I see this as being correlated to the emergence of the mobile devices (another event in the CONSUMER electronics space) and their differences (reduced bandwidth and, more importantly, a very different interaction with the user) rather than recognizing that the rich-client model has any value.

P.P.S. I wrote this post in a hurry. It probably shows…

Later edit: If my assumption that hardware price changes due to demand in the consumer electronics space drove enterprise IT is correct it would be interesting to see what would be the next drivers. Changes in the price of software is a possible driver. It would be possible that changes in IT would be done on “merit”: i.e. a certain paradigm would be implemented because it is a more efficient way to write software rather than because it is related to a drop in the price of a certain hardware platform.

For some time me and my wife have been talking about the possibility of returning to our home country, Romania. It would be nice to be in Romania (I’m not using the expression “back home” because I have been living here for such a long time I don’t think I can call Romania home) and the high demand for IT professionals would raise the odds considerably for both of us. We have been talking about it for a while now and in a certain way we have started preparing for this. Except that it is starting to take on a weird feeling…
This weekend I talked to a friend of mine from Romania and I was surprised to find him happy (I know, it sounds horrible to be surprised by people being happy, but in that part of the world happiness is the exception to the rule). Things were going pretty well for him, to the point where he brought up the possibility of returning, after congratulating me for 15 years for leaving the country.
Things are going well over there. My friend spent quite a lot of time to tell me about the 9-figure investment by a major European corporation into Romania, about how everything is changing, how the dinosaurs so far in control of the country will be obsolete, etc… All very nice.

Except that right now I get the feeling that moving over there right now is buying shares in a bull-market. Not a comfortable feeling…