Nedir Bu COM Geçtiğimiz uzun yıllar boyunca programcılık tek parça uygulama geliştirmekten ibaretti. Monolithic (tek parça) uygulamalarda bir veya birden fazla fonksiyonalite bir arada bulunuyordu. Böyle bir ortamda ise uygulamaların çalışabilmesi için IBM tarafından geliştirilmiş server teknolojisi olan mainframe sunucular kullanılmaktaydı. Ancak geniş monolithic uygulamalarda tek sorun sunuculara yapılan yatırımlar değildi. Yazılım geliştirici tarafındada bir çok problemle karşılaşılıyordu. Bu problemlerin belli başlılarını arasında monolithic uygulamaların geliştirilmesinin uzun bir süre alması, bakım ve uygulamada yapılacak düzeltme, yeni özellik ekleme gibi işlemlerinin zor olması ve çok efor gerektirmesi ve günümüzde hakim olan yazılım geliştirme mimarisi ve mantığına aykırı olarak monolithic uygulamalarda yazılmış olan bir işlevsellik veya bir özellik taşıyan bileşen aynı programlama dilinde yazılmış olsa bile başka bir uygulamada kullanılamaması ve yazılım geliştiricilerin yeni uygulama için aynı kodu tekrar yazmak zorunda kalması veya uygulamanın bir kısmını değiştirilmesinin,kaldırılmasının istenmesi durumunda bile tüm uygulamanın kodu üzerinde değişiklik yapılması gerekmesi bulunmaktadır. Zamanla yazılım dünyasındaki bu probleme karşı çözümler geliştirilmiştir. Bu çözümlerden ilki uygulamaları server (sunucu) ve client (istemci) tarafına bölmektir. Client/Server Model adı verilen bu çözümde arayüzün ve bazı işlemlerin clientta, data erişimi ve diğer işlemlerin serverda bulunacak şekilde paylaştırılması sonucu monolithic uygulamaların kompleksliğine kısmen çözüm bulunabilmesine karşın bileşenlerin tekrar kullanılamaması sorununa çözüm geliştirememiştir. Yani Visual Basic te yazılmış bir bileşeni C temelli diller desteklemiyor, kullanamıyordu yada C temelli bir dille yazılmış bir bileşen Visual Basic de kullanılamıyordu. Diğer bir çözüm yöntemi olarak geliştirilen Component Model (Bileşen Modeli) hem monolithic hemde Client/Server uygulamaların problemlerine çözüm bulmuştur. Artık yazılım geliştiriciler geliştirdikleri uygulamaları bileşenler ile yazarak bu bileşenleri ileride başka projelerde tekrar kullanabiliyorlardı. COM (Component Object Model) uzun zamandır yazılım dünyasının karşılaştığı birçok probleme çözüm olan ve sürekli yenilenerek zamana ayak uyduran bir teknolojidir. Bu teknolojinin yaratılmasının arkasında bulunan temel düşünce yazılım bileşenlerinin en az işgücü ile en verimli biçimde yeniden kullanılabilmesidir. Bu tanım bir yazılım geliştirici için daha önceden yazılmış olan bir kodun tekrar yazılmaması, bir IT yöneticisi için ise bu kodun tekrar yazılmasından kaynaklanan maliyet ve zamandan tasarruf demektir. Nesne tabanlı bir programlama modeli olan COM uygulamaların birlikte kullanılabilirliğini sağlamıştır. Yani iki veya daha fazla uygulama veya bu uygulamalara ait bileşenler birbirleriyle iletişim sağlayabilmektedirler. Burada esas can alıcı nokta bu uygulamaların farklı dillerde yazılmış olduklarında ve hatta farklı bilgisayarlar üzerinde bulunan farklı işletim sistemleri üzerinde çalışıyor olmaları durumunda bile bu iletişimin başarıyla sağlanmasıdır. COM ve.net COM ile server tabanlı uygulama geliştirmenin faydaları arasında yazılım geliştiricilerin COM uygulamalarını farklı diller ile farklı platformlar (Unix vs.) için geliştirilmiş olsalar bile uygulamaların birbirleri ile çalışabilir bir yapıda olmaları, COM nesneleri başka makinelerde olsalar bile client programın bir parçasıymış gibi çalışabilmeleri,com bileşeni geliştirmek
için gerekli olan standartlar Interface ler ile sağlandı, böylece bir programın COM nesnesini kullanırken Interface leri kullanarak COM nesnesine erişebilmesi, Versiyon özelliği yani her bir class a yeni interfaceler ekleyerek ek işlevselliklerin katılması ve bu işlevsellik katılırken uygulamayı halihazırda kullanan kullanıcıların herhangi bir kesinti yaşamaması,bir COM nesnesinin, COM arayüzlerini oluşturmayı destekleyen bir programlama dili ile çok hızlı bir şekilde gerliştirilebilmesi, örneğin VB 6.0, C++ gibi diller varsayılan olarak COM standartlarına uyum sağlaması bulunur. COM Server tabanlı program geliştirmede birçok soruna çözüm olmasına rağmen zamanla ortaya bazı diğer sorunlar çıkmıştır. Ortaya çıkan bu sorunlara COM un çözüm sağlayamamasına karşın.net Framework bu sorunla çözüm olmuştur..net Framework un çözüm getirdiği konular;bir COM uygulamasının belirli bir platform için geliştirilmesi sonucu sadece o platformda çalışabilir olmasıdır. Ancak.NET teknolojisinde geliştirilen çözüm.net dillerinden herhangi biri kullanılarak yazılmış bileşenlerin MSIL (Microsot Intermediate Language) e derlenmesi ve kullanılacak platformda CLR(Common Language Runtime) yüklü olması sonucu her platformda çalışabilir olmasısır. Bunun yanı sıra COM un cevap veremediği diğer bir sorun ise.net te geliştirilmiş uygulamaların sadece kendi yetkileri olan memory alanlarına erişebilmesidir. Yani çalışan bir uygulama diğer bir uygulamaya özel değişkenlere erişemez ve diğer uygulamanın kilitlenmesine sebep olamaz..net i ön plana çıkaran bir diğer özellik ise daha gelişmiş bir versiyon kontrol mekanizmasını barındırmasıdır. COM da bulunan ve biraz önce incelediğimiz versiyonlama özelliğine ek olarak.net te uygulamanın eski sürümünün eski istemcilere hizmet vermeye devam etmesinin garanti altına alınması vede yeni halinin ise yeni istemcilerde kullanılabiliyor olması sağlanmıştır. Birçok kişi tarafından COM+ programcılığının eskidiği düşünülse bile COM+ sundugu enterprise-level (genis çaplı) uygulamalar halen gelistiriciler tarafından.net e uygulanmaktadır ve.net su an COM+ servislerine tam erişim hakkı vermektedir. Bunun yanı sıra bunu bildiğiniz veya sevdiğiniz programlama dilini kullanarak geliştirme şansı sunmaktadır. Eğer enterprise-level uygulamalar yazacaksanız COM+ servislerinin avantajlarından yararlanmak bazı noktalarda kaçınılmaz olacaktır. COM+ Servisleri Geliştirilmiş başarılı bir uygulamanın altyapısının aynı anda birden çok kullanıcı tarafından kullanılabileceğinin düşünülmesi, bu kullanıcıların herbirinin aynı yetkilere sahip olmayacağından dolayı yetkilendirme ve güvenlik, aynı anda bazı datalarda işlem yapılmasından dolayı kaynaklanacak problemler, veri tutarlılığı problemlerine ait çözüm geliştirilmesi çok uzun zamanlar alabilecek bir geliştirme süreci içermektedir. Ancak COM+ da bu problemlere ait çözümler geliştirilmiş olarak hazırda bulunmaktadır. COM+ servislerinin bu avantajı sayesinde uygulama geliştirme süreleri kısalmakta ve yazılım geliştiriciler daha verimli çalışabilmektedir. Bu servisler transaction, kaynak yönetimi, senkronizasyon ve güvenlik gereksinimlerini karşılayabilmektedir. Şimdi bu temel servislerin neler olduğunu basitçe inceleyelim. Transactionlar Transactionların veri tutarlılığı ve uygulama stabilitesi bakımından kullanılması kaçınılmazdır. Çok kullanıcılı bir Distributed Application (Dağıtık Uygulama) da
değişikliklerin veritabanında bulunan tablolara ve hatta bazen diğer nesnelere(örn message queue) yansıması gerekebilir. Böyle bir durumda uygulamada birbirine bağlı birden fazla iş yapılmaktadır ve bu işlerden sadece birinin bile başarısız olma durumunda uygulamanın bunu yakalayıp aksiyonda bulunması gerekmektedir. Yapılan iş tutarsız(kararsız) bir şekilde yani bir kısmı yapılmış bir kısmı yapılmamış bir şekilde bırakılamaz. Burada transaction devreye girer. Transaction yapılan işlerin toplu olarak başka bir iş gurubunda bulunması gibi düşünülürse alt iş guruplarından herhangi birinde bir hata oluştuğunda kapsayan gurubun işleminin yapılamayacağı anlamına gelir. Transactionlar ya hep ya hiç prensibine göre çalışır. İşlemlerin ya tamamı gerçekleştirileceğinden yada hiçbiri gerçekleştirilmeyeceğinden veri tutarsız bir şekilde kalmayacaktır. Database işlemlerinde ve diğer işlemlerde transactionların birlikte kullanılmasının bir uygulamaya adapte edilmesi çok zordur. Ancak COM+ bu transaction yönetim sistemini altyapısının bir parçası olarak sunar. COM+ bileşenler aktive olduğu anda otomatik olarak transactionlarınıda yaratır. Bu sayede bileşenlere transactional herhangi bir kod yazmak zorunda kalmayız. Compensating Resource Managers(Telafi Edici Kaynak Yöneticileri) COM+ transaction yapısı içermeyen bileşenlerin transaction içinde yeralabilmeleri için Compensating Resource Managers (CRM) denilen bir yapı sunar. Bu yapı sayesinde bu bileşenleri bir transaction içinde kullanarak gerekli durumlarda yapılmış değişiklikleri geri alabiliriz. Resource Management (Kaynak Yönetimi) Bir uygulama çok client tarafından kullaılıyorsa uygulamadaki nesneler kaynak paylaşımında bulunmalıdır. Bu paylaşım çoğu zaman veri tabanı, diski hafıza, bant genişliği şeklinde olabilir. Bu kaynaklar sadece gerektiği zamanlarda ve en verimli şekilde kullanmalıdır. COM+ faydası tartışılmayan bu hizmetleri Just In Time (JIT) Activation ve Object Pooling adı verilen iki servis ile sunmaktadır. Just In Time (JIT) Activation (Tam Zamanında Aktivasyon) COM+ de yer alan kaynak yönetimi ile ilgili bu servis bir nesnenin sadece çağrıldığı zaman aktive olması ve işi bittiği zaman hafızadan silinmesi temeline dayalıdır. Bu şekilde hafızadan kazanç sağlanmış olur. Server bu sayede daha fazla client yükünü kaldırabilecekdir. Bu servisin adı yaptığı işle benzer olarak tam zamanında aktivasyon olarak belirlenmiştir. Bir nesnenin bir metoduna client tarafından istekte bulunulduğunda COM+ nesneyi yaratır ve aktive eder. Nesneye yapılan istek bittiğinde yani metod cevabı döndürdüğünde COM+ nesneyi hafızadan kaldırmak suretiyle deaktive eder. Daha sonraki işlemlerde bu nesne her çağrıldığında aktive edilip tekrar deaktive edilecektir. Object Pooling (Nesne Havuzları) COM+ tarafından sağlanan bu otomatik servis sayesinde uygulamada bulunan bileşenlerin belirtilen sayıda birer instanceleri (örnek) hafızada bulunan havuzda kullanıma hazır olarak saklanır. Bu sayede Object Creation Time dan (Nesne Yaratım Zamanı)kazanç elde edilmiş olur. Pool Size (hafızada hazır bulunacak nesne sayısı) ve time out (zaman aşımı) süresi
bileşen özelliklerinden ayarlanabilir. Örneğin bir bileşen hafızada 10 örnek yaratılmışsa yani pool size ı 10 olarak belirlenmişse 11. istek geldiği zaman timeout süresi kadar hafızadaki bir nesnenin işinin bitmesi beklenir, biterse o nesnenin yerini 11. istek alır bitmezse geriye hata döner. Bir uygulama tarafından çok sık kullanılan bileşenlerde yaratma zamanının sebep olduğu gecikmeler ve yavaşlamaların önüne geçilebilmesi için gerekli ve çok kullanılan bir servistir. Synchronization (Senkronizasyon) Distributed Applicationlar (dağıtık uygulamalar) aynı anda birden fazla client tarafından kullanılabilmeli ve client lardan gelen bu istekleri eşzamanlı olarak karşılayabilmektedirler. Aynı zamanda bu uygulamalardaki iş kuralları birçok farklı bilgisayarda aynı anda thread ler kullanarak işlem yapabilmelidir. Çoklu bilgisayarlarda çoklu thread yönetimi yazılım geliştirici bakımından geliştirilmesi oldukça zordur. COM+ basit bir eş zamanlı çalışma modeli sunarak bu ağır kodlama gerektiren senkronizasyon işlemi ile vakit kaybedilmemesi için büyük bir avantaj sunmaktadır. COM+ ın sunduğu bu servis aktiviteler sayesinde sağlanır. Aktivite bir nesnenin client tarafından istenip yaratılmasından sonra çalışma süreci boyunca ilerleyip serbest bırakılması sürecine kadar geçen ve client ın nesneye eriştiği zaman aralığını kapsar. Nesnein bu isteklere cevap verebilmesi için aynı aktiviteye ait ek COM+ nesneleri yaratması gerekmektedir. Aktivite sayesinde yazılım geliştiriciler tek kullanıcı gibi düşünerek çoklu kullanıcıya hizmet edebilen programları gayet kolaylıkla yazabilmektedir. Security (Güvenlik) Uygulamanın birden fazla client tarafından kullanılabilirliğinden dolayı kuşkusuz olarak authentication (doğrulama) ve authorization (izin verme) mekanizmalarının COM+ tarafından içerilmesi kaçılnılmazdır. Bu sayede sadece uygulamada işlem yapabilecek kullanıcıların uygulamaya erişebilmesi dolayısıyla uygulamanın güvenliği sağlanmış olmaktadır. COM+ ın güvenlik mekanizmasının temelinde roller tanımlanması ve bu rollerin yetkilendirilmesi yatmaktadır. Roller Windows NT tabanlı kullanıcılar ve guruplardan yaratılır ve rollere belirli classlardaki (sınıf) belirli interfaceler atanır. Daha sonra bu rollere Sistemde bulunan (Windows NT tabanlı kullanıcılar ve guruplar) kullanıcılar atanarak sadece izin verilen nesnelere erişmeleri COM+ tarafından yazılım geliştircinin ekstra hiçbir kod yazmasına gerek duyulmaksızın denetlenir. Loosely Coupled Events (İnce Bağlı Olaylar) Birçok event handling (olay tutucu) sistemde olay kaynağı ve olay yatırıcısı çalışma zamanında birbirilerini refere etmelidir. Bu tür bir ilişki sıkı bir çift oluşturmaktadır. Birçok senaryoda sıkı ilişkili olay çiftlerini yönetmek kolay olmayacaktır. COM+ bu sorunların aşılması için ince bağlı olaylar adı verilen bir servis sunmaktadır. Queued Components (Sıralanmış Bileşenler) Dağıtık uygulamalar her zaman senkron çalışma prensibine dayalı olarak çalışmamakta bazen asenkron çalışmaları gerekmektedir. Windows XP bize Message Queuing adı verilen bir
asenkron servis sunmaktadır. Bu servis sayesinde kaynak makina işlemleri mesajlar olarak sıralı durabilecekleri bir şekilde oluşturur ve istemciler bu mesajları sıra ile alarak işlerler. Bu servisin asenkron çalışması sayesinde veri iletişiminin kolaylıkla sağlanabilmesine karşın uygulamaların bir bileşen üzerindeki metoda asenkron isteklerde bulunmasını desteklememektedir. COM+ servislerinden Queued Components Message Queuing i kullanarak bu desteği sunmaktadır. COM+ Runtime Architecture (COM+ Çalışma Zamanı Mimarisi) COM+ çalışma zamanı servisleri uygulamanın kodunu surrogate (Com objeler için çalışan host process) ortamda barındırır. COM+ çalışma zamanı kodun doğru servisleri kullandığını içinde bileşen genel durumu ve durdurucu metodların çağrılmasını sağlan bir metodun dahil olduğu birçok mekanizma kullanarak garanti altına alır. Bu mekanizmaların nasıl çalıştığının iyi anlanması daha verimli COM+ uygulamaları yazabilmek anlamına gelmektedir. COM+ ve.net Terminolojisi COM+ uygulamalarında iki çeşit bileşen vardır. Bunlat configured componenet ve serviced component dır. Configured component aslında COM+ ortamında çalışan, uygulamasına dahil olan COM uygulamalarıdır. Bu uygulamayı yükledikten sonra COM+ servislerini kullanabilmesi için COM+ kataloğunda bazı ayarlar yapmak gerekmektedir. Bir COM bileşeni DLL(Dynamic Link Library) veya EXE dosyası olabilirken COM+ bileşenleri sadece DLL dosyalardan oluşmaktadır. COM bileşenleri oluşturmak için Microsoft Visual Basic 6.0 veya Microsoft Visual C++ 6.0 kullanılabileceği gibi diğer araçlardanda faydalanılabilir. Yaratılan bu bileşenler.net Framework tarafından unmanaged code olarak algılanacaklardır. Serviced Component ise.net Framework mantığına göre Common Language Specification (CLS) e uygun bir biçimde yazılmış ve System.EnterpriseServices.ServicedComponent Classından türemiş bir classtan başka bir şey değildir. Bu şekilde oluşturulmuş class lar COM+ uygulaması içinde yer alabilirler ve tüm servisleri kullanabilirler. Aynı zamanda serviced componenet bir configured component tır. Tüm.NET Framwork classları COM ile iletşim sağlayabilecek şekilde olduğundan Serviced components ile unamanged components arasındaki iletişimde aynı mantıkta olacaktır. Bileşen Configured Component Managed/Unmanaged Visual C++ 6.0 Bileşenleri Evet Unamanged Visual Basic 6.0 Bileşenleri Evet Unamanged Diğer COM Bileşenleri Evet Unmanaged Serviced Components Evet Managed COM+ Uygulamaları COM+ uygulamaları configured bileşenlerin bir araya gelmesinden oluşmaktadır. COM+ uygulamaları aynı zamanda bir güvenlik sınırını yapısı olarak koyar. COM+ uygulamaları Server Uygulaması ve Library uygulaması olmak üzere iki çeşitte olabilir.
Surrogate çalıştırılabilir bir görevdir ve DLL olarak oluşturulmuş bir COM bileşenini barındırabilir. Surrogate Exe uygulamasını çalıştırmak suretiyle uzaktaki bir bilgisayardaki DLL sunucusunu çalıştırılabilir. Bir server uygulaması kendisine özel tahsis edilmiş işlemde çalışır. COM+ server uygulamalarını barındırmak için Dllhost.exe yi kullanır. Her bir server uygulaması kendi Dllhost.exe örneğinde çalışmaktadır. Dllhost.exe surrogate i COM+ çalışma zamanının çekirdeğini oluşturur. Bileşenlere servisleri kullanabilmek için gerekli olan thread yönetimi, eş zamanlı bağlantı yönetimi gibi hizmetlerin altyapısını sunar. Server uygulaması COM+ servislerinin tamamını desteklemektedir. Library uygulamaları client in işleminde aktive olurlar.client işlemi unmanaged bir işlem olabilir. Örneğin IIS üzerinde çalışan bir asp uygulamasının configured bileşeni çağırabilir. Çoğu durumda bu işlem DllHost.exe nin bir örneği olmasına karşın üzerlerindeki sınırlamalardan dolayı COM+ ın bazı özelliklerini kullanamazlar. Kitaplık uygulamalarının sunucu uygulamalarına göre daha iyi performans sağlamalarının sebebi kitaplık uygulamasında bulunan bir nesneye erişim süresinin işlemler ve bilgisayarlar arasında dolaşarak erişebilecek bir nesneye erişme süresinden çok daha kısa olmasıdır. Ancak kitaplık uygulamalarındada connection pooling, queued bileşen yüklenememe, bazı güvenlik ayarlarının çağırıcıdan yani classımızdan türetilmesinden dolayı bir kısım güvenlik ayarlarını kullanamama gibi bazı sınırlandırmaları vardır.ayrıca bir işlemde hata oluşması durumunda sunucu uygulama sadece dllhost.exe yi sonlandıracak ve diğer çalışmakta olan işlemlere bir zarar gelmeyecektir. Ancak kitaplık uygulamasındaki hata istemci tarafındaki işlemlerin tamamen durmasına sebep olacaktır. Bu sebepten dolayı server uygualamaları çoğunlukla tercih edilmektedir. Her iki tip uygualamanında birbirine üstünlüklerini inceleyecek olursak Sunucu uygulamalar, hata oluşturabilecek bir koda karşı izolasyon geliştirilmiştir, queued bileşenleri ve object poolingi destekler ancak işlemler arası metod çağırmalar çok maliyetlidir. Kitaplık uygulamalarında ise metod çağırımları daha hızlı olmasına ve istemciye özel bazı kaynaklara erişilebilmesine rağmen, sunucu uygulamalarındaki avantajları sağlamamaktadır. COM+ ın yeni versiyonu olan 1.5 numaralı versiyonu geliştirilmiş bir sunucu uygulamayı windows servis olarak kullanabilme olanağı sunar. Bu ise bilgisayar yeniden başladığında belirtilen kullanıcı veya sistem hesabının o işlemi yeniden başlatacağı böylece uygulamamızın sürekli çalışır halde olacağı anlamına gelmektedir. Bileşenleri Windows Service olarak çalıştırabilmek için My Application Properties penceresinden ve Activation tabından Server Application a tıklandıktan sonra Run Application As NT Service işaretlenmelidir. COM+ Uygulamalarının İzlenmesi Ve Yönetilmesi Bilgisayarda yüklü olan COM+ uygulamalarının görülmesi ve yönetilmesi için Component Services Yönetim Aracı adı verilen araç kullanılır. Bu araç sayesinde bileşen veya uygulama bazında değişiklik yapılabilir veya bazı uygulamalar durdulup yeniden başlatılabilir. Bu araç Control Panel den Administrative Tools altından Component Services tıklanarak açılabilir..
Bu pencerede bilgisayarda yüklü olan COM+ uygulamalarını görmek için sol tarafta bulunan Component Services klasörü geneişletildikten sonra sırası ile Computers, My Computer, COM+ Applications klasörleride genişletilir. Sol tarafta gördüğümüz uygulamaların hangi bileşenlerden oluştuğunu ve bu bileşenleri görmek için sol taraftan uygulamayı seçtikten sonra Components klasörü çift tıklanır. Bu bileşenin interfacelerini görmek için interfacelerini görmek istediğimiz bileşen seçildikten sonra Interfaces klasörü çift tıklanır.
Uygulama tipinin server uygulamamı yoksa kitaplık uygulamasımı olacağının belirlenmesi için aynı pencerede tipini değiştirmek istediğimiz uygulamaya sağ tıklanır ve Properties menüsü seçilir. Açılan pencerede Activation tabı seçilir ve Library Application veya Server Application seçeneklerden biri seçildikten sonra OK basılarak pencere kapatılır.
Server uygulaması kendisine tahsis edilmiş işlemde çalıştığından bu işlemin durdurup başlatma gibi opsiyonların olduğu çok açıktır. Ancak COM+ 1.5 ile birlikte artık server uygulamalarını duraklatıp yeniden başlatmak mümkün hale gelmiştir. Ayrıca herbir kitaplık veya sunucu uygulamasını veya herbir bileşeni tek tek disable veya enable etme yeteneğinide beraberinde getirmiştir. Duraklarma ve disable etme opsiyonları kullanımında yeni bir bileşen aktive olmayacaktır ama halihazırda kullanılmakta olan bileşenler çalışmalarına devam edeceklerdir. Bir uygulamayı disable ederek o andaki mevcut işlemleri etkilemeden yeni bir versiyon yüklemek veya bazı düzenlemeler yapmak mümkündür ve bu işlemleri yaparken hata alma olasılığı düşük olacaktır. Uygulamayı disable ettiğinizde sunucuyu yeniden başlatsanız bile yeni aktivasyonlar kabul edilmeyecektir, yani sunucu bir önceki durumunu hatırladığından uygulamayı yeniden enable etmek gerekmektedir. Uygulamaları durdurmak, başlatmak, enable, disable etmek Component Services Yönetim aracı sayesinde yapılmaktadır. Bu işlemlerin yapılması istenilen bileşen seçilir ve sağ tıklanarak açılan menüden ilgili işlem seçilir. Çalışan uygulamaları bazı hata oluşan durumlarda sadece hata oluşturan işlemi incelemek istediğinizde uygulamayı duraklatıp o bileşen üzerinden debug işlemi gerçekleştirmek isteyebilirsiniz. Bu durumda yeni Component Services Yönetim Aracı nda Running Processes seçilir ve o an çalışmakta olan işlemlerin arasından duraklatılmak istenen işlem sağ tıklanır ve açılan menüden pause seçilir. Applications, Assemblies And Classes (Uygulamalar, Assemblyler ve Sınıflar) Bir uygulama birçok assembly den birçok class barındırıyor olabilir. Bir bileşen bir COM+ uygulamasında kullanılmaya ayarlandıktan sonra başka bir COM+ uygulamasında kullanılmamalıdır. Bir assembly birden fazla uygulamaya class sağlıyor olabilir. Bunu bir örnek şekil üzerinden inceleyecek olursak. COM+ Catalog (COM+ Kataloğu) COM+ çalışma zamanı mimarisinin çok önemli bir elemanıda COM+ kataloğudur. COM+ kataloğu uygulamalarla ilgili tüm bilgileri tutar. Mesela ismi IlkUygulamam olan ve IlkBilesenim bileşenini içeren bir server uygulamasına ait tüm veriler burada saklanmaktadır. En basit anlamda COM+ kataloğu serverda bulunan uygulama adını,türünü ve uygulamada
kullanılan bileşenlerin tutulduğu bir veritabanıdır. Aynı zamanda çalışma zamanı gereksinimleride bu katalogdan sağlanr, yani bir bileşen transaction içinde yer alacaksa bu bileşen yaratıldığı zaman transactiona girmesi gerektiğini COM+ kataloğu bilir. Component Services Yönetim Aracında yapılmış olan her tür değişiklik bu katalogda saklanır. Ayrıca bu ayarları uygun API leri kullanarakta yönetmek mümkündür. COM+ da Uygulama Yaratalım Yeni bir uygulama yaratmak için öncelikle Component Services Yönetim Aracı açılıp Component Services ve My Computer klasörlerini genişletilmelidir. COM+ Applications klasörüne sağ tıklanır ve açılan menüden New ve Application seçilir. Karşımıza COM+ Uygulama Yükleme Sihirbazı gelir, ilk pencrede next e basarak ilerlenir. Karşımıza çıkan pencereden eğer yeni bir uygulama yaratacaksak Create An Empty Application, daha önceden Application Export Wizard kullanılarak export edilmiş bir uygulamayı eklemek için Install Pre-Built Applications seçilir. Yaratacağımız uygulama yeni bir uygulama olduğundan Create An Empty Application ı seçtikten sonra uygulamamızın ismini ve tipini belirleyeyip next e basarız.
Bir sonraki adımda ise uygulamamızın sistemde hangi kullanıcı ile çalışacağını seçilir ve next e basılır. Kitabın son kısımlarında inceleyeceğimiz roller yaratılır ve daha sonra.son ekranda Finish e basarak uygulamamızın kurma işlemini biter.
Mevcut uygulamamıza bir bileşen eklemek için Component Services Yönetim ekranında bileşen eklemek istediğimiz uygulamanın altındaki Components klasörüne sağ tıklanır ve New ve Component seçilir. Shirbazın ilk sayfası next e basılarak geçildikten sonra açılan pencerede bileşen eklemek için üç seçenek vardır bunlar; Install New Component, Import Components That Are Already Registered, Install New Event Class dır.anlamlarını inceleyecek olursak Install New Component yeni bir bileşen yüklemek için kullanılır, Import Components That Are Already Registered ise daha önceden Regsvr32.exe ile sistemin registy kayıtlarına kaydedilmiş bileşenleri uygulamaya katmak içindir, Install New Event Class ise COM+ Event Service içinde kullanılmış COM+ olaylarını eklemek içindir. Bu adımdan sonra çıkan pencereden bileşenimizi seçerek Add e basarız ve next, finish ile sihirbazdan çıkarız. Yarattığımız uygulamalardaki bileşenlerin aktivitelerini görmek için Component Services Yönetim Aracında Distributed Transaction Cordinator seçilir ve daha sonra Transaction Statistics seçilir. Bu pencereden Transaction istatistikleri izlenebilir. Context ve Interception Contextler aynı çalışma zamanı gereksinimlerini barındıran nesneleri guruplamak için kullanılırlar. Bir COM+ uygulamasında çalışması için yaratılmış bileşenler configured bileşenlerdir ve bu bileşenlerin çalışma zamanı gereksinimleri COM+ kataloğunda belirli özelliklerin bir bileşimidir. Çalışma zamanı gereksinimlerinin özellikleri o nesnelerin hangi COM+ servislerini kullanacaklarını ve bu servisleri nasıl çalıştıracaklarını belirler. Bir class ın örneği yaratıldığı zaman COM+ bu örneği çalışabileceği bir ortam olan ve classın istediği özellikleri taşıyan Context e koyar. Contextlerin özellikleri tanımlarını daha önce yaptığımız Senkronizasyon, Transaction, Threading, JIT, Object pooling, Securit olabilmektedir. Her COM+ nesnesi bir Context gurubu içinde bulunmalıdır. Context ler ise
en az bir COM+ nesnesi içermelidirler. Her class ın çalışma zamanı gereksinimleri farklı olabileceğinden class lar farklı contextlerde yer alabilirler. Dolayısıyla çoğunlukla olduğu gibi bir işlem birden fazla context kaplıyor olabilir. İki çeşit context vardır. Bunlar object context ve call context tir. Object context yaşam süreci boyunca hafızada ve uygulamada kalırken call context sadece çağrıldığı metodun işi bitinceye kadar aktif kalacaktır. Bu sebepten dolayı call context genelde güvenlik için kullanılır. Bir istemci serviced bileşen yaratmaya çalıştığı zaman COM+ servisleri yeni bileşenin özelliklerini COM+ kataloğundan okuyarak belirler ve eğer çalışma zamanı gereksinimleri aynı ise aynı context içinde, farklı ise farklı bir context içine nesne yaratılır. Aynı context içindeki nesnelerin iletişiminde bir problem yoktur ancak farklı context lerde bulunan nesneler için.ner Enterprise Services bize yönetilebilir bir proxy sunar. Bu proxy bize sadece gerekli gerekli güvenlik koşullarının sağlandığı zaman diğer context gurubundaki metodları çağırabilem avantajını getirir. Ancak Contextlerin bazı özellikleri her context için tekrar yaratılırlar. Bunlar; Transaction Id : Nesnenin içinde bulunduğu Distributed (dağıtılmış) Tansaction a ait Id numarasıdır. Bu numara bir transactionda hangi nesnelerin bulunduğunun anlaşılmasını sağlar ve transaction ayarlarına göre üretilebilir. Activity Id : Çalışmakta olan aktivitiye ait Id numarasıdır. Bu numara senkronizasyon için kullanılmaktadır ve senkronizasyon ayarlarına göre üretilebilir. Consistent Flag : İşin nesne tarafından tutarlı bir şekilde yapıldığını ve transaction ın commit edilebileceğini bildirir. True veya False değerlerini alabilir. Done Flag : Nesnenin işini yapıp bitirdiğini ve metod içinde deaktive edilebileceğini belirtir. True veya False Değerlerini alabilir. COM+ contexti aktivasyonu ve çalışma zamanı özelliklerini belirleyip servislerin bileşenlerde nasıl etkili olacağına karar verir. Ancak COM+ context ile tamamen farklı bir yapı olan ve hiçbirzaman iletişim içinde olmayan.net context sadece çoklu threadler için senkronizasyonu belirler. Yukarıda incelediğimiz gibi farklı context ler arasında metod çağırımları söz konusu olduğu zaman bir proxy yaratılıyordu. Bu işleme Interception adı verilmektedir. İki çeşit Interception vardır bunlardan ilki Activation Interception diğeri ise Method-Call Interception dur. Activation Interception bir nesnenin aktive edilmesi veya client trarafından gelen yaratılma isteğinin COM+ tarafından alınmasından sonra method düzeyinde interception oluşturması için gereklidir. Bunun yanısıra Object Pooling ve Object Constructor Stringlerinin Servislerinin COM+ tarafından sunulmasını sağlar. Farklı context lerde bulunan objeler arasındaki iletişim sağlanırken bir context ten diğer context e giderken çağrı arada Interception katmanından geçer ve asıl nesneye erişir, geri dönüştede izlenen yol aynıdır.
Method düzeyinde inteception bileşenin çalışabilmesi için gerekli tüm koşulların sağlanmış olduğu bitr ortamda çalışmasını sağlar vede JIT Activation ve transaction gibi bazı hizmetlerin nesneye erişimlmesinden önce devreye girmesinde rol oynar. Interceptionun gerekli olduğu zamanları inceleyecek olursak, Objeden objeye olan isteklerde : bir objeden bir objeye olan istek hiçbir sınır geçmez. Her iki nesneninde aynı bilgisayarda ve aynı çalışma zamanı gereksinimlerinde oldukları zaman gerçekleşir ve çok hızlıdır. Cross context istekler : farklı contextlerde bulunan yani aynı çalışma zamanı gereksinimleri bulunmayan bileşenler arasında olan istektir ve nispeten hızlı bir yöntemdir. Bu yönteme örnek olarak iki bileşen ele alacak olursak ve bu bileşenlerden birinde transaction servisi gerekli ise ve diğerinde desteklenmiyorsa farklı çalışma zamanı gereksinimlerinden dolayı farklı contextlerde bulunacaklardır ve metod çağırımları interception üzerinden yapılacaktır. Cross application calls : iki nesnenin farklı COM+ uygulamalarında bulundukları zaman gerçekleşir ve her metod çağrılışında bileşenler farklı uygulamalarda olduklarından farklı güvenlik sınırlandırmalarına tabi olduklarından interception gereklidir. Cross appdomain calls : bu call eğer iki nesneninde farklı.net frameworkleri uygulama domaini üzerinde yeralması durumunda gerçekleşir. Uygulamalar birbirinden tamamen bağımsızdır. Böyle bir uygulamada remoting ve interception kullanılması şarttır.
.NET Enterprise Servisleri için Asseblyleri Ayarlamak Sınıflar ve asseblylerin.net Enterprise servislerine erişimleri özellikler(attributes) sayesinde ayarlanabilir. Özellikler çalışma zamanı veya kayıt zamanında belirlenerek bir sınıfın hangi servisleri alabileceği ve servisleri nasıl kullanacağı hakkındaki yapılandırmaların yapılmasını sağlar. System.EnterpriseServices namespacini projemize referans olarak ekledikten sonra bileşenimizin alabileceği herhangi bir servise ait özellikleri rahatlıkla yönetip ayarlamk mümkün olacaktır. Örneğin kullanabileceğimiz iki özellik ApplicationName ve ApplicationActivationdur. Bunlardan ApplicationName uygulamamaızın ismini belirlerken, ApplicationActivation uygulamamızın servermı yoksa library uygulamasımı olacağını belirler. Bu özellikler program tarafından kodla yapılabileceği gibi Component Service yönetim ekranındanda yapılabilmektedir. Bileşenimize ait bazı özellikler kayıt sırasında belirlenmeli ve daha sonra değiştirilmemelidir. Bunalara örnek gösterecek olursak bileşenimizin transaction kullanması gerekiyorsa transaction özelliği Required olarak ayarlanmalı ve öyle kayıt edilmelidir ve kayıt sonrasında bu özelliğe ait bir değişiklik yapılmamalıdır. Bir değişiklik yapılmamasının sebebi bileşenimizin transaction içinde yer alabilecek şekilde şekilde yapılandırılması ve buna göre derlenmesidir. Bu yüzden uygulamanın gereksinimleri geliştirici tarafından uygulama yaratılmadan önce çok iyi analiz edilmelidir. Özellikleri yönetim ekranından ayarlayabileceğimiz gibi projemize EnterpriseServices i eklediğimiz ve özellikleri kodda belirlediğimiz anda COM+ kataloğunda yer alan bütün özellikler uygulamamızı derlerken kodda belirttiğimiz şekilde ayarlanacak ve özellikler COM+ kataloğuna transfer edilecektir. Servis Verilen Bir Bileşen Yaratımı.Net Enterprise Servislerini kullanamak için bir class mutlaka ServicedComponent classını inherit etmelidir. ServicedComponent class ı System.EnterpriseServices namespace i altında yer alamaktadır. Bu class bize gerekli activation ve interception işlemlerinin doğru bir şekilde çalışmasını sunar ve aynı zamanda bu sınıfta overide edebileceğimiz ve kişiselleştirebileceğimiz Activate ve Deactivate gibi bazı methodlar vardır. ServicedComponent class ını inherit edebilmemiz için mutlaka System.EnterpriseServices namespace ini projemize referans olarak eklemiş olmamız gerekmektedir. Daha sonra bu namespace i import ederek ServicesComponent class ına ulaşabiliriz. Imports System.EnterpriseServices Public Class IlkBilesenim Inherits ServicedComponent Public Sub New() 'İlk Com+ Bileşenimizi yarattık End Sub End Class
Servis Verilen Bileşenden Context e Erişmek Daha öncede basitçe değindiğimiz gibi her obje context adı verilen ve transaction, activity, ve security bilgilerini içeren bir ortam içinde çalışmaktadır. Bağlam içindeki bazı özelliklere erişmemizi ContextUtil sınıfı aracılığı ile sağlarız ve bu sınıfın bazı metodları ile bazı servisleri kontrol edebiliriz. Herbir bağlamın kendine ait GUID formunda benzersiz bir tanımlayıcı numarası vardır. Bu numaraya ContextUtil sınıfındaki GetContextId metodu ile erişebiliriz. Imports System.EnterpriseServices Public Class GuidiAlinacakBilesenim Inherits ServicedComponent Public Function BaglamGUIDi() As System.Guid Return ContextUtil.ContextId End Function End Class JIT Aktivasyonu Neden Gereklidir? Database bağlantıları ve hafıza gibi sunucu kaynakları çok istemci tarafından paylaşılması gereken sınırlı kaynaklardır. Çok istemciye hizmet sunabilecek uygulamalar geliştirmek istiyorsak JIT kullanmamız kaçınılmazdır. JIT Aktivasyonu genellikle transaction ve senkronizasyon için kullanılmaktadır. Geleneksel uygulamalarda istemci bir sunucu kaynağına talepte bulunur ve bunu belirsiz bir süre boyunca kullanır. Dolayısıyla her istemci bir sunucu kaynagını belirsiz bir süre boyunca kullanacağı için çok kullanıcı uygulamalardaki performans nedeniyle bu yöntem kullanılmamaktadır. Ancak artık istemciler sunucu kaynaklarını sadece ihtiyaçları olduğu süre boyunca kullanakta ve böylece performanstaki düşüklük sorunu aşılacağından uygulama çoklu istemcilere yanıt verebilir hale gelmektedir. JIT sayesinde bu sunucu kaynaklarını serbest bırakacak kodunda yazılım geliştirici tarafından yazılmasına gerek kalmaz. JIT i tanımlarken bahsettiğimiz gibi transaction kullanılıyorsa JIT kullanılmalıdır çünkü transaction içinde yer alan bir nesne bir sonraki transactionda tekrardan yaratılmalı ve bir önceki nesnenin özelliklerini taşımamalıdır. JIT aynı zamanda senkronizasyon içinde kullanılmaktadır çünkü her bir çağırım için bir nesnenin birbirinden bağımsız örneklerini yaratmalıdır ve işi bittiği zaman bu örneklerin kullanımdan kaldırılması gerekemektedir. Transaction ve senkronizasyonda nesneler işleri bittiği zaman otomatik olarak yok edilmezlerse kaynak kullanımında aşırı bir artış gözlenmesi kaçınlmazdır. Şimdide JIT in nasıl çalıştığını inceleyelim. Bir nesneye bir istek gittiği zaman kesme eğer bu nesnede JIT aktive edilmişse nesnenin bir örneğini yaratır ve Activate metodunu çağırır. Nesne gerekli kaynakları kullanmaya hazır duruma gelir. Daha sonrasında ise nesnedeki bir method çağırıldığında bu metod işlemi gerçekleştiri ve işlem bittiği zaman Done Bit inin değerini true olarak atar ve metodun sonucunu geriye döndürür. Daha sonrasında ise metodun Done Bit değeri true ise nesnenin Deactivate metodu çalıştırılark nesnenin rezerve ettiği kaynakları geriye bırakılır ve nesne erişemez duruma gelir. Daha sonrasında ise bu nesneleri garbace collectiondan garbage collector alarak temizler.
Şimdide JIT aktivasyonunu yazdığımız bir bileşene nasıl uygulayacağımızı inceleyelim. <JustInTimeActivation(True)> _ Public Class JIT Inherits System.EnterpriseServices.ServicedComponent Public Sub Metodum() End Sub Protected Overrides Sub Activate() 'Activate metodunda yapılacak iş End Sub Protected Overrides Sub Deactivate() 'Deactivate metodunda yapılacak iş End Sub End Class JIT konusunda bahsigeçen Done Bit inin ne işe yaradığını inceleyelim. Objede çağırılan metodun çalışma işlemi bittikten sonra true değerini alan bu bit artık nesnenin deaktive edilebileceğini belirtir. Eğer done bit inin değeri false ise nesne hafızadan kalkmaz ve birdahaki çalışma sonucu true değerini alıncaya kadar hafızada kalır. Done Bit inin programatik olarak yönetmek mümkündür. Bunu yönetmek için bileşenimizin özelliklerine müdahele etmemize izin verdiğini belirttiğimiz ContextUtil sınıfının DeactivateOnReturn özelliğini kullanabiliriz. Ancak DoneBit inin varsayılan olarak gelen false değerinin varsayılan değerini true yapmak için Autocomplete özelliğini kullanmamız gerekmektedir. Bu iki kullanıma ait bir örneği aşağıda inceleyeceğiz. Public Sub Metodum() 'Burada metodumuz işini yapar ContextUtil.DeactivateOnReturn = True End Sub Veya <AutoComplete(True)> _ Public Sub Metodum() 'Burada metodumuz işini yapar End Sub Aktivasyon ve Deaktivasyon Yönetilebilir veya yönetilemez kodda aktivasyon ve deaktivasyonolayları birbirinden farklı olmasına rağmen yaptıkları iş tüketimin bittiği anda kaynakları serbest bırakacak bir yapı sunmaktır. Objemizi her zaman Activate metodunda başlatmalıyız. Activate metodunun çalışması ise JIT özelliğinin aktive edilip edilmemesine bağlıdır. Alışılagelmiş deaktive yönteminde Deactivate metodu çağrıldığı zaman database bağlantısı gibi bazı kaynaklar serbest bırakılır ve Release metodu çağırılır. Bu metod ise objenin hafızadaki referansını dıfırlar. Bu sıfırlama işlemi sonrasında artık hiçbir istemci o nesneyi referans olarak kullanamayacağından bileşinimiz silinmiş demektir.ancak.net te ilk adım ortak olmasına karşın kesme katmanı artık o objeyi referans olarak göstermeyeceğinden dolayı nesne erişilemez duruma gelir ve artık hafızadan kaldırılabilir..net te yaratılmış nesneler silinme işlemini DeActivate metodunda yaparlar ve bundan dolayı tekrardan bir Dispose metodu yazmaya gerek kalmaz. Ancak yazılması kaçınılmaz ise Deacctivate metodu ile aynı işlevselliği sağlayabilecek bir metod yazılmalıdır.
Senkronizasyon Eşzamanlı Çalışma Sorunları Burada bahsi geçen eşzamanlı aynı anda birden fazla programın uyumlu çalışabilmesinin sorunsuzca tamamlanabilmesidir.tek işlemcili bir sistemde uyumlu çalışma başarısına zaman paylaşımı tekniği kullanarak erişilmesine karşın çok işlemcili sistemlerde ise bu başarıya her bir programın veya görevin farklı işlemcilerde aynı anda çalışmasıyla erişilir. Windows XP de bu uyumluluk thread adı verilen yapılar ile sağlanmaktadır. Ölçeklenebilir uygulamalar yazarken uyumluluk kullanılması kaçınılmazdır. Online bilet satışının yapıldığı ve çok talep gören bir konserin biletlerinin satışa çoktığı anı senaryolaştıracak olursak bu durumda sunucuya belki saniyede 10 tane istek gelecektir. Sunucunun bu istekleri serileştirerek sıraya koyup yapması yerine aynı anda gelen tüm isteklere cevap vererek paralel bir şekilde işlemleri yürütmesi doğru olan yöntemdir. Ancak bu istekleri aynı anda karşılayabilmel çoklu thread desteği olan bir altyapı ile sağlanmalıdır. Ancak bu şekilde çalışacak bir altyapı inşa etmek ve bunun üzerine kod yazmak oldukça zor ve maliyetli bir işlem olduğundan dolayı iş yapma yeteneği olan thread ler bir havuz oluşturularak saklanır. Bu havuzun maksimum ve minimum boyutu sunucumuzun donanımı ve kaynaklarına göre yapılandırılabilir. Sunucuya bir istek geldiği zaman bu havuzdan bir thread bu işlemi üzerine alır ve yerine getirir. Bu thread bu işlemle uğraşırken diğer treadler başka isteklere açık bir şekilde hazır beklerler. Öultitasking desteği bulunan işletim sistemlerinde ise threadler komplex bir algoritma ile işletim sistemi tarafından yönetilirler. Ve biz yazılım geliştiriciler tarafından kodun bu şekilde yazılması gerkemektedir. Kodun threading2e uygun şekilde yazılmaması durumunda karşımıza çıkabilecek bazı problemlere gözatacak olursak; a)yarış durumları Bu genellikle farklı thread ler altında çalışacak kodların birinin diğerinin sonucuna bağımlı olması durumunda karşımıza çıkar ve eğer ilk çalışması gereken thread yarışı kazanamazsa diğer thread hata verecektir. Bunun çözmek için ilk threadin kodunda belirli bir noktasına erişildiği anda ikinci threadi başalatabiliriz. Buda senkronizasyon konusu ile alakalıdır. b)deadlock Bu durumda ise bir threadin kaynakladığı bir kaynaga diğer thread tarafından erişilmeye çalışılmaktadır ve beklemede olduğundan dolayı onunda kilitlediği kaynaklar serbest bırakılmamılştır. İşte burumda ilk thread ikinci threadin kilitlediği kaynağa erişmeye kalkarsa bu iki thread birbirlerini kilitlemiş ve deadlock a girmiş demektir. Bu durum genellikle transacrionlarda görülebilmektedir. c)livelock bu durumda ise iki kaynağın kilitledikleri kaynakları değişmesi sırasında meydana gelebilecek bir durum söz konusudur. Bu durumda kaynaklar arasında dar bir tünel oldugunu düşünecek ve iş yapan kişilerin bu tünelde karşılaşıp kararsızlıkta kalarak birbirlerini geçmek için sağa sola haraket etmesi ancak karşısındakininde aynı kararsızlıkta sağa sola hareket etmesi sonucu bir geçiş yolu bulamaması sonucu meydana gelir.
Senkronizasyon Mekanizmaları Çok işlem yapılan ve çoklu thread içeren uygulamalarda thread ler kaynaklara erişirken başka bir thread ın bu kaynağa erişememesi tutarlılık bakımından gereklidir. Bu basit senkronizasyon uygulamasındanda anlaşılabileceği gibi bir threadın kaynakla işi bitmeden başka bir thread o kaynağa erişmemelidir. Buda kilitleme mekanizması ile sağlanır. Bir threadd bir kaynağa erişirken o kaynağa bir kilit koyarken başka uygulamaların veya threadlerin erişimine kapar işi bittiği zaman ise koymuş olduğu kilidi açar..net ile yazılmış olan bütün kodlar multithread dir ve bunlar arasındaki senkronizasyonu sağlayabilmek için.net Framework yapısında System.Threading uzay ismi vardır. Ancak COM+ ile.net senkronizasyonubirbirinden tamamen farklıdır..net senkronizasyonu proje düzeyindedir aynı bağlamda bulunan diğer uygulamlar veya baska bilgisayarlarda bulunan uygulamalar için geçerli değildir. Böyle br uygulamaya COM+ yapısında bulunan senkronizasyon izin vermektedir. COM bileşenlerinde single thread apartment(sta) modeli varken bu geliştirilip multithread apartment (MTA) modeli geliştirilmiştir bunun sebebi ise
Transactionlar Transactionlar veri bütünlüğünün ve işlemin kesinliğinin garanti altına alındığı önemli yapılardır. Bir kaynak veya birden fazla kaynak üzerinden birbirinden bağımsız birçok işlem yapıldığı durumda bu işlemlerin herhangi birinde bir hata oluşması veya o işlemin yapılamama durumunun ortaya çıkması halinde tüm işlemlerin geri alınarak verilerin işlem başlanmadan önceki haline dönmesi hayati önem taşımaktadır. Transactionlara birçok programda ihtiyaç duyulmaktadır. Transactionlar konusunda konuyu pekiştirmek amacıyla en sık verilen örnek banka hesapları arasındaki para transferlerinin yönetilmesidir. Burada bir hesaptan para çekildiği zaman diğer hesaba başarı ile yatması garanti edilmelidir, işte bu noktada transaction devreye girer ve çekilen paranın hesaba yatamaması durumunda tüm işlemi geri alarak bakiyeyi ilk durumuna geri getirecektir. Transaction lar ACID adı verilen temel özellikleri taşımalılardır. ACID in açılımını inceleyecek olursak; Atomicity : Bu özellik transactionda bulunan tüm işlemlerin başarılı bir şekilde yapılmasını veya hehangi bir hata oluştuğu zaman tüm işlemlerin geri alınması temelinin barındığı özelliktir. Bu tarz bir kodun yazılım geliştirici tarafından yazılmasının çok zamana malolacağı ve yazılım maliyetlerini arttıracağı transactionların bizim için ne kadar önemli oldğunu ortaya koymaktadır. Consistency : Bu özellik ise veri tutarlılığının ve bütünlüğünün garanti altına alınmasını sağlamaktadır. Bu konun başında verdiğimiz banka örneğindeki işlemlerin transactionlarla yönetildiğini düşünürsek yeni para yatırılmadığı ve sadece hesaplar arası para transferi yapıldığı bir sistemde tüm hesaplardaki toplam tutar hiçbir zaman değişmeyecektir. Isolation : Aynı kaynak üzerinde eşzamanlı yapılabilecek işlemlerden oluşabilecek hataların engellemesini temel alan özelliktir. İki tane transactional işlemimiz olduğunu yine banka örneği üzerinde inceleyelim. Aynı anda başlayan işlemlerden ilki bir hesaptan parayı çekti ancak diğer hesaba parayı yatıramadı, tam bu sırada ikinci işlem devreye girerek hesapta kalan parayı okudu. İlk işlem işlemi geri aldıktan sonar ikinci işlemde görülen hesap bakiyesi yanlıştır. Çünkü bu değişiklik birinci işlemin yeraldığı transaction içinde rollback edilmiştir. İşte bu gibi durumların önüne geçmek amacıyla isolation kullanılır ve bir lock level belirlenerek ikinci transactionun devreye bile girmemesini sağlamak elimizdedir. Durability : Üzerinde işlem yapılan serverda herhangi bir yazılım veya donanım problemi olması durumunda transactionlar kendisini ilk başladığı duruma getirebilecek özelliktedirler. Bir Resource Manager(Kaynak Yöneticisi) veriyi saklamaktan sorumlu olan ve transaction destekleyen yapılardır. Desteklenen transactionlar local veya distributed olabilirler. En çok kullanılan resource manager Microsoft SQL Server 7.0 dır..net te bulunan transactionlar sadece resource manager lar ile çalışmayı desteklemektedir. Eğer verilerinizi bir file system üzerinde tutuyorsanız bu durumda verileriniz distributed bir transaction içinde yeralmasını sağlamak için Compensanting Resource Manager gibi teknolojileri kullanabilirsiniz. Biraz once değindiğimiz local ve distributed transaction kavramlarını inceleyelim. Local Transactions : Bu tür transactionlar client server uygulamalarında ve değişikliklerin bir connection üzerinden bir kaynağa yapıldığı durumlarda gerçekleşir. ADO.Net bu transaction