T.C. TRAKYA ÜNĠVERSĠTESĠ FEN BĠLĠMLERĠ ENSTĠTÜSÜ

T.C. TRAKYA ÜNĠVERSĠTESĠ FEN BĠLĠMLERĠ ENSTĠTÜSÜ DAĞITIK NESNE YÖNETĠMĠ MĠMARĠLERĠNĠN ĠNCELENMESĠ Altan MESUT Yüksek Lisans Tezi Bilgisayar Mühendisliği Anabilim Dalı DanıĢman: Yrd. Doç. Dr. Aydın CARUS EDĠRNE-2002

T.C. TRAKYA ÜNĠVERSĠTESĠ FEN BĠLĠMLERĠ ENSTĠTÜSÜ DAĞITIK NESNE YÖNETĠMĠ MĠMARĠLERĠNĠN ĠNCELENMESĠ Altan MESUT YÜKSEK LĠSANS TEZĠ BĠLGĠSAYAR MÜHENDĠSLĠĞĠ ANABĠLĠM DALI Bu tez 10/01/2002 tarihinde aģağıdaki jüri tarafından kabul edilmiģtir. Yrd. Doç. Dr. Aydın CARUS (DanıĢman) Yrd. Doç. Dr. Erdem UÇAR Yrd. Doç. Dr. ġaban AKTAġ

i ÖZET Son on yılda çıkan nesneye yönelik programlama ve dağıtık sistem teknolojileri modern yazılımları büyük ölçüde etkiledi. RPC (Remote Procedure Call Uzak Prosedür Çağrısı) gibi eski nesil istemci/sunucu mimarileri nesneye yönelik bir modele sahip değildirler. Bu mimaride istemci, sunucuya nasıl ulaşması gerektiğini ve sunucunun yerini bilmek, ve kodu eklenecek her yeni servis için değiştirilmek zorundadır. İstemci/sunucu sistem teknolojisinin gelişiminin bir sonraki basamağı, dağıtık sistem ile nesneye yönelik programlama teknolojilerinin birleşimi olan dağıtık nesne yönetimi sistemleridir. Dağıtık sistemlerin gerçek faydası, ancak karmaşık uygulamaların yeniden kullanılabilir yazılım bileşenleri kullanılarak meydana getirilmesine izin veren, dağıtık nesne yönetimi sistemlerinin kullanılması ile mümkün olacaktır. Bu çalışmanın amacı, değişik zamanlarda, farklı platformlar (işletim sistemleri & donanımlar) ve farklı programlama dilleri ile, birbirinden bağımsız olarak tasarlanmış yazılım bileşenlerinin, bir bütün olarak çalışabilmesi için kullanılan dağıtık nesne yönetimi mimarilerinden CORBA (Common Object Request Broker Architecture Genel Nesne İstek Aracı Mimarisi) ve DCOM (Distributed Component Object Model Dağıtık Bileşen Nesne Modeli) mimarilerinin incelenmesi, aralarındaki benzerlikler ve farklılıkların belirlenmesidir. Tezin giriş bölümünde, monolitik sistemlerden istemci/sunucu mimarilerine, ve daha sonrasında dağıtık mimarilere kadar olan gelişim kısaca açıklanmıştır. İkinci ve üçüncü bölümlerde, CORBA ve COM/DCOM mimarileri incelenmiş ve dördüncü bölümde bu iki mimarinin yapısal olarak karşılaştırılması, temel programlama mimarisi, erişim mimarisi ve tel mimarisi olmak üzere üç ayrı katmanda, iki boyutlu tamsayılar üzerinde çalışan Grid adında bir uygulama kullanılarak gerçekleştirilmiştir. Tezin son bölümünde karşılaştırmanın özeti yer almaktadır.

ii ABSTRACT The object-oriented programming and distributed computing techniques made significant impact on modern software development over the past ten years. Older generation client/server architectures, such as RPC (Remote Procedure Call), do not have an objectoriented model. In these architectures, the client must be aware of where the server is located and how to access the server, and its code must be modified to make use of new services that become available. The next step in the evolution of the client/server architecture is the distributed object management systems, which is the union of object-oriented programming and distributed computing. The significant promise of this technology is that it enables construction of complex applications from reusable software components. The purpose of this thesis is to study CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model) distributed object management architectures, which provide interoperability of software components possibly designed at different times, written in different programming languages and worked in different platforms (hardware & operating systems). The introductory first chapter includes a survey of the monolitic systems, the client/server architecture and its evolution, and distributed systems. The second and third chapters describe the CORBA and COM/DCOM architectures, respectively. The fourth chapter includes architectural comparison of DCOM and CORBA at three different layers: basic programming architecture, remoting architecture, and the wire protocol architecture, by using Grid, a program which performs computations on a two-dimensional grid of integers. The final chapter involves a summary of the thesis, and conclusions.

iii TEġEKKÜR Bu önemli konuda çalışmamı sağlayan, bana yol gösteren, destek ve yardımlarını benden esirgemeyen danışman hocam Yrd. Doç. Dr. Aydın CARUS a, konu hakkındaki bilgisinden yararlandığım Dr. Bülent KÜÇÜK e ve çalışabilmem için gerekli ortamın yaratılmasını sağlayan ve tüm yoğun zamanlarımda anlayışlı davranan çalışma arkadaşlarıma ve aileme teşekkürlerimi sunarım.

ĠÇĠNDEKĠLER 1. GĠRĠġ... 1 1.1. BaĢlangıç: Monolitik Sistemler ve Mainframeler... 1 1.2. Devrim: Ġstemci/Sunucu Mimarisi... 2 1.3. Evrim: Çok Parçalı Ġstemci/Sunucu... 3 1.4. Yeni Nesil: Dağıtık Sistemler... 4 1.4.1. Soket Programlama... 5 1.4.2. RPC - Remote Procedure Call... 6 1.4.3. DCE Distributed Computing Environment... 6 1.4.4. CORBA Common Object Request Broker Architecture... 6 1.4.5. DCOM Microsoft Distributed Component Object Model... 7 1.4.6. RMI Java Remote Method Invocation... 7 2. CORBA... 8 2.1. OMA Object Management Architecture... 9 2.1.1. ORB... 9 2.1.2. CORBA Servisleri (CORBA Services)... 9 2.1.3. Dikey & Yatay CORBA Vasıtaları (Horizontal & Vertical CORBA Facilities)... 10 2.1.4. Uygulama Nesneleri (Application Objects)... 10 2.2. Bir ORB nin (Object Request Broker) Yapısı... 10 2.2.1. Object Request Broker (ORB)... 14 2.2.2. İstemciler... 15 2.2.3. Nesne Yürütmeleri... 15 2.2.4. Nesne Referansları... 16 2.2.5. OMG Arayüz Tanımlama Dili (IDL Interface Definition Language)... 16 2.2.6. Programlama Dilleri ile OMG IDL nin Eşlenmesi... 16 2.2.7. İstemci Stub ları... 17 2.2.8. Dinamik Çağrı Arayüzü (DII Dynamic Invocation Interface)... 17 2.2.9. Yürütme İskeleti... 18 2.2.10. Dinamik İskelet Arayüzü (DSI Dynamic Skeleton Interface)... 18 2.2.11. Nesne Adaptörleri... 18 2.2.12. ORB Arayüzü... 19 2.2.13. Arayüz Ambarı... 19

2.2.14. Yürütme Ambarı... 19 2.3. Örnek ORB ler... 20 2.3.1. İstemci- ve Yürütme-Yerleşik ORB... 20 2.3.2. Sunucu-tabanlı ORB... 20 2.3.3. Sistem-tabanlı ORB... 20 2.3.4. Kütüphane-tabanlı ORB... 21 2.4. Bir Ġstemcinin Yapısı... 21 2.5. Bir Nesne Yürütmesinin Yapısı... 22 2.6. Bir Nesne Adaptörünün Yapısı... 23 2.7. CORBA ya Ġhtiyaç Duyan Nesne Adaptörü... 25 2.7.1. Taşınabilir Nesne Adaptörü (POA Portable Object Adapter)... 25 2.8. Yabancı Nesne Sistemlerinin Entegrasyonu... 26 2.9. Arayüz Tanımlama Dili (IDL)... 27 2.9.1. Gömülü Tipler (Built-in Types)... 28 2.9.2. Yapısal Tipler (Constructed Types)... 28 2.9.3. Şablon Tipler (Template Types)... 28 2.9.4. Nesne Referans Tipleri (Object Reference Types)... 29 2.9.5. Arayüz Miras Alma (Interface Inheritence)... 29 2.10. Dil EĢlemeleri... 31 2.11. Arayüz Ambarı... 32 2.12. CORBA nın Bugünü ve Yarını... 33 2.12.1 MDA Model Driven Architecture... 33 2.12.1.1 UML Unified Modeling Language... 34 2.12.1.2. MOF Meta-Object Facility... 34 2.12.1.3 CWM Common Warehouse Meta-model... 34 2.12.2 CORBA 3... 34 2.12.2.1 Java ve Internet Entegrasyonu... 34 2.12.2.2 Servis Kalitesi Kontrolü... 35 2.12.2.3 CORBAcomponents Mimarisi... 35 5.12.3. CORBA Yürütmeleri... 36 3. DCOM... 38 3.1. COM Component Object Model... 38 3.1.1. Arayüzler... 38

3.1.2. Sınıflar ve Sunucular... 39 3.1.3. Nesne Yaşam Döngüsü... 41 3.1.4. İkili Birlikte Çalışabilirlik (Binary Interoperability)... 42 3.1.5. Paketleme Şeffaflığı... 43 3.2. DCOM Distributed Component Object Model... 43 3.2.1. Yer ve Paketleme Şeffaflığı... 44 3.2.2. Serbest Threading Modeli... 46 3.2.3. Güvenlik... 46 3.2.4. Referans Sayımı ve Ping Gönderme... 47 3.2.5. Yönetim... 48 3.3. MIDL Microsoft Interface Definition Language... 48 3.3.1. Tip Kütüphanesi... 49 3.3.2. Bir Arayüzün Karakteristik Özellikleri... 49 3.3.3. MIDL Derleyicisi... 49 3.3.4. Tip Tanımları, Yapı Bildirimleri, ve Import... 50 3.3.4.1. Bildirilebilen Yapılar... 50 3.3.4.2. Sabit Bildirimi (Constant Declaration)... 51 3.3.4.3. Genel Bildirim (General Declaration)... 51 3.3.4.4. Fonksiyon Bildirimi (Function Declaration)... 51 3.3.4.5. Örnekler... 51 3.3.5. IDL Nitelikleri (IDL Attributes)... 52 3.3.5.1. Dönüştürme ve Örtüşme Nitelikleri... 52 3.3.5.2. Asenkron Nitelikler... 52 3.3.5.3. Dizi ve Boyutlu-İşaretçi Nitelikleri... 53 3.3.5.4. Veri Tipi Nitelikleri... 55 3.3.5.5. Yönlendirici Nitelikler... 56 3.3.5.6. Fonksiyon Çağrım Nitelikleri... 56 3.3.5.7. Arayüz Başlık Nitelikleri... 57 3.3.5.8. Performans Nitelikleri... 57 3.3.5.9. İşaretçi Tipi Nitelikleri... 58 3.3.5.10. Struct ve Union Nitelikleri... 58 3.3.5.11. Tip Kütüphanesi Nitelikleri... 59 3.3.6. MIDL Veri Tipleri... 61 3.3.6.1. Ön-tanımlı ve Temel Tipler... 61

3.3.6.2. İşaretli ve İşaretsiz Tipler... 62 3.3.6.3. Diğer MIDL Veri Tipleri... 62 3.3.7. MIDL Dizileri... 62 3.3.7.1. İşaretçilerin Dizileri... 63 3.3.8. Yapılar (Structures) ve Birleşimler (Unions)... 64 3.3.8.1. Korunmuş Birleşimler (Encapsulated Unions)... 64 3.3.8.2. Korunmamış Birleşimler (Nonencapsulated Unions)... 65 3.3.9. Bağlı İşleyiciler (Binding Handles)... 65 3.4. DCOM un Bugünü ve Yarını... 66 3.4.1. COM+... 67 3.4.2..NET... 67 4. CORBA - DCOM KARġILAġTIRMASI... 69 4.1. Örnek Uygulama... 71 4.2. Üst Katman: Temel Programlama Mimarisi... 77 4.3. Ara Katman: EriĢim Mimarisi... 80 4.4. Alt Katman: Tel Protokol Mimarisi... 84 5. SONUÇLAR... 89 KAYNAKLAR... 91 ÖZGEÇMĠġ... 92 EKLER... 93 EK-1 TERĠMLER... 93 EK-2 KISALTMALAR... 94 EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ... 95

1 1. GĠRĠġ Bilgisayarlar arası haberleşmeye ihtiyaç duyulduğu andan itibaren, çözüm için çeşitli yöntemler geliştirilmiştir. Dağıtık sistemler, günümüze kadar bu isimle değil de farklı isimlerle anılmış olmalarına rağmen, bilgisayarlar arası haberleşmenin tarihinde daima varolmuşlardır. Esas konumuz olan Dağıtık Nesne Yönetimi Mimarileri ne girmeden önce dağıtık sistemlerin günümüze kadar geçirdiği evrimleri incelemekte fayda vardır. 1.1. BaĢlangıç: Monolitik Sistemler ve Mainframeler Mainframe ler bilgisayarlar arası haberleşmenin tarihinde başlangıç noktasını teşkil etmektedirler. Mainframe ler ile birlikte hiyerarşik veritabani sistemleri ve yeşil ekranlar olarak ta bilinen aptal terminaller kullanılmaya başlanmıştır. Bir mainframe sistemi, bakımının yapılması oldukça zahmetli olmasına rağmen, bir çok kullanıcıya hizmet verebilme ve tek bir noktadan yönetilebilme (ki bunun avantaj mı dezavantaj mı olduğu kişinin bakış açısına göre değişebilir) gibi özelliklere sahiptir. Mainframe ler için geliştirilen yazılımlar genellikle monolitik yazılımlardır. Bunun anlamı; kullanıcı arayüzü, iş kuralları ve veri erişimi fonksiyonelliği, oldukça büyük tek bir uygulamanın içinde bulunur. Aptal terminaller kendileri işlem yapmayıp mainframe leri kullandıkları için, uygulamanın tamamı mainframe de çalışır. Monolitik mimariyi gerekli kılan şey de budur. Tipik bir monolitik uygulama mimarisi ġekil 1.1. de gösterilmiştir. Mainframe Uygulama İş Kuralları Veritabanı Kullanıcı Arayüzü Terminal Terminal Terminal ġekil 1.1. Monolitik Uygulama Mimarisi

2 1.2. Devrim: Ġstemci/Sunucu Mimarisi Monolitik mimaride tüm yükün mainframe de olması kimilerine göre bir dezavantajdır. PC lerin yaygınlaşması ile kullanılmaya başlanan İstemci/Sunucu mimarisinde ise yapılacak işlemlerin bir kısmının kullanıcı tarafındaki makinelerde yapılması sağlanarak sunucu tarafındaki yük azaltılmıştır. İstemci/Sunucu mimarisinin yayılması ile birlikte, UNIX tabanlı sunucuların da kullanılmasına başlanmıştır. Bir çok uygulama yazılımı çalışabilmek için mainframe sistemlerin sahip olduğu yüksek donanım gücüne ihtiyaç duymaz. Buna ek olarak İstemci/Sunucu mimarisinde işlem yükünün bir kısmı istemci tarafında gerçekleştiğinden dolayı, UNIX tabanlı sunucuların kullanılması, mainframe lerin kullanılmasından daha ucuza mal olacaktır. Bu da bütçesi sınırlı şirketler için ideal bir çalışma ortamı oluşturmaktadır. İstemci/Sunucu mimarisinin başka bir avantajı da, bir şirket içinde farklı departmanların kendilerine ait farklı sunucuları olmasına imkan tanımasıdır. Bu sayede belirli bir departmanda çalışan bir işçi, kendi bölümüne özel bir bilgiye erişmek istiyorsa, mainframe sistemlerde olduğu gibi büyük bir uygulama içinde istediğine ulaşmayı beklemek yerine, kendi departmanındaki sunucuya erişerek ihtiyacı olan bilgiye daha kısa yoldan ulaşabilir. Ayrıca, mainframe sistemlerdeki terminaller sadece mainframe üzerindeki uygulamaları çalıştırabilirken, bir PC sunucusuna bağımlı değildir. Ondan bağımsız olarak kendisinde yüklü olan değişik uygulamaları da çalıştırabilir. İstemci/Sunucu mimarisi tipik olarak uygulamanın bileşenlerini ayırır. Buna göre veritabanı sunucu tarafında, kullanıcı arayüzü istemci tarafında, iş kuralları da ya sunucu ya da istemci tarafında yer almaktadır. Ancak istemci bileşeninin parçalarında değişiklik olduğunda, istemci bileşeninin yeni kopyalarının (genellikle çalıştırılabilir dosyalar) diğer kullanıcılara dağıtılması gerekir. Çok parçalı İstemci/Sunucu mimarisinin kullanılmaya başlanması ile birlikte, orijinal İstemci/Sunucu mimarisi artık iki parçalı istemci/sunucu (two-tier client/server) olarak adlandırılmaya başlanmıştır. İki parçalı istemci/sunucu mimarisi ġekil 1.2 de gösterilmiştir.

3 Sunucu Uygulama İş Kuralları Veritabanı Başka Sunucular İş Kuralları İstemci Kullanıcı Arayüzü İstemci ġekil 1.2. İki Parçalı İstemci/Sunucu Mimarisi 1.3. Evrim: Çok Parçalı Ġstemci/Sunucu Mainframe sistemlerden İstemci/Sunucu sistemlerine geçmek her ne kadar bir devrim sayılsa da, bu devrimin hataları da yok değildir. Örneğin, veritabanı erişim fonksiyonelliği (gömülü veritabanı sorguları gibi) istemci tarafında bulunan uygulama bileşenlerinin değişmesi sonucunda, uygulamayı kullanan tüm kullanıcılara yeni bir istemci tanıtımı yapılması gereklidir. Bu da istemci tarafında sık sık değişiklik yapılmasına neden olur ki bu da istenen bir durum değildir. Her ne kadar bir uygulama istenildiği kadar parçaya ayrılabilse bile en çok kullanılanı 3 parçalı mimaridir. Bu mimariye göre sistem, Kullanıcı Arayüzü, İş Kuralları ve Veritabanı Erişim Katmanı olmak üzere üç parçaya ayrılır. Üç parçalı sistemlere bir örnek ġekil 1.3 te gösterilmiştir. Çok parçalı istemci/sunucu mimarisi iki parçalı istemci/sunucu mimarisini iki yönden geliştirmiştir: İlki, ve belki de en önemlisi, uygulamanın geri kalanında oluşan değişikliklerden istemciyi yalıtarak, uygulamanın daha dengeli olmasını sağlar. İkincisi, çalıştırılabilen bileşenler daha fazla parçalı yapıda olduklarından dolayı, bir uygulamanın yayılması sırasında, bu mimari daha çok esneklik sağlar.

4 Çok parçalı istemci/sunucu mimarisi, katmanlar arasında daha fazla yalıtım ve daha fazla ayrım sağlamasından dolayı, sistemin narinliğini azaltır. Kullanıcı arayüzü katmanı sadece iş kuralları katmanı ile haberleşebilir, veritabanı erişim katmanı ile hiçbir zaman doğrudan haberleşemez. İş kuralları katmanı bir yandan kullanıcı arayüzü katmanı ile, diğer yandan veritabanı erişim katmanı ile haberleşir. Böylece veritabanı erişim katmanında meydana gelebilecek herhangi bir değişiklik, kullanıcı arayüzü katmanını etkilemeyecektir çünkü bu iki katman birbirlerinden yalıtılmıştır. Sunucu Uygulama Veritabanı İş Kuralları Kullanıcı Arayüzü Başka Sunucular İstemci Kullanıcı Arayüzü İstemci Kullanıcı Arayüzü ġekil 1.3. Üç Parçalı İstemci/Sunucu Mimarisi 1.4. Yeni Nesil: Dağıtık Sistemler Uygulama mimarilerinin evrimindeki bir sonraki mantıksal basamak, çok parçalı istemci/sunucu mimarisinden yola çıkılarak oluşturulan dağıtık sistem modelidir. İş kuralları ve veri erişimini ayırmak yerine, dağıtık sistem modeli uygulamanın tüm fonksiyonelliğini nesnelere bırakır. Bu nesneler sistemdeki diğer nesneler tarafından, hatta başka sistemlerdeki nesneler tarafından sağlanan servisleri kullanabilir. Bu mimari aynı zamanda sunucu ve istemci arasındaki farkı azaltır. Öyle ki, istemci bileşenleri, sunucu vazifesi görebilen nesneler yaratabilmektedirler. Dağıtık sistem mimarisi aynı zamanda diğer mimarilere kıyasla

5 çok daha fazla esnektir. Özel bileşen arayüzlerinin (interface 1 ) tanımını teşvik ederek (veya mecbur ederek), bu esnekliği kazanır. Bir bileşenin arayüzü, diğer bileşenlere, o bileşen tarafından sunulan servisleri ve bu servislerin nasıl kullanılacağı bilgisini sunar. Buna göre bir bileşenin arayüzü değişmediği sürece, bileşenin yürütmesi diğer bileşenleri etkilemeden değişebilir. Örneğin, bir firma için müşteri bilgisi sağlayan bir bileşen bu bilgiyi ilişkisel bir veritabanında tutabilir. Daha sonra, uygulama tasarımcıları bir nesne tabanlı veritabanının daha uygun olacağına karar verebilirler. Tasarımcılar, bileşenin arayüzüne dokunmadıkları sürece, bileşenin yürütmesinde istedikleri değişiklikleri yapabilirler. Dağıtık sistemler, istemci ve sunucu sayısı çok fazla olan, çok parçalı istemci/sunucu sistemi olarak kabul edilebilir. Aralarındaki en önemli fark, dağıtık sistemlerin, uygulamanın çeşitli bileşenlerine başka servislerin erişebilmesine izin veren dizin servisleri (directory services 2 ) gibi, bir takım ek servisler sağlamasıdır. Bu başka servisler, işlerin beraberce çalışmalarına izin veren bir hareket monitörü (transaction monitor 3 ) servisi ihtiva edebilirler. Dağıtık uygulamaları tasarlayıp yürütürken, tasarımcıya değişik uygulama geliştirme ortamları sunulur. Bu seçenekler uygulamanın geliştirildiği ortamdan, yürütme için kullanılan dilinin seçimine kadar farklılıklar gösterebilir. Şimdi bu farklı ortamları kısaca inceleyelim: 1.4.1. Soket Programlama Modern sistemlerin çoğunda, makineler arasındaki ve bazen aynı makinedeki işlemler arasındaki iletişim, soketler kullanılarak yapılır. Bir soket uygulamaların kendi aralarında bağlanabilmeleri ve haberleşebilmeleri için bir kanaldır. Uygulama bileşenleri arasında haberleşmeyi sağlamak için en uygun yol soketleri direkt olarak kullanmaktır (bu soket programlama olarak bilinir). Geliştirici veriyi sokete yazar ve/veya veriyi soketten okur. 1 Arayüz, bir sistemin iki farklı bileşeni arasındaki haberleşme protokolünü tanımlar. Bu bileşenler, farklı işler, farklı nesneler, bir kullanıcı, bir uygulama, vb sistemde birbirleriyle haberleşme ihtiyacı duyan herhangi iki farklı varlık olabilir. Arayüz, bir bileşenin hangi servisleri sunduğunu, ve bu servisleri kullanmak için gerekli protokolü tanımlar. Nesne tarafından bakıldığında, arayüz, o nesne tarafından tanımlanmış, giriş ve çıkış parametreleri olan, yöntemler kümesi olarak düşünülebilir. 2 Dizin Servisini bir telefon defteri gibi düşünebiliriz. Nasıl telefon defterinde değişik isimler ve telefon numaraları tutuluyorsa, bir dizin servisi de sistemdeki nesnelerin bilgilerini grup halinde tutar, ve ihtiyaç duyulduğunda dizin servisinden bu bilgilere erişilir. 3 Hareket monitörü servisi, diğer nesneler adına işleri idare eder. Bir hareket (transaction), otomatik olarak yapılması gereken bir iş veya iş kümesidir. Harekette olan tüm nesneler hareketi ya commit (kayıt yenileme) etmeli, yada hareketi abort (hareketin oluşumundan önceki duruma dönme) etmelidirler. Hareket ister commit edilsin ister abort edilsin, içerilen tüm nesneler tutarlı bir durumda olacaklardır. Diğer nesnelere hareketbağlantılı servislerin sağlanması iş yapma monitörünün görevidir.

6 Soket Programlama da kullanılan Uygulama Programlama Arayüzü (API Application Programming Interface), oldukça düşük seviyelidir. Bu yüzden soket programlama karmaşık uygulamalar için uygun değildir. Örneğin uygulama bileşenleri farklı tipten makinelerde bulunuyorlarsa veya farklı programlama dillerinde yürütülmüşlerse, karmaşık veri tiplerini elde etmek için soket programlama uygun değildir. Direkt soket programlama çok ufak ve etkili uygulamalarda sonuç verebilir, ama genel kanı karmaşık uygulama geliştirmesi için uygun olmadığıdır. 1.4.2. RPC - Remote Procedure Call Soket programlamanın bir üst basamağı RPC dir. RPC, soket seviyesindeki iletişimlere fonksiyon-tabanlı bir arayüz sağlar. RPC kullanarak, verinin akarak bir soket oluşturmasını direkt olarak sağlamak yerine, geliştirici, C gibi fonksiyonel dillerdekine benzer şekilde bir fonksiyon tanımlayıp, bu fonksiyonun çağırana normal bir fonksiyon gibi görünmesini sağlayan bir kod oluşturur. Fonksiyon, uzaktaki bir sunucuyla (remote server) iletişim kurmak için, arka planda soketleri kullanır. Fonksiyon-tabanlı bir arayüz sağladığı için, RPC yi kullanmak çoğu kez ham soket programlamayı kullanmaktan daha kolaydır. RPC aynı zamanda, birçok istemci/sunucu uygulamaları için temel oluşturabilecek kadar güçlüdür. RPC protokolünün uyumsuz birçok yürütmesi olmasına rağmen, birçok platforma uyumlu olan standart bir RPC protokolü vardır. 1.4.3. DCE Distributed Computing Environment OSF (Open Software Foundation Açık Yazılım Kuruluşu) tarafından geliştirilmiş bir yöntem olan DCE (Dağıtık Hesaplama Ortamı), daha çok dağıtık ortamlar için çeşitli standartlar tanımlamak amacıyla üretilmiştir. Bu standartları tanımlarken de RPC yi kullanmıştır. DCE standardı bir süre kullanılmış, fakat tam sonuç alınamadan yerine geçecek değişik yöntemlerin çıkması (CORBA, DCOM) sonucu, bugün çok az uygulamada kullanılmaktadır. Microsoft COM u geliştirirken, DCE RPC yi temel almıştır. 1.4.4. CORBA Common Object Request Broker Architecture OMG (Object Management Group 1 - Nesne Yönetim Grubu) tarafından geliştirilen CORBA, bileşenler arasındaki arayüzleri tanımlamak için standart bir mekanizmaya sahiptir, 1 OSF den farklı olarak, OMG gerçek yazılım üretmez, sadece ayrıntılı tanımlar üretir.

7 ve bu arayüzlerin gerçeklenmesini kolaylaştırmak için geliştiricinin seçeceği programlama dilini kullanan bazı araçlar içerir. CORBA, bir uygulamanın veya farklı uygulamaların çeşitli bileşenlerinin, kendi aralarında haberleşebilmeleri için gerekli olan tüm altyapıyı sağlar. CORBA, bilgisayar yazılım dünyasında nadir olarak sağlanabilen platform bağımsızlığı ve dil bağımsızlığı özelliklerini içerir. Platform bağımsızlığı, üzerinde CORBA ORB yürütmesi olan her türlü platform (modern işletim sistemleri) üzerinde CORBA nesnelerinin kullanılabilmesi demektir. Dil bağımsızlığı ise, CORBA nesnelerinin hemen hemen istenilen tüm programlama dillerinde gerçeklenebileceği, haberleştikleri diğer CORBA nesnelerinin hangi dili kullandıklarını bilmek zorunda olmadıkları anlamına gelir. 1.4.5. DCOM Microsoft Distributed Component Object Model 1993 yılında duyurduğu COM (Component Object Model) ile farklı sistemler üzerindeki bileşenlere erişim sağlayan Microsoft, 1996 yılında duyurduğu DCOM modeli ile de bileşenlerden oluşan ağ uygulamaları yaratmayı mümkün hale getirerek, dağıtık sistemler piyasasına giriş yapmıştır. DCOM, CORBA ile benzer imkanlara sahiptir. DCOM Microsoft işletim sistemlerine (Windows 9x, NT, 2000) entegre edilmiştir. Fakat Windows işletim sistemleri dışında seyrek kullanılır. CORBA-DCOM köprüleri sayesinde CORBA nesneleri DCOM nesneleri ile, ve DCOM nesneleri de CORBA nesneleri ile haberleşebilirler. Mevcut uyumsuzluklar nedeni ile iki sistemi uzlaştırmak zordur. Bu köprüler her ne kadar mükemmel çözüm olmasalar da, DCOM ve CORBA nesnelerinin bir arada kullanılması gerektiği durumlarda kullanışlıdırlar. 1.4.6. RMI Java Remote Method Invocation RMI, bir kaç özelliği dışında CORBA ya çok benzer. RMI nin avantajlarından biri nesneleri CORBA nın aksine referans olarak değil de değer olarak geçirmesidir. (CORBA nın 2.0 sürümünden itibaren nesnelerin değer olarak geçirilmesine destek verilmiştir.) Ancak RMI nin en büyük dezavantajı sadece Java destekli olmasıdır. Yani hem istemci hem sunucu tarafı programları tamamen Java ile yazılmış olmalıdır.

8 2. CORBA CORBA, OMG (The Object Management Group) tarafından geliştirilmiştir. OMG, Nisan 1989 da, içlerinde 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems ve Unisys Corporation ın da bulunduğu 11 şirket ortaklığında, dağıtık nesneye yönelik uygulamaların beraber çalışabilirliğini ve taşınabilirliğini sağlayan standartları oluşturmak amacıyla kurulmuştur. Şu anda 800 kadar üyesi olan konsorsiyum, yazılım endüstrisi için firma bağımsız ayrıntılı tanımlar geliştirmeye devam etmektedir. Günümüzde birçok işletim sisteminde bu ayrıntılı tanımların olduğunu görebilirsiniz. Bu ayrıntılı tanımlar, Dağıtık Nesne Hesaplamaları için gerekli standart arayüzleri, detayı ile anlatır. OMG nin 1989 yılındaki kuruluşunu takiben, Aralık 1990 yılında CORBA 1.0 piyasaya sürülmüştür. Bunu, 1991 yılının başlarında, IDL (Interface Definition Language) ve uygulamaların bir ORB ile haberleşebilmeleri için API lerin tanımlandığı CORBA 1.1 takip etmiştir. CORBA 1.x sürümleri ile birlikte farklı mimarilerde, farklı makinelerde ve farklı dillerde yazılmış nesnelerin birbirleriyle haberleşmelerini sağlayarak nesneler arası ilişkilere ayrı bir boyut kazandırmıştır. CORBA 1.x sürümleri dağıtık nesnelerin ilişkilendirilmesi açısından atılmış önemli adımlardı, fakat bazı eksiklikleri vardı. IDL için ve bir uygulama üzerinden bir ORB ye erişmek için standartlar tanımlanmış olsa da, en büyük eksiklik ORB ların birbirleriyle haberleşebilmeleri için standart bir protokol tanımlanmamış olmasıydı. Bu yüzden bir üreticinin ürettiği bir ORB ile farklı bir üreticinin ORB u haberleşemeyecekti. Bu da dağıtık sistemlerin amacına sınırlama getirmekteydi. Aralık 1994 de tamamlanan CORBA 2.0 sürümünün en büyük başarısı, farklı ORB ler arası haberleşmenin sağlanabilmesi için standart bir protokolün tanımlanmış olmasıydı. IIOP (Internet InterORB Protocol) olarak adlandırılan bu protokol sayesinde CORBA uygulamaları daha fazla üreticiden bağımsız hale geldiler. IIOP protokolü sadece, Internet ve birçok intraneti bünyesinde barındıran TCP/IP tabanlı ağlarda kullanılabilir. CORBA, Nesne Yönetim Mimarisinin (OMA Object Management Architecture) bir parçasıdır. CORBA nın OMA içerisindeki görevi ORB (Object Request Broker Nesne İstek Aracı) fonksiyonlarını yerine getirmektir. CORBA yı anlatmaya başlamadan önce OMA hakkında biraz bilgi vermek konunun daha rahat anlaşılmasını sağlayacaktır.

9 2.1. OMA Object Management Architecture Nesne Yönetim Mimarisi, nesne teknolojisine dayandırılan bir tak-ve-çalıştır bileşen yazılım ortamı yaratmak için, bileşen arayüzlerinin nasıl standartlaştırılacağına rehberlik eder. OMA bir Nesne Modeli ve bir Referans Modeli nden oluşur. Nesne Modeli, heterojen bir bölgede dağılmış olan nesnelerin nasıl tanımlanacağını belirlerken, Referans Modeli de bu nesneler arasındaki etkileşimi tanımlar. OMA Nesne Modeli nde bir nesne, servislerine sadece tanımlanmış arayüzler üzerinden erişilebilen, tekil sabit bir kimliği olan korunmuş bir varlıktır. İstemciler, servisleri kendi taraflarında icra etmek için nesnelere istek gönderirler. Her nesnenin bulunması ve yürütülmesi isteği yapan istemciden saklanır. Uygulama Nesneleri Dikey CORBA Vasıtaları Yatay CORBA Vasıtaları ORB CORBA Servisleri ġekil 2.1. OMA Referans Modeli ġekil 2.1 de gösterilen OMA Referans Modeli, OMA yı oluşturan bileşenleri, arayüzleri ve protokolleri teşhis eder ve tanımlar. 2.1.1. ORB Modelin merkezinde, istemcilerin ve nesnelerin dağıtık bir ortamda haberleşmelerini sağlayan, modelin haberleşme merkezi sayılan ORB bileşeni yer alır. ORB, adreslenmiş nesnelerin yürütülmesinde kullanılan platformlardan ve tekniklerden bağımsız olarak, nesnelerin haberleşebilmelerini sağlamak için bir alt yapı sağlar. 2.1.2. CORBA Servisleri (CORBA Services) Bu bileşen, nesnelerin yaşam döngüsü yönetimini standartlaştırır. Nesneleri yaratmak, nesnelere erişimi kontrol etmek, tekrar aranan nesnelerin izini saklamak, ve nesnelerin

10 grupları arasındaki ilişkiyi sürekli olarak muhafaza etmek için fonksiyonlar sağlanır. CORBA Servisleri bileşenleri tek nesnelerin görevlerini yerine getirebilecekleri soysal ortam sağlarlar. CORBA Servislerinin standartlaştırılması, farklı uygulamaların uyumuna önderlik etmiş, ve geliştirici için verimliliği arttırmıştır. CORBA Servisleri bazı kaynaklarda Nesne Servisleri olarak geçer. Bu servislere örnek olarak, istemcilerin nesneleri isimlerine göre bulmalarını sağlayan İsimlendirme Servisi (Naming Service), ve özelliklerine göre bulmalarını sağlayan Takas Servisi (Trading Service), sayılabilir. 2.1.3. Dikey & Yatay CORBA Vasıtaları (Horizontal & Vertical CORBA Facilities) Dikey vasıtalar, alana özel vasıtalar olarak ta adlandırılır. Özel bir dikey pazarda (ör: sağlık, üretim, finans) yer alan iş problemlerine çözümler sağlayan bileşenleri temsil eder. Genel vasıtalar da denilen yatay vasıtalar (Vertical CORBA Facilities) ise, şirketlerin ve işlerin üstünde bir destek sağlayan bileşenleri temsil eder. Bu vasıtalara örnek olarak, Sayısal Mal Yönetimi (Digital Asset Management) bileşeni ve Dağıtık Doküman Bileşen Vasıtası (DDCF Distributed Docment Component Facility) sayılabilir. DDCF bir doküman modeline dayalı olarak nesnelerin gösterimine ve takasına izin verir. 2.1.4. Uygulama Nesneleri (Application Objects) Kullanıcılar için özel işleri yerine getiren nesnelerdir. OMG tarafından standartlaştırılmış olsun yada olmasın, bu arayüzler dağıtık bir ortamda ORB üzerinden uzak nesnelerdeki yöntemleri dinamik veya statik olarak çağırabilen uygulama nesnelerine erişim sağlarlar. Bir uygulama tipik olarak çok sayıda temel nesne sınıfının bir araya getirilmesi ile oluşur. Uygulama nesnelerinin yeni sınıfları, CORBA Servisleri tarafından sağlanan varolan sınıfların genelleştirilmesi ve özelleştirilmesi vasıtasıyla, varolan sınıfların değiştirilmesi ile oluşturulabilir. Uygulama geliştirmedeki çoklu-nesne sınıfı yaklaşımı, geliştirici için verimliliği arttırırken, son kullanıcı için de uygulamalarını bir araya getirmek ve en iyi şekilde çalıştırabilmek için çeşitliliği arttırır. 2.2. Bir ORB nin (Object Request Broker) Yapısı ġekil 2.2, bir istemci tarafından bir nesne yürütmesine gönderilmiş bir isteği gösteriyor. İstemci, nesne üzerinde bir işlem yapmak isteyen varlıktır, ve nesne yürütmesi gerçekte nesneyi yürüten kod ve veridir.

11 ġekil 2.2. ORB Üzerinden Gönderilen Bir İstek ORB, istek için nesne yürütmesini bulmada, nesne yürütmesini isteği almak için hazırlamada, ve isteği oluşturan veri ile iletişim kurmada gerekli tüm mekanizmalardan sorumludur. İstemci arayüzünün görünüşü, nesnenin nerde konumlandığından, hangi programlama dilinde yürütüldüğünden, veya nesnenin arayüzüne yansımayan herhangi başka bir durumdan tamamen bağımsızdır. ġekil 2.3. Nesne İstek Arayüzlerinin Yapısı

12 ġekil 2.3 başlı başına bir Object Request Broker (ORB) ın yapısını gösterir. ORB ye doğru olan arayüzler kutular ile gösterilmiştir, ve oklar ya ORB nin çağrıldığını yada arayüz üzerinden bir üst-çağrı yapıldığını gösterir. Bir çağrı yapmak için İstemci, Dinamik Çağrı Arayüzü nü (DII Dynamic Invocation Interface hedef nesnenin arayüzünden bağımsız olan aynı arayüz) veya bir OMG IDL stub ını (hedef nesnenin arayüzüne bağlı olan özel stub) kullanabilir. İstemci bazı fonksiyonlar için ORB ile direkt olarak temas ta kurabilir. Nesne Yürütmesi bir çağrıyı, OMG IDL tarafından üretilen iskelet üzerinden veya bir dinamik iskelet üzerinden, bir üst-çağrı olarak alır. Nesne Yürütmesi bir isteği işlerken veya başka durumlarda, Nesne Adaptörünü ve ORB yi çağırabilir. Arayüzlerin nesnelere tanımlanması iki yolla yapılabilir. Arayüzler, arayüz tanımlama dilinde (IDL) statik olarak tarif edilebilir. Bu dil, nesnelerin tiplerini, üzerlerinde yapılabilecek işlemlere, ve bu işlemlerin alabileceği parametrelere göre tanımlar. Alternatif olarak, arayüzler aynı zamanda bir Arayüz Ambarı (Interface Repository) servisine eklenebilir; bu servis bir arayüzün bileşenlerini, bu bileşenlere çalışma zamanı (run-time) erişime izin vererek, nesneler olarak gösterir. Her ORB yürütmesinde, Arayüz Tanımlama Dili ve Arayüz Ambarı eşit güçtedirler. ġekil 2.4. Stub ı veya Dinamik Çağrı Arayüzünü Kullanan Bir İstemci.

13 İstemci, nesnenin tipini ve yapılması gereken işlemi bilerek, ve nesne için bir Nesne Referansına erişerek, bir çağrı yapar. İstemci çağrıyı, nesneye özel stub rutinlerini çağırarak, veya çağrıyı dinamik olarak yapılandırarak, başlatır (ġekil 2.4). Bir çağrıyı başlatmak için dinamik ve stub arayüzü aynı çağrı semantiklerini yerine getirirler, ve mesajın alıcısı çağrının nasıl başlatıldığını bilemez. ORB uygun yürütme kodunu yerleştirir, parametreleri aktarır, ve IDL iskeleti veya dinamik iskelet üzerinden Nesne Yürütmesine kontrolü geçirir (ġekil 2.5). İskeletler arayüze ve nesne adaptörüne özeldir. Çağrıyı gerçekleştirirken, nesne yürütmesi, Nesne Adaptörü vasıtasıyla ORB den bazı servisleri bulabilir. Çağrı tamamlandığında, kontrol ve çıktı değerleri istemciye geri döner. Nesne Yürütmesi hangi Nesne Adapörünün kullanılacağını seçebilir. Bu karar, Nesne Yürütmesinin hangi tipte servislere ihtiyaç duyduğuna bağlıdır. ġekil 2.6, arayüz ve yürütme bilgisinin, istemciler ve nesne yürütmeleri üzerinde, nasıl hazır hale getirilebileceğini gösterir. Arayüz OMG IDL de ve/veya Arayüz Ambarında tanımlanır; tanımlama istemci stub larını ve nesne yürütme iskeletlerini oluşturmak için kullanılır. ġekil 2.5. İstek Alan Bir Nesne Yürütmesi

14 ġekil 2.6. Arayüz ve Yürütme Ambarları Nesne yürütme bilgisi yükleme sırasında sağlanır, ve çağrı teslimatı sırasında kullanılmak üzere Yürütme Ambarında saklanır. 2.2.1. Object Request Broker (ORB) Mimaride, ORB nin tek bir bileşen gibi yürütülmesinden ziyade, arayüzleri vasıtasıyla tanımlanması makbuldür. Uygun arayüzü sağlayan herhangi bir ORB yürütmesi kabul edilebilir. Arayüz üç kategoride düzenlenir: 1. Tüm ORB yürütmeleri için aynı olan işlemler 2. Nesnelerin belirli tiplerine özel olan işlemler 3. Nesne yürütmelerinin belirli tarzlarına özel olan işlemler Farklı ORB ler farklı yürütme seçeneklerini gerçekleştirebilirler, ve IDL derleyicileri, ambarlar, ve çeşitli Nesne Adaptörleri ile birlikte, farklı seçeneklere ve özelliklere sahip nesnelerin yürütmeleri ve istemcilere bir takım servisler sağarlar. Nesne referansları için farklı gösterimlere sahip, ve çağrıların gerçekleşmesinde farklılıkları olan birçok ORB yürütmesi olabilir. Bir istemcinin, farklı ORB yürütmeleri tarafından idare edilen iki nesne referansına, aynı anda erişmesi mümkündür. İki ORB beraber çalışmak üzere tasarlanmışsa, bu ORB ler kendi nesne referanslarını ayırt edebilmeliler. Bu istemcinin sorumluluğunda değildir.

15 ORB çekirdeği, nesnelerin, ve isteklerin iletişiminin temel gösterimini sağlayan ORB nin bir kısmıdır. CORBA, farklı nesne mekanizmalarını desteklemek üzere tasarlanmıştır, ve ORB çekirdeğinin üstünde olan, ORB çekirdekleri arasındaki farklılıkları gizleyebilen arayüzleri sağlayan bileşenlerle ORB yi oluşturarak bunu yapar. 2.2.2. Ġstemciler Bir nesnenin bir istemcisi, nesne için bir nesne referansına erişir, ve nesnedeki işlemleri çağırır. İstemci, arayüzüne göre nesnenin sadece mantıksal yapısını bilir ve çağrılara karşı nesnenin davranışını dener. Her ne kadar bir istemcinin, bir nesne üzerindeki istekleri başlatan bir program veya işlem olduğunu genellikle düşüneceksek te, bir istemcinin belirli bir nesneye bağlı bir şey olduğunu kabul etmek önemlidir. Örneğin bir nesnenin yürütmesi, başka nesnelerin istemcisi olabilir. İstemciler genellikle nesneleri ve ORB arayüzlerini, ORB yi programcıların seviyesine çıkartan bir dil eşlemesinin görüş açısı vasıtası ile görürler. İstemciler taşınabilirler, ve istenilen arayüzü yürüten herhangi bir nesne örneği ile istenilen dil eşlemesini destekleyen herhangi bir ORB deki kaynak değişiklikleri olmadan da çalışabilmeye elverişli olmalıdırlar. İstemciler nesnenin yürütülmesi, hangi nesne adaptörünün yürütme tarafından kullanılacağı, veya hangi ORB nin ona erişeceği hakkında herhangi bir bilgiye sahip değildirler. İstemciler hakkında daha fazla bilgi için 2.4. Bir İstemcinin Yapısı bölümüne bakınız. 2.2.3. Nesne Yürütmeleri Bir nesne yürütmesi, genellikle nesne örneği için veriyi ve nesnenin yöntemleri için kodu tanımlayarak, nesnenin semantiklerini sağlar. Yürütme çoğu kez, nesnenin davranışını yerine getirmek için, diğer nesneleri veya ek yazılımları kullanacaktır. Bazı durumlarda, nesnenin birincil görevi, nesne olmayan şeylerin üzerinde yan etki oluşturmaktır. Ayrı sunucular, kütüphaneler, yöntem vasıtasıyla bir program, korunmuş bir uygulama, nesneye yönelik bir veritabanı gibi şeyler içeren çok çeşitli nesne yürütmeleri desteklenebilir. Ek nesne adaptörlerinin kullanımı doğrultusunda, nesne yürütmesinin herhangi bir tipini sanal olarak sağlamak mümkündür. Genellikle, nesne yürütmeleri ORB ye veya istemcinin nesneyi nasıl çağırdığına bağlı değildirler. Nesne yürütmeleri, nesne adaptörünün tercihi ile ORB ye bağlı servislere arayüzler seçebilirler. (Detaylı bilgi için: 2.5. Bir Nesne Yürütmesinin Yapısı)

16 2.2.4. Nesne Referansları Bir Nesne Referansı, bir ORB içinde bir nesne tanımlamak için gerekli olan bilgidir. Hem istemciler hem de nesne yürütmeleri, dil eşlemesine bağlı olarak nesne referansının donuk bir tasarımına sahiptirler, ve böylece gerçek gösterimlerinden yalıtılırlar. İki ORB yürütmesi nesne referansı gösterim tercihlerine göre farklılık gösterebilirler. Bir istemciye verilen bir nesne referansının gösterimi, ancak o istemcinin ömrü kadar geçerlidir. Tüm ORB ler, belirli bir programlama dili için, bir nesne referansına (çoğunlukla bir Nesne olarak işaret edilir) aynı dil eşlemesini sağlamalıdırlar. Bu, belirli ORB den bağımsız nesne referanslarına, belirli bir dilde yazılmış bir programın erişmesine izin verir. Programcının rahatlığı için, nesne referanslarına erişmek için dil eşlemesi de ek yollar sağlayabilir. Tüm nesne referanslarından farklı olması garanti edilmiş ayrı bir nesne referansı vardır, ki bu da hiç nesne olmadığının gösterimidir. 2.2.5. OMG Arayüz Tanımlama Dili (IDL Interface Definition Language) OMG Arayüz Tanımlama Dili nesnelerin tiplerini arayüzlerini tayin ederek tanımlar. Arayüz, bir isimlendirilmiş işler kümesi ve bu işlerin parametrelerinden oluşur. IDL in, ORB tarafından oluşturulan nesnelerin tanımlanması için kavramsal bir kafes sağlamasına rağmen, ORB nin çalışması için IDL kaynak kodunun varlığına gerek yoktur. Stub rutinlerinde veya bir çalışma zamanı arayüz ambarında eş bir bilgi olduğu sürece, belirli bir ORB düzgün çalışma yeteneğine sahip olabilecektir. IDL belirli bir nesne yürütmesi için, hangi işlerin hazır olduğunu ve onların nasıl çağrılması gerektiğini potansiyel istemcilerine söylemekle görevlidir. IDL tanımlamalarından, CORBA nesnelerini belirli programlama dillerinin veya nesne sistemlerinin içine yerleştirmek mümkündür. Daha detaylı bilgi için 2.9. Arayüz Tanımlama Dili bölümüne bakınız 2.2.6. Programlama Dilleri ile OMG IDL nin EĢlenmesi Farklı olan nesneye yönelik veya nesneye yönelik olmayan programlama dilleri, CORBA nesnelerine farklı yollardan erişmeyi tercih edebilirler. Nesneye yönelik diller için, CORBA nesnelerini programlama dili nesneleri gibi görmek istenebilir. Nesneye yönelik olmayan dillerde, nesne referansı, yöntem isimleri gibi şeylerin gerçek ORB gösterimini

17 gizlemek iyi bir fikirdir. Bir programlama dili ile belirli bir OMG IDL nin eşlenmesi, tüm ORB yürütmeleri için aynı olmalıdır. Dil eşlemesi, ORB üzerinden nesnelere ulaşmak için, dile özgü veri tiplerinin ve prosedür arayüzlerinin tanımlamalarını içerir. İstemci stub arayüzünün (nesneye yönelik diller için gerekli değil), dinamik çağrı arayüzünün, yürütme iskeletinin, nesne adaptörlerinin, ve direkt ORB arayüzünün yapılarını içerir. Bir dil eşlemesi, nesne çağrıları ile yürütme veya istemcideki kontrol thread lerinin arasındaki etkileşimi de tanımlar. En genel eşlemeler, nesne işi bitince rutini geri döndüren senkron çağrılarını sağlarlar. Ek eşlemeler bir çağrının başlatılmasını sağlatabilirler, ve kontrolü programa geri verirler. Bu gibi durumlarda, nesne çağrımı ile programın kontrol thread leri arasındaki senkronizasyonu sağlamak için, dile-özgü ek rutinler olmalıdır. Daha detaylı bilgi için 2.10. Dil Eşlemeleri bölümüne bakınız. 2.2.7. Ġstemci Stub ları Nesneye yönelik olmayan bir dilin eşlenmesi için, her arayüz tipi için stub lara doğru bir programlama arayüzü olacaktır. Genellikle, stub lar bir nesne üzerindeki OMG IDL tanımlı işlere, OMG IDL ye ve belirli bir programla dili için dil eşlemesine aşina olan programcılar için kolay olan bir yol ile, erişim sağlarlar. Stub lar, belirli bir ORB çekirdeğine özel olan, ve tahminen ona göre ayarlanmış olan, arayüzleri kullanarak ORB nin diğer kısmına çağrı yaparlar. Eğer birden fazla ORB hazır durumdaysa, farklı ORB lere tekabül eden farklı stub lar olabilir. Bu durumda ORB ve dil eşlemesinin, belirli nesne referansı ile doğru stub ları birleştirmek üzere beraber çalışmaları gereklidir. C++ ve Smalltalk gibi nesneye yönelik diller stub arayüzlerine ihtiyaç duymazlar. 2.2.8. Dinamik Çağrı Arayüzü (DII Dynamic Invocation Interface) Arayüz aynı zamanda, nesne çağrılarının dinamik yapılandırılmasına izin vermeye de hazırdır. Bunun anlamı, belirli bir nesne üzerinde belirli bir iş yapmaya özel bir stub rutinini çağırmaktansa, istemci çağrılacak nesneyi, yapılacak işlemi, ve bir çağrı veya çağrılar dizisinden geçen işin parametreler kümesini belirleyebilir. İstemci kodu yapılacak iş ve geçirilecek parametreler hakkında bilgi içermelidir (muhtemelen bunu Arayüz Ambarı ndan veya başka bir çalışma zamanı kaynaktan elde eder). Dinamik çağrı arayüzünün doğası, aslında bir programlama dili eşlemesinden diğerine farklılıklar gösterebilir.

18 2.2.9. Yürütme Ġskeleti Belirli bir dil eşlemesi için, ve muhtemelen nesne adaptörüne bağlı olarak, her tipten nesneyi yürüten yöntemlere doğru bir arayüz olacaktır. Arayüz genellikle üst-çağrı (up-call) arayüzü olacaktır. Bunun anlamı; nesne yürütmesi arayüze uyan rutinler yazar ve ORB iskelet üzerinden onları çağırır. Bir iskeletin varlığı, ona uyan bir istemci stub ının varlığını ifade etmez (istemciler aynı zamanda dinamik çağrı arayüzü vasıtasıyla da istek yapabilirler). Yürütme yöntemlerini çağırmak için iskelet kullanmayan bir nesne adaptörü yazmak ta mümkündür. Örneğin, Smalltalk gibi diller için yürütmeleri dinamik olarak yaratmak mümkün olabilir. 2.2.10. Dinamik Ġskelet Arayüzü (DSI Dynamic Skeleton Interface) Nesne çağrılarının dinamik olarak tutulmasını sağlayan bir arayüz vardır. İstemci tarafının Dinamik Çağrı Arayüzü ne benzer şekilde, bir nesnenin yürütmesi, belirli bir işe özel bir iskelet üzerinden erişim yerine, iş isimleri ve parametrelere erişim sağlayan bir arayüz üzerinden ulaşır. Sadece bu parametrelerin statik bilgisi kullanılabilir, veya parametreleri tayin etmek için, dinamik bilgi (muhtemelen Arayüz Ambarı ndan alınır) de kullanılabilir. Yürütme Kodu ORB ye tüm iş parametrelerinin tanımlamalarını sağlamalıdır, ve ORB de işi yaparken kullanılabilecek her giriş parametresinin değerini sağlamalıdır. Arayüz kodu her çıkış parametresinin değerini, veya başka bir şeyi, işi yaptıktan sonra ORB ye vermelidir. Dinamik iskelet arayüzünün doğası, aslında bir programlama dili eşlemesinden veya nesne adaptöründen diğerine farklılıklar gösterebilir, ama tipik olarak bir üst-çağrı arayüzü olacaktır. Dinamik iskeletler, hem istemci stub ları tarafından, hem de dinamik çağrı arayüzü tarafından çağrılabilirler; her ikisinde de istemci istek yapısı arayüzünün tarzı aynı sonuçları sağlar. 2.2.11. Nesne Adaptörleri Bir nesne adaptörü, bir nesne yürütmesinin ORB tarafından sağlanan servislere erişmesinin temel yoludur. Nesnelerin özel çeşitleri için uygun olan arayüzler ile birkaç nesne adaptörünün, yaygın olarak hazır durumda olması beklenecektir. Bir nesne adaptörü vasıtası ile ORB tarafından sağlanan servisler çoğu kez, nesne referanslarının oluşumunu ve izahını,

19 çağrı yöntemini, birbirine tesir etmenin güvenliğini, nesne ve yürütme aktivasyonunu ve deaktivasyonunu, nesne referanslarının yürütmelerle eşlenmesini, ve yürütmelerin kaydını içerir. Nesnelerin sayıları, ömürleri, idareleri, yürütme tarzları, ve diğer özelliklerinin geniş bir yelpazesi, ORB çekirdeğinin tüm nesneler için uygun ve etkili tek bir arayüz sağlamasını zorlaştırır. Bunun için, nesne adaptörleri vasıtasıyla, ORB nin, onlara uydurulmuş arayüzlerle benzer ihtiyaçları olan nesne yürütmelerinin belirli gruplarını hedeflemesi mümkündür. Daha detaylı bilgi için 2.6 Bir Nesne Adaptörünün Yapısı bölümüne bakınız. 2.2.12. ORB Arayüzü ORB Arayüzü, tüm ORB ler için aynı olan ve nesnenin arayüzüne veya nesne adaptörüne bağlı olmayan, direkt olarak ORB ye giden arayüzdür. ORB nin görevlerinin çoğu nesne adaptörü, stub lar, iskelet, veya dinamik çağrı üzerinden sağlandığı için, tüm nesneler için genel olan sadece birkaç iş vardır. Bu işler hem istemciler hem de nesnelerin yürütmeleri için kullanışlıdırlar. 2.2.13. Arayüz Ambarı Arayüz Ambarı, çalışma zamanında hazır durumda olan bir form içinde IDL bilgisini temsil eden sürekli nesneler sağlayan bir servistir. Arayüz Ambarı bilgisi istekleri yapmak için ORB tarafından kullanılabilir. Üstelik, Arayüz Ambarı ndaki bilgiyi kullanarak, program derlendiği sırada arayüzü henüz bilinmeyen bir nesne ile karşılaşan bir program, nesne üzerinde hangi işlerin yapılabileceğine karar verme ve onun üzerinde çağrı yapma imkanına sahip olur. ORB nin çalışmasındaki rolüne ek olarak Arayüz Ambarı, ORB nesnelerine arayüzlerle birleştirilmiş ek bilgileri saklamak için genel bir yerdir. Örneğin, hata giderme (debugging) bilgisi, stub ların veya iskeletlerin kütüphanesi, belirli nesne çeşitleri ile görüntülenebilen veya biçimlendirilebilen rutinler Arayüz Ambarı ile birleştirilebilirler. Daha detaylı bilgi için 2.11 Arayüz Ambarı bölümüne bakınız. 2.2.14. Yürütme Ambarı Yürütme Ambarı, ORB nin nesnelerin yürütmelerini seçmesi ve aktif hale getirmesi için gerekli bilgiyi içerir. Yürütme Ambarı ndaki birçok bilginin bir ORB ye veya işletim birimine özel olmasına rağmen, Yürütme Ambarı böyle bir bilgiyi saklamak için geleneksel yerdir. Çoğunlukla yürütmelerin kurulumu ve politikaların kontrolü aktivasyona bağlıdır, ve nesne yürütmelerinin çalıştırılması Yürütme Ambarı ndaki işler üzerinden yapılır.

20 ORB nin çalışmasındaki rolüne ek olarak Yürütme Ambarı, ORB nesnelerinin yürütmeleri ile birleştirilmiş ek bilgileri saklamak için genel bir yerdir. Örneğin, hata giderme bilgisi, idari kontrol, kaynak ayrımı, güvenlik gibi şeyler Yürütme Ambarı ile birleştirilebilirler. 2.3. Örnek ORB ler Genel ORB mimarisi içinde ORB yürütmelerinin bir çok çeşidi vardır. Bu bölüm bazı farklı seçenekleri anlatacaktır. Belirli bir ORB nin iletişim için çok yönlü seçenek ve protokolleri destekleyebileceği unutulmamalıdır. 2.3.1. Ġstemci- ve Yürütme-YerleĢik ORB Eğer uygun bir iletişim mekanizması varsa, bir ORB istemcilerde ve yürütmelerde bulunan rutinlerde yürütülebilir. İstemcideki stub lar, yürütmelerle iletişimi kurmak için, bir şeffaf-konum (location-transparent) IPC mekanizmasını kullanabilirler veya bir konum servisine direkt ulaşabilirler. Yürütme ile bağlanmış kod, istemciler tarafından kullanılması için ilgili veritabanlarını kurmakla görevlidir. 2.3.2. Sunucu-tabanlı ORB ORB nin idaresini merkezileştirmek için, tüm istemciler ve yürütmeler, görevleri istekleri istemcilerden yürütmelere yönlendirmek olan bir yada daha çok sunucu ile haberleşebilirler. Altında olan işletim sistemine kalırsa ORB normal bir program olabilir, ve ORB ile haberleşmek için normal IPC kullanılabilir. 2.3.3. Sistem-tabanlı ORB Güvenliği, kuvveti ve performansı arttırmak için, ORB, altında olan işletim sisteminin bir temel servisi olarak sağlanabilir. Nesne referansları, her istekteki kimlik sorgulama masrafını azaltarak, kalıcı yapılabilir. İşletim sisteminin istemcilerin ve yürütmelerin yerini ve yapısını bilebilmesi sayesinde, çok çeşitli iyileştirmelerin yerine getirilmesi mümkündür, örneğin, ikiside aynı makinedeyse dönüştürme (marshaling 1 ) işleminden sakınır. 1 ORB nin görevlerinden biri, method u çağıran bileşenden giriş parametrelerini almak, ve bunları ağ üzerinden aktarılabilecek bir biçime dönüştürmektir. Bu işleme dönüştürme (marshaling) denir. ORB, ağ üzerinden gelen dönüş parametrelerini de, çağıran bileşenin anlayabileceği biçime geri dönüştürür. Bu işleme de geri dönüştürme (unmarshaling) denir.

21 2.3.4. Kütüphane-tabanlı ORB Yürütmeleri paylaştırılabilen ve hafif olan nesneler için, yürütme gerçekte bir kütüphanede olmalıdır. Bu durumda, stub lar gerçek yöntemler olabilir. Bu, bir istemci programın nesneler için olan verilere erişmesinin mümkün olduğunu, ve yürütmenin veriye zarar vermemesi konusunda istemciye güvendiğini farz eder. 2.4. Bir Ġstemcinin Yapısı Bir nesnenin bir istemcisi o nesneye işaret eden bir nesne referansına sahiptir. Bir nesne referansı, farklı bir nesne üzerindeki bir çağrıya bir parametre olarak aktarılan veya çağrılabilen bir işaret (token) tir. Bir nesnenin çağrımı, çağrılan nesnenin, yapılan işin, işe gönderilen veya işten dönen parametrelerin belirtilmesini gerektirir. ORB, nesne yürütmesine doğru olan kontrol aktarımını ve veri aktarımını, ve istemciye geri dönüşünü idare eder. ORB nin çağrıyı tamamlayamaması durumu için, istisna bir cevap sağlanmıştır. Genellikle, bir istemci çağrıyı yapan programının içindeki bir rutini çağırır, ve iş bitince geri döner. İstemciler programlarında, kütüphane rutinlerine erişir gibi nesne-tipine-özel stub lara erişebilirler (ġekil 2.7). İstemci programı böylece, kendi programlama dilinde, rutinleri normal bir biçimde çağrılabilir olarak görür. Tüm yürütmeler nesneleri işaret etmek için dillere özgü bir veri tipi sağlayacaklardır, bu genelde bir donuk işaretçi (opaque pointer) dir. Daha sonra istemci, çağrıyı başlatmak için o nesne referansını stub rutinlerine geçirir. Stub lar nesne referans gösterimine ulaşabilirler, ve çağrıyı gerçekleştirmek için ORB ile etkileşim içine girerler. Kütüphane kodunun alternatif bir kümesi nesneler üzerinde çağrılar yapmak için hazır durumdadır. Örneğin, nesne derleme zamanında tanımlı değilse, bu küme kullanılır. Bu durumda, istemci program, nesnenin tipini ve çağrılan yöntemi adlandırmak için ek bilgi sağlar, ve parametreleri belirlemek ve çağrıyı başlatmak için bir sıra çağrılar gerçekleştirir. İstemciler nesne referanslarını genellikle, referanslarının bulunduğu başka nesneler üzerindeki çağrılardan çıkış parametresi biçiminde alarak bulurlar. Bir istemci aynı zamanda bir yürütme olduğunda, nesne referanslarını, yürüttüğü nesnelere olan çağrılardaki giriş parametreleri olarak alır. Bir nesne referansı, dosyalarda saklanabilen veya korunan yada farklı anlamlarda ifade edilen, ve sonradan karakter kümesini oluşturan ORB tarafından bir nesne referansına tekrar dönüştürülen, bir karakter kümesine (string) de çevrilebilir.

22 ġekil 2.7. Tipik bir İstemcinin Yapısı 2.5. Bir Nesne Yürütmesinin Yapısı Bir nesne yürütmesi bir nesnenin gerçek durumunu ve davranışını sağlar. Nesne yürütmesi çok değişik şekillerde yapılandırılabilir. İşlerin kendileri için yöntemler tanımlamalarının yanında, bir yürütme, genellikle nesneleri aktive ve de-aktive etmek için prosedürler tanımlayacak ve nesne durumunun devamlılığı ve nesneye erişimin kontrolü için başka nesneleri veya nesne olmayan vasıtaları, yöntemleri yürütür gibi kullanacaktır. Nesne Yürütmesi (ġekil 2.8), varlığını tayin etmek, yeni nesneler yaratmak, ve ORBbağımlı servisleri bulmak için, ORB ile bir çok değişik biçimde etkileşir. Temel olarak, nesne yürütmesinin belirli bir çeşidi için uygun olan ORB servislerine bir arayüz sağlayan, bir nesne adaptörüne erişerek bunu yapar. Mümkün nesne yürütmelerinin çokluğu yüzünden, bir nesne yürütmesinin nasıl yapılandırılacağı konusunda kesin konuşmak zordur. Bir çağrı oluştuğunda, ORB çekirdeği, nesne adaptörü, ve iskelet, yürütmenin ilgili yöntemine bir çağrı yapıldığı konusunda anlaşmaya varırlar. Çağrılmakta olan nesneyi, yöntemin nesne için veriyi yerleştirmesinde kullanabileceği, bu yönteme doğru bir paramete tayin eder. Ek parametreler iskelet tanımına göre temin edilirler. Yöntem tamamlandığında, meydana gelen çıkış parametrelerini veya iletilen diğer sonuçları istemciye geri verir.

23 ġekil 2.8. Tipik bir Nesne Yürütmesinin Yapısı Yeni bir nesne yaratıldığında, ORB bu nesne için yürütmeyi nerden bulacağını bilmesi konusunda uyarılabilir. Genellikle, yürütme aynı zamanda kendini belli bir arayüzün yürütülmüş nesneleri olarak kaydeder, ve eğer yürütme çalışır durumda değilse onu nasıl çalıştıracağını belirler. Çoğu nesne yürütmeleri, ORB ve nesne adaptörüne ek olarak, davranışlarını vasıtalar kullanarak sağlarlar. Örneğin, taşınabilir nesne adaptörü bir nesne (kendi OID si veya Nesne ID si) ile ilişkilendirilmiş bazı sürekli veriler sağlamasına rağmen, nispeten küçük boyuttaki bu veri tipik olarak nesne yürütmesinin seçtiği bir depolama servisinde saklanan gerçek nesne verisi için bir teşhis edici olarak kullanılır. Bu yapı ile, sadece farklı nesne yürütmelerinin aynı depolama servisini kullanması değil, nesnelerin kendilerine en uygun servisi seçmeleri de mümkündür. 2.6. Bir Nesne Adaptörünün Yapısı Bir nesne adaptörü, nesne referans oluşturması gibi ORB servislerine erişmek için bir nesne yürütmesinin temel aracıdır. Bir nesne adaptörü, nesne yürütmesine genel bir arayüz, ve iskelete de özel bir arayüz ihraç eder. Özel bir ORB-bağımlı arayüz üzerine kuruludur.

24 Nesne adaptörleri aşağıdaki fonksiyonlardan sorumludurlar: Nesne referanslarının oluşturulması ve açıklamaları Yöntem çağrısı Etkileşimlerin güvenliği Nesne ve yürütme aktivasyonu ve de-aktivasyonu Nesne referansları ile ilgili nesne yürütmelerini eşleştirmek Yürütmelerin kaydı Bu fonksiyonlar ORB çekirdeği ve bazı gerekli ek bileşenler kullanılarak yapılır. Çoğu kez, bir nesne yürütmesi görevlerinin üstesinden gelmek için kendi durumunu muhafaza edecektir. Belirli bir nesne adaptörünün, bir yada daha çok sorumluluğunu üzerine yapılandırıldığı çekirdeğe emanet etmesi mümkündür. ġekil 2.9 da görüldüğü gibi, direkt arayüz iskeletler üzerinden olmasına rağmen, Nesne Adaptörü yöntemlerin çağrımına tamamıyla bağlanmıştır. Örneğin, Nesne Adaptörü yürütmeyi aktif hale getirmek veya isteği onaylamak için kullanılabilir. ġekil 2.9. Tipik bir Nesne Adaptörünün Yapısı Nesne Adaptörü, Nesne Yürütmesinin bağlanabileceği servislerin büyük bir bölümünü ORB den ayırır. Farklı ORB ler farklı seviyelerde servis sağlayacaklardır, ve farklı işletim birimleri bazı özellikleri tamamıyla sağlayabilecek ve diğerlerinin Nesne Adaptörü tarafından eklenmesine ihtiyaç duyacaklardır. Örneğin, bir çağrıda nesnenin kolay belirlenmesi için

25 nesne referansındaki belirli değerleri saklamayı istemek, Nesne Yürütmeleri için genel bir şeydir. Eğer nesne adaptörü, yeni bir nesne yaratıldığında yürütmenin bu gibi değerleri belirlemesine izin verirse, buna izin veren ORB ler için bu değerleri nesne referansında saklamayı becerebilir. Eğer ORB çekirdeği bu özelliği içermiyorsa, Nesne Adaptörü değeri kendi deposunda saklayacak, ve bir çağrı üzerindeki yürütmeye verecektir. Nesne Adaptörleri sayesinde, ORB çekirdeğinde yürütülüyor olsun yada olmasın bir nesne yürütmesinin bir servise erişmesi mümkündür. Eğer ORB çekirdeği bu özelliği içeriyorsa, adaptör basitçe ona bir arayüz sağlayacaktır; aksi halde, adaptör onu ORB çekirdeğinin tepesinde yürütmelidir. Belirli bir adaptörün her örneği, yürütülmekte olduğu tüm ORB ler için aynı arayüzü ve servisi sağlamalıdır. Aynı zamanda, tüm Nesne Adaptörleri için aynı arayüzü veya görevselliği sağlamak ta gerekli değildir. Bazı Nesne Yürütmelerinin özel gereksinimleri vardır. Örneğin, bir nesneye yönelik veritabanı sistemi, binlerce nesnesini, Nesne Adaptörüne ayrı ayrı çağrılar yapmadan tümüyle kaydetmek isteyebilir. Böyle bir durumda, nesne adaptörü için herhangi bir nesnebaşına (per-object) durumunu muhafaza etmek elverişsiz ve gereksiz olacaktır. Bu gibi nesne yürütmeleri için hazırlanan nesne adaptörü arayüzünü kullanarak, ORB ye en etkili erişimi sağlamak için belirli ORB çekirdeğinin detaylarından faydalanmak mümkündür. 2.7. CORBA ya Ġhtiyaç Duyan Nesne Adaptörü Birçok mümkün nesne adaptörü vardır; ama, nesne adaptörü arayüzü nesne yürütmelerinin bağlı olduğu birşey olmasından dolayı, pratik olarak kullanılabileceği kadar az olması caziptir. Nesne adaptörlerinin çoğu, nesne yürütmelerinin bir kısımını kapsamak üzere tasarlanmışlardır. Yalnızca, bir yürütme temelden farklı servislere veya arayüzlere ihtiyaç duyduğunda, yeni bir nesne adaptörü düşünülmelidir. 2.7.1. TaĢınabilir Nesne Adaptörü (POA Portable Object Adapter) Taşınabilir Nesne Adaptörü, birçok ORB nesnesi tarafından geleneksel yürütmeler ile kullanılabilir. POA nın amacı, adından da anlaşılabileceği gibi, farklı üreticilerin yürütmeleri ile ilgili, minimum yeniden yazma ihtiyacı olan birçok ORB ile kullanılabilen Nesne Adaptörü sağlamaktır. Bu tanımlama sunucuların birkaç şekilde kullanılmasına izin verir, ama sunucu programlarının başlatılmasının idari meseleleri ile ilgili değildir. Ama, bir defa başlatıldığında bir tekil yöntem çağrısı için bir hizmetçi başlatılıp bitirilebilir, her nesne için ayrı bir hizmetçi olabilir, veya nesne tipinin tüm örnekleri için paylaşılan bir hizmetçi olabilir. Bu, POA

26 nesnesinin farklı örnekleri ile kayıtlı olması vasıtasıyla nesne gruplarının ilişkilendirilmesine, ve yürütmelerin kendi aktivasyon tekniklerini belirlemelerine izin verir. Çağrı yapıldığında yürütme aktif değilse, POA bir tane başlatır. POA IDL de tanımlanır, böylece dillerle eşlenmesi, dil eşleme kurallarını takiben büyük oranda otomatiktir. (Bir dil eşlemesinden geriye kalan temel görev, hizmetçi tipinin tanımlanmasıdır.) 2.8. Yabancı Nesne Sistemlerinin Entegrasyonu Genel ORB Mimarisi, nesne sistemlerinin geniş bir kısmının birbirleri ile iş yapmasına izin vermek üzere tasarlanmıştır (ġekil 2.10). Çünkü varolan birçok nesne sistemi vardır, genel bir istek, ORB vasıtasıyla erişilebilen sistemlerdeki nesnelere izin verilmesi olacaktır. Kendileri ORB olan nesne sistemlerinin bazı mekanizmalar sayesinde başka ORB lere bağlanmaları mümkündür. ORB nesneleri ile kendi nesnelerini basitçe eşleştirmek ve ORB üzerinden çağrılar almak isteyen nesne sistemleri için, bir yaklaşım bu nesne sistemlerinin ilgili ORB nesnelerinin yürütmeleri olarak gösterilmesidir. Nesne sistemi nesnelerini ORB ile kaydedecek ve gelen istekleri kabul edecektir, ve bir istemci gibi davranıp istek gönderebilecektir. Bazı durumlarda, başka nesne sisteminin bir POA nesne yürütmesi gibi davranması elverişsiz olacaktır. Bir nesne adaptörü, ORB ile birleşme yerinde yaratılan ve temel olarak ORB üzerinden çağrılabilen nesneler için tasarlanabilir. Başka bir nesne sistemi, ORB ye danışmadan nesneleri yaratmayı isteyebilir, ve çağrıların çoğunun ORB üzerinden olmasındansa kendi üzerinden olmasını tercih edebilir. Bu gibi bir durumda, daha uygun bir nesne adaptörü, nesneler ORB üzerinden geçerken tamamıyla kayıtlı olmalarına izin verebilir. ġekil 2.10. Yabancı Nesne Sistemlerinin Entegrasyonunda Farklı Yöntemler