Making it stick.
Tuesday, July 22, 2003
  Multiple Canonical Models: Databases or Messages?

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. 

  Less Code == More Productivity

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.
Monday, July 21, 2003
  John Robb's New Location John Robb's new site is up. Great. 
  Jess in Action

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

  Agile Concurrency

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.  

Patrick Logan's weblog.

March 02, 2003 / March 09, 2003 / March 16, 2003 / March 23, 2003 / March 30, 2003 / April 06, 2003 / April 13, 2003 / April 20, 2003 / April 27, 2003 / May 04, 2003 / May 11, 2003 / May 18, 2003 / June 01, 2003 / June 08, 2003 / June 15, 2003 / June 22, 2003 / June 29, 2003 / July 06, 2003 / July 13, 2003 / July 20, 2003 / July 27, 2003 / August 03, 2003 / August 10, 2003 / August 17, 2003 / August 24, 2003 / August 31, 2003 / September 07, 2003 / September 14, 2003 / September 21, 2003 / September 28, 2003 / October 05, 2003 / October 12, 2003 / October 19, 2003 / October 26, 2003 / November 09, 2003 / November 16, 2003 / November 23, 2003 / November 30, 2003 / December 14, 2003 / December 21, 2003 / December 28, 2003 / January 04, 2004 / January 11, 2004 / January 18, 2004 / January 25, 2004 / February 01, 2004 / February 08, 2004 / February 15, 2004 / February 22, 2004 / February 29, 2004 / March 07, 2004 / March 14, 2004 / March 21, 2004 / March 28, 2004 / April 11, 2004 / April 18, 2004 / April 25, 2004 / May 02, 2004 / May 09, 2004 /

Powered by Blogger