|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
What Color Are My Shoes?
September 1, 2005
|DDD - Diagram Driven Design|
|What Does It Mean to Use Messaging?|
|A Chapter a Day...|
|Clouds and Integration Patterns at JavaOne|
|My First Google Wave Robot|
|Into the Clouds on New Acid|
|Design Patterns: More than meets the eye|
|Reflecting on Enterprise Integration Patterns|
|Google Gears Live From Japan|
|Double-Dipping: OOPSLA and Colorado Software Summit|
|Enterprise Mashup Summit|
|Facebook Developer Garage|
|Mashups Tools Market|
|Mashups == EAI 2.0?|
Martin Fowler once said that you can tell a social geek by the fact that he looks at the other person’s shoes. While this makes for a good joke I have actually found that there is a distinct group of software developers who are quite social and well connected. When someone asked me recently how I keep up on all the happenings in the software world I realized that I do a good portion of it by hanging out around the people who know a lot more than I do. This can mean a pub crawl in London, late nights at the TechEd speaker hotel, or the Tangosol party at JavaOne.
Over time I have actually become used to attending conferences not so much for the session content but for the networking and hallway or bar discussions. Apparently I am not alone because Bruce Eckel created a “conference” just for people like me. This “conference” includes only people who are usually speakers at other conferences (or easily could be) and it features a very loosely structured format that is reminiscent of a dinner or beer discussion. Because of the selective audience the noise level at the event is very low and marketing is completely absent because we have nothing to sell to each other. For the past 3 years I have always left a little smarter and quite inspired. Since the audience for such an event is naturally limited this year I want to share some of the topics we discussed. Each of the topics is probably worth its own blog entry so I will expand the ones I find particularly interesting. But here a few sound bytes to wet your appetite. Note that these notes were derived from discussion groups rather than prepared talks so that the "conclusions" take a smaller role than the exchange of experiences and opinions.
Metadata in the code (aka Attributes / Annotations) is the shiny new toy in both the C# and Java world. Having worked with C# for a while I can’t help myself but to be amused and irritated by the fact that Sun used to tell Java developers that all this “syntactic sugar” is superfluous, just to completely change their mind once the competition moved in. So either they were lying all along or they have no spine. But anyway, before I start to sound like Hani, let me share some of our discussions around metadata annotations.
One of the problems with every new tool is that it is hard to determine what the boundaries of its best usage are unless you actually cross those boundaries. I think many people went through that experience with attributes not too long ago. In order to shorten the learning cycle we exchanged some experiences and opinions on proper use of attributes.
SetUpas the naming convention for a setup method, only one method in each class can have this name (assuming an empty list of parameters). If you use an attribute, you need to decide whether you want to allow multiple methods to be marked this way and, if so, what the desired behavior is. Moreover, if you allow inheritance do you want to automatically “inherit” the attribute to the child class? You might end up building some of the compiler infrastructure yourself in order to get the behavior. So be careful if the behavior associated with the attribute is more complex than “for every method with the attribute do X”.
ISerializable. Instead, we would have to perform the equivalent check explicitly and at run-time, reducing the amount of validation the compiler can do for us.
SoapActionname at deployment time? Attributes are part of the source code after all and require access to the source code. Microsoft Indigo is fixing this aspect by allowing all configuration to be specified either as attributes, as code, or in a config file. Another example of external configuration is provided by the EJB 3.0 configuration of schema and table name of an entity:
@Entity @Table(name=”…” schema=”…”). This is information that is typically intended to be changed at deployment time and it will be cumbersome (at the least) to have to edit source code and rebuild the application. On the other hand though, for very simple apps this usage can be more explicit (and hence more readable) than an external configuration file. So as in most cases, the world is not exactly black and white.
In summary people appreciated attributes because they can make properties of a class (or the application of a cross-cutting concern) a lot more visible in the class source. However, caution should be exercised that the attributed truly denotes a property of the class itself and not a property or relationship external to the class (e.g. the table or Web service configuration described above).
I have previously declared my love for visualizations. I am quite convinced that many people do not have enough of a “big picture” of what their system looks like. Visualizations are very powerful tools, especially considering humans’ ability to quickly recognize patterns in complex diagrams. The gist of model extraction is to use modeling not to generate source code but to use source code (or a running system) to extract a model. Essentially you define a metamodel (yeah, big word, I know) and then apply the actual system against this metamodel. For example, a directed graph is a very popular metamodel and can be used very well to depict dependencies, message flows and the like. Once you have this model you can use it for validations, visualizations etc.
One of the shortcomings of most visualizations is that they tend not to scale very well, exemplified by the proverbial 3’ by 4’ database schema poster that is entirely useless. I think that assisted model generation using attributes can help in this category. You can actively decorate your source code with metadata to distinguish “important” from “unimportant” elements etc. This type of decoration (using attributes in the source) are particularly useful because they convey intent (i.e. the “why”) as opposed to the “how”. The latter is (well, should be) quite obvious in the source code itself and does not require any further explanation (reminding me of my favorite source comment
// sets variable x to zero).
Another way to convey relevant information without running our of paper is to use polymetric diagrams, i.e., diagrams that convey more than one metric in a single picture. The most famous example of a polymetric chart is likely the map of napoleon’s Russia campaign. Erik showed us Code Crawler which provides a host of visualizations that use position, size, shading and shape to convey multiple aspects of your source code. Unfortunately, is runs only on SmallTalk but an Eclipse plug-in allows for conversion from Java code. Erik showed some very cool visualizations that show class lines of code, the number of methods and the number of fields in a single diagram.
I hosted the topic of mixing multiple architectural styles in a single application. This topic is close to my heart since I spend a lot of time with workflow engines, messaging, rules engines, document transformations and other non-OO stuff. Each of these tools and engines is based on a different architectural style and often uses a different programming languages (e.g., BPEL, XSLT, etc). Some of the topics we discussed included when an application layer becomes complex enough to warrant a new style and whether this style should be based on the core language (e.g. Java or X#) or whether a whole new language should be created. When creating a new language, you have further choices, such as whether to use a "standard" language or create your own domain language. As this post is already getting lengthy (and slow in coming along) I’ll postpone a more detailed discussion to a separate post. Plus, this topic makes a great segue to the next item.
Many of us believe that DSLs are the “next big thing” on the horizon for enterprise software development. Some very early tools are starting to appear, such as JetBrains' MPS or Microsoft's Visual Studio 2005 DSL Tools. Other tools, like the Intentional Programming work continue to be shrouded in mystery.
Einar hosted a great session on goal-based design used primarily in the context of agent systems. Agent-based systems consists of a collection of collaborating agents, which in unison accomplish an overall goal. The individual agents' behavior is based on their belief (aka state), their goal (a completeness condition) and their plan (an algorithm of sorts). Agent-based systems can be very effective at breaking down complex goals into small, manageable tasks. Agent-based systems are generally associated more with the academic fringe, with many commercial tools being quite expensive and mostly limited to military applications. However, some open source alternatives seem to be appearing.
To me two discussion items stood out particularly:
I guess I have to buy the bullet and get the (pricey) book that Einar was reading. The book does not as much talk about what agents are but focuses instead on a methodology to design agent-based systems.
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is a software architect with Google. 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.
|© 2010 • All rights reserved.|