Dağıtık Nesne Yönetimi Mimarilerinin İncelenmesi
Transkript
Dağıtık Nesne Yönetimi Mimarilerinin İncelenmesi
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 Veritabanı İş Kuralları 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 Veritabanı İş Kuralları Başka Sunucular İstemci İş Kuralları 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 İstemci Kullanıcı Arayüzü 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 (interface1) 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 services2) 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 monitor3) 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 Group1 - 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 (marshaling1) 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 27 2.9. Arayüz Tanımlama Dili (IDL) Bir istemcinin bir nesneye istek yapabilmesi için, nesne tarafından desteklenen iş tiplerini bilmesi gerekir. Bir nesnenin arayüzü, nesnenin desteklediği tipleri ve işleri belirler, ve böylece nesne üzerinde yapılabilecek istekleri tayin eder. Nesneler için arayüzler IDL’de tanımlanır. Arayüzler, C++’taki sınıflarla, ve Java’daki arayüzlerle benzerdir. Bir IDL arayüz tanımlama örneği aşağıdaki gibidir: // OMG IDL interface Fabrika { Object yarat(); }; Bu tanımlama, bir işi (yarat) destekleyen Fabrika adında bir arayüzü belirtir. yarat işi hiçbir parametre almaz ve Object tipinde bir nesne referansı döndürür. Fabrika tipinde bir nesne için verilen bir nesne referansını, bir istemci yeni bir CORBA nesnesini yaratmak için çağırabilir. Bu arayüz, daha önce bahsedilen Fabrika nesnelerinden biri tarafından desteklenebilir. IDL’nin önemli bir özelliği de dil bağımsız olmasıdır. IDL bir programlama dili değil, bir tanımlama dili olduğundan, arayüzlerin nesne yürütmesinden bağımsız tanımlanmalarını mecbur kılar. Bu, nesnelerin farklı programlama dilleri kullanılarak oluşturulmasına, ve buna rağmen birbirleri ile haberleşmelerine izin verir. Dil bağımsız arayüzler, tüm programlama dilleri tüm platformlarda bulunmadığı veya desteklenmediğinden dolayı, heterojen sistemlerde önemlidirler. IDL, programlama dillerinin çoğunda bulunan veri tiplerine benzer tipler ihtiva eder. long, double ve boolean gibi temel tipler, struct, union gibi yapısal tipler, ile sequence ve string gibi şablon tipleri içerir. Tipler, işlerin parametre tiplerini ve geri dönüş tiplerini tayin etmek için kullanılır. Yukarıdaki örnekte görüldüğü gibi, belirli arayüz tipini destekleyen nesneler tarafından sağlanan servisleri belirlemek için, işler arayüzlerin (interface) içinde kullanılır. IDL, bir işin rotasında ortaya çıkabilecek istisnai durumları belirlemek için, exception tanımlamalarını içerir. struct’lar gibi, exception’lar da herhangi bir IDL tipinden bir yada daha çok veri üyesi içerebilirler. IDL module yapısı, isim çakışmalarını engellemek için, tanımlama isimlerinin faaliyet alanının belirlenmesine izin verir. 28 2.9.1. Gömülü Tipler (Built-in Types) IDL aşağıdaki gömülü tipleri destekler: long (signed ve unsigned) 32-bit aritmetik tipleri. long long (signed ve unsigned) 64-bit aritmetik tipleri. short (signed ve unsigned) 16-bit aritmetik tipleri. float, double, ve long double IEEE 754-1985 kayan nokta tipleri char ve wchar – karakter ve geniş karakter tipleri. boolean – mantıksal tip. octet – 8-bit değer. enum – sayı tipi. any – gömülü tipleri ve kullanıcının tanımladığı tipleri de içeren OMG IDL tiplerinden, bir değer tutabilen ek tip. CORBA tanımı, heterojen donanım platformları üzerinde çalışabilirliği sağlamak için, tüm temel tiplerin büyüklüklerini kesin bir biçimde tanımlar. 2.9.2. Yapısal Tipler (Constructed Types) OMG IDL yapısal tipleri de destekler: struct – veri bütünleştirme yapısı (C/C++’taki struct ile benzer) union – union tanımında belirtilen mümkün OMG IDL tiplerinden birinin bir değeri ile, bir tip ayırıcısından oluşan tip. OMG IDL union’ları C/C++’taki union’larla benzerdir. Fakat hangi alternatifin geçerli olduğu bilgisini de tutarlar. 2.9.3. ġablon Tipler (Template Types) OMG IDL, gerçek davranışı tanımlama anında tarif edilen şablon tipleri de destekler: string ve wstring – katar (string) ve geniş-karakter katarı tipleri. Her iki tip te, sınırlı veya sınırsız olarak tanımlanabilirler. Örneğin, 10 karakter uzunluk ile sınırlı bir string string<10> şeklinde tanımlanırken, sınırsız olarak tanımlamak için sadece string yazmak yeterlidir. 29 sequence – maksimum uzunluğu ve eleman tipi “< >” içinde tanımlanabilen dinamik uzunluklu lineer bir taşıyıcıdır. Örneğin, sequence<Fabrika>, Fabrika nesne referansının sınırsız bir serisini tanımlarken, sequence<string,10>, 10 karakter katarından fazla olamayacak sınırlı bir seri tanımlar. fixed – 31 adet anlamlı rakamdan fazla olmayan sabit noktalı ondalık değer. Örneğin fixed<5,2>, beş adet rakamda oluşur (2 tanesi ondalık), en fazla $999.99 gösterebilecek şekilde, parasal değerler için kullanılabilir. 2.9.4. Nesne Referans Tipleri (Object Reference Types) OMG IDL Nesne Referans Tipleri, istenilen arayüz tipini isimlendirerek kolaylıkla tanımlanabilir. Örneğin: // OMG IDL interface FabrikaBulucu { // bir Fabrika nesne referansları serisi tanımı typedef sequence<Fabrika> FabrikaSerisi; FabrikaSerisi fabrikalari_bul(in string interface_name); }; Bu OMG IDL tanımlaması, FabrikaSerisi adında bir tipin tanımını içeren, FabrikaBulucu isimli bir arayüzü tanımlar. FabrikaSerisi tipi, Fabrika nesne referanslarının sınırsız bir serisi olarak tanımlanır. fabrikalari_bul işi, sınırsız bir string tipini giriş argümanı olarak alır, ve Fabrika nesne referansları serisi döndürür. 2.9.5. Arayüz Miras Alma (Interface Inheritence) OMG IDL arayüzlerinin önemli bir özelliği, bir yada daha çok arayüzden miras alabilmeleridir. Bu, yeni servisler tanımlandığında, varolan arayüzleri tekrar kullanmayı mümkün kılar. interface Fabrika { Object yarat(); }; // Yukardaki OMG IDL örneği ile aynı 30 // Dosya arayüzünün ön tanımı, tam tanımı burada yok interface Dosya; // FabrikaDosyasi, Fabrika’dan türetiliyor interface FabrikaDosyasi : Fabrika { Dosya dosya_yarat; }; Bu örnekte, FabrikaDosyasi arayüzü Fabrika arayüzünden miras alınmıştır, böylece FabrikaDosyasi arayüzünü destekleyen bir nesne, iki iş sağlar: 1. Fabrika’dan miras alınmış yarat işi. 2. FabrikaDosyasi arayüzünün içinde tanımlanmış dosya_yarat işi. Arayüz miras alma CORBA’da çok önemlidir. Değişiklik için sistemi kapalı tutarken genişleme için sistemin açık olmasına izin verir (Açık-Kapalı Prensibi). Türetilmiş bir arayüz, tüm temel arayüzlerinde tanımlı tüm işleri miras aldığından dolayı, türetilmiş arayüzü destekleyen nesneler tüm miras alınmış işleri de desteklemelidirler. Bu, türetilmiş arayüzler için nesne referanslarının, temel arayüzler için nesne referanslarının kabul edildiği her yere yedeklenebilmesine izin verir. Örneğin, bir FabrikaDosyasi nesne referansı, bir Fabrika nesne referansının kabul edildiği her yerde kullanılabilir, çünkü FabrikaDosyasi tüm Fabrika işlerini destekler. Böylece FabrikaDosyasi nesnelerinin yeni yetenekleri, Fabrika arayüzünü kullanan varolan uygulamaları veya Fabrika arayüzünün kendisini değiştirmeden sisteme eklenebilir. OMG IDL arayüz miras almanın özel bir durumuna sahiptir: tüm arayüzler, tamamıyla CORBA modülünde tanımlı Object arayüzünden türetilmiştir. Tüm arayüz tanımlamaları aşağıdaki gibidir: // CORBA::Object tüm arayüzler için temel arayüzdür interface Fabrika : Object { ... }; CORBA::Object’ten alınan bu miras tüm OMG IDL arayüzleri için otomatik olduğundan, burada görüldüğü gibi açıkça tanımlanmasına gerek yoktur. 31 OMG IDL tip sistemi birçok dağıtık uygulama için yeterlidir, ve aynı zamanda minimaldir ve bu düzeyde tutulmaya devam edilmektedir. OMG IDL’yi olabildiğince basit tutmak demek, onun çok daha fazla programlama dili ile kullanılabilmesi demektir. Bazı programlama dillerinde gerçeklenemeyecek tipleri içerseydi bu dillerle kullanılamazdı. OMG IDL’nin basitliği CORBA’nın entegrasyon teknolojisindeki başarısında önemli rol oynar. 2.10. Dil EĢlemeleri Daha önce de bahsettiğimiz gibi, OMG IDL tam olgunlaşmış bir programlama dili değil, sadece tanımsal bir dildir. Böyle olunca, kontrol yapıları gibi özellikleri ihtiva etmez, dağıtık uygulamaların yürütülmesinde direkt olarak kullanılamaz. Dil eşlemeleri, OMG IDL özelliklerinin verilen bir programlama dilinin imkanları ile nasıl eşleneceğini belirler. Bir dil eşlemesinin neleri içerdiğini anlamak için, C++ dili için eşlemeyi göz önüne alalım. OMG IDL arayüzleri C++ sınıfları ile, bu sınıfların üye fonksiyonları ile işlerin eşlenmesi yoluyla eşlenir. Nesne referansları operator-> fonksiyonunu destekleyen nesnelerle eşlenir (örn., arayüz sınıfına normal bir C++ işaretçisi (pointer), veya bir overloaded operator-> ile nesne örneği). Module’ler C++ namespace’leri ile eşlenir (veya henüz namespace’leri desteklemeyen, C++ derleyicileri için iç içe geçmiş (nested) sınıflarla). OMG IDL tiplerinin geri kalanı ile eşlemeler Tablo 2.1’de gösterilmiştir. OMG IDL Tipi long, short float, double enum char boolean octet any struct union string wstring sequence fixed nesne refereransı arayüz C++ EĢleme Tipi long, short float, double enum char bool unsigned char Any sınıf struct sınıf char* wchar_* sınıf Fixed şablon sınıfı işaretçi veya nesne sınıf Tablo 2.1. OMG IDL Tipleri İçin Eşlemeler 32 OMG IDL dilinin CORBA tanımında bulunan ORB arayüzü ve diğer sahte-nesneler (pseudo-objects) ile nasıl eşlendiği de başka bir önemli noktadır. Sahte-nesneler tamamen CORBA::Object’ten türetilmemiş ORB arayüzleridir. Başka bir deyişle, sahte-nesneler gerçek CORBA nesneleri değildirler. Ama bu arayüzleri normal nesne arayüzleri gibi tanımlamak, uygulamaların normal nesneleri idare eder gibi ORB’yi de idare etmesine izin verir. CORBA’nın yeni sürümlerinde, sahte-nesneler yavaş yavaş elimine edilmekte, ve tüm CORBA arayüzleri normal OMG IDL’de tanımlanmaktadırlar. CORBA nesnelerinin dil içinde nasıl yürütüldükleri de önemlidir. Java, Smalltalk ve C++ gibi nesneye yönelik dillerde, CORBA nesneleri programlama dili nesneleri gibi yürütülürler. C’de ise, nesneler soyut veri tipleri olarak yazılırlar. Örneğin, tipik bir yürütme, nesnenin durumunu tutan bir struct ile bu durumu idare eden bir grup C fonksiyonundan (nesne tarafından desteklenen OMG işleri ile ilgili olan fonksiyonlar) oluşur. OMG IDL dil eşlemeleri, yürütmenin “gerçek dünyası” ile CORBA’da tanımlanan kavramların buluşma noktasında yer alır. Bu yüzden CORBA uygulamalarındaki önemleri göz ardı edilemez. Verilen bir dil için zayıf veya yarım kalmış bir eşleme tanımlaması, programcıların CORBA teknolojisini bu dilde verimli bir şekilde kullanmalarını imkansız kılar. Dil eşleme tanımlamaları, yeni uygulamalar yazıldıkça ortaya çıkan yeni ihtiyaçları yerine getiren özellikleri eklemek gibi, programlama dillerinin evrimi ile birlikte, periyodik olarak ilerlemelidirler. 2.11. Arayüz Ambarı Her CORBA-tabanlı uygulama çalıştırıldığı zaman OMG IDL tip sistemine erişmeye ihtiyaç duyarlar. Bu gereklidir, çünkü uygulama istenilen argümanlar olarak geçirilecek değerlerin tiplerini bilmek zorundadır. Uygulama, kullanılan nesneler tarafından desteklenen arayüzlerin tipini de bilmek zorundadır. Birçok uygulama, sadece OMG IDL tip sisteminin statik bilgisine ihtiyaç duyar. Tipik olarak, bir OMG IDL tanımlaması uygulamanın programlama dilinde derlenir, veya kendi dil eşlemesi tarafından tanımlandığı gibi, bu dil için dönüştürme kurallarını takip ederek dönüştürülür. Daha sonra, oluşturulan bu kod uygulamanın içine direkt olarak yerleştirilir. Bu yaklaşımla, uygulamanın OMG IDL tip sistemi bilgisi kurulduğu anda sabitlenir. Eğer dağıtık sistemin geri kalanının tip sistemi uygulamaya yerleştirilen tip sistemine uyumsuz bir biçimde değişirse, uygulama yeniden yapılandırılmalıdır (rebuilt). Örneğin, bir istemci uygulaması Fabrika arayüzüne bağlı ise, ve Fabrika arayüzündeki yarat işinin ismi 33 fabrika_yarat olarak değiştirilirse, uygulama herhangi bir Fabrika nesnesine istek yapmadan önce yeniden yapılandırılmalıdır. Bununla beraber, OMG IDL tip sisteminin statik bilgisinin elverişsiz olduğu uygulamalar da vardır. Örneğin, bir yabancı nesne sistemindeki uygulamaların (Microsoft Component Object Model uygulamaları gibi) CORBA nesnelerine erişmelerine izin veren bir Geçit (Gateway) düşünelim. Birileri sisteme yeni bir OMG IDL arayüz tipi ekledikçe geçidi yeniden derlemek ve yeniden yapılandırmak, çok büyük bir idare ve bakım problemi yaratır. Bunun yerine, geçidin tip bilgisini gerekli oldukça dinamik olarak bulması ve istifade etmesi daha iyi olacaktır. CORBA Arayüz Ambarı (IR – Interface Repository), OMG IDL tip sistemine çalışma zamanında erişilmesine izin verir. IR’ın kendisi, diğer CORBA nesnelerinde olduğu gibi işleri çağrılabilen bir CORBA nesnesidir. IR arayüzünü kullanarak, uygulamalar OMG IDL bilgisinin tüm hiyerarşisini tarayabilirler. Örneğin, bir uygulama IR’ın üst düzey sahasından başlayıp orada tanımlanmış tüm module tanımlamalarını tarayabilir. Aranan module bulunduğunda, onu açabilir ve benzer bir biçimde içindeki tüm tanımlamalar üzerinde tarama yapabilir. Bu hiyerarşik arama yaklaşımı, bir IR içinde saklanan tüm bilgileri bulmak için kullanılabilir. IR bilgisine erişmek için başka (ve muhtemelen daha verimli) bir yol, CORBA::Object arayüzünde tanımlanmış get_interface işinden InterfaceDef nesne referansını elde etmektir. Tüm arayüzler CORBA::Object’ten türetildikleri için, tüm nesneler get_interface işini destekler. Bunun için, InterfaceDef nesne referansı her nesneden, o nesne tarafından desteklenen arayüzlerin türetilmiş tiplerini bilmeye gerek olmadan da, elde edilebilir. Uygulamaların tip bilgisini çalışma zamanında araştırmalarına izin vermesi sayesinde, IR’ın gerçek faydası CORBA dinamik çağrısını desteklemesinin altında yatar. Aynı zamanda, IR’daki OMG IDL tanımlamaları, OMG IDL dosyasında yazılanlar ile aynı olduğundan, uygulamalar için statik destek kodu oluşturmada bir kaynak olarak kullanılabilir. 2.12. CORBA’nın Bugünü ve Yarını 2.12.1. MDA – Model Driven Architecture MDA (Model Güdümlü Mimari) OMA’nın geliştirilmesi ile oluşturulmuştur. MDA, UML (Unified Modeling Language – Birleştirilmiş Modelleme Dili), MOF (Meta-Object 34 Facility – Meta-Nesne Vasıtası), ve CWM (Common Warehouse Meta-model – Genel Depo Meta-modeli) gibi OMG’nin geliştirdiği modelleme standartlarını biraraya getirmektedir. Bu modelleme standartları kullanılarak yapılmış platform bağımsız uygulama tanımları, CORBA, Java, .NET, XMI/XML ve Web-tabanlı platformlar gibi, herhangi bir açık veya özel platform kullanılarak gerçeklenebilmektedir. 2.12.1.1. UML – Unified Modeling Language UML, yazılım sistemlerinin olduğu kadar iş modellerinin ve diğer sistemlerin de yapısını tanımlamak, canlandırmak, yapılandırmak ve belgelemek için geliştirilmiş bir dildir. Büyük ve karmaşık sistemlerin modellenmesinde başarılılığı ispatlanmış en iyi mühendislik pratiklerinin bir koleksiyonunu sunar. UML, National Software ve ortakları tarafından geliştirilmiştir. Birçok firma, iş modelleme, ihtiyaç yönetimi, analiz & tasarım, programlama ve test etme gibi disiplinleri kapsayan ürünlerini geliştirirken UML’yi bir standart olarak kullanırlar. 2.12.1.2. MOF – Meta-Object Facility MOF, OMG’nin tüm modelleme özellikleri için genel bir meta-model tanımlayarak, türetilmiş özelliklerin doğal bir biçimde bir arada çalışmasına izin verir. MOF aynı zamanda meta-modeller, ve dolayısıyla da modeller için (bir meta-model bir modelin özel bir durumu olduğu için) standart bir ambar tanımlar. 2.12.1.3. CWM – Common Warehouse Meta-model CWM, bir şirket içindeki veya daha uzaktaki veritabanı sınırları içinde veriyi bulup getirmeye izin veren tamamlanmış geniş kapsamlı bir meta-model standardı sunar. OMG ve MDC (Meta-Data Coalition) ortak çalışmasının bir ürünü olan CWM, UML’nin uygulama modeli için yaptığını veritabanı modeli için yapar da diyebiliriz. 2.12.2. CORBA 3 2001’de duyrulan ve 2002’de tanımlamalarının yayınlanması beklenen CORBA 3 ile getirilmesi düşünülen yenilikleri üç temel kategoride ele alabiliriz. 2.12.2.1. Java ve Internet Entegrasyonu 1. CORBA 2.3’ten beri varolan nesnelerin değer olarak geçirilebilmesi özelliği geliştirilecek. 35 2. Java-to-IDL eşlemesi sayesinde, Java RMI nesneleri ağ üzerinde CORBA nesneleri gibi çalışabilecekler, CORBA nesne referansları olacak, ve IIOP protokolünü kullanacaklar. Yani uygulamalarda CORBA bileşenlerinin ve EJB’lerin (Enterprise Java Beans) kütüphanelerinin beraber çalışabilmesi sağlanacak. 3. Nesne referansları URL biçiminde tanımlanabilecek. Bu özelliği sağlayan Interoperable Name Service 2000’in sonlarına doğru çıkan CORBA 2.4’te de vardı. 4. CORBA’nın firewall’lardan güvenli bir biçimde geçebilmesi için gerekli yetenekler arttırılacak. 2.12.2.2. Servis Kalitesi Kontrolü 1. Yeni mesaj gönderme özelliği, CORBA için hem statik hem de dinamik olarak çağrılabilecek birçok zaman-bağımlı ve asenkron çağrı biçimleri tanımlamıştır. Politikalar çağrıların servis kalitesinin kontrolüne izin verirler. Bu özellik te 2.4 sürümünde eklenmiştir. 2. Yine 2.4 sürümünde eklenmiş olan minimumCORBA, gömülü ve kart tabanlı sistemlerde kullanılmak üzere tasarlanmıştır. Bu sistemler yongalar üzerinde yer aldıkları ve güncellenmedikleri için CORBA’nın dinamik özelliklerine ihtiyaç duymazlar. Bu sebepten, Dinamik Çağrı Arayüzü ve Arayüz Ambarı gibi özellikler minimumCORBA’da yer almazlar. 3. Yine 2.4 sürümünde eklenmiş olan Gerçek-zamanlı CORBA, kaynak kontrol thread’leri, protokoller, bağlantılar, ve bunlar gibi şeyleri öncelik modelleri kullanarak standartlaştırır. 4. Henüz eklenmemiş olan hata toleranslı CORBA, yazılım konfigürasyonlarını ve sistemlerini standartlaştırarak daha fazla güvenilirlik ve daha sağlam performans sağlayacak. 2.12.2.3. CORBAcomponents Mimarisi 1. OMG’nin CORBA 2 için geliştirdiği IIOP’den sonra yaptığı en önemli gelişmelerden biri olan CORBAcomponents, hareketlilik, güvenlik ve devamlılığı paketleyen, ve arayüz ile olay çözümü sağlayan bir taşıyıcı ortam içerecek. Bunun yanında, CORBAcomponent yazılım pazarına imkan verecek bir yazılım yayımlama biçimi, ve EJB ile entegrasyonu da içerecek. Bir kurulum ve XML-tabanlı konfigürasyon aracı da içerecek. 2. Script diller CORBA istemci ve nesnelerine erişebilecekler. Şu anda biri Python diğeri de CORBA-özel script dili olmak üzere iki script dili desteklenmektedir. 36 5.12.3. CORBA Yürütmeleri OMG gerçek yazılım üretmez, sadece ayrıntılı tanımlar üretir. CORBA yürütmelerini, OMG’ye üye olan veya olmayan yazılım üreticileri, OMG’nin tanımladığı standartlar doğrultusunda üretirler. OMG bugüne kadar CORBA için, Ada, C, C++, COBOL, CORBA Scripting Language, Java, Lisp, Python ve Smalltalk dillerine yönelik dil eşlemeleri tanımları oluşturmuştur. Bu dil eşlemelerini kullanarak, üreticiler Windows’ta ve diğer platformlarda çalışan CORBA yürütmeleri gerçekleştirmişlerdir. Bu yürütmelerden bazıları Tablo 2.2’de verilmiştir. Orbix ve ORBacus yürütmelerinin destekledikleri platformlar ve derleyiciler de örnek teşkil etmesi açısından Tablo 2.3 ve Tablo 2.4’te gösterilmiştir. Yürütme Üretici Tipi Desteklediği Diller VisiBroker Inprise (Borland) Ticari C++, Java Orbix IONA Ticari C++, Java ORBacus IONA Ücretsiz C++, Java e*ORB Vertel Ticari C++, Java vbORB Martin Both Ücretsiz Visual Basic The ACE ORB Washington University Ücretsiz C++ Ücretsiz Ada AdaBroker the Computer Science department of the École Nationale Supérieure des Télécommunications in Paris, France. Tablo 2.2. CORBA Yürütmeleri İşletim Sistemi Derleyici Windows NT4 (SP6a) C6.0 (SP3) & JDK 1.3 Windows 2000 VC6.0 (SP3) & JDK 1.3 Windows 98 2nd Edition (Client only) VC6.0 (SP3) & JDK 1.3 Linux RedHat 6.2 GCC 2.95.2 & JDK 1.3 Solaris 2.6 (SunOS 5.6) Sun C++ 5.2 (Forte 6.1) & JDK 1.3 Solaris 2.6 GCC 2.95.2 Solaris 2.8 (SunOS 5.8) 32 & 64 bit Sun C++ 5.2 (Forte 6.1) & JDK 1.3 HP-UX 11.0 - 32 & 64 bit HP ANSI C++ aCC A03.25 & JDK 1.3 HP-UX 11i - 32 bit HP ANSI C++ aCC A03.25 & JDK 1.3 AIX 4.3.3 Visual Age 5.0 & JDK 1.3 Compaq Tru64 5.1 Compaq C++ 6.2 & JDK 1.3 Tablo 2.3. ORBIX’in Desteklediği Platformlar ve Derleyiciler 37 İşletim Sistemi Derleyici Solaris 2.6/7/8 Forte C++ 6 Update 2 Solaris 2.6/7/8 GCC 2.95.3 HP-UX 11 HP ANSI C++ A.03.27 Windows NT/2000 Visual C++ 6.0 Linux GCC 2.95.3 Compaq Tru64 5.1 C++ 6.2 (024) AIX 4.3.x VA C++ 5.0 with 5.0.0.2 PTF Solaris 2.6/7/8 JDK 1.3 HP-UX 11 JDK 1.3 Windows NT/2000 JDK 1.3 Linux JDK 1.3 Compaq Tru64 5.1 JDK 1.3 AIX 4.3.x JDK 1.3 SGI IRIX 6.5 JDK 1.3 Tablo 2.4. ORBacus’ün Desteklediği Platformlar ve Derleyiciler 38 3. DCOM DCOM, OLE’nin ve ActiveX’in altyapısını oluşturan COM (Component Object Model)’dan geliştirilerek oluşturulmuştur. COM, yazılım bileşenlerini geliştirmek ve yaymak amacıyla kullanılan nesne tabanlı bir çatıdır. COM, geliştiricilerin soyutlamaları bileşen arayüzleri olarak elde etmelerine izin verir, ve bu arayüzleri yürüten sınıfları sağlar. İstemci uygulamaları sadece bir nesnenin arayüzünde tanımlı olan fonksiyonları çağırabilirler (encapsulation). COM’un ikili birlikte çalışabilirlik (binary interoperability) standardı, yazılım bileşenlerinin geliştirilmesini ve bu bileşenlerin ikili (binary) biçimde yayılmasını sağlar. Sonuç olarak bağımsız yazılım geliştiriciler, tekrar kullanılabilen yapı bloklarını geliştirebilir ve kaynak kodunu taşımadan paketleyebilirler. DCOM (Distributed COM), uzak yöntem çağrıları, güvenilirlik, ölçeklenebilirlik ve yer şeffaflığı sağlayarak, COM’un ağ üzerinde çalışmasını sağlamıştır. DCOM’un COM’u ne yönden geliştirerek ağ üzerinde çalışmasını sağladığını anlatmadan önce, COM mimarisinin temellerine biraz değinelim. 3.1. COM – Component Object Model COM, farklı zamanlarda, farklı üreticilerin, çeşitli diller, araçlar ve platformlar kullanarak oluşturdukları yazılım bileşenlerinin geliştirilmesine izin vermek üzere tasarlanmış, bir nesne-tabanlı programlama modelidir. COM bileşenleri kolaylıkla yayılabilir ve müşterinin sistemine entegre edilebilir. 3.1.1. Arayüzler Bir COM arayüzü, bir yazılım bileşeninin davranışlarını ve yeteneklerini, bir yöntemler ve özellikler kümesi olarak tanımlar. Bir arayüz, onu destekleyen nesnelerden anlamsal olarak tutarlı bilgileri alacağını garanti altına alan bir anlaşmadır. Her COM nesnesi birden çok arayüzü aynı anda destekleyebilir. Nesneler en az bir arayüzü (IUnknown arayüzü) mutlaka desteklemelidirler. Bileşen tasarımcıları arayüzleri DCE RPC IDL’nin nesneye-yönelik olacak şekilde geliştirilmiş hali olan MIDL (Microsoft's Interface Definition Language) kullanarak tanımlarlar. Microsoft, bir arayüz tanımından C veya C++ dillerinde proxy ve stub kodu oluşturan bir MIDL derleyicisi sağlar. Oluşturulan proxy kodu, arayüzü destekleyen nesneler 39 için, bir istemci tarafı uygulama programlama arayüzü (API – Application Programming Interface) sağlar. Stub nesneleri gelen istemci isteklerinin şifresini çözer (decode) ve sunucudaki ilgili nesneye bunları iletirler. Arka planda, istekleri ve cevapları değerlendirmek için proxy ve stub kodları ilgili çalışma zamanı kütüphanelerle etkileşime girerler. COM çalışma zamanı yazılımı, nesneler istemci ile aynı işlemde bulunuyorsa, bu fazladan işi yapmayacak kadar akıllıdır. Bileşen tasarımcıları, her arayüze, her zaman ve her yerde tek olan bir belirleyici (UUID – Universally Unique Identifier) atayarak, isim çakışmalarından doğabilecek belirsizlikleri ortadan kaldırırlar. Arayüz belirleyicisi (IID – Interface Identifier) olarak adlandırılan bu belirleyici, aynı zamanda COM’un arayüz uyarlama modelinin temel taşıdır. Her COM nesnesinin en azından IUnknown standart arayüzünü desteklemesi gerektiğini söylemiştik. IUnknown, nesne yaşam döngüsünün yönetilmesi için temel yapı bloklarını sağlayan, ve bir nesne tarafından desteklenen arayüzlerin gelişimine izin veren yöntemleri tanımlar. IUnknown arayüzünün QueryInterface yöntemi, bir IID olarak tanımlanan belirli bir arayüzün bir nesne tarafından desteklenip desteklemediğini belirlemek için istemciler tarafından kullanılır. Zamanla, bir nesne yeni arayüzleri veya her birinin farklı IID’si olan aynı mantıksal arayüzün yeni sürümlerini destekleyebilir. Varolan istemciler, yeniden derlenmeden bir arayüzün daha eski bir sürümünü kullanmaya devam edebilirler, ve yeni istemciler arayüzün son sürümünü sorgulayabilir ve bu sayede eklenen yeniliklerden faydalanabilirler. QueryInterface, arayüz işaretçisi (interface pointer) denilen bir işaretçi döndürür. Arkaplanda, bir arayüz işaretçisi COM’un ikili birlikte çalışabilirlik standardı tarafından dikte ettirilen bir veri yapısına işaret eder. Standart, istemci ve sunucu programlarının yürütme bileşenleri arasındaki farkları önemsemeden, çağrılması gereken yön arayüz fonksiyonlarını dikte eder. 3.1.2. Sınıflar ve Sunucular Arayüzler kendi başlarına COM uygulamaları oluşturmak için yeterli değildirler. Bir COM sınıfı, bir yada daha çok COM arayüzünün bir yürütmesi olan bir kaynak kodunun gövdesidir. Desteklediği her arayüz yöntemi için, desteklenen herhangi bir programlama dilinde, gerçek fonksiyonlar sağlar. 40 Her arayüz bir IID tarafından tekil olarak tanımlandığından, her COM sınıfı CLSID adı verilen bir tekil belirleyici ihtiva eder. Bir istemci uygulamanın, bir bileşenle etkileşime girmesi için, en az bir CLSID ve bu sınıf tarafından desteklenen arayüz için bir IID hakkında bilgi sahibi olması veya öğrenebilecek konumda olması gerekmektedir. Bir istemci bu bilgiyi kullanarak, bir nesne üretmek ve bir ilgili arayüz işaretçisi döndürmek için COM’dan izin ister. Bir yada daha çok COM sınıfı, kullanılabilecek çeşitli tekniklerden biri kullanılarak bir sunucunun içine yerleştirilir. Sunucunun içindeki bir sınıfa bir istemci tarafından ilk kez erişildiğinde, bir COM sunucusu istemci işleminde yüklenen bir dinamik bağlantı kütüphanesi (DLL – dynamic link library) olarak paketlenebilir. Buna, işlem içi sunucu (in-process server) denir. ActiveX kontrolü, bir işlem içi COM sunucusudur. Bir COM sunucusu ayrı ayrı çalışabilecek şekilde de paketlenebilir. Bu tip bir sunucu, bir istemci ile aynı makinede veya DCOM kullanılarak erişilebilen uzak bir makinede yürütülebilir. Bu sunuculara, işlem dışı sunucular (out-of-process server) denir. Aynı istemci kodu, farklı COM sunucu tipleri ile etkileşebilir. İstemci İşlemi Yerel Sunucu İşlemi İşlem-içi Nesne İşlem-içi Sunucu İstemci Uygulama Yerel Nesne Proxy Stub Yerel Nesne COM Uzak Makine Uzak Sunucu İşlemi COM Uzak Nesne Proxy Stub Yerel Nesne COM ġekil 3.1. İstemciler, Yerel Sunucular ve Uzak Sunucular İstemci uygulamaları, arayüz işaretçileri vasıtasıyla COM nesneleri ile etkileşirler. COM tarafından sağlanan encapsulation, bir istemcinin, bir COM nesnesinin herhangi bir yürütme detayına bağlı olmamasını sağlar. İşlem içi sunucular söz konusu olduğunda, bir istemci tarafından, bir arayüz işaretçisi kullanılarak yapılan çağrılar, direkt olarak istemcinin işleminde yaratılan bir nesneye gider. Bir işlem dışı sunucudan nesnelere yapılan çağrılar, ilk önce, bir uzak prosedür çağrısı (RPC) kullanarak çağrıyı başlatmaktan sorumlu olan işlem içi proxy nesnesine gider. İşlem dışı sunucuda, stub nesnesi gelen her çağrıyı alır ve ilgili COM 41 nesnesine gönderir. ġekil 3.1, farklı biçimlerde paketlenmiş COM nesneleri ile etkileşime giren bir COM nesnesini gösteriyor. ġekil 3.1’de görüldüğü gibi, DCOM yer ve paketleme şeffaflığı sağlar. Bir nesne, işlem içi, yerel makinede işlem dışı, veya uzak bir makinede işlem dışı olabilir. İşlem dışı sunucular söz konusu olduğunda, DCOM arayüze-özel proxy ve stub kodu (tipik olarak bir IDL dosyasından oluşturulur) ile bir RPC mekanizması kullanır. 3.1.3. Nesne YaĢam Döngüsü Arayüz ve sınıf kavramları, ve COM istemcisi ile sunucusu arasındaki haberleşme konuları hakkında fikir edindikten sonra, şimdi de bir istemcinin, bir COM nesnesini nasıl oluşturduğunu inceleyelim. Her COM nesnesi bir COM sınıfının bir örneğidir. Her COM sınıfı, görevi bir COM sınıfının örneklerini oluşturmak olan, sınıf fabrikası denilen başka bir COM sınıfı ile ilişkilidir. COM’un fabrika mekanizması ġekil 3.2’de gösterilmiştir. Fabrika tipik olarak, COM tarafından tanımlanmış standart bir arayüz olan IClassFactory’i destekler. Verilen bir CLSID ve ilgili COM sunucusunun bir tanımı ile, COM çalışma-zamanı (run-time) verilen CLSID için bir fabrika tayin edebilir. İstemci 1. Bir nesne yarat *6. İstekleri direkt olarak çağır Sunucu Nesne COM 2. 3. 4. 5. Sunucuyu Bul DLL’i yükle veya EXE’yi çalıştır Sınıf Fabrikasını elde et Fabrikadan yaratma izni al Sınıf Fabrikası ġekil 3.2. COM Sunucuları, Açık Sınıflar ve Sınıf Fabrikaları ġekil 3.2’de görüldüğü gibi, istemci uygulaması yeni bir nesne yaratma isteği gönderdiğinde, COM sunucuyu bulur, yükler yada başlatır, ve nesneyi yaratabilmek için fabrikaya danışır. COM bir arayüz işaretçisini istemciye döndürür, ve sonraki çağrılar direkt olarak COM nesnesine gider. Bir istemci uygulaması, bir COM sınıfı için, sınıfın bir örneğini oluşturmak üzere, standart bir biçimde fabrika ile etkileşime girer, ve oluşan COM nesnesine bir arayüz işaretçisi bulur. ġekil 3.3, COM arayüzleri, sınıfları ve nesneleri arasındaki ilişkiye dair bir örnek gösteriyor. 42 Arayüzler Sınıflar IUnknown QueryInterface() AddRef() Release() Yürütmeler Motor Sınıfı Iunknown Yürütmesi Mirasların Alınması IMotor Yürütmesi IMotor Baslat() Durdur() Ayarla() BenzinEkle() TipiniAl() HızıDegistir() Motor Fabrikası Yaratımlar IMotor IMotor IUnknown motor_1 IUnknown motor_2 Nesneler ġekil 3.3. Arayüzler, Sınıflar ve Nesneler ġekil 3.3’te görüldüğü gibi, bir COM arayüzü, ilgili yöntemler kümesini tanımlar, ve tekil bir arayüz belirleyicisine atanır. Bir COM sınıfı, bir yada daha çok arayüzü yürütür, ve tekil bir sınıf belirleyicisine atanır. Her COM sınıfı, COM nesneleri yaratmaktan sorumlu olan bir sınıf fabrikasına sahiptir. Bir COM nesnesi oluşturulduğunda, COM bir nesneye doğru ne kadar önemli referans bulunduğunu, ve bu nesnenin ne zaman yok edilebileceğini takip etmek için standart bir protokol belirler. COM nesneleri, IUnknown arayüzünde tanımlanan AddRef ve Release yöntemleri ile işletilen bir referans sayısı muhafaza eder. Her COM sınıfı, örneklerinin varolan kullanımlarının sayısını takip etmek için bu yöntemleri yürütmelidir. Geliştiricinin tercihine bağlı olarak bu referans takibi, nesnenin tümü için tek bir sayı ile yapılabileceği gibi, nesnenin desteklediği her arayüz için ayrı sayılar ile de yapılabilir. Referans sayısı sıfır olduğunda, bu nesneye işaret eden herhangi bir istemci kalmadığı, ve bu yüzden artık yok edilebileceği kabul edilir. QueryInterface’in de aralarında bulunduğu arayüz işaretçileri döndüren yöntemler, bir nesneye yeni bir referans belirtmek için AddRef’i çağırmalıdırlar. Arayüz işaretçileri kullanan istemciler, arayüz işaretçisine erişimlerini tamamladıklarında Release’i çağırmalıdırlar. 3.1.4. Ġkili Birlikte ÇalıĢabilirlik (Binary Interoperability) COM’un ana teması bileşenlerin birbirleri ile çalışabilmeleridir. Buraya kadar, COM tüm yöntem çağrımları için arama yığınının (call stack) planını dikte eden bir ikili arama standardı tanımlamıştır. DCOM bu birlikte çalışabilirliği, bir ağ birlikte çalışabilirlik 43 protokolü tanımlayarak büyütür. Bu birlikte çalışabilirlik tanımlamaları, geliştiricilerin farklı istemci ortamları için özelleştirme yapmalarına gerek bırakmadan, sadece bileşenlerin yapılandırılması ile ilgilenmelerini sağlar. İkili standart, kaynak koduna erişim olmadan hazır bileşenlerin kullanılmasını kolaylaştırır. İkili standart, bir arayüz işaretçisini, bir fonksiyon tablosuna doğru bir işaretçiye işaret eden bir işaretçi gibi tanımlar. İşlem içi sunucular için, fonksiyon tablosu gerçek nesne yürütme fonksiyonlarına işaret eder. İşlem dışı sunucular için, fonksiyon tablosu proxy fonksiyonlarına işaret eder. 3.1.5. Paketleme ġeffaflığı COM mimarisinin temel özelliklerinden biri paketleme şeffaflığıdır. Geliştiriciler nesneleri DLL veya EXE olarak yayabilirler. COM istemci uygulamaları bir sunucunun nasıl paketlendiği ile veya DLL’inin veya EXE’sinin nerede olduğu ile ilgilenmek zorunda değildirler. Bunun yerine, uygulama istenilen bir CLSID’ye dayandırılan nesneleri yaratmak için COM’u kullanır. İstemci sunucu çeşitlerini sınırlayabilir, ama bunu yapmaya ihtiyacı yoktur. İşlem içi sunucular ile etkileşimli olan istemci kodu, işlem dışı sunucular ile de etkileşime girebilir. COM kütüphanesi istenilen bir sınıfın yürütmesine konumlanır ve istemci ile sunucu arasında bir iletişim kurar. COM, COM sınıflarının geliştiricilerinin sunucunun tipi hakkındaki bilgileri ve DLL’inin veya yerel bir kayıttaki EXE’nin yerini kayıt etmelerine ihtiyaç duyarak, bu servisi teklif eder. COM’un Servis Kontrol Yöneticisi (SCM – Service Control Manager)’nin görevi, kayıtlardan CLSID’yi aramak, ve sunucuyu aktif hale getirmek için ilgili faaliyeti yerine getirmektir. Geliştiriciler SCM ile direkt olarak etkileşimde bulunmazlar; bunun yerine, COM kütüphanesi bir nesne yaratılacağı veya bir sınıf fabrikası bulunacağı zaman SCM’yi kullanır. 3.2. DCOM – Distributed Component Object Model Dağıtık COM, COM tarafından duyurulan programlama modelini ağ üzerinden çalışabilecek şekilde geliştirmiştir. Bu geliştirmelerin içinde daha fazla yer ve paketleme şeffaflığı, ek threading modelleri, yeni güvenlik seçenekleri, ve ek yönetimsel yetenekler vardır. Önce DCOM’un COM’u nasıl geliştirdiğini şekiller üzerinde inceleyecek, sonra da bu geliştirmelere kısaca değineceğiz. 44 COM, bileşenlerin ve istemcilerinin nasıl etkileşeceğini tanımlar. Bu etkileşim, istemci ve bileşenin, hiçbir ara sistem bileşenine ihtiyaç duymadan haberleşebilecekleri şekilde tanımlanır. İstemcinin bileşendeki yöntemleri doğrudan çağırması ġekil 3.4’te gösterilmiştir. Günümüz işletim sistemlerinde, işlemler birbirlerinden ayrı şekilde muhafaza edilirler. Başka bir işlemdeki bir bileşenle haberleşmek isteyen bir istemci, bileşeni direkt olarak değil de, işletim sistemi tarafından sağlanan bazı ara işlemleri kullanarak çağırır. COM bu haberleşmeyi tamamen şeffaf bir biçimde sağlar. İstemci çağrılarının yolunu keserek, onları başka bir işlemdeki bileşene gönderir. COM/DCOM çalışma zamanı kütüphanelerinin istemci ve bileşen arasındaki bağlantıyı nasıl sağladıkları ġekil 3.5’te gösterilmiştir. İstemci ve bileşen farklı makinelerde yer aldıklarında, DCOM’un yaptığı iş, yerel birlikte çalışabilirlik haberleşmesini bir ağ protokolü ile değiştirmektir. Ne istemci ne de bileşen, aralarındaki bağlantıyı kuran telin biraz daha uzun olduğundan haberdar olmazlar. ġekil 3.6, DCOM mimarisini ana hatlarıyla gösterir. COM çalışma zamanı, istemcilere ve bileşenlere nesneye yönelik servisler sağlar, ve DCOM protokol standardına uyan standart ağ paketleri oluşturmak için, RPC ve güvenlik sağlayıcıyı kullanır. 3.2.1. Yer ve Paketleme ġeffaflığı COM ile, istemci uygulamaları sunucunun paketlenmesinden bağımsız olarak yazılır. COM nesneleri istemci işlemine yüklenebilir veya aynı makinede ayrı bir işlemde başlatılabilir. DCOM, nesnelerin ağda herhangi bir yerde olmalarına izin vererek yer şeffaflığı sağlamak için, bu şeffaflığı geliştirmiştir. DCOM “Nesne RPC” (ORPC – Object RPC)’si DCE RPC’yi temel alır. Bir nesne referans veri tipi içererek ve hedef nesne için her çağrımda bir parametre ekleyerek RPC’yi geliştirmiştir. Bir istemci, uzak nesne için bir COM sınıf fabrikasına başvurduğunda, yerel SCM uzak makinedeki SCM ile bağlantı kurar. Uzak SCM sunucuyu yerleştirir ve onu başlatır, ve sunucu tarafından sağlanan istenilen sınıf fabrikasına bir RPC bağlantısı döndürür. İstemci uygulaması için bir sınıf fabrikası proxy’si yaratılır, ve nesne yaratılması dağıtık olmayan durumda olduğu gibi devam eder. Önceki şeklimize SCM’nin görevini de eklersek, DCOM Mimarisi’nin daha ayrıntılı bir görünümünü elde etmiş oluruz (ġekil 3.7). 45 Nense (Bileşen) İstemci ġekil 3.4. Aynı işlemdeki COM bileşenleri Proxy Nesne İstemci Güvenlik Sağlayıcı Nense (Bileşen) Stub Güvenlik Sağlayıcı DCE RPC LPC DCE RPC LPC ġekil 3.5. Farklı işlemlerdeki COM bileşenleri Proxy Nesne İstemci Güvenlik Sağlayıcı Stub Güvenlik Sağlayıcı DCE RPC Protokol Yığını Bileşen DCE RPC Protokol Yığını DCOM Ağ Protokolü ġekil 3.6. Farklı makinelerdeki COM bileşenleri (DCOM) Proxy Nesne İstemci CoCreateInstance Güvenlik Sağlayıcı Stub Güvenlik Sağlayıcı DCE RPC Protokol Yığını OLE32 Bileşen DCE RPC Protokol Yığını CoCreateInstance (Remote) Activation SCM DCOM Ağ Protokolü ġekil 3.7. DCOM Mimarisi SCM 46 İlgili yönetimsel ayarlar ile, istemciler ağ için özel kodlamalar olmadan uzak makinelerdeki DCOM nesnelerine erişebilirler. Bir yönetici, performans ve ayarlanabilirlikten en iyi şekilde istifade etmek için, çeşitli sunucu paketleme ve yerleştirme seçeneklerini deneyebilir. Alternatif olarak, istemciler yeni bir DCOM nesnesi yaratılırken erişilmesi gereken uzak ana bilgisayarı belirleyebilirler. Bu girdi, son kullanıcı tarafından kontrol edilen uygulama seçeneklerinden gelebilir. DCOM ile duyurulan başka bir paketleme seçeneği de, bir DCOM sunucusunu bir NT Servisi olarak yayabilme becerisidir. Bu yetenek, belirli bir sunucu makinesi çalıştığında sunucuyu idare etmek için ihtiyaç duyulan tutarlı ve elverişli bir mekanizma sağlar. 3.2.2. Serbest Threading Modeli Birçok faktör dağıtık nesne sistemlerinin ayarlanabilirliğini etkileyebilir. Tek makinede en yüksek verime ulaşmak için, geliştiriciler multithreaded sunucular kurmaya ihtiyaç duymuşlardır. Bu tip nesne eşzamanlılığı, sunucunun bir çok işlemcili sunucu makinesinin gücünde olmasına olanak sağlar. Önceden de belirttiğimiz gibi DCOM, sunucu paketleme modellerinden birindeki multithreaded sunucuların gelişimi için COM’un verdiği desteği geliştirmiştir. DCOM’un Windows NT 4.0 üzerinde standart olarak kullanılmaya başlanmasından önce, multithreaded COM sunucular, apartman modeli threading olarak adlandırılan bir threading biçimi ile sınırlandırılmışlardı. Bu model, her COM nesnesini, sadece o nesneyi yaratan tek bir thread tarafından erişilebilmesi ile sınırlıyordu. Windows NT 4.0 serbest threading adında bir eşzamanlı modeli duyurmuştur. Serbest threading ile, her gelen nesne çağrımı ayrı bir thread ile idare edilebilir, ve birçok gelen çağrı, tek bir nesne üzerinden, aynı zamanda ve farklı thread’lerle gönderilebilir. Gönderme işlemi, COM kütüphanesi tarafından, RPC çalışma zamanı kütüphanesi ile birleşme noktasından yönetilir. Yüksek performansa ihtiyaç duyan uygulamalar için, tüm nesnelerin thread güvenliğini sağlamak için mutex’ler gibi eş zamanlı ilkeller kullanma sorumluluğu geliştiricinin üzerindedir. 3.2.3. Güvenlik Herhangi bir dağıtık mimarinin güvenlik desteği, onun en önemli bölümlerinden biridir. DCOM, geliştirici ve yönetici tarafından ihtiyaç duyulduğunda seçilebilecek çok kademeli bir güvenlik sağlar. Bir bileşenin güvenliğini belirleyebilme becerisi, geliştiriciler için başka bir şeffaflık biçimi sağlar: Aynı ikili bileşen, hiç güvenliğe ihtiyaç olmayan bir 47 ortamda kullanılabileceği gibi, çok sıkı güvenlik gerektiren başka bir ortamda da kullanılabilir. DCOM, COM bileşenleri üzerinde Erişim Kontrol Listelerini (ACL – Access Control Lists) sağlayarak bu şeffaflığa ulaşır. Eğer istek yapan kullanıcının bileşene erişme izni yoksa, bileşen kodundan önce davranan DCOM, isteği reddedecektir. Yüksek güvenlik için, ACL’leri DCOMCNFG adlı bir araç ile yönetebilirsiniz. Bir yönetici bu aracı kullanarak, belirli bir makinedeki özel nesne sunucularına hangi kullanıcıların ve grupların erişebileceğini idare edebilir. Aynı zamanda, sadece yöneticilerin DCOM nesnelerine uzaktan erişmelerine izin veren makine bazlı varsayılan durumlar da geçerlidir. DCOM’un önerdiği bir ek güvenlik katmanı seviyesi de, hangi kullanıcıların ve grupların bir sunucu başlatmasına izin verildiğinin kontrol edilmesi yeteneğidir. Varsayılan durum, sadece yöneticilerin uzak DCOM nesnelerini başlatabilmelerine izin verilmesidir. Daha iyi güvenlik seviyelerine ulaşmak için, DCOM yöntemleri ayrık yöntem çağrımlarının kimlik denetimlerini program ile kontrol edebilir. Kayıt anahtarlarının (registry keys) ve Windows NT API’lerinin bir kombinasyonunun kullanılmasıyla, bir yöntem geleneksel güvenlik politikalarını yürütebilir. 3.2.4. Referans Sayımı ve Ping Gönderme Dağıtık uygulama geliştiricilerin karşılaştığı sorunlardan biri, istemcileri öldüğünde bunu algılayabilen sunucular yazmaktır. Bir nesnenin ne zaman gitmesi gerektiğine karar veren referans sayımının kullanılması nedeniyle, bu sorun DCOM’da özellikle önemlidir. Tipik çözüm, işlemin hala hayatta olduğunu, periyodik ping gönderimleri ile algılamaktır. Dağıtık nesneler dünyasında, ilgili işlemlerin durumunu bu şekilde takip etmek, istemciler ve sunucular arasında büyük bir ağ trafiğine neden olur. Neyse ki, DCOM mimarları yüksek performanslı ping gönderme desteği tasarlamışlardır. Ping göndermeyi en iyi şekilde kullanmak için, DCOM her makine için hayatta kalma mesajlarını kullanır. Bir ping mesajı makineler arasında, bir makinedeki istemci işlemleri sayısından ve belirli bir uzak makinede erişilmekte olan bileşen sunucularının sayısından bağımsız olarak, kullanılır. Eğer istemci işlemi ölürse, DCOM durumu algılar ve ilgili sunucu arayüz işaretçilerinde Release çağrılarını başlatır. Sıradan istekler üzerinde yüklü (piggybacking) ping mesajları, ve tüm uzak referanslar kümesini sürekli transfer etmek yerine sadece yapılan değişiklikleri takip etmek, DCOM’da bulunan ek özelliklerden bazılarıdır. 48 DCOM, bu takibi başarmak için, başka makineler tarafından değiştirilmiş nesneleri ve nesne referanslarını takip eden, Nesne İhracatçısı (Object Exporter) adında bir bileşen yürütür. Nesne İhracatçısı, verilen bir makine üzerindeki istemci işlemlerinin yaşayıp yaşamadıklarını takip etmekle sorumludur. 3.2.5. Yönetim Dağıtık nesne uygulamaları, son birkaç senede önemli bir şekilde gelişmiştir. Ama hala, geniş çaplı dağıtık nesne ortamlarının konfigürasyonu ve idaresi göz korkutan işlerdir. DCOM bu işi daha kolay hale getirmek için bazı araçlar sağlar, ama yeterli değildir. Her yayılan bileşenin, bir yada daha çok sunucu makinesinde kayıtlı olması gerektiği gibi ayrı istemci makinelerinde da kayıtlı olmaları gerekir. Ufak bir dağıtımda, kurulum ve muhafaza sorun değildir. İstemci ve sunucu makineleri ve bileşenlerinin sayılarının artmasıyla, ağ yöneticilerinin istemci isteklerinin yükünün birçok sunucu makineleri üzerindeki dengeli dağıtımı ile ilgilenmeleri gerekecektir. DCOM yük dengelemesi için yapısal bir destek içermez. Eğer bir uygulama yükü dinamik olarak dengeleyemiyorsa, ağ yöneticileri, belirli istemci makinelerinin belirli sunucuları kullanmalarını sağlamak gibi yöntemlerle, ortamı statik olarak düzenlemelidirler. Eğer bileşen farklı bir sunucu makinesine taşınmak zorunda kalınırsa, eski makineye yapılan her referans güncellenmelidir. DCOM’da, bir istemcinin özel bir makine yerine makinelerin bir listesinde sunucuyu araması gerektiğini gösterecek açıkça bir yol yoktur. 3.3. MIDL – Microsoft Interface Definition Language Microsoft Arayüz Tanımlama Dili (MIDL), dağıtık uygulamalarda kullanılan arayüzlerin yürütülmesi için geliştirilmiştir. COM ve DCOM tabanlı uygulamalar, arayüzlerini MIDL kullanarak tanımlarlar. MIDL, OSF-DCE IDL’den geliştirilerek üretilmiştir, ve birçok yönden C ve C++ dilleri ile benzerlikler gösterir. MIDL sayesinde bir uygulama bir yada daha çok arayüze sahip olabilir. Her arayüz, istemci ve sunucu programları arasında tekil bir dağıtık anlaşma belirler. Bir arayüz, farklı ortamlarda ve farklı koşullar altındaki programların birlikte çalışabilmelerini sağlamak için, tanımlamalar ve uzak fonksiyonlar içerir. COM’un ve DCOM’un arka planda RPC kullandığını söylemiştik. Bir RPC uygulamasında, arayüz şunları belirler: İstemci ve sunucu uygulamalarının birbirlerine kendilerini nasıl tanıtacakları İstemci ve sunucu arasında verinin nasıl aktarılacağı 49 İstemci uygulamanın çağırabileceği uzaktaki prosedürleri Uzaktaki prosedürlerin geri dönüş değerleri ve parametreleri için veri tipleri Bir COM veya DCOM arayüzü, bir COM nesnesinin kimliğini ve dış özelliklerini tanımlar. İstemcilere, nesnelerin yöntemlerine ve verilerine erişme yeteneği kazandırır. DCOM’da, nesnenin aynı işlemde yada farklı işlemlerde olmasına, veya aynı makine üzerinde yada farklı makineler üzerinde olmasına bakılmaksızın erişim yapılabilir. RPC istemci/sunucu arayüzleri ile, bir COM yada DCOM nesnesi, fonksiyonelliğini çok değişik yollarla ve birden çok arayüz üzerinden gösterebilir. 3.3.1. Tip Kütüphanesi Bir tip kütüphanesi (.tlb), çalışma zamanında diğer uygulamaların erişebileceği bir şekilde bulunan, bir COM veya DCOM nesnesinin özellikleri ve yöntemleriyle ilgili bilgilerin saklandığı bir binary dosyadır. Tip kütüphanesini kullanarak, bir uygulama veya gezgin (browser) nesnenin hangi arayüzleri desteklediğine karar verebilir, ve nesnenin arayüz yöntemlerine çağrı yapabilir. COM/DCOM çalışma zamanı birimleri de, tip kütüphanelerinde tanımlanan arayüzler için işlemler arası ve makineler arası otomatik dönüştürme sağlamak üzere, bir tip kütüphanesi kullanabilirler. 3.3.2. Bir Arayüzün Karakteristik Özellikleri Bir arayüzün karakteristik özellikleri bir IDL dosyasında tanımlanabileceği gibi, isteğe bağlı olarak bir uygulama konfigürasyon dosyasında (ACF – application configuration file) da tanımlanabilir. IDL dosyası uygulamanın arayüzlerinin alt seviyedeki karakteristik özelliklerini belirler. Yani, istemci ve sunucu arasında veya COM nesneleri arasında verinin nasıl aktarılacağı ile ilgilenir. ACF dosyası ise yerel işletim birimleri ile ilgisi olmayan arayüz karakteristik özelliklerini belirler. ACF dosyası aynı zamanda, karmaşık bir veri tipinin makine bağımsız bir şekle nasıl dönüştürüleceğini ve aktarılacağını da belirleyebilir. Her iki dosya da MIDL script’leri ile oluşturulurlar. 3.3.3. MIDL Derleyicisi Midl.exe derleyicisi hem C dili stub’larını ve başlık (header) dosyalarını, hem de tip kütüphanesi dosyalarını oluşturmak için MIDL script’lerini kullanır. IDL dosyasının içeriğine göre MIDL derleyicisi aşağıdaki dosyalardan herhangi birini üretir: 50 MIDL derleyicisi, bir arayüz nitelik listesinde nesne niteliği ile karşılaştığında; C dilinde bir proxy/stub dosyası, bir arayüz belirleyici dosyası, bir DLL veri dosyası, ve belirli bir COM arayüzü için ilgili bir başlık dosyası oluşturur. MIDL derleyicisi, IDL dosyasında kütüphane (library) ifadesi ile karşılaştığında Derlenmiş tip kütüphanesi dosyasını (.tlb) ve ilgili başlık dosyasını oluşturur. IDL dosyasında nesne niteliği taşımayan arayüzler varsa; C/C++ dilinde istemci ve sunucu stub dosyaları, ve RPC arayüzü için ilgili başlık dosyası oluşturulur. 3.3.4. Tip Tanımları, Yapı Bildirimleri, ve Import Tip tanımları (type definitions), yapı bildirimleri (construct declarations), ve import’lar, arayüz bedeninin dışında meydana gelirler. Temel IDL dosyasındaki tüm tanımlamalar oluşturulan başlık dosyasında yer alacak, ve temel IDL dosyasındaki tüm arayüzlerdeki tüm prosedürler stub rutinlerini oluşturacaklardır. Bu, birden çok arayüzü destekleyen uygulamaların, IDL dosyalarını birleşik bir IDL dosyasında toplamalarına imkan verir. Sonuç olarak, dosyaları derlemek daha az zaman alır, ve aynı zamanda oluşturulan stub’larda MIDL’ın fazlalıkları azaltmasına izin verir. Temel arayüzler ve türetilmiş arayüzler için temel kod paylaşımı yeteneği ile, nesne arayüzlerinin değerleri önemli ölçüde arttırılabilir. Nesnesiz arayüzler için, prosedür isimleri tüm arayüzlerde tek olmalıdır. Nesne arayüzleri için ise, prosedür isimleri sadece bir arayüzün içinde tek olmalıdır. /osf1 anahtarını kullandığınızda, çoklu arayüzleri kullanamayacağınızı unutmayın. 3.3.4.1. Bildirilebilen Yapılar IDL dilindeki bildirilebilen yapılar için sentaks, C dilindekine benzer. MIDL, aşağıdaki istisnalar dışında, tüm Microsoft C/C++ bildirilebilen yapılarını destekler. Bildiricinin tip belirleyicisi olmadan belirlenmesine izin veren eski tip bildiricileri desteklemez. Örneğin x(y) gibi değil, short x(y) gibi olmalıdır. İlk değer atayan bildirileri desteklemez. Sadece MIDL’ın const sentaksına uyan bildirileri destekler. 1 /osf anahtarı, OSF DCE standartları ile uyumluluğu sağlar. 51 import kelimesi ithal edilecek bir yada daha çok IDL dosyası ismini belirler. import deyimi C’deki include’a benzer, ama ithal edilen IDL dosyasına sadece veri tipleri bağdaştırılır. 3.3.4.2. Sabit Bildirimi (Constant Declaration) Sabit bildirimi Boolean, integer, character, wide-character, string, ve void * sabitlerini belirler. 3.3.4.3. Genel Bildirim (General Declaration) C’deki typedef ifadesi ile benzerdir, fazladan IDL tip nitelikleri de eklenmiştir. /osf anahtarı kullanıldığında, MIDL derleyicisi değişken tanımı biçimindeki kesin bildiriye de izin verir. 3.3.4.4. Fonksiyon Bildirimi (Function Declaration) Fonksiyon birdiricisi, genel bildirimin özel bir şeklidir. IDL nitelikleri, fonksiyon geri dönüş tipinin ve parametrelerin her birinin davranışlarını belirlemek için kullanılabilir. 3.3.4.5. Örnekler [ uuid(12345678-1234-1234-1234-123456789ABC), version(3.1), pointer_default(unique) ] interface IdlGrammarExample { import "windows.idl", "other.idl"; const wchar_t * NAME = L"Example Program"; typedef char * PCHAR; HRESULT DictCheckSpelling( [in, string] PCHAR [out] ); } word, // aranan kelime short * isPresent // yoksa 0 52 3.3.5. IDL Nitelikleri (IDL Attributes) 3.3.5.1. Dönüştürme ve Örtüşme Nitelikleri Dağıtık uygulamalar, arayüz prosedürlerini çağırdıklarında, istemci ve sunucu programlar arasında veri aktarırlar. Geliştiriciler, istemci ve sunucu programları arasında verilerin standart bir biçimde aktarılabilmesi için, veri tanımlamada MIDL kullanırlar. MIDL derleyicisi, veriyi ağ üzerinden aktarılabilecek standart bir biçime dönüştüren istemci ve sunucu için uygulama stub veya proxy programları yaratır. Ağ Veri Gösterimi (NDR – Network Data Representation) olarak adlandırılan bu standart biçime, çoğu zaman verinin tel biçimi (wire format) de denir. CORBA’da olduğu gibi, COM’da da veri tel üzerinden aktarılmadan önce dönüştürülme (marshaling) işlemi yapılır, ve aktarıldıktan sonra da yine eski haline geri dönüştürülür (unmarshaling). Verinin NDR biçimine nasıl dönüştürüleceği ve ağ üzerinden nasıl aktarılacağını kontrol etmek için dönüştürme ve örtüşme nitelikleri (Tablo 3.1) kullanılır. Nitelik Kullanımı call_as Uzağa gönderilemeyen bir fonksiyonu bir uzak prosedür çağrısı ile eşler. iid_is İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar. transmit_as Bir veri tipini ağ üzerinden aktarılabilmesi için daha basit bir tipe çevirir. wire_marshal transmit_as ile benzerdir, ama veriyi boyutlandırmak, dönüştürmek, geri dönüştürmek, ve bırakmak için rutinleri siz yürütürsünüz. Tablo 3.1. Dönüştürme ve Örtüşme Nitelikleri 3.3.5.2. Asenkron Nitelikler Bir program bir arayüzdeki bir prosedürü çağırdığında, program senkron veya asenkron olarak çalışabilir. Senkron bir prosedür, çağıran programın, prosedürün geri dönüşünü beklemesine neden olur. Asenkron bir prosedür ise sonuçları beklemeden geri dönebilir. Çağıran program veriyi almak için daha sonra tekrar arayüz prosedürü ile senkronize edilmelidir. Asenkron uzak prosedür çağrıları için destek sağlamak istiyorsanız, Tablo 3.2’deki nitelikleri kullanabilirsiniz. 53 Nitelik Kullanımı async Bir fonksiyon parametresinde yer aldığında, çağıranın asenkron bir çağrı yapmasına ve sonuçları beklemeden geri dönmesine izin veren bir işleyici (handle) tanımlar. async niteliği, ACF dosyalarında bir prosedür veya bir tam arayüz için bir asenkron işleyici tanımlamak için de kullanılır. COM arayüzleri için tam arayüz modası geçmiş bir arayüzdür ve yeni arayüzlerle kullanılamaz. async_uuid Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL derleyicisini yönlendirir. maybe Bu uzak prosedür çağrısını yapan istemci, teslimat veya çağrının bitirilmesi ile ilgili herhangi bir yanıt beklentisinde bulunmaz, ve teslimat garantisi yoktur. Yanıt beklentisi olmayan ama teslimat garantisi olan mesaj işlemlerine zıttır. message Uzak prosedür çağrısına istemciden sunucuya bir asenkron mesajmış gibi davranılır. İstemci çağrıyı yapar, ve gerçek çağrı mesaj-kuyruk taşıması (ncadg_mq) tarafından ele alınırken sonuç beklenilmeden hemen geri döner. Tablo 3.2. Asenkron Nitelikler 3.3.5.3. Dizi ve Boyutlu-İşaretçi Nitelikleri MIDL, veri işaretçileri ve verilerin dizilerini aktarmak için zengin bir özellikler kümesi sağlar. Tablo 3.3’teki nitelikleri kullanarak dizilerin karakteristik özelliklerini ve işaretçilerin boyutlarını belirleyebilirsiniz. Nitelik Kullanımı size_is Boyutlu işaretçiler, boyutlu işaretçilere boyutlu işaretçiler, ve tek veya çok boyutlu diziler için ayrılacak hafıza bölgesinin büyüklüğünü belirler. max_is Bir dizi indisi için maksimum değeri belirler. length_is Aktarılacak dizi elemanlarının sayısını belirler. first_is Aktarılacak ilk dizi elemanının indisini belirler. last_is Aktarılacak son dizi elemanının indisini belirler. string Tek boyutlu char, wchar_t, byte dizilerin (veya eşdeğerleri), veya böyle bir diziye işaretçilerin string olarak ele alınacağını gösterir. range Çalışma zamanında değerleri belirlenen argümanlar veya alanlar için kabul edilebilir değer aralığını belirler. Tablo 3.3. Dizi ve Boyutlu-İşaretçi Nitelikleri MIDL üç tip işaretçi destekler, referans işaretçiler (ref), tekil işaretçiler (unique) ve tam işaretçiler (ptr). 54 Bir işaretçi niteliği, bir type niteliği gibi; bir structure üyesi, union üyesi veya parametreye uygulanan bir alan niteliği gibi, veya fonksiyon geri dönüş tipine uygulanan bir fonksiyon niteliği gibi, tahsis edilebilir. İşaretçi niteliği pointer_default kelimesi ile de görünebilir. Uzak bir fonksiyonun çağrımı sırasında bir işaretçi parametresinin değiştirilmesini, çoklu işaretçi bildiricilerini destekleyerek dolaylı yoldan sağlamak gerekir. Parametreye uygulanan kapalı işaretçi niteliği, sadece parametre için en sağdaki işaretçi bildiricisini etkiler. Bir parametre bildiriminde birden çok işaretçi bildiricisi olduğunda, diğer belirleyiciler pointer_default niteliği ile belirlenen işaretçi niteliğine bağlıdırlar. Birden çok işaretçi bildiricisine farklı işaretçi nitelikleri uygulamak için, açık işaretçi niteliklerini belirleyen ayrı tipler tanımlanmalıdır. Varsayılan ĠĢaretçi-Niteliği Değerleri Parametre olan bir işaretçi ile hiçbir işaretçi niteliği ilişkilendirilmediğinde, işaretçi bir ref işaretçisi olarak kabul edilir. Bir structure’ın veya bir union’ın bir elemanı olan bir işaretçi ile hiçbir işaretçi niteliği ilişkilendirilmediğinde, MIDL işaretçi niteliklerini aşağıdaki öncelik sırasını kullanarak atar: 1. İşaretçi tipine açık bir şekilde atanan nitelikler 2. İşaretçi parametre veya üyeye açık bir şekilde atanan nitelikler 3. Tipi tanımlayan IDL dosyasındaki pointer_default niteliği 4. Tipi ithal eden IDL dosyasındaki pointer_default niteliği 5. ptr (osf iken); unique (Microsoft RPC iken) IDL dosyası varsayılan şekilde derlendiğinde, ithal eden dosyalar işaretçi niteliklerini ithal edilen dosyalardan miras alabilirler. /osf anahtarı kullanılarak derleme yapıldığında bu özellik geçerli değildir. Fonksiyon DönüĢ Tipleri Bir fonksiyon tarafından döndürülen işaretçi, bir tekil işaretçi veya bir tam işaretçi olmalıdır. Bir fonksiyonun sonucu bir referans işaretçi olursa, MIDL derleyicisi varsayılan biçimde veya açık bir şekilde bir hata üretir. Dönen işaretçi her zaman yeni bir yerde saklanmalıdır. 55 Bir işaretçi değeri döndüren fonksiyonlar, bir işaretçi niteliğini bir fonksiyon niteliği gibi belirleyebilirler. Eğer bir işaretçi niteliği bulunmuyorsa, fonksiyon-sonuç işaretçisi, sağlanan değeri pointer_default niteliği olarak kullanır. Tip Tanımlamalarında ĠĢaretçi Nitelikleri Bir typedef ifadesinin en üst basamağında bir işaretçi niteliği belirlendiyse, belirlenen nitelik beklendiği gibi işaretçi bildiricisine uygulanır. Eğer hiç işaretçi niteliği belirlenmediyse, bir typedef ifadesinin en üst basamağında, işaretçi bildiricileri kullanıldığı zaman işaretçi nitelik tipini miras alırlar. DCE IDL, açık bir şekilde iki defa uygulanan (örn: hem typedef bildiriminde hem de parametre niteliği listesinde uygulandıysa) aynı işaretçi niteliğine izin vermez. MIDL derleyicisinin varsayılan durumunu kullandığınızda bu kısıtlama gevşetilir. 3.3.5.4. Veri Tipi Nitelikleri Bir typedef ifadesindeki veri tiplerine, veri tipinin etkisine veya kullanımına ek özellikler kazandırmak için, Tablo 3.4’teki nitelikleri uygulayabilirsiniz. Nitelik Kullanımı context_handle Belirli bir istemciden gelen uzak prosedür çağrıları ile belirli bir sunucu arasındaki içerik (context) bilgisini muhafaza eden bir bağlı işleyici tanımlar. Nesne arayüz fonksiyonları için geçerli değildir. handle Uygulamaya özgü, özel bir işleyici (handle) tipi belirler. ms_union Korunmamış (nonencapsulated) union’ların NDR düzenlemesini kontol eder. MIDL 1.0 ve 2.0 ile oluşturulmuş arayüzler ile geriye dönük uyumluluk için typedef’lerde kullanılır. pipe Sonu belirlenmemiş bir dizinin bir uzak prosedür çağrısı üzerinden aktarımına izin verir. Bir in pipe parametresi, bir uzak prosedür çağrısı sırasında sunucunun istemciden veri dizisini çekmesine izin verir. Bir out pipe parametresi, sunucunun veriyi dizisini istemciye geri göndermesine izin verir. transmit_as Özel dönüştürmede kullanılan bir veri tipinin ağ üzerinden nasıl aktarılacağını belirler. v1_enum Belirlenen sayı tipinin 16-bit varsayılan değerle değil de, 32-bit olarak aktarılacağını belirler. wire_marshal transmit_as ile benzerdir, ama veriyi boyutlandırmak, dönüştürmek, geri dönüştürmek, ve bırakmak için rutinleri siz yürütürsünüz. Tablo 3.4. Veri Tipi Nitelikleri 56 3.3.5.5. Yönlendirici Nitelikler Verinin aktarılacağı yönü göstermek için, yönlendirici nitelikler parametrelere uygulanır. Her iki nitelik te tek bir parametreye uygulanabilir, ama bunu yapmak bir çağrı ile ilişkilendirilmiş masrafları arttırır. Nitelik Kullanımı in Çağırandan çağrılan fonksiyona aktarılacak olan parametre out Çağrılan fonksiyondan çağırana aktarılacak olan parametre Tablo 3.5. Yönlendirici Nitelikler 3.3.5.6. Fonksiyon Çağrım Nitelikleri Programlar bu nitelikleri ayrık fonksiyonlarda arayüzler içinde kullanabilirler, ve sadece o fonksiyonu etkiler. Nitelik Kullanımı message Uzak prosedür çağrısına istemciden sunucuya bir asenkron mesajmış gibi davranılır. İstemci çağrıyı yapar, ve gerçek çağrı mesaj-kuyruk taşıması (ncadg_mq) tarafından ele alınırken sonuç beklenilmeden hemen geri döner. maybe Bu uzak prosedür çağrısını yapan istemci, teslimat veya çağrının bitirilmesi ile ilgili herhangi bir yanıt beklentisinde bulunmaz, ve teslimat garantisi yoktur. Yanıt beklentisi olmayan ama teslimat garantisi olan mesaj işlemlerine zıttır. broadcast Uzak prosedür çağrısı ağ üzerindeki tüm sunuculara gönderilir. İstemci ilk geri dönüşü kabul eder, diğer sunuculardan gelen takip eden yanıtlar önemsenmez. idempotent Çağrı durum değiştirmez, ve aynı giriş parametreleri ile her çağrıldığında aynı bilgiyi geri döndürür. callback Sunucunun istemciden bilgi almak için çağırabileceği istemci uygulamada bulunan bir fonksiyonu tatbik eder. call_as Bir uzak prosedür çağrısı ile uzaklaştırılamayacak bir fonksiyonu eşler. local MIDL’ın stub kodunu oluşturmayacağı bir yerel prosedür tatbik eder. Nesne arayüz fonksiyonları için geçerli değildir. Tablo 3.6. Fonksiyon Çağrım Nitelikleri Nesne olmayan arayüzlerde, string, ptr ve context_handle niteliklerini de geri dönüş değerinin karakteristik özelliklerini belirlemek için bir fonksiyona uygulayabilirsiniz. 57 3.3.5.7. Arayüz Başlık Nitelikleri Tüm arayüz hakkında bilgi taşımak için arayüz başlığında bu nitelikler birleştirilir. Nitelik Kullanımı async_uuid Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL derleyicisini yönlendirir. uuid Belirli bir arayüzü tüm diğer arayüzlerden ayırmak için 128-bit’lik bir değer verir. Gerçek değer, bir GUID, bir CLSID, veya bir IID’yi temsil edebilir. local MIDL derleyicisini sadece başlık dosyalarını oluşturması için yönlendirir. Bir arayüz ya uuid yada yerel bir nitelik sahibi olmalıdır. ms_union Korunmamış (nonencapsulated) union’ların NDR düzenlemesini kontol eder. MIDL 1.0 ve 2.0 ile oluşturulmuş arayüzler ile geriye dönük uyumluluk için typedef’lerde kullanılır. object Arayüzü bir COM arayüzü olarak belirler ve MIDL derleyicisini RPC istemci ve sunucu stub’ları yerine proxy/stub kodu üretmesi için yönlendirir. version Arayüzün birden çok sürümünün bulunması olasılığına karşı bir arayüzün belirli bir sürümünü belirler. Çünkü COM arayüzlerinin değişmezliği yüzünden, nesne arayüzünün üstünde version niteliğini kullanamazsınız. pointer_default Parametre listesindekiler haricindeki tüm işaretçiler için varsayılan işaretçi tipini belirler. Varsayılan tip unique, ref veya ptr olabilir. endpoint Sunucu uygulamanın uzak prosedür çağrılarını dinleyeceği, statik bir son nokta belirler. Tablo 3.7. Arayüz Başlık Nitelikleri 3.3.5.8. Performans Nitelikleri Tablo 3.8’deki nitelikleri bir IDL dosyasında, stub kodunun boyutunu azaltmak veya performansı arttırmak için kullanabilirsiniz. Nitelik Kullanımı ignore Bir işaretçinin, bir struct veya union tarafından kapsandığını gösterir, ve işaretçi tarafından gösterilen nesne aktarılmayacaktır. local Bir fonksiyonun, uygulama için lokal olduğunu, ve MIDL’ın stub kodunu üretmesine gerek olmadığını gösterir. Wire_marshal Bir veri tipini, ağ üzerinden aktarılabilmesi için daha basit bir tip olarak tanımlar, ve tip için dönüştürme ve geri dönüştürme rutinlerinin yürütülmesine olanak sağlar. Tablo 3.8. Performans Nitelikleri 58 3.3.5.9. İşaretçi Tipi Nitelikleri Tablo 3.9’daki nitelikler, işaretçilerin karakteristik özelliklerini belirlemek için kullanılırlar. Nitelik Kullanımı ptr Bir işaretçiyi, bir C dili işaretçisinin örtüşme (aliasing) özelliği de dahil, tüm nitelikleri ile bir tam işaretçi olarak belirtir. ref Bazı verilerin adreslerini sağlayan, MIDL’daki en basit işaretçi tipini belirtir. Referans işaretçiler hiçbir zaman boş (NULL) olamazlar. unique İşaretçinin boş (NULL) olmasına izin verir, ama örtüşmeyi desteklemez. pointer_default Bir arayüze, varsayılan değeri ref olan üst-düzey parametre işaretçileri dışında, o arayüzdeki tüm işaretçiler için varsayılan işaretçi tipini belirlemek üzere uygulanır. iid_is İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar. string İşaretçinin bir karakter katarını gösterdiğini belirtir. Tablo 3.9. İşaretçi Tipi Nitelikleri 3.3.5.10. Struct ve Union Nitelikleri Bir union’ın bir uzak prosedür çağrısındaki karakteristiğini belirlemek için switch_* nitelikleri kullanılır. Belirli miktardaki struct veya union üyelerini istemci uygulamaya yerel olarak göstermek için ignore niteliği kullanılır. Nitelik Kullanımı switch Korunmuş (encapsulated) bir birleşim (union) için ayırtacı (discriminant) belirler. switch_is Korunmamış (nonencapsulated) bir birleşim için ayırtacı belirler. switch_type Korunmamış bir birleşim için ayırtacın tipini belirler. ignore Bir işaretçinin, bir struct veya union tarafından kapsandığını gösterir, ve işaretçi tarafından gösterilen nesne aktarılmayacaktır. Tablo 3.10. Struct ve Union Nitelikleri struct ve union üyelerinin karakteristik özelliklerini belirlemek için Dizi ve Boyutlu-İşaretçi Niteliklerini de (bakınız 3.3.5.3) kullanabilirsiniz. 59 3.3.5.11. Tip Kütüphanesi Nitelikleri ġekil 3.11’deki nitelikler, IDL dosyasında bir library ifadesinin içerdiği kısımda tip kütüphanesi bilgisini belirler. Nitelik Kullanımı aggregatable coclass’ı, başka bir nesnenin arayüz işaretçisini direkt olarak gösterebilen destekleyen nesneler olarak belirler. appobject coclass’ı, bir tam EXE uygulaması ile ilişkilendirilmiş bir uygulama nesnesi olarak belirler. bindable Özelliğin veri bağlantısını desteklediğini gösterir. Bu, bir özellik değerini değiştirdiği zaman istemcinin bilgilendirilmesini sağlar. coclass Bir bileşen nesnesi için desteklenen arayüzlerin bir listesini sağlar. control Bir coclass’ı veya kütüphaneyi, kapsayan yerin ek tip kütüphaneleri veya bileşen nesne sınıfları türeteceği bir COM kontrolü olarak belirler. custom MIDL’da tanımlı olmayan özel bir nitelik tanımlar. default Coclass içinde tanımlanan arayüzün varsayılan arayüzü temsil ettiğini gösterir. defaultbind Nesneyi en iyi şekilde gösterecek bağlanabilir tekil özelliği gösterir. defaultcollelem Varsayılan koleksiyonun bir üyesi için bir erişici fonksiyon olarak özelliği işaretler. Microsoft Visual Basic kod optimizasyonu için kullanılır. defaultvalue Seçimlik bir parametre için varsayılan bir değerin belirlenmesine izin verir. defaultvtable Bir nesnenin iki farklı kaynak arayüzü olmasına izin verir. dispinterface IDispatch::Invoke’u çağırabileceğiniz özellikler ve yöntemlerin bir kümesini tanımlar. displaybind Kullanıcıya bağlanabilir olarak gösterilmesi gereken bir özellik gösterir. dllname(str) Bir modül için giriş noktalarını içeren DLL dosyasının ismini belirler. dual IDispatch ve Vtable üzerinden özellikleri ve yöntemleri teşhir edilecek arayüzü tanımlar. entry DLL’de giriş noktasını belirleyerek ihraç edilmiş fonksiyon veya sabiti bir modülde belirler. helpcontext Kullanıcının Yardım dosyasında bu üye ile ilgili bilgi bulabileceği bir içerik belirleyicisi tanımlar. helpfile Bir tip kütüphanesi için yardım dosyasının ismini belirler. helpstring Uygulandığı üyeyi tanımlamak için kullanılan bir karakter katarını belirler. helpstringdll Doküman karakter taraması yapmak için kullanılacak DLL’in ismini belirler. hidden Maddenin varolduğunu ama kullanıcıya gösterilmemesi gerektiğini ifade eder. id Bir üye fonksiyon (arayüzdeki bir özellik veya bir yöntem) için bir DISPID belirler. immediatebind Bir veri-bağı (data-bound) nesnesinin bir özelliğindeki tüm değişikliklerden veritabanının hemen haberdar edileceğini gösterir. 60 lcid Bir kütüphane ifadesine bir localeID argümanıyla beraber uygulandığında, bir tip kütüphanesi veya bir fonksiyon argümanı için yer belirler, ve kütüphane bloğu içinde enternasyonal karakterlerin kullanılmasına izin verir. library İfade içinde referans edilen arayüzler ve sınıflar için tip kütüphanesi bilgisini oluşturması için, MIDL derleyicisine talimat verir. licensed Uygulandığı coclass’ın lisanslı olduğunu gösterir, ve örnekler IClassFactory2 kullanarak oluşturulmalıdırlar. nonbrowsable Özelliğin bir nesne gezgininde (özellik değerlerini göstermeyen) yer alacağını, ama özellikler gezgininde (özellik değerlerini gösteren) yer almayacağını gösterir. noncreatable İstemcinin, bir nesne arayüzünün örneklerini oluşturmak için varsayılan sınıf fabrikasını kullanmasını engeller. nonextensible IDispatch yürütmesinin sadece arayüz tanımında yer alan özellikleri ve yöntemleri içereceğini, ve yürütme zamanında ek üyelerle genişletilemeyeceğini belirler. oleautomation Bir arayüzün otomasyon ile uyumlu olduğunu gösterir. optional Bir üye fonksiyonu için seçimlik bir parametre belirler. propget Bir özellik erişici fonksiyon belirler. propput Bir özellik yerleştirici fonksiyon belirler. propputref Bir değer yerine bir referans kullanan bir özellik yerleştirici fonksiyon belirler. public Typedef ile bildirilen bir alias’ın, tip kütüphanesinin bir parçası haline gelmesini sağlar. readonly Bir değişkene yeni bir değerin atanmasını engeller. requestedit Özelliğin OnRequestEdit bildirimini desteklediğini gösterir. restricted Bir modülün veya bir arayüzün bir kütüphanesinin veya bir üyesinin keyfi olarak çağrılamayacağını belirler. retval Üyenin dönüş değerini alan parametreyi belirtir. source Bir özellik, yöntem veya coclass’ın bir üyesinin olayların kaynağı olduğunu gösterir. string Tek boyutlu char, wchar_t, byte dizilerinin (veya eşdeğerlerinin) veya bu gibi dizilere işaretçinin, string olarak davranması gerektiğini gösterir. uidefault Tip bilgi üyesinin, kullanıcı arayüzünde görünüm için varsayılan üye olduğunu gösterir. usesgetlasterror Bir modül giriş noktasının geri dönen hata kodları için SetLastError kullandığını, ve eğer bir fonksiyona girişte bir hata varsa çağıranın hata kodunu almak için GetLastError’u çağırabileceğini gösterir. uuid Bir tip kütüphanesi, coclass, veya arayüz için tekil bir belirleyici belirtir. vararg Fonksiyonun değişken sayıda argüman alabileceğini belirler. version Bir tip kütüphanesinin belirli bir sürümünü belirtir. Tablo 3.11. Tip Kütüphanesi Nitelikleri 61 3.3.6. MIDL Veri Tipleri 3.3.6.1. Ön-tanımlı ve Temel Tipler MIDL aşağıdaki temel ve ön-tanımlı tipleri destekler. Veri tipi Açıklama Varsayılan iĢaret Boolean 8 bit. oleautomation arayüzleri ile uyumlu değil; bu arayüzlerde unsigned (işaretsiz) VARIANT_BOOL kullanılır. byte 8 bit. - char 8 bit. unsigned (işaretsiz) double 64-bit kayan noktalı sayı. - error_status_t Hata idaresi için kullanılan 32-bit işaretsiz tam sayı unsigned (işaretsiz) float 32-bit kayan noktalı sayı. - handle_t bağlama (binding) için ilkel tip. - hyper 64-bit tam sayı. signed (işaretli) int 32-bit tam sayı. 16-bit platformlarda, short, small, long veya hyper signed (işaretli) gibi bir büyüklük sınırlayıcısı olmadan, uzak fonksiyonlarda yer alamaz. __int32 32-bit tam sayı. long ile eşdeğer. __int3264 32-bit platformlarda 32-bit, ve 64-bit platformlarda 64-bit olan bir signed (işaretli) tam sayı. __int64 64-bit tam sayı. hyper ile eşdeğer. long 32-bit tam sayı. signed (işaretli) short 16-bit tam sayı. signed (işaretli) small 8-bit tam sayı. signed (işaretli) void Prosedürün bir değer döndürmeyeceğini gösterir. - void * Sadece içerik işleyiciler için 32-bit işaretçi - wchar_t Geniş karakterler için 16-bit ön-tanımlı tip. unsigned (işaretsiz) Tablo 3.12. Ön-tanımlı ve Temel Tipler 62 3.3.6.2. İşaretli ve İşaretsiz Tipler İşaretli ve işaretsiz tipler için farklı varsayılan durumlar kullanan derleyiciler, dağıtık uygulamalarda yazılım hatalarına sebep olabilirler. Karakter tipleri işaretli (signed) veya işaretsiz (unsigned) olarak kesin bir biçimde belirlenirse, bu problemler ortaya çıkmaz. DCE IDL derleyicileri signed kelimesini kabul etmezler. Bu durumda /osf anahtarı kullanıldığında bu kelime kullanılamayacaktır. MIDL, C derleyicisindeki char tipi ile aynı varsayılan işareti elde etmek için small tipini tanımlamıştır. Eğer derleyici char’ın işaretsiz olduğunu farz ettiyse, small da işaretsiz olarak tanımlanacaktır. Birçok C derleyicisi varsayılan değerin bir komut satırı seçeneği ile değiştirilmesine izin verir. Örneğin Microsoft Visual C++’de, /J komut satırı seçeneği, char’ın varsayılan işaretini, işaretliden işaretsize çevirir. MIDL derleyicisindeki /char komut satırı anahtarı ile, char ve small tiplerindeki değişkenlerin işaretleri kontrol edilebilir. Bu anahtar, derleyicinin kullandığı varsayılan işareti belirlemeye izin verir. MIDL derleyicisi, oluşturulan başlık dosyasında C derleyicinizin varsayılan tipi ile uyuşmayan tüm char tiplerinin işaretlerini, açıkça bildirir. 3.3.6.3. Diğer MIDL Veri Tipleri MIDL, BSTR, VARIANT, ve SAFEARRAY, gibi birçok COM ve otomasyon (Automation) veri tipini, ve HMETAFILE_PICT, HENHMETAFILE, HMETAFILE, HBITMAP, HPALETTE, ve HGLOBAL gibi birçok COM işleyicisini kabul eder. 3.3.7. MIDL Dizileri Dizi bildiricileri, IDL dosyasının arayüz gövdesinde aşağıdakilerden biri olarak yer alırlar: Bir genel bildirimin parçası olarak Bir struct veya union bildiriminin bir üyesi olarak Uzak bir prosedür çağrısına bir parametre olarak Microsoft RPC’nin C dilini baz alması nedeniyle, dizi bildirimleri C dilindekine benzer. Dizinin her boyutunun sınırları ayrı ayrı köşeli parantezler içerisinde verilir. Köşeli parantezin içinin boş bırakılması veya “*” işaretinin bulunması, dizinin alt sınırının sıfır olduğunu, ve üst sınırının çalışma zamanı içerisinde belirleneceğini gösterir. C dilinde olduğu gibi, çok boyutlu dizilerde sadece ilk boyutun çalışma zamanında belirlenmesine izin verilir. 63 /* IDL file interface body */ #define MAX_INDEX 10 typedef char ATYPE[MAX_INDEX]; typedef short BTYPE[]; // [*] ile aynı; typedef long // [][10] ile aynı CTYPE[*][10]; typedef float DTYPE[0..10]; // [11] ile aynı typedef float ETYPE[0..(MAX_INDEX)]; Dikkat edilecek bir diğer kural da, Microsoft RPC’nin alt sınır olarak sadece sıfır değerini kabul etmesidir ([alt_sınır..üst_sınır] belirlenmesinde alt_sınır daima sıfır olmalıdır). Diziler alan nitelikleri ile ilişkilendirilebilirler. size_is veya max_is kullanılarak dizinin üst sınırı (boyutu), length_is, first_is veya last_is kullanılarak dizinin alabileceği değer aralığı belirlenebilir. Bir C yapısının içinde değişken boyutlu bir dizi bildirimi yapılacaksa, yapının en son elemanı olarak bildirilmelidir: typedef struct { unsigned short boyut; unsigned short uzunluk; [size_is(boyut), length_is(uzunluk)] char string[*]; } counted_string; 3.3.7.1. İşaretçilerin Dizileri Referans işaretçileri geçerli bir veriyi işaret etmelidirler. İstemci uygulama referans işaretçilerinin bir [in] veya bir [in, out] dizisi için, özellikle de dizi [in] veya [in, out], [length_is] veya [last_is] değerleri ile ilişkilendirildiyse, tüm hafızayı tahsis etmelidir. İstemci uygulama aynı zamanda çağrıdan önce tüm dizi elemanlarını başlatmalıdır. Sunucu uygulama, istemciye geri dönmeden önce, aktarılan aralıktaki tüm dizi elemanlarının geçerli depolama yerine işaret ettiklerini doğrulamalıdır. Sunucu tarafında stub, çağrı zamanındaki [length_is] veya [last_is] değerini önemsemeden tüm dizi elamanları için yer tahsis etmelidir. Bu özellik uygulamanızın performansına etki edebilir. 64 unique işaretçilerin dizilerinde hiçbir kısıtlama bulunmaz. Hem istemcide hem de sunucuda, boş işaretçiler için yer tahsis edilir. İşaretçiler dolduğunda, veri önceden tahsis edilmiş yere yerleştirilir. Seçimlik bir işaretçi bildiricisi, dizi bildiricisinin önünden gidebilir. Gömülü referans işaretçileri sadece [out] parametreler olduklarında, sunucuyönetici kodu, referans işaretçilerinin dizisine geçerli değerleri atamalıdır. Örneğin: typedef [ref] short * ARefPointer; typedef ARefPointer ArrayOfRef[10]; HRESULT proc1( [out] ArrayOfRef Parameter ); Oluşturulan stub’lar diziyi tahsis ederler ve dizide gömülü olan tüm işaretçilere NULL değerler atarlar. 3.3.8. Yapılar (Structures) ve BirleĢimler (Unions) Temel tiplerin alanlarına normal C semantikleri uygulanır. İşaretçiler, diziler ve diğer yapısal tipler gibi daha karmaşık tiplerin alanları, tip veya field_attributes ile değiştirilebilir. MIDL, C/C++ union ifadesinin bir üst kümesini destekler. MIDL, union’ların iki türünü destekler: 3.3.8.1. Korunmuş Birleşimler (Encapsulated Unions) Ayırtacı (discriminant) ile beraber bir yapı içerisinde olan birleşime, korunmuş birleşim denir. Korunmuş birleşim, switch kelimesinin varlığı ile gösterilir. Bu tip bir birleşimde, MIDL derleyicisi bir uzak prosedür çağrısı sırasındaki aktarım için birleşimi ve ayırtacı bir yapı içinde otomatik olarak korur. Eğer birleşim etiketi (örnekteki U1_TYPE) yoksa, derleyici yapıyı tagged_union adındaki birleşim alanı ile oluşturur. Birbirleriyle bağlantılı olmalarını sağlamak için, birleşimlerin biçimleri tüm platformlarda aynı olmalıdır. 65 typedef union _S1_TYPE switch (long l1) U1_TYPE { case 1024: float f1; case 2048: double d2; } S1_TYPE; /* in generated header file */ typedef struct _S1_TYPE { long l1; union { float f1; double d2; } U1_TYPE; } S1_TYPE; 3.3.8.2. Korunmamış Birleşimler (Nonencapsulated Unions) Ayırtacı ile beraber bir yapı içerisinde olmayan birleşime, korunmamış birleşim denir. Korunmamış birleşim, switch_type tip niteliğinin ve switch_is alan niteliğinin varlığı ile gösterilir. Bu tip bir birleşimde, MIDL derleyicisi bir uzak prosedür çağrısı sırasındaki aktarım için birleşimi ve ayırtacı bir yapı içinde otomatik olarak korur. 3.3.9. Bağlı ĠĢleyiciler (Binding Handles) Bağlı handle’lar, istemci ile sunucu arasındaki bağı gösteren veri nesneleridir. MIDL, handle_t temel tipini destekler. Bu tipin işleyicileri, ilkel işleyiciler (primitive handles) olarak bilinirler. [handle] niteliğini kullanarak kendi özel işleyicilerinizi tanımlayabilirsiniz. Bu şekilde tanımlanmış işleyiciler, kullanıcı-tanımlı (user-defined) veya özelleştirilmiş (customized) veya soysal (generic) işleyiciler olarak bilinirler. 66 [context_handle] niteliğini kullanarak durum bilgisini muhafaza eden bir işleyici tanımlayabilirsiniz. Bu şekilde tanımlanmış işleyiciler “içerik” (context) işleyicileri olarak bilinirler. Eğer durum bilgisine ihtiyaç yoksa, ve işleyici yönetmek için RPC çalışma zamanı kütüphanelerini çağırmayı seçmediyseniz, çalışma zamanı kütüphanelerinin otomatik bağlantı yapmalarını isteyebilirsiniz. Bu, [auto_handle] ACF anahtar kelimesi kullanılarak yapılır. [implicit_handle] ACF anahtar kelimesini kullanarak global bir değişkeni bir bağlı işleyici olarak belirleyebilirsiniz. [explicit_handle] anahtar kelimesi, her uzak fonksiyonun açıkça belirlenmiş bir işleyicisi olduğunu belirtmek için kullanılır. 3.4. DCOM’un Bugünü ve Yarını DCOM, 1996 yılında piyasaya sürülen Windows NT 4.0 ile Windows işletim sistemlerinin bir parçası haline gelmiş, ve bu tarihten sonra çıkan tüm Windows sürümlerinde yerini almıştır. Windows dışındaki ortamlarda da DCOM’un söz sahibi olabilmesi için, Microsoft, Software AG ve Digital Equipment Corp. ile ortaklığa gitmiştir. Bunun sonucunda Solaris, IBM MVS, HP-UX, DEC UNIX ve Siemens Nixdorf SINIX gibi platformlarda DCOM kullanılabilir duruma gelmiştir. COM/DCOM nesneleri, C++, Visual Basic, Java programlama dilleriyle ve VBScript, JScript script programlama dilleriyle kullanılabilirler. DCOM, MTS (Microsoft Transaction Server) ve Dizin Hizmetleri (Directory Services) gibi sonradan ortaya çıkan bazı Microsoft teknolojilerinin de temel taşı olmuştur. MTS, COM ve DCOM nesnelerinden oluşmuş multitier uygulamaların geliştirilmesi, yayılması ve idaresi sağlayan bir hareket işlem sistemidir. DCOM, makineler arasındaki tüm nesne haberleşmelerinde kullanılır. MTS ise, nesnelere hareket desteği sağlamanın yanında, thread’leri, işlemleri, veritabanı bağlantılarını, iş nesnelerini sağlarken geliştiricilerin başvurabilecekleri paylaşım özelliklerini yönetir. SQL Server ile sıkı bir entegrasyonu olmasına rağmen, diğer veritabanı sistemlerine de destek verecek şekilde tasarlanmıştır. Dizin Hizmetleri ve Aktif Dizin (Active Directory), ilk defa Windows 2000’de yer almıştır. Ağ üzerinde bulunan tüm bilgilerin (kullanıcılar, gruplar, bilgisayarlar, yazıcılar, ...) dizin mantığı ile depolanması sayesinde, bu bilgilerin kullanıcılar ve yöneticiler tarafından kolayca bulunması ve kullanılması sağlanmıştır. COM ve DCOM’un önemli olduğu başka bir alan da veritabanı erişimidir. Microsoft’un geliştirdiği OLE DB, veritabanları arasındaki işlemlerin nasıl olması gerektiğini 67 ve uygulamaların nasıl veritabanlarına bağlanacaklarını belirler. OLE DB, herhangi bir veri haznesinin veriyi bir cetvel (tabular) biçiminde göstermesine izin veren bir bileşen kümesi sağlar. OLE DB’nin ODBC’nin yerini alması düşünülmemiştir. Hatta OLE DB, ODBC üzerinden ilişkisel veritabanlarına bağlanır. COM ve DCOM mimarilerini takiben, bu teknolojilerin gelişimlerinin bir evresi olarak kabul edilebilecek olan COM+ ve .NET teknolojileri piyasaya çıkmıştır. Şimdi bu iki teknolojiye biraz daha yakından bakarak, getirdikleri yeniliklere göz atalım. 3.4.1. COM+ COM+, Microsoft Visual Studio 6.0 ile ilk defa ortaya çıkmış ve Windows2000’de ağırlıklı olarak kullanılmaya başlanmıştır. COM+’ın getirdiği yenilikler şunlardır: Yayınlama ve abonelik servisi: Birden çok istemcinin yayınlamış çeşitli olaylara abone olmalarını sağlayan genel bir olay mekanizması sağlar. Yayıncı bir olayı harekete geçirdiğinde, COM+ olay sistemi, abonelik veritabanı vasıtasıyla tüm abonelere haber verir. Kuyruğa atılmıĢ bileĢenler: İstemcilerin COM bileşenleri üzerinde asenkron modeli kullanarak yöntemleri çağırmasına izin verir. Böyle bir model, güvenilir olmayan ağlarda ve bağlantısız kullanım senaryolarında kullanılabilir. Dinamik yük dengeleme: İstemci isteklerini eşdeğer COM bileşenlerine otomatik olarak dağıtır. MTS’nin COM’da tam entegrasyonu: Nitelik tabanlı programlama, hareketler gibi varolan servislerden istifade etmek, güvenlik ve yönetim için daha geniş destek içerir. Aynı zamanda desteklediği TIP (Transaction Internet Protocol) sayesinde başka hareket tabanlı ortamlarla birlikte çalışabilirliği arttırır. 3.4.2. .NET 2000 yılında sözü edilmeye başlanan bu kavram, ilk olarak WindowsXP işletim sisteminde kullanılmaya başlanmıştır. Visual Studio.NET yazılım geliştirme araçları .NET tabanlı yazılım geliştirmeyi destekler. Yakın bir zamanda .NET tabanlı çalışan Windows.NET ve Office.NET ile de tanışacağız. .NET’in getirdiği yenilikler arasında şunları sayabiliriz: .NET yazılım geliştirme sürecinde verimi ve esnekliği artıracak bir çok olanak sağlamaktadır. 68 .NET ile yazılım geliştirmek için COM ile gerçekleştirilen yatırımlardan vazgeçme zorunluluğu yoktur. Aksine .NET sayesinde mevcut altyapı değiştirilmeden yeni projeler tasarlanabilir, ve COM temelli yazılımlar uzun süre kullanılabilir. COM ve .NET arasında gerekli iletişim .NET tarafından otomatik olarak sağlanmakta, ve bu konuda kullanıcıya fazla bir iş düşmemektedir. COM hataları belirlemek için fonksiyonlardan dönen kodları kullanırken, .NET exception handling üzerine kurulu bir error handling mekanizması kullanmaktadır. 69 4. CORBA - DCOM KARġILAġTIRMASI Bir COM sunucusu, birden çok nesne sınıfının nesne örneklerini yaratabilir. Bir COM nesnesi, her biri nesnenin farklı bir görünümünü veya davranışını temsil eden birden çok arayüz destekleyebilir. Bir arayüz, fonksiyonellikle ilgili bir yöntemler kümesinden ibarettir. Eğer nesne istemcinin adres uzayında yer alıyorsa, bir COM istemcisi bir COM nesnesi ile, o nesnenin arayüzlerine doğru olan bir işaretçiyi elde ederek etkileşime girer, ve bu işaretçi üzerinden yöntemleri başlatır. COM, C++ sanal fonksiyon tablosunda olduğu gibi, herhangi bir arayüzün standart hafıza planını takip etmesini zorunlu kılar. Tanımlama ikili seviyede olduğundan, C++, Java ve Visual Basic gibi faklı dillerde yazılması muhtemel ikili bileşenlerin entegrasyonuna izin verir. Bir CORBA nesnesi, dış dünyaya bir yöntemler kümesi ile bir arayüz vasıtasıyla anlatılır. Bir nesnenin belirli bir örneği, bir nesne referansı ile tayin edilir. Eğer nesne istemcinin adres uzayında yer alıyorsa, bir CORBA nesnesinin istemcisi, kendi nesne referansını elde eder ve bunu yöntem çağrıları yapmak için kullanır. Nesnenin yürütmesinin bulunması, isteği alması için hazırlanması, isteğin onunla haberleşmesi, ve eğer varsa yanıtın istemciye taşınması için gerekli tüm mekanizmalardan ORB sorumludur. Nesne yürütmesi, ya bir Nesne Adaptörü, yada ORB arayüzü vasıtasıyla ORB ile etkileşime girer. Hem DCOM hem de CORBA, istemci-sunucu tipi haberleşmeleri sağlarlar. Bir istemci, bir servise istek yapmak için, istemci-sunucu modelinde sunucu olarak rol oynayan bir uzak nesne tarafından yürütülen bir yöntemi başlatır. Sunucu tarafından sağlanan servis bir nesne olarak korunur ve bir nesnenin arayüzü bir IDL’de tanımlanır. IDL dosyasında tanımlanan arayüzler, bir sunucu ile istemcileri arasında bir anlaşma vazifesi görür. İstemciler IDL’de tanımlanan yöntemleri başlatarak bir sunucu ile etkileşime girerler. Gerçek nesne yürütmesi istemciden saklanır. Veri korunması, polymorphism ve tekli miras gibi bazı nesneye yönelik programlama özellikleri IDL düzeyinde vardır. CORBA, IDL düzeyinde çoklu miras özelliğini de destekler, ama DCOM desteklemez. Bunun yerine, DCOM aynı amaç için birden çok arayüze sahip nesne kavramını kullanır. CORBA IDL’de istisnai hatalar da tanımlıdır (exceptions). Hem DCOM’da hem de CORBA’da, bir istemci işlemi ile bir nesne sunucusu arasındaki etkileşimler nesneye yönelik RPC tipi haberleşmelerle yürütülür. ġekil 4.1, tipik bir RPC yapısını gösterir. İstemci, uzak fonksiyonu başlatmak için, istemci stub’a bir çağrı yapar. Stub, çağrı parametrelerini bir istek mesajı içine paketler, ve mesajı sunucuya iletmek 70 için bir tel protokolü başlatır. Sunucu tarafında, tel protokolü mesajı sunucu stub’ına iletir. Sunucu stub’ı mesajın paketini açar ve nesnedeki gerçek fonksiyonu çağırır. DCOM’da istemci stub’ına proxy, sunucu stub’ı da stub denir. CORBA’da ise istemci stub’ına stub, sunucu stub’ına iskelet denir. Bazen, CORBA’daki stub’ın çalışmakta olan bir örneğine proxy denir. işlem() yanıt İstemci Sunucu Üst Katman istemci stub’ı Ara Katman sunucu stub’ı tel protokolü Alt Katman tel protokolü Ağ ġekil 4.1. RPC Yapısı CORBA ve DCOM mimarilerinin ayrıntılı yapıları sırasıyla ġekil 4.2 ve ġekil 4.3’te gösterilmiştir. Sonraki bölümlerde, hem DCOM’da hem de CORBA’da yürütülmüş bir örneği inceleyecek, ve şekillerde görülen üç farklı katman üzerinde nesne aktivasyonlarının ve yöntem çağrılarının adım adım tanımlamalarını vereceğiz. Üst katman, istemci ve nesne sunucusu programlarının geliştiricilerinin gördüğü temel programlama mimarisi’dir. Ara katman, arayüz işaretçilerinin ve nesne referanslarının farklı işlemler üzerinde anlamlı olmasını sağlayan eriĢim mimarisi’dir. Alt katman ise, erişim mimarisini farklı makineler üzerinde çalışabilecek şekilde genişleten tel protokol mimarisi’dir. İstemci Sunucu Nesne Temel Programlama Katmanı istemci stub’ı (proxy) Erişim Katmanı CORBA kütüphanesi ORB(ler) (orbixd) & Yürütme Ambarı ORB ORB Tel Katmanı TCP Soketi ġekil 4.2. CORBA Mimarisi Nesne İskeleti Nesne Adaptörü (CORBA kütüphanesi) 71 İstemci Sunucu Sınıf Fabrikası Temel Programlama Katmanı Nesne ara nesne proxy proxy COM Kütüphanesi Erişim Katmanı SCM(ler) & Registry SCM SCM Registry Registry RPC Kanalı Tel Katmanı OXID çözümleyicisi OXID çözümleyicisi istemci ping sunucu ping nesne stub’ı ara stub COM Kütüphanesi OXID nesnesi Nesne ihracatçısı ġekil 4.3. DCOM Mimarisi 4.1. Örnek Uygulama Grid adında bir uygulama hem DCOM hem de CORBA ile geliştirilmiştir. Grid sunucusu iki boyutlu bir tamsayılar dizisi ve iki adet yöntemler grubu içerir. İlk grup iki yöntemden oluşur: get() dizinin belirli bir noktasındaki değeri alırken, set() dizinin belirli bir noktasındaki değeri yeniler. İkinci grupta sadece bir yöntem vardır: reset() yöntemi dizinin her noktasına belirli bir değeri yazar. Basit bir gösterim olsun diye, Grid istemcisi get() yöntemini başlatarak (0,0) koordinatlarındaki değeri elde eder, değerini bir arttırır, ve reset() yöntemini çağırarak tüm diziyi yeni değerle doldurur. CORBA birden çok arayüzden miras alan bir arayüze izin verirken, DCOM’un birden çok arayüzlü nesneleri desteklediğini göstermek amacıyla, DCOM ve CORBA yürütmeleri farklı yollarla tasarlanmışlardır. DCOM ve CORBA, temel olarak C++ yürütme sınıfları ile aralarındaki miras ilişkileriyle ilgisizdirler. CORBA’da üç arayüz tanımlanmıştır: (1) grid1 arayüzü: get() ve set()için (2) grid2 arayüzü: reset() için 72 (3) grid arayüzü: grid1’den ve grid2’den mirasları biraraya getirmek için DCOM’da ise iki arayüz tanımlanmıştır: (1) IGrid1 arayüzü: get() ve set()için (2) IGrid2 arayüzü: reset() için DCOM’da, Grid nesnesinin yürütmesi, iki arayüzlü bir nesneyi yürümek için, IGrid1 ve IGrid2’den çoklu miras alma özelliğini kullanır. CORBA’da olduğu gibi, arayüz tekli miras özelliğini kullanarak, tüm yöntemleri bir arayüzde bir araya getirebilirdik. Ama DCOM birden çok arayüze sahip nesnelere verdiği destek, bir nesnenin her ayrık özelliğinin farklı arayüzlerde olmasına izin verir. Her yürütme için, kaynak kodları 5 dosya halinde yazılmıştır. Gösterimi basitleştirmek için sadece gerekli kodlar gösterilecektir. Tablo 4.1’de gösterilen ilk dosya, arayüzlerin ve yöntemlerinin tanımlandığı IDL dosyasıdır. DCOM IDL dosyası, coclass kısmında görüldüğü gibi, bir nesne sınıfı ile birden çok arayüzü ilişkilendirir. DCOM’da da, CORBA’da da, Bir IDL dosyasını bir IDL derleyicisinden geçirmek, proxy/stub/iskelet kodunu ve hem sunucu hem de istemci tarafından kullanılan arayüz başlık dosyasını (grid.h veya grid.hh) oluşturur. DCOM’da her arayüzün bir arayüz belirleyicisi (IID – Interface ID) denilen UUID’ye atandığına dikkat edin. Benzer bir şekilde, her nesne sınıfı da tekil bir sınıf belirleyicisine (CLSID) atanır. Aynı zamanda, her COM arayüzü IUnknown arayüzünden miras alınmış olmalıdır. Bu arayüz, aynı nesnenin farklı arayüzleri arasında gezinmek için kullanılan QueryInterface() yönteminden, ve referans sayımı için kullanılan AddRef() ve Release() yöntemlerinden oluşur. DCOM’u anlatırken de belirtildiği gibi, nesne sayımı, bir COM nesnesinin istemcilerinin izini takip etmesine yarayan bir yaşam zamanı kontrol mekanizması sağlar, ve artık gerekli olmadığında kendisini siler. Tablo 4.2’de gösterilen ikinci dosya, sunucu yürütme sınıfının arayüzlerden nasıl türetildiğini gösteren, yürütme başlık dosyasıdır. DCOM dosyası, sık sık kullanılan ama gerekli olmayan, bir sınıf fabrikasının (CClassFActory) tanımını da içerir. Önceden söylediğimiz gibi, CGrid yürütme sınıfı, IDL’den oluşan arayüz başlık dosyasında (grid.h) tanımlanan, iki saf soyut temel sınıftan mirasları alarak biraraya getirir. CGrid sınıfında, AddRef() referans sayısını arttırırken, Release() azaltır. Referans sayısı sıfıra düştüğünde, sunucu nesnesi kendini siler. Bu da sıklıkla kullanılır ama gerekli değildir. Sonuçta, sunucu nesnesi kendi yaşam zamanını kontrol eder. 73 CORBA yürütmesinde, IDL derleyicisi grid arayüz sınıfını, grid.hh başlık dosyasında arayüz tanımından faydalanarak oluşturur. Uygulama geliştirici yürütme sınıfı grid_i’yi yazar. Yürütme sınıfını arayüz sınıfı ile ilişkilendirmenin iki yolu vardır; miras yaklaşımı veya delegasyon yaklaşımı. Bu örnekte miras yaklaşımı kullanılmıştır. Bu yaklaşımda, Orbix’teki IDL derleyicisi, iskelet sınıfını örneklendirmekle (instantiating) yükümlü olan gridBOAImpl adlı bir sınıf oluşturur. gridBOAImpl sınıfı, CORBA::Object sınıfından miras alan grid sınıfından miras alır. grid_i yürütme sınıfı, arayüz sınıfı ile yürütme sınıfı arasındaki eşleşmeyi tamamlamak için gridBOAImpl sınıfından miras alır. POA (Portable Object Adaptor) geliştirilmeden önce, CORBA iskelet sınıfının neye benzeyeceğini ve temel sınıfın ismini belirlemediği için, bu sınıf sadece Orbix’e özeldir. POA’nın geliştirilmesiyle, bu problem giderilmiş, ve temel sınıf için bir isim belirlenmiştir. Bu örnekte POA kullanılsaydı, temel sınıfın ismi POA_grid olacaktı. Tablo 4.3’te gösterilen üçüncü dosya, sunucu sınıfın yöntemlerini yürütür. DCOM dosyası aynı zamanda sınıf fabrikasının bazı yöntemlerini de yürütür. Tablo 4.4’te gösterilen dördüncü dosya, sunucu için ana programdır. DCOM programı, tüm aktif sunucu nesneleri silindiğinde uyaracak ve sunucunun kapanmasını sağlayacak bir olay (event) yaratır ve bu olayda bekler. Gerçek istemci çağrıları, bir thread havuzundaki farklı thread’ler tarafından aynı anda elde edilir. (Başka bir DCOM thread modeli, tek bir thread kullanarak istekleri seri olarak elde eder.) Benzer şekilde, CORBA sunucu programı grid_i sınıfının bir örneğini (instance) örneklendirir (instantiate), ve gelen istemci isteklerini almak için impl_is_ready()’de durur. Eğer sunucu varsayılan zaman aşımı içinde herhangi bir istek almazsa kapanır. İstemci istekleri, nesne sunucusu için kullanılan aktivasyon politikasına bağlı olarak, seri olarak veya farklı thread’ler vasıtasıyla elde edilir. Tablo 4.5’te gösterilen son dosya istemci kodudur. Ek IUnknown yöntem çağrıları yüzünden, DCOM kodu CORBA kodundan daha uzundur. Java veya Visual Basic’te yazılan DCOM istemcileri, sanal makine katmanı IUnknown yöntem çağrıları ile ilgilendiği ve onları programcılardan gizlediği için, daha kısa olabilir. C++ istemcisinde de, referans sayımını gizlemek için akıllı arayüz işaretçileri kullanılabilir. Programları derledikten sonra ve çalıştırmadan önce, hem DCOM hem de CORBA sunucu için bir kayıt işlemine ihtiyaç duyar. CORBA’da, arayüz ismi ile sunucu EXE’sinin yol (path) ismi arasındaki ilişki yürütme ambarında (implementation repository) tutulur. 74 DCOM’da, CLSID ile sunucu EXE’sinin yol (path) ismi arasındaki ilişki registry’de tutulur. DCOM arayüz proxy/stub’ı da bir COM nesnesi olduğundan, DLL biçimindeki bağlı olduğu sunucusu da benzer şekilde kayıt edilmelidir. Yer darlığından, derleme zamanında (compile-time) statik tip bilgisine ihtiyaç duymayan dinamik çağrılara değinmedik. DCOM’da, arayüz yöntemleri için tip bilgileri, IDL derleyicisi tarafından oluşturulan bir tip kütüphanesi’nde saklanır. IDispatch arayüzü vasıtasıyla dinamik çağrı yapmak için kullanılabilir. Tip kütüphanesi güdümlü dönüĢtürme (Soysal bir dönüştürücü, bir arayüze özel bir bilgi içeren ayrı bir proxy/stub DLL’i kullanmak yerine, tip kütüphanesi bilgisini okuyarak dönüştürmeyi yapabilir.) için de kullanılabilir. CORBA’da, IDL derleyicisi bir arayüzdeki her yöntem için tip bilgisini oluşturur, ve arayüz ambarı’nda saklar. İstemci arayüz ambarını ilgili bir arayüzle ilgili çalışma zamanı bilgisini almak için sorgulayabilir, ve bu bilgiyi dinamik çağrı arayüzü vasıtasıyla dinamik olarak nesne üzerindeki bir yöntemi yaratmak ve başlatmak için kullanabilir. Benzer şekilde, sunucu tarafındaki dinamik iskelet arayüzü, yürüttüğü nesnenin tipinin derleme zamanı bilgisi olmayan nesne üzerindeki bir işlemin, bir istemci tarafından başlatılmasına izin verir. DCOM IDL CORBA IDL // IGrid1’in tanımlanması ve uuid [ object, uuid(3CFDB283-CCC5-11D0-BA0B-00A0C90DF8BC), helpstring("IGrid1 Interface"), pointer_default(unique) ] interface IGrid1 : IUnknown { interface grid1 import "unknwn.idl"; { HRESULT get([in] SHORT n, [in] SHORT m, [out] LONG *value); long get(in short n, in short m); HRESULT set([in] SHORT n, [in] SHORT m, [in] LONG value); void set(in short n, in short m, in long value); }; }; // Igrid2’in tanımlanması ve uuid [ object, uuid(3CFDB284-CCC5-11D0-BA0B-00A0C90DF8BC), helpstring("IGrid2 Interface"), pointer_default(unique) ] interface IGrid2 : IUnknown { import "unknwn.idl"; HRESULT reset([in] LONG value); }; // tip kütüphanesinin tanımlanması ve uuid [ uuid(3CFDB281-CCC5-11D0-BA0B-00A0C90DF8BC), version(1.0), helpstring("grid 1.0 Type Library) ] library GRIDLib { importlib("stdole32.tlb"); // sınıfın tanımlanması ve uuid [ uuid(3CFDB287-CCC5-11D0-BA0B-00A0C90DF8BC), helpstring("Grid Class") ] // çoklu arayüzler coclass CGrid { [default] interface IGrid1; interface IGrid2; }; }; interface grid2 { void reset(in long value); }; // arayüzlerin çoklu miras alma olayı interface grid: grid1, grid2 { }; Tablo 4.1. IDL (Arayüz Tanımlama Dili) dosyaları 75 DCOM sunucu sınıf tanımı (cgrid.h) #include "grid.h" // IDL tarafından oluşturulan arayüz // başlık dosyası CORBA sunucu sınıf tanımı (grid_i.h) #include "grid.hh" // IDL tarafından oluşturulan arayüz // başlık dosyası class CClassFactory : public IClassFactory { public: // IUnknown STDMETHODIMP QueryInterface(REFIID riid, void** ppv); STDMETHODIMP_(ULONG) AddRef(void) { return 1; }; STDMETHODIMP_(ULONG) Release(void) { return 1; } // IClassFactory STDMETHODIMP CreateInstance(LPUNKNOWN punkOuter, REFIID iid, void **ppv); STDMETHODIMP LockServer(BOOL fLock) { return E_FAIL; }; }; class CGrid : public IGrid1, public IGrid2 { public: // IUnknown STDMETHODIMP QueryInterface(REFIID riid, void** ppv); STDMETHODIMP_(ULONG) AddRef(void) { return InterlockedIncrement(&m_cRef); } STDMETHODIMP_(ULONG) Release(void) { if (InterlockedDecrement(&m_cRef) == 0) { delete this; return 0; } return 1; } // IGrid1 STDMETHODIMP get(IN SHORT n, IN SHORT m, OUT LONG *value); STDMETHODIMP set(IN SHORT n, IN SHORT m, IN LONG value); // IGrid2 STDMETHODIMP reset(IN LONG value); CGrid(SHORT h, SHORT w); ~CGrid(); private: LONG m_cRef, **m_a; SHORT m_height, m_width; }; class grid_i : public gridBOAImpl { public: virtual CORBA::Long get(CORBA::Short n, CORBA::Short m, CORBA::Environment &env); virtual void set(CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &env); virtual void reset(CORBA::Long value, CORBA::Environment &env); grid_i(CORBA::Short h, CORBA::Short w); virtual ~grid_i(); private: CORBA::Long **m_a; CORBA::Short m_height, m_width; }; Tablo 4.2. Sunucu yürütme başlık dosyaları DCOM sunucu yürütmesi #include "cgrid.h" CORBA sunucu yürütmesi #include "grid_i.h" STDMETHODIMP CClassFactory::QueryInterface(REFIID riid, void** ppv) { if (riid == IID_IClassFactory || riid == IID_IUnknown) { *ppv = (IClassFactory *) this; AddRef(); return S_OK; } *ppv = NULL; return E_NOINTERFACE; } STDMETHODIMP CClassFactory::CreateInstance(LPUNKNOWN p, REFIID riid, void** ppv) { IGrid1* punk = (IGrid1*) new CGrid(100, 100); HRESULT hr = punk->QueryInterface(riid, ppv); punk->Release(); return hr; } STDMETHODIMP CGrid::QueryInterface(REFIID riid, void** ppv) { if (riid == IID_IUnknown || riid == IID_IGrid1) *ppv = (IGrid1*) this; else if (riid == IID_IGrid2) *ppv = (IGrid2*) this; else { *ppv = NULL; return E_NOINTERFACE; } AddRef(); return S_OK; } STDMETHODIMP CGrid::get(IN SHORT n, IN SHORT m, OUT LONG* value) { *value = m_a[n][m]; return S_OK; } CORBA::Long grid_i::get(CORBA::Short n, CORBA::Short m, CORBA::Environment &) { return m_a[n][m]; } STDMETHODIMP CGrid::set(IN SHORT n, IN SHORT m, IN LONG value) { m_a[n][m] = value; return S_OK; } void grid_i::set(CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &) { m_a[n][m] = value; } 76 STDMETHODIMP CGrid::reset(IN LONG value) { SHORT n, m; for (n=0; n < m_height; n++) for (m=0; m < m_width; m++) m_a[n][m] = value; return S_OK; } void grid_i::reset(CORBA::Long value, CORBA::Environment &) { short n, m; for (n = 0; n < m_height; n++) for (m = 0; m < m_width; m++) m_a[n][m]=value; return; } CGrid::CGrid(SHORT h, SHORT w) { m_height = h; m_width= w; m_a = new LONG*[m_height]; for (int i=0; i < m_height; i++) m_a[i] = new LONG[m_width]; m_cRef = 1; } grid_i::grid_i(CORBA::Short h, CORBA::Short w) { m_height=h; // set up height m_width=w; // set up width m_a = new CORBA::Long* [h]; for (int i = 0; i < h; i++ ) m_a[i] = new CORBA::Long[w]; } extern HANDLE hevtDone; CGrid::~CGrid () { for (int i=0; i < m_height; i++) delete[] m_a[i]; delete[] m_a; SetEvent(hevtDone); } grid_i::~grid_i () { for (int i = 0; i < m_height; i++) delete[] m_a[i]; delete[] m_a; } Tablo 4.3. Sunucu yürütme dosyaları DCOM sunucu ana programı CORBA sunucu ana programı HANDLE hevtDone; void main() { // Ana thread’in işaretini vermek için kullanılan olay hevtDone = CreateEvent(NULL, FALSE, FALSE, NULL); hr = CoInitializeEx(NULL, COINIT_MULTITHREADED); CClassFactory* pcf = new CClassFactory; hr = CoRegisterClassObject(CLSID_CGrid, pcf, CLSCTX_SERVER, REGCLS_MULTIPLEUSE, &dwRegister); // Olay CGrid::~CGrid() tarafından alınana kadar bekle WaitForSingleObject(hevtDone, INFINITE); CloseHandle(hevtDone); CoUninitialize(); } int main() { // grid_i yürütme sınıfını kullanarak bir grid nesnesi oluşturma grid_i ourGrid(100,100); try { // Sunucunun başlatılmasının tamamlandığını Orbix’e söyleme CORBA::Orbix.impl_is_ready("grid"); } catch (...) { cout << "Unexpected exception" << endl; exit(1); } } Tablo 4.4. Sunucu ana programları DCOM istemci kodu CORBA istemci kodu #include "grid.h" #include "grid.hh" void main(int argc, char**argv) { IGrid1 *pIGrid1; IGrid2 *pIGrid2; LONG value; void main (int argc, char **argv) { grid_var gridVar; CORBA::Long value; CoInitialize(NULL); // COM’u başlatma CoCreateInstance(CLSID_CGrid, NULL, CLSCTX_SERVER, IID_IGrid1, (void**) &pIGrid1); pIGrid1->get(0, 0, &value); pIGrid1->QueryInterface(IID_IGrid2, (void**) &pIGrid2); pIGrid1->Release(); pIGrid2->reset(value+1); pIGrid2->Release(); CoUninitialize(); // "grid" nesnesine bağlanma (Orbix’e özel) gridVar = grid::_bind(":grid"); value = gridVar->get(0, 0); gridVar->reset(value+1); } } Tablo 4.5. İstemci ana progamları 77 4.2. Üst Katman: Temel Programlama Mimarisi Üst katmanda, DCOM’un ve CORBA’nın programcılar için olan görünümü yer alır. Bir istemcinin bir nesneye nasıl istek yapacağı ve yöntemlerini çağıracağı, ve bir sunucunun nasıl bir nesne örneğini yaratacağı ve istemci için hazır hale getireceği bu katmanda açıklanacaktır. Gerçekte istemcinin sunucuya nasıl bağlanacağı programcılardan tamamen gizlenmiştir. İstemci ve sunucu programları aynı makinedeki aynı adres alanında yer alıyorlarsa etkileşirler. Bu katmandaki DCOM ile CORBA arasındaki temel farklardan biri, istemcinin arayüzü nasıl tanımlayacağı, diğeri de COM’un sınıf fabrikaları ve IUnknown yöntemleridir. Tablo 4.6’da adım adım karşılaştırma verilmiş, ġekil 4.4’te DCOM için, ġekil 4.5’te de CORBA için gösterilmiştir. (Parantez içindeki numaralar nesne aktivasyon adımları için, köşeli parantez içindekiler ise yöntem çağrı adımları içindir.) Her ne kadar Tablo 4.6 genel bir DCOM çağrı sırası verse de, iki noktaya değinmek gerekmektedir. Bunlardan ilki, COM’da sınıf fabrikası kullanımının seçime bağlı olmasıdır. Bir sunucu nesnesi gerçekte herhangi bir arayüz işaretçisini kaydetmek için CoRegisterClassObject() nesnesini çağırır, ve istemciler bu işaretçiyi kazanmak için CoGetClassObject() adında başka bir COM API’sini çağırabilirler. İkinci önemli nokta ise, CoCreateInstance() yeni bir boş örnek yaratamaz. Bir sunucu, IClassFActory::CreateInstance() içinde, farklı istemcilerin aynı nesne örneğine belirli bir durumda bağlanabilmelerini sağlamak için, her zaman aynı arayüz işaretçisini döndürmeyi seçebilir. İsimlendirilmiş sunucu nesne örneğine bağlanmanın başka bir yolu da moniker’ları ve/veya Çalışan Nesne Tablolarını (ROT – Running Object Table) kullanmaktır. CORBA’da bir nesne, varolan bir nesne referansındaki herhangi bir yöntemin çağrılması ile aktif hale getirilir. Bazı üreticiler özel yöntem çağrıları sağlarlar. Örneğin Orbix’te _bind() işlemi bir sunucu nesnesini aktif hale getirir ve nesne referansını elde eder. Eğer istenilen tipe uyan varolan bir örnek varsa, istemci yeni bir örnek yerine varolan bu örneğe eklenebilir. Bir istemci, bir nesne referansını object_to_string() kullanarak karakterlere dönüştürüp saklayabilir, ve daha sonra string_to_object() ile tekrar eski haline dönüştürerek kullanabilir. DCOM ile CORBA arasındaki programlama katmanı farklarından bir diğeri de, istisnai hataları ele alma biçimleridir. CORBA standart C++ hatalarını ve CORBA’ya özel bazı hataları destekler. Buna ek olarak, kullanıcı tanımlı istisnai hataların da IDL içinde tanımlanmasına izin verir. IDL derleyicisi kullanıcı tanımlı istisnai hata ile bir C++ sınıfını 78 eşleştirir. Bunun aksine, DCOM tüm yöntemlerin HRESULT adı verilen 32-bit’lik hata kodu döndürmesine ihtiyaç duyar. Dil/araç katmanında, bir anlaşmalar ve sistem destekli servisler kümesi (IErrorInfo nesnesi), hatalı HRESULT’ların dile özgü bir biçimde istisnai hatalara dönüştürülmesine izin verir. Örneğin Microsoft Visual C++’ta, istemci programcıları standart C++ try/catch bloklarını kullanarak COM yöntem çağrılarından hataları yakalayabilirler. Derleyici hatalı dönüş kodunu bir istisnai hataya dönüştürerek, HRESULT’ı IErrorInfo’nun doğru kullanımı ile eşleştirir. DCOM tel protokolü, body extensions diye bilinen zengin istisnai hata bilgisinin taşınmasına izin veren bir mekanizma içerir. DCOM CORBA Nesne Aktivasyonu 1. İstemci COM kütüphanesinin CoCreateInstance()’ını CLSID_Grid ve IID_IGrid1 ile çağırır. 1. İstemci, istemci stub’ının statik bir fonksiyonu olan grid::_bind()’ını çağırır. 2. COM altyapısı olan CLSID_Grid için bir nesne sunucusu başlatır. 2. ORB, grid arayüzünü destekleyen bir nesne içeren bir sunucuyu başlatır. 3. Sunucu ana programında görüldüğü gibi, sunucu tüm desteklenen CLSID’ler için sınıf fabrikaları üretir ve her fabrikayı kaydetmek için CoRegisterClassObject()’i çağırır. 3. Sunucu ana programında görüldüğü gibi,tüm desteklenen nesneleri, örneklendirir. (Her constructor’da, çağrılar bir nesne referansını yaratmak ve kaydetmek için yapılır.) Sunucu, kendisine artık ihtiyaç olmadığını bildiren bir sinyal gibi bir olayı bekliyor. Gelen istemci isteklerine başka thread’ler hizmet edecekler. Sunucu istemci isteklerini almaya hazır olduğunu ORB’ye bildirmek için CORBA::BOA::impl_is_ready() ’yi çağırır. 4. COM CLSID_Grid fabrikasından IClassFactory işaretçisini elde eder, ve CreateInstance()’ı onun üzerinde başlatır. 5. CreateInstance()’ta, sunucu bir nesne örneği üretir ve IID_IGrid1 arayüzüne bir arayüz işaretçisi bulmak için bir QueryInterface() çağrısı yapar. 6. COM arayüz işaretçisini pIGrid1 olarak istemciye geri döndürür. 4. ORB grid için nesne referansını gridVar olarak istemciye geri döndürür. 79 Yöntem Çağrımı 1. İstemci ilerde sunucuda CGrid::get()’i çağıracak olan pIGrid1->get()’i çağırır. 1. İstemci ilerde sunucuda grid_i::get()’i çağıracak olan GridVar->get()’i çağırır. 2. Aynı nesne örneğinin başka bir IID_IGrid2 arayüzüne bir işaretçi sağlamak için, istemci CGrid::QueryInterface’i çağıran pIGrid1->QueryInterface()’i çağırır. 3. pIGrid1’in kullanımı bittiğinde istemci, CGrid::Release()’i çağırmayabilecek olan pIGrid1->Release()’i çağırır.1 4. İstemci CGrid::reset()’i çağıran pIGrid2->reset()’i çağırır. 2. İstemci grid_i::reset()’i çağıran GridVar->reset()’i çağırır. 5. İstemci CGrid::Release()’i çağıran pIGrid2->Release()’i çağırır. Tablo 4.6. Üst katman tanımlaması İstemci COM çalışma zamanı sistemi Sunucu (4) Sınıf Fabrikası Temel Programlama Katmanı (3) (6) (1) COM Kütüphanesi (2) Erişim Katmanı (5) Nesne COM Kütüphanesi [1] [2] [3] [4] [5] ġekil 4.4. Üst katmandaki DCOM adımları 1 Performans sebebiyle, bir istemcinin aynı nesnede tutmakta olduğu tüm arayüz işaretçileri bırakılmadan, ayrık arayüzler için Release() çağrıları sunucu tarafına aksettirilmeyebilir. Bu, istemci tarafından tekrar istenebilecek arayüz işaretçilerinin saklanmasına, ve alt katmanların bir uzak çağrıda birçok Release() çağrısını toplamalarına izin verir. 80 İstemci ORB Sunucu Temel Programlama Katmanı istemci stub Nesne (4) (1) COM Kütüphanesi (2) Erişim Katmanı (3) Nesne Adaptörü [1] [2] ġekil 4.5. Üst katmandaki CORBA adımları 4.3. Ara Katman: EriĢim Mimarisi Altyapıdan oluşan ara katman istemciyi ve sunucuyu aynı adres alanında olduklarına inandırmak için gereklidir. Tablo 4.7’deki tanımlama, farklı işlemler üzerinde bir yöntem çağrımı meydana geldiğinde, altyapının istek yapılan sunucuya ve içerdiği varlıklara nasıl eriştiğini ve onu nasıl başlattığını gösterir. DCOM için ġekil 4.6’da, CORBA için de ġekil 4.7’de ilgili çizimler verilmiştir. Bu katmanda CORBA ile DCOM arasındaki en önemli farklar; sunucu nesnenin nasıl kaydedileceği ve proxy/stub/iskelet örneklerinin ne zaman yaratılacağı konularını içerir. Verinin farklı adres alanları üzerinde aktarımı, dönüştürme (marshaling) ve geri dönüştürme (unmarshaling) denilen bir işlem gerektirir. Dönüştürme, bir yöntem çağrımının parametrelerinin istemcinin alanında, veya geri dönüş değerlerinin sunucunun alanında, taşıma için standart biçimde paketlenmesidir. Geri dönüştürme ise, gelen işlemin adres alanında, bu paketlerin açılarak ilgili veri biçimine dönüştürülmesidir. Bu bölümde anlatılan dönüştürme DCOM terminolojisinde standart dönüştürme olarak geçer. DCOM, standart dönüştürme prosedürünün haricinde bir özel dönüştürme mekanizması da içerir. Bir sunucu nesnesi, bir IMarshal arayüzünü yürüterek, hangi verinin ve nasıl dönüştürüleceği ve geri dönüştürüleceğini, ve istemcinin sunucuyla nasıl iletişim kurması gerektiğini kontrol etmek istediğini beyan eder. Tablo 4.7’de kullanılan bazı CORBA terimlerini açıklayalım. Nesne adaptörünün nesne yürütmeleri ile ORB arasındaki haberleşmeden sorumlu olduğunu 2. bölümde (2.2.11) görmüştük. Nesne adaptörleri, nesne referanslarının oluşturulması ve izahı, yöntem çağrıları, nesne aktivasyonu, ve nesne referansları ile yürütmelerin eşlenmesi ile ilgili servisler sağlarlar. Farklı nesne yürütme biçimlerinin farklı ihtiyaçları vardır, ve farklı nesne 81 adaptörleri tarafından desteklenmeye ihtiyaç duyarlar. Örneğin bir veritabanındaki nesneler için nesneye yönelik veritabanı adaptörü gibi. Temel Nesne Adaptörü (BOA – Basic Object Adapter) en geleneksel nesne yürütmelerinde kullanılabilecek bir nesne adaptörü tanımlar. CORBA tanımları, ORB/BOA fonksiyonelliğinin nasıl yürütülmesi gerektiği konusunda emir vermezler. Orbix, ORB/BOA fonksiyonelliğini iki kütüphane ve bir cin (daemon) işleminde (orbixd) gerçekleştirir. Cin nesnelerin yerleştirilmesi ve aktivasyonundan sorumludur. Fonksiyonelliğin geri kalanını sağlamak için Sunucu tarafı kütüphane ve istemci tarafı kütüphane derleme zamanında sunucu ve istemci yürütmeleri ile bağlanırlar. BOA’nın yerini artık POA (Portable Object Adapter) almıştır. POA tanımları CORBA sunucu kodu için taşınabilirlik sağlamış, ve aynı zamanda nesne adaptörüne bazı yeni özellikler kazandırmıştır. (POA hakkında daha detaylı bilgi için bakınız: 2.7.1) DCOM CORBA Nesne Aktivasyonu 1. CoCreateInstance() çağrısının gelmesi üzerine, COM kütüphanesi görevi SCM’ye havale eder. 1. grid::_bind() çağrısının gelmesi üzerine, istemci stub’ı görevi ORB’ye havale eder.1 2. SCM, CLSID_Grid için bir sınıf fabrikası kayıtlı mı diye bakar; değilse, CLSID_Grid ile sunucusunun yol ismini eşleştirmek için registry’e danışır, ve sunucuyu başlatır. 2. ORB grid ile sunucusunun yol ismini eşleştirmek için Yürütme Ambarına danışır, ve sunucuyu aktive eder (Orbix’te, orbixd cini sunucu işlemini ayırır). 3. Sunucu, desteklenen tüm sınıf fabrikalarını bir sınıf nesne tablosuna kaydeder. 3. Sunucu, aralarında grid_i sınıfının bir grid nesnesi de bulunan, desteklenen tüm nesneleri örneklendirir. grid_i sınıfı dolaylı olarak, constructor’ı bir nesne referansını geri almak için, bir tekil referans belirleyicisiyle BOA::create()’i çağıran, CORBA::Object’ten miras alınmıştır. Daha sonra obj_is_ready()’yi çağırarak nesne referansını ORB’ye kaydeder. 4. SCM, tablodan CLSID_Grid fabrikasına doğru olan IClassFactory işaretçisini alır, ve CreateInstance()’ı onun üzerinde başlatır. 1 Aslında, stub ilk önce grid için halihazırda bir nesne referansı olup olmadığını görmek için proxy nesne tablosunu kontrol eder. Proxy nesne tablosu, istemci tarafındaki tüm geçerli nesne referanslarının bir çalışma zamanı tablosunu ihtiva eder. 82 5. CreateInstance(), IID_IGrid1 işaretçisini döndürdüğünde, COM (kavramsal olarak) yeni yaratılmış nesne örneği için bir nesne stub’ı yaratır. 4. grid_i sınıfı için constructor iskelet sınıfının örneğini de yaratır.1 6. Nesne stub’ı arayüz işaretçisini dönüştürür, IID_IGrid1 için bir arayüz stub’ı yaratmak için registry’e danışır, ve sunucu nesnesinin gerçek IID_IGrid1 arayüzü ile onu ilişkilendirir. 7. SCM, dönüştürülmüş işaretçiyi istemci tarafına geri taşıdığında, COM nesne örneği için bir nesne proxy’si yaratır. 8. Nesne proxy’si işaretçiyi geri dönüştürür, IID_IGrid1 için bir arayüz proxy’si yaratmak üzere registry’e danışır, ve onu stub’a bağlı olan RPC kanal nesnesi ile ilişkilendirir. 5. ORB, nesne referansını istemci tarafına geri taşıdığında, proxy sınıfının bir örneğini yaratır, ve ilgili nesne referansıyla beraber proxy nesne tablosuna kaydeder. 9. COM kütüphanesi, arayüz 6. İstemci stub’ı nesne refernasını proxy’sine doğru olan bir istemciye gridVar olarak geri IID_IGrid işaretçisini, istemciye döndürür. pIGrid1 olarak geri döndürür. Yöntem Çağrımı 1. pIGrid1->get() çağrısının gelmesi 1. gridVar->get() çağrısının gelmesi üzerine, arayüz proxy’si gerekli üzerine, proxy bir istek pseudo parametreleri dönüştürür, ve nesnesi yaratır, gerekli isteği göndermek için RPC kanalı parametreleri burada dönüştürür, nesnesinde SendReceive() ve mesajı kanala koyması için yöntemini başlatır. CORBA::Request::send()’i çağıran Request::invoke()’u çağırır, ve CORBA::Request::get_response()’ta cevap için bekler. 2. RPC kanalı, isteği sunucu 2. Mesaj sunucuya ulaştığında, BOA tarafına gönderir, hedef olan hedef olan iskeleti bulur, IID_IGrid1 arayüz stub’ını bulur, istenilen nesneyi yeniden ve Invoke() yöntemini onun oluşturur, ve iskelete gönderir. üzerinde çağırır. 3. Arayüz stub’ı parametreleri geri dönüştürür, bir yöntem numarası 1 3. İskelet parametreleri istenilen nesneden geri dönüştürür, bir 3. ve 4. adımlar, bir dereceye kadar POA’daki açık aktivasyon politikasına bağlıdır. POA nesne aktivasyonu ile ilgili birçok politika önerir. 83 ile belirlenen yöntemi grid nesnesi üzerinde başlatır, dönüş değerlerini geri dönüştürür ve Invoke yönteminden geri döner. yöntem ismi ile belirlenen yöntemi grid nesnesi üzerinde başlatır, dönüş değerlerini geri dönüştürür ve iskelet yönteminden geri döner. ORB bir yanıt mesajı oluşturur ve nakil tampon bölgesine yerleştirir. 4. RPC kanalı dönüştürülmüş dönüş değerlerini istemciye geri aktardığında, arayüz proxy’si SendReceive() çağrısından döner, dönüş değerlerini geri dönüştürür, pIGrid1->set() çağrısını bitirmek için onları istemciye geri döndürür. 4. Yanıt istemciye ulaştığında, CORBA::Request::get_response() çağrısı, alıcı tampon bölgesinden yanıtı okuduktan sonra geri döner. Proxy dönüş değerlerini geri dönüştürür, istisnai hataları kontrol eder, ve gridVar->get() çağrısını bitirmek için onları istemciye geri döndürür. 5. pIGrid1->QueryInterface() çağrısının gelmesi üzerine, arayüz proxy’si isteği nesne proxy’sinin IUnknown arayüzüne havale eder. 6. Nesne proxy’si yukarıda açıklanan işleme benzer bir şekilde gerçek QueryInterface() çağrısını grid üzerinde başlatır. 7. Yeni IID_IGrid2 arayüz işaretçisinin geri dönmesi üzerine, COM onun için arayüz stub’ını ve proxy’yi (IID_IGrid1 arayüz stub’ı ve proxy’si ile aynı nesne stub’ı ve proxy’sini paylaşan) yaratır. 8. IID_IGrid1 arayüz proxy’si istemciye, yeni arayüz proxy’sine doğru olan bir IID_IGrid2 işaretçisini geri döndürür. 9. pIGrid1->Release() çağrısının gelmesi üzerine, IID_IGrid1 arayüz proxy’si isteği nesne proxy’sine havale eder. 10. pIGrid2->reset() çağrısının 5. gridVar->reset() çağrısının gelmesi üzerine, her zaman olduğu gelmesi üzerine, proxy benzer bir gibi IID_IGrid2 proxy’si uzak prosedür takip eder. çağrıyı yapar. 11. pIGrid2->Release() çağrısının, gelmesi üzerine, IID_IGrid2 arayüz proxy’si, bırakılan pIGrid2’ye (ve muhtemelen pIGrid1’e) bir uzak çağrı yapacak olan nesne proxy’sine isteği havale eder. Tablo 4.7. Ara katman tanımlaması 84 İstemci Sunucu Sınıf Nesne Tablosu Sınıf Fabrikası (3) Temel Programlama Katmanı [8] (9) Nesne (4) (2) COM Kütüphanesi Erişim Katmanı ara proxy ara proxy (1) [1] (5) SCM(ler) & Registry [4] nesne stub’ı [3] (6) ara stub [2] RPC Kanalı Tel Katmanı [5] (8) (7) [9] [6] nesne proxy COM Kütüphanesi ara stub [7] [10] [11] ġekil 4.6. Ara katmandaki DCOM adımları İstemci Sunucu Nesne Temel Programlama Katmanı (6) istemci stub’ı (proxy) (2) Erişim Katmanı CORBA kütüphanesi (1) ORB(ler) (orbixd) & Yürütme Ambarı (5) [1] [4] (4) Nesne İskeleti (3) Tel Katmanı Nesne Adaptörü [2] İletişim Kanalı [3] ġekil 4.7. Ara katmandaki CORBA adımları 4.4. Alt Katman: Tel Protokol Mimarisi Alt katman, farklı makinelerde çalışan istemci ve sunucuyu desteklemek için bir tel protokolü belirler. Tablo 4.8’deki tanımlama, uzak makinedeki nesnelerin nasıl yaratıldığını ve bir yöntem çağrımı makineler arasında taşınırken görev yapan varlıkları tarif eder. DCOM için ġekil 4.8’de, CORBA için de ġekil 4.9’da ilgili çizimler verilmiştir. DCOM ve CORBA arasında, bu katmandaki en temel farklar; uzak arayüz işaretçilerinin veya nesne 85 referanslarının sunucunun son nokta (endpoint) bilgisini istemciye taşınması için nasıl gösterileceği, ve bir heterojen ortamdaki aktarım için dönüştürülen verideki standart biçim konularını içerir. CORBA, aynı firma tarafından sağlanmış ORB’ler üzerinde çalışan bir nesne sunucusu ile bir istemci arasındaki iletişim için bir protokol belirlememiştir. Aynı firma ORB’ları arasındaki ORB’lar arası iletişim için protokol, firmaya bağımlıdır. Ama, farklı ORB ürünlerinin birbirleriyle etkileşebilmelerini sağlamak üzere, bir Genel ORB’lar arası protokol (GIOP - General Inter-ORB Protocol) belirlenmiştir. GIOP’un TCP/IP bağlantıları üzerindeki spesifik bir eşlenmesi tanımlanmıştır, ve IIOP (Internet Inter-ORB Protocol) olarak bilinir. CORBA için, hem IIOP hem de Orbix yürütmeleri için tanımlamalar verilmiştir. DCOM tel protokolü birkaç istisna dışında, çoğunlukla OSF DCE RPC tanımlamasına dayandırılmıştır. Uzak nesne referans gösterimini, uzak IUnknown yöntem çağrılarının performansını en iyi hale getirmek için bir IRemUnknown arayüzünü, ve bir ping’leme protokolünü içerir. 3. bölümde de değindiğimiz gibi ping’leme, uzak istemci anormal bir şekilde sonlandığında, sunucu nesnesinin uzak nesne referanslarının artıklarını toplamasına izin verir. Bir istemci ilk defa uzak bir nesneye işaretçi elde ettiğinde, istemci makinesindeki ping istemci kodu nesneyi bir ping listesine ekler, ve istemcinin hala hayatta olduğundan haberdar etmek için periyodik olarak sunucu makineye ping gönderir. Ardışık ping’lerin önceden tanımlanmış sayıdaki bir kaybı, istemcinin anormal bir biçimde sonlandığını, ve tuttuğu arayüz işaretçilerin bırakılabileceğini gösterir. Performansı en iyi seviyeye getirmek için, ping’ler makine bazlı ve artan bir sırada gönderilir. Normal mesajların içine gömülü de olabilirler. Gerektiğinde, ağ trafiğini azaltmak için ping işlevi kapatılabilir. DCOM CORBA Nesne Aktivasyonu 1. Havale edilen CoCreateInstance() isteğinin gelmesi üzerine, eğer istemci tarafı SCM yerel registy’e danıştığında grid nesnesinin farklı bir sunucu makinesine yerleştirilmesi gerektiğini görürse, sunucu tarafı SCM üzerindeki IRemoteActivation RPC arayüzünün bir yöntemini çağırır. 1. Havale edilen grid::_bind() isteğinin gelmesi üzerine, istemci tarafı ORB gridi destekleyen makineyi seçmek için bir yer belirleyici dosyaya danışır ve TCP/IP üzerinden sunucu tarafı ORB’ye bir istek gönderir. 86 2. Sunucu, sunucu tarafı SCM tarafından başlatıldığında, bir nesne ihracatçısı ile eşleştirilir, ve bir nesne ihracatçısı belirleyicisine (OXID) atanır. OXID ile sunucuya ulaşmak için kullanılabilecek RPC bağı eşleştirilmesi, sunucu tarafı OXID tasarlayıcısı ile kaydedilir. 3. Nesne stub’ı CreateInstance() tarafından döndürülen IID_IGrid1 işaretçisini dönüştürdüğünde, işaretçi sunucu içinde tekil olan bir arayüz işaretçi belirleyicisine (IPID) atanır. Bir nesne referansı da (OBJREF) işaretçiyi temsil etmek için yaratılır. Bir OBJREF, IPID, OXID, OXID çözümleyicilerinin adresleri (her protokole bir tane) gibi bilgileri içerir. 4. Dönüştürülmüş arayüz işaretçisi, sunucu tarafı ve istemci tarafı SCM’lerinin üzerinden istemci tarafına geri döndüğünde, nesne proxy’si OBJREF’ten OXID ve OXID çözümleyicilerinin adreslerini çıkarır, ve yerel OXID çözümleyicisinin IOXIDResolver:ResolveOxid() yöntemini çağırır. 5. İstemci tarafı IXID çözümleyicisi OXID için bir tampon eşlemesinin olup olmadığına bakar; yok ise, kayıtlı RPC bağlantısını döndüren sunucu tarafı OXID çözümleyicisinin IOXIDResolver:ResolveOxid() yöntemini çağırır. 6. İstemci tarafı çözümleyicisi eşlemeyi tampona alır, ve nesne proxy’sine RPC bağlantısını geri döndürür. Bu, nesne ihracatçısına bağlı olan bir RPC kanalını yaratmak üzere, nesne proxy’sinin kendisine ve arayüz proxy’lerine bağlanmasına izin verir. 2. Sunucu, sunucu tarafı ORB tarafından başlatıldığında, bir grid nesnesi sunucu tarafından örneklendirilir, CORBA::Object constructor’ı çağrılır, ve BOA::create() başlatılır. BOA::create()’in içinde, BOA bir soket son noktası (endpoint) üretir, grid nesnesi sunucu içinde tekil olan bir nesne belirleyicisine atanır, arayüz ve yürütme isimlerini, referans belirleyicisini ve son nokta adresini içeren bir nesne referansı yaratılır. IIOP protokolünde konuşan istemciler için, sunucu bir makine ismi, bir TCP/IP port numarası, ve bir object_key içeren, birbirleriyle etkileşebilen nesne referansı (IOR – Interoperable Object Reference) oluşturur. BOA nesne referansını ORB ile kaydeder. 3. Nesne referansı istemci tarafına geri döndüğünde, proxy son nokta adresini çıkarır ve sunucuya bir soket bağlantısı kurar. 87 Yöntem Çağrımı 1. pIGrid1->get() çağrısının gelmesi 1. gridVar->get() çağrısının gelmesi üzerine, arayüz proxy’si Ağ Veri üzerine, proxy Genel Veri Gösterimi (NDR - Network Data Gösterimi (CDR – Common Data Representation) biçimindeki Representation) biçimindeki parametreleri dönüştürür. parametreleri dönüştürür. 2. RPC kanalı, OXID-çözümlü RPC 2. İstek, kurulan soket bağlantısı bağlantısı tarafından tanımlanmış üzerinden hedef sunucuya hedef nesne ihracatçısına isteği gönderilir. gönderir. 3. Sunucu tarafı RPC altyapısı, RPC başlığında bulunan IPID’ye dayandırılan hedef arayüz stub’ını bulur. 3. Hedef iskelet, referans belirleyicisi veya object_key olarak teşhis edilir. 4. Sunucu nesnesindeki gerçek yöntemi başlattıktan sonra, arayüz stub’ı dönüş değerlerini NDR biçimine dönüştürür. 4. Sunucu nesnesindeki gerçek yöntemi başlattıktan sonra, iskelet dönüş değerlerini NDR biçimine dönüştürür. 5. havale edilen pIGrid1->QueryInterface() çağrısının gelmesi üzerine, nesne proxy’si hedef nesne ihracatçısındaki OXID nesnesi1 üzerinde IRemUnknown::RemQueryInterface() yöntemini çağırır. OXID nesnesi daha sonra QueryInterface() yöntemini ihracatçı içindeki arayüzler (muhtemelen birden çok olurlar) üzerinde çağırır. 6. havale edilen pIGrid1->Release() çağrısının gelmesi üzerine, nesne proxy’si hedef nesne ihracatçısındaki OXID nesnesi üzerinde IRemUnknown::RemRelease yöntemini çağırır. OXID nesnesi daha sonra Release() yöntemini ihracatçı içindeki arayüzler üzerinde çağırır. Tablo 4.8. Alt katman tanımlaması 1 Her nesne ihracatçısı için bir OXID vardır. Her OXID nesnesi RemQueryInterface(), RemAddRef(), ve RemRelease() yöntemlerinden oluşan bir IRemUnknown arayüzünü destekler. Bu yöntemler performansı arttırmak için, aynı nesne ihracatçısına tahsis edilen birden çok uzak IUnknown yöntem çağrılarına izin verirler. Bu tip çağrıların hepsi ilk önce OXID nesnesi tarafından elde edilir, ve daha sonra hedef arayüze yönlendirilir. Bu ve diğer alt katman API’leri aslında yürütme detaylarıdırlar. Uygulama programcıları bunlarla karşılaşmazlar. 88 İstemci Sunucu Sınıf Fabrikası Temel Programlama Katmanı Nesne [1] ara nesne proxy proxy COM Kütüphanesi OBJREF (3) Erişim Katmanı SCM (4) (1) Registry SCM [4] nesne stub’ı ara stub [3] [5] Registry OXID nesnesi Kanalı Tel RPC Katmanı [2] (6) [6] OXID çözümleyicisi (5) COM Kütüphanesi Nesne ihracatçısı OXID çözümleyicisi (2) OXID ġekil 4.8. Alt katmandaki DCOM adımları İstemci Sunucu Nesne Temel Programlama Katmanı [1] istemci stub’ı (proxy) [3] Erişim Katmanı CORBA kütüphanesi (3) yerleştirici ORB Yürütme Ambarı (1) ORB Tel Katmanı Nesne İskeleti Nesne Adaptörü (2) IOR TCP Soketi ġekil 4.9. Alt katmandaki CORBA adımları [2] [4] 89 5. SONUÇLAR Değişik zamanlarda, farklı platformlar ve farklı programlama dilleri ile, birbirinden bağımsız olarak tasarlanmış yazılım bileşenlerinin, birlikte çalışabilmelerine imkan sağlayan dağıtık nesne yönetimi mimarilerinin önümüzdeki yıllarda da kullanım oranlarının giderek daha fazla artması beklenmektedir. DCOM ve CORBA mimarilerinin geleceğine baktığımızda; COM ve DCOM’un .NET altında çalışmaya devam edeceğini, ve CORBA’nın da MDA altında varlığını sürdüreceğini söyleyebiliriz. Diğer dağıtık nesne yönetimi mimarilerinin, şu an için bu iki mimari ile rekabet edebilecek seviyelerde olmadıklarını görmekteyiz. Üç katmanlı adım adım tanımlamalar, DCOM ve CORBA mimarilerinin temel olarak benzer olduklarını göstermiştir. Her ikisi de şeffaf aktivasyonlar ve uzak nesne erişimi için dağıtık nesne altyapısı sağlar. Aralarındaki temel farklar şunlardır: 1. DCOM birden çok arayüzlü nesneleri destekler ve arayüzler arasında gezinmek için QueryInterface() yöntemini sağlar. Bu aynı zamanda, bir nesne proxy’sinin (stub) erişim katmanında birden çok proxy’i dinamik olarak yüklemesi fikrini ortaya çıkarır. CORBA’da bunun yerine çoklu miras alma özelliği vardır. 2. Her CORBA arayüzü, nesne kaydı, nesne referans oluşumu, iskelet örneklendirilmesi, gibi genel görevleri açık bir biçimde yerine getiren constructor olan CORBA::Object’ten miras alır. DCOM’da, bu gibi görevler ya sunucu programları tarafından üstü kapalı bir şekilde yerine getirilir, ya da DCOM çalışma zamanı sistemi tarafından dinamik olarak elde alınır. 3. DCOM’un tel protokolü RPC’ye sıkı bir şekilde bağlanmıştır. CORBA bu konuda serbesttir. 4. DCOM tanımlaması yürütme konusu olarak düşünülen ve CORBA tarafından belirlenmeyen bir çok detayı içerir. İki mimarideki birbirinin yerini tutan terimler, Temel Programlama Mimarisi, Erişim Mimarisi ve Tel Mimarisi katmanları için ayrı ayrı olarak, Tablo 5.1’de özetlenmiştir. 90 DCOM CORBA Üst katman: Temel Programlama Mimarisi Temel sınıf IUnknown CORBA::Object Nesne sınıf belirleyicisi CLSID arayüz ismi Arayüz belirleyicisi IID arayüz ismi İstemci tarafı nesne aktivasyonu CoCreateInstance() bir yöntem çağrısı/bind() arayüz işaretçisi Nesne idaresi nesne referansı Ara katman: EriĢim Mimarisi Yürütme eşlemesinin adı Registry Yürütme Ambarı Yöntemler için tip bilgisi Tip Kütüphanesi Arayüz Ambarı Yerleştirme yürütmesi SCM ORB Aktif etme yürütmesi SCM OA İstemci tarafındaki stub proxy stub/proxy Sunucu tarafındaki stub stub iskelet (skeleton) Alt katman: Tel Protokol Mimarisi Sunucu son nokta çözümleyicisi OXID çözümleyicisi ORB Sunucu son noktası nesne ihracatçısı OA Nesne Referansı OBJREF IOR (veya nesne referansı) Nesne Referans oluşumu nesne ihracatçısı OA Veri biçimini dönüştürme NDR CDR Arayüz örneği belirleyicisi IPID object_key Tablo 5.1 Birbirinin yerini tutan terimlerin ve varlıkların özeti 91 KAYNAKLAR Microsoft, “MSDN – Microsoft Developer Network”, (http://msdn.microsoft.com) Microsoft, 1998, “DCOM Architecture White Paper”, Microsoft Microsoft, 2001, “Technical Introduction To DCOM”, The Dalmatian Group, Inc., (http://www.dalmatian.com/com_dcom.htm) OMG, 2001, “The Common Object Request Broker: Architecture and Specification”, OMG, Editorial Revision: CORBA 2.4.2 (http://www.omg.org) RAJ, G. S., 1997, “A Detailed Comparison of CORBA, DCOM and Java/RMI”, (http://www.execpc.com/~gopalan/misc/compare.html) ROSENBERGER, J. L., 1998, “Teach Yourself CORBA In 14 Days”, SAMS Publishing ROY, M., EWALD, A., 1997, “Inside DCOM”, (http://www.dbmsmag.com/9704d13.html) VINOSKI, S., 1997, “CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments”, IEEE Communications Magazine, VINOSKI, S., 1993, “Distributed Object Computing With CORBA”, C++ Report Magazine 92 ÖZGEÇMĠġ 1976’da Bulgaristan’ın Varna şehrinde dünyaya gelen Altan Mesut, 1978’de Türkiye’ye gelip İstanbul’a yerleşti. İlk öğrenimine İstanbul’da başlayıp, Edirne’de tamamladı. Orta öğrenimini Edirne Anadolu Lisesi’nde 1994’te bitirdi. Aynı yıl İstanbul Üniversitesi Bilgisayar Bilimleri Mühendisliği Bölümü’nü kazandı ve 1998’de bu bölümden mezun oldu. Bir yazılım firmasında kısa süre çalıştıktan sonra, 1998 yılının Kasım ayında Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü’nde araştırma görevlisi olarak göreve başladı. 1999 yılında bu bölümde yüksek lisans eğitimine başladı ve 2002 yılında yüksek lisansını tamamladı. 2005 yılında Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü’ne öğretim görevlisi olarak atandı ve halen bu görevini sürdürmektedir. 93 EKLER EK-1 TERĠMLER Terim Anlamı Arayüz Bir fonksiyonellik gösteren belirli soyut işlerin (veya yöntemlerin) ismi olan bir kolleksiyonu. Bileşen Dağıtık bir ağda bir uygulama oluşturmak için, aynı bilgisayarda yada farklı bilgisayarlarda bulunan diğer bileşenlerle birleştirilebilecek yapı bloğu. Hareket Veritabanı bütünlüğünü sağlamak için bir birim gibi davranan ilgili işin (veritabanı güncelleme gibi) ve bilgi takasının bir serisi. İstemci Bir nesnenin bir yöntemini çağıran bir işlem. Miras Alma Bir alt sınıfın, türetildiği genel sınıf yada sınıfların tanımlamalarını, tekrar tanımlamaya ihtiyaç duymadan kullanabilmesi. Nesne (Nesne Örneği) Bazı nesne sınıflarının örneklendirilmesi. Her nesne belirli bir sınıfın yada alt sınıfın bir örneğidir. Sınıf (Nesne Sınıfı) Bir yada daha çok ismi olan somut bir yürütmesi. Stub Büyük bir programın yerine geçebilen ufak bir program rutini. RPC’de stub, uzak prosedür ile isteği yapan program arasındaki iletişimi idare eder. Sunucu (Nesne Sunucusu) Nesne örneklerini yaratma ve ev sahipliği yapmadan sorumlu işlem. Thread Belirli bir servis isteğine veya bir kullanıcıya hizmet etmek için gerekli olan bilgi. 94 EK-2 KISALTMALAR Kısaltma Açılımı Türkçesi ACF Application Configuration File Uygulama Konfigürasyon Dosyası ACL Access Control Lists Erişim Kontrol Listeleri ASP Active Server Pages Aktif Sunucu Sayfaları CILabs Component Integration Laboratories Bileşen Entegrasyon Laboratuarları CLSID Class Identifier Sınıf Belirleyicisi COM Component Object Model Bileşen Nesne Modeli CORBA Common Object Request Broker Architecture Genel Nesne İstek Aracı Mimarisi CWM Common Warehouse Meta-model Genel Depo Meta-modeli DCE Distributed Computing Environment Dağıtık Hesaplama Ortamı DCOM Distributed Component Object Model Dağıtık Bileşen Nesne Modeli DII Dynamic Invocation Interface Dinamik Çağrı Arayüzü DSI Dynamic Skeleton Interface Dinamik İskelet Arayüzü EJB Enterprise JavaBeans Kurumsal JavaBeans IDL Interface Definition Language Arayüz Tanımlama Dili IIOP Internet Inter-ORB Protocol Internet ORB’lar arası Protokol IID Interface Identifier Arayüz Belirleyicisi IIS Internet Information Server Internet Bilgi Sunucusu J2EE Java 2 Platform Enterprise Edition Java 2 Platformu Kurumsal Baskısı J2SE Java 2 Platform Standard Edition Java 2 Platformu Standart Baskısı LPC Local Procedure Call Yerel Prosedür Çağrısı MDA Model Driven Architecture Model Güdümlü Mimari MIDL Microsoft Interface Definition Language Microsoft Arayüz Tanımlama Dili MOF Meta-Object Facility Meta-Nesne Vasıtası MTS Microsoft Transaction Server Microsoft Hareket Sunucusu NDR Network Data Representation Ağ Veri Gösterimi OMA Object Management Architecture Nesne Yönetim Mimarisi OMG Object Management Group Nesne Yönetim Grubu ORB Object Request Broker Nesne İstek Aracı OSF Open Software Foundation Açık Yazılım Kuruluşu PDC Professional Developers Conference Profesyonel Geliştiriciler Konferansı POA Portable Object Adapter Taşınabilir Nesne Adaptörü RMI Remote Method Invocation Uzak Yöntem Çağrımı ROT Running Object Table Çalışan Nesne Tablosu RPC Remote Procedure Call Uzak Prosedür Çağrısı SCM Service Control Manager Servis Kontrol Yöneticisi SOM System Object Model Sistem Nesne Modeli TIP Transaction Internet Protocol Hareket Internet Protokolü UML Unified Modeling Language Birleştirilmiş Modelleme Dili XMI XML Metadata Interchanger XML Meta-veri Takasçısı XML Extensible Markup Language Uzatılabilir Biçimlendirme Dili 95 EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ 1989 OMG kuruldu ve CORBA üzerinde çalışmalara başlandı. 1990 OMG, OMA'yı ve CORBA'yı olşturan temel parçaları tanımladı. 1992 DEC, HP, Hyperdesk, NCR, ODI, ve SunSoft'un katkılarıyla oluşturulan CORBA 1.1 tamamlandı. IBM OS/2 2.0 tamamlandı. SOM adında CORBA 1.1 ile uyumlu olan bir nesne modeli de içeriyordu. Apple, IBM ve Lotus OpenDoc'u geliştirmeye başladılar. 1993 Microsoft COM'un ilk sürümünü tamamladı. OpenDoc CILabs tarafından lisaslandı. CILabs'ın ilk destekçileri Apple, IBM, Novell, Oracle, SunSoft, Taligent, WordPerfect, ve Xerox oldu. IONA (kuruluşunda Trinity College'ın bir parçasıydı) ORBIX ürününü piyasaya sürdü. 1994 IIOP sayesinde farklı üreticilerin ORB'lerinin birlikte çalışabilmesini sağlayan CORBA 2.0 tamamlandı. OMG öncülüğünde geliştirilen UML ilk şeklini aldı. 1995 COM tabanı üzerinde kurulu olan OLE'nin desteklendiği Windows 95 işletim sistemi piyasaya sürüldü. OLE/COM tabanı üzerine kurulan, başlarda adı Network OLE olan mimarinin adının DCOM olacağı açıklandı. SOMobjects IBM tarafından duyruldu. 1996 İlk JavaOne konferansında, JavaBeans tabanlı bileşenler duyruldu. Mart ayındaki Internet PDC'de Microsoft, ActiveX'i duyurdu ActiveX ile sıkı bir bağı bulunan DCOM'un özellikleri yayınlandı. 1997 Sun, JavaBeans Development Kit'i piyasaya sürdü. Sun, RMI'ı içeren JDK 1.1'i piyasaya sürdü. Sun, Enterprise JavaBeans (EJB) teknolojisini tanıttı. Web uygulamaları için COM bileşenleri ile entegrasyon sağlayan ASP, IIS 3.0 ile birlikte piyasaya sürüldü 1998 IIS 4.0, ASP 2.0 ve MTS 2.0 ile birlikte piyasaya sürüldü. Visual Studio 6.0 ile birlikte COM+ ortaya çıktı. 1999 Sun J2EE'yi piyasaya sürdü. Java 2 platformu ile RMI ile IIOP entegre edildi, Java IDL, Java ORB ve CORBA desteği sağlandı. 2000 Microsoft, IIS 5.0 ve ASP 3.0'ı içeren Windows 2000'i piyasaya sürdü. Windows 2000 COM+ desteği de sağlıyordu. IBM'in Web services, HP'nin e-speak, Sun'ın ONE, ve Microsoft'un .NET Web servislerini duyurması. IBM, Java servlets, JavaServer Pages, XML, EJB bileşenleri, ve CORBA desteği sağlayan WebSphere'i piyasaya sürdü. CORBA 2.4 özellikleri yayınlandı. 2001 CORBA 3.0 ve MDA çalışmalarına başlandı.