Java kullanarak client-server uygulamalar geliştirenler bilirler, bu iş hem çok kolay hem de oldukça keyiflidir. Keyifli olmasının en büyük nedeni ise sanırım dertsiz ve bug sız olması :)

Socket ve ServerSocket nesnelerini kullanıp birde bunların üstüne object serialization mekanizmasından da faydalanırsanız 3-5 satır kod ile hemencecik bir client-server uygulama geliştirebilirsiniz.

Tabii bu işin daha başlangıcı. Özellikle server tarafında 100+ kullanıcıyı destekleyecek bir yapı kurmayı düşünüyorsanız aslında herşeyin o kadar da parlak olmadığını görmeniz fazla sürmüyor. Problemin kaynağı ise Java nın client-server haberleşmesinde kullandığı blocking mekanizma. Siz bir ServerSocket oluşturup daha sonra accept() ile bu socket üzerinden bir bağlantı kabul ettiğiniz zaman sistem haberleşme için kullanabileceğiniz bir Socket nesnesi oluşturur. Bu nesne size bağlanan istemci ile haberleşmede kullanabileceğiniz yegane araçtır.

Buraya kadar herşey güzel, fakat siz bu socket üzerinden doğal olarak veri okumaya kalkıştığınızda veri bulunamadığı zaman programın o noktada yeni bir veri paketi gelinceye kadar tıkandığını görürsünüz (blocking). Eğer sadece bir client ile haberleşecekseniz sorun yok, fakat ya birden fazla client ile haberleşmeniz gerekiyorsa (tipik oyunlarda olduğu gibi). Çözüm her haberleşen client için ayrı bir thread yaratıp senkronize olarak haberleşmeyi sağlamak(tı). Yani en azından ufak uygulamalar için yapılan şey bu idi. Gayet basit ve uygulaması kolay bir yöntem. Tabii birden fazla thread işin içine girince ortak kullanılan verilere senkron erişimi kontrol etmek için çeşitli kilit mekanizmaları (mutex, lock ...) kullanmak gerekiyordu, ee gülü seven dikenine katlanır.

Peki bu sistemde problem ne? Problem şu: kullanıcı sayınız arttıkça thread sayınızda artıyor. Her ne kadar Java thread leri lightweight olarak adlandırılsa da (yani bellekte az yer kaplayan, fazla işlen gücü gerektirmeyen) siz thread sayısını 100+ gibi rakamlara çıkarınca doğal olrak bellek tüketiminiz de artıyor. Ama daha da önemlisi bir süre sonra o kadar fazla thread iniz oluyor ki, bunlar arasında jvm tarafından gerçekleştirilen periyodik switching ve bakım işlemleri çok fazla zaman almaya başlıyor, ki uğraşmanız gereken ortak kullanılan nesneler de cabası. Yani bir süre sonra performans yerlerde sürünmeye başlıyor(du).

Bu probleme çözüm olarak new io olarak adlandırılan yeni bir IO sistemi dile kazandırıldı ve java.nio ismi ile standart kütüphaneler arasına katıldı (java 1.4 sürümü ile). Bu kütüphane diğer birçok getirdiği yeniliğin yanı sıra konumuz olan blocking socket olayında da bir alternatif yöntem ortaya çıkardı. Ehe, non blocking io.. :).. Aslında biz zaten bu olayı win32 ve unix socket lerini kullanarak ezelden beri gerçekleştiriyorduk fakat Java için bir ilkti bu.

Java.nio kullanarak birden fazla stream üzerinden nonblocking okuma yapabiliyorsunuz. Sistem üzerinde veri bulunan bir stream ile karşılaştığı zaman size otomatik olarak haber veriyor, yani arkada bekleyen n adet veri yolunu periyodik denetleme işini kendisi etkin bir biçimde gerçekleştiriyor. Burada etkin den kastım şu. JVM üzerinde çalıştığı platformun nonblocking desteğinden direk olarak faydalanıyor. Yani bu iş win32 ya da posix socket ler ile ne kadar hızlı yapılabiliyor ise java.nio ile de o kadar etkin yapılabiliyor.

Peki güzel, o zaman bunu kullanalım derken aslında yapının çok da kolay kullanılabilir birşey olmadığını anlamanız pekte uzun sürmüyor. En azından eski-güzel-basit kullanımdan daha zor ve karışık olduğu aşikar. (ama yine de win32 kullanımı ile karşılaştırmıyorum, bu bile 1000kat kolaydır orası ayrı..)

İşte burada MINA kütüphanesi devreye giriyor. Üff , evet bu kadar yazı sonunda nihayet amacımıza ulaşabildik. :)

MINA, apache jakarta proje grubunun kanatları altındaki yüce programcılar tarafından geliştirilmiş ve şu anda 1.0 sürümünde bulunan bir nio yardımcı kütüphanesi. Yaptığı şey basit olarak: sizi java.nio ayrıntıları ile boğuşturmadan nio kullanan bir network arayüzü oluşturabilmenize olanak sağlamak. Yani oldukça yüksek seviyeli bir nio arayüz kütüphanesi diyebiliriz. Ayrıca tabii ki bu kadarla da sınırlı kalmıyor,günümüz yazılım sistemlerinde çok sevilen ve popüler olan scalability konusunda da bize yardımcı oluyor. Birkaç ufak api çağrısı ile network yapımızın n adet thread i desteklemesini sağlıyabiliyor. Üzerindeki yüke göre bu sayıyı çalışma zamanında optimize edebiliyor. Hberleşmeyi katmanlı bir model haline getiriyor. Aklınıza gelebilecek her türlü protokolü ve filtreleme mekanizmasını kolayca işleyen sisteminize ekleyebiliyorsunuz.

Örneğin: oluşturduğunuz bir haberleşme protokolünü değiştirmek, geliştirmek, yeni bir versiyonunu işleyen yapınızı bozmadan sisteme entegre etmek MINA ile çok daha kolay.

Örneğin: haberleşme protokolünüze çeşitli filtreler eklemek çocuk oyuncağı. Mesela ssh desteği, yada veri sıkıştırma, yada şifreleme, yada loglama yada ... aklınıza ne geliyorsa. Bunların bazıları MINA ile zaten geliyor, diğerlerini yapmak ise MINA api si ile düşündüğünüzden çok daha kolay olacak.

Örneğin: sunucudaki kullanıcı sayısı 10 dan 1000 e çıkınca ne olacak?, thread pool lar ne işe yarar? hani benin scalabilitim? diyorsanız.. hiç boşuna uğraşmayın, bırakın bu işleri MINA halletsin.

Evet, aslında böyle elle tutulur , gözle görülür birşeyler olmadığı için MINA yı ve konsepti anlatmak ve anlamak oldukça zor. İşin içine girmeniz, uygulamalara bakmanız ve en önemlisi bu alanda çalışıyor olup gerçekten bu işin tıkandığı noktalar konusunda bilgi sahibi olmanız (buna ihtiyaç duymanız...) gerekiyor. O zaman MINA ya bakıyorsunuz ve ... hoşunuza gidiyor :)

http://directory.apache.org/subprojects/mina/

deniz.