Martin Fowler urges the data people and messaging people to talk, but not to define a single model.

This makes sense whether you are talking about enterprise databases or enterprise messages. I would add two points. The final one, if you want to cut to the chase, is addressed pretty well by Cutter's Doug Barry.

The first is that although enterprise models are not easily "big designed upfront" there are proven techniques for supporting their emergence. The best I know of comes from Ralph Kimball, who I've written about before in the context of enterprise integration.

The other point I would add is that Martin is really addressing at least two significant issues. In addition to the perils of enterprise modeling, he's made an implicit point about messaging and databases. I'm not going to put words in his mouth but he could have pointed to his peers efforts to illustrate what he means by enterprise messaging.

I am not sold on the idea of general messaging. There are special cases where a high performance message product makes sense, e.g. broadcasting large volumes of financial information on a trading floor is the motivating example.

In the general case, messaging is just too much like a crippled database that assumes the consumer is not the provider. You end up with an additional product and all the associated costs. I think there is a lot of room for improving 80 percent of the cases a relational database is applied to, but not at the expense of an entirely new and yet severely limited product like messaging. (Hint: every messaging product has some kind of simple persistence mechanism you can't get to in a general way. Why?)

I would choose either low cost databases for Martin's integration scenarios, or, more ideally, a simple XML-based tuple space-like database. Either approach can be used in a myriad ways without assuming the consumer is not also the provider.

Doug Barry kind of addresses this issue in a Cutter report. He is a fellow traveller from the Object Oriented Database market. A full OODB is overkill. So is a full relational database, but at least they are commodity and not so esoteric.

This second point is we need simpler database products rather than messaging products.  ¶ 7:45 AM

Via Lambda the Ultimate we see Don Box wanting less code to espress a simple concept. This makes sense and corresponds to the conventional wisdom that programmers can get X lines of code running per day no matter what the language.

Reading between the lines the argument is that *explicit* static typing is just not a good idea, period. Dynamic languages and static languages based on type inferencing are the result of taking this direction to the limit.

I am not convinced static typed delegates vs. static typed classes in and of itself is that significant. Why not simply be able to pass methods around as first class objects without having to declare somewhere that it takes no arguments and returns a boolean? In a large post-modern system there will be at least a half dozen different such explicit declarations for programmers to keep track of.

Jython provides an example of how anonymous classes can be replaced by simple functions rather than pre-declared "delegates"...

In Java...

Button button = new Button(parent, style);
button.addActionListener(new ActionListener() {
    void actionPerformed(ActionEvent e) {
        // Take some action here.
        }});

In Jython, this can be replaced with a keyword parameter and function argument...

    button = Button(parent, style, actionPerformed=self.actionPerformed)
    ...
def actionPerformed(self, event):
    ## Take some action here.

I came across a new book on rule-based expert systems with Java and Jess. No review yet.  ¶ 6:56 AM

From the Manageability weblog comes the question and some answers about the ability to hide concurrency issues through one form of abstraction or another.

Functional programming is dinged for not having a concept of state or time. This is a misstatement. There are several ways to represent state and time in functional languages. It's just that none of them are that much better than they are in other styles of programming.

Toward the end of the item there are some subtle observations...

In short, it's all about coordination, and if you can build effective coordination mechanisms then you're on the right track to solving the real problem. To say that it can be abstracted away isn't solving the problem, it's denying the problem exists.

Ah, but what the item does not address is what are the various ways of abstracting concurrency. Abstracting does not always mean "hiding 100 percent".

The key is to build appropriate abstractions for representing concurrency, rather than hiding concurrency. For example an effective technique for avoiding deadlock is to assign an order for aquiring resources.

The difficult attempt would be to hide the fact that multiple consumers are competing for multiple shared resources. The typical attempt would be to explicitly code the competition using some low level locking mechanism.

The "just right" attempt would be to evolve an API that describes the desired order of consumption, holding on to multiple resources (or not), and the exceptional behavior for waiting.

One thing we need are better modeling and testing frameworks for concurrency scenarios.

We can also simplify the API evolution through higher level concurrency mechanisms like tuple spaces. Tuple spaces provide a few simple operations that act as building blocks for a wide variety of scenarios. They can be applied to in-process, multi-process, and persistent or transitory scenarios.   ¶ 6:43 AM