Kurumsal Uygulama Nedir?
Kurumlar, soyutlandığında iş süreçleri üzerine
kuruludur. Küçük patron şirketlerinden uluslararası
holdinglere kadar her kurum iş akışları, iş mantığı,
girdileri ve çıktıları ile süreçlerden oluşur. Bu
geniş yelpazenin iki ucu arasındaki tek fark
süreçlerin tanımlı olmasıdır.
Her koşulda, kurum süreçlerini otomatikleştirmek ve
karar almaya destek verecek sistemleri geliştirmek
zor bir tasarım problemidir. Süreçlerin tanımlı
olması, problemin zor olmasını engellemez; ve
kurumsal uygulamalar geliştirmekten bahsediyorsak,
genelde her problem zordur.
Kurumsal uygulamalar, iş süreçlerinin otomasyonunu
gerçekleştirmek için geliştirilen ve genelde büyük
miktarda ve karmaşık ilişkileri olan verinin
görüntülenmesini, işlenmesini ve saklanmasını
sağlayan yazılım uygulamalarıdır [1,Fowler]. Bu
sistemlerin diğer bir adı da Bilgi Sistemleri’dir.
Yazılım geliştirme süreçleri doğal olarak bu tür
uygulamaları geliştirmeyi de sağlamaktadır. Ancak,
kurumsal uygulama geliştirmek ile televizyon
içindeki donanımı kontrol edecek gömülü yazılımı
geliştirmek arasında çok büyük farklar vardır. Her
iki durumda aynı yazılım geliştirme yaklaşımını
kullanmak, bu nedenle, çok büyük problemler
yaratabilir.
Literatürde, Kurumsal Uygulama’nın ne olduğu net
olarak tanımlı değildir. Ancak, genel olarak bir
kurumsal uygulama şu özellikleri içerir:
·
Çok miktarda veri
·
Karmaşık veri ilişkileri
·
Eş-zamanlı erişim
·
Çok kullanıcılı arayüzler
·
Dağıtık altyapı
·
Farklı sistemlerle entegrasyon
·
Belirli bir iş alanı (Business Domain) bilgisi
B2C siteler, Rezervasyon sistemleri, Müşteri
İlişkileri Yönetimi (CRM) sistemleri, Kurumsal
Kaynak Planlama (ERP) sistemleri, Hastane Yönetim
Bilgi Sistemleri (HYBS) , Üniversite Öğrenci İşleri
Bilgi Sistemleri (ÖİBS), kurumsal uygulamalardan
birkaçıdır.
Kurumsal Uygulama Geliştirme
Yazılım geliştirme, ve özellikle
kurumsal uygulama geliştirme, pek çok açıdan inşaat
yapmak ile aynıdır. Ancak, bir yazılım mühendisi
kadar sofistike eğitime sahip olmayan inşaat
işçileri, kalfalar, ustalar tarafından yapılan (ve
elbette, mimar ve inşaat mühendisi tarafından
tasarlanmış) yapı projelerinin gerçeklenmesinde pek
problem yaşanmazken (Biten İnşaat / Tüm İnşaatlar
oranı çok yüksektir), yazılım mühendisleri ve
programcılar tarafından yürütülen projelerin
başarısızlık oranı çok yüksektir. Kurumsal Uygulama
Geliştirme problemi için öncelikle buradaki
çelişkiyi anlamamız gerekmektedir.
Yapılar inşaa etmek insanoğlunun
binlerce yıldır tekrarladığı bir iştir. İnsan,
yerleşik düzenin temelini oluşturan barınak
yapımından günümüzün gökdelenlerine kadar herşeyi
inşaa etmiş ve bunun tecrübesini nesilden nesile
aktarmıştır. Neticede, günümüzde insanoğlu binlerce
yıllık bir tecrübeyi kullanarak daha büyük ve daha
gelişmiş yapılar inşaa etmektedir. Burada sizlerin
de farkedeceği anahtar kavramlar tecrübe aktarımı ve
bunun çalışma-zamanındaki karşılığı tekrarlamadır.
Kısa bir not olarak, hepimizin bildiği ve kullandığı
Design Patterns (Tasarım Desenleri) kavramının
mimari bir kavram olduğunu belirtmekte fayda var [2,Alexander].
Buradan hareketle günümüzün yazılım
geliştirme kavramına bakacak olursak ilk başta
binlerce yıllık bir bilgi birikiminin olmaması
nedeniyle sıkıntıların yaşandığı sonucu
düşünülebilir. Ancak, bu asıl problemin
yanılsamasıdır. Yazılım Geliştirme her iterasyonda
(her projede) sıfırdan başlandığı için problemler
yaşamaktadır. Tekrarlama ve tecrübe aktarma
kavramlarını içermeyen bir yazılım geliştirme
sürecinin başarısız olması ihtimali yüksektir.
Pragmatik olarak tecrübe aktarma ve
tekrarlama kavramlarını tasarım desenleri (design
patterns) ve bunun çalışma-zamanı karşılığı tekrar
kullanılabilirlik (re-usability) ve ile
gösterebiliriz. Tasarım probleminin çözümüne yönelik
tasarım desenlerini kullanmak ve bu tasarımları
içeren kod bileşenlerini tekrar kullanmak kurumsal
uygulama geliştirme projesinin başarıya ulaşması
için gerekli pratiklerdir.
Kurumsal Mimari Desenler
Tasarım Desenleri (Design Patterns),
Gang of Four (GoF) olarak bilinen, Eric Gamma,
Richard Helm, Ralph Johnson ve John Vlissides
tarafından yazılan “Design Patterns: Elements of
Reusable Object-Oriented Software” kitabıyla Yazılım
Mühendisliği literatüründe yerini aldı. Elbette,
Gamma’nın ve diğer bazı yazılım mühendislerinin konu
üzerinde 80’li yılların sonundan beri çalıştığını
biliyoruz ancak GoF Design Patterns kitabı
yayınlandığında tüm yazılım geliştiricilerin
dikkatini bu konuya ve kavrama çekti. Bugün tasarım
desenleri çok yaygın olarak tanımlanmakta ve
kullanılmaktadır. Farklı problem türleri için
zamanla tekrar eden çözümlerin “keşfedilmesi”yle
çeşitli desenler ortaya çıkmıştır. Kısacası,
desenler aslında yıllardır kullanılan çözümlerdir ve
birisinin fikri yada tasarımı değildir.
Desenlerin keşfedildiği bilgisini
aklımızın bir kenarında tutarak Kurumsal Mimari
Desenler’in ne olduğunu inceleyelim. Kurumsal Mimari
Desenler, kurumsal uygulama geliştirirken
karşılaşılan özel tasarım problemlerini çözmekte
kullanılan çözümlerdir. Farklı kurumsal uygulama
platformlarında kullanılan özel çözümler de
mevcuttur (ör. Sadece J2EE tasarım desenleri).
Bir desen, belirli bir tip problemi
çözmekte kullanılır. Bu nedenle, desenin hangi
durumlarda kullanılacağını bilmek ve özel olarak
karşılaşılan problemde nasıl kullanılacağını bulmak
önemlidir. Ancak desenler, problemi çözmek için
olduğu gibi yutulan sihirli haplar değildir. Her
desenin ilgili problem için özelleştirilmesi her
zaman olmasa da çoğu zaman gereklidir.
Kurumsal Uygulama Geliştirme Problemleri
Desenleri incelemeye başlamadan önce
kurumsal uygulama geliştirme problemlerinden
bahsetmek istiyorum. Tabi “problem” kelimesinin
sıkıntı veren durum anlamında değil, ilgili durumu
oluşturan bileşen olarak kullandığımı da
belirtmeliyim. Kurumsal uygulama geliştirme
problemlerini aşağıdaki şekilde sıralayabiliriz:
-
İş Alanı Modelleme
-
Veri/İş Modeli Uyumu
-
Web sunumu
-
Çok-katmanlı yapı
-
Çok-kullanıcı için multi-threading
-
Transaction problemleri
Kurumsal uygulamaların iş süreçleriyle
doğrudan ilintili olduğunu belirtmiştim. Bu nedenle,
iş mantığının (yada daha doğru olacak şekilde,
ilgili iş alanının) belirlenmesi çözülmesi gereken
bir problemdir. İş alanı bilgisi veya iş mantığının
bileşenlerinin belirlenmesi, bunların yapısal ve
davranışsal ilişkilerinin çözümlenmesi, ilgili iş
modelinin oluşturulması ve temel mimari yapının bu
model üzerinde belirlenmesi bu problemin çözüm
adımlarıdır. Günümüzde iş-alanı (domain)
modellenmesinde Model-güdümlü Mimari (Model-driven
Architecture, MDA) ve Alan-güdümlü Analiz (Domain-driven
Analysis, DDA) kullanılmaktadır.
Kurumsal uygulamalar ile ilgili diğer bir problem,
veri modeli ile iş mantığının eşleştirilmesidir.
Günümüzdeki persistance mekanizmaları (Hibernate,
TopLink vb. ) bu probleme doğrusal bir şekilde çözse
de, bu problemin farklı durumlarda tercih
edilebilecek birden fazla çözümü bulunmaktadır.
Ayrıca dağıtık ve heterojen veri kaynaklarının
erişimi ve model eşleştirilmesi de yine ele alınması
gereken problemlerdendir.
Internet’in yaygınlaşmasıyla günümüzün
kurumsal uygulamalarının büyük bir çoğunluğu Web
sunumuna sahiptir. Ancak Web’in HTTP ve HTML tabanlı
olması (Mobil uygulamalardaki durum da hemen
aynıdır) dinamik web uygulamalarına özgü problemleri
de ilgi alanımıza sokmuştur. Bütün dinamik Web
platformları aynı yaklaşımla çalışır.
Model-View-Controller (MVC) olarak adlandırılmış bu
yaklaşım (aynı isimli desen de mevcuttur) ASP, PHP,
JSP veya daha farklı bir dinamik Web platformunun,
dinamik olarak üretilen verinin (Model) durağan HTML
gösterimine (View) çevrilmesini (Controller
tarafından) sağlar. Burada Model’in iş mantığı ile
etkileşimi, Model bilgisinin Controller tarafından
View’e çevrimi ve View’in Model’deki bileşenleri
temsil etme biçimi bir çözülmesi gereken bir çok
problemi içerir.
Kurumsal uygulamaların yapısal
tasarımında çok katmanlı yapı kullanılmaktadır. Çok
katmanlı yapıya duyulan gereksinim bu makalenin
kapsamı dışındadır. Ancak, mimari olarak
katmanların belirlenmesi yine çözülmesi gereken bir
problemdir. Sunum katmanının kapsamı, İş mantığının
katmanlar arasındaki etkileşimi ve veri katmanına
erişim bu aşamadaki problemlerimizdir. Kimi
uygulamalarda sunum katmanı sadece verinin
gösterimini içermekte, kimi uygulamalarda da iş
mantığının belirli kısımlarını içermektedir. Benzer
şekilde bazı uygulamalar sunum katmanının veri
katmanına doğrudan erişimini içerirken (genelde bu
çok sık görülür) bazı uygulamalar veri katmanını iş
mantığı içerisinde gizlemektedir. Burada
hatırlanması gereken temel prensip uzamsal olarak
bağımlılıkların yukarıdan aşağıya doğru olmasını
sağlamaktır.
Kurumsal uygulamaların genelde (doğrusu
hemen her zaman) çok kullanıcılı sistemler olduğunu
düşünecek olursak, çok kullanıcının aynı kaynak(lar)
üzerinde yaptıkları işlemlerin sistemin kararlılık
sınırları içerisinde kalmasını ama aynı anda birden
fazla kullanıcıya hizmet edebilmesini sağlamak çok
zor bir problemdir. Problemin en zor yanı çok
kullanıcıya hizmet vermek için multi-thread uygulama
geliştirmekte yatar. Bu tür uygulamaların çalışma
zamanı davranışlarını test etmek çok zordur. Ayrıca,
çalışma zamanındaki performansları çok hassastır;
tasarımındaki ufak değişiklikler performanslarını
çok fazla etkiler. Bu nedenle, multi-thread
uygulamaları tasarlarken kullanılacak kaynaklar,
işlem zamanları, iyi/kötü senaryolar, stress
testleri dikkatlice planlanmalı ve dikkatlice
uygulanmalıdır.
Multi-threading ile birlikte transaction
kullanımı da kurumsal uygulama tasarımındaki
problemlerdendir. Transaction denince ACID tabirini
de hemen hatırlarız. İşte kurumsal uygulama
geliştirirken sıkça kullanacağımız tranasction’lar
için ACID özelliklerini sağlayacak çözümler
geliştirmek gereklidir. ACID özelliklerine kısaca
değinecek olursak:
-
Atomicity: Transaction içindeki her bir eylemin
başarıyla tamamlanması gereklidir. Herhangi bir
adımda yaşanacak hata bütün transaction’ın
başarısız olmasına ve tüm işlemlerin geri
alınmasına (roll-back) neden olur.
-
Consistency: Sistemin transaction süresince
tutarlı durumda bulunması gereklidir.
-
Isolation: Her bir transaction işleminin sonucu,
başarıyla tamamlanana kadar diğer
transaction’ları etkilememeli ve onlar
tarafından görülmemelidir.
-
Durability: Transaction işleminin sonucu kalıcı
olmalıdır.
Kurumsal Mimari Desenler, işte bu
sıraladığım problemler için uygulanan çözümlerdir.
Yukarıda sıralanan problemlerin herbiri için tek tek
veya belirli kombinasyonları için uygulanacak
çözümler mevcuttur. Ancak daha önce de belirtmiş
olduğum gibi, bu çözümleri olduğu gibi uygulamaya
çalışmak problemi çözmek yerine yeni “sıkıntı”lar da
yaratabilir. Bu nedenle iyi bir tasarım için, ilgili
durumu iyi anlamak ve desenlerin nasıl
kullanılacağını belirlemek önemlidir.
Sonuç
Bu makale, Kurumsal Mimari Desenler
konulu serinin ilk adımıdır. Kurumsal mimari
desenleri anlamak için öncelikle kurumsal uygulama
kavramını ve çözümü gerektiren problemlerin yapısını
anlamak gerekmektedir. Serinin bir sonraki
makalesinde Dependency Injection desenini
işleyeceğiz. Tekrar görüşmek üzere.
