Michael Ingold's Blog

Singleton patterns: We all know and love them! Altough I came across a problem that puzzled me for a bit, so I wanna share that little piece of experience with you guys. So here’s the first bit of code:

public class StorageLevelObserver implements IArticleObserver
{
  private static StorageLevelObserver instance;
  private ch.hslu.appe.stock.Stock legacy;

  private StorageLevelObserver(ch.hslu.appe.stock.Stock legacy)
  {
    if(legacy == null)
    {
      this.legacy = new StockLocal();
    }
    else
    {
      this.legacy = legacy;
    }
  }
  /**
  * Gets the Singleton-Instance of a StorageLevelObserver
  * @return The StorageLevelObserver to be used.
  */
  public static StorageLevelObserver getStorageLevelObserver(ch.hslu.appe.stock.Stock legacy)
  {
    if(StorageLevelObserver.instance == null)
    {
      StorageLevelObserver.instance= new StorageLevelObserver(legacy);
    }
    else
    {
      //if(legacy != StorageLevelObserver.instance.legacy)
      //{
      //  StorageLevelObserver.instance.legacy = legacy;
      //}
    }
    return StorageLevelObserver.instance;
  }
  public void notify(IObservableArticle article, String property)  {   ...  }
}

Take a moment to realize what the code actually does, ignoring the commended part of getStorageLevelObserver()! getStorageLevelObserver() is in this case of a Singleton, is the function to construct the internal instance of StorageLevelObserver and saves the reference to the private static referencevariable instance, therefor using an if to check if the reference is already set or not. I introduced a new parameter to the getStorageLevelObserver()-Method because I needed give the Observer a stock to order Items from, if the local stocklevel is too low. (This is done within the  notify-Method! It isn’t important, so don’t bother)

Of course i also want to test such an important class, so i set up two new Testcase for two different scenarios to be testet. That’s probably the place where the legacy-Field comes in, that you have been asking yourselves about multiple times until now. Legacy holds a reference to an Instance of Stock, an Object that represents the central Stock, from whitch our stock has to order, if the local level of Items of a specific article is too low. The StorageLevelObserver -Class’s objective is to keep the local stocklevels within given boundaries!

When testing i inserted my own StockHelper-Objects, that implement the Stock-Interface, and help me checking that a change within an article correctly triggers an order to the Legacy-Stock-System, thereby filling the local stock. For the two testcases I also wrote two different StockHelpers. The beginning of each TestCase was the same: Get the StockLevelObserver-Instance by also directly passing the according StockHelper as an actual parameter. The Tests in my IDE succeded, using JUnit and Eclipse as an IDE. Me, quiet happy, ran  the tests again using ant test. The tests failed! What!?!?!?

I could not find the solution to my problem using the eclipse Debugger, and debugging using ant…Well not so much either. It puzzeled me for a while, then I got it. The singleton pattern and it’s behavior within the JVM-Environment seem to be the problem. Eclipse apparently creates a separate instance of JVM for each TestCase, while ANT doesn’t. So what exactly happend?

Using Eclipse and thereby one separate instance of the JVM for each Testcase, the singleton was created twice, using the two different StockHelpers as intended, because the block within the IF-Statement in getStorageLevelObserver() was executed twice!!! That does not happen if one and the same JVM-Instance is used for both TestCases. In that case the internal Field instance is already set and the constructor will not be called, thereby not setting legacy to the new StockHelper-Object and cause my tests to fail, because the wrong StockHelper was used the second time!

When I realized that, I created a new IF-Block whose content will be executed if the new legacy-Object differs from the old one, thereby setting legacy to the new value, without having to call the private constructor (not necessary, creates overhead only…). It solved my problem, and hopefully keeps you from being puzzeld by the same buggy code yourself.

Edit: The problem seems to be the same even if the StockHelper will not be changed during runtime. If the instance of JVM is not destroyed after one test-Run, instance might still be set, provoking the same odd behavior as mentioned above. (Apparently ANT behaves sometimes like that – that was the problem for me too)

Wenn man am Morgen zu viel Zeit hat, und sich etwas auf Google+ herumtreibt, dann stösst man auch so anscheinend erstaunlich einfach Aufgaben. Ich will Sie euch also auch nicht vorenthalten:

Vielleich möchte sich jemand mittels Kommentaren zur richtigen Lösung äussern!?! Ich kenne an der HSLU mindestens einen Dozenten, welcher seine Freude an dieser Aufgabe haben wird

Wer hat’s erfunden? Als stolze Schweizer würden wir diese Frage selbsverständlich wie die weltweilt berühmte Ricola-Werbung beantworten. Doch für einmal scheint dies nicht der Fall zu sein. Früher waren Patente eine tolle Methode in einem Land sein Produkt davor zu schützen, dass es von einem anderen Hersteller kopiert oder teilweise übernommen wurde. Das funktionierte in den 60er Jahren warscheinlich sogar sehr gut, da der Weltmarkt noch nicht so globalisert und Wissen noch nicht wie heute so schnell übers Internet verbreitet werde konnte. Durch diese Globalisierung ist der Konkurrenzdruck und insbesondere dabei auch der Zeitdruck auf Neuentwicklungen so stark angestiegen, dass es heute oft schwierig ist, ohne jeden Zweifel festzustellen wer was erfunden hat, oder dann, wer wem abgeschaut hat. Es ist ein Dilemma in welchem sich die nationalen Justizsysteme in dieser Frage befinden. Ich nenne es auch oft, das Ricola-Dilemma.

In den letzten Jahren beginnt mich eine Entwicklung sehr zu beunruhigen. Nahmhafte Firmen im IT-Bereich beginnen damit, riesige jurstische Abteilungen zu gründen, welche den ganzen Tag nichts anderes tun, als anderen Firmen auf die Finger zu schauen, und sie so schnell wie nur möglich vor Gericht zu bringen, wenn etwas auch nur im entfertnesten ähnliches auf den Markt kommt, was sie bereits mit einem Patent geschützt haben. Den jüngsten und warscheinlich bald grössten Urheberrechtsstreit fechten gerade der amerikanische IPhone-Hersteller Mac und der südkoeranische Technologiekonzern Samsung aus. Samsung wurde von Mac vor einem US-amerikanischen Gericht verklagt, weil der Konzern mehr als 20 Patente des mobilen Betriebssystems IOS verletzt habe.

Als Antwort darauf kauft sich Samsung die Firma S3 Graphics welche in einem Rechtsstreit wegen zwei Patentverletzungen gegen Mac auftritt und macht sich damit vom Verklagten zum Kläger. Solche Paktiken scheinen in sich in der SmartPhone-Banche langsam aber sicher einzubürgern, bezahlt doch der taiwanesische SmartPhone-Hersteller HTC pro SmartPhone 5 Dollar Lizenzgebühren an Microsoft, wenn Googles OS Android auf dem Gerät installiert wurde.

Warscheinlich geht es noch anderen so wie mir: Ich habe die Nase voll davon in den IT-News zu lesen, welcher Softwarekonzern wieder den Konkurrenten verklagt. Was diese Grossfirmen jedoch in ihrem Patent-Wahn zu vergessen scheinen ist, dass Innovation nicht vor Gericht stattfindet, sondern auf dem Markt und in den Labors all jener Firmen, welche verstanden haben, dass sie auf Innovation setzen müssen, und nicht auf Patente.

Wir als Kunden interessieren in diesen Rechtsstreitigkeiten peripher warschienlich jedoch überhaupt nicht. In diesem Rechtsstreitigkeiten geht es nur um eines: Den Hochmut der IT-Riesen. Wie sagt man so schön: Hochmut kommt vor dem Fall!
Wir als Kunden verlieren bei diesen Streitereien hingegen doppelt: Die beiden klagenden Parteien müssen ihre exorbitanten Anwaltskosten mittels total überhöhten Preise Ihrer Produkte wieder berappen und die Geräte, welche wir dann trotzdem (blauäugig wie der Durchschnittbenutzer halt ist) zu diesen Preisen kaufen sind kaum noch innovativ – geschweigen denn mit kreativen neuen Lösungen ausgestattet.

Ich empfehle den grossen IT-Konzernen wie MAC, Microsoft, Google, HTC, Samsung und all jenen, welche ich hier nicht aufführe, wieder in Innovation zu investieren (Mac investierte in den letzten Jahren im Verhältniss zu ihrem Umsatz immer weniger in Innovation und Forschung!) und nicht mehr in Gerichtsverfahren. Legen Sie sich wieder einen Stolz zu und freuen sie sich darüber wenn Ihre Firma innovativ ist. Patente haben keinen Wert, das einzige was in der schnellebigen IT-Branche einen Wert hat, sind innovative Mitarbeiter. Doch Juristen – so wichtig sie für unser Zusammenleben auch sein mögen – sind nicht innovativ.

Ich habe etwas über Social Networking nachgedacht, nachdem ich mich der Diaspora Community angeschlossen hatte. Diaspora hat mich überzeugt. Klar ist, dass das Projekt im Alpha-Status nicht gerade ein Facebook-Gegener sein kann, aber die Ansätze sind klar vorhanden und das Potential liegt ebenfalls in vollem Mass vor.

Ich habe mir einige Gedanken dazu gemacht, wie Diaspora schneller bekannt und populär werden kann. Dazu habe ich Wissen aus der Netzwerktechnik und dem Web vereint und mir daraus eine Vision aufgestellt.

Diaspora verfolgt einen guten Ansatz, in dem es seine Server verteilt und jeder Besitzer eines Webservers einen eigenen Diasporaserver betreiben kann. Die Server können untereinander verbunden werden. Dies spart Geld, da die Server auf sehr vielen kleinen und bereits vorhandenen und bezahlten Ressourcen laufen können. Da so die Nutzerzahl auf einen Server eher beschränkt bleibt, ist die nicht ganz optimale Skalierbarkeit von Diaspora nur zweitrangig wichtig. Das aktuelle Konzept von Diaspora lässt mir einen Aspekt leider etwas zu sehr ausser Acht, welchen man bei verteilten Systeme dieser Art beachten sollte: die Skalierbarkeit.

Das aktuelle Konzept von Diaspora sieht vor, dass die Administratoren auf einer Diaspora-Instanz eigenhändig Verbindungen zu anderen Instanzen erzeugen müssen, dass die Nutzer der beiden Systeme kollaborieren können. Wenn man nun davon ausgeht, dass Diaspora mit derselben Geschwindigkeit wie Facebook seinerzeit wachsen könnte, wird genau dieser Aspekt zu einem Problem.

Der entscheidenen Vorteil von zentralisierten Systemen wie Facebook ist der, dass sich die Nutzer nicht überlegen müssen, ob ihr Freund, den sie in den Ferien kennengelernt haben, über ihren Server erreichbar sein wird oder nicht. Dies ist bei Diaspora nicht gegeben. Es ist möglich, dass mein Server denjeneigen des Freunden aus den Ferien nicht erreichen kann, somit verfehlt das SocialNetwork seinen Zweck.

Gesucht ist also ein Lösungsansatz welcher diese Mauer fallen lässt. Hier kommt das Wissen aus der Netwerk Welt ins Spiel. Denn Router innerhalb eines Netzwerkes sehen sich mit einer ähnlichen Problematik konfrontiert: Wie finde ich meine Nachbaren automatisch? Wie sende ich die Posts eines Nutzers an den richtigen Server, auch wenn ich diesen nicht kenne? Gelöst wir dies im Bereich der Netzwerke mittels einer Vielzahl unterschiedlicher Routing-Protokolle. Dieses Wissen und dieses Konzept kann nun auch auf ein verteiltes Soziales Netzwerk angewendet werden, denn Sie haben eines gemeinsam: Es sind beides Netzwerke und verteilte Infrastrukturen.

Wie könnte dies nun im Fall Diaspora aussehen? Wir möchten nun also den Diaspora-Server ‘Bern’ mit dem Diaspora-Server ‘Alaska’ bekanntmachen. Wie dies bei Routern der Fall ist muss natürlich zuerst eine Verbindung zwischen den zwei Instanzen bestehen. Dies wir mit einem sogenannten ‘Link’ realisiert. Links können grundsätzlich vom Administrator manuell oder aber vom Server autonom erstellt werden. Wir machen nun Instanz Bern mit Instanz Alaska bekannt. Nun kann der Benutzer ‘bob@diaspora-bern.ch’ mit seiner Flamme ‘alice@diaspora-alaska.com’ in Verbindung treten. Dies ist der einfachste Fall und braucht keine Routingfunktionalität. Wie sieht es jedoch aus, wenn der Server in Alaska noch einen weiteren Server in China kennt? Wie kann nun Bob in der Schweiz mit einer Ferienbekanntschaft aus Taiwan in Kontakt bleiben? Wie kann der Server in Bern herausfinden, dass sein Gegenüber in Alaska, den taiwanesischen Diaspora-Server kennt? (einfach dass keine Verwirrung entsteht – Diasporaserver sind nicht an Hoheitsgebiete oder Landesgrenzen gebunden, die hier geschilderte Ausgangslage dient als anschauliches Beispiel) Die Lösung der Netzwerkwelt zu dieser Fragestellung lautet: Routingtabellen. Jeder Router hat eine solche Routingtabelle in die er die Wege zu den gewünschten Netzwerken einträgt. Ein ähnliches Konstrukt könnte nun jede Diaspora-Instanz implementieren.

In diese ‘Linktables’ werde nun alle Netzwerke eingetragen welche manuell von einem Systemadministrator erstellt wurden. Der Server in Alaska trägt nun den Server in Taiwan mit Name und IP-Addresse in seine Linktable ein. Im Moment in dem Server Bern und Alaska verbunden werden, tauschen die beiden Server ihre Linktables aus. Der berner Server nimmt nun Alaskas Linkstable entgegen und vergleicht diese mit seiner eigenen Tabelle. Der Eintrag des Servers Taiwan fehlt in seiner Tabelle höchstwarscheinlich und wird nun hinzugefügt.

Bei klassischen Routingprotokollen würde nun der Router Bern seine Routingtable so ergänzen, dass er weiss: eine Nachricht für den Router in Taiwan muss über den Router in Alaska geleitet werden. Dies ist bei Routern deshalb notwendig, da der Router Bern keine physikalische Verbindung nach Taiwan besitzt, daher muss er den Umweg über den Router in Alaska gehen. Bei einem sozialen Netzwerk wie Diaspora ist dieser Schritt nicht notwendig, da die Netzwerkverbindung nach Taiwan besteht und sich der OSI-Stack darum kümmert, dass unser Nachrichten korrekt von Bern nach Taiwan gelangen. Der Diaspora Server in Bern trägt also einfach die IP-Adresse des Diaspora-Servers in Taiwan in seine Linktable ein, und erstellt eine direkte Verbindung nach Taiwan. Es ist somit kein Zwischenschritt über Alaska mehr notwendig. Somit erspahrt man dem Diaspora-Server in Alaska viel Datenverkehr, welcher ihm nichts nützt und reduziert die Latenzzeit bei der Übertragung zwischen den Servern.

Auf diese Art kann nun Bob auf dem Server in der Schweiz mit seinen Freunden auf dem Diasporaserver in Taiwan in Verbindung treten ohne, dass die Administratoren in Taiwan oder Bern einen neuen Link auf den jeweiligen Server erstellen.

Nun kann also ein Diaspora-Netzwerk auf die hier geschilderte Art selbständig konvergieren. Bedenken treten bei mir jedoch bei der Sicherheit der neu erstellten Verbindung zwischen Taiwan und Bern auf, denn das Einrichten der verschlüsselten Verbindung könnte mitgehört und somit die Verschlüsselung angreifbar werden. Da ich mich gerade entschlossen habe, dieser Idee etwas mehr Aufmerksamkeit zu schenken, werde ich ein Whitepaper aufsetzen worin ich auch den Aspekt der Sicherheit näher beleuchten werde. Ebenfalls weiterverfolgen werde ich den Spezialfall, dass ein Diaspora-Server einen anderen Server nicht in seine Routingantworten einbinden möchte, sodass dieser versteckt bleibt. Auch wichtig zu wissen ist, in welchen UseCases ein solchen Bedürfniss entstehen könnte.