Arşiv | ASP.NET 4.0 RSS feed for this section

SOAP Nedir?

17 Kas

SOAP (Simple Object Access Protocol – Basit Nesne Erişim Protokolü), Service-oriented Architecture felsefesini pratiğe uyarlayan iki interface’den biridir. Üzerinde bulunanUniversal Description Discovery and Integration (UDDI) ile birlikte hizmet yönelimli mimarinin pratikte kullanılmasını mümkün kılar.

SOAP Nedir?

SOAP (Basit Nesne Erişim Protokolü) dağıtık uygulamalarda ve web servislerinin haberleşmesinde kullanılmak üzere tasarlanan, RPC (Remote Procedure Call) modelini kullanan, istemci/sunucu mantığına dayalı bir protokoldür. Daha genel olarak SOAP, web üzerinden fonksiyonları kullanmak için geliştirilmiş bir sistemin XML tabanlı kurallar topluluğudur. SOAP ile ilgili bütün mesajlar XML formatında iletilir ve temel olarak bir SOAP mesajı 3 şekilde oluşabilir:Metod ÇağırımıCevap MesajıHata Mesajı

Bir SOAP mesajının yapısı

Envelope

Bütün SOAP mesajlarının içinde olduğu elemandır. SOAP mesajına ilişkin XML belgesinin root elemanı olmak zorundadır. Envelope elemanı içinde Body veya Header gibi elemanlar bulunur. Envelope elemanının içinde her zaman bir Body elemanı vardır fakat Header elemanı olmak zorunda değildir. SOAP mimarisine göre eğer Envelope elemanı içinde Header elemanı varsa bu eleman Envelope elemanının içindeki ilk eleman olmalıdır. Soap kullanan mimarilerde kesinlikle erişim protokolü olarark TCP kullanılmalıdır

Header

SOAP mesajlarındaki Header elemanını HTML standartlarında bulunan etiketlerine benzetebiliriz. Header bölümü metot çağrımı ile doğrudan ilişkili değildir. Header bölümü ile meta-data dediğimizi bilgiler gönderilir.

Body

Body elemanı SOAP mesajının en önemli kısmını oluşturur. Body bölümünde web metodunun adı ve metodun parametrik bilgileri XML formatında gönderilir. Cevap mesajında ise metodun geri dönüş değeri Body bölgesine eklenir. Metodun parametrik yapısının bu şekilde XML formatında yazılmasına SOAP Serialization denir. Son olarak hata mesajlarında ise Body bölümünde hatanın adı ve tanımı gibi bilgiler bulunur.

Kaynak: Sefer ALGAN, http://tr.m.wikipedia.org/wiki/SOAP

Page Methods

3 Tem

Burada .Net bize birden fazla yerde nasıl ve hangi aşamada işlem yaptırıyor ona bakalım.

Bu olay metodu bir web sayfasının yaşam döngüsünde genellikle kontrolün dinamik olarak oluşturulması istendiği durumlarda tercih edilmektedir. Elbetteki bu bir zorunluluk değildir. İstenildiğinde Page_PreInit yada Page_Load gibi event metodlarınıda dinamik kontrol oluşturma amacıyla göz önüne alabiliriz

protected void Page_PreInit(object sender, EventArgs e)
{
    Debug.WriteLine(“Page_PreInit metodu”);
}
protected void Page_Init(object sender, EventArgs e)
{
    Debug.WriteLine(“Page_Init metodu”);
}
protected void Page_Load(object sender, EventArgs e)
{
    // Diğer kod satırları
    Debug.WriteLine(“Page_Load metodu”);
}
protected void Page_PreRender(object sender, EventArgs e)
{
    Debug.WriteLine(“Page PreRender Metodu”);
}
protected void Page_Unload(object sender, EventArgs e)
{
    Debug.WriteLine(“Page Unload Metodu”);
}

ASP.NET 3.5 Summary 4 – Output Caching etc…

28 Haz
 
 ASP NET sitelerinde performansı arttırmak için kullanılan en önemli yapılardan biri olan Caching mekanizmasını anlatmaya çalışacağım. Caching’in Türkçesi önbellekleme demektir ki adından da anlaşılacağı gibi sayfanızın bir kopyasının önbellekte saklanması ve artık gelen isteklere de önbelleklenmiş sayfanın gösterilmesi ve bu sayede ASP.NET sayfamızın yeniden derlenmemesi ve böylece artan performans. Artık düşündüğümüzde 1000 lerce kişinin bağlandığı bir server da isteklere göre sayfaların derlenmesi ve kullanıcılara gösterilmesinin oluşturacağı gecikmeyi herhalde tahmin edebilirsiniz ama tabiî ki cachin’gin iyi yönleri olduğu gibi kötü yönleride vardır, aslında kötü yönleri demeyelim de dezavantajları diyelim ama ne güzeldir ki yine bu dezavantajları da caching için kullanacağımız kodlarda bazı değişikler yaparak giderebiliriz. Caching olayını eğer sınıflamak gerekirse ana başlık altında 2 sınıfta toplayabiliriz.

1– OutPut Caching (*Çıktı Önbellekleme)
2– Data Caching (*Veri Önbellekleme)

Ve bunların dışında ama yukarıdakiler ile alakalı alt başlık olarakta koyabileceğimiz özelleşmiş cachingler ise Fragment Caching (*Parça parça önbellekleme) ki bu OutPut Caching’in özelleşmiş bir halidir ve DataSource Caching (*VeriKaynağı Önbellekleme) ki bu da Data Caching in özelleşmiş halidir.

Biz bu makalemizde Data Cacheing hariç diğer bütün yöntemlere göz atmaya çalıcağız.

OutPut Caching : Bu Cachleme sayesinde sayfamızın son HTML halininin önbellekte bir kopyası oluşturulur ve gelen isteklere bu sayfalar gönderilir ama unutmadan söyleyelim cache için bir yaşam süresi diyebileceğim Duration alt özelliğini eklememiz gerekecektir. Bunun sayesinde cache mizin ne kadar süre
önbellekte saklanacağını ayarlamış olacağız. Şimdi bu dediklerimizi bir örnekle açaklamaya çalışalım.

İlk başta kendinize yeni bir ASP.NET projesi oluşturun. Sayfasınıza

 

<%@ OutputCache Duration=”5″ VaryByParam=”None” %> satırını ekleyin.Bu kod satırını açıklamak gerekirse ;
*Duration : Sayfamızın önbellekte ne kadar saklanacağını belirttiğimiz alt özelliktir.
* VaryByParam : Bu alt özellikiğin “None” yapılması demek, Sayfamızın tamamının önbelleğe alınması demektir ki buna ileride daha detaylı değineceğiz.

Şimdi sayfamıza önbelleklemeyi somut bir şekilde görmek için Zaman ekleyelim. Bunu yapmak için tek yapmanız gereken sayfamıza bir tane label eklemeniz ve şu kodları yazmanız;

public partial class _Default : System.Web.UI.Page
{
         protected void Page_Load(object sender, EventArgs e)
         {
               label1.Text = DateTime.Now.ToLongTimeString();
         }
}

Yukarıda bulunan kodda sizinde göreceğiniz gibi Sayfa her Yüklendiğinde eğer önbellekleme yapılmamış ise o anki saati gösterir ama şimdi sayfamızı derleyelim ve sayfamızı devamlı Refresh yani yenileyelim , ne gördünüz? Tabiki saatin hiç değişmediğini, neden? Nedeni ni söyleyelim ; Önbellekleme tabiki. Sayfamızı devamlı yenilerseniz 5 saniyede bir saatin saniyesinin değişeceğini göreceksiniz. Çünkü biz önbellekleme süresini 5 saniye olarak ayarladık ve her 5 saniyede yeni bir cachimiz oluşturulur.

Bu olayın avantajları :

*Sayfamız yeniden derlenmedi
*Kullanıcılara değişmeyen yani static sayfalar daha hızlı bir şekilde gösterilir
*Server gereksiz yere yorulmaz
(Static sayfalarda performans için mükemmel bir yöntem.)

Kısacası performans artışı…

Dezavantajlar ise :

*Eğer sayfamız dinamik olsaydı ve dışarıdan QueryString ler ile farklı bilgiler gelseydi !

İşte yukarıdaki dezavantajtan sıyrılmanın yöntemi :

Yeniden bir proje açın ve bu sefer iki tane asp.net sayfası ekleyin projenize. İsimleri Default.aspx ve Default2.aspx olsun.Default2.aspx sayfasının Source kısmına şunu yazmayı uutmayın : <%@ OutputCache Duration=”10″ VaryByParam=”None” %> Burada önbellekte kalma süresini 10 saniye yaptık. Şimdi Default.aspx sayfamızın Kod kısmı olan Default.aspx.cs sayfasının Button_Click olayına aşağıdaki kodları yazın ama bundan önce tabi sayfamıza bir tane TextBox ve bir tane de Button Kontrolu koymayı unutmayın.

protected void Button1_Click(object sender, EventArgs e)
{
      Response.Redirect(“Default.aspx?giden=” + TextBox1.Text);
}

Burada Default2.aspx sayfamıza giden QueryStringi sayesinde TextBox1 den alınan veriyi gönderiyoruz şimdi de Default.aspx sayfasına bir tane Label koyun ve Default2.aspx.cs sayfasına ise şu kodları yazın ;

protected void Page_Load(object sender, EventArgs e)
{
      Label1.Text = Request.QueryString[“giden”].ToString();
}

Burada ise gelen verimizi Request ile aldırdıktan sonra Labelimiza yazdırıyoruz. Evet şimdi deneyin bakalım ne olacak.Ben size söyleyeyim ilk gönderdiğiniz veri (TextBox a yazıp buttona bastıktan sonra gönderilen veri yani) Default2.aspx sayfamızda görülecek ama bunda sonra her göndereceğiniz veride yeni ilk gönderdiğiniz veri şeklinde gözükecek.Yani Label kontrolmuzde hep aynı yazı gözükecek taki 10 sn geçene kadar.İşte size Dezavantaj ?. İşte bundan şöyle sıyrılacağız : <%@ OutputCache Duration=”10″ VaryByParam=”*” %> kodumuzun VaryByParam özelliğini “*” bu şekilde yapın ve bu sefer yeniden deneyin bakalım ne olacak o zaman. İşte şimdi problem çözüldü. Artık her gelen yeni QueryStringe göre bir cache oluşturulup kullanıcılara en taze hali gösterilir ama burada da çok ama çok önemli bir durum söz konusu: Şimdi siz mesela “Ahmet” diye bir QueryString gönderdiniz Default2.aspx sayfamıza ve doğal olarak ta label kontrolmuzda “Ahmet” gözükecektir.İşte bu sayfanın serverda A kopyası olarak saklandığını düşünelim.Peki başka bir kullanıcı ise “Mehmet” diye bir QueryString gönderdi o zaman Default2.aspx sayfamda ise “Mehmet” olarak gözükecektir Label kontrolum ama önceki A kopyam silindi mi peki? Cevap vereyim: Kocaman bir Hayır! A kopyam hala saklanmakta ve bu sefer ise “Mehmet” olan B kopyam olarak saklanıyor.Eğer başka bir tane daha farklı bir QueryString ile sayfama istekte bulunulursa bu sefer sayfam C kopyası olarak saklanacaktır. Peki bunlar saklandı ama ne olacak bunlara.Eğer bir kullanıcı sayfamı Ahmet QueryString ile çağırırsa o zaman ona A kopyası gösterilecek ve sayfam yeniden derlenmecektir.Eğer başkası ise “Mehmet” QueryString ile çağırırsa ona da B kopyası gönderilecektir ve bu sayede yine performans artışı sağlanacaktır.Nasıl ama? ? Peki ben eğer iki tane QueryString gönderirsem ama sayfamın sadece bir tane QueryStringim değiştiğinde cachleme yapmasını istiyorsam o zaman ne yaparım.Düşünün bir UrunlerID ve HizmetID diye iki tane QueryStringim var ve ben bunlardan sadece HizmetID değiştiğinde sayfamın serverda farklı bir cachlenmiş halinin saklanmasını istiyorum.O zaman yapmam gereken sadece şu : <%@ OutputCache Duration=”10″ VaryByParam=”HizmetlerID” %> İşte bu kadar. Artık istediğim gibi oldu.(Unutmadan! Bakın bu yöntemler sadece QueryStringler için geçerlidir.Cookiler ve Sessionlar için geçerli yöntemler değillerdir) Eğer ki ben birkaç tane QueryString e göre cachleme yapmak istiyorsam o zaman ise Noktalı Virgül kullanmam yeterli olacaktır. Örneğin VaryByParam=”HizmetlerID;UrunlerID;SenID” vs gibi.Gayet kolay değil mi?

Şimdi diğer özellikleri inceleyelim (Bu makalede bunları yüzeysel geçeceğiz ama diğer makalelerde hepsine teker teker inceleyeceğiz) :

*VaryByCustom : Bu alt özellik ; kendi yazacağımız kodumuza göre Cahcleme yapabiliriz.Mesela Browser farklılıklarına göre bile Önbellekme yapabiliriz.Bir düşünün Nescape kullanan ve bir kullanıcı doğal olarak Nescape-Optimized sayfalara ulaşacaktır aynı şekilde IE kullanan ise Explorer-Optimized sayfalar kullanmak ister.İşte bu farklılık doğal olarak Cachlemeyede yansır. Aynı şekilde başta ta dediğimiz gibi kendinize Procuderler yazarak (Code-Behind a yazabileceğiniz gibi Global.asax dosyalarında yazabilirsiniz ) istediğiniz bir şeye göre cachleme yapabilirsiniz.Diğer makalemizde kodların nasıl yazılacağını göstermeye çalışacağız ki bu özelliğin kullanması ise özel bir kod yapısı kullanması gerekmektedir.

*DiskCacheable : Bu alt özellik ise diskinizin önbellenebilir veya olmadığını ayarlamanızı sağlar.Bool değer geriye dönderir.( True/False)

*VaryByHeader : Bu alt özellik ise HTML başlığınızın değişimine göre Cachleme yapılmasını sağlar.

*Location : Bu ise Cachlemenmiş dosyaların nerede saklancağını göstermenizi sağlar.

*NoStore : Depolama yapılıp yapılmayacağını belirtmenizi sağlar. (True/False)

*SqlDependency : Bu alt özellik ise gerçekten en önemli özelliklerden biridir ve Sql bağımlılığını gösterir. Şöyleki DataBase olarak Sql kullandığınız durumda eğer sayfanızı önbellekliyorsanız ve eğer değişen verileriniz (Delete/Update vs gibi) varsa doğal olarak sayfanın en güncel veriyi kullanıcılara göstermesi gerekecektir. Bu durumda bu özelliği kullanarak eğer veritabanınızda bir değişiklik olmuş ise yeni bir cachin oluşturulması sağlanır.

*VaryByControl : Bu ise istediğiniz kontrollere göre önbellekleme yapılmasını sağlar.

Unutmadan söyleyelim bu anlatılanları hepsi OuptPut Caching kapsamına girmektedir.

Fragment Caching : Bazen sayfamızın her tarafını değilde bazı yerlerini önbellekleme ihtiyacı duyarız ki bu bazen çok önemli bir ihtiyaçta olabilir.İşte bu durumlarda kullanılacak olan Fragment Cachingtir.Bunu yapmak aslından çok basittir ve User Controls kullanılmasını gerektirir. Eğer User Controls bilmiyorsanız ilk başta onları incelemenizde yarar var. User Controls oluşturun ve bunu VaryByControl özelliğine bağlayın ve bitti.Unutmadan söyleyelim eğer bu yapıyı kullancaksanız Cachleme zamanı bitmeden Önbelleklediğiniz User Controllerinin (*Kullanıcı Kontroleri) Event’ler (*Olayları) çalışmaz.

İlk başta anlattığımız ama örnek vermediğimiz Fragment cahcing ile devam edelim. Kısaca özetlemek gerekirse bu cachleme yöntemi parça parça cachleme olarakta türkçe bir karşılık getirebiliriz. Bu yöntemde amaç sayfamızın belli bölümlerini önbellekleme yapmak ve böylece istediğimiz doğrultuda performans artışına gitmektir. Unutmadan söylemek gerekki burada ki ince nokta user controls ( kullanıcı kontrolleri ) kullanmak. Tabi ki bu yöntemi uygulama sırasından tek user controls kullanılacak diye bir olay aynı şekilde subsitution kontrolunu kullanarak ta yapabiliriz.

Bu özetlerden sonra konumuza başlayalım. Önceki bölümlerde Directive bölümüne cachleme işlemi yapmak için hangi directive leri yazdığımızı görmüştük şimdi bunlardan yola çıkarak çok basit ve anlaşılır örnekler ile konumuzu inceleyelim.(Unutmadan eğer user controls hakkında bilginiz yoksa bu makaleyi okumada önce ilk başta user controls konusunu incelemenizi şiddetle tavsiye ederim.)

1.) İlk başta Toplama isimli bir user control ü projenize ekleyiniz ,tasarimi yapınız

2.) Bu tasarımı yaptıktan sonra Kullanıcı Kontrolümüzde Source (kaynak) kısmına gelip şu direktivi ekleyelim sayfamızın üst kısmına
<%@ OutputCache Duration=”5″ VaryByParam=”None” %>

2.) Yukarıda dikkatinizi çeken kısımlardan biri duration yani cache mizin kullanılma süresinini 5 saniye yaptık.
3.) Şimdi bu oluşturduğumuz Kullanıcı Kontrolunün Toplama isimli tuşun olay yordamına şunu yazın ;

protected void btnToplama_Click(object sender, EventArgs e)
{
       lblSonuc.Text = (Convert.ToInt16(txtSayi1.Text) + Convert.ToInt16(txtSayi2.Text)).ToString();
}

Evet bunları yaptıktan sonra artık iki sayıyı toplayan ve sonucunu bize veren bir kullanıcı kontolümüz olmuş oldu. Şimdi ise yapmamı gereken olay bunu Default.aspx sayfamıza eklemek. Ekledikten sonra cachlemeyi daha iyi farkedebilmek amacıyla Default.aspx sayfamıza bır tane label ekleyin ve Page_Load olayına şu kodları yazın :

protected void Page_Load(object sender, EventArgs e)
{
     Label1.Text = DateTime.Now.ToLongTimeString();
}

Evet artık sistemimiz çalışmaya hazırdır ve şimdi derleyiniz. Evet açılan sayfamızda bulunan Kullanıcı Kontrolümüzde sayıları girip Toplama tuşuna basınız. Neler gördünüz ? Tabiki herhangi bişey değişmedi ama Default.aspx sayfasına eklediğiniz Label baktığımzda ise her sayfayı yenilemede değiştiğini göreceksiniz ve 5 saniye sonra ise Kullanıcı Kontrolümüz değişir. Burada önemli noktalardan biri ise Cache in kullanımı sırasında Kullanıcı Kontrolu için yazılan Code-Behind (Toplama.ascx.cs) deki kodun derlenmeyeceğidir. İşte sizde Fragment önbelleklemenin ne kadar kolay olduğunu gördünüz.

Peki ben Default.aspx sayfasına koyduğum Label1 kontrolunun içeriğinin Herhangi bir kontrole göre değişmesini isteseydim yani, Default.aspx sayfamda yeni bir cache oluşturulmasını tetikleyici etkenin benim belirlediğim kontrolümün olmasını isteseydim bunu nasıl yapardım ? Bunun için tek yapmanız gereken olay şu :

Default.aspx sayfasına bır tane örnek olması amacıyla DropDownList ekleyiniz. Ve EnableAutoPostBack özelliğini true yaptıktan sonra 3-4 tane içine item ekleyiniz yada direk aşağıda bulunan kodu Default.aspx sayfanızın Source kısmına ekleyiniz :

<asp:DropDownList ID=”DropDownList1″ runat=”server” AutoPostBack=”True”>
<asp:ListItem>Visual C#.NET</asp:ListItem>
<asp:ListItem>ASP.NET</asp:ListItem>
<asp:ListItem>CSharpnedir.com</asp:ListItem>
</asp:DropDownList>

Şimdi bunu ekledikten sonra Default.aspx sayfamızda Directive bölümüne şunu eklemeniz gerekecek :

<%@ OutputCache Duration=”5″ VaryByControl=”DropDownList1″ %>

Evet şimdi burada önemli olan nokta VaryByControl ( Kontrole göre değiştir ) özelliği. Burada amacımız DropDownList1 kontrolünün değişimine göre önbellekleme yapmak. ( Tabiki hala önceden eklediğimiz ve güncel zamanı gösteren Label1 kontrolümüz duruyor olması gerekir.) ve sayfamızı derleyelim. İlk başta sayfamızı yenileyelim bakalım zamanı gösteren label kontrolünde herhangi bir değişim oluyo mu? Dikkat ettiyseniz her 5 dakikada bir değişim olduğunu göreceksiniz ve şimdide eklemiş olduğumuz DropDownList1 kontrolümüzün seçili olan indexini değiştirin. Ne oldu ? Tabiki sayfamız önbellekleme zamanının bitmesini beklemeden yeniden bir önbelleği oluşturuldu ve güncel sayfa önümüze geldi. İşte bu şekilde herhani bir kontrole göre de nasıl önbellekleme yapabileceğimizi görmüş olduk.

Bu arada değinmeden geçmek istemediğim bölümlerden birisi ise Önceki örneğimizde Kullanıcı Kontrolleri ile çalışırken şöyle bir ifadeninde Kullanıcı Kontrollerinde önbellekle yapma sırasında gözükebileceği :

<%@ OutputCache Duration=”5″ Shared=”true” %>

Peki buradaki Shared özelliği ne işimize yarıyor. İlk başta adından da anlaşılacağı gibi paylaşılmış manasına gelen bu özellik : aynı kullanıcı kontrolünü birden fazla yerde kullanabilirsiniz ve her farklı sayfa için asp.net bu kullanıcı kontrolünün farklı bir önbelleklenmiş kontrolünü oluşturur. Ama eğer biz böyle bir gereksinime ihtiyaç duymuyorsak ve her sayfa için aynı önbelleklenmiş kullanıcı kontrolünü kullanmak istiyorsak o zaman Share özelliğini true yapmamız sorunumuzu giderecektir.

A.K.G. Teşekkürler.

Sıradaki konular:

 -get,set**
 -Generic Handlers
 -Custom HTTP handler
 -Configuring Projects
-Propery.Pages
-Menü–> Website–>ASP.NET Configuring
-ASP.NET Providers
Services–> Membership,Sitemaps,Profile
 Authentication:Windows Integrated Auth.,Forms Auth.
 Identy:Impersonation,Authorization
 -Configuring Application Pools
 -Servislerde  ASP.NET State Services  session state

ASP.NET 3.5 Summary 3 – WCF etc.

28 Haz

WCF aslında dağıtık mimarinin .Net Framework 3.0 ile gelen yeni hali olarak düşünülebilir. Microsoft, bu güne kadar dağıtık mimari uygulamalarının (Distributed Applications) geliştirilebilmesi için COM+, .Net Remoting, XML Web Servisleri, MSMQ gibi sistemleri geliştirmiştir. WCF, temel olarak bu sistemlerin tamamının yeteneklerini bünyesinde barındıran ve tam SOA (Service Oriented Architecture – Servis Yönelimli Mimari) desteği sağlayan güçlü bir Framework API’ si olarak tanımlanabilir. Aslında ilk zamanlarda fonksiyonel programlamadan nesne tabanlı programlamaya (Object Oriented Architecture) geçilmiştir. Sonrasında bu modeli nesnelerin bileşen haline getirilebilmesi sayesinden, bileşen yönelimli mimari (Component Oriented Architecture) izlemiştir. Son olarak da , servis yönelimli mimariyi (SOA) kullanılmaya başlanmıştır. İşte WCF, SOA mimarisine tam ve yüksek seviyede destek veren bir API olarak karşımıza çıkmaktadır.

Temel olarak WCF, servis yönelimli mimariyi doğrudan desteklemekte ve iki önemli özellik içermektedir. Bunlardan birisi, özellikle Microsoft kanadındaki servislerin, farklı platformlar tarafından ele alınabilmesidir(Interoperability). Böylece, karmaşık .Net tiplerini özel olarak Java, Com gibi modelleri destekleyen çeşitli tipteki platformlara yayabiliriz. Dolayısıyla Linux, Unix vb sistemler servislerimizin birer potansiyel tüketicisi olabilirler. İkinci önemli özellik ise, windows tarafındaki çeşitli dağıtık mimari modeller arasındaki entegrasyonun tek bir çatı altında toplanabilmesinin sağlanmış olmasıdır(Integration). Bu iki özelliğin yanı sıra WCF, CLR (Comman Language Runtime) tiplerini birer servis olarak sunabilmemizi ve hatta servisleride birer CLR tipiymiş gibi ele alabilmemizi sağlayan bir mimari sağlamaktadır.

Dikkat ederseniz servise,

  • Aynı makine içerisinde aynı süreçte (process) yer alan farklı bir uygulama alanı (application domain) üzerinden,
  • Aynı makinede yer alan farklı bir süreç (process) içerisindeki farklı bir uygulama alanı (application domain) üzerinden,
  • Farklı bir makinedeki bir süreç (process) içerisinde yer alan farklı bir uygulama alanı (application domain) üzerinden,

erişebiliriz. İstemciler hangi uygulama alanı (Application Domain) içerisinde olurlarsa olsunlar, servis ile olan iletişimlerini bir proxy nesnesi üzerinden sağlamak zorundadır. Bununla birlikte proxy nesneleri üzerinden giden mesajlar servis tarafında bir endPoint üzerinden geçerler. Benzer şekilde servis tarafından istemcilere giden mesajlarda bu endPoint üzerinden çıkarlar. Bu resim aslında bildiğimiz dağıtık mimari modelin WCF tarafından bir görünüşüdür.

İngilizce bazı kaynaklarda, WCF’ ının ABC’ sinden bahsedilmektedir. Burada ABC aslında Addresses (Adresler), Bindings (Bağlayıcılar) ve Contracts (Sözleşmeler) kelimelerinin baş harfleridir. Bu üçleme, WCF’ ının çekirdeğinde yer alan en önemli kavramlardır. Öyleki, dağıtık modele göre servis olarak dış ortama sunulan her bir CLR tipi için bir endPoint tanımlanır. Tanımlanmak zorundadır. Aslında endPoint bir servisin dış ortama sunulan arayüzü (Interface) olarak düşünülebilir. Yani istemcilerin, proxy üzerinden gönderecekleri ve alacakları mesajların servis tarafında karşılandığı nokta olarak düşünülebilir. Bir endPoint içerisinde üç önemli parça vardır.

Servis Adresleri (Service Addresses)

WCF’ a göre, hizmette bulunan her servis benzersiz bir adrese sahip olmalıdır. Genellikle bir servis adresi, servisin yeri (service location) ve taşıma protokolü (transport protocol) bilgilerinden oluşur. Aslında servis yerinden kasıt,

  • Bilgisayarın adı,
  • Site adı,
  • Network adı,
  • İletişim portu adı,
  • Pipe adı,
  • Queue adı,
  • Belirli bir path bilgisi,
  • URI adı

olabilir. Taşıma protokollerimiz ise,

  • HTTP,
  • TCP,
  • P2P (Peer To Peer),
  • IPC (Inter-Process Communication),
  • MSMQ (Microsoft Message Queuing),

olabilir. Bu bilgiler ışığında örnek servis adresi şablonu aşağıdaki gibi olacaktır.

[taşıma protokolü(transport protocol)]://[makine veya domain adı]:[opsiyonel port numarası]/[opsiyonel URI bilgisi]

Aşağıda bu desene uygun bir kaç örnek servis adı yer almaktadır. Buradaki desenler özellike .Net Remoting ve Xml Web Servisleri üzerinde geliştirme yapanlarada tanıdık gelecektir.

net.tcp://localhost:4578/MatSrv
net.msmq://localhost:6789/MatSrv
http://localhost:9001/MatSrv

Sözleşmeler (Contracts)

Temel olarak bir servisin ne iş yaptığının bilinmesi önemlidir. Bu özellikle, istemcilerin ihtiyaç duyduğu proxy sınıflarının yazılmasında önem arz eden bir konudur. Bu nedenle WCF’ da tüm servisler dış ortama bir sözleşme (Contract) sunmaktadırlar. Genel olarak dört sözleşme tipi vardır.

  • Servis Sözleşmesi (Service Contract): Servis üzerinden hangi operasyonları gerçekleştirebileceğimizi tanımlayan sözleşme çeşididir.
  • Veri Sözleşmesi (Data Contract) : Servislerden istemcilere giden ve istemcilerden servise gelen veri tiplerini tanımlayan sözleşme çeşididir. Int gibi bilinen tipler için bu sözleşmeler bilinçsiz(implicit) olarak hazırlanır. Ancak karmaşık tiplerde ve özellikle kendi tiplerimizde açık (explicit) bir şekilde tanımlanmaları gerekir. İşte bu sayede, Java gibi platformlar ile konuşabiliriz. Nitekim onların anlayacağı şekilde bir veri sözleşmesini dış ortama sunma şansımız artık vardır.
  • Hata Sözleşmesi (Fault Contract): Servis tarafından hangi hataların fırlatılabileceğini ve bunların istemciye nasıl aktarılacağını tanımlayan sözleşme çeşididir.
  • Mesaj Sözleşmesi (Message Contract): Servislerin mesajlar ile etkileşimde bulunmasını sağlayan sözleşme çeşidir.

Genellikle servisler bir sözleşme tanımlamak için ServiceContract ve OperationContract niteliklerini kullanırlar. Daha sonra geliştireceğimiz ilk örnekte bu niteliklere tekrardan değineceğiz. Temel olarak bir tipin servis olarak sunulabileceğini belirtmek için ServiceContract niteliği kullanılır. Servis içerisinde sunulabilecek metodlar ise OperationContract adı verilen nitelikler ile işaretlenirler. Bu aslında WCF’ ının başka bir özelliğidir. Nitelik tabanlı (Attribute Based) programlama.

  WCF uygulamalarını geliştirebilmek için gereken temel tipler, Framework 3.0 ile gelen System.ServiceModel.dll, System.IdentityModel.dll, System.Runtime.Serialization.dll vb… Assembly’ lar içerisinde yer alırlar. Bu nedenle bu Assembly’ ları gerektiğinde kullanabilmek için projelere açıkça referans etmemiz gerekmektedir.

Bağlayıcılar (Bindings)

Bağlayıcılar temel olarak servisler ile nasıl iletişim kurulacağını tanımlamak üzere kullanılırlar. Aslında bir bağlayıcı tip (Binding Type) taşıma tipi (transport type), protokol(protocol) ve veri çözümlemesi(data encoding) bildirir. Bunlar aslında servis yönelimli mimari modelde kullanılabilen senaryolar göz önüne alınarak oluşurlar. Bu sebepten dolayıda WCF, bu önceden bilinen senaryoları kullanabilmek için gerekli bağlayıcı tipleri önceden bildirmiştir. Bu tipler aşağıdaki tabloda yer aldığı gibidir.

Binding Tipi Konfigurasyon
Elementi
Taşıma Çeşidi
(Transport Type)
Veri Çözümlemesi
(Data Encoding)
Platform
Desteği
(Inter
operability)
BasicHttpBinding <basicHttpBinding> HTTP / HTTPS Text Var
NetTcpBinding <netTcpBinding> TCP Binary Yok
NetPeerTcpBinding <netPeerTcpBinding> P2P Binary Yok
NetNamedPipeBinding <netNamedPipeBinding> IPC Binary Yok
WSHttpBinding <wsHttpBinding> HTTP/HTTPS Text/MTOM Var
WSFederationBinding <wsFederationHttpBinding> HTTP/HTTPS Text/MTOM Var
NetMsmqBinding <netMsmqBinding> MSMQ Binary Yok
MsmqIntegrationBinding <msmqIntegrationBinding> MSMQ Binary Var
WSDualHttpBinding <wsDualHttpBinding> HTTP Text/MTOM Var

Buradaki tiplerden hangisini seçeceğimiz, geliştireceğimiz SOA (Service Oriented Architecture) modelindeki ihtiyaçlarımız doğrultusunda belirlenebilirler. Dikkat ederseniz her bağlayıcı tipin interoperability desteği bulunmamaktadır. Bazılar daha yüksek performans sağlayacak şekilde Binary veri çözümlemesini ele alır. Ama kimiside IIS gibi ortamlar üzerinden internete açılabilecek protokol desteğini sunar. İşte bu tip kriterlere göre uygun olan bağlayıcı tipler seçilebilir. Elbette istersek buradaki tipler dışından kendi bağlayıcılarımızı da yazma şansına sahibiz. Ancak bahsi geçen tipler hemen hemen her dağıtık uygulama senaryosu göz önüne alınarak tasarlanmıştır.Böylece WCF’ ın ABC’ sine çok kısada olsa değinmiş olduk.

Gelelim WCF servislerini nerelerde barındırabileceğimize. Sonuç itibariyle yazılan servileslerin mutlaka bir windows süreci (Windows Process) üzerinden sunulması gerekmektedir. Artık temel olarak iki farklı barındırma (Hosting) seçeneğimiz vardır. IIS Hosting ve Self Hosting. IIS Hosting sisteminde, geliştirilen servislerin IIS üzerinde barındırılması amaçlanır. Doğal olarak servisler, web üzerinden hizmet verilebilmektedir. Self Hosting modeli ise kendi içerisinde dörde ayrılmaktadır. Windows Aktivasyon Servisi (Windows Activation Service), Windows Servisi, Konsol uygulaması, Windows Uygulaması.

Windows Aktivasyon Servisi (Windows Activation Service), Vista ile birlikte gelen bir uygulama çeşididir. Özetle Http desteği olmayan host uygulamalar için IIS benzeri bir işlevselliği sağlamakla yükümlüdür. Diğerleri ise özellike .Net Remoting’ den aşina olduğumuz host uygulama tipleridir. Elbette servislerin hizmet verebilmesi için host edilmeleri şarttır. Bu da servisi sunan uygulamanın sürekli çalışır olmasını gerektirir. Nitekim uygulama çalışmadığı takdirde istemcilere hizmet veremez. Buraya kadar anlatıklarımızdan yola çıkacak olursak, WCF cephesinden bir servis yönelimli sistem için şu adımları takip etmemiz yeterli olacaktır.

  • Servise ait sözleşmeyi barındıran ve asıl fonksiyonelleri içeren bir assembly geliştirilir.
  • Servisi istemcilere sunacak olan bir host uygulama geliştirilir.
  • İstemcilerin söz konusu servisi kullanabilmeleri için gerekli olan proxy sınıfı üretilir.
  • İstemci uygulama geliştirilir.

Bu adımlar sırasında özellikle servis tarafında ve istemci tarafında gereken bir takım ayarlamalar için konfigurasyon dosyalarından faydalanabilir yada programatik olarak gerekli hazırlıkların yapılmasını sağlayabiliriz.

Dilerseniz basit bir örnek üzerinden hareket ederek örnek bir WCF sistemi geliştirmeye çalışalım. İlk olarak bir Class Library projesi geliştireceğiz. Projemiz içerisinde servis sözleşmesi rolünü üstlenecek bir arayüz(interface) tipi ve bu arayüz tipini uygulayan bir sınıfımız olacak. WCF’ da, servis sözleşmlerinin tanımlanması için ServiceContract ve OperationContract niteliklerinin kullanılmasını gerekir. Daha önceden de belirttiğimiz gibi bu nitelikler(attributes) System.ServiceModel isim alanı (namespace) altında yer almaktadır. Bu nedenle ilk olarak projemize bu referansı  eklememiz gerekir.

  WCF uygulamalarını Visual Studio 2005 üzerinde daha kolay geliştirmek için gerekli extension’ ları yüklememiz gerekir. Bu extension’ lar yüklendiği takdirde, proje şablonları arasına WCF Service Library seçeneğide gelecektir. Bu proje şablonu, servis sözleşmesinide uygulayan ve ön bilgiler veren hazır bir örnek kütüphane üretmektedir.

Şimdi sınıf kütüphanemizin içerisine  tipleri ekleyelim.

using System;
using System.ServiceModel;namespace MatematikServisLib
{
    [ServiceContract]
    public interface IMatematikServis
    {
        [OperationContract]
        double Toplam(double x, double y);        void DahiliMetod();
    }    public class Matematik : IMatematikServis
    {
        #region IMatematikServis Members        public double Toplam(double x, double y)
        {
            return x + y;
        }        public void DahiliMetod()
        {
        }        #endregion
    }
}

Burada test amacıyla DahiliMetod isimli metod için OperationContract niteliği kullanılmamıştır. Bu sebepten dolayı bu metodun bilgisi servis sözleşmesine dahil edilmeyecektir. Bir başka deyişle istemciler bu metodu hiç bir şekilde kullanamayacaktır.

Şimdi sırada host uygulamasının geliştirilmesi var. Şu an için WCF’ a merhaba demek istediğimizden, host uygulamasınıda basit bir konsol projesi olarak geliştireceğiz. .Net Remoting mimarisinden de hatırlanacağı gibi, genellikle sunucu ve istemci tarafındaki ayarları konfigurasyon bazlı dosyalarda tutmayı tercih ederiz. Bu bize, uygulamayı yeniden derlemeden kanal(channel), port numarası, uzak nesne bilgisi gibi ayarların değiştirilebilmesi ve kullanılabilmesi imkanını sunmaktadır. Aynı felsefeyi WCF uygulamalarında da benimsemekte fayda vardır. Bu nedenle, host uygulamamız için gerekli bazı bilgileri (endPoint gibi) App.config dosyasında tutmayı tercih edeceğiz. Tahmin edeceğiniz gibi konfigurasyon dosyası içerisine WCF’ nın ABC’ sini koymalıyız. Yani adres (address), bağlayıcı (binding) ve sözleşme (contract) bilgilerini dahil ederek gerekli endPoint tipini tanımlamalıyız. Bu amaçla konsol uygulamamızın konfigurasyon dosyasını aşağıdaki gibi geliştirelim.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
    <appSettings>
        <add key=”adres” value=”http://localhost:4590/MatSrv”/&gt;
    </appSettings>
    <system.serviceModel>
        <services>
            <service name=”MatematikServisLib.Matematik”>
                <endpoint address=”http://localhost:4590/MatSrv&#8221; binding=”basicHttpBinding” contract=”MatematikServisLib.IMatematikServis”/>
            </service>
        </services>
    </system.serviceModel>
</configuration>

Dilerseniz konfigurasyon dosyasına yazdıklarımızı inceleyelim. Servisimize ait bir endPoint tanımlamamız gerekmektedir. EndPoint servisin sunulduğu adres bilgisini, bağlayıcı tipini ve servis sözleşmesini ilgili niteliklerden almaktadır. endPoint elementleri, service elementleri içerisinde tanımlanır. Bir service elementi içerisine birden fazla endPoint bilgiside konulabilir. Diğer tarafan service elementleride services elementi tarafından sarmalanmıştır. Dolayısıyla birden fazla service elementininde tanımlanabileceğini söyleyebiliriz.

Peki istemcilere sunmak istediğimiz tipi host uygulama içerisinde servise nasıl sunacağız? Bu amaçla, System.ServiceModel isim alanı altında yer alan ServiceHost sınıfını kullanmamız gerekmektedir. Bu sınıfın temel görevi, parametre olarak aldığı tipi, yine parametre olarak aldığı adres üzerinden istemcilere sunmaktır. Dolayısıyla konsol uygulamamız içerisindeki Main metodunda aşağıdaki kodları yazmamız servisi sunmak için yeterli olacaktır. Tekrardan hatırlatalım; Host uygulamanın konfigurasyon dosyasındaki adres değerine erişebilmesi için System.Configuration.dll, ServiceHost tipini kullanabilmesi için System.ServiceModel.dll, Matematik tipini kullanabilmesi içinde MatematikServisLib.dll assembly’ larına referansta bulunması gerekir.

Gelelim host uygulama kodlarımıza;

using System;
using System.ServiceModel;
using System.Configuration;
using MatematikServisLib;namespace HostApp
{
    class Program
    {
        static void Main(string[] args)
        {
            // Servisin sunulacağı base address bilgisi konfigurasyon dosyasından alınır.
            Uri adres=new Uri(ConfigurationManager.AppSettings[“adres”]);
            // Matematik tipi, Uri üzerinden host edilmek üzere ServiceHost nesne örneğine bildirilir.
            ServiceHost srv = new ServiceHost(typeof(Matematik), adres);
            // Servis açılırken çalışan event metodu
            srv.Opening += delegate(object sender, EventArgs e)
            {
                Console.WriteLine(“Servis açılıyor…”);
            };
            // Servis açıldıktan sonraki event metodu
            srv.Opened += delegate(object sender, EventArgs e)
            {
                Console.WriteLine(“Servis açıldı…”);
            };
            // Servis kapanırkenki event metodu
            srv.Closing += delegate(object sender, EventArgs e)
            {
                Console.WriteLine(“Servis kapanıyor…”);
            };
            // Servis kapandığındaki event metodu
            srv.Closed += delegate(object sender, EventArgs e)
            {
                Console.WriteLine(“Servis kapandı…”);
            };
            // Servis açılır
            srv.Open();
            Console.ReadLine();
            // Servis kapatılır
            srv.Close();
        }
    }
}

Uygulamamızı çalıştırdığımızda servisimiz şu an için başarılı bir şekilde çalışmaktadır.

Gelelim istemci tarafına. Yazımızın başında da belirttiğimiz gibi, istemcilerin WCF Servislerini kullanabilmeleri için proxy sınıflarına ve gerekli istemci taraflı konfigurasyon ayarlarına ihtiyaçları vardır. Çok doğal olarak bu sınıfların üretilebilmesi için, servise ait bir metadata bilgisinin olması ve dış ortama sunulması gerekmektedir. Şimdi şunu deneyelim. Servisimizi host eden uygulamayı çalıştıralım ve herhangibir tarayıcı penceresinden, http://localhost:4590/MatSrv adresini girelim. (Tarayıcı penceresinden bu adresi girerken host uygulamanın açık olması şarttır.)

Dikkat ederseniz, servis için metadata yayınlama hizmetinin şu an için geçersiz olduğu ibaresi vardır. İlgili servisin metadata’ sına ulaşamadığımızdan, istemciler için gerekli proxy sınıfını üretemeyiz. Çözüm, konfigurasyon dosyasına behavior tipi eklemektir. Bu tipi Metadata Exchange (MEX) davranışını uygulayacak şekilde aktif etmemiz gerekir. Bunun için app.config dosyamızı aşağıdaki hale getirmemiz yeterlidir.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
    <appSettings>
        <add key=”adres” value=”http://localhost:4590/MatSrv”/&gt;
    </appSettings>
    <system.serviceModel>
        <services>
            <service name=”MatematikServisLib.Matematik” behaviorConfiguration=”MatematikBehavior”>
                <endpoint address=”http://localhost:4590/MatSrv&#8221; binding=”basicHttpBinding” contract=”MatematikServisLib.IMatematikServis”/>
            </service>
        </services>
        <behaviors>
            <serviceBehaviors>
                <behavior name=”MatematikBehavior”>
                    <serviceMetadata httpGetEnabled=”true”/>
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>
</configuration>

Şimdi host uygulamamızı tekrar çalıştırır ve tarayıcı penceresinden servisimizi tekrar talep edersek sonuç alırız.

Dolayısıyla artık servisimize ait metadata dış ortama sunulabilir ve http üzerinden elde edilebilir haldedir. Bir başka deyişle proxy sınıfını oluşturabilir ve istemcilerin hizmetine sunabiliriz. Burada, ?wsdl takısının olduğuna da dikkat edelim. Bu bize Xml Web Servislerinden son derece tanıdık gelecektir. Bildiğiniz gibi WSDL (Web Service Description Language) bir servisin ne yaptığını Xml olarak söyleyebilen çıktıların üretilmesinde rol almaktadır. Bu yapı WCF içerisindede aynen kullanılabilmektedir.

Artık istemci tarafını kodlayabiliriz. Ama öncesinde proxy sınıfımızı nasıl üretebileceğimize bakalım. Bunun için iki yolumuz vardır. Birincisi .Net Framework 3.0 SDK ile gelen komut satırı araçlarından olan svcutil.exe dir. Diğeri ise, Visual Studio 2005 içerisinde yer alan Add Service Reference seçeneğidir. Biz bu makalemizde svcutil aracı ile proxy sınıfımızı nasıl yazacağımızı inceleyeceğiz. Bunun için Visual Studio 2005 Command Prompt’ ta aşağıdaki komut satırı ifadesini çalıştıralım. (svcUtil aracının başarılı bir şekilde proxy sınıfını ve config dosyasını üretmesi için, host uygulamanın çalışır olduğundan emin olun.)

svcutil http://localhost:4590/MatSrv?wsdl /out:Proxyim.cs /config:app.config

Gördüğünüz gibi Proxyim.cs ve app.config isimli iki dosya üretildi. Artık tek yapmamız gereken bunları istemci uygulamada kullanmaktır. Üretilen proxyim.cs dosyası içerisinde aşağıdaki şekilde görülen tipler yer almaktadır. Dikkat ederseniz servis sözleşmesine göre uygun bir sınıf üretimi gerçekleştirilmiştir. Ayrıca istemci için gereken konfigurasyon ayarlarıda otomatik olarak app.config dosyası içerisine dahil edilmiştir.

İstemci tarafında kullanacağımız tip MatematikServisClient isimli sınıftır. İstemci uygulamamızı aşağıdaki kodları yazarak test edebiliriz.

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;namespace Istemci
{
    class Program
    {
        static void Main(string[] args)
        {
            MatematikServisClient mat = new MatematikServisClient();
            Console.WriteLine(mat.Toplam(4, 5).ToString());
            Console.ReadLine();
        }
    }
}

Elbetteki istemci uygulamanın çalışabilmesi için öncesinde host uygulamanın çalışıyor olması gerekmektedir. Aksi takdirde EndPointNotFoundException tipinden bir istisna alırız. Bu aynı zamanda gerçketende istemcinin bir sunucuya bağlanmaya çalıştığınında bir ispatıdır. Eğer önce sunucuyu sonrada istemciyi çalıştırırsak uygulamanın başarılı bir şekilde yürüdüğünü ve Toplam metodunun sonucunun elde edildiğini rahatlıkla görebiliriz.

B.S.Şenyurt,Teşekkürler

Sıradaki Konular:

Page output caching  *
%@OutputCache Duration=”900″ varyByParam=”None”%
 -get,set**
 -Generic Handlers
 -Custom HTTP handler
 -Configuring Projects
-Propery.Pages
-Menü–> Website–>ASP.NET Configuring
-ASP.NET Providers
Services–> Membership,Sitemaps,Profile
 Authentication:Windows Integrated Auth.,Forms Auth.
 Identy:Impersonation,Authorization
 -Configuring Application Pools
 -Servislerde  ASP.NET State Services  session state

.NET 4.0 Neler Getirdi!

23 Haz

Son zamanlarda C# 4.0 ile birlike gelen yeniliklerden haberdarız. Geçmişteki yeniliklerden belkide en önemli olanı, CLR(Common Language Runtime) çekirdiğinde değiştirilme yapılmasını da zorunlu kılan generic mimariydi. Tabiki generic dışında gelen, yield anahtar kelimesi, isimsiz metodlar(anonymous methods), static sınıflar ve diğerleride önemli gelişmelerdi. Zaman ilerledi ve C# 3.0 ile birlikte bu kez hayatımıza, generic modelinden daha fazla etki yapan LINQ(Language INtegrated Query) girdi. Bir geliştirici olarak her zaman için yeniliklere açık olmamız ve yakalayabildiğimiz ölçüde takip etmemiz gerektiğini düşünüyorum. Bu bir geliştirici için neredeyse bir yaşam tarzı. Dolayısıyla artık C# 4.0 üzerinde konuşmanın zamanı geldide geçiyor.

C# 4.0 ile birlikte gelen yeniliklerin daha çok dinamik çalışma zamanını(Dynamic Language Runtime-DLR) kullanan diller üzerinde odaklanmış durumda olduğunu söyleyebiliriz. Peki bu ne anlama geliyor? DLR tarafını ilgilendiren dillere ait nesneler ile daha kolay konuşulması olarak küçük bir sebep belirtebiliriz. Bu nedenle C# 4.0 ile birlikte gelen önemli yeniliklerden birisi olan dynamic anahtar kelimesi sayesinde, Python, Ruby veya Javascript ile üretilen nesnelerin C# 4.0 tarafında late-binding ile ele alınması mümkün. Hatta var olan .Net nesnelerinin reflection kullanılmadan ele alınması veya COM objelerine ait üyelerin çağırılmasında bu anahtar kelimeyi kullanabiliyoruz. Aslında C#’ ın 2.0, 3.0 versiyonunda gelen yenilikler nasıl ki belirli ihtiyaçlar nedeni ile ortaya çıkmışsa, C# 4.0 ile gelen yenilikleride bu anlamda düşünmemiz ve araştırmamız gerekiyor.
B.S.Ş.

Garbage Collection değişiklikleri

CLR 4.0 ile beraber Garbage Collection tarafında iyileştirmeler yapılmış. Performans konusunda yapılan bu iyileştirmeler ile GC’nin çalışma algoritmalarında büyük değişiklikler var. .NET Framework tarafında yaratılan objeler belli koleksiyonlarda tutuluyor. Objeler yaşam sürelerine göre bu koleksiyonlar da konumlanıyor. GC’da bu koleksiyonlardaki objeleri yaşam sürelerine göre topluyor,yok ediyor…CLR 4.0’da bu işler artık daha hızlı.

İç içe çalışan CLR

CLR 4.0’ın bence en güzel yeniliklerinden biri de, içerisinde başka CLR versiyonlarının da çalışabilmesi. Ne demek oluyor bu açalım biraz daha…. .NET Framework ile çalışan ana uygulama tek bir CLR versiyonu yükleyebiliyordu. Bu da uygulamalarda destek sorununa neden olabiliyordu. Mesela CLR 1.0 versiyonu ile çalışan bir uygulamaya, CLR 2.0 versiyonu ile bir şey yazamıyorduk. CLR 4.0 ile artık bu sorun ortadan kalkıyor.

Yakalanamayan hatalar
Önceki CLR versiyonlarında bazı unmanaged işlemlerden doğan hataları yakalamak normal try-catch blokları ile mümkün değildi. InvalidMemory,AccessViolation falan filan gibi. CLR 4.0 ile artık bu tarz hataları yakalamak daha kolay. Bunun için [HandleProcessCorruptedStateExceptions] özelliğini programımızın başlangıcına eklememiz yeterli.

Profiling yenilikleri

Uygulamaları profile etmek için önceki CLR versiyonlarında üretim ortamına Visual Studio kurmamız gerekmekteydi. Artık buna gerek yok…

Dump Debuging

Belli arayüzler ile artık uygulamalarımızda dump debuging yapabileceğiniz. Hata olduğunda “Gönderim mi,göndermiyim mi” sorusu ile başbaşa kaldığımız ekran .NET 4.0 ile kendi uygulamalarımız adına biraz daha anlam kazanacak.

Çok çekirdekli .NET

Ay çekirdeği tadındaki bu en güzel yenilik, artık çok çekirdekli işlemcilerde, bu çekirdeklerden faydalanmamızı sağlayacak Parallel Extensions olarak karşımıza çıkıyor. CLR thread’leri artık bu çekirdekler arasında dağıtılabilinecek.

Kod kontratları

AOP kavramı, Code Contracts kavramı ile CLR 4.0’da .NET 4.0’ın daha bir içine giriyor. Artık .NET 4.0’da methodlarımıza belli condition’ları belirterek, runtime sırasında nasıl çalışacağını belirtebiliyoruz. Bu aynı zamanda kodlarımızın compile sırasında farklı şekilde derlenebilmesini ve farklı ortamlarda çalışabilmesini sağlıyor olacak. Bir uygulamanın Windows, XBOX ve Windows Phone üzerinde değişmeden çalışmasının temelinde bu olay yatıyor işte…

A.Ç.