čtvrtek 23. října 2003

Návrat chytrých klientů a soumrak "HTML aplikací"?

Tomáš Kouba mě ve spotu Pokles HTML aplikací? přivedl na zkoumání, co to znamená tzv. chytrý klient(Rich Client) a na takové malé zamyšlení, ale po pořádku. V spotu můžeme nalézt tabulku, která vyjadřuje procentuelní podíl různých klientů distribuovaných řešení v roce 2002 a předpoklad pro rok 2005. Tabulku jsem z původního spotu Tomáše Kouby zkopíroval.

Typ klienta 2002 2005
1st Generation Rich Client 24% 6%
Stand-Alone Rich Client 7% 30%
Browser Rich Client 5% 18%
HTML 64% 46%

V samotném spotu, stejně jako ve výše uvedené tabulce, narazíte na termín chytrý klient(Rich Client). Chytrý klient je takový typ aplikace, který nabízí komfort klasických desktopových aplikací s využitím rozšířených standardů webu potažmo internetu. Právě komfort, i když bych spíše volil slovo použitelnost, hraje klíčovou roli. Proč právě komfort? Uživatelé chtějí programy s takovým grafickým rozhraním a takovými možnostmi, které jim nabízí jejich operační systém případně aplikace, které na něm používají. Počínaje standardním grafickým rozhraním, drag&drop operacemi, kvalitním tiskovým výstupem, stavovou konzistenci(přechody mezi stránkami ve Web aplikacích) a konče uživatelskou personalizací. Proč používat web aplikace s HTML výstupem, které jsou ve velké většině na prohlížeči závislé? Dodejme ne nepodstatné, pokud mají alespoň částečně splňovat některá výše uvedená kritéria.

Web aplikace tak jak je známe dnes, již narážejí a mnohdy jsou za hranicí HTTP,HTML,DHTML a dalších vlastností, které prohlížeče nabízejí. Právě proto je tu myšlenka chytrých klientů-programů, které jsou platformově nezávislé a poskytující vyšší funkčnost s pohodlnějším komfortem než dnešní a v podstatě jakékoliv internetové prohlížeče s běžně dostupnými technologiemi.

Právě nástup těchto chytrých klientů(Stand-Alone Rich Clients) bude v roce 2005 na úrovni 30% ze všech používaných typů klientů. Je více než pravděpodobné, že základní technologické platformy budou tvořit Java a .NET. Některé indicie shodné s touto tezí poodhaluje John Yu v článku Rich clients emerge as alternatives for Web applications. Stejně tak se projeví nárůst podílu Browser Rich Clients. Tito chytří klienti budou zřejmě postaveny na rozšířených technologiích, které jsou nebo se budou moci stát součástí prohlížeče případně v něm budou integrovány. Největší šance mají technologie, které jsou již masivně používány dnes například Flash, XUL(Mozilla), ActiveX, Java Applet ...

Řeknemeli A řekněmě i B. Jakých web aplikací se výše uvedené dotkne? Bude se jednat o běžné B2C(Business to Customer) nebo složité B2B(Business to Business)? Samozřejmě vše začne a začalo u těch složitějších aplikací a pomalu se bude přesouvat k těm běžně rozšířeným jako je například internet banking. Tento trend se pravděpodobně vyhne tzv. webovým rozhraním jaké používají neplacené služby typu emailu.

Z výše uvedeného si dovoluji soudit, že ryzí HTML aplikace byly, jsou a budou. V budoucnu se ovšem projeví profilace těchto aplikací pouze na určité typy úloh.

Singleton a problém Double-check lockingu

Pokud jste již někdy používali návrhový vzor Singleton ve vícevláknovém prostředí, tak jste zřejmě narazili na problém jedinečnosti Singletonu resp. synchronizaci metody, která vrací jeho instanci. Synchronizovat celou metodu vracející instanci, se nevyplatí z hlediska vzájemného zdržování jednotlivých vláken.

V některých materiálech se proto uvádí technika tzv. double-check lockingu (dvojité kontroly s uzamčením), která vypadá následovně

 
  .
  .
  . 
  public static Singleton getInstance() {
    if(singleton == null) {
      synchronized(Singleton.class) {
        if(singleton == null) {
          singleton = new Singleton();
        }
      }
    }
    return singleton;
  }
 

Tato technika je založena na tom, že se synchronizuje pouze vytvoření instance Singletonu to pouze v případě, že je Singleton neinicializován(singleton == null) v synchronizovaném bloku.

Tento kód je teoreticky dobrý ovšem prakticky je nepoužitelný! Na vině je pamětový model Javy, který umožňuje tzv. Out-of-order zápis. V podstatě se jedná o to, že reference na objekt nemusí být rovná null(je již alokována paměť na haldě s ukazatelem na zásobníku) a objekt ještě není zinicializován(je volán jeho konstruktor). Out-of-order zapís je zavlečen JIT kompilátorem.

Řešení se nabízí více a každé má své pro a proti. Například v použití statické třídní proměnné nebo proměnné typu volatile, u které nesmí JIT kompilátor provést Out-of-order. Více o tomto problému Peter Haggar v článku Double-checked locking and the Singleton pattern a tým odborníků David Bacon, Joshua Bloch, Jeff Bogda, Cliff Click, Paul Haahr, Doug Lea, Tom May, Jan-Willem Maessen, John D. Mitchell, Kelvin Nilsen, Bill Pugh, Emin Gun Sirer v článku The "Double-Checked Locking is Broken" Declaration

pondělí 20. října 2003

Java vs. C#

Tomáš Kouba se pustil do testování rychlosti Javy. Spot či spíše článek Porovnání rychlosti Javy na MS Windows a Linuxu a srovnání s C# a C ukazuje porovnání těchto technologií jak z hlediska vývojové platformy(Java,C#,C), tak v případě Javy, porovnání výkonu na operačních systémech Windows a Linux. Pokud mohu soudit, tak se jasně ukázalo, že C# a celá platforma .NET vychází architekturou z Javy a její neduhy dotahuje k dokonalosti. Na druhou stranu je třeba brát zřetel na fakt, že Virtuální stroj pro C# je tvořen samotným Microsoftem a proto je harmonie s operačním systémem takřka dokonalá. Otázkou zůstává jakou rychlost by C# vykazoval na portaci v linxuvém prostředí.

Hledisko rychlosti prezentované výsledky testů nemusí mít takovou váhu v řešeních, pro které je Java a C# určen. Nepředpokládm možnost, že by se v Jave někdy v budoucnu psali ovladače. Nesporná výhoda totiž leží v přenositelném byte kodu. Větší váha je dnes kladena na efektivitu vývoje a v neposlední řadě na kvalitě dalších aspektů jako je flexibilita a rozšiřitelnost těchto platforem.