Oracle DB ‘de Türkçe Karaktere Göre Sorgulama Problemleri

Oracle'ın Ulusal Dil Desteği (National Language Support-NLS) mimarisi, veri tabanı sorgulamalarında bölgesel dillere has karşılaşılan problemlere çözümler sağlamakta, tüm veritabansal işlemleri yaparken anadile, yerel ayarlara adapte olunmasını sağlamaktadır.

İki yöntemle yerel dile göre sorgu işlemleri yapılabilir.

a)    Aktif session(oturum) için tanımlama yapılarak;

ALTER SESSION SET NLS_COMP=LINGUISTIC;

ALTER SESSION SET NLS_LANGUAGE=’TURKISH’;

ALTER SESSION SET NLS_SORT='XTURKISH';

ile sorgulama yapılan aktif sessionda karşılaştırma, uyarı ve sıralama işlemleri için dili ayarını Türkçe olarak belirlemiş oluruz. NLS_LANGUAGE veritabanının varsayılan dilini    belirtir.

      b) Linguistic(Dilbilimsel) olarak herhangi bir sessionda yapılan sorgulamada, sorgulama anında dinamik olarak dil parametresi belirtilerek; 

NLSSORT ‘un Türkçe karakterler için kullanımı ve genel argümanları aşağıdaki gibidir.

Kullanımı:

NLSSORT(SUTUN_ADI , ´NLS_SORT_XTURKISH´)

ile türkçe karakterilerin sorgunun en sonunda (ASC) ya da en başında (DESC) yer almasını önleyebiliriz.

Söz dizimi:

NLSSORT(char [, 'NLS_SORT = sort[_ai |_ci]' ])

Argümanlar:

char : Sıralanacak bir text ifadesidir.

Sort : Sorguda, Native Language Support olarak tercih edilen olan dildir.

_ai   : Şive, aksan, vurgu duyarsız sorgulama olduğunu belirtir.

_ci   : Harf duyarsız sorgulama olduğunu belirtir.

Örnek datanın hazırlanması;

CREATE TABLE PERSON (ID NUMBER NOT NULL,NAME VARCHAR2(25 BYTE) NOT NULL);

INSERT INTO PERSON(ID,NAME) VALUES(1,'Çağdaş');

INSERT INTO PERSON(ID,NAME) VALUES(2,'İsmail');

INSERT INTO PERSON(ID,NAME) VALUES(3,'Şeyma');

INSERT INTO PERSON(ID,NAME) VALUES(4,'Arif');

INSERT INTO PERSON(ID,NAME) VALUES(5,'Muhammed');

INSERT INTO PERSON(ID,NAME) VALUES(6,'Eymen');

Dil ayarı İngilizce iken;

Sorgu:

SELECT ID,NAME FROM PERSON ORDER BY NAME;

Çıktı:

ID        NAME

4          Arif

6          Eymen

5          Muhammed

1          Çağdaş

2          İsmail

3          Şeyma

Dil ayarı Türkçe olarak belirtilerek sorgulandığında;

Sorgu:

Aşağıdaki üç sorgu şekli de Türkçe karakterlere göre kayıtları sıralama işlemini yapar. Üç sorgunun da çıktısı aynıdır.

SELECT ID,NAME FROM PERSON ORDER BY NLSSORT(NAME,'NLS_SORT=TURKISH');

SELECT ID,NAME FROM PERSON ORDER BY NLSSORT(NAME,'NLS_SORT=XTURKISH') ASC;

SELECT ID,NAME FROM PERSON ORDER BY NLSSORT(NAME,'NLS_LANG=TR');

Çıktı:

ID        NAME

4          Arif

1          Çağdaş

6          Eymen

2          İsmail

5          Muhammed

3          Şeyma

Türkçe karakterleri bozmadan büyük harfe çevirme işlemi için NLS_UPPER kullanılmalıdır;

Kullanımı :

NLS_UPPER(ALAN_ADI, 'NLS_SORT=XTURKISH')

Örnek:

SELECT ID, NLS_UPPER(NAME, 'NLS_SORT = XTURKISH') "UPPER_NAME" FROM PERSON  ORDER BY NLSSORT(NAME,'NLS_SORT=XTURKISH') ASC;

Çıktı:

ID        UPPER_NAME

4          ARİF

1          ÇAĞDAŞ

6          EYMEN

2          İSMAİL

5          MUHAMMED

3          ŞEYMA

Türkçe karakterleri bozmadan küçük harfe çevirme işlemi için  ise NLS_LOWER kullanılmalıdır;

Kullanımı:

NLS_LOWER(ALAN_ADI, 'NLS_SORT=XTURKISH')

Örnek:

SELECT ID, NLS_LOWER(NAME, 'NLS_SORT = XTURKISH') "LOWER_NAME" FROM PERSON  ORDER BY NLSSORT(NAME,'NLS_SORT=XTURKISH') ASC;

Çıktı:

ID        LOWER_NAME

4          arif

1          çağdaş

6          eymen

2          ismail

5          muhammed

3          şeyma

Arama opsiyonlarının olduğu sorgulamalarda da UPPER ve LOWER opsiyonları kullanılabilir;

Örnek:

Türkçe karakterle başlayan yeni bir data ekleyip, iki farklı türde sorgulama yapıp aynı sonucu alıyoruz;

INSERT INTO PERSON(ID,NAME) VALUES(7,'İhsan');

SELECT ID,NAME FROM PERSON WHERE NLS_UPPER(NAME, 'NLS_SORT = XTURKISH') like '%İ%' ORDER BY NLSSORT(NAME,'NLS_SORT=BINARY_AI');

SELECT ID,NAME FROM PERSON WHERE NLS_LOWER(NAME, 'NLS_SORT = XTURKISH') like '%i%' ORDER BY NLSSORT(NAME,'NLS_SORT=BINARY_CI');

Çıktı:

ID        NAME

4          Arif

7          İhsan

2          İsmail

Kaynaklar:

• http://docs.oracle.com/cd/B13789_01/server.101/b10759/functions090.htm
• http://docs.oracle.com/cd/B28359_01/olap.111/b28126/dml_functions_2038.htm
• http://docs.oracle.com/cd/B14117_01/server.101/b10759/functions088.htm

COM, DCOM, CORBA, OLE ile Dağıtık Programlama

Yazılım Bileşenlerinin , Nesnelerinin Ortak ve Dağıtık Olarak Kullanılması:

Nesneye Yönelik programlama(NYP) yaklaşımı ile oluşturulan nesnelerin, mimari sınırları ve ağ yapılarını aşan ,aynı ve çapraz adres evrenlerinde etkileşimi sağlayan standart bir alt yapıya sahip olmayışları,  NYP yaklaşımının değerini yitirmeye başlamasına sebep olmuştur. Oluşturulan bu nesneler arasında etkileşimin olmayışı insanları yeni teknoloji arayışlarına itmiştir. Bu arayışın sonucunda nesneler arası etkileşimi sağlayan,uygulama geliştiricilere oluşturulan paket bileşenlerinin tekrar ve her ortamda kullanılması olanağı veren COM(Component Object Model) teknolojisi ortaya çıkmıştır. COM teknolojisiyle uygulama geliştiriciler kendi fonksiyonlarını yazılım bileşenleriyle bütünleştirerek kullanabilmişlerdir. Bu durum sonucunda yazılımı oluşturacak bileşenler hazır paketler halinde alınarak yazılım geliştirilmeye başlanmıştır. Böylelikle uygulama geliştiriciler, uygulama bileşenlerini kendileri oluşturmadan hazır halde aldıkları ve her uygulamada sorunsuz kullanabildikleri için geliştirme zamanından da kazanç sağlamış oldular. Bu teknolojinin yaratılmasının arkasında bulunan düşüncelerden biri de yazılım bileşenlerinin en az iş gücü ile en verimli biçimde yeniden kullanılabilmesidir. Bu tanım bir yazılım geliştirici için daha önceden yazılmış olan bir kodun tekrar yazılmaması, bir IT yöneticisi için ise bu kodun tekrar yazılmasından kaynaklanan maliyet ve zamandan tasarruf demektir.

Yeni ihtiyaçlar doğdukça farklı teknoloji arayışları da sürmüştür. COM, ilk ortaya çıktığında aynı makine üzerinde çalışan uygulamalar arasında etkileşim sağlanabiliyordu. Dolayısıyla,COM teknolojisi de bu ihtiyaç çerçevesinde geliştirilmiş bir teknoloji olmuştur. Uygulamaların birbirleriyle etkileşimi için ise aynı makine üzerinde çalışıyor olmaları kısıtını ortadan kaldırmak amacıyla yeni çalışmalar yapılmış ve 1991 yılında IBM,Sun Microsystem gibi bazı şirketlerin de desteklediği Omg(The Object Management Group) tarafından CORBA(Common Object Request Broker Architecture) mimarisi geliştirilmiştir.Geliştirilen diğer bir mimari ise Microsoft’un geliştirdiği DCOM(Distributed Component Object Model) olmuştur.Bu mimari, COM teknolojisinin gelişmişi olarak ağ üzerinde değişik makinelerdeki nesneler arası iletişim kurmayı hedefleyen bir mimari olarak geliştirilmiştir. Bu teknolojilerde en önemli olan noktalardan biri de, bu uygulamaların farklı dillerde yazılmış olduklarında ve hatta farklı bilgisayarlar üzerinde bulunan farklı işletim sistemleri üzerinde çalışıyor olmaları durumunda bile bu component veya nesneler arası iletişimin başarıyla sağlanması olmuştur.

COM (Component Object Model-Bileşen Nesne Modeli):

Yazılım bileşenleri için, yeni bileşenler oluşturmak veya var olan bileşenleri uygulama programları veya başka bileşenler içerisinden kullanmak için Microsoft Firması tarafından 1993 yılında tanımlanmış bir Binary-Interface(BI) standardıdır. Bu standart ; Bileşen Nesne Modeli, nesnelerin yaratılması ve istemci-nesne arasındaki bağlantıyı standart mekanizmalar şeklinde tanımlamıştır. Bu mekanizmalar, bilinen Nesneye Yönelik programlama ortamından farklı olarak uygulamalardan ve bu uygulamaların oluşturulduğu dilden bağımsızdır. Bileşen Nesne Modeli’nin işletim sisteminden,donanım ortamından, uygulama dilinden bağımsız olması İkili Yapı Standardı(BI) ile sağlanmıştır.Ağ ortamında da kullanılan bu yapı mimariden bağımsız bir iletişim ve protokol yapısı ile farklı ortamlarda oluşturulan nesnelerin birbirleriyle etkileşimini sağlamaktadır. Bu yapı kullanıldığı sürece, nesneler birbirlerinin gerçekleştirimine bakmadan sadece nasıl bağlantı kurulacağı ve verinin nasıl aktarılacağını bilerek birbirleriyle etkileşim içinde olabilirler. Bu yapıyı kullanan metotlardan oluşan arayüz (yazılım bileşenlerinin anlaşmalarını sağlayan işlemler kümesi ) COM içeriğinde tanımlanarak yazılımlara sağlanmıştır. Her arayüz(interface) yazılımlar için ortak özelliklere sahip bir bağlantı noktası konumundadır. Uygulama geliştiriciler bu bağlantı yapılarını özelleştirerek kendi nesne yapılarını oluştururlar.

COM genel olarak karmaşık uygulamaların farklı ortamlardaki uygulamalarla etkileşim sorununu çözmek için yeni bir anlayış ortaya çıkarmıştır. Bu etkileşim sorunu çözülünce, COM teknolojisi uygulama geliştiriciler tarafından oluşturulmuş olan nesnelerin yeniden kullanılabilirliğini sağlamıştır. Yeniden kullanabilirlik, uygulama geliştiricilere sistem oluşturmada kolaylık sağlayan ve bu şekilde oluşturulmuş farklı kuruluşların sistem bileşenlerinin standart bir yapıyı kullanarak birbirleriyle iletişim kurmasına olanak veren önemli bir özelliktir. Temel olarak aynı yapıya sahip COM teknolojisini kullanabilen nesnelerin, bu yapıya uygun özelliklerinin fazla esnek olmaması, sistem bakımını ve nesnelerin farklı COM yapısını kullanan ortamlara uyum sağlamasını kolaylaştırır. COM teknolojisi,uygulama geliştiricilere standart bir uygulama geliştirme arayüzü tanımlamıştır. Bu arayüzle uygulama geliştiricilerin COM yapısını kullanabilen nesneler oluşturması ve bu nesneleri özel uygulamalarda kullanarak değişik uygulamalardaki nesnelerle etkileşim sağlayabilmesine olanak verilmesi hedeflenmiştir.

 Şekil 1 : COM(Component Object Model) in evrimsel gelişimi.

DCOM(Distributed Component Object Model- Dağıtık Bileşen Nesne Modeli):

DCOM, Bileşen Nesne Modelinin(COM) bir uzantısıdır. Microsoft tarafından bilgisayarlar arasında dağıtılmış uygulamaların daha rahat oluşturulabilmesi ve çalışabilmesi için yazılmıştır. COM’un ağ üzerinde farklı bilgisayarlarda bulunan bileşenlerin iletişim kurmasını sağlamak üzere geliştirilmiş sürümüdür. COM aynı makinedeki farklı görevlere istemcinin erişmesine olanak verirken, farklı makinelerde haberleşmeyi sağlayamaz. İstemci görev ve bileşenler ayrı makinelerde olduğu zaman DCOM yerel Inter-process haberleşmesini ağ protokolü ile sağlar. DCOM’un sağladığı altyapı ile uygulamalar ağ üzerinde dağıtılabilir. DCOM ile bileşenin bulunduğu yer bilgisi istemciden gizlenir. Bu sayede istemci bileşenin türü ne olursa olsun bileşene bağlanmak için aynı kodu kullanır. DCOM, COM programlama modeline yerden bağımsızlık, yeni güvenlik mekanizmaları, bileşen yönetimi ve bellek yönetimi konularında ilave yetenekler getirmektedir. COM ile istemci uygulamaları sunucunun paketleme türü ne olursa olsun aynı programlama modelini kullanmaktadır. COM nesneleri istemci prosesi içerisine yüklenebileceği gibi aynı makine üzerinde farklı bir proses olarak da yüklenebilir. DCOM bu konum saydamlığı özelliğini daha da genişleterek bileşenlerin ağ üzerinde herhangi bir bilgisayarda olmasını olanaklı kılmaktadır.

DCOM Microsoft IDL(MIDL- Microsoft Interface Defination Language ) olarak bilinen ikili arayüzlerin tanımlandığı bir tablo kullanmaktadır. Her arayüz(interface) 128 bitlik uniq bir belirtece sahiptir.(Interface Identifier-IID) DCOM nesneleri bir sınıfın örneği olarak yaratılır. Bu nedenle aslında DCOM sınıf nesneleri olarak da tanımlanabilir. Bütün nesneler standart bir nesne arayüzü uygularlar. Bir nesne yaratıldığı zaman sınıf nesnesi bu arayüze bir gösterge döndürür. Ayrıca her nesne sınıfının da kendine ait uniq referansı vardır(CLSID). İstemci taraf için nesneler üzerinde kendi adres alanındaymış gibi işlem yapılır. Yani; istemci taraf başka bir makinede işlem yapıldığını anlamaz. Çağrılan yöntemler ve kullanılan nesne bileşenleri sanki kendi adres alanındaymış gibi işlem yapar. DCOM’ da istemcinin yeniden çağrılan bir nesneye referansı bir arayüz göstergesidir. İstemci bu arayüz göstergesini referans gösterilen arayüzde metot çağırmada kullanır. İki görev arasında iletişim bu göstergeler sayesinde olur. Bir göstergeyle işlem yapmak demek aslında o göstergenin ait olduğu arayüzün uniq olan IID(Interface Identifier)’ si ile işlem yapmak anlamına gelir.

Şekil 2 : Görev yönünden DCOM şeması

DCOM da, COM’un devamı olarak dilden bağımsızdır. DCOM bileşenleri her dilde oluşturulabilir ve oluşturulan bileşenler farklı dillerde ve araçlarda da kullanılabilir. Dil bağımsızlığı sayesinde geliştiriciler kendi dilleriyle gerçekleştirim yapabilir, yeni bir dil öğrenmek zorunda kalmazlar. C++, Microsoft VJ++, Object Pascal (Delphi), Visual Basic ve Cobol gibi dillerle DCOM bileşenleri geliştirilebilir. Ancak yine de dil bağımsızlığında bazı kısıtlamalar vardır. Örneğin, DCOM Java’nın sadece Microsoft tarafından geliştirilmişiyle çalışır.

DCOM; TCP/IP, UDP IPX/SPX ve NETBIOS gibi birçok iletişim protokolüyle çalışabilmektedir. Böylelikle uygulamanın belirli bir platforma bağlı kalması önlenir. DCOM bu protokollerin hepsinde güvenlik iskeleti sağlamaktadır.

CORBA (Common Object Request Broker Architecture-Ortak Nesne İstem Aracısı Mimarisi) :

CORBA, OMG (Object Management Group-Nesne Yönetim Grubu) tarafından geliştirilmiş dağıtık nesne mimarisi standardıdır. Nesne Yönetim Grubunun, Nesne Yönetim Mimarisi‘nin (OMA-Object Management Architecture) ana bileşenlerinden birisidir. OMG, bilgisayar endüstrisinde yer alan 800’den fazla kuruluş tarafından desteklenen bir çalışma grubudur. Microsoft, söz konusu destekçi kuruluşlar arasında bulunmamaktadır. Bunun nedeni Microsoft’un DCOM (Dağıtık Bileşen Nesne Modeli) adında kendine özgü dağıtık nesne mimarisini geliştirmiş olmasıdır.

Nesne Yönetim Mimarisi Nesne Modeli ve Referans Modelinden oluşur. Nesne Modeli heterojen bir ortamda dağılmış nesnelerin nasıl tanımlanabileceğini belirler. Referans Modeli ise nesneler arası etkileşimleri tanımlar. Dolayısıyla Nesne Yönetim Mimarisi heterojen ortamlara dağılmış beraber işleyebilen dağıtık nesnelerin geliştirilmesine yardımcı olur. CORBA sayesinde programcılar kullandıkları nesnelerin hangi dilde yazıldığına, dağıtık olup olmadıklarına, işletim sistemlerine ve iletişim protokollerine bakmaksızın yazılım uygulamalarını geliştirebilirler. Dağıtık nesnelerin istemci ve sunucu olmak üzere iki yönü vardır. İstemci ve sunucu arasındaki ilişki şöyle gerçekleşir; Sunucu, uzak bir ara yüz (remote interface) sağlar ve istemci de sağlanan uzak ara yüzü çağırır. Bu ilişki RMI ve CORBA gibi birçok dağıtık nesne standartlarında benimsenen bir yaklaşımdır. Bu bağlamda, sunucu ve istemci terimlerinden kastedilen uygulama düzeyindeki etkileşimlerden ziyade nesne düzeyindeki etkileşimlerdir. Yani bir uygulama, herhangi bir nesne için sunucu olabilirken başka bir nesnenin istemcisi olabilir.

Şekil 3 : Farklı dillerde yazılmış CORBA bileşenlerinin iletişimi

CORBA nesneleri bilgisayar ağı üzerinde herhangi bir yerde bulunabilmektedir. Uzak istemciler bu nesnelere metod çağrımları yolu ile erişebilmektedirler. İstemcilerin, sunucu nesnelerinin bilgisayar ağı üzerindeki yerini bilmesine gerek yoktur. Sunucu nesnelerinin hangi dille yazıldığı da istemciler açısından önemli değildir. Örneğin, bir sunucu nesne C++ sınıfları olarak veya uzun bir COBOL programı olarak gerçekleştirilmiş olabilir. İstemci açısından önemli olan sunucu nesnenin dışarıya sunduğu arayüzdür. Sunucu nesne arayüzünde, uzak istemcilere sunulabilecek servisler belirlenmektedir. Bu nedenle sunucu nesne arayüzü uzak istemciler ve sunucular arasında geçerli olan bir kontrata (anlaşmaya) benzetilebilir. Bir nesnenin başka bir nesneden servis isteyebilmesi için, o nesnenin dışarıya sunduğu arayüzü bilmesi gerekir. IDL (Interface Definition Language-Arayüz Tanımlama Dili), CORBA nesnelerinin arayüzlerini tanımlamak için kullanılan dildir. IDL ile yazılan arayüzlerde bulunan metod, CORBA’nın desteklediği (CORBA ile bağlanabilen) C, C++, Ada, Smalltalk, COBOL, Java dillerinde yapılabilmektedir. Diğer dillerin de desteklenmesi için çalışmalar devam etmektedir. IDL, yukarıdaki Şekil 3’de de görüldüğü gibi işletim sistemi ve programlama dilinden bağımsız arayüzler tanımlanmasını sağlayarak farklı dillerde yazılmış istemci ve sunucuların içten-işletilebilirliğine (interoperability) izin vermektedir. IDL dili, C++ dilinin bir alt kümesi olarak tasarlanmıştır. Bu alt küme, kalıtım (inheritance), aykırı durum yönetimi (exception handling) gibi özellikleri de içermektedir.

Şekil 4 : CORBA Mimarisinin Temel Elemanları

CORBA mimarisi; yukarıdaki Şekil 4 de de görüldüğü gibi dört temel elemandan oluşmaktadır. Bu elemanlar;

ORB (Object Request Broker) : Nesnelerin birbirlerinin yerini, gerçekleştirim dillerini, alt düzey iletişim mekanizmalarını bilmeden saydam (transparent) olarak birbirlerinden istekte bulunabilmelerini ve yanıtlar alabilmelerini sağlamaktadır.

CORBA servisleri (CORBA Services): CORBA servisleri, IDL ile yazılmış arayüzler biçiminde paketlenmiş sistem düzeyinde servisler topluluğudur.

CORBA’nın uygulama seviyesinde hizmetleri(CORBA Facilities): “CORBA Facilities”, uygulama nesnelerinin doğrudan kullanabileceği ve IDL ile tanımlanmış olan uygulama düzeyi çerçeveler (frameworks) topluluğudur. Gezgin etmenler (mobile agents), güvenlik duvarları (firewalls), uluslararası yapma (internationalization) “CORBA facilities” implementasyon örnekleri arasında sayılabilmektedir.

Uygulama Nesneleri : Uygulama nesneleri kullanıcıların geliştirdiği uygulamaya ilişkin nesnelerdir.

OLE (Object Linking and Embedding ) : 1990 ‘lı yıllarda Microsoft tarafından  geliştirilen özel bir teknolojidir. Kaynak nesne referansını, gömülü olarak başka nesne içerisinden çağırmamızı sağlar. Yani; kaynak dosyadaki veriler değiştiğinde hedef dosyadaki(link alınmış dosyadaki) verilerin güncellenmesi isteniyorsa, bağlantılı nesneler(OLE nesneleri) kullanılabilir. OLE nesneleri kullanıldığında özgün bilgiler kaynak dosyada depolanmış olarak kalır. Özgün veriler ile olan bağlantıları koruyabilmek için mutlaka ilgili OLE nesnesinin bulunduğu dosya, bulunulan networkte kullanılabilir olarak kalması gerekmektedir. Kaynak dosyada ki veriler değiştirildiğinde otomatik olarak güncellenerek hedef dosyada ki verilerin değiştiği görülebilir. Geliştiriciler için, OLE denetimi Uzantısı “OCX” ’tir.

Kaynaklar :

• https://en.wikipedia.org/wiki/Component_Object_Model
• http://belgeler.cs.hacettepe.edu.tr/yayinlar/eski/DCOM_20122029.pdf
• http://www.tameroz.com/content/files/complus.pdf
• http://www.slideshare.net/PeterREgli/com-13617090
• http://www.indigoo.com/dox/wsmw/1_Middleware/COM.pdf
• http://altanmesut.trakya.edu.tr/pubs/YL_tez.pdf
• Mustafa TÜRKSEVER, R. Cenk ERDUR, “Farklı Bakış Açılarından Java RMI ve CORBA’nın Karşılaştırılması” Pamukkale Üniversitesi Mühendislik Fakültesi,Mühendislik Bilimleri Dergisi,7/1 (2001) 63-69
• https://seyfullahgenc.wordpress.com/2015/05/24/dagitik-programlama-3/
• https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
•  

ESB(Enterprise Service Bus)

ESB(Enterprise Service Bus - Kurumsal Veri Yolu); SOA(Service Oriented Architecture – Servis Yönelimli Mimari) mimarisinin uygulanması(implementasyonu) için bir şablon (pattern) olarak nitelendirilebilen, çeşitli altyapısal hizmetleri sunan, bağımsız heterojen ortamlarda dahi çalışabilen, böylece bu ortamlardaki entegrasyonu kolaylaştıran bir yazılım mimarisi modelidir. JAVA tabanlı sistemlerde yaygın olarak kullanılmaktadır. Bu mimarinin ilk olarak çıkışı 2002 yılında Gartner Group ta , Roy W. Schulte ‘a atfedilir. SONIC Software de çalışan David Chappell, "The Enterprise Service Bus" isimli bir kitap ile bu mimariden bahsetmiş, ancak uzun yıllar öncesinde de bu mimarinin isimlendirilmeden kullanıldığına dair ortak bir inanç bulunmaktadır.

ESB’ler ; servisleri ve uygulamaları entegre etmek için esnek bir yapı sağlarlar. Servisler arası mesajları yönlendirirler. Servis ve isteği yapan arasında protokol dönüşümü , mesaj dönüşümü yaparlar. Farklı protokollerle mesajlaşmayı desteklerlerler. Bir protokolden diğerine dönüşümü sağlayabilirler. Sadece SOAP mesajları değil, farklı mesaj tipleriyle de çalışabilirler. (JMS, REST, XML vs.). Yani farklı platform ve sistemlerin birbirleriyle “konuşabilmelerini” sağlarlar.  ESB ile birlikte kurumlar, mevcutta var olan uygulamalar arasındaki entegrasyon yapılarını yeniden şekillendirmektedirler. Buna göre artık “Miras(Legacy)” adını verdiğimiz kurum içerisindeki eski uygulamalara, yatırım kaybı olarak bakılmamaktadır. Bu uygulamalardan modüler servisler üretilerek bir yandan uygulamalar arasındaki entegrasyon ihtiyaçları giderilirken diğer yandan servis odaklı yeni bir hizmet mantığına geçilmektedir. Artık “Peer to Peer”  olarak bilinen her uygulamanın bir diğer uygulama ile entegrasyonu yöntemi terk edilirken, bunun yerine bütün uygulamaların üzerinde yeni bir katman olarak “ESB” konumlandırılmaktadır. Genel olarak referans mimarilerden de anlaşılabileceği gibi bu yaklaşım kurum içi ve kurum dışı entegrasyon maliyetlerini son derece düşürmektedir. Yani, Entegrasyon ve toplam sahip olma maliyetlerinde tasarruf sağlamaktadır. Ayrıca ESB, servis geliştirme zamanlarını kısaltmakta, kurumsal süreç otomasyonu için altyapının oluşturulmasını, kurumda var olan uygulamaların kolayca servis haline dönüştürülmesini  ve bu servislerin kolaylıkla farklı Protokollere açılımını sağlamaktadır. (Protokoller arası geçişlilik).

Şekil 1: Farklı Yazılım Uygulamalarının, kullandığı farklı iletişim protokollerine göre birbirleri ile ESB altyapısını kullanarak nasıl haberleştiklerinin gösterimi.

Bir ESB, hizmet odaklı mimari (SOA) uygulanması için gerekli olan bağlanırlığı sağlar ve uygulamalar ile hizmetlerin bütünleştirilmesinin karmaşıklığını azaltır. Biraz daha açacak olursak; ESB’ler dağıtık Servisleri birleştirmeyi, çalıştırmayı ve yönetebilmeyi sağlarlar. Yani dağıtık çalışan, standartlara dayanan entegrasyon için kurumsal bir altyapı sunmaktadırlar. Geleneksel sistemler sıkı semantik bağlarla kurulmuştur eğer bu semantik zincirinin bir halkası kırılırsa bütün zincir kırılmış olur. Halbuki ESB’ler semantik dönüşümleri de mümkün kılmaktadırlar. Fiziksel bağlantılar soyutlaştırılır böylelikle konum bağımsızlığı kazanılır. ESB içinde iş süreçlerini uygulayabilecek yada iş mantığını uygulayabilecek araçlar, akıllı mesaj yönlendirmesinin yanında filtreleme de bulundurulabilir. Servislere Güvenlik hizmetleri sağlayabilir onları koruyabilirler. Ayrıca Hizmet Seviyesi Anlaşmalarına (SLA) dayanarak servisleri gözlemleyebilir ve alarmlar oluşturabilirler.

Bu mimari model için, firmalar tarafından yeni bir ürün kategorisi olarak ortaya çıkarak yada mevcut ürünlerin ESB özellikleri ön plana çıkarılarak ticari  ve açık kaynak kodlu çeşitli ürünler pazarlanmaktadır.

Ticari ürünler;

•       IBM WebSphere ESB

•       Microsoft BizTalk Server

•       Oracle Enterprise Service Bus (BEA Logic)

•       Progress Sonic ESB

•       Tibco Software

•       Fiorano SOA Platform

•       IONA

Açık Kaynak Kodlu(Open Source) Ürünler;

•       Apache ServiceMix

•       Progress Software FUSE (Managed adoption of Apache Service Mix)

•       NetKernel

•       Petals ESB

•       Open ESB

•       Mule

•       UltraESB

•       JBoss ESB

•       Spring Integration

Kaynaklar:

• http://www.turk-internet.com/portal/yazigoster.php?yaziid=14660
• https://en.wikipedia.org/wiki/Enterprise_service_bus
• https://soacorner.wordpress.com/2014/10/09/esb-enterprise-service-bus-nedir/
• http://samples.sainsburysebooks.co.uk/9781743332672_sample_143790.pdf

AXIS ve CXF nedir?

Apachi AXIS(Apache eXtensible Interaction System- Apachi Genişletilebilir Etkileşim Sistemi); Apachi firması tarafından geliştirilmiş, open-source, XML tabanlı Web Servis framework tür. Java ve C++ implemantasyonları vardır. Web servis uygulamalarının deploy edilmesi ve oluşturulması için çeşitli araçlar ve API(Application Interface) ‘ler barındırmaktadır. Apache Axis, developer lara birlikte çalışabilir, dağıtık bilgisayar uygulamaları geliştirebilmeyi sağlar. SOAP ve XML RPC protokollerini destekler. Yani JAX-RPC ve JAX-WS Apileri kullanarak web servislerin yönetilmesini sağlar. Ancak AXIS 2 ile beraber JAX-RS API ile RESTful protokol desteği de gelmiş bulunmaktadır.

Apachi CXF(CeltixXFire); Apachi firması tarafından “Celtix” ve “XFire” projeleri biraraya getirilerek tek bir çatı altında toplanmıştır. CXF de open-source, çok özellikli bir Web Servis framework tür. CXF, SOAP ile beraber RESTful protokolünü de desteklemektedir. Developerın JAX-WS ve JAX-RS API'lerini kullanarak etkileşimli hizmetler geliştirmelerine yardımcı olur. Ayrıca CXF ‘de Spring entegrasyonu da mümkündür. XML dışında, JSON ve CORBA data taşımaya da izin verir.

            Bunların yanı sıra alternatif olarak; JAX-RPC ve JAX-WS destekli olan Metro, JAX-RS destekli olan Jersey, RESTEasy, RESTLET, Dropwizard Web Servis frameworkleri de tercih edilebilir. Daha detaylı karşılaştırma ve kullanım seçiminizi belirleyebilmek için aşağıdaki kaynaklar kısmındaki makaleleri inceleyebilirsiniz.

Kaynaklar

• http://cxf.apache.org/
• http://axis.apache.org/axis/java/user-guide.html#Publishing_Web_Services_with_Axis
• https://en.wikipedia.org/wiki/Apache_Axis
• http://www.oracle.com/technetwork/java/webservices-136604.html
• http://resteasy.jboss.org/
• https://jersey.java.net/
• https://en.wikipedia.org/wiki/List_of_web_service_frameworks
• http://www.slideshare.net/vpgmck/survey-of-restful-web-services-frameworks
• http://www.javacodebook.com/2013/08/15/web-service-framework-comparison-2013/

REST nedir? SOAP ile arasındaki farklar nelerdir?

Web Servisler, temelde HTTP protokolünü kullanarak, platformdan bağımsız metodlar ile ortak veri formatında veri alış verişinin yapılmasını sağlayan yapılardır. REST ve SOAP;  Web Servis teknolojilerinde günümüzde çok tercih edilen veri iletişim protokolleri,yöntemleri arasında yer alır. SOAP (Simple Object Access Protocol – Basit Nesne Erişim Protokolü);  iletilen veri türünün XML olması gereken veri transfer yöntemidir. SOAP tabanlı bir web servis, WSDL(Web Services Description Language) standardında gönderilen XML verisini yorumlamak zorundadır.

REST(Representational State Transfer – Temsili Durum Transferi); iletilen verilerin türünün bilinmediği veri transfer yöntemidir. 2000 yılında HTTP spesifikasyonunun yazarlarından biri olan Roy Fielding tarafından doktora tezinin bir parçası olarak geliştirilmiştir. REST mimarisinde, işlemler resource kavramıyla yapılır. Resource URI ile tanımlanır ve bir metod tanımlaması veya bir değişken olabilir. Yani REST’te SOAP’ta olduğu gibi XML yardımıyla metodlar çağırılmaz bunun yerine o metodu çağıracak URI ‘ler ile web servise HTTP protokolüyle istek yapılır. Böylece REST için WSDL gibi bir tanımlama diline ihtiyaç kalmaz. İşlemler tamamen HTTP metodları üzerinden yapılır. Örneğin, bir web servisin metodunu SOAP ile “getUnitName” şeklinde çağırırken REST ile “/units/name/1″ URI’si ile çağırabiliriz. Ayrıca REST’in döndürdüğü veri tipinin de XML olması zorunlu değildir; JSON, XML, TXT, HTML gibi istenen veri türünde değer döndürülebilir.

REST ile HTTP metod çağrımı :

REST tabanlı web servislerde HTTP metodlarına özel anlamlar yüklenir ve böylece web servise bir HTTP isteği geldiği anda metod çalıştırılmış olur. Bu durumda HTTP metodlarının REST ile nasıl kullanılacağı önemlidir. REST’de iki tip URI vardır. Bunlardan biri Collection URI diğeri Element URI’dir.

Collection URI ; array, list gibi veri yapıları için kullanılır. Örnek kullanım şekli;

http://example.com/resources

GET: Belirtilen collection’ın URI’lerini veya detaylarını listelemede kullanılır.

PUT: Bütün bir collection’ı başka bir collection’la yer değiştirmek için kullanılır.

POST: Yeni bir collection oluşturmak için kullanılır ve yeni oluşturulan collection’ın URI’si döndürülür.

DELETE: Tüm collection’ı silmek için kullanılır.

Element URI ise değişkenler üzerinden işlem yapmak için kullanılır. Örnek kullanım şekli;

http://example.com/resources/item/17

GET: Adresi verilen nesneyi döndürmek için kullanılır.

PUT: Var olan bir nesneyi değiştirmek için veya eğer yoksa yeni bir tane oluşturmak için kullanılır.

POST: Yeni bir nesne oluşturmak için kullanılır. Her seferinde yeni bir nesne oluşturur.

DELETE: Adresi verilen nesneyi silmek için kullanılır.

REST Requesti Sonucu, Çoğunlukla Dönen HTTP Status Kodları:

200 OK: Genelde veri listeleme sonuçları 200 ile dönüş yapılır.

201 CREATED: Veri eklendiği zaman verinin kendisi ile 201 dönülür.

204 NO CONTENT: Veri silindiği zaman 204 dönülür.

400 BAD REQUEST: Genel olarak kayıt ekleme ya da güncelleme isteklerinde gönderilen veri validasyondan geçemediyse neden geçemediği hakkında bilgiyle beraber 400 HTTP Statusuyla dönülür.

403 Forbidden: Yetkiye dayalı bir işlem yapılıyorsa bu API uç noktasında işlem yapmaya çalışan kişinin bu işlemi yapmaya yetkisi yoksa 403 status kodu döner.

401 Unauthorized: Api ucunuzda bu işlemi yapmak için login olmak zorunlu ise ve API’ye istek yapan kullanıcı login değilse bu HTTP Status ile cevap verilir.

404 Not Found: Bu HTTP Status,  kullanıcının istek yaptığı URL yok ise ya da URL deki veri geçersiz ise bu hatayı alırız.

405 Method Not Allowed: Bu HTTP Statusu istek yapılan API uç noktası gönderilen metodu implemente etmemiş ise bu HTTP Statusunu alırız. Örneğin login olması için token verdiğimiz bir API ucumuz var ve bu uçta sadece POST isteğini kabul ediyor. Kullanıcı bu API URL’ine GET isteği yaparsa 405 statusu döner.

429 Too Many Requests: Bu HTTP Statusunu, saatlik ya da dakikalık kısıtlanan sınırdan fazla istek yapıldığında alırız. 

Gruplanmış Bakış Açısıyla HTTP Statusları;
Bilgilendirme – 1xx
Başarılı İşlem – 2xx
Yönlendirmek – 3xx
Kullanıcı Taraflı hata – 4xx
Server Taraflı hata – 5xx       Şeklinde ifade edebiliriz.

Örnek REST Requestleri;

GET /tickets – Ticket Listesi
GET /tickets/12 – Ticket Detayı
POST /tickets – Yeni Ticket Ekleme
PUT /tickets/12 – Ticket Güncelleme
PATCH /tickets/12 – Ticketin bir kısmını güncelleme
DELETE /tickets/12 – Ticket Silme

GET /tickets/12/messages – 12 id li ticket e bağlı mesajlar listesi
GET /tickets/12/messages/5 – 5 id li mesajın detayı
POST /tickets/12/messages – 12 id li ticket e mesaj ekleme
PUT /tickets/12/messages/5 – Mesaj güncelleme
PATCH /tickets/12/messages/5 – Mesajın belli bir kısmını güncelleme
DELETE /tickets/12/messages/5 –5 id li mesajı silme

GET /tickets?sort=-created_at&page=1 – Ticketları Eklenme tarihini büyükten küçüge sıralama işlemi ve birinci sayfa verisini getir
GET /tickets?type=1&sort=-created_at – Ticketları Eklenme tarihini büyükten küçüğe sıralama işlemi ve tipi 1 olan ticketlar
GET /tickets?fields=id,subject,customer_name,updated_at&type=1&sort=-updated_at – Sadece belli fiedleri ve tipi 1 olan son güncelleme tarihine göre büyükten küçüğe sıralama

REST ile SOAP Arasındaki Farklar;

• SOAP XML veri tipini desteklerken REST istenen veri türüyle işlem yapabilir. JSON veri tipi ile XML’den çok daha düşük boyutlarla veri tutulabildiği için REST ile daha hızlı işlem yapılabilir. Yani REST’de gelen, giden data boyutu SOAP ile karşılaştırıldığında çok ufaktır diyebiliriz.
• Ayrıca SOAP için WSDL ile tanımlama yapmak gerekirken REST için böyle bir zorunluluk yoktur. (WADL<Web Application Description Language> REST için kullanılan, WSDL’e benzer bir yapıdır fakat kullanma zorunluluğu yoktur.) Bir dile ihtiyaç duymadan HTTP metodlarıyla tasarlanabildiği için REST’i kullanması ve tasarlaması daha kolaydır.
• SOAP için birçok geliştirme aracı mevcuttur, REST için geliştirme araçlarına ihtiyaç duyulmaz, tasarlaması kolaydır.
• SOAP; XML-Scheme kullanırken REST; URI-Scheme kullanır yani metotlar için URI’ler tanımlanır.
• Her ikisi de HTTP protokolünü kullanırlar. Fakat REST için HTTP zorunluluğu varken SOAP; TCP, SMTP gibi başka protokollerle de çalışabilir.
• Test ve hata ayıklama aşaması REST için daha kolaydır. Çünkü HTTP hatalarını döndürür ve bunlar bir Tool‘a ihtiyaç duyulmadan görülebilir. SOAP için hata ayıklama araçları gerekebilir.
• REST basit HTTP GET metodunu kullandığı için Cache leme işlemi daha kolaydır. SOAP ile Cache leme yapabilmek için karmaşık XML requestleri yapılmalıdır.
• İkisi de HTTPS destekler, SOAP için WS-SECURITY adlı bir eklenti mevcuttur.
• Güvenlik açısından SOAP daha gelişmiştir çünkü hazır yapılar bulunmaktadır.
• Dokümantasyon bakımından SOAP daha gelişmiştir ve daha fazla kaynak bulunmaktadır.
• Verimlilik, ölçeklenebilirlik ve kullanıcı tarafından algılanan performans açılarından bakıldığında REST , SOAP ‘tan daha iyidir ve tercih edilir.

Kaynaklar :

• https://en.wikipedia.org/wiki/List_of_web_service_protocols
• http://www.obenplus.com/blog/rest-api-nedir-nasil-kullanilir/
• https://youtu.be/YCcAE2SCQ6k
• http://blog.matemata.com/soap-ile-rest-web-servislerin-farklari/#disqus_thread
• https://tr.wikipedia.org/wiki/REST