Corebanking Next Generation

Yaklaşık 10 aylık bir çalışmanın sonunda 1 şubat 2011 tarihinde İşbankası Corebanking projesindeki görevimi tamamladım. Corebanking projesi, İsbankası’nın 2 sene önce başlatmış olduğu, Cobol ile geliştirilen Mainframe sistemlerinden açık sistemlere (Java, J2EE) geçişi öngören bir proje. Projenin nihayi amacı uzun vadede bankanın alt yapısını tamamen açık sistemlere taşımak ve Mainframe sistemlerini devre dışı bırakmak.

Danışman, teknik ekip lideri ve programcı olarak çalışmış olduğum bu 10 aylık zaman diliminde, Corebanking projesindeki faaliyet alanlarım şu şekilde oldu:

  • Test güdümlü yazılımın proje genelinde kullanımı
  • Continuous Integration ve Continuous Deployment gibi çevik metotların projeye entegrasyonu
  • Yazılım sürecinin iterasyon bazlı organizasyonu (Extreme Programming)
  • Build işlemlerinin otomatize edilmesi (Ant,Maven)
  • Lokal yazılım geliştirme işlemi için Websphere uygulama sunucusunun devre dışı bırakılması ve uygulama sunucusu kullanmak zorunda kalmadan test güdümlü yazılım yapılabilmesi
  • Lokal testler için gerekli referans verilerinin cachelenmesi ve uygulama sunucusunun start-up zamanının optimize edilmesi
  • Veri tabanı üzerindeki yükü azaltmak için proje genelinde bir caching mekanizmasinin implementasyonu (hazelcast)
  • Maven kullanılarak tüm Corebanking projesinin modüler bir yapıya geçirilmesi
  • Nexus kurulumu ve otomatik dependency yönetimi
  • Performans analizi ve logmalası için AOP (Aspect Oriented Programming) kullanımı
  • Performans testlerini yapılması ve performans testlerinde ortaya çıkan problemlerin lokalizasyonu ve eliminasyonu
  • Ekibin çevik süreç, çevik metotlar ve tasarım prensipleri konusunda eğitimi
  • Code ve architecture review
  • Açık sistemler ile Mainframe arasındaki komunikasyonu sağlamak için REST tabanlı bir mimarinin oluşturulması (JBoss EasyREST)

İlk çalışma alanlarımdan birisi build ve deployment işlemlerini otomatize etmek oldu. Bunun için gerekli Ant skriptleri oluşturdum ve build işlemlerinin merkezi bir yerden tetiklenmesini sağladım.

Bir proje bünyesinde kodun sürekli entegre edilmesi (Continuous Integration) önemli ve gerekli bir işlemdir. Bu şekilde entegrasyon problemlerini zamanında lokalize etmek mümkündür. Bu amaçla Corebanking projesi için Cruise Control kullanarak bir sürekli entegrasyon serveri oluşturdum. Bu server programcıların yaptığı her commit sonunda otomatik olarak tüm kodu Clear Case’den alarak derliyor ve mevcut testleri kosturuyor. Altta yer alan resimlerde de görüldüğü gibi bir build monitörü kullanarak, projelerin entegrasyon işlemlerinin ne durumda olduğunu takip etmemiz mümkün. Herhangi bir kırılma olması durumunda gerekli programcılar email aracılığı ile uyarılıyor. Bunun yanısıra entegrasyon monitörü herkesin gözü önünde olduğundan, entegrasyon sürecinin hangi safhada olduğunu görmek her zaman mümkün.

Diğer bir faaliyet alanım performans testleri esnasında performans ölçümünde kullanılabilecek metriklerin oluşturulması idi. Bu amaçla AspectJ (Java’da Aspect Oriented Programming yapmak için kullanılan bir framework) kullanarak perfomans aspektleri oluşturdum. Bu aspektleri kullanılan teknolojiye göre (Webservice, Rest, JDBC) metot bazında işlem tamamlama süresini ölçecek şekilde programladım. Tüm proje bu aspektler kullanılarak derlendikten sonra, kod bazında bir değişiklik yapmak zorunda kalmadan, işlem tamamlama sürelerini ölçmek mümkün oldu.

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;

@Aspect("perthis(execution(public * com.kurumsaljava.core.restapi.*Resource.*(..)))")
public class RestPerformanceMonitor extends  AbstractPerformanceMonitor
{
    @Before("execution(public * com.kurumsaljava.restapi.*Resource.*(..))")
    public void before()
    {
    	startMonitor();
    }
    
    
    @After("execution(public * com.kurumsaljava.restapi.*Resource.*(..))")
    public void after()
    {
    	stopMonitor("[performance:rest]");
    }  
}

Çevik süreçleri kullanarak iterasyon bazlı proje yönetimi yapabilmek için kullanıcı hikayelerinin (user story) oluşturulması gerekiyor. Corebanking bünyesindeki bir projenin yazılım sürecini hikaye kartları (story card) kullanarak yapılandırdık. Hikaye kartları üzerinde kullanıcı hikayeleri yer aldı. Aşağıdaki resimlerde görüldüğü gibi çalışma alanımızın bir duvarını hikaye kartlarını barındıracak biçimde şekillendirdik.

Son dört aylık çalışmamın temelini, Corebanking projesinin daha modüler ve geliştirilebilir bir alt yapıya geçirilmesi işlemi oluşturdu. Corebanking uygulamaları, oluşturduğum ve Corebanking Next Generation (CBNG) ismini verdiğim bu yeni alt yapı ile şimdi İşbankasi’nın production sistemlerinde deploy ediliyor.

Neden CBNG’ye gerek duyulduğunu sizlere kısaca aktarmak istiyorum. Başlangıçta tek bir uygulama olarak yola çıkan Corebanking projesi, zaman içinde büyüyerek, bünyesinde üç ve daha fazla uygulama barındırmaya başlamış. Prensipte birbirlerinden bağımsız olan bu projeler ne yazık ki aynı kod köklerine sahip olduklarından, birbirlerinden bağımsız olarak deploy edilmeleri mümkün olmuyordu. Yaşadığımız en büyük sorun, hazır olmayan ve test edilmemiş kodun, Corebanking bünyesindeki herhangi bir uygulamanın test ya da production sistemlerine çıkmayı istemesi durumunda, bu projeyle beraber gitmek zorunda olmasıydı, çünkü tüm Corebanking uygulamaları bir EAR dosyası olarak deploy ediliyordu. Bir başka sorun ise, proje yöneticilerinin sürekli kendi test ya da production çıkışlarını diğer projelerle koordine etmek zorunda olmaları idi. Bu şartlar altında yeni Corebanking uygulamalarının geliştirilmesi, yani binanın üzerinde yeni katlar çıkılması imkansız bir hal alıyordu.

Buradan yola çıkarak mimari ekip / teknik lider toplantılari bünyesinde Corebanking Next Generation alt yapısına geçiş fikri oluştu ve kısa bir zaman sonra bu yeni alt yapıyı oluşturmak için çalışmalara başladım.

Prensip olarak yeni alt yapının “Programming in the large” modeline göre tasarlanması gerekiyordu. Bu modele göre proje bünyesindeki birçok alt proje, ufak ekipler tarafından, birbirlerini etkilemeden, versiyonlanmış modüler ve komponentler kullanılarak geliştirilebilir hale geliyor.

Yeni alt yapı büyük bir gökdelen inşa etmek yerine, bir site oluşturarak, bu site içerisinde 2-3 katlı villalar kurulmasına izin veriyor. Her bir villayı bir proje olarak düşünürsek, ekipler birbirlerinden bağımsız olarak kendi villalarını oluşturabiliyorlar.

Kulağa hoş gelen bu model, ne yazik ki 2 senelik bir kod tabanına sahip bir projeden yola çıkıldığında uygulaması çok zor bir hal alabilir. Karşılaştığım en büyük problemlerden birisi, her proje tarafından kullanılan ortak sınıfların lokalize edilmesi ve her proje tarafından kullanılabilir bir modül haline getirilmesi oldu. Bunun yanısıra sınıflar arasında sirküler bağımlılıkların (circular dependency) olması, ortak kullanılabilir modüllerin ortaya çıkmasını zorlayan bir durumdu. Yer yer DRY (Do not repear yourself) prensibine uyulmadığı için aynı özellikleri taşıyan sınıfların birden fazla lokasyonda bulunması ve konsolide edilmesi karşılaştığım diğer bir sorundu.

İşe mevcut tüm projeleri Maven projesi olacak şekilde yeniden yapılandırarak başladım. Daha sonra Corebanking bünyesindeki en ufak çaplı projeyi seçerek, bu projeyi yeni modele uygun şekilde yeniden yapılandırdım. Bu esnada diğer projelerinde kullanabileceği ortak modüller şekillenmeye başladı. Bu şekilde adım adım ilerleyerek ilk Corebanking uygulamasını CBNG konform hale getirdim. Bu işlemin ardından projenin tüm testlerini (1000 üzerinde acceptance testleri) koşturarak, yeni yapıyı test ettik. Testler yüzde yüz çalışır hale gelinceye kadar yeni alt yapıyı rekonfigüre ettim. Bu işlemler tamamlandıktan sonra yeni alt yapıyı programcı ekibe teslim ettim. Bu şekilde yeni alt yapı sahada yayılmaya başladı. Bu noktadan itibaren iki Corebanking uygulaması, eski ve yeni dünya olarak paralel yaşamaya başladı. Tüm projeyi durdurup, 1-2 ay yeni alt yapıyı oluşturmak için ayıramayacağımız için bu şekilde bir seçim yapmak zorunda kaldık.

Kısa bir zaman sonra ilk CBNG uygulaması bir EAR dosyası olarak production sistemlerinde deploy edildi. Akabinde diğer bir Corebanking uygulamasını aynı şemayi takip ederek eski alt yapıdan yeni alt yapıya uyarladım ve sahada kullanılır hale gelmesini sağladım. Bu sürecin sonunda Corebanking tamemen transform edilmiş ve CBNG olarak hayatını sürdürmeye devam ediyor olacak. Bu gerçekleşene kadar eski ve yeni alt yapı iki değişik EAR olarak yanyana yaşamaya devam edecek.

Lokal repository olarak Nexus serverini kurdum. Bu server bünyesinde ortak kullanılan tüm modüller versiyonlanmış JAR dosyalar olarak yer aldı. Nexus ve Maven bağımlılıkların otomatik yönetimini ve kod birimlerinin ortak ve yeniden kullanımını sağlayan alt yapı komponentleri. Bu şekilde herhangi bir CBNG projesi ihtiyaç duydugu bir modülü Nexus‘dan temin edebilir. Aynı şekilde bu proje diğer projelere sunmak istediği modülleri versiyonlanmış bir Jar dosyası olarak Nexus bünyesine katabilir.

Benim için şüphesiz en heyecan verici faaliyet alanı CBNG oldu. Geliştirme plarformu olarak kullandığımız RAD 7 (Eclipse 3.2) mümkün olan tüm engelleri ortaya koyarak, yaptığım işin hergün heyecan verici kalmasını sağladı :) En büyük sorunlardan birisi RAD‘ın eski bir Eclipse versiyonu olduğu için M2Eclipse pluginini aktüel versiyonunda kullanamıyor olmamdı. Eski ve birçok bugı olan bir M2Eclipse plugin versiyonu ile çalışmanın ne kadar ve heyecan verici olabileceğini düsünebilirsiniz :) Oluşan birçok problem için birçok workaround bulmak zorunda kaldım. Bu kadar sorunla karşılaşacağımı önceden biliyor olsaydım, acaba CBNG‘yi hayata geçirmeye kalkarmıydım? Beni tanıyanlar bu sorunu cevabını biliyor :)

Corebanking Next Generation (CBNG) hakkında yazabileceğim sayfalar dolusu anılarım var. Lakin banka bünyesinde olup bitenleri çok detaylı bir şekilde anlatmak doğru olmaz. Danışman ya da banka çalısanı olarak dikkat etmemiz gereken en önemli konulardan birisi, gizlilik prensibine uymaktır.

Corebanking projesi bünyesinde birçok yetenekli programcıyla çalışma fırsatı buldum. Bilgi alışverişine açık bir ortamda çalışmak gerçekten çok zevk vericiydi. Bu programcı arkadaşlara bu vesile ile buradan kucak dolusu selam ve sevgilerimi gönderiyorum.

EOF ( End of Fun)

Özcan Acar



Proje Günlüğü kategorisinden son yazılar

Share Button
0.00 avg. rating (0% score) - 0 votes

8 Comments

  • acar

    03 Ocak 2000

    Mehrhaba,

    Corbaning uygulamasi POJO bazl bir yapiya sahip. Bu sebepten dolayi böyle bir uygulamayi, TDD kullanarak, uygulama sunucusu disinda gelistirmek mümkün.

  • Aykut Taşdelen

    09 Ocak 2000

    Elinize sağlık üstat, Türkiye’de takip ve takdir ettiğim az sayıdaki meslektaşlarımdan birisiniz.
    Başarılı çalışmalar dilerim

  • Şaban Ulutaş

    17 Nisan 2011

    Özcan hocam neredesiniz diye merak ediyordum.
    dönüşünüzü bu güzel deneyim aktarımı ile yaptınız ;)
    teşekkürler.

  • Alihan

    17 Nisan 2011

    Kurumsal rezil projeler yav iyi sabretmissiniz.

  • acar

    17 Nisan 2011

    Hocam hep buradaydim ;-)
    Selamlar

  • acar

    17 Nisan 2011

    :)

  • erhan elgün

    27 Haziran 2011

    Özcan Bey selamlar,

    Kurumda uygulama sunucusu olarak Ibm Websphere kullanılıyor ve biz geliştiriciler de yazılım geliştirme işlemi için Ibm RSA 7.5 kullanıyoruz. Aslında Rsa in normal Eclipse den hiçbir farkı yok hatta versiyon olarak daha eski bir eclipse versiyonunu kullanmışlar ve . Fakat Rsa kurulurken test uygulama sunucusu olarak websphere 6.1(embeded) ile beraber kuruluyor. Hem kurulum aşamasında hem de uygulama geliştirme aşamasında çok sıkıntılı bir ürün olduğunu kanaatindeyim. Yukarıdaki yazınızda “Lokal yazılım geliştirme işlemi için Websphere uygulama sunucusunun devre dışı bırakılması ve uygulama sunucusu kullanmak zorunda kalmadan test güdümlü yazılım yapılabilmesi” ifadesini okuyunca bunu nasıl yaptığınızı merak ettim.
    Bu konuda bilgi verirmisiniz.

  • acar

    15 Ekim 2011

    Tesekkür ederim hocam, sagolun.
    Iyi calismalar

Bir Cevap Yazın