1 HACETTEPE ÜNİVERSİTESİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ BİL447 - YAZILIM MÜHENDİSLİĞİ LABORATUVARI ARAŞTIRMA ÖDEVİ (J2EE Clustering) Hasan Gölle 20021905 h_golle@yahoo.com

2 Önsöz. 3 Temel terimler.. 3 J2EE cluster mimarisi. 4 J2EE clustering nedir? 6 Web tier (dizi) clustering (öbekleme) gerçekleştirimi. 8 JBoss ile J2EE Clustering -Singleton Service... 15 Uygulama sunucu dağıtımı. 16 Kaynaklar 20

3 Önsöz Günümüzde çok fazla sayıda kritik görevli ve geniş çaplı uygulamalar Java 2, Enterprise Edition (J2EE) da çalıştırılmaktadır. Banka ve faturalandırma gibi kritik görevli uygulamalar üst düzeyde elde edilebilirlik gerektirirken Google ve Yahoo gibi geniş çaplı uygulamalar ise ölçeklenebilirlik gerektirirler. Elde edilebilirlik ve ölçeklenebilirliğin önemi şu olayla da ispatlanmıştır: Haziran 1999 da ebay da 22 saatlik hizmet kesintisi 2.3 milyon müzayede kesintisine ve ebay ın hisse değerinin yüzde 9.2 düşmesine neden olmuştur. Hata toleransı ile birlikte elde edilebilirlik ve ölçeklenebilirlik sağlama açısından J2EE clustering popüler bir teknolojidir. Fakat J2EE özelliğinin destek vermemesi nedeniyle J2EE satıcıları clustering i farklı şekillerde gerçekleştirmişlerdir. Bu da J2EE mimarları ve geliştiricileri için sorunlara neden olmuştur. Temel Terimler Clustering altında yatan kavramları anlamak gereklidir. Bu kavramlardan bazıları; Ölçeklenebilirlik Bazı geniş ölçekli sistemlerde son kullanıcıların sayısını ve davranışlarını önceden kestirmek zordur. Ölçeklenebilirlik, hızlı sayıda artan kullanıcıya destek verebilme yeteneğidir. Bunun sezgisel yolu kaynakları (hafıza, CPU, disk gibi) artırmaktır. Clustering ise alternatif bir yoldur. Bir grup sunucunun ağır işleri paylaşmasını ve tek bir mantıksal sunucu gibi davranmasını gerektirir. Yüksek elde edilebilirlik Ölçeklenebilirliğe tek sunucu çözümü (kaynak artırma) tek hata noktası nedeniyle sağlıklı bir çözüm değildir. Kritik görevli uygulamalar (banka gibi) bir dakikalık bile kesintiye tolerans gösteremez. Bu hizmetlerin makul cevap verme süreleri olmalıdır. Clustering, bu tür elde edilebilirliğe yedek sunucular sağlayarak ve hata durumunda yedeğini çalıştırarak çözüm sağlar. Yük dengeleme Clustering in anahtar teknolojisidir. Gelen istekleri farklı sunuculara dağıtarak daha iyi performans sağlar. Yük dengeleyici basit bir servlet yada plug-in den pahalı bir donanıma kadar pek çok şey olabilir. Hata Toleransı Yüksek elde edilebilir veri çok doğru veri olmayabilir. J2EE cluster da sunucu hata yaparsa kesilmez çünkü diğer istekler yedek sunucular tarafından değerlendirilir. Hata tolerans hizmetiyle az sayıda hataya rağmen doğru hizmeti garanti eder.

4 Failover Hata toleransı sağlamak için gerekli diğer bir anahtar teknolojidir. Cluster da başka bir düğüm seçmekle orijinal düğüm hata yapsa bile işlem devam eder. Başka bir düğüme failover açıkça kodlanabilir yada otomatikman yürütülür. J2EE Cluster Mimarisi J2EE cluster şunları içerir: Bir yada çok J2EE olgusu Olgu yaratabilen merkezi servisler Bir yada çok veritabanı Dağıtıcılar ve sunucular farklı fiziksel sunucular arasında dağıtılabilir. Merkezi hizmetler (mesaj hizmeti ve kuyruklama hizmeti) gereksinmeleri sağlayabilen bir host a yüklenebilir.genel olarak J2EE clustering teknolojisi yük dengeleme ve failover gerektirir. Minimum Cluster Yükleme Aşağıdaki grafik SAP Web uygulamasının en basit cluster yüklemesini gösterir. Bu şekilde yüklenen sunucu yalnızca J2EE sorgularını işletir.

5 Bu J2EE cluster da şunlar vardır: Dağıtıcı, üç sunucu ve yazılım yükleme yönecisi ile merkezi bir j2ee olgusu, Merkezi servisler, Veritabanı. J2EE olgusu şunları içerir: 0-n J2EE dağıtıcı (genelde her olgu için bir dağıtıcı kullanılır ), Bir yada çok sunucu işlemi. Geniş Cluster Yükleme Aşağıdaki grafik daha büyük bir J2EE cluster yükleme gösterir. Dört olgu içerir, herbirinin olgu numarası vardır ve herbiri ayrı ayrı başlatılır, bitirilir ve gözlenebilir.

6 J2EE Clustering Nedir? Yük dengeleme Şekilde görüldüğü gibi hedef nesnelerden eşzamanlı istekte bulunan birçok istemci nesne vardır. Çağıran ve çağrılan nesneler arasında bulunan yük dengeleyici, istekleri yedek nesnelere gönderir. Bu sayede yüksek performans sağlanır. Failover Şekilde görüldüğü gibi failover yük dengelemeden farklı çalışır. Bazen istemci nesne hedef nesneden ardışık metot istemlerinde bulunur. Eğer hedef nesne başarısız olursa failover sistemi bu hatayı bulmalı ve sonraki istemleri diğer nesneye yönlendirmelidir. Hata toleransı bu şekilde sağlanır. Eğer J2EE clustering hakkında daha fazla öğrenmek istiyorsanız ne tür nesneler öbeklenebilir yada J2EE kodda yük dengeleme ve failover nerede bulunmalı gibi temel sorular sorabilmelisiniz. Aslında her nesne öbeklenemez ve J2EE kodda her yerde bulunamaz. Şu örnek koda bakalım;

7 Instance1 hata verirse Class A nın business() metodu diğer B olgusu üzerine failover yada yük dengelemesi mi yapacak? Hayır. Yük dengelemesi ve failover için çağrılan ve çağıran arasında metot çağrılarını dağıtan ve farklı nesnelere yönlendiren bir yakalayıcı bulunmalıdır. Class A ve B nesneleri aynı JVM de çalışırlar ve sıkıca bağlıdırlar. Metot çağrıları arasına dağıtma mantığı eklemek zordur. Öyleyse ne tür nesneler öbeklenebilir?- Yalnızca dağıtılmış topolojilere yüklenebilen bileşenler. Öyleyse J2EE kodda failover ve yük dengeleme nerde olur?- Yalnızca dağıtılmış nesnelerin metotlarının çağrıldığı yerlerde.

8 Şekil: Dağıtılmış nesneler Şekildeki gibi dağıtılmış bir ortamda çağıran ve çağrılanlar belli sınırları olan farklı çalışma zamanı kaplarına ayrılırlar. Sınırlar JVM ile işlemler yada makineler arasında olabilir. Hedef nesne istemci tarafından çağrıldığında hedef nesnenin kabında işlev çalıştırılır. (Bu nedenle dağıtılmış denir). İstemciler ve hedef nesneler standart ağ protokolü ile haberleşirler. Bu özellikler sayesinde bazı mekanizmalar metot çağırma yoluna girerek yük dengeleme ve failover yürütebilir. Şekilde görüldüğü gibi tarayıcı uzak JSP nesnesini HTTP protokolü üstünden çağırabilir. JSP Web sunucu tarafından çalıştırılır, tarayıcı nasıl çalıştırıldığı ile ilgilenmez, yalnızca sonucu ister. Böyle bir senaryoda yük dengeleme ve failover işlevleri için tarayıcı ve web sunucu arasında bir şey bulunmalıdır. J2EE de dağıtma teknikleri JSP(Servlet), JDBC, EJB, JNDI, JMS, web servisleri ve diğerlerini içerir. Bu dağıtılmış metotlar çağrıldığında yük dengeleme ve failover yürütülür. Detaylı teknikleri bir sonraki bölümde anlatacağız. Web tier (dizi) clustering (öbekleme) gerçekleştirimi Web dizisinde öbekleme J2EE clustering de en önemli işlevdir. Web öbekleme teknikleri web yük dengeleme ve HTTP oturum failover içerir.

9 Web Yük Dengeleme J2EE satıcıları web yük dengelemeyi birçok yöntemle başarırlar. Temelde yük dengeleyici tarayıcılar ile web sunucuları arasına girerler. Şekil: Web yük dengeleyici Yük dengeleyici F5 yük dengeleyici gibi donanımsal bir ürün olabilir, ve yük dengeleyici plug-in leri ile birlikte bir web sunucu da olabilir. Ip zincirleri ile bir Linux kutusu yük dengelemeyi yapabilir. Hangi tekniği kullanırsa kullansın yük dengeleyici şu özelliklere sahiptir;. Yük dengeleme algoritmalarını gerçekleştirir İstemciden istek geldiğinde yük dengeleyici bu istekleri en son sunucu olgularına nasıl dağıtacağına karar verir. Popüler algoritmalar round-robin, random ve ağırlık tabanlı olanlardır. Yük dengeleyici her sunucu olgusuna eşit iş yükünü sağlamaya çalışır, fakat yukarıdaki algoritmalardan hiçbiri mükemmel eşitliği sağlayamaz çünkü hepsi bir sunucu olgusuna dağıtılan istekleri temel alırlar.. Sağlık kontrolü Bazı sunucu olguları hata verirse yük dengeleyici bu hatayı bulmalı ve o sunucuya bir daha istek göndermemelidir. Yük dengeleyici ayrıca bu sunucu geri döndüğünde izlemeli ve istek göndermeye devam etmelidir.

10. Oturum Hemen hemen her web uygulaması oturum durumlarına sahiptir, bunlar log-in durumu yada alışveriş listesini hatırlamak kadar basit olabilir. Http protokolü durumsuz olduğundan oturum durumu bir yere kaydedilmeli ve aynı uygulamadan tekrar istendiğinde geri çağrılabilmelidir. Yük dengeleyici için bazı tarayıcı oturumlarının isteklerini en son dağıtılan sunucu olgusuna dağıtmak en iyi çözümdür. Oturum durumu web sunucu olgusunun hafızasına yüklendiğinden yük dengeleme için oturum özellikleri önemlidir. Eğer bir sunucu olgusu güç kesilmesi gibi bir nedenle hata verirse bu sunucudaki oturum durumu kaybedilir. Yük dengeleyici bu hatayı bulmalı ve o sunucuya bir daha istek göndermemelidir. Fakat oturum durumu hata veren sunucuda kayıtlı olan istekler bütün oturum bilgilerini yitirirler ve bu da hataya neden olur. Bu durumda oturum failover ortaya çıkar. HTTPOturum (HTTPSession) Failover Şekil: HTTPOturum Failover Bütün popüler J2EE satıcıları bütün istemci isteklerinin oturum durumu yitirilmeden işletildiğinden emin olmak için kendi cluster ürünlerinde HTTPOturum failover gerçekleştirirler. Üstteki şekilde görüldüğü gibi tarayıcı, durumlu bir web uygulamasını ziyaret ettiğinde (1,2. adımlar) bu uygulama daha sonra kullanmak için hafızada oturum nesnesi oluşturabilir. Aynı zamanda tarayıcıya bu oturum nesnesini belirleyecek HTTPOturum kimliği gönderir(3. adım). Tarayıcı bu kimliği cookie (çerez) olarak kaydeder ve aynı web sunucudan sayfa istediğinde yeniden gönderir. Oturum failover desteklemek için web sunucudaki oturum nesnesi kendini yedeklemelidir(adım 4), böylece sunucu hatalarında oturum kaybı önlenir. Yük dengeleyici hatayı fark ettiğinde (5, 6. adım) sıradaki istemleri aynı uygulama içindeki diğer sunucu olgusuna gönderir. Oturum durumu bir yerde yedekli olduğundan bu yeni web sunucu olgusu oturumu geri getirir(adım 8) ve istemleri yürütür.

11 HTTPOturum failover gerçekleştiriminde şu kavramlar dikkate alınmalıdır.. Global HTTPOturum Kimliği(ID) Yukarda belirtildiği gibi HTTPSession kimliği hafıza içi oturum nesnesini belirlemede kullanılır. J2EE de HTTPOturum kimliği JVM olgusuna bağlıdır. Her JVM olgusu birden çok web uygulamasını tutabilir, her bir uygulama farklı kullanıcılar için birçok HTTPOturum tutabilir. HTTPOturum kimliği o anki JVM olgusunda ilgili oturum nesnesine erişmek için anahtar rolündedir. Farklı JVM olguları iki tane aynı HTTPOturum kimliği üretmemelidir, çünkü failover olduğunda bir JVM deki oturumlar yedeklenebilir ve diğerinden çağrılabilir. Sonuç olarak global HTTPOturum kimliği mekanizması gerçekleştirilmelidir.. Oturum durumları nasıl yedeklenir Oturum durumlarının nasıl yedeklendiği konusu J2EE sunucuyu özel yapmak ve diğerlerinden üstün kılmak için anahtar rolündedir. Farklı satıcılar farklı şekilde gerçekleştirmektedir.. Yedekleme sıklığı HTTPOturum durum yedeklemenin performans maliyetleri vardır(cpu devri, ağ bant genişliği, veritabanına yada diske yazma IO maliyeti gibi). Yedekleme sıklığı cluster performansını önemli ölçüde etkiler. Veritabanı devamlılığı yaklaşımı Bütün popüler J2EE cluster ürünleri oturum durumunuzu yedeklemeniz için size JDBC arayüzü üstünden ilişkisel veritabanı seçme olanağı sunar.alttaki şekilde görüldüğü gibi bu yaklaşım basitçe sunucu olgusunun oturum içeriğini serileştirmesi ve veritabanına yazmasıdır. Failover olduğunda diğer bir sunucu olgusu hatalı sunucunun sorumluluğunu alır ve veritabanından bütün oturum durumlarını geri alır. Nesnelerin serileştirilmesi önemlidir çünkü bu sayede hafıza içi verinin kalıcı ve taşınabilir olması sağlanır. Java nesne serileştirimi için http://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html adresine bakınız. Oturum durumunu veritabanına yedekleme Veritabanı sorguları maliyetli olduğundan bu yaklaşımın temel dezavantajı oturumlar içinde çok sayıda nesne saklandığında sınırlı ölçeklenebilir olmasıdır. Veritabanı oturumu kullanan çoğu uygulama sunucuları nesneleri saklamak için minimum HTTPOturumu kullanmayı savunur, fakat bu web uygulamasının mimarisini ve tasarımını kısıtlar. Buna rağmen veritabanı yaklaşımının bazı avantajları da vardır. Gerçekleştirimi kolaydır. Veritabanı paylaşımlı olduğundan oturum başka bir host a failover edebilir. Oturum bilgisi tüm öbek çökene kadar durur.

12 Hafıza kopyalama yaklaşımı Performans nedenlerinden ötürü bazı J2EE sunucu ları (Tomcat, JBoss, Weblogic, and Websphere) alternatif bir yaklaşım getirmiştir: Hafıza kopyalama Şekil: Oturum durumu için hafıza kopyalama Hafıza tabanlı oturum, oturum bilgilerini veritabanı yerine bir yada birkaç yedek sunucuda tutar. Bu yaklaşım yüksek performansı nedeniyle çok popülerdir. Veritabanı yaklaşımına kıyasla orijinal sunucu ile yedek sunucular arası ağ haberleşmesi çok önemsiz kalır. Ayrıca veritabanı yaklaşımındaki geri okuma aşamasına gerek kalmaz çünkü zaten oturum bilgisi yedek sunucuda bulunmaktadır. JavaGroups JBoss ile Tomcat öbekleme arasındaki haberleşme katmanıdır. Grup üyeliği protokolleri ve mesaj yayını gibi öbekleme için temel özellikleri sağlar. Daha fazla bilgi için http://www.jgroups.org/javagroupsnew/docs/index.html. adresine bakınız. Tomcat in yaklaşımı: Çoklu-sunucu kopyalama Hafıza kopyalamanın birçok değişik yöntemi vardır. İlki oturum bilgisini cluster daki bütün düğümlerde kopyalamaktır. Tomcat 5 bunu şu şekilde yapar.

13 Şekil: Çoklu-sunucu kopyalama Şekilde görüldüğü gibi bir sunucu olgusunda oturum değişirse o sunucu verilerini bütün diğer sunuculara yedekler. Bir sunucu olgusu hata verirse yük dengeleyici yedek olarak diğer sunucuyu seçebilir. Fakat bu yaklaşımın ölçeklenebilirlik açısından kısıtları vardır. Eğer öbekte çok sayıda olgu varsa ağ haberleşmesi maliyeti gözardı edilemez. Weblogic, Jboss ve WebSphere yaklaşımı- eşli sunucu kopyalama Performance ve ölçeklenebilirlik açısından Weblogic, JBoss ve Websphere başka bir hafıza kopyalama geliştirmiştir: Her sunucu olgusu oturum bilgisini tutmak için keyfi bir yedek olgu seçer.

14. Bu yolla her sunucu olgusu kendi eş yedek sunucusuna sahiptir Bu yaklaşım ölçeklenebilirlik problemine çözüm getirir, fakat şu kısıtları vardır:. Yük dengeleyiciye karmaşıklık getirir. Bir sunucu olgusu hata verirse yük dengeleyicinin hata veren sunucunun eşini bilmesi gerekir. Bu da yük dengeleyicinin alanını kısıtlar.. Normal istem gerçekleştirme haricinde sunucular kopyalama sorumluluğunu da almalıdır.. Normal işlem esnasında yedek oturumları tutmak için kullanılan hafıza, failover olmazsa yedek sunucularda boşa harcanır. IBM in yaklaşımı- merkezi durum sunucu Websphere de hafıza kopyalamaya alternatif bir çözüm vardır: Merkezi durum sunucuya yedek durum bilgisi. Şekil: Merkezi sunucu kopyalama Veri tabanı çözümüne çok benzerdir. Veritabanı sunucu yerine oturum yedek sunucu kullanılmıştır. Bu yaklaşım şu avantajları getirir:. Yürütülen işlemleri yedek oturum işlemlerinden ayırmak cluster ı daha sağlam yapar.. Bütün oturum bilgileri ilgili sunucuda yedeklenmiştir. Hafıza tüketen sunucu olgularına gerek yoktur.. Uygulama sunucu ile oturum yedek sunucu arasındaki soket haberleşmesi veritabanı bağlantılarına göre basit olduğundan daha iyi performans verir. Buna rağmen geri okuma aşaması nedeniyle performansı hafızanın eşler arasında direk kopyalandığı çözüm gibi olamaz. Ayrıca fazladan oturum yedek sunucuları karmaşa getirir.

15 Sun ın yaklaşımı- Özel veritabanı Sun JES uygulama sunucusu oturum failover a farklı bir yaklaşım getirir. Veritabanı yaklaşımına benzese de aslında JES in kullandığı veritabanı (HADB) oturum erişimi için optimize edilmiştir ve bütün veriyi hafızada tutar. Dolayısıyla merkezi durum sunucu yaklaşımına daha yakındır. JBoss ile J2EE Clustering -Singleton Service Singleton hizmet veren cluster içindeki düğüme efendi düğüm denir. Efendi düğüm hata verirse diğerleri arasından bir efendi seçilir ve servis tekrar başlar.

16 Uygulama sunucu dağıtımı Cluster ınıza uygulama sunucu olgularını dağıtırken cluster da tek düğümde birden çok uygulama sunucu olgusu istediğinize karar vermelisiniz, ve cluster daki toplam düğüm sayısını belirlemelisiniz. Bir düğümdeki uygulama sunucu sayısı CPU sayısına, kullanımına ve hafızaya bağlıdır. Cluster daki optimum düğüm sayısını belirlemek tekrarlı bir iştir. Öncelikle uygulamanın profili çıkarılır ve optimize edilir. Sonra maksimum kullanım için yük testi yapılır. Son olarak hata olduğunda yükü kaldıracak fazladan düğümler eklenir.

17 Oturum depolama anahatları Kırılmayı minimize etmek için uygulama sunucu ları anahatları takip edilmelidir: Bütün nesneler ve HttpOturumda özyineli olanlar serileştirilebilir olmalıdır ve java.io.serializable gerçekleştirmelidir. HttpOturumda nesnenin durumu değiştiğinde nesnenin değiştiğini belirtmek ve değişikliği yedek sunucuya kaydetmek için session.setattribute(...)çağrılır. AccountModel am = (AccountModel)session.getAttribute("account"); am.setcreditcard(cc); //You need this so the AccountModel object on the backup receives the //Credit card session.setattribute("account",am); ServletContext serializable değildir bu nedenle olgu değişkeni olarak kullanılamaz. EJB uzak nesneleri serileştirilemezler. Serileştirilemeyen durumlarda mekanizma aşağıdaki ile değiştirilir (Bu sınıf java.io.serializable gerçekleştirilmez çünkü superclass ı AccountModel bunu yapar).... public class AccountWebImpl extends AccountModel implements ModelUpdateListener, HttpSessionBindingListener { transient private Account acctejb;... private void writeobject(objectoutputstream s) { try { s.defaultwriteobject(); Handle accthandle = acctejb.gethandle(); s.writeobject(accthandle); catch (IOException ioe) { Debug.print(ioe); throw new GeneralFailureException(ioe); catch (RemoteException re) { throw new GeneralFailureException(re);

18 private void readobject(objectinputstream s) { try { s.defaultreadobject(); Handle accthandle = (Handle)s.readObject() Object ref = accthandle.getejbobject(); acctejb = (Account) PortableRemoteObject.narrow(ref,Account.class); catch (ClassNotFoundException cnfe) { throw new GeneralFailureException(cnfe); catch (RemoteException re) { throw new GeneralFailureException(re); catch (IOException ioe) { Debug.print(ioe); throw new GeneralFailureException(ioe); Oturum diskten geri yazıldığında ve HttpSession's setattribute(...) methodu her çağrıldığında HttpSessionBindingListener' ın valuebound(httpsessionbindingevent event) methodu çağrılır. Buna rağmen failover esnasında valuebound(httpsessionbindingevent event) çağrılmaz. Hafıza içi oturum durum kopyalaması Hafıza içi oturum durum kopyalaması veritabanı yaklaşımından daha zordur çünkü HttpOturum daki her bir nesne değiştikçe yedek sunucuda serileştirilebilir. Veritabanı yaklaşımı durumundaysa oturumdaki nesnelerin biri değişse hepsi birden serileştirilir. Hata durumunda uygulama çalışır fakat bazı özellikler çalışmayabilir- alışveriş kartı daha fazla parçayı reddedebilir örneğin. Problem, uygulamanızın aynı alışveriş kart nesnesine referans gösteren farklı parçalarından (alışveriş kartını güncelleyen ve gösteren) kaynaklanır. Tek sunucu durumunda bu durum görülmez çünkü her parça aynı nesneye referans gösterir. Aşağıda dolaylı kopyalayan nesnelerin örneği görülmektedir. import java.io.*; public class Aaa implements Serializable { String name; pubic void setname (String name) { this.name = name; public String getname( ) { return name;

19 import java.io.*; public class Bbb implements Serializable { Aaa a; public Bbb (Aaa a) { this.a = a; pubic void setname (String name) { a.setname(name); public String getname( ) { return a.getname(); In first.jsp on sunucu1: <% Aaa a = new Aaa(); a.setname("abe"); Bbb b = new Bbb(a); // a is copied to backup machine under key "a" session.setattribute("a",a); // b is copied to backup machine under key "b" session.setattribute("b",b); %> In second.jsp on sunucu1: <% Bbb b = (Bbb)session.getAttribute("b"); b.setname("bob"); // b is copied to backup machine under key "b" // but object Aaa under key "a" has the name "Abe" // and "b"'s Aaa has the name "Bob" session.setattribute("b",b); ---> Failure trying to get to sunucu1's third.jsp ----->Failover to sunucu2's (backup machine) third.jsp In third.jsp on sunucu2: The name associated with Object Aaa is: <%=((Aaa)session.getAttribute("a")).getName()%> The name associated with Object Aaa through Object Bbb is:

20 <%=((Bbb)session.getAttribute("b")).getName()%>... //End of third.jsp İlk ifade etiketi Abe çıktısı verirken, ikincisi Bob üretir. Tek sunucu durumunda her ikisi de Bob üretir. Kaynaklar: http://www.theserverside.com/articles/article.tss?l=j2eeclustering http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-extremescale2.html http://help.sap.com/saphelp_webas630/helpdata/en/2e/611724f410254ca12a3f396ec5ae85/content.htm http://www.onjava.com/pub/a/onjava/2003/08/20/jboss_clustering.html