Oct 6, 2006
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 an Enterprise Strategist at
AWS.
My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home: ArchitectElevator.com.
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.
One highlight 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 if they are 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?
if statements looked like an if statement. Erik: I hope Ruby will get closures right.
Will Mapping (O-R, XML) Become Easier or Go Away?
What role will AI play?
Will CSP or OCCAM come back?
What Do You Think of Formal Views in Programming Languages?
Will DSL's Cause Language Proliferation?
Will AOP Make It to the Mainstream?
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.
Best Quotes (Kevlin is the clear winner in this category):
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.
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:
overridetestNewCollectionIsEmptyserializableProgrammers 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.
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.
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.
OK, I got to stop writing. I attended so many more interesting sessions that I can only mention in passing here:
Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent
speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several
books on architecture and architects.