Arşiv | C# RSS feed for this section

Yazılım Geliştirme Süreci ve Güvenli Yazılım Geliştirme

14 Ara

Yazılımların hayatımızdaki yeri ve öneminin gün geçtikçe artması yazılımlara ilişkin çalışmaları hızlandırmakta, bu durum yeni yazılım geliştirme yöntemleri, programlama kuralları veya programlama dilleri ve araçları ortaya çıkarmaktadır. Tüm bu gelişmelere rağmen yazılım projelerinde tasarlanan zamanın gerisinde kalma, bütçeyi aşma, düşük kalite, sürekliliği ve güvenilirliği sağlayamama, kullanıcı taleplerinin karşılanmasında yetersizlik gibi problemlerle sıkça karşılaşılmaktadır. Gartner araştırmasına göre bilişim güvenliği ihlallerinin yazılım güvenliği problemlerinden kaynaklananlarının oranı %80’dir [1]. Genel olarak problemlerin çoğu, yazılım geliştirme sürecinin en başında gereksinim ve sistem analizlerinin doğru ve yeterli yapılmamasından kaynaklanmaktadır. Analiz konusunda yetersiz kalan yazılımlar güvenlik riski oluşturmakta, bu durum bilgiye yönelik tehditlerin ortaya çıkmasında önemli bir açıklık oluşturmaktadır.

Bilginin gizliliği, bütünlüğü ve erişilebilirliğini, kısaca bilgi güvenliğini hedefleyen tehditlerle mücadele için yazılımlarda bilgi güvenliğinin sağlanmış olması gerekmektedir. Bilgi güvenliği;  karşılaşılabilecek tehditlerin farkında olunması,  işlerin devamlılığını sağlama, yaşanabilecek her türlü problemlerde kayıpları en aza indirme, firmaların varlıklarının her koşulda gizliliği, erişebilirliği ve bütünlüğünü korunma amaçları taşımaktadır. Bu kapsamda ortaya çıkartılan ve sürekli geliştirilmekte olan bir süreç de “Bilgi Güvenliği Yönetim Sistemi (BGYS)” dir.

Yazılımlarda bilgilerin korunması yazılımın geliştirme sürecinin başından itibaren tüm aşamaların bilgi güvenliği kontrollerine uygun olarak gerçekleşmesine bağlıdır. Yazılımın geliştirme sürecinde bilgi güvenliği yönetim sisteminin sağlanmış olması, yazılımlardaki bilgilerin kullanıma hazır olduğunu, sadece yetkisi olanların erişebildiğini ve kullanılan bilginin doğru ve güncel olduğu anlamına gelmektedir.

Bu çalışmanın ikinci ve üçüncü bölümünde yazılım, yazılım geliştirme süreçleri ve güvenli yazılım geliştirmeye ilişkin bilgilere yer verilecektir. Dördüncü bölümde uluslararası bir standart olan “ISO/IEC 27001 Bilgi Teknolojileri- Güvenlik Teknikleri-Bilgi Güvenliği Yönetim Sistemi- Gereksinimler Standardı (ISO 27001)” ele alınacak, sonrasında ISO 27001’in yazılım geliştirme süreçleriyle ilişkili kontrol maddelerine ve sonuç bölümüne yer verilecektir.

Yazılım Geliştirme Süreçleri

Yazılım kelimesinin sözlük anlamına bakıldığında; yazılım, “bir bilgisayarda donanıma hayat veren ve bilgi işlemde kullanılan programlar, yordamlar, programlama dilleri ve belgelemelerin tümü” olarak ifade edilmektedir [2] . Yazılım ayrıca, mevcut bir problemi çözmek amacıyla değişik cihazların birbirleriyle haberleşebilmesini sağlayan ve görevlerini ya da kullanılabilirliklerini geliştirmeye yarayan bilgisayar dili kullanılarak oluşturulmuş anlamlı ifadeler bütünü olarak da nitelendirilebilir [3]. Yazılım ile ilgili bu tanımlamalar daha çok kod ile ilgilenirken yazılım geliştirme, bilinenin aksine sadece kodlama değildir. Birkaç tane kullanıcı ekranı tasarlayıp, bu ara yüzlerin arkasına kod yazarak ve veritabanı ilişkisi kurularak yazılım geliştirme süreci tamamlanamaz. Bu işlemler yazılım geliştirme sürecinin sadece bir bölümü olup, toplamda yazılım geliştirme süreci kodlama yapmaktan çok daha fazlasıdır [4]. Bu bakımdan yazılım geliştirme, yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği tüm aşamalar olarak tanımlanabilir.

Geçmişte yazılım geliştirmede başvurulan iş akış şemaları gibi yöntemler günümüzde gereksinimleri karşılayamadıklarından etkinliklerini yitirmişlerdir. Bu yöntemler özellikle güvenlik odaklı olmadıklarından yetersiz kalmışlardır. Yazılımın her aşamasında güvenliğe ilişkin ortaya çıkabilecek problemleri gözeten etkin bir geliştirme süreci sonuç ürünün daha güvenilir olmasına önemli katkı sağlayacaktır.

Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar sürekli bir döngü biçiminde ele alınmaktadır. Böylece döngü içerisinde her hangi bir aşamada geriye dönmek ve tekrar ilerlemek söz konusudur [5]. Yazılım geliştirmede çok sayıda farklı model ve süreç değerlendirmelerinden söz etmek mümkündür. Bununla birlikte; yazılım mühendisliğindeki diğer modellere temel teşkil eden “Çağlayan Modeli (Waterfall Model)” yazılım yaşam döngüsünü analiz, tasarım, kodlama, test ve bakım olmak üzere beş aşamada ele almaktadır [6].

Analiz

Bir problemin çözümü olarak nitelediğimiz yazılımların ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama analiz aşamasıdır. Yazdığınız kod ancak isteneni doğru bir biçimde yerine getiriyorsa başarılı bir yazılımdır. Bu nedenle öncelikle yazılımdan ne istendiğinin doğru bir biçimde tanımlanması gerekir. Analiz aşaması personel, donanım ve sistem gereksinimlerinin belirlenmesi, sistemin fizibilite çalışmasının yapılması, kullanıcıların gereksinimlerinin analizi, sistemin ne yapıp ne yapmayacağının kısıtlamalar göz önüne alınarak belirlenmesi, bu bilginin kullanıcılar tarafından doğrulanması ve proje planı oluşturulması adımlarından oluşur.

Tasarım

Analiz aşaması sonucunda belirlenen gereksinimlere yanıt verecek yazılımın temel yapısının oluşturulduğu aşamadır. Yazılım tasarımı, bir bileşen veya sistemin nasıl gerçekleştirileceğini belirlemek için kullanılan teknikler, stratejiler, gösterimler ve desenlerle ilgilidir. Bu aşama yazılım bileşenleri arasındaki içsel ara yüzler, mimari tasarım, veri tasarımı, kullanıcı ara yüzü tasarımı, tasarım araçları ve tasarımın değerlendirilmesi alt süreçlerini de kapsamaktadır. Tasarım aşaması, yazılımın hem kullanıcı ara yüzünü hem de programın omurgasını ortaya koymaktadır. Yapılacak tasarım, yazılımın işlevsel gereksinimlere uygun olmasının yanı sıra kaynaklar, performans ve güvenlik gibi kavramları da göz önüne alınarak gerçekleştirilmelidir.

Kodlama

Kodlama aşaması, tasarım sürecinde ortaya konan veriler doğrultusunda yazılımın gerçekleştirilmesi aşamasıdır. Bu süreç programlama çalışmalarının yanı sıra yazılımın geliştirilmesi ve kullanıcıya ulaştırılması sürecindeki bütün çalışmaları kapsar. Tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışması olarak da nitelendirilebilir [5]. Yazılım geliştirme ortamı, programlama dili, veri tabanı yönetim sistemi, yazılım geliştirme araçları seçimi kodlama aşamasında gerçekleştirilir.

Test

Test aşaması, yazılım kodlanması sürecinin ardından gerçekleştirilen sınama ve doğrulama aşamasıdır. Elde edilen uygulama yazılımının hem belirlenen gereksinimleri sağlayıp sağlamadığı hem de gerçekleştirimin beklentilere uygun olup olmadığını kontrol etmek için statik ve dinamik sınama tekniklerinden yararlanır. Statik teknikler, yazılımın tüm yaşam döngüsü boyunca elde edilen gösterimlerin analizi ve kontrolüyle ilgilenirken, dinamik teknikler sadece gerçekleştirilmiş sistemi içerir. Yazılım üretiminde ilk testler genelde geliştirme sürecinde programcı tarafından yapılır. Bununla birlikte, asıl hata ayıklama ve geribildirim hizmeti test ekipleri tarafından yapılır. Testler ve geribildirim müşteri yazılımı kullandığı sürece devam eder. Test sürecinde en faydalı geribildirimler son kullanıcı test gruplarından gelir.

Bakım

Yazılımın tesliminden sonra hata giderme ve yeni eklentiler yapma aşamasıdır. Yazılımın kullanıma başlanmasından sonra yazılımın desteklenmesi sürecini kapsar. Yazılımın eksiklerinin giderilmesi, iyileştirilmesi gibi alt aşamaları içeren aşamadır.

Güvenli Yazılım Geliştirme

Yazılımların yaygın olarak kullanılmaya başlandığı ilk yıllarda kaliteli ve olgun yazılım üretmek, son yıllarda ise özellikle güvenli yazılım geliştirmek için çok sayıda model ve çerçeve üzerinde çalışılmıştır. Bu durumun en büyük tetikleyicisi son yıllarda güvenlik açıklıklarının artmasıdır [7]. Artan bu güvenlik tehditleri Şekil 1’de görüldüğü üzere hiç hesaba katılmayan sürpriz maliyetleri de beraberinde getirmektedir. Yazılım geliştirmede erken bir süreçte farkına varılan yazılım açıklıklarının düzeltilmesinin daha ileri süreçlerde farkına varılan açıklıklara göre daha az maliyetli olacağı yazılım endüstrisince yaygın olarak kabul edilen bir ilkedir [8]. Bu ilke yazılım geliştirme sürecinin güvenli olmasının maliyet açısından da ne denli önemli olduğunun göstergesidir.

ekil_1.jpg

Şekil 1 – Yazılım Geliştirme Süreçlerinde Yazılım Açıkları Giderme Maliyeti [8]

Yazılım güvenliği kavramı ile ilgili yapılan en önemli yanlış güvenliği sadece kodun güvenliği ve ek olarak da yetkilendirme güvenliği ile sınırlandırmaktır. Halbuki yazılım güvenliği kavramını “güvenilir bilişim” (trusted computing) kavramı ile yakından ilişkilendirmek gerekmektedir. “Trusted Computing Group” tarafından konmuş olan güvenilir bilişim kavramı gizlilik, bütünlük, erişebilirlik, ve kurtarılabilirlik olmak üzere dört temel kavram üzerinde durmaktadır [9].

Güvenli yazılım geliştirme süreçlerinde ayrıca değişiklik ve konfigürasyon yönetimi, geliştirme, test ve üretim ortamı ayrışımı, geliştirme ortamında gerçek verilerin kullanılmaması, üretim ortamına almadan önce kod incelemesi, güvenli programlama teknikleri kullanımı, uygulama güvenlik duvarı kullanımı ya da kaynak kod inceleme hizmeti alınması gibi çalışmaların yapılması da güvenliğe ayrıca katkı sağlayacaktır [1].

Güvenli yazılım geliştirme sürecinde ele alınması gereken temel olarak dokuz ana güvenlik konusu vardır [10]:

1.Girdi Geçerleme (Input Validation):

Günümüzde bilinen ve gelecekte de muhtemel tehditlerin çoğu kötü niyetli girdi ile başlamaktadır. Bununla birlikte; basit girdi geçerleme yöntemleri ile büyük güvenlik tehditlerinin önlenmesi mümkündür.

Girdi geçerleme yöntemlerini “beyaz kutu” ve “kara kutu” olmak üzere ikiye ayırmak mümkündür. Beyaz kutu yönteminde bilinen bir şablon girdi olarak kullanılmakta, bu şablonun dışındaki tüm girdiler kötü niyetli olarak kabul edilmektedir. Şablonun kontrolü çok kolay olduğundan bu yöntem oldukça etkili bir yöntemdir. Kara kutu yöntemi ise daha az etkili olmasına rağmen daha çok tercih edilen bir yöntemdir. Bu yöntemde kullanılan belirli bir şablon yoktur, sadece bilinen saldırıların bir listesi mevcuttur. Eğer girdi bilinen bir saldırıya benziyor ise o zaman girdi reddedilecek, onun dışındaki tüm girdiler ise kabul edilecektir. Bugün bile tüm atak çeşitlerini belirlemek zor iken gelecekteki atakları bilip filtrelemek daha da zor olacağından bu yöntemin etkinliğinin az olduğu açıktır. Dolayısıyla veri yapıları, mümkün olduğunca belli bir şablona uygun tasarlanarak geçerleme daha güçlü kılınmalıdır.

İstemci-sunucu uygulamalarında geçerleme hem istemci hem de sunucu tarafında yapılabilmektedir. Bununla birlikte; bir saldırgan istemci tarafındaki geçerleme kontrolünü kolay aşabileceğinden istemci tarafındaki geçerleme hiçbir zaman yeterli bir güvenlik önlemi olarak ele alınmamalıdır. Bunun yerine daha çok sunucu tarafında geçerleme kontrolü yapılarak güvenlik seviyesi arttırılmalıdır. Kısaca güvenilir olmayan bir kaynaktan (örneğin kullanıcıdan) gelen veri mutlaka onaylanmalıdır.

2.Kimlik Doğrulama (Authentication):

Kimlik doğrulama,  varlıkların (kullanıcı, cihaz veya bir uygulama) kimlik kontrolünden geçmesi işlemidir ve farklı kimlik doğrulama yöntemleri bulunmaktadır.

Genellikle yazılımlar önceleri sadece kullanıcı adı ve şifre kullanması şeklinde zayıf doğrulama yöntemleri kullanılmakta idi. Eğer bir “domain” yapısı varsa, kullanıcılar “Active Directory” kullanılarak doğrulanmakta, “domain” dışında ise kimlik yönetimine ilişkin veritabanı uygulanmaktadır. Daha güçlü doğrulama yöntemleri olarak da biometrik metotlar veya akıllı kartlar kullanılmaktadır. Bir diğer doğrulama yöntemi ise üçüncü bir tarafın doğrulama işini yapması ve bu üçüncü tarafa güven duyulması şeklindedir.

3.Yetkilendirme (Authorization):

Kullanıcıların tanımlanması aşaması olan kimlik doğrulamadan sonra kullanıcının kimliği doğrultusunda erişim haklarının belirlendiği ve kontrolünün gerçekleştiği aşama yetkilendirmedir. Hangi yetkilerle işlem yapılacağını belirlemek için bir çok yöntem bulunmaktadır.

4.Konfigürasyon Yönetimi  (Configuration Management):

Konfigürasyon, uygulama ile ilgili hassas bilgileri içermektedir. Örnek vermek gerekirse veri tabanına erişim için gerekli bağlantı bilgilerini içeren dosyalar bu kapsamdadır. Konfigürasyona müdahale uygulamanın işleyişini değiştirebilir veya çalışmamasına sebep olabilir. Konfigürasyon dosyalarının sunucularda saklanıyor olması yeterli güvenlik önlemlerinin alındığı anlamına gelmemektedir. Konfigürasyon dosyaları hassas bilgi olarak nitelendirilmeli, şifrelenmiş bir şekilde tutulmalı ve bu dosyalara erişim kayıt altında tutulmalıdır.

5.Hassas Bilgi (Sensitive Information):

Hassas bilginin ne olduğunun belirlenebilmesi için uygulamanın ve işin bir arada ele alınması gerekir. Uygulama geliştirici işin niteliğini tam olarak bilemediğinden, diğer yandan işin sahibi de uygulamanın teknik altyapısı hakkında sınırlı bilgiye sahip olacağından bu iki taraf tek başlarına hassas bilgi için yeterli tanımlama yapamayacaklardır. İki tarafın bir araya gelmesiyle hassas bilgileri içeren bir liste oluşturulmalı ve bu listeyi koruyacak bir politika oluşturulmalıdır.

6.Kriptografi (Cryptograhy):

Veriyi korumanın yollarından biri de şifrelemedir. Bugün şifreleme çalışmaları oldukça ilerlemiş, bilgisayarlar oldukça gelişmiştir. Fakat bu durum saldırganlar için de geçerlidir. Hassas bilgiler bilinen ve test edilmiş şifreleme yöntemleri ile saklanmalıdır. Ayrıca daha önce kırılması uzun zaman alan algoritmalar günümüzde daha kısa zamanda çözülebilmektedir. Dolayısıyla uygulama içindeki algoritmalar zamanla gözden geçirilmeli ve güncellenmelidir.

7.Parametre Manipülasyonu (Parameter Manipulations):

Dağıtık algoritmalar modüller arasında parametre gönderirler. Eğer bu parametreler arada değiştirilirse, saldırı gerçekleştirilmiş olur. 1 dolara satın alınan Ferrari bu duruma bir örnektir. Borcun belirlenmesi için web formu kullanan uygulama bu formdaki rakamın http proxy kullanılarak manipüle edilmesi sonucu değer 1 dolara olarak değiştirilmiştir.

8.Hata Yönetimi (Exception Management):

Bazı teknolojiler hataları kullanarak hata yönetimi gerçekleştirmektedirler. Hatalar geliştiriciler ve sistem yöneticileri için uygulama ile ilgili birçok önemli bilgi ihtiva ettiği için çok önemlidirler. Bununla birlikte; geliştirici için bu derece önemli olan bilgi kullanıcı açısından problem oluşturabilmektedir. Her ne kadar kullanıcılar bu hataların ne demek olduğunu anlamasalar da saldırganlar için büyük ipuçları, yazılımla ilgili önemli bilgiler içermektedir. Bundan dolayı sadece genel bir hata mesajının dönmesi, hataların kayıt altında tutulması ve gerçek hataya sadece yöneticiler ulaşmasını sağlayacak sürecin oluşturulması gerekmektedir.

9.Kayıt Tutma ve Denetim (Logging and Auditing):

Uygulama veya uygulamanın yöneticileri saldırı altında olduklarını anlamalıdır. Bu durum aslında neyin normal neyin anormal olduğunun belirlenmesi ile sağlanır. Bir uygulamaya ilişkin normal süreç ve şablon tanımlanmalı ve bunu dışında bir olay olduğunda saldırı ihtimali ele alınmalıdır. Örneğin, normal senaryoda bir uygulamaya dakikada ortalama beş kişinin erişmesi beklenirken bu sayı bine ulaşıyorsa muhtemelen bir “Servis Dışı” bırakma atağı söz konusudur.

Yukarıdaki ve bunlara benzer onlarca tehdit güvenilir uygulamalar geliştirmek için yazılım geliştirme sürecinin güvenliğinin yönetilmesinin büyük önem arz etmekte olduğunu gözler önüne sermektedir.

ISO 27001 Bilgi Güvenliği Yönetim Sistemi

Bilgi güvenliği, yazılı, sözlü, elektronik ortam gibi farklı ortamlardaki bilginin gizlilik, bütünlük ve erişebilirlik bakımından güvence altına alınması ve bu güvence durumunun sürekliliğinin sağlanmasıdır.

Bilgi sistemlerinin hayata geçmesiyle ortaya çıkan depolama ve işleme imkânlarının artması, izinsiz erişimler, bilginin yetkisiz imhası, yetkisiz değiştirilmesi veya yetkisiz görülmesi ihtimallerinin artması gibi hususlar nedeniyle bilgi güvenliği kavramı gündeme gelmektedir.

Bilgi hangi biçime girerse girsin veya ne tür araçlarla paylaşılır veya depolanır olursa olsun, her zaman uygun bir şekilde korunmalıdır. Bilgi sistemlerinin çoğu, bilgi saklanırken, paylaşılırken, gönderilirken güvenlik kaygıları düşünülerek tasarlanmamıştır. Kurumların sahip oldukları bilgi doğru tasarlanmamış sistemler nedeniyle pek çok çeşitli tehditlere karşı açık durumdadır.

Bilgi güvenliği ihlali ve buradan doğacak kayıpların riskini minimize etmek kurulan sistemlerin en başında BGYS gelmektedir. BGYS, bilgi güvenliğini kurmak, işletmek, izlemek ve geliştirmek için iş riski yaklaşımına dayalı, dokümante edilmiş, işlerliği ve sürekliliği garanti altına alınmış bir yönetim sistemidir.

BGYS kurumunuzdaki tüm bilgi varlıklarının değerlendirilmesi ve bu varlıkların sahip oldukları zayıflıkları ve karşı karşıya oldukları tehditleri göz önüne alan bir risk analizi yapılmasını gerektirir [11].

BGYS, bağımsız kuruluşların ya da tarafların ihtiyaçlarına göre özelleştirilmiş güvenlik kontrollerinin gerçekleştirilmesi için gereksinimleri belirtir. BGYS’nin ihtiyaç duyduğu gereksinimlere cevap vermek için çok sayıda standart vardır. Bunların en önde geleni ISO 27001 standardıdır.

PUKÖ Modeli

ISO 27001 kurumların bilgi güvenliği yönetim sistemi kurmaları için gereklilikleri tanımlayan tek denetlenebilir BGYS standardıdır. ISO 27001 ülkelere göre özel tanımlar içermeyen, genel tanımların bulunduğu uluslararası standardıdır. ISO 27001 standardı; kuruluşların kendi bilgi güvenlik sistemlerini sağlamasını mümkün kılan teknoloji tarafsız, satıcı tarafsız yönetim sistemleri için bir çerçeve sağlar.

ISO 27001, kuruma uygun politikalar, prosedürler ve kılavuzlar oluşturmaya yol gösteren uluslararası kabul görmüş yapısal bir metodoloji sunar. ISO 27001 sertifikası, kurumların güvenlik seviyesine ve kurumun konuya ciddi yaklaşımına ilişkin bir göstergedir.

Bilgi güvenliği yönetimi konusunda ilk standart British Standard Institute (BSI) tarafından geliştirilen BS 7799’dur. BS 7799  “Pratik Kurallar” ve “BGYS Gerekleri” başlıklı iki kısımdan oluşmaktaydı. BS 7799 birinci kısım daha sonra ISO tarafından 2000 yılında “ISO 17799” olarak kabul edilmiştir. 2002’de BSI; BS 7799-2’yi çıkartmıştır. ISO, 2005 yılında ISO/IEC 1799:2005’i ve BS 7799-2’nin yeni hali olan ISO/IEC 27001:2005’i yayınlamıştır. ISO 27001, 2005 yılında yayınlanmasıyla yürürlüğe girmiş ve ISO/IEC 27000 standart serisi altında yerini almıştır. Söz konusu bu standart 2006 yılında Türk Standardı olarak kabul edilerek, ”TS ISO/IEC 27001 Bilgi Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenliği Yönetim Sistemleri – Gereksinimleri” adıyla yayınlanmıştır [12].

ISO 27001 yaşayan, dolayısı ile tehdit ve saldırılara reaksiyon gösteren ve kendini yenileyen bir bilgi güvenliği sisteminde yer alması gereken öğeleri tanımlamaktadır [13]. ISO 27001, BGYS’yi kurmak, işletmek, izlemek, gözden geçirmek, sürdürmek ve iyileştirmek için standart proses yaklaşımını benimsemiştir. Bu proses yaklaşımı güvenlik önlemlerinin belirlenip kurulması, uygulanması, etkinliğinin gözden geçirilmesi ve iyileştirilmesi süreçlerini ve bu süreçlerin sürekli olarak tekrarlanmasını içerir. Bu süreçler Planla, Uygula, Kontrol et, Önlem al (PUKÖ) döngüsünden oluşan bir model olarak da ortaya konmuştur.

BGYS’de kurum kendine bir risk yönetimi metodu seçmeli ve risk işleme için bir plan hazırlamalıdır. Risk işleme için standardda öngörülen kontrol hedefleri ve kontrollerden seçimler yapılmalı ve uygulanmalıdır. Şekil 2’de gösterilen PUKÖ Modeli uyarınca risk yönetimi faaliyetlerini yürütmeli ve varlığın risk seviyesi kabul edilebilir bir seviyeye geriletilene kadar çalışmayı sürdürmelidir [11].

ekil_2.jpg

Şekil 2- BGYS’nin PUKÖ Modeli [13]

PUKÖ Model’inin süreçleri aşağıdaki gibidir:

Planla: BGYS’nin kurulması

Sonuçları kuruluşun genel politikaları ve amaçlarına göre dağıtmak için, risklerin yönetimi ve bilgi güvenliğinin geliştirilmesiyle ilgili BGYS politikası, amaçlar, hedefler, prosesler ve prosedürlerin kurulması.

Uygula: BGYS’nin gerçekleştirilmesi ve işletilmesi

BGYS politikası, kontroller, prosesler ve prosedürlerin gerçekleştirilip işletilmesi.

Kontrol Et: BGYS’nin izlenmesi ve gözden geçirilmesi

BGYS politikası, amaçlar ve kullanım deneyimlerine göre proses performansının değerlendirilmesi ve uygulanabilen yerlerde ölçülmesi ve sonuçların gözden geçirilmek üzere yönetime rapor edilmesi.

Önlem Al: BGYS’nin sürekliliğinin sağlanması ve iyileştirilmesi

BGYS’nin sürekli iyileştirilmesini sağlamak için yönetimin gözden geçirme sonuçlarına dayalı olarak, düzeltici ve önleyici faaliyetlerin gerçekleştirilmesi [12].

ISO 27000 Ailesi

Bilgi güvenliği ile ilgili olarak ISO 27000 serisi güvenlik standartları, (Şekil 3) kullanıcıların bilinçlenmesi, güvenlik risklerinin azaltılması ve de güvenlik açıklarıyla karşılaşıldığında alınacak önlemlerin belirlenmesinde temel bir başvuru kaynağıdır. Bu standartlar temel ISO’nun 9000 kalite ve 14000 çevresel yönetim standartlarıyla da ilgilidir [12].

ISO 27000 standardı, ISO 27000 standartlar ailesi ile ilgili kavramların açıklanmasını sağlayan ve bilgi güvenliği yönetimine yönelik temel bilgileri içeren bir standarttır. ISO 27000 standartlarının büyük bir çoğunluğu bilenen, diğerleri ise basım aşamasında olan standartlar olarak verilebilir.

ISO/IEC 27000 standart serisi altında yer alan ve ISO 27001 için gereken güvenlik kontrollerini içeren standart; ISO/IEC 27002:2005 – Bilişim Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenlik Yönetimi için Uygulama Kılavuzu’dur. Bu standardın önceki adı ISO/IEC 17799:2005’dir. 1 Temmuz 2007 tarihinde, ISO tarafından yapılan teknik bir düzenlemeyle ISO/IEC 17799:2005 standardının adı, ISO/IEC 27002:2005 (ISO 27002) olarak değiştirilmiştir [14].

ekil_3.jpg

Şekil 3- ISO 27000 Standart Ailesi [15]

Güvenlik Kontrol Alanları

ISO 27001’de BGYS oluşturmada güvenlik için gereken 11 kontrol alanı, 39 kontrol hedefi ve 133 kontrolü tanımlayan bir uygulama kılavuzudur. Bu kontrol alanları aşağıda kısaca açıklanmaktadır [16]:

  1. Güvenlik Politikası: Bilgi güvenliği için yönetimin desteğini ve katılımını sağlamak, bilgi güvenliğinin önemini vurgulamak
  2. Bilgi Güvenliği Organizasyonu:  Bilgi güvenliğinin koordinasyonu ve yönetimi için bir yönetim çerçevesi geliştirmek, bilgi güvenliği için sorumlulukları tahsis etmek
  3. Varlık Yönetimi: Tüm kritik veya hassas varlıklar için uygun bir koruma düzeyi belirlemek
  4. İnsan Kaynakları Güvenliği: Kullanıcı eğitimini ve bilincini teşvik ederek hırsızlık, dolandırıcılık veya bilgisayar kaynaklarının kötüye kullanılma riskini azaltmak
  5. Fiziksel ve Çevresel Güvenlik: Kuruluşun tesislerindeki bilgi işlem olanaklarına yetkisiz erişimi önlemek ve bilgilerin zarar görmesini engellemek
  6. Haberleşme ve İşletim Yönetimi: Bilgi işlem tesislerinin uygun ve güvenli kullanımını sağlamak ve olay müdahale prosedürleri geliştirerek riski ve sonuçlarını azaltmak
  7. Erişim Kontrolü: Yetkisiz erişimlerin tespiti ve ağ sistemlerinin korunması için gerekli kontrol faaliyetlerini sağlamak
  8. Bilgi Sistemleri Edinim, Geliştirme ve Bakımı: İşletim sistemleri ve uygulama yazılımlarını bilgi kaybına karşı güncellemek ve kayıpları engellemek
  9. Bilgi Güvenliği İhlal Olayı Yönetimi: Etkin bir bilgi güvenliği sağlamak için olayların zamanında tespit etmek ve gerekli önlemleri almak
  10. İş Sürekliliği Yönetimi: Kritik arızalar, olaylar, doğal afetler, felaketlerden kaynaklanan kesintilere karşı hızla müdahale edilebilmek için kapasite geliştirme faaliyetleri gerçekleştirmek
  11. Uyum: Mevcut güvenlik politikalarının tüm yasalara ve yönetmeliklere uygun olduğundan ve üst yönetim onayından geçtiğinden emin olmak

Yazılım Geliştirme Süreçleri ve ISO 27001

ISO 27001, gerek yazılım geliştirme süreçleriyle doğrudan ya da dolaylı ilişki içerisinde olan birçok kontrol içermektedir. Bu kontroller ve kontrol kapsamında yazılım geliştirme süreci aşamalarında gerçekleştirilmesi gereken hususlar aşağıdaki gibidir.

Analiz Aşamasına İlişkin Kontroller

Yazılım geliştirme sürecinin en önemli aşamasıdır. Bu aşamada yapılacak yanlışlıklar yazılım projesinin başarısını en yüksek düzeyde etkilemektedir.

Bu aşamada kurumun mevcut bilgi teknolojileri, varsa sistem veri tabanı yapısı, sistem veri yapıları tanımlanmalıdır. Kullanıcı uygulama ihtiyaçları doğrultusunda yazılım ihtiyaç tanımları, veri yapılarını güncelleyen giriş bilgileri, uygulama yazılım ara yüz tanımları, yazılımın üreteceği çıktı bilgileri, yazılım için istenen sorgular gibi tanımlar belirlemelidir.

Yapılacak analiz, uygulama servislerinin performans ya da kısıtlamalar yönünden zorlanması ve doğru hizmet vermelerini engelleme girişimlerini de hesaba katmalıdır. Sunucu tarafındaki konfigürasyonların güvenli şekilde yapılması gerekir.

Yazılım için devreye alınacak yeni bilgi sistemleri için iş gereksinimleri bildirgeleri ya da mevcut bilgi sistemlerine yapılan iyileştirmeler güvenlik kontrolleri için gereksinimleri belirlemelidir. (A.12.1.1 – Güvenlik gereksinimleri analizi ve belirtimi) Yeni bilgi işleme tesisleri için, bir yönetim yetki prosesi tanımlanmalı ve gerçekleştirilmelidir. (A.6.1.4 – Bilgi işleme tesisleri için yetki prosesi)

Yetkilendirilmiş kullanıcıların sistemde neler yapabileceği uygun şekilde belirtilmelidir, aksi durumlarda başka kullanıcı haklarını kullanma, yetkisiz olduğu halde verilere erişebilme gibi sakıncalar doğabilir. Kuruluş içinden ya da dışından sağlanmış olsun tüm ağ hizmetlerinin güvenlik özellikleri, hizmet seviyeleri ve yönetim gereksinimleri tanımlanmalıdır. (A.10.6.2 – Ağ hizmetleri güvenliği)

İletişimin bütün türlerinin kullanımıyla ve bilgi değişimini korumak için resmi değişim politikaları, prosedürleri ve kontrolleri oluşturulmalıdır. (A.10.8.1 – Bilgi değişim politikaları ve prosedürleri)

Yazılımda kullanılacak harici materyaller için fikri mülkiyet haklarına göre materyallerin kullanımı ve patentli yazılım ürünlerinin kullanımı üzerindeki yasal, düzenleyici ve anlaşmalarla doğan gereksinimlere uyum sağlanmalıdır. (A.15.1.2 – Fikri mülkiyet hakları (IPR))

Kuruluşun dış taraflarla yapacağı bilgi ve yazılım değişimi için anlaşmalar yapılması gerekir, bu gereksinim analiz aşamasında karşılanmalıdır. (A.10.8.2 – Değişim anlaşmaları)

Tasarım Aşamasına İlişkin Kontroller

Tasarım aşamasında, uygulanacak geliştirme safhaları, her safha için girdiler, çıktılar ve kontrol metotları, iş zaman planları, uygulama planlarının yanı sıra yapılacak işlerin neler olduğu, bu işler için gerekli zaman ve kaynak ihtiyaçlarının tespiti, ilerlemenin izlenmesi için kullanılacak metotlar belirlenmelidir.

Tüm yazılım kullanıcıları için her türlü yazılım sistemine erişim kullanıcı isimleri ve şifreler ile sağlanmalı, bu şifre ve kullanıcı isimleri her kullanıcı için tek ve benzersiz olacak şekilde tasarlanmalıdır. Tasarımda kullanıcılar işlevlerine ve sorumluluk alanlarına göre gruplandırılmalı, grup bazında programlara ve veri tabanlarına erişim hakları verilerek yetkisiz kişilerin sistemi kullanmasına imkân verilmemelidir. Uygulama içinde çalışmalar her zaman menüler yardımıyla olmalı, kullanıcı programları kullanırken hiçbir zaman uygulamanın sağladığı komutlar dışına çıkma olanağı bulmamalıdır.

Bilgi sistemlerinin birbirine bağlantısı ile ilişkili bilgiyi korumak için politikalar ve prosedürler geliştirilmeli ve gerçekleştirilmeli, bilgi sızması fırsatları önlenmelidir. (A.10.8.5 – İş bilgi sistemleri, A.12.5.4 – Bilgi sızması ) Bu kapsamda tasarım aşamasında yüksek riskli uygulamalara ek güvenlik sağlamak için bağlantı sürelerinde sınırlandırmalar kullanılması gerektiği hesaba katılmalıdır. (A.11.5.6 – Bağlantı süresinin sınırlandırılması)

Tehditlerden korunmak için ve iletilmekte olan bilgi dâhil ağı kullanan sistemler ve uygulamalar için güvenliği sağlamak amacıyla ağlar uygun şekilde yönetilmeli ve kontrol edilmelidir. (A.10.6.1 – Ağ kontrolleri) Kullanıcılar ve destek personeli tarafından bilgi ve uygulama sistem işlevlerine erişim, oluşturulması önerilen tanımlanmış erişim kontrol politikasına uygun olarak kısıtlanmalıdır. (A.11.6.1 – Bilgi erişim kısıtlaması)

Kodlama Aşamasına İlişkin Kontroller

Yazılımlarda kodlamalar yapılırken güvenli yazılım kodlama teknikleri kullanılmalıdır.

Yazılımlar, modüler planlanmalı, modüler arası ilişkilerde yapısallık göz önünde bulundurulmalı ve programcı müdahalesi asgari seviyede olacak şekilde parametrik hazırlanmalıdır. Sisteme yeni modülerin ilavesi, modüllerin değiştirilmesi ya da silinmesi durumda sistemin bütünü etkilenmemelidir. Yazılımlarda kullanılacak menü, dosya, alan, değişken, tablo gibi her türlü isim anlamlı olarak seçilmelidir.

Aynı veri veya bilginin farklı veritabanı tabloları için ayrı ayrı girilmesine engel olunmalıdır (Normalizasyon). Tutarsız kod ve verilerin girişine engel olacak tedbirler alınmalı, veri tipleri ile kullanıcıların giriş yaptıkları alanların birbirleri ile tutarlı olma durumu kod içinde yapılan düzenlemeler ile giriş anında kontrol edilmelidir. Hata yapma olasılığı yüksek verilerin girildiği alanlar için liste veya seçenek kutuları kullanılmalıdır.

Özellikle web yazılımının kullanıcı bilgisayarında bir atak aracı olarak kullanılan çapraz site betiklerine (Cross side scripting) ve kontrolü ele almak üzere tamponların taşırılması gibi tehditlerden doğabilecek hatalar uygun bir şekilde kontrol edilmelidir. Kontrol edilmeyen hatalar dış dünyaya sistem ile ilgili bilgiler verebilir ve yeni açıklara zemin hazırlayabilmektedir.

Yazılımların karşılaştığı en önemli tehditlerden biri uygulamalarda gerçekleşen veri giriş-çıkışında kontrollerin tam ve sağlıklı olarak yapılmadan işleme alınması ya da çıktı olarak verilmesidir.  Uygulamalara gerçekleşen veri girişinin, bu verinin doğruluğunun ve uygunluğunun geçerlenmesi gerekmektedir. Yazılımda girdi parametreleri yazılım dışından verilebilir olmamalıdır. Kayıt olanakları ve kayıt bilgisi kurcalanma ve yetkisiz erişime karşı korunmalıdır. (A.10.10.3 – Kayıt bilgisinin korunması) Böyle bir koruma olmaması durumunda SQL (Structed Query Language) enjekte etme ve komut enjekte etme gibi yöntemlerle sistemlere girebilecek kodlar büyük zararlar verebilir. (A.12.2.1 – Giriş verisi geçerleme) Giriş verisi kadar çıkış verisi de önemlidir. Yazılımda çıkış verisi sistemimiz hakkında bilgi vermemeli veri sızıntısına açıklık bırakmamalıdır. Bir uygulamadan gerçekleşecek veri çıktısı, depolanan bilginin işlenmesinin koşullara göre doğruluğunun ve uygunluğunun sağlanması için geçerlenmelidir. (A.12.2.4 – Çıkış verisi geçerleme) Veri işleme hataları veya kasıtlı eylemler nedeniyle herhangi bir bilgi bozulmasını saptamak için geçerleme kontrolleri uygulamalar içine dâhil edilmelidir. (A.12.2.2 – İç işleme kontrolü)Uygulamalarda verinin kimliğinin doğruluğunu sağlama ve mesaj bütünlüğünü koruma gereksinimleri tanımlanmalı bunlarla ilgili uygun kontroller tanımlanmalı ve gerçekleştirilmelidir. (A.12.2.3 – Mesaj bütünlüğü)

Kötü niyetli koda karşı korunmak için saptama, önleme ve kurtarma kontrolleri ve uygun kullanıcı farkındalığı prosedürleri gerçekleştirilmeli, elektronik mesajlaşmadaki bilgi uygun şekilde korunmalıdır. Benzer bir biçimde mobil kod kullanımı yetkilendirildiğinde, konfigürasyon yetkilendirilmiş mobil kodun açıkça tanımlanmış bir güvenlik politikasına göre işletilmesini sağlamalı ve yetkilendirilmemiş mobil kodun yürütülmesi önlenmelidir. (A.10.4.1 – Kötü niyetli koda karşı kontroller, A.10.8.4 – Elektronik mesajlaşma, A.10.4.2 – Mobil koda karşı kontroller)

Kriptografi teknikleri yazılımlarda güvenliği sağlamada faydalanılan önemli tekniklerdir. Bilginin korunması için kriptografik kontrollerin kullanımına ilişkin bir politika geliştirilmeli ve gerçekleştirilmelidir. (A.12.3.1 – Kriptografik kontrollerin kullanımına ilişkin politika) Kriptografi için yeterli rastgeleliği sağlayan kriptografik tekniklerin kullanım desteklenmeli ve anahtar yönetimi bulunmalıdır. (A.12.3.2 – Anahtar yönetimi)

Yazılım geliştirme hizmetinin kuruluş dışından sağlanması durumunda, hizmeti sunan şirketin hareketleri ve yaptığı işler denetlenmeli ve izlenmelidir. (A.12.5.5 – Dışarıdan sağlanan yazılım geliştirme) Yazılım geliştiricilerce gerçekleştirilen ve revizyon kontrolü yapılmayan yazılım değişiklikleri karmaşaya ve çeşitli sorunlara neden olabilmektedir. Yazılım değişikliklerin gerçekleştirilmesinde resmi değişim kontrol prosedürlerinin kullanılması bu karmaşayı ortadan kaldıracaktır.(A.12.5.1 – Değişim kontrol prosedürleri)

Test Aşamasına İlişkin Kontroller

Kodlama aşamasından sonra gerçekleştirilecek test aşamasında yazılım uygulaması modüllerinin nitelik ve nicelik testleri yapılır. Geliştirme, test ve işletim olanakları, işletilen sisteme yetkisiz erişim veya değişiklik risklerini azaltmak için ayrılmalıdır. (A.10.1.4 – Geliştirme, test ve işletim olanaklarının ayrımı)

Bu aşamada bir test planı oluşturulmalı bu planda; test senaryoları, veri çeşitleri ve veri örnekleri ve test tasarım tanımlamaları ayrıntılı olarak belirtilmelidir. Test,   proje yöneticisi ve kullanıcı yetkilileri tarafından koordine ile programcı ve tasarımcılarla, gerçek kullanıcılar tarafından yapılmalıdır. Sistemin bütünü göz önünde bulundurularak modüllerin amaçlanan fonksiyonları tam ve etkin olarak yerine getirip getirmediği, birbiri ile entegre çalışıp çalışmadığı, veri alışverişi (varsa) yapıp yapmadığı kontrol edilmelidir.

Veri tabanının büyüklüğü ve listelenen, sorgulanan kayıt sayısı ile sistemin performans ilişkisi kontrol edilmelidir.  (A.12.2.1 – Giriş verisi geçerleme, A.12.2.4 – Çıkış verisi geçerleme, A.12.2.2 – İç işleme kontrolü) Test verisi dikkatlice seçilmeli, korunmalı ve kontrol edilmelidir. (A.12.4.2 – Sistem test verisinin korunması)

Yazılım ürünlerinin,   sistemin ve alt sistemlerin modül,   fonksiyon,   entegrasyon ve performans testlerinden sonra testlerde ortaya çıkan değerlere uygun olarak gerçek bilgi ve verilerle, gerçek kullanıcı donanım ve işletim ortamında tüm ihtiyaçların karşılandığı kontrol edilmelidir.

Revizyon istekleri göz önüne alınarak gerekli düzeltme ve düzenleme işlemleri yapılır. Entegrasyon, performans ve revizyon testleri tamamlandıktan sonra başlar. Test süresi tüm ihtiyaçların tamamlandığı ve kontrolü yapıldıktan sonra biter.

Test aşaması bitip uygulama devreye alınırken tüm çalışanlar, yükleniciler ve üçüncü taraf kullanıcıların bilgi ve bilgi işleme olanaklarına olan erişim hakları, istihdam, sözleşme veya anlaşmalarının sonlandırılmasıyla birlikte kaldırılmalı ya da değiştirilmesiyle birlikte ayarlanmalıdır. (A.8.3.3 – Erişim haklarının kaldırılması)

Bakım Aşamasına İlişkin Kontroller

Yazılım geliştirme sürencin son aşaması, bakım aşamasında da alınması gereken bir takım güvenlik önlemlerinden söz etmek mümkündür.

Yazılım paketlerine yapılacak değişiklikler, belirli bir incelemeden geçirilmeli, gerek duyulanlar gerçekleştirilmeli, bunun dışındakiler önlenmelidir. Tüm değişiklikler sıkı bir biçimde kontrol edilmelidir. (A.12.5.3 – Yazılım paketlerindeki değişikliklerdeki kısıtlamalar) Benzer bir biçimde kullanıcıların erişim hakları da resmi bir proses kullanarak düzenli aralıklarda gözden geçirmelidir. (A.11.2.4 – Kullanıcı erişim haklarının gözden geçirilmesi)

Yazılım Kaynak kodlarının bozulma riskini azaltmak ve bilgi kaybından korumak amacı ile kaynak kodları yazılım uzmanlarının işletim sistemleri içinde değil sunucu terminal üzerinde bulunmalıdır. Program kaynak koduna erişim kısıtlı olmalıdır. (A.12.4.3 – Program kaynak koduna erişim kontrolü) Söz konusu ortama erişim yalnızca ilgili yazılım uzmanı tarafından sağlanmalıdır.

Donanım arızaları, yazılım hataları, insandan kaynaklanan nedenler ve doğal afetler yazılımlarda bilgi kayıplarının ana sebepleridir.  Sebep her ne olursa yedekleme yazılımlarda hatalardan ve problemlerden geri dönüş için son derece önemlidir. Yedekleme için kurtarılabilir veri saklama yöntemleri uygulanmalı, bilgi ve yazılımlara ait yedekleme kopyaları düzenli olarak alınmalı ve alınan yedekler belirlenecek bir politikaya göre uygun şekilde düzenli olarak test edilmelidir. (A.10.5.1 – Bilgi yedekleme)

Belirlenmiş bir ön yetkilendirme olmaksızın teçhizat, bilgi veya yazılım bulunduğu yerden çıkarılmamalıdır. (A.9.2.7 – Mülkiyet çıkarımı) Eğer yetkilendirme varsa ve bilgi içeren ortamın, kuruluşun fiziksel sınırları ötesinde taşınması söz konusu ise taşıma esnasında, bilgiler yetkisiz erişime, kötüye kullanıma ya da bozulmalara karşı korunmalıdır. (A.10.8.3 – Aktarılan fiziksel ortam)

Bilgisayar donanımlarının depolama ortamı içeren tüm parçaları, elden çıkarılmadan önce, herhangi bir hassas veri ve lisanslı yazılım varsa kaldırılmasını veya güvenli şekilde üzerine yazılmasını sağlanmalıdır. (A.9.2.6 – Teçhizatın güvenli olarak elden çıkarılması ya da tekrar kullanımı)

Kurumların ve şirketlerin operasyonel sistemlerindeki yazılımların kurulmasını kontrol etmek için prosedürler bulunmalıdır.(A.12.4.1 – Operasyonel yazılımın kontrolü)

Zayıf parolalar ve şifreler bilişim sistemleri açısından önemli açıklıklar ortaya çıkarmaktadır. Kullanıcılardan, parolaların seçiminde ve kullanımında iyi güvenlik uygulamalarını izlemeleri istenmelidir. Bu ve bunun gibi hususlar için bilinçlendirme çalışmaları yapılmalı eğitimler verilmelidir. (A.11.3.1 – Parola kullanımı)

İşletim sistemleri değiştirildiğinde, kurumsal işlemlere ya da güvenliğe hiçbir kötü etkisi olmamasını sağlamak amacıyla iş için kritik uygulamalar gözden geçirilmeli ve test edilmelidir. (A.12.5.2 – İşletim sistemindeki değişikliklerden sonra teknik gözden geçirme)

Sonuç

Kurumların güvenli bir ortamda faaliyet gösterebilmeleri için dokümante edilmiş bir BGYS’yi hayata geçirmeleri gerekmektedir. Bu kapsamda ISO 27001 standardı tüm dünyada kabul görmüş ve en iyi uygulamaları bir araya getiren bir modeldir. Standart bu yönetim sistemini oluştururken ele aldığı önemli alanlardan biri de yazılım geliştirme süreçlerinde güvenliğinin sağlanması ve buna ilişkin olarak yazılım geliştirme politikasının oluşturulmasıdır. Yazılım geliştirme süreçlerinde standardın belirttiği gizlilik, bütünlük ve erişebilirlik kavramları mutlaka dikkate alınmalıdır. Bu kapsamda, yazılım geliştirmenin her aşamasında belirli bir güvenlik politikasının uygulanması kritik önem taşımaktadır. Kurumsal güvenlik için öncelikle yazılı olarak kurallar belirlenmelidir. Etkin bir BGYS kurmaya çalışan ve bunu ISO 27001 standardına uyumlu yapmak isteyen tüm kurumların oluşturacağı bu politikada belli kontrol maddeleri asgari olarak yer almalıdır.

Dr. İzzet Gökhan Özbilgin, Sermaye Piyasası Kurulu; Mustafa Özlü, Türk Patent Enstitüsü

Kaynak: https://www.bilgiguvenligi.gov.tr/yazilim-guvenligi/yazilim-gelistirme-surecleri-ve-iso-27001-bilgi-guvenligi-yonetim-sistemi.html

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

System.Speech İle Basit Bir Ses Algılama Uygulaması

15 Şub

.Net Framework’ün 3.0 versiyonu ile gelen System.Speech kütüphanesinde bulunan metodlar ve sınıflar ile Ses Algılama işlerini nasıl yapabileceğimi bir uygulama ile görmeye çalıştım.İnternette benzeri olan basit uygulamayı biraz farklı yorumlayarak aktarıyorum.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Speech;
using System.Speech.Recognition;
using System.Threading;
using System.Diagnostics;
using System.Timers;

//Kullanılan Kütüphaneler Burada önemli olan Speech kütüphanelerinin ve SDK’larının kurulu olması.

namespace AppleVoice
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

SpeechRecognitionEngine sre = new SpeechRecognitionEngine();
//Algılama Engine burada tanımlanıyor

private void Form1_Load(object sender, EventArgs e)
{
KomutlariOlustur();

//4 Olay var;Algılama,Tanıma,Tamamlanma,Cevap
sre.SpeechDetected += new EventHandler(sre_SpeechDetected);
sre.SpeechRecognized += new EventHandler(sre_SpeechRecognized);
sre.RecognizeCompleted += new EventHandler(sre_RecognizeCompleted);
sre.SpeechRecognitionRejected += new EventHandler(sre_SpeechRecognitionRejected);
Thread t = new Thread(delegate() { sre.SetInputToDefaultAudioDevice(); sre.RecognizeAsync(RecognizeMode.Single); });
t.Start();

//Thread salınıyor
}

private void KomutlariOlustur()
{
string[] komutlar = new string[] { “apple”, “pear” };
Choices insChoices = new Choices(komutlar);
GrammarBuilder insGrammarBuilder = new GrammarBuilder(insChoices);
insGrammarBuilder.Culture = System.Globalization.CultureInfo.GetCultureInfoByIetfLanguageTag(“en-US”);
Grammar insGrammar = new Grammar(insGrammarBuilder);
sre.LoadGrammar(insGrammar);

//Komutlar tanımlanıyor.Burada önemli olan Dil Faktörü .NET ve OS’unuzun uyumuna göre tanım vermelisiniz

}

void sre_SpeechRecognitionRejected(object sender, SpeechRecognitionRejectedEventArgs e)
{
progressBar1.Style = ProgressBarStyle.Blocks; ;
lblDurum.Text = “Komut algılanamadı.”;
}

void sre_RecognizeCompleted(object sender, RecognizeCompletedEventArgs e)
{
sre.RecognizeAsync();
progressBar1.Style = ProgressBarStyle.Blocks;
}

void sre_SpeechRecognized(object sender, SpeechRecognizedEventArgs e)
{
if (e.Result.Text == “apple”)
{
Process.Start(“notepad.exe”);
}
else if (e.Result.Text == “pear”)
{
Process.Start(“mspaint.exe”);
}
lblDurum.Text = “”;
//elma dersek notepad armut dersek paint çalışacak
}

void sre_SpeechDetected(object sender, SpeechDetectedEventArgs e)
{
int ds = Convert.ToInt32(System.DateTime.Now.Second);
lblDurum.Text = “Komut algılanıyor…”;
progressBar1.Style = ProgressBarStyle.Marquee;
}

}
}

ASP.NET 3.5 Summary 5 – Get,Set etc…

28 Haz

Get metodu bir değişken çağırıldığında çalışmaya başlayan metotdur.
Set metodu ise bir değişkene değer atandığında çalışmaya başlayan metotdur.

Kodlar ile açıklamaya çalışalım.

public class GetterSetter
    {
        private double a;
        public double A
        {
            get
            {
                MessageBox.Show(“Public A degiskeni çağırıldı get{} bloğu çağırıldı!!!”);
                return a;
            }
            set
            {
                MessageBox.Show(“Public A degiskenine deger atandı set{} bloğu çağırıldı!!!”);
                // value :  A degiskenine atanan degerdir…
                if (value > 10)
                {
                    MessageBox.Show(“A sayisina 10 dan buyuk deger giremezsiniz”);
                    return;
                }
                if ((value <= 10) && (value >= 0))
                {
                    MessageBox.Show(“Private a degiskenine girdiginiz degerin yarısını atıyorum!!!”);
                    a = value / 2;
                    MessageBox.Show(“a = ” + a.ToString());
                }
            }
        }
    }

Şimdi ise bu class`ımızdan bir object oluşturup get ve set metodumuzun nasıl çalıştığına bakalım.

       GetterSetter cagirmaatama = new GetterSetter(); // sınıftan nesne türetiyoruz…

        private void button1_Click(object sender, EventArgs e)
        {
            cagirmaatama.A = double.Parse(textBox1.Text); // atama set işlemi gerçekleştiriliyor
        }

        private void button2_Click(object sender, EventArgs e)
        {
            MessageBox.Show(“A = ” + cagirmaatama.A.ToString()); // çağırma get işlemi gerçekleş…
        }

Sıradaki Konular:

-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 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

C# Programlama Dili

23 Haz

C# Programlama Dili (si şarp şeklinde telaffuz edilir), Microsoft‘un geliştirmiş olduğu yeni nesil dilidir. Yine Microsoft tarafından geliştirilmiş .NET Teknolojisi için geliştirilmiş dillerden biridir.

Microsoft tarafından geliştirilmiş olsa da ECMA ve ISO standartları altına alınmıştır.

C programlama dilinde bir tamsayı değişkeni 1 atrırmak için ++ soneki kullanılır. C++ dili adını, C diliyle Nesneye Yönelimli Programlama yapabilmek için eklentiler (C With Classes) almıştır. Benzer şekilde C++ diline yeni eklentiler yapılarak ((C++)++) bir adım daha ileriye götürülmüş ve tamamen nesneye yönelik tasarlanmış C# dilinin isimlendirilmesinde, + karakterlerinin birbirlerine yakınlaşmış hali ve bir melodi anahtarı olan C# Major kullanılmıştır.

Bu dilin tasarlanmasına Pascal, Delphi derleyicileri ve J++ programlama dilinin tasarımlarıyla bilinen Anders Hejlsberg liderlik etmiştir.

Birçok alanda Java’yı kendisine örnek alır. .NET kütüphanelerini kullanmak amacıyla yazılan programların çalıştığı bilgisayarlarda uyumlu bir kütüphanenin ve yorumlayıcının bulunması gereklidir. Bu, Microsoft’un .Net Framewok‘u olabileceği gibi ECMA standartlarına uygun herhangi bir kütüphane ve yorumlayıcı de olabilir. Yaygın diğer kütüphanelere örnek olarak Portable.Net ve Mono verilebilir.

Özellikle nesne yönelimli programlama kavramının gelişmesine katkıda bulunan en aktif programlama dillerinden biridir .NET platformunun anadili olduğu bazı kesimler tarafından kabul görse de bazıları bunun doğru olmadığını savunur.

C#.NET orta seviyeli programlama dillerindendir. Yani hem makine diline hem de insan algısına eşit seviyededir. Buradaki orta ifadesi dilin gücünü değil makine dili ile günlük konuşma diline olan mesafesini göstermektedir. Örneğin; Visual Basic.NET(VB.NET) yüksek seviyeli bir dildir. Dersek bu dilin insanların günlük yaşantılarında konuşma biçimine yakın şekilde yazıldığını ifade etmektedir. Dolayısı ile buradan yola çıkarak VB.NET, C#.NET’ten daha güclü bir dildir diyemeyiz.

Tasarım hedefleri

ECMA tarafından C# dilinin tasarım hedefleri şöyle sıralnır:

  • C# basit, modern, genel-amaçlı, nesneye yönelik programlama dili olarak tasarlanmıştır.
  • Çünkü yazılımın sağlamlılığı, güvenirliliği ve programcıların üretkenliliği önemlidir. C# yazılım dili, güçlü tipleme kontrolü (strong type checking), dizin sınırlar kontrolü (array bounds checking), tanımlanmamış değişkenlerin kullanım tespiti, (source code portability), ve otomatik artık veri toplama gibi özelliklerine sahiptir.
  • Programcı portatifliği özellikle C ve C++ dilleri ile tecrübesi olanlar için çok önemlidir.
  • Enternasyonal hale koymak için verilen destek çok önemlidir.
  • C# programlama dili sunucu ve gömülü sistemler için tasarlanmıştır. Bununla birlikte C# programlama dili en basit işlevselli fonksiyondan işletim sistemini kullanan en teferruatlısına kadar kapsamaktadır.
  • C# uygulamaları hafıza ve işlemci gereksinimleri ile tutumlu olmak uzere tasarlanmıştır. Buna rağmen C# programlama dili performans açısından C veya assembly dili ile rekabet etmek için tasarlanmamıştır.

Örnek “HeLLo!”

class MerhabaDunya
   {

       //Programın ilk girdiği nokta (Entry Point)
       static void Main(/*string[] args*/)
       {
           System.Console.WriteLine(“Merhaba Dünya!”);
           //System isim uzayındaki Console sınıfının WriteLine() yöntemini kullanarak
           //basit bir Konsol çıktısı ürettik.
        }
   }

Yukarıdaki örnek kod

Merhaba dunya!

şeklinde ekranda çıktısı olacaktır. Bu kod parçası konsol uygulaması üzerinden verilmiştir. C# ile Windows Form,Consol,WPF,WCF,WF,SilverLight,Web ve daha bir çok türde uygulama geliştirilebilir.

Wiki

.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.Ç.