Vaadin Architecture

Merhaba arkadaslar, bu yazımızda Vaadin mimarisine biraz bakınmış olacağız. İlk yazımızda Vaadin’in ne oldugundan, niçin/ne zaman kullanılması gerektiği durumları belirtmiş ufak bir örnek göstermiştik. Tabi bu örnek öğrenmeyi kamçılamak için idi şimdi ve sonraki yazılarımızda Vaadinin mimarisine, çalışma şekline daha çok yer vereceğiz.

Vaadin Architecture

Vaadinin temelinde iki yaklaşım oldugundan bahsetmiştik hatırlarsanız. Bunlar client-side ve server-side idi. Bu iki yaklaşım ayrı ayrı kullanılabileceği gibi beraber de kullanılabilir. Bu yazımızda mimari konusuna değinirken, bir önceki yazımızda kullandıgımız örneği detaylandıracağız.

Server side yaklaşımı daha çok tercih edilmekle birlikte client-side ile beraber de oldukça kullanılır. Client-side model de widget’lar ve java kodları javascript’e çevrilierek browserda görüntülenir. Çevirme işlemi GWT ile yapılır arka planda. İki yaklaşım da servislerini paylaşabilir, entegre olabilir birbirine.

Aşağıdaki mimari çizimde web browserdan bir sayfaya gelen isteğin karşılanması ve load olunması bulunmaktadır;

 

architecture-detailed-hi

 

Client side tarafından server side tarafına AJAX ile iletişim kurulur. Her fırsatta Servlet’leri öğrenerek Java EE olaylarına girmenin mantıklı olacagını ifade eden biriyim. Yukardaki şekilde görebileceğiniz gibi istekleri karşılayan bir SERVLET’TIR. Portlet de kullanılabilir ama ona deginmeyecegiz şuan. Servlete gelen istek handle edilir, theme build edilecekse edilir, componentlar varsa oluşturulur. Business logic ihtiyacı var ise karşılanır en sonunda html sayfa olarak tarayıcıya dönülür. Themes sunumdan sorumludur, Data binding ise MVC’deki modele karsılık gelmektedir. Ek olarak client-side tarafı içerisinde Vaadin Compiler olan Java kodlarını Javascripte çeviren yapıyı barındırır.

 

Vaadin Servlet, bildigimiz pure Servlet class’ıdır ve Servlet Contaıner içerisinde çalışmaktadır. Url mapping yapılan url’e bir HTTP isteği geldiginde servlet isteği handle eder ve yukarda belirttigim gereksinimlere göre ihtiyaclar giderilip nihayetinde tarayıcıya cevap dönülecektir.

Mimarideki başlıkları açıklayalım;

  • User Interface : Business logic ile data model arasında yer alır ve kullanıcı arayüzü sunar. Her Vaadin application mutlaka en az bir UI’a sahiptir. UI, com.vaadin.ui.UI sınıfından extend edilmis bir class’tan ibarettir. İstek geldiginde ui load olunur, loda olurken ui’da bulunan componentler oluşturulur, buton click event listener vs oluşturulur. Bir sayfada birden fazla ui olabilir, bir ui birden fazla sayfada yer alabilir.
  • User Interface Component : Client-side tarafta bulunan user component’lerin bir karışılığı da server-side tarafında bulunmaktadır. Buton, link, layout gibi bileşenlerdir.  İlerde belki  Vaadin Cheat Sheet konusuna değinebiliriz.
  • Theme, VaadinServlet ve Events bileşenlerini kısmen yukarda tanımladık.
  • Server push : Event driven modelde ilgilenilen bir durum meydana geldiginde notification yayınlanır ve durumdan haberdar edilir. Vaadin, server push yaklaşımını destekler. Örneğin multithread olan applicationda threadlerden biri bir değişkenin durumunu/state değiştirdi, eger server push enabled ise ilgili değişiklik hemen sayfada update olacaktır. Bu yaklaşımda client’in refresh yada update gibi bir isteği bulunmamaktadır. Server push enabled etmek için vaadin-push jar dosyası projeye eklenmelidir ve server push edilecek olan UI classının başına @Push ile üzerinde barındırdıgı componentlerde olan bir degisiklikte clienttan istek beklemeden ui’yin güncellenmesi gerektigini belirten annotation koyulmalıdır. 
  • Back-end : Bu kısım tamamen business logic olarak adlandırılabilir. MCV’deki Controller olacaktır.

Bir önceki yazımızda kullandıgımız olan örneği hatırlayalım;

Yukarıdaki örnekte bir UI’ımız bulunmaktadır. Vaadin request geldiginde ki bu Http requesttir ve Servlete yapılan isteğin aynısıdır. init ile ui üzerindeki componentleri oluşturup event tanımlaması yapmış bulunuyor. Desktop application’lara oldukca benzer olmakla beraber daha kolaydır. Bir UI oluşturdugunuzda bunu bir url ile mapping etmeniz, ilişkilendirmeniz gerekmektedir. Bunun için inner bir servlet class olan ve VaadinServletten extend edilen servlet ile mapping ediyoruz. Annotationlarla yapılan yukarıdaki işlemde context path’den sonra gelen her url isteğini VaadinHelloWordUI karşılacayaktır.

Yukarıya @Push parametresini ekledim. Bu otomatik/default olarak şöyle algılanacaktır; PushMode.AUTOMATIC. @Push mekanizmasına daha sonra deginecegim, Broadcast yayınlama Receiver vs gibi konular var burada, giriş yazıları degil ama ilerleyen yazılarda değineceğiz kısmetse.

 

Örnekte Annotationlarla yapılmasına rağmen ben deployment file’dan yapılmasını tavsiye ederim. Çünkü; yarın olur da url mappingi degistirmek zorunda kaldınız, Annotation ile yapmış iseniz ilgili class’a gidip class içerisinden bu degisikliği yapmalısınız ve yeniden compile etmelisiniz. Eğer web.xml içerisinden bu mappingi yapmış iseniz sadece dosyası update eder eskisi ile degistirir yolunuza bakarsınız

Aynı mappingi web.xml ile yapalım;

Vaadin servlet configürasyondaki protectionMode kısmını ise context-param olarak ekleyebilirsiniz. Bu degisken default olarak true degerini alır ve vaadin application’un debug modde çalıştığını temsil eder.

Yine server push özelliğini web.xml’den şu şekilde ayarlayabilirsiniz. Eğer pushmode automatic olursa ui, client istek atmadan update olabilecektir. Eğer manuel seçili olursa push() methodunun kullanılması gerekecektir.

Yazımızı burada sonlandırıyoruz arkadaslar.

~ A.Akkus

 

962 Total Views 2 Views Today