Arkadaşlar Merhaba;
Şimdiye kadar yazdığım, Geçmişten Günümüze Serisineki makaler ile amacım sizlere WCF'e gelene kadar kullanılan servis mimari teknolojileri hakkında, giriş seviyesinde de olsa bilgi vermekti. Artık Windows Communication Foundation'a gönül rahatlığı ile giriş yapabilirim. Aslında bundan önce sizlere Servis Orianted Architecture konusunu açmam gerekiyor. Bu konuda WCF kategorisinde biraz kısa da olsa bilgiler olduğu için üzerinde durmayacağım. SOA'yı gerçek anlamda incelemeye kalarsak inanın 100 makalenin bile yeteceğini sanmıyorum :)
Windows Communication Foundation, .Net Framework 3.0 ile birlikte bizim hayatımıza girmiş ve biraz zor çıkacağa benzemektedir :) Kısaca bu da Servis Yönelimli Mimari'de kullanılacak, güçlü, geliştirilmesikolay olarak tasarlanmış ve tabii ki platform bağısızlığı sunan bir teknolojidir. Eski teknolojilerde çok fazla kod yazarak, çok fazla noktaya dikkat ederek geliştirmemiz gereken servisleri, çok ama çok basit bir kaç konfigurasyon ayarı ve bir kaç noktaya dikkat ederek geliştirebilirsiniz. Windows Communication Foundation'un aslında hedefi, eski teknolojilerin nerdeyse bütün zorluklarından kurtularak, o güne kadar kullanılan dağıtık mimari uygulamalarının tamamının ve fazlasının, tek bir platformada toplanmasını sağlamaktır.
Hemen bir WCF Library Projesi açalım ve karşımıza gelen şablonda neler olduğuna bakıp, şablon üzerinden yazımıza devam edelim ;)
Projemiz açıkdıktan sonra, Solution Explorer'ı inceleyelim. Öncelikle şunu belirtmek isterim, şuanda kullandığımız şablon için, genel olarak kullanılan bir class yapısını kullanabilirsiniz. Servisimizin ihtiyacı olan referansları projenize dahil etmeniz, ve sınıfınızın içerisine birazdan değineceğimiz noktalara dikkat etmeniz yeterli olacaktr ;)
System.ServiceModel ve System.Runtime.Serialization namespace'leri bizim servisimizin ihtiyaç duyduğu DDL'ler dir. Solution Explorer'a baktığımızda, bizim için Service.cs ve IService.cs adında, bir class ve bir Interface olduğunu görüyoruz. Buradaki Interface'in amacı, Implemente ettiği class'ın şablonunu oluşturmak. Bu şekilde kullanımı önerilmekte ama kesinlikle böyle bir zorunluluğunuz yok ;) Siz isterseniz tek bir class içerisinde servisinizi geliştirebilirsiniz.
Windows Communication Foundation'u geliştirirken dikkat etmeniz ve bilmeniz gereken bazı noktalar var ;) kısaca bunlardan bahsedip, servisimizi geliştirmeye devam edeceğim.
Mimariye baktığımızda karşımıza, Address, Binding, Contract kavramlarının çıktığını görüyoruz.
Address, adından da çok rahat anlaşılabileceği gibi, servisimizin yayınlanacağı adresi temsil etmektedir. Aynızaman da bu adres bilgisi içerisinde, servisin kullanacağı protokol ve port numarası bilgileride bulunmaktadır. Geiştirilen serviste kullanılan Binding Tipi, protokol ile belirlenmiştir.
Örnek Olarak, http:// - https:// - net.tcp:// - net.msmq:// gösterilebilir. Sadece bu protokoller ile sınırlı da değildir ;)
Bindings, bağlayıcılar, temel olarak servisler ile kurulacak olan iletişimin, nasıl kurulması gerektiği bilgisini sunmaktadır. Bağlayıcı tip, protokol, veri encoding ve taşıma tipini bildirmelidir. Bağlayıcı tipler, servisimiz ile, desteklediği model, WS*- protolleri vb. sunmaktadır.
BasicHttpBinding, WsHttpBinding, WsDualHttpBindig, WebHttpBinding, NetTcpBinding, MsmqIntegrationBinding bunlardan bazıları ve genellikle en çok kullanılanlarıdır. Her binding tipinin kendine özgü, yetenekler, güvenlik seviyeleri, ws* destekleri, iletişim çeşitleri, mesaj seviyesinde güvenlikleri ve fazlası vardır. Binding tipi ve seçimi bu özellikler ışığında gerçekten çok önemlidir.
Contracts, Geliştirilen servisin, hangi amaca hizmet ettiğini, ne iş yaptığının bilinmesinde kilit rol oynamaktadır. Sözleşmeler dörk ana kategoriye ayrılmaktadır, Service Contract, Data Contract, Message Contract ve Fault Contract.
Serviler End Point'ler üzerinden iletişimi sağlamaktadır. Address, Binding ve Contract'lar bu End Pointler üzerinden iletişimi sağlarlar. istemci tek bir End Point kullanırken, servisimiz içerisinde N sayıda End Point kullanılabilir.
İstemciler taleplerini belirtirken, Contract-Binding-Address şeklinde servise mesajını göndermeleri gerekmektedir. Servisler ise tam tersi şeklinde bu talebi işler ve istemciye cevabı gönderirken yine Contract-Binding-Address şeklinde göndermeleri gerekmektedir. Bu teknik bir bilgidir ve servisi geliştiren bir kişinin bu bilgilere hiç bir şekilde ihtiyacı yoktur ;)
Geliştirdiğimiz servisimizi iki ana kategoride host etme imkanına sahibiz. Genel olarak IIS kullanılırken, Self Hosting ile de servisimizi host etme imkanımızda vardır. Self Hosting "Console Application dan Windows Presentation Foundation'a, Wista ile gelen, Windows Activation Service'den Silverlight'a kadar" bir çok seçenek ve teknoloji sunmaktadır.
Yukarıda açtığımız WCF Service Library'e geri dönüp, bu bilgiler ışığında projemize devam edebiliriz ;)
IService.cs interface'in içeriğinde;
[ServiceContract]
public interface IService1
{
[OperationContract]
string GetData(int value);
[OperationContract]
CompositeType GetDataUsingDataContract(CompositeType composite);
// TODO: Add your service operations here
}
// Use a data contract as illustrated in the sample below to add composite types to service operations
[DataContract]
public class CompositeType
{
bool boolValue = true;
string stringValue = "Hello ";
[DataMember]
public bool BoolValue
{
get { return boolValue; }
set { boolValue = value; }
}
[DataMember]
public string StringValue
{
get { return stringValue; }
set { stringValue = value; }
}
}
Service.cs class'ın içerisinde;
public class Service1 : IService1
{
public string GetData(int value)
{
return string.Format("You entered: {0}", value);
}
public CompositeType GetDataUsingDataContract(CompositeType composite)
{
if (composite == null)
{
throw new ArgumentNullException("composite");
}
if (composite.BoolValue)
{
composite.StringValue += "Suffix";
}
return composite;
}
}
Kodlarının bizim için hazır olarak geldiğini görebiliriz. Aslında şuan da servis bizim için hazır ve test edilebilir durumda. Direk olarak Ctrl + F5'e basarak, arkada çalışan WCF Test Client uygulaması ve WcfSvcHost mekanizması ile kodu test edebiliriz ;) Bu araç üzerinden SOAP XML mesajının içeriğine de ulaşıp inceleyebiliriz.
Class içerisinde ServiceContract, OperationContract, DataContract ve DataMember Attribute'lerinin olduğunu görüyorsunuz. Yukarıda değindiğim gibi, Contract'lar 4 kategoridedir. İçerisinde ki veri üyeleri biraz daha fazla olsada, ana kategorileri bunlardır.
Contract'lar ve çeşitlerini, ana kategorilerini bir iki cümle ile biraz daha açıklamak gerekirse;
Service Contract (Hizmet Sözleşmesi): Geliştirilen servisimiz sonuç olarak dışarıya bir hizmet sunmaktadır ve bunu belirten sözleşme çeşididir. Her bir servis için, birden fazla OperationContract, DataContrat ve DataMemeber, EnumMember vs. kullanabilirsiniz. Ancak bir servis implementasyonu için, en az bir tane ServiceContract ve En fazla da, bir tane ServiceContract kullanabilirsiniz :) Aynı cs içerisinde bir den fazla Interface kullanacaksanız, o zaman tabii ki bunu da ServiceContract Attribute ile imzalamak gerekir. Öbürtürlü zaten bunu servis olarak kullanma şansımız yoktur.
Data Contract (Veri Sözleşmesi): CLR tiplerinin serileştirilmesi için, bu tiplerin DataContract sözleşmesi ve DataMember, EnumMember ile tanımlanması gerektiği önerilmektedir. Ancak böyle bir zorunluluk ta söz konusu değildir. Bugün'e kadar geliştirdiğiniz ve kullandığınız sınıfları, bir servis olarak direk kullanabileceğiniz gibi, DataContrat sözleşmesi ile standartlara uygun hale getirip de çok rahat kullanabilirsiniz.
Fault Contract (Hata Sözleşmeleri): Geliştirdiğimiz bütün uygulamalarda hataları göz önene almamız ve projeyi buna göre test etmememiz gerekir. Windows Communication Foundation'da hata bildirimleri SOAP Fault Message'larından gelmektedir. Bu gibi durumlarda kulanılması gereken sözleşme tipi FaultContract'tır.
Message Contract (Mesaj Sözleşmesi): Servislerin mesajlar ile etkileşimde bulunmasını sağlayan sözleşme çeşididir. Mesaj bildirimlerini içermekte, ve SOAP mesaj biçimlendirilmesi için kullanılır. SOAP mesajları biliyorsunuz Header ve Body olmak üzer iki parçadan oluşur. MessageCOntract ile imzalanan bir sınıf, MessageBOdyMember ve MessageHeader ile çok basit bir şekilde kullanılır.
Sözleşmelerin hepsi ile ilgili "özellikle Fault ve Mesage" daha sonradan örnekleri yapacağım ;)
G.G.S sersini bu yazı ile bitirip, WCF detaylarını anlatan makalelerim ve, Data Access olarak adlandırılan EF ve Linq Providerları ile custom sınıflar üzerinden yazılarıma devam edeceğim.
Bu yazılara kendi kategorilerinden ulaşabilirsiniz ;)
