1. Know your audience. If you look at the log files of many applications you quickly realize who the intended audience is: Developers. The log is full with technical detail, but not much of it makes sense to anybody else. The groups you probably should have on your list are: Developers on the search for bugs, performance issues, Administrators trying to install, start or shutdown your application and Support personal trying to detect and analyze problems or trying to verify that a problem did not occur. Once you realize there are different audiences you’ll understand what kind of information is helpfull in the logs.
2. Use a framework. The major options are: Log4j, SLF4J, JUL, Commons Logging or Logback. Each one has it’s pros and cons, but they are all better then System.out.println. They allow you to configure at deploy or runtime, what gets logged where and in what format. If you don’t want to do any research, and don’t have special requirements, use SLF4J.
3. Logging must be rock solid. If a logging causes problems. Throw it out. Don’t do experiments like remote logging, if you can avoid it.
4. Define rules, when to use which Log Level: I propose the following:
   • DEBUG: Not important, except if you are researching a very specific problem.
   • INFO: General information like startup, shutdown, version and configuration of an application. Information about important decisions in the code or changes in the configuration.
   • WARN: Things that are fishy, but don’t represent a problem in themself, but might indicate a problem when appearing very often. E.g. a failed log in attempt is such a candidate. If it happens sometime it is not a problem, but if it happens a lot somebody might want to look into that.
   • ERROR: This should only be used when a problem occurs that somebody needs to look into. Typically but not necessarily relating to an exception in the code. Use this when only a limited part of the application is affected.
   • FATAL: If something goes completely wrong, rendering the application unable to recover this log level is appropriate, very likely accompanied by a shutdown of the application or the session.

   Of course your rules need some tayloring for your context, but absolutely need rules, and every developer must know and understand those.

5. Log everything you log exactly once: When analyzing log files I often see log messages that always come in groups. This happens often when exceptions get caught, logged, and rethrown. Don’t do that. Log at the place where you actually do handle the exception. This is the only way to log an exception exactly once and also being able to decide which log level to use.
6. Include useful information and data: The information should typically include answers to the following questions
   • Why are you logging this, typically the root cause of an exception.
   • What is the affected use case? Did it happen during creation of an order or when importing product data from a remote site?
   • What effect has it on the use case that was executing? Does the user need to repeat the action, or did it succeed? Did the complete batch fail, or just a single step?
   • What instance of the use case was effected? For example an order id.

   In order to make all this information available to your logs MDC (Mapped Diagnostic Context) is tremendously helpful. If you don’t know MDC, follow the link and read about it NOW. MDC exists also in SLF4J and Log4J and should be easy to port for other frameworks as well.

7. Use more then one logging hierachy: The link contains more information about why. The simple idea is, that you can seperate different aspects you want to log by using different prefixes. This becomes especially usefull when adhering to the following points
8. Log the time needed for stuff which might be intersting for tuning: Of course this includes the time used for access to remote resources (e.g. webservices or databases) and execution of complex algorithms, but possibly also the time spend in the various layers in the application. You can use different log level for three categories, a separate logging hierarchy for separating performance logging from other stuff. Performance problems a notorious difficult to hunt down, especially when they appear over time. You’ll love this logs, when performance becomes an issue.
9. Log stuff that worked, not only what failed: Distributed systems become common place more and more. When debugging distributed system one often has the situation that requests just disappear, and it can be extremely challenging to decide which component failed. After all not everybody does such a fine logging as us, right? So I recommend the following log events:
   • RECEIVED: The application received a request through the UI, a Webservice or any kind of interface offered.
   • SEND: The application send a request to some other component.
   • GOT ANSWER:  The application got a reply to a request it send.
   • ANSWERED: The application answered to a request it received.
10. Log how often stuff happens: One possible reason for decreasing performance is a changed usage pattern. So logging how often per day, hour or minute a certain kind of use case is triggered can help tremendously.

While obviously I recommend a lot of logging, it isn’t free of cost. So when doing some logging you should be sure to avoid it in tight loops that get executed millions of times. Also MDC keeps a reference to everything you put into, so make sure to clear it when you are done and think twice before putting complex objects in. And finally think about data privacy. A lot of people might have access to the log files. They shouldn’t find passwords, credit cards or similar information their.

Probably somewhere around point number 8 you might have started to think: “Man this guy is crazy. I’ll have more highly repetitive logging code than anything else in my application!” And if you do everything by hand you are probably right. But if you have cleanly structured code where you can deduct use cases, application layers, access to remote connections and so on from the method signature and the packages involved, most of these logging statement can get injected using AOP. So what is left is to create a framework that handles all this.

Since I couldn’t find an Open Source Solution I started my own: Meta Logga. It is still in an extremely early stage, definitely not ready to be used, but possibly ready to understand where I am heading.

If you agree with me that this is indeed something that would be useful you can help in many extremely easy ways. Comment on this post, tweet it, dzone it, blog about or in any other way make this post more visible to others. All this will help me to keep motivated, thus it will help the project.

So I should be pretty happy right? Well in the general sense actually I am, but as a developer, I have the feeling that I am operating on the wrong level of abstraction. A lot of the time I am working directly on the code level. Writing getters, setters, exception handling, logging. There are some areas, where the abstraction level moved considerable upwards in the last years. Persistence comes to the mind. Hibernate is pretty reasonable, although it has it’s problems, and it’s enemies. Another one might be rules engines, I haven’t tried those. But other then that …? Of course there has been progress. A lot of progress. We have hundreds of languages, many with very interesting features. We have a large choice of databases with innovative concepts to choose from, and of course a pletorea of java libraries for almost every purpose. We have IDEs so smart, I sometimes wonder if they are really just another piece of code. So what am I complaining about?

I think it is about time for the next paradigm shift. Why are we still coding objects? An example: I want to build the ubiquitous shopping system. I take a jar I found somewhere on the web to get started. Of course I have my own little idea, about how this thing should work, so I want to tweak the shopping cart a little. So what do I do?

public class MyCart extends somebody.elses.Cart {
    public void setRealyCoolFeature() { ...

But most of the time, this doesn’t work. Because the new attribute doesn’t get saved in the database. Or maybe it does, but the repository returns only Cart’s and not MyCart’s. The gui doesn’t show the new attribute, actually the gui of the component is for swing, but I want a web gui. No problem I can write that, but now I have tons of fireProperty noise in the code, that really nobody cares about. Of course it’s better than the other way round, because it is extremely tricky get fireProperty calls into a class without changing the source files.

Hold on a second I know what you are thinking: You fix that with a little AOP here, and this won’t be a problem if the component was cleanly designed in the first place. Agreed. But my point is: I want to use the concept of a shopping system. I don’t want to deal with technical detail like AOP, IoC and similar. Or from the perspective of the component provider: I want to code the concept of a shopping system, and I do not care, how the users want to store it, how they want to show it, and how they want to extend it. That is what I’d call a new paradigm.

Of course I am not the first calling for the next paradigm since OOP. Actually there are many alternatives out there on various levels: AOP, Functional Programming, Meta Programming on the very technical side. Business Process Modeling, Rule Engine, and Components pretend to operate on a higher level, but sometimes I get the feeling they’re just a glorified version of Basic. None of those come even close, to what I imagine. And I don’t even use drugs to get there. Still there might be a solution in sight. Imagine something along these lines:

If you write a component, you use a language that is much more expressive than java, possibly like groovy but two steps further and with a strong type checking (I’m a fan of strong type checking). In this language you specify the structure (the relationships) of you component. Using the equivalent of annotations on stereoids you specify things like transactional behavior, logging behavior, GUI representation, concurrency options, but on a very high abstraction level. For example for concurrency you don’t specify locks, latches and stuff like that, instead you specify data that is related and there for needs protection against concurrent access.

All this is not compiled into a single jar (or whatever we will call it), but actually ends up in separate ajars (Aspect Jars). So as a user, I can take the differnt pieces, and create a extension, specifying the various aspects in the same way, thereby extending all the aspects I need to extend. This is possible, since the aspects are still separated, and not compiled in one big blob. And the original developer separated those, because it was the easiest thing to do.

The guy actually using the component, somebody else created, and extended be  me, uses the components in a high level DSL, that allows him to glue pieces together. For example he could specify which kind of order and invoice component should get created from the cart component. And although the three components come frome completely distinct developers, they would be joined automatically using domain information from the semantic internet. This joining would of course need some tweaking but it should give you a head start. I think this sounds extremely nice, doesn’t it?

Will it happen? Most certainly not. The description is to specific to fit whatever comes, yet way to vague for anybody to actually implement it. BUT I am pretty optimistic something along these lines will actually happen in the next 10 years. DSLs and AOP and new languages that allow Aspects to be written as easily as a for loop will be key players at it.

So if you are a genius with lots of time and a strong developer team at hand, get into contact with me to exchange ideas. If you just a stupid enterprise application developer as I am that needs a job for the next 30-40 years to come, get used to AOP, watch the new languages and don’t worry to much about concurrency.

Sprachen

Das aktuelle Thema überhaupt ist sicherlich Sprachen. Durch die Allgegenwart von zwei wesentlichen Laufzeitumgebungen (JVM von Java/Sun und der CLR von .NET/Microsoft) ist es extrem einfach neue Sprachen mal auszuprobieren. Zu dem Thema empfehle ich den Artikel von Markus Völter.

Meine persönlichen Erkenntnisse dazu:

• Fast(?) nichts von den Konzepten ist neu. Die Basis für funktionale Sprache z.B. ist das Lambda Kalkül von 1930. Insbesondere das Polyglotte Programmieren ist doch längst Standard. Ich z.B. zähle in den meisten Projekten mindestens Java, SQL, PL/SQL, HTML und CSS zu meinem Handwerkszeug. Was sich ändern könnte, ist warum wir zwei oder mehr Sprachen einsetzen: Weil bestimmte Aspekte in der einen, andere in der zweiten Sprache besser darstellbar sind. Während bisher der Grund der Mangel an Alternativen ist. (Ja ich weiß, man kann auch in Oracle mit Java arbeiten. Aber wer das einwirft hat es noch nicht ernsthaft ausprobiert).
• Wir werden uns damit beschäftigen müssen. Heiße Kandidaten für die praktische Anwendung sind für mich: Groovy und Scala.
  Auch spannend finde ich Haskell. Ich habe vor vielen Jahren an der Uni Miranda gelernt und hätte nie gedacht, dass dies mal im Berufsleben relevant werden könnte.
  Als Physiker, der einmal intensiv mit Fortran gearbeitet hat finde ich auch Fortress sehr beeindruckend. Dies Sprache kann zumindest für Mathematiker und ähnliche sehr leserlich gerendert werden und ist speziell auf (massiv)parallele Ausführung ausgerichtet.

Womit wir bei einem weiteren Thema sind:

Concurrency

Das Moore’sche Gesetz als Basis des Quaketunings (18 Monate Quake spielen, schon ist die Anwendung doppelt so schnell) ist am Ende. Als ‘horizontale Ausweichbewegung’ werden uns von AMD und Intel Mehrkern CPUs auf den Schreibtisch gestellt. Dadurch geraten überall Leute in Panik, existierende Anwendungen würden nun wie die Fliegen von den Wänden fallen, da Threadingprobleme sich nun manifestieren.

Nun ja, ich weiß nicht was für Anwendungen ihr schreibt, aber ich schreibe beruflich entweder Swing oder Webanwendungen, die auf Datenbanken gehen. Nur ein sehr kleiner Teil der Arbeit steckt in komplexen Algorithmen, und ich habe noch nie etwas davon parallelisiert. Datenbanken und Webserver laufen ‘schon immer’ auf Mehrprozessormaschinen. Es sind heute halt 512 statt 16. Die Art und Weise wie dort Parallelverarbeitung eingesetzt wird, ist extrem einfach und daher handhabbar: Jede Anfrage bekommt einen Thread, und darf ihn für sich alleine verwenden, bis die Anfrage abgearbeitet ist. Zumindest sieht es aus der Sicht des Entwicklers so aus.

Nur in Swing muss man typischer Weise mit mehreren Threads arbeiten, da lang laufende Aktionen sonst die Darstellung der Anwendung blockieren. Dies wird man aber wenn irgend möglich minimieren, da jeder der Doug Leas Buch gelesen hat, weiß wie schwierig Concurrency ist.

Viele der neuen Sprachen haben aber Konstrukte, die die Verteilte Ausführung unterstützen und es ist ja nicht so, dass wir die nicht zu nutzen wüssten. Unabhängig von der Anzahl der Prozessoren gibt es nämlich einen Bereich, in dem Concurrency eine Rolle spielen sollte: bei dem Zugriff auf verteilte Ressourcen. Egal ob es die Datenbank oder der entfernte Web Service ist, wenn wir eine Anfrage abschicken und warten, bis die Antwort kommt, bevor wir die nächste Anfrage lostreten verschwenden wir mindestens Zeit, und meist auch wertvolle Ressourcen (mindestens den wartenden Thread). Je nachdem wie knapp die Ressourcen sind, wird man früher oder später genötigt sein, die Anfragen parallel anzustoßen und anschließend die Ergebnisse zusammenzuführen. Schön wenn die Sprache mit der man dies tut, ein solches Vorgehen angemessen unterstützt.

Security

Es gibt immer wieder Stimmen, die meinen, Security würde jetzt DAS große Thema. Vertraut mir, wird es nicht. Genauso wenig wie Gasmasken oder Panzertüren DAS große Thema werden. Aber Security ist ein Dauerbrenner, den niemand ignorieren sollte. Oder schließt ihr euer Auto und eure Wohnung nicht ab? Daher gab es auch auf der JAX Vorträge zu diesem Thema.

Für mich die wichtigsten Punkt waren dabei:

• * Der Deming Zyklus gilt auch hier. D.h.
  • Plant was eure Sicherheitsziele sind und was ihr dafür tun müsst. Wollt ihr euch gegen Skriptkiddies schützen? Oder haltet ihr die NSA für euren Feind? In letzterem Fall könnte aber auch ein Psychater helfen
  • Führt die Maßnahmen durch.
  • Prüft, ob die Maßnahmen wirksam sind.
  • Wenn die Prüfung negativ ausfällt, reagiert darauf.
• Schwierig an dem Security Thema ist, dass selbst gigantische Sicherheitsprobleme nicht von allen erkannt werden. Wenn ich in mein Haus eine Tür aus Pappe einbaue, brauche ich keinen Experten um zu erkennen, dass das eine schlechte Idee ist. Bei Software ist das ganze deutlich weniger offensichtlich. Ich habe die privaten Schlüssel für Zertifikate schon gemailt bekommen. Daher gibt es eine ganz wichtige Aufgabe, wenn eine Anwendung ‘sicher’ werden muss: Awareness schaffen. Alle Beteiligten (Entwickler, Designer, Tester, Administratoren, Anwender, …) müssen in Sachen Security geschult werden. Denn was nützt die schöne Sicherheitsarchitektur, wenn der Benutzer seines Sohnes Namen als Passwort verwendet und das auch noch per E-Mail verschickt und auf den Monitorrahmen schreibt?
• Security heißt nicht einfach Benutzer Authentifizierung und Authorisierung sondern durchdringt den gesamten Entwicklungsprozess.
  • Bei der Analyse müssen die Anforderungen aufgenommen werden.
  • Diese müssen bei der Architektur und dem Design berücksichtigt werden.
  • Es muss natürlich implementiert werden,
  • aber auch getestet,
  • deployed
  • und genutzt

  Und wie ich oben skizziert habe, gibt es auch in den Bereichen Herausforderungen, wo man sie normalerweise vielleicht nicht erwartet.

Architektur

Ist ein weiterer Dauerbrenner, und ähnlich wie bei Security lautet hier mein Hinweis Deming Circle! Eine Architektur hat eine Aufgabe zu erfüllen. Die Aufgabe sollte vorher klar sein und nachher muss geprüft werden, dass die Aufgabe gelöst wurde. Ansonsten ist Architektur ein Unfall oder Selbstbefriedigung des Architekten.

Durch das Thema Nr.1 ‘Sprachen’ gewinnen wir gerade im Bereich Architektur gerade gewaltig an Möglichkeiten:

• Unterschiedliche Sprachen für unterschiedliche Bereiche.
• DSLs für Spezialfälle
• AOP oder spezielle Sprachstrukturen für die Umsetzung von Architekturentscheidungen

SOA und BPM

Viel Hype und (fast) nichts dahinter.

Das 5. Element (Quintessenz)

Die Probleme bleiben die alten. Die Lösungen sind auch nicht neu. Die Zeiten bleiben interessant.