2. Seminer İçeriği
• WCF (Windows Communication Foundation) Kimdir?
• WCF Öncesi Halimiz
• WCF ve SOA (Service Oriented Architecture)
• Kuşbakışı WCF Mimarisi
• Örnek WCF Vakkaları
• Demo - Merhaba WCF
• Hosting Seçenekleri
• Demo - Windows Servisi Olarak Yayınlamak
• Geliştirici için Kazançlar
• Daha Ne Var?
• Yardımcı Kaynaklar
• Soru – Cevap
4. WCF (Windows Communication
Foundation) Kimdir?
Microsoft .Net
Framework 3.0
Windows
Communication
Foundation
(WCF)
5. WCF Kimdir?
Servis yönelimli
mimari(Service Oriented
Architecture - SOA) için
uygulamalar geliştirmek
amacıyla, Microsoft tarafından
üretilmiş birleştirilmiş, kolay ve
güçlü yeni bir programlama
anlayışıdır.
6. WCF Kimdir?
ASMX .NET
Remoting
Diğer Platformlar Genişletilmiş
İle daha kolay Remoting
uyumluluk
Nitelik Tabanlı
Programlama MSMQ
WS-*
Protokol Desteği
Enterprise System.Messaging
Services
WSE
7. WCF Kimdir?
WCF, hızlı bir şekilde servis yönelimli mimariyi baz alan
uygulamalar yazabilmek için geliştirilmiş, birleştirilmiş(unified)
bir Framework API' si olarak düşünülebilir.
WCF, Windows tarafındaki çeşitli dağıtık mimari
modeller arasındaki entegrasyonun tek bir çatı altında
toplanabilmesini sağlamaktadır (Integration).
WCF, önceki dağıtık mimari modellerine göre platform
desteğini daha güçlü desteklemektedir (Interoperability) .
11. WCF ve SOA
Azon Yarış Bisikleti Pedalları Satıcısı
Muhasebe İmalatçı Call Center
Pazarlama
Satış Ofisi Web Sayfası
Elamanı
12. WCF ve SOA
Azon Yarış Bisikleti Pedalları Satıcısı
Muhasebe İmalatçı Call Center
Sipariş
Ticari Ortak CRM
Servisi
Pazarlama
Satış Ofisi Web Sayfası
Elamanı
14. Kuşbakışı WCF Mimarisi
WCF, CLR
(Comman Language
Runtime) tiplerinin birer
servis olarak
sunulabilmesini ve hatta
servislerin de birer CLR
tipiymiş gibi ele
alınabilmesini sağlayan
bir mimari sağlamaktadır.
15. Kuşbakışı WCF Mimarisi
endPoint bir servisin dış
ortama sunulan arayüzüdür
(Interface).
endPoint, istemcilerin
proxy üzerinden gönderdiği
ve aldığı mesajların servis
tarafında karşılandığı
WCF’ in ABC’ si
noktadır.
16. Kuşbakışı WCF Mimarisi
WCF’ in ABC’ si -> Adresler (Addresses)
Hizmette bulunan her servis benzersiz bir adrese
sahip olmalıdır.
Servis adresi, servisin yeri (service location) ve
taşıma protokolü (transport protocol) bilgilerinden oluşur.
Servis yeri, bilgisayar, site, network, iletişim portu,
pipe, URI, queue adı veya belirli bir path bilgisi olabilir.
Taşıma protokolü, HTTP,TCP, P2P (Peer To
Peer), IPC (Inter-Process Communication), MSMQ
(Microsoft Message Queuing) olabilir.
17. Kuşbakışı WCF Mimarisi
WCF’ in ABC’ si -> Adresler (Addresses)
net.tcp://localhost:4578/MatSrv
net.msmq://localhost:6789/MatSrv
http://localhost:9001/MatSrv
...
18. Kuşbakışı WCF Mimarisi
WCF’ in ABC’ si -> 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.
Bir bağlayıcı tip (Binding Type), taşıma tipi
(transport type), protokol(protocol) ve veri
çözümlemesi(data encoding) bildirir.
19. Kuşbakışı WCF Mimarisi
Veri
Konfigurasyon Taşıma Çeşidi Çözümlemes Platform Desteği
Binding Tipi
Elementi (Transport Type) i (Inter operatbility)
(Data Encoding)
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
20. Kuşbakışı WCF Mimarisi
WCF’ in ABC’ si -> Sözleşmeler(Contracts)
Sözleşmeler bir servisin ne iş yaptığının
bilinmesinde önemli rol oynarlar. Bu özellikle, istemcilerin
ihtiyaç duyduğu proxy sınıflarının yazılmasında önem arz
eden bir konudur.
WCF' da tüm servisler dış ortama bir sözleşme
(Contract) sunar.
21. Kuşbakışı WCF Mimarisi
WCF’ in ABC’ si -> Sözleşmeler(Contracts)
WCF 4 farklı sözleşme çeşidi sunar.
Servis Sözleşmesi (Service Contract): Servis üzerinden hangi
operasyonların gerçekleştirilebileceğini 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.
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.
23. Örnek WCF Vakkaları
Klasik Intranet Modeli
Active
Directory NetTcpBinding
Servis
(Service)
İş Nesnesi
(Business
TCP TCP Components)
Veri Erişim
Doğrulama Katmanı
Istemci (Authentication) (DAL)
24. Örnek WCF Vakkaları
Web Servisi Modeli
BasicHttpBinding
HTTPS İş
S
N
Basic Username
e e
D
Profile r s
AspNetDb A
v n
L
Username e
i s
HTTP s i
WsHttpBinding
WS*
Profile
25. Örnek WCF Vakkaları
Güvenilir İş Ortağı Modeli
S İş
N
WsHttpBinding e e
HTTP HTTP D
r s
A
İş Ortağı v n
L
e
(Internet i s
İstemcisi)
Sertifika s i
Deposu
(Certificate
Store)
26. Örnek WCF Vakkaları
Web Uygulaması Tabanlı Model
S İş
NetTcpBinding N
e e
HTTPS Asp.Net D
App.
r s
TCP A
(Internet v n
L
e
İstemcisi) i s
AspNetDb Sertifika s i
Deposu
(Certificate
Store)
37. Daha Ne Var?
Hata Yönetimi (Fault Management)
Transaction Yönetimi (Transaction Management)
Asenkron Erişimler (Asynchronous Access)
Mesaj Seviyesinde Güvenlik (Message Level Security)
İletişim Seviyesinde Güvenlik (Transport Level Security)
Internet veya Intranet Üzerinden Güvenlik
Özel Bağlayıcı Tipler (Custom Binding Types)
Çift Yönlü İletişim ve Olay Tetikleme
39. Daha Ne Var?
Transaction Yönetimi
Binding Tipi Transaction Protokolü Desteği
BasicHttpBinding Destek yok
WSHttpBinding WSAT
WSDualHttpBinding WSAT
WSFederationHttpBindin WSAT
g
NetTcpBinding OleTx
NetPeerTcpBinding Destek yok
NetNamedPipesBinding OleTx
NetMsmqBinding Destek yok
MsmqIntegrationBinding Destek yok
43. Yardımcı Kaynaklar
C#Nedir? (www.csharpnedir.com)
Bsenyurt (www.bsenyurt.com)
Programming WCF Services
Juval Löwy – O’Reilly
Professional WCF Programming
Scott Klein – Wrox
Pro WCF - Practical Ms SOA Implementation
Chris Peiris, Denis Mulder - APress
Michele Leroux Baustamante – WCF Web Cast Series
MSDN Magazine – Service Station
46. Bunları Yapmazsak
Elektrik tüketimi daha düşük bilgisayarlar alınmalı.
Masaüstü PC yerine dizüstü bilgisayarlar tercih
edilmeli.
Yazıcıdan kağıt çıktısı alınması asgariye indirilmeli.
Bilgisayarlar bekleme konumunda bırakılmamalı.
Kullanılmayan bilgisayarlar atılmamalı.
Gereksiz kâğıtlar müsfette kullanım için saklanmalıdır.
47. Bunları Yapmazsak
Enerji dostu ampuller kullanılmalı.
Televizyonlar bekleme konumunda bırakılmamalı.
Evler ısı kaybına karşı yalıtılmalı.
Eşyalar, radyatörleri kapatmayacak
şekilde yerleştirilmeli.
Daha az su tüketen yeni teknoloji
rezervuarlar kullanılmalı.
Diş fırçalama, bulaşık yıkama,
traş esnasında musluk açık bırakılmamalı.
Yazıcıdan çıkarılacak dokümanların kenar boşlukları ve font
büyüklükleri azaltılmalı.
Ofislerde lambaların tamamı yerine, belirli bir kısmı kullanılmalı.
03/07/13 23:17 WSE ? Web Service Enhancements hakkında biraz bilgi edinelim.
03/07/13 23:17
WSE – Web Services Enhancements-> Çoğunlukla web servislerinde güvenlik üzerine geliştirilmiş eklentileri içeren bir microsoft mimarisidir. WCF doğrudan WSE 3.0’ ı içermektedir.
Burada tüm parçaların, sipariş mantığını kendi içlerinde uyguladıkları düşünülür. Buna göre sipariş mantığında bir değişklik olduğundan bunu tüm iş parçalarına uygulamak gerekecektir. Üstelik yeni iş parçaları eklendiğinde bunlarada sipariş mantığının genişletilmesi gerekir. Çözüm, söz konusu sipariş mantığını bir servis olarak tasarlamaktır.
Burada tüm parçaların, sipariş mantığını kendi içlerinde uyguladıkları düşünülür. Buna göre sipariş mantığında bir değişklik olduğundan bunu tüm iş parçalarına uygulamak gerekecektir. Üstelik yeni iş parçaları eklendiğinde bunlarada sipariş mantığının genişletilmesi gerekir. Çözüm, söz konusu sipariş mantığını bir servis olarak tasarlamaktır.
MTOM -> Microsoft Transmission Optimization Mechanism -> Web servislerinden etkili bir şekilde binary veri gönderilme ve alınma işlemleri ile ilgilenir.
Tcp protokolü üzerinde binary mesajlaşma vardır. Müşterik Windows Doğrulama sistemleri kullanılabilir. NTLM(NT LAN Manager) ve Kerberos(Bir Computer Network Authentication Protocol) gibi. Windows Ehliyetleri (Windows Credentials) yardımıyla mesaj koruması(Message Protection) sağlanır.
Transfer güvenliği HTTPS ile yada Mesaj Seviyesinde WS*’ a uygun olacak şekilde karşılanabilir. Standart internet tabanlı kullanıcı adı ve şifre doğrulama sistemi kullanılabilir. Örneğin Asp.Net 2.0 ile gelen AspNetDb’ den faydalanılabilir. Http/Text veya Http/MTOM ile mesaj gönderilebilir. WS* Protokolüne destek vardır. Http ile olan erişimde mesaj seviyesinde koruma yer almaktadır. Https içinse iletişim seviyesinde güvenlik söz konusudur.
Bu senaryoya göre, istemcideki mesajlar sertifika yardımıyla servise gönderilirler. Dolayısıyla sertifika tabanlı doğrulama (Certificate Based Authentication) yapılır. Transfer Security istenirse HTTPS ile istenirse mesaj seviyesinde sağlanabilir. Burada mesaj seviyesindedir. Eğer istemciler intranet içerisindelerse aynı senaryo TCP/Binary bazlı olarakda gerçeklenebilir. Tabi bu durumda Binding tipini değiştirmek gerekecektir.
Bu senaryoya göre istemciler web uygulamasına bağlanırlar. Burada authentication veya authorization işlemleri için yine aspnetdb kullanılır. Servisi kullanan web uygulamasının kendisidir. Web uygulaması servise yine sertifika ile bağlanır. Ancak performans için Tcp/Binary şeklinde bir bağlantı kurar.
03/07/13 23:17
03/07/13 23:17
03/07/13 23:17
Bu şekle göre istemcinin talepte bulunduğu işlemler sonrası Servis A, Servis B ve Servis C üzerindeki kaynaklardaki işlem parçalarının başarılı bir şekilde tamamlanmasını istemektedir. Bir başka deyişle Servis B , Servis C ve Servis A üzerindeki işlem parçalarının hepsinin ayrı ayrı başarılı olmaları gerekmektedir. Burada ortaya bir koordinasyon problemi çıktığıda son derece açıktır. Örneğin aşağı daki maddeler halinde sıralanmış olan soruların söz konusu sistemde nasıl karşılanabileceği düşünüldüğünde, sadece bu işler için neden güçlü koordinasyon uygulamaları yazıldığı daha kolay bir şekilde anlaşılmaktadır. Acaba bu sistemde Transaction' ı kim başlatacak? Diyelimki Transaction birisi tarafından başlatıldı. Diğer işlem parçalarını açılan bu Transaction' a kim dahil edecek (auto enlist) ? Öyleki dahil olmadan transaction' ın farklı sistemlere yayıldığı nasıl anlaşılacak? Geri alma (Rollback) veya onaylama (Commit) işlemlerini kim üstlenecek? Birden fazla servis söz konusu olduğundan bunlar üzerinde toplu bir rollback veya commit kararı nasıl ve neye göre verilecek? Transaction' ı üstlenen, bir başka deyişle süreci başlatıp bitirecek olan servis, diğer servislerdeki işlem parçalarının sonuçlarından nasıl haberdar olacak? Bahsedilen bu işlem parçalarını içeren ve yürüten servisler farklı platformlarda hatta farklı iletişim seviyelerinde (Http, Tcp gibi) olduğu zaman nasıl kontrol altına alınacak?
WSAT – Web Service Atomic
İstemci uygulama, Makine A üzerinde yer alan servisten bir işlem için talepte bulunmaktadır. Makine A üzerinde yer alan servis bu senaryoda root olarak görev yapmaktadır. Buna göre transaction' ın başlatılmasından hatta sonlandırılmasında n (ister commit ister rollback) kendisi sorumludur. Makine A' da yer alan servis işlemlerin geri kalanı için Makine B ve C üzerinde yer alan servisleride kullanmaktadır. Burada root servis kendi proxy nesnesi yardımıyla B ve C servislerine bir transaction ID değeri gönderir. Bu transaction ID sistem tarafından üretilen benzersiz ve tekrar etmeyen bir değerdir. Bunu programlama ortamında da kullanabildiğimiz GUID (Global Unique IDentifier) değeri olarak düşünebiliriz. Söz konusu ID, B ve C servisleri tarafından kendi makinelerindeki DTC hizmetlerinede bildirilir. Bir başka deyişle B ve C makinelerinde yapılmak üzere olan işlemlerin, transaction ID' si belirtilen sürece ait oldukları bildirilir. Dolayısıyla B ve C servislerinin yürüttükleri işlemler otomatik olarak, root servis tarafından açılan transaction' a dahil edilmiş olurlar. Bu işlemlerin ardından tahmin edileceği üzere çift yönlü geçerli kılma protokolü (two phase commit protocol) başlar. Yani root servis, transaction' a dahil olmuş diğer servislerden oylarını ister. Burada diğer makinelerdeki DTC servisleri devreye girerek oylama (vote) sonuçlarını root DTC servisine iletirler. Eğer herkes kabul ediyorsa, bir başka deyişle transaction' a dahil olan tüm servisler yaptıkları işlemlere onay vermişse, root servis ikinci aşamaya geçer. Bu aşamada da transaction' a dahil olan servislere işlemleri onaylamalarına dair bilgi gider. Sonuç olarak işlemler onaylanır (Commit) . Elbetteki diğer makinelerdeki DTC' lerden gelecek tek bir iptal isteği, tüm transaction' ın iptal edileceği ve işlemlerin geri alınması için root DTC' den, bağlı olan servislere bilgi gönderileceği anlamına da gelmektedir (Rollback) . Burada dikkat edilmesi gereken noktalardan biriside, yönetsel işlemleri üstlenen Dağıtık Transaction Koordinasyon(DTC) servisinin, root makinede olmasıdır. Bir başka deyişle Servis Yönelimli Mimari (SOA) modelindeki tüm DTC' lerin oylarını kontrol edip, kabul edilmeleri veya iptal işlemlerini gerçekleştirebilecek tek bir DTC var olabilir.
İlk olarak istemci uygulama Servis A üzerinden bir operasyon çağrısında bulunur. Şekle göre Servis A bağlayıcı tipini (Binding Type) istemcilerden gelecek transaction akışlarını destekleyecek biçimde tasarlamıştır. Üstelik çağırılan operasyon için Servis A, Transaction akışına izin vermektedir. Bununla birlikte istemcide açılan bir Transaction mevcut değildir. Lakin Servis A için TransactionScopeRequired özelliğinin değeri true olarak belirlenmiştir. Buna göre söz konusu operasyon için Servis A otomatik olarak bir Transaction alanı (Scope) açacaktır. Gelelim Servis B' ye. Servis A, Servis B üzerinden de bir operasyon çağrısı yapmaktadır. Servis B' ye ait bağlayıcı tip(binding type) diğer istemcilerden transaction akışına izin vermektedir. Bununla birlikte Servis B' deki operasyonun TransactionFlow özelliği Mandatory olarak belirlenmiştir. Bir başka deyişle Servis A' nın Servis B' ye bir Transaction akışı sağlaması şarttır. Diğer taraftan Servis B' deki TransactionScopeRequired özelliğinin değeri true olduğundan Servis B' deki operasyon, otomatik olarak Servis A' dan gelen Transaction Scope ' a dahil olacaktır. Buna göre Servis A ve Servis B aynı Transaction Scope içerisinde çalışacaktır. Servis B, Servis C üzerinden bir operasyon çağırmaktadır. Servis C' deki duruma baktığımızda, bağlayıcı tipin başka servis veya istemcileriden gelen transaction akışına izin vermediği görülmektedir. Bununla birlikte operasyon içinde, transaction akışına izin verilmemektedir. Ancak çağırılan operasyonun bir transaction içerisinde çalıştırılması gereklidir. Çünkü TransactionScopeRequired özelliğinin değeri true olarak ayarlanmıştır. Bu sebepten Servis C kendine ait Transaction alanı içerisinde çalışmaktadır. Servis C, Servis D üzerinden de bir operasyon çağırmaktadır. Servis C' dekine benzer olarak diğer servis veya istemcilerden gelecek transaction akışına izin vermeyecek şekilde bağlayıcı tipi ayarlanmıştır. Diğer yandan çağırılan operasyon içinde transaction akışına izin verilmemekte ve yeni bir transaction oluşturulması da engellenmektedir. Dolayısıyla buradaki operasyon tamamen transaction haricinde kendi haline çalışmaktadır.
