Gregor's Ramblings
Home Patterns Ramblings Articles Talks Download Links Books Contact

JAOO 2006

Oct 6, 2006

ABOUT ME
Gregor Hohpe
Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also the Chief Architect at Allianz SE, one of the largest insurance companies in the world.
RAMBLINGS
Here I share my thoughts and ideas on a semi-regular basis. I call these notes "ramblings" because they are typically based on my personal opinions and observations as opposed to official "articles".

I am just riding the train back from Aarhus (the second largest city in Denmark in case your geography skills are as weak as mine were before my first trip here) to Copenhagen. Many speakers consistently rave about JAOO. The speaker roster, the logistics, the attendees – everything just seems to be very high quality and run very smoothly. This year I was nominated to be track host for the SOA track, entitled "SOA – What's Left to Say?" (if you pronounce SOA Ass Oh Ay, it actually rhymes).

The overarching scheme at JAOO this year was certainly languages, which is not all too surprising if you look at the concentration of language heavyweights in the speakers list. I got to meet Guy Steele (Scheme), Erik Meijer (self-declared "Language Pimper"), Betrand Meyer (Eiffel), and Ole Lehrmann Madsen (Simula). A whole track focused on DSLs and a separate track on abstractions for concurrency. With so much gray hair at the event, Dave Thomas moderated a track on "Back to the Future". In various sessions words like OCCAM, CSP, SIMULA, BETA, SCOOP, fortress, Scheme, Lisp, Visual Basic, C# and (almost forgot) Java were part of the vocabulary. Time to dust of those language books! It seems that the advent of multi-core chips (and to some extend the increasing pervasiveness of SOA) have really brought into the foreground of developers' minds that we are always working with concurrent systems. It also causes a lingering feeling that our current popular languages are not terribly well suited for such an environment.

Not surprisingly a lot more happened at JAOO than I can capture in a single blog entry. What follows are merely the highlights. A number of the talks would surely warrant a whole post on their own.

The Beers vs. The Waters

One of the highlights of the conference must have been he closing panel moderated by Dave Thomas. He pitched The Beers (Erik Meijer, Kevlin Henney, and Steve Vinoski) against The Waters (Guy Steele and Ole Lehrmann Madsen) to talk about Programming in 2016.

Before taking questions from the audience, Dave asked each participant for their opening statement. I think the viewpoints reflected the sentiment of the audience quite well. Guy's observation is that multi-core chips make parallelism more visible at the language level. Just writing a single-threaded app and hoping for the best will no longer cut it. Guy also expects a more diverse programming language environment. However, this could be a self-fulfilling prophecy as he is actively contributing to said diversity with Fortress. Guy also anticipates that the pervasiveness of Unicode might mean that languages are will no longer be tied to the ASCII character set. APL here we come…

Ole is looking for languages that provide for better abstractions and support for common patterns. Most of us would agree with him that many of today's popular languages hide useful patterns behind way too much syntax clutter. Steve expects IDEs to better support dynamic languages so that Ruby users no longer have to code in NotePad. Interestingly, he also expects us to be closer to where we were with SmallTalk 10 years ago. Maybe this will be the day the SmallTalkers will finally stop complaining that everything was so much better back when (Gartner purportedly has a 0.01 probability attached to that part of the prediction).

Kevlin, who has once described his favorite activity as talking picked right up on Steve's point on IDE's. "These EMACS users. Their heads are so full of key combinations there is no room for anything else". His biggest fear is that the future of programming looks like XML. He had only three words for that scenario: "That just sucks"

For the rest of the panel Dave collected questions from the audience. He asked participants to write their questions up "so he could spice them up a little of they were not mean enough". Here some of the more interesting questions and more entertaining answers. Keep in mind that these are not always my views, but those of the panel (with a little literary license).

Will Ruby succeed where Smalltalk failed? Or will it be like Java in 2006?

  • One of the reasons SmallTalk failed is because it was fairly bound up. One could not just use NotePad and code something up. Not even an if statements looked like an if statement. Erik: I hope Ruby will get closures right.
  • According to Dave, SmallTalk failed because the market shifted and it was very difficult to make dynamic language like SmallTalk run efficiently on a virtual machine like the JVM. So it was not a developer preference that killed SmallTalk, but a shift in the market. Sadly, the arrogance and close-mindedness of SmallTalkers sealed the lid.

Will Mapping (O-R, XML) Become Easier or Go Away?

  • Steve: JAX-WS allows you to work without mapping by allowing you to work directly with the XML documents .The problem is, though, that Java is not all that great at working with XML. He prefers languages like E4X (ECMA for XML) that are much more terse.
  • Erik: Mapping is always doomed. You need to pick your model(s) carefully because you cannot expect any system to just magically go from one model to another.
  • Dave thinks that a lot of the OO stuff will simply go away and simplify the mapping problem. A lot of OO code is written for things that are not inherently OO. Some day people will use objects properly to build the domain model but not for application infrastructure.

What role will AI play?

  • AI is by definition the thing that is not yet commercially applied. Once AI technologies are successful (e.g. camera autofocus) people stop calling it AI.

Will CSP or OCCAM come back?

  • It would be useful to define CSP style programming in other languages
  • Guy stated that CSP inspired some of the ways parallelism is expressed in Fortress. (unfortunately I missed Guy's Fortress talk because it was scheduled for a cruel 9am start)
  • Erik: Co-routines should come back. He points out that iterators in C# are not real co-routines. Kevlin also feels that Co-routines are one of the great lost paradigms.
  • Everybody agreed that CSP could help make concurrent systems easier to understand and safer to program. We really need to find a simpler model for distributed systems to stay clear of deadlocks, race conditions and poor performance.

What Do You Think of Formal Views in Programming Languages?

  • Ole thinks that pre and post conditions are a good way to express more about the intent of your program. For example, one of Bertrand Meyer's student has created a tool that can create unit tests from a contract (he demo'd this tool at the Google Testing Automation Conference in London)
  • Kevlin struck back by observing that pre and post conditions are Structured Programming in disguise because they assume top-down control.

Will DSL's Cause Language Proliferation?

  • Steve likes to tell the episode from the Blues Brothers movie where the woman at the bar proudly states that "We have both kinds of music: country and western". Too many programmers today think "We have both languages, C# and Java". In Steve's view, more languages mean more choices, not necessarily having to learn many languages.
  • Kevlin is also worried about 4GL Soup as the result of DSL movement. Most people are simply not good language designers because it is very difficult. Another worry of his is that creating too many languages will cause a new class of problems: What if my domain changes, which causes me to change my domain specific language? Now we have to deal with schema drift inside a programming language.

Will AOP Make It to the Mainstream?

  • Too bad Rod Johnson was not on the panel for this one as Kevlin dealt a blow against AOP. Kevlin reminded us that FORTRAN had the infamous assign-to operation, which is an incarnation of the comeFrom concept. Assign-to was considered too dangerous to be used in production code and recommended only for debugging. According to Kevlin, AOP is very similar to assign-to. The main problem is that one has no clue about what is actually going on by looking at the source code. He thinks that it is unlikely that AOP will become a general purpose programming thing. However, the thinks that AOSD (Aspect Oriented Software Development) might have better luck.
  • Guy took a more balanced stance, pointing out that too many AOP papers and talks recycle the same old examples. We would really like to see more use cases before we can decide which way it is going to go.
  • Ole felt that aspects would benefit from a better theoretical foundation. I'll let him elaborate on that. My brain is just the size of a peanut. Oh wait, this is Erik Meijer's line!

Is This Programming Thing Ever Going to Get Easier?

There seemed to be a general sentiment in the audience that programming is getting harder and harder as opposed to simpler. Besides all the excitement about better programming models and more efficient environments it seemed that the panel shares some of the same concerns.

  • Ole's main worry was that we are having a difficult time keeping the tools up with the complexity of new languages and platforms (in Java land it took almost a decade for a decent IDE to arrive). He could not help but point out that some people (all hands pointing at Steve) still use EMACS!
  • Dave believes that a lot of the problem lies in the fact that the platform vendors essentially ensure that the automated tools will always behind the complexity of the platform.

Best Quotes (Kevlin is the clear winner in this category):

  • I don’t use emacs. My embedded systems background taught me not to run multiple operating systems on the same hardware.
  • Concurrency will bring new bugs. So in 2016 our bugs will run faster.
  • The biggest problem with SmallTalk are the SmallTalkers.

Werner Vogels Keynote

Werner gave a keynote summarizing the history of Amazon's infrastructure. It quickly became apparent that having a bunch of app servers access a single database would not scale. So Amazon decided to avoid direct database access from the application and instead wraps all core business logic behind a ser of services. Services consists of both foundation services and aggregators. Aggregators combine data from multiple application services to build up a page. Amazon assigns one team to build each service. On occasion they have multiple teams competing for the construction of a service. I coined this the Reverse Conway's Law: you design your organizational structure so that the resulting system, which according to the law will resemble this structure, comes out the way you like it.

Amazon is continuing to battle the CAP theorem – the balance between Consistency, Availability, and Partionability. The theorem states that one can achieve only two of the three desirable properties when designing a system. For example, high availability is generally achieved through redundancy, which tends to compromise consistency. Werner's current thinking is that the application should be involved in data partinioning in order to maximize scalability.

Domain Annotations

Erik Doernenburg and Mike Royle gave their great Talk on Domain Annotations (they chose the word "annotations", but their guidance applies equally to Java annotations and .Net attributes). They reminded us of four ways that we commonly express metadata in source code:

  • Keywords, such as override
  • Naming conventions, such as testNewCollectionIsEmpty
  • Marker interfaces, such as serializable
  • Formatted comments, such as JavaDocs

Programmers use annotations for a variety of things. They make great markers for pointcuts (as opposed to naming or types). They can also be used to represent (and enforce) structural rules. For example, specific classes in the system could be tagged as [Layer("domain")]. The build system could validate dependencies between these layers, so that for example the domain layer cannot depend on the UI layer or the persistence layer.

One important guideline for annotations that is often overlooked (and was already discussed at Crested Butte) is the fact that they should describe a property that is intrinsic to the item being annotated. The annotation should change when the code of the annotated items change, not when the environment changes. This observation became apparent in the design of nUnit. While the use of annotations in nUnit is definitely a step forward over the jUnit naming conventions, the annotations do suffer from some violation of this useful guideline. For example, the [TestFixture] annotation is redundant. If a class contains a method annotated with [Test], it should be considered a fixture automatically. The [SetUp] annotation indicates which method should be called before any test invocation. As such it describes the role of this method in a larger context, i.e. the test invocation. This forces the nUnit framework to deal with issues like inheritance, which more or less led to a reimplementation of method dispatch.

Erik and Mike continued to show some interesting uses of annotations in the context of a domain model, i.e. a set of classes that describe a business domain. For example, they annotated string fields with a maxLength attribute. While this sounds trivial it is actually quite useful as different layers of the application could interpret this attribute in different ways. For the example, the UI layer could generate JavaScript that limits input length to the specified number of characters while the domain layer throws an exception of the string exceed the limit. Even though the field is used in different contexts, the meaning of the annotation is directly related to the annotated field and will only change if the nature of the field changes.

Other uses of annotations in domain models include classifying classes as (static) reference data or transactional data. For example, changes to reference data might need to be audited. Such annotations can also be used to color visualizations generated from the code base.

Erik and Mike showed a more involved example that uses annotations to navigate the object graph. The annotations describe the relationships between classes and which fields form this relationship. At runtime they can inspect these relationships without actually having to instantiate any objects as the annotations sit on the classes themselves. Some of the actual code to manage the navigation was a bit hairy but luckily it was well hidden inside utility classes. All the application developer has to do is place the annotations.

DSL Tutorial

Thursday and Friday are tutorials days at JAOO. I attended Markus Voelter’s hands-on tutorial on building a DSL with Eclipse and openArchitectureWare. Markus was clever enough to omit the dreaded MDA acronym from the title of his tutorial – the night before we discussed the trend towards MDC –Model-driven Crap. Markus is one of the more pragmatic members of the MDSD (Model-driven Software Development) community and it showed in this tutorial. After 15 minutes of PowerPoint slides he fired up Eclipse and started building a domain language using his modeling framework. Our goal was to define a language that uses Eric Evan’s vocabulary of entities and value objects. In order to make such a language we would have to create a metamodel, a code generator, and design a textual language. In order to express the metamodel we need to define a metametamodel. While that sounds a little scary it actually isn’t – we used the EMF metametamodel. From there we create the notion of a ValueObject, which we define as having a name and a set of attributes. In the end the template-based code generator turns each ValueObject in an immutable class with the appropriate constructor and getters.

The best part about this tutorial was that 90% of the time was spent coding as opposed to handwaving. Also, the focus on development tools for DSLs makes a lot of sense. For example, the framework supplies an editor for our newly made textual language, complete with autocomplete and syntax underlining.

Resources, Events, Agents

Pavel Hruby gave a tutorial on modeling using REA(Resources, Events, Agents). By the way. Pavel is the guy who created by far the best UML stencils for Visio. Pavel just completed a book on Model-driven Design using Business Patterns.

The REA approach starts from the assumption that almost all business software applications deal with a few common concepts, such as economic resources, events, agents. Pavel uses a pizzeria example to illustrate how these concepts can be used to model the pizzeria. For example, the sale of pizza involves economic agents Customer and Pizzeria and involves the events Sale and Payment Receipt, which affect the economic resources Pizza and Cash. Pavel then demonstrated how to create similar models for all business processes that make up the pizzeria’s business, such as making pizza, ordering raw materials, or acquiring labor.

The strength of REA is that it allows for validations of a domain model based on axioms (e.g., every increment economic event must be related to a decrement economic event via exchange duality). These validations allow the early discovery of imbalances or omissions in domain models.

Pavel illustrated how to extend the model to include concepts like time etc., but I think it is fair to say that the REA approach has a certain sweet spot and I had a more difficult time with the extensions.

So Much More

OK, I got to stop writing. I attended so many more interesting sessions that I can only mention in passing here:

  • Charles Simonyi on Intentional Programming (finally we got to see a demo)
  • Erik Meijer waxing about the greatness of higher order functions in Haskell.
  • Alistair’s keynote on the analogies between swimsuits and methodologies.
  • Dan North and Niclas on behavior-driven development
  • Oh, and my SOA track!
  • And so on and so on

MORE RAMBLINGS    Subscribe  SUBSCRIBE TO GREGOR'S RAMBLINGS


Gregor is the Chief IT Architect of Allianz SE. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.
www.eaipatterns.com