Üretim Hattında Spring (1)

Yazar: Adrian Colyer, CTO, Interface21 October 2007

Çeviri ve Türkçe’ye uyarlama: Kenan Sevindik
Spring Framework ve Spring Portföy’ündeki ürünler dünya genelinde ki her tür endüstride, yaşamsal öneme sahip pek çok uygulamada kullanılmaktadır. Spring programlama ve konfigürasyon modeli net biçimde anlaşılır, ve dokümante edilmiş olup, bugün dünya genelinde binlerce uygulama geliştirici tarafından tecrübe edilmiştir. Bu makale, bu tür uygulamaları yöneten “operasyonel ekipler” için yazılmıştır. Spring’i farklı bir açıdan ele almaktadır; Spring çalışma zamanı (runtime)ortamı ve kurumsal uygulamaların işletilmesinde bu ortamın oynadığı kritik rol.

Giriş

Spring Framework ve Spring Portföy’ündeki ürünler dünya genelinde ki her tür endüstride, yaşamsal öneme sahip pek çok uygulamada kullanılmaktadır. Örneğin, İngiltere’deki hemen hemen bütün bankalararası transfer işlemleri Voca isimli bir firma tarafından yönetilmektedir. Voca, yoğun günlerde 80 milyonun üzerinde operasyonu işlemekte, İngiliz halkının %70’inden de fazla bir kesiminin fatura, ve %90’lık bir kesiminin de maaş ödemelerini idare etmektedir. Voca, bugüne kadar tek bir ödeme ile ilgili işlemi kaybetmemesi ile övünmektedir. Bütün bu operasyonlar Spring ile güçlendirilmiştir. Örneğin, yakın bir zamanda HSBC Interface21 ile üretim hattındaki uygulamalarında hayati önem arz edecek derecede Spring kullanmaya yönelik bir destek anlaşmasına girmiştir. Diğer bir örnek,dünya üzerindeki kargo hareketlerinin %25’inin yönetimi Navis tarafından, Spring destekli bir uygulama ile gerçekleştirilmektedir. Spring programlama ve konfigürasyon modeli net biçimde anlaşılır, ve dokümante edilmiş halde olup, dünya genelinde binlerce uygulama geliştirici tarafından kullanılmaktadır. Bu makale, bu tür uygulamaları yöneten “operasyonel ekipler” için yazılmıştır. Spring’i farklı bir açıdan ele almaktadır; “Spring çalışma zamanı ortamı ve kurumsal uygulamaların işletilmesinde bu ortamın oynadığı kritik rol”. Spring çalışma zamanı kapsamlı bir alan olup, çok çeşitli sayıda uygulama servisini barındırmaktadır. Bu makalede, Spring ile güçlendirilmiş pek çok uygulama tarafından kullanılan çekirdek çalışma zaman bileşenlerine (core runtime componenets),ve Spring ile desteklenmiş bir uygulamanın performans ayarlamasının nasıl yapılacağına odaklanacağız.

Spring çalışma zamanı yüksek düzeyde kalitesi ve rüşdünü doğrudan üretim ortamında ispat etmesi ile haklı bir üne sahiptir. Spring kullanan uygulamaları destekleyen operasyonel ekiplerin yararını gözetmek amacı ile, farzı muhal, çalışma zamanında, bileşenlerde herhangi bir sorun olsa, gözlemlenebilecek belirtileri açıklamaya çalışacağız. Tabi ki, bu tür durumlarla kesinlikle karşılaşmamanızı ümit ederiz!

Spring Çalışma Zamanına Genel Bir Bakış

Spring çalışma zamanı üretim hattındaki uygulamaların işletilmesinde hayati bir rol oynamaktadır. İşin en temel noktasında, Spring çalışma zamanı uygulama bileşenlerinin yaratılmasından, yönetilmesinden, ve bu bileşenler tarafından karşılanan her bir isteğin yürütülmesinden sorumludur. Bu temelin de üstünde, Spring çalışma zamanı kaynaklara erişim, transaction, güvenlik, mesajlaşma vb. pek çok diğer kritik kurumsal servisi yönetmektedir.
Spring çalışma zamanının tam kalbinde “Spring core container” yer almaktadır. Bunun da üzerinde AOP (aspect oriented programming) ve kaynak yükleme (resource loading) ile ilgili çalışma zamanlı bileşenlerin yer alması ile Spring çalışma zamanının çekirdeği (kernel) ortaya çıkmaktadır. Bu çekirdek, uygulama bileşenlerini yaratıp, ayarlarını yapmakta, ve bu bileşenler tarafından karşılanan herbir isteğin yürütülmesini sağlamaktadır.
Spring’in extension mekanizmaları ile doğrudan bu çekirdeğe eklemlenen, örneğin “namespace handler” ve “post-processor”lar da kurumsal uygulamaların ihtiyaç duydukları hayati öneme sahip servisleri sağlayan çalışma zamanlı bileşenlerdir. Bu bileşenler kurumsal servis katmanını oluşturmaktadır. Bu bileşenler, iş mantığı ile ilgili işlemlerin transaction içerisinde yürütülmesi, hataların ele alınması, gelen mesajların uygulama bileşenlerine yönlendirilmesi, güvenlikle ilgili bağlamların (context) vs. oluşturulmasını sağlar.

Şekil 1: Spring çalışma Zamanına Genel Bir Bakış

Spring Çalışma Zamanı: Çekirdek (Kernel)

Spring çalışma zamanı, uygulama bileşenlerinin yönetilmesinde temel bir role sahip “core container”, bileşenler üzerindeki operasyonların uyandırılmasını idare eden AOP, kaynak yükleme merkezi, ve olay yönetim alt sisteminden oluşmaktadır.

UYGULAMA BİLEŞENLERİNİN YÖNETİMİ

Spring çekirdeğinin kurumsal bir uygulama başalatılırken ön yüklenmesi (bootstrap) gerekmektedir. Çekirdek, bir kere ayağa kalkıp, çalışır duruma geçtiğinde aşağıdaki ana sorumlulukları yerine getirir:

uygulama tarafından ihtiyaç duyulan bileşenlerin tespit edilmesi
bu bileşenlerin konfigürasyon bilgilerinin sağlanması
bileşenlerin bağımlılık şemasının oluşturulup, yaratılması
bir bütün oluşturacak biçimde bileşenlerin birbirlerine monte edilmesi
belitilen özellikte bir istek karşılama hattının (request dispatching pipeline) kurulması için bileşenlerin dekorasyonu
uygulama bileşenlerinin faaliyet alanlarının ve yaşam döngülerinin yönetilmesi

Bu sorumluluklar aşağıda detaylı biçimde incelenmektedir.

Ön Yükleme (Bootstrapping)

Spring “application context” uygulama için çalışma zamanlı bir bağlam sunar. Uygulama bileşenleri yaratılmadan evvel bir “application context” yaratılmalıdır. Bu bazı uygulamalarda doğrudan programatik olarak yapılmaktadır. Spring kullanan pek çok uygulama için ise Spring’in sağladığı herhangi bir ön yükleme mekanizması yardımı ile otomatik olarak gerçekleşmektedir. Örneğin, bir web uygulamasında Spring’in sağladığı DispatcherServlet başlangıç noktası konumundadır. OSGI tabanlı bir uygulamada ise Spring’in “extender bundle” mekanizması benzer bir görev icra etmektedir.
“Application context” yaratıldığı vakit, uygun bir kaynak yükleme yöntemini kurarak ve Spring “namespace handler”larını tespit edip,kaydederek kendisini çalışma zamanının ortamına uyarlamaktadır. “Namespace handler”lar, “core container”ın XML şema şeklinde tanımlanmış konfigürasyon bilgisini yorumlamasına, bu XML konfigürasyon bilgisindeki eleman ve öznitelik tanımlarının deklare edilmiş uygulama ihtiyaçlarına uygun biçime dönüştürülmesine olanak sağlar.
Ön yükleme fazındaki herhangi bir arıza uygulamayı çalışmaz kılacaktır. Örneğin, bir “namespace handler”ın tespit edilip kaydedilmesindeki bir başarısızlık, eğer uygulama konfigürasyon tanımlarında bu “namespace” içinden XML elemanları kullanılmış ise, “application context”in oluşturulmasında başarısızlık anlamına gelmektedir.

Bileşen Konfigürasyonunun Tespit Edilmesi

Ön yükleme yapıldıktan hemen sonraki kritik aşama, oluşturulması gereken uygulama bileşenlerinin tespit edilmesi, bu bileşenlerin nasıl ayarlanacağı ve ne tür destek servislerine ihtiyaç duyduklarının belirlenmesidir.
Konfigürasyon bilgisi pek çok değişik kaynaktan gelebilir. Bu kaynaklar, ön yükleme aşamasında tespit edilmektedir, ve yine konfigürasyon dosyaları içerisinde belirtilen ilave konfigürasyon metadata kaynakları ile de desteklenmektedir. Örneğin, konfigürasyon bilgisi genellikle birden fazla XML dosyasından sağlanmaktadır. Bu konfigürasyon dosyalarından birisi, Spring 2.5 ile birlikte sağlanan bileşen tarama (component scanning) kabiliyetini aktive edebilir. Bileşen tarama özelliği classpath üzerindeki kaynakları tarayarak ilave konfigürasyon metadata bilgisini tespit etmektedir.
Kayıtlı “namespace handler”lar ve diğer “metadata handler”lar konfigürasyon kaynaklarını işleyerek oluşturulacak altyapı ve uygulama bileşenlerini tespit ederler. Bunların ürettiği, belirtilen uygulama konfigürasyonunu yansıtan “bileşen tanım nesneleri”dir. Uygulama tarafından ihtiyaç duyulan bileşenlerle ilgili bilginin yanında, bu çalışma zamanlı tanım bileşenler arasındaki bağımlılıkları ve konfigürasyon değerlerini de içerir. Kurumsal servis katmanındaki servisler ve uygulama konfigürasyonu da bir veya daha fazla “post processor”ü bileşen tanımları üzerinde doşalmaları, üzerlerinde ilave dönüşümler yapmaları için kaydettirmiş olabilir.
Uygulama başlangıcının bu çok önemli evresi, konfigürasyon bilgileri ile ifade edilmiş uygulama planının (gerekli bileşenler ve onların ayarları) başarılı bir biçimde hafızada yaratılmasını, bir sonraki evrede de konfigüre edilmiş, tam fonksiyonel uygulama nesneleri olarak hayata geçirilmesini garanti eder.
Uygulama planının çıkartılması aşamasında oluşabilecek arızalar, kayıp veya eksik ayarlanmış bileşenlere yol açabilir. Uygulama geliştiriciler tarafından ifade edilen uygulama planının tam olarak oluşturulması bu safhada bir zorunluluktur.

Yaratma, Konfigürasyon ve Montaj

Çekirdeğin çalışma zamanında ki bir sonraki görevi uygulama planını analiz ederek gerekli bileşenleri yaratmaktır. Container bu işlem sırasında bileşenlerin sağlıklı bir sırada yaratılabilmesi için aralarındaki bağımlılıkları ve sıralama kısıtlarını hesaba katmak zorundadır.
Konfigürasyon planı, bileşenlerin ne şekilde oluşturulacağını tanımlamaktadır. Bileşen oluşturma süreci, içine nesnelerin dizin veya servis kütüğünden elde edilmesi, fabrika metodları vasıtası ile yatatılması veya uzak sistem servislerine referans oluşturulması işlemlerini alacak kadar karmaşık bir süreçtir. Yeni bileşenlerin ayarları XML, property dosyaları, placeholder ifadelerinin çevrilmesi gibi yöntemlerle elde edilen konfigürasyon verisi ile gerçekleştirilmektedir. Container String tipindeki verinin, bileşenlerin ihtiyaç duyduğu tiplere çevrilebilmesi, List, Map ve Set gibi yapıları kullanarak konfigürasyon verisinin oluşturulabilmesi için gelişmiş bir desteğe sahiptir. Bir bileşen aynı zamanda işbirliği yaptığı diğer bileşenlerle (bu bileşenin etkileşimde bulunması gereken uygulamanın diğer bileşenleri) beraber yapılandırılmaktadır. En basit manada, işbirlikçi bileşenler (collaborators) isimleri vasıtası ile tespit edilirler, fakat container diğer farklı bir takım yöntemleri, örneğin isim ve tip kriterine bakarak da, bu işbirlikçi bileşenleri tespit edebilir.
Spring uygulama bağlamının (application context) oluşturulması ve ayarlar sırasında ortaya çıkabilecek arızalar, uygulama bağlamının başarılı biçimde ayağa kalkmasını engeller ve sonuç olarak uygulamayı çalışmaz bir halde bırakır. Böyle bir durumda “Exception during initialization” mesajı log dosyalarında belirecektir.

Bileşenlerin Son İşlemeye (Post Processing) Tabi Tutulması

Kurumsal servis katmanındaki servisler, bir veya daha fazla bileşen (bean) son işlemcisini (post processor) “container”a kaydettirmiş olabilir. Bunlara ilave olarak, ayar dosyalarında da kullanıcı düzeyinde son işlemciler tanımlanmış olabilir. Spring çalışma zamanı bu son işlemcileri bir sıraya koyar ve bileşenlerin yaratılmasından sonra bunları sırayla çalıştırır. Kurumsal servis katmanı tarafından kayıt ettirilen pek çok son işlemci bir sonraki bölümde anlatıldığı gibi bileşenleri dekorasyona tabi tutar.

Dekorasyon

Spring bileşenlerin iş mantığındaki çapraz kesen davranışlarını – örneğin transaction namespace’indeki davranışlar, AOP namespace’i ile tanımlanan aspectler veya annotasyonlu sınıflar gibi – tanımlamak için basit bir dekleratif model sunmaktadır. Bu deklerasyonları çalışma zamanında ki ilgili iş mantığını barındıran ara ürünlere (artifact) çeviren mekanizma çok daha karmaşıktır.
Temel yaklaşım ilk once bu bileşen metodları her çağırıldığında çalıştırılması gereken çapraz kesen işlerin olup olmadığını görmek için bu operasyonların tespit edilmesidir. Örneğin, “transaction demarcation” söz konusu mudur? Bir dizi eşleştirme stratejileri mevcuttur, ancak en yaygını bir AspectJ “pointcut” ifadesinin değerlendirilmesidir. Bu işlem ifadenin parse edilmesi ve ilgili metod ile eşleştirilmesini kapsamaktadır. Tespit aşamasından sonra eğer bir veya daha fazla bileşenin metodlarının yine bir veya daha fazla aspect ile advise edilmesi sözkonusu ise, Spring çalışma zamanda ilgili metodlar çağırıldığında (metod çağrısından öce, sonra veya çağrının etrafında) bu advice’ların çalıştırılmasını sağlayacak proxy nesnesini üretir. Bir metod için birden fazla advice’ın çalıştırılması gerekebilir. Bu durumda çekirdeğin sıralama kısıtlarına uyması gerekmektedir. Proxy nesnelerinin üretilmesi ya JDK dinamik proxy ya da çalışma zamanında alt sınıfların yaratılması ile gerçekleştirilir. Container aynı zamanda gerekli davranışın çok daha etkin biçimde üretilmesini sağlayabilen AspectJ load time weaving özelliği ile entegre çalışacak biçimde de ayarlanabilir. Bu durumda uygulama sınıflarının çalışma zamanında byte code düzeyinde ilgili davranışı sergileyecek biçimde değiştirilmesi söz konusudur.
Bazı durumlarda belirtilen bir bileşen metodunun statik yöntemlerle herhangi bir “advise”a tabi tutulup tutulmayacağını tespit etmek mümkün olmayabilir. Böyle bir durumda çekirdek her metod çağrısında yapılacak test işlemini belirlemektedir. Bu test, örneğin, verilen bir argümanın belirli bir tipin nesnesi olup olmadığının kontrolü şeklinde olabilir.
Dekorasyon fazının sonunda artık çapraz kesen servislere ihtiyaç duyan bileşenler için proxy nesneleri oluşturulmuştur, ve gerçek uygulama nesnelerinin yerine bu proxy nesneleri kaydedilmiştir. Dekorasyon fazı kritik kurumsal servislerin, örneğin transaction ve güvenlik yönetimi gibi, temelini oluşturmaktadır.

Bileşenlerin Yaşam Döngüsünün ve Faaliyet Alanlarının Yönetilmesi

Bileşenlerin oluşturulması, ayarlanması, ve dekorasyonu işlemlerinden sonra da container’ın görevi sürmektedir. Bileşenler belli bir yönetime tabi tutulması gereken farklı yaşam döngülerine sahip olabilirler. Örneğin, bir istek boyunca aktif olacak bir bileşen, kendisine erişim söz konusu olan her bir istek sırasında yeniden yaratılmalıdır. Container içindeki bütün singleton olmayan bileşenlerin yaşam döngülerinin sonundaki yıkımlarından da container sorumludur.

İSTEKLERİN SEVKİ (REQUEST DISPATCHING)

Çekirdek, dekorasyona tabi tutulmuş veya belirli bir kapsama alanına sahip bileşenin çalıştırılma hattına ayrıntılı biçimde müdahil olmaktadır. Bu bileşenler üzerinde herhangi bir metod çağırıldığı vakit Spring çalışma zamanı ilk önce, varsa dekorasyon fazında AOP alt sistemi tarafında ayarları yapılmış olan, “interceptor”’leri çalıştırmaktadır. Bu “interceptor”lerden bazılarının çalıştırılması daha evvelden belirlenmiş olan çalışma zamanlı testlere göre gerçekleşebilir. Bu durumda ilk önce bu testler uygulanır, ardından sadece bu testlere göre seçilen “interceptor”ler çalıştırılır. Spring AspectJ’nin “pointcut” ve “advice” modelini “fully typed advice” olarak sağlamaktadır. Bunun anlamı çalışma zamanının elde ettiği bağlamsal bilginin (contextual information) “advice” metodundaki parametrelere bağlamasıdır (bind). Eğer çalıştırılan “advice” işlemin devamına işaret ederse, işte o zaman çalışma zaman hedef bileşeni metod çağırsını gerçekleştirmek için seçer. Basit durumlar için hedefteki bileşen her zaman aynıdır, fakat belirli bir kapsama alanına sahip bileşenler, örneğin “request scoped” bir bileşen için çalışma zaman o andaki aktif alanda yönetilen bileşeni seçer.
Bileşenin metodunun çalışıtılmasından sonraki safhada da AOP çalışma zamanı metod değerini dönmeden evvel “interceptor” zincirini çağırmalıdır. Metodun çalıştırılmasından sonraki bu çağrılarda öncesinde olduğu gibi bir takım çalışma zamanlı testlerin çalıştırılmasını ve parametrelerin bağlanmasını (bind) içermektedir. “Interceptor”lerin çalıştırılması dönen değerlere göre belirli koşullara tabi olabilir veya “exception” fırlatılması sözkonusu olabilir. Dekorasyon fazı AOP alt sisteminin düzgün biçimde ayarlandığını garanti eder, fakat metod çağrılarının çalışma zamandaki yönetimi kurumsal servislerin her seferinde doğru biçimde çalışmalarını sağlar.

KAYNAK YÜKLEME (RESOURCE LOADING)

Kaynak yükleme bileşeni diğer kısımlara göre göreceli olarak küçük olmasına rağmen çekirdeğin (kernel) önemli bir parçasıdır. Bu parça, container her ihtiyaç duyduğunda ilgili kaynakların yüklenmesinden sorumludur. Classpath, dosya sistemi, InputStream, byte array vb yerlerden kaynakların yüklenmesi desteklenmektedir.

OLAYLAR

Çekirdek ayrıca olay (event) yönetim alt sistemine de sahiptir. Bu alt sistem uygulama bağlamında meydana gelen olayların yayımlanması ve herhangi bir uygulama bileşenine bu olayların ulaştırılması ile ilgilenir. Normal şartlarda olayların teslimi senkrondur ve bu teslim olayı yayımlayanın “transaction context”i içerisinde meydana gelir. Bu davranışı isteğe gore özelleştirmek mümkündür.Örneğin, Spring Security bu olay yönetim sistemini güvenlikle ilgili olayların yaratılması ve yayımlanmasında kullanmaktadır. Eğer Spring kümeleme (cluster) yapılmış bir ortamda kullanılıyorsa, kümleme ve kaşe (cache) alanındaki pek çok üretici, uygulama bağlamı ile ilgili olayların küme genelindeki bütün sistemlere dağıtılmasını desteklemektedir.