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

Transkript

1 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

2 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ġ

3 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.

4 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.

5 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.

6 ĠÇĠNDEKĠLER 1. GĠRĠġ BaĢlangıç: Monolitik Sistemler ve Mainframeler Devrim: Ġstemci/Sunucu Mimarisi Evrim: Çok Parçalı Ġstemci/Sunucu Yeni Nesil: Dağıtık Sistemler Soket Programlama RPC - Remote Procedure Call DCE Distributed Computing Environment CORBA Common Object Request Broker Architecture DCOM Microsoft Distributed Component Object Model RMI Java Remote Method Invocation CORBA OMA Object Management Architecture ORB CORBA Servisleri (CORBA Services) Dikey & Yatay CORBA Vasıtaları (Horizontal & Vertical CORBA Facilities) Uygulama Nesneleri (Application Objects) Bir ORB nin (Object Request Broker) Yapısı Object Request Broker (ORB) İstemciler Nesne Yürütmeleri Nesne Referansları OMG Arayüz Tanımlama Dili (IDL Interface Definition Language) Programlama Dilleri ile OMG IDL nin Eşlenmesi İstemci Stub ları Dinamik Çağrı Arayüzü (DII Dynamic Invocation Interface) Yürütme İskeleti Dinamik İskelet Arayüzü (DSI Dynamic Skeleton Interface) Nesne Adaptörleri ORB Arayüzü Arayüz Ambarı... 19

7 Yürütme Ambarı Örnek ORB ler İstemci- ve Yürütme-Yerleşik ORB Sunucu-tabanlı ORB Sistem-tabanlı ORB Kütüphane-tabanlı ORB Bir Ġstemcinin Yapısı Bir Nesne Yürütmesinin Yapısı Bir Nesne Adaptörünün Yapısı CORBA ya Ġhtiyaç Duyan Nesne Adaptörü Taşınabilir Nesne Adaptörü (POA Portable Object Adapter) Yabancı Nesne Sistemlerinin Entegrasyonu Arayüz Tanımlama Dili (IDL) Gömülü Tipler (Built-in Types) Yapısal Tipler (Constructed Types) Şablon Tipler (Template Types) Nesne Referans Tipleri (Object Reference Types) Arayüz Miras Alma (Interface Inheritence) Dil EĢlemeleri Arayüz Ambarı CORBA nın Bugünü ve Yarını MDA Model Driven Architecture UML Unified Modeling Language MOF Meta-Object Facility CWM Common Warehouse Meta-model CORBA Java ve Internet Entegrasyonu Servis Kalitesi Kontrolü CORBAcomponents Mimarisi CORBA Yürütmeleri DCOM COM Component Object Model Arayüzler... 38

8 Sınıflar ve Sunucular Nesne Yaşam Döngüsü İkili Birlikte Çalışabilirlik (Binary Interoperability) Paketleme Şeffaflığı DCOM Distributed Component Object Model Yer ve Paketleme Şeffaflığı Serbest Threading Modeli Güvenlik Referans Sayımı ve Ping Gönderme Yönetim MIDL Microsoft Interface Definition Language Tip Kütüphanesi Bir Arayüzün Karakteristik Özellikleri MIDL Derleyicisi Tip Tanımları, Yapı Bildirimleri, ve Import Bildirilebilen Yapılar Sabit Bildirimi (Constant Declaration) Genel Bildirim (General Declaration) Fonksiyon Bildirimi (Function Declaration) Örnekler IDL Nitelikleri (IDL Attributes) Dönüştürme ve Örtüşme Nitelikleri Asenkron Nitelikler Dizi ve Boyutlu-İşaretçi Nitelikleri Veri Tipi Nitelikleri Yönlendirici Nitelikler Fonksiyon Çağrım Nitelikleri Arayüz Başlık Nitelikleri Performans Nitelikleri İşaretçi Tipi Nitelikleri Struct ve Union Nitelikleri Tip Kütüphanesi Nitelikleri MIDL Veri Tipleri Ön-tanımlı ve Temel Tipler... 61

9 İşaretli ve İşaretsiz Tipler Diğer MIDL Veri Tipleri MIDL Dizileri İşaretçilerin Dizileri Yapılar (Structures) ve Birleşimler (Unions) Korunmuş Birleşimler (Encapsulated Unions) Korunmamış Birleşimler (Nonencapsulated Unions) Bağlı İşleyiciler (Binding Handles) DCOM un Bugünü ve Yarını COM NET CORBA - DCOM KARġILAġTIRMASI Örnek Uygulama Üst Katman: Temel Programlama Mimarisi Ara Katman: EriĢim Mimarisi Alt Katman: Tel Protokol Mimarisi SONUÇLAR KAYNAKLAR ÖZGEÇMĠġ EKLER EK-1 TERĠMLER EK-2 KISALTMALAR EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ... 95

10 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 BaĢlangıç: Monolitik Sistemler ve Mainframeler Mainframe ler bilgisayarlar arası haberleşmenin tarihinde başlangıç noktasını teşkil etmektedirler. Mainframe ler ile birlikte hiyerarşik veritabani sistemleri ve yeşil ekranlar olarak ta bilinen aptal terminaller kullanılmaya başlanmıştır. Bir mainframe sistemi, bakımının yapılması oldukça zahmetli olmasına rağmen, bir çok kullanıcıya hizmet verebilme ve tek bir noktadan yönetilebilme (ki bunun avantaj mı dezavantaj mı olduğu kişinin bakış açısına göre değişebilir) gibi özelliklere sahiptir. Mainframe ler için geliştirilen yazılımlar genellikle monolitik yazılımlardır. Bunun anlamı; kullanıcı arayüzü, iş kuralları ve veri erişimi fonksiyonelliği, oldukça büyük tek bir uygulamanın içinde bulunur. Aptal terminaller kendileri işlem yapmayıp mainframe leri kullandıkları için, uygulamanın tamamı mainframe de çalışır. Monolitik mimariyi gerekli kılan şey de budur. Tipik bir monolitik uygulama mimarisi ġekil 1.1. de gösterilmiştir. Mainframe Uygulama İş Kuralları Veritabanı Kullanıcı Arayüzü Terminal Terminal Terminal ġekil 1.1. Monolitik Uygulama Mimarisi

11 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.

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

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

14 5 çok daha fazla esnektir. Özel bileşen arayüzlerinin (interface 1 ) tanımını teşvik ederek (veya mecbur ederek), bu esnekliği kazanır. Bir bileşenin arayüzü, diğer bileşenlere, o bileşen tarafından sunulan servisleri ve bu servislerin nasıl kullanılacağı bilgisini sunar. Buna göre bir bileşenin arayüzü değişmediği sürece, bileşenin yürütmesi diğer bileşenleri etkilemeden değişebilir. Örneğin, bir firma için müşteri bilgisi sağlayan bir bileşen bu bilgiyi ilişkisel bir veritabanında tutabilir. Daha sonra, uygulama tasarımcıları bir nesne tabanlı veritabanının daha uygun olacağına karar verebilirler. Tasarımcılar, bileşenin arayüzüne dokunmadıkları sürece, bileşenin yürütmesinde istedikleri değişiklikleri yapabilirler. Dağıtık sistemler, istemci ve sunucu sayısı çok fazla olan, çok parçalı istemci/sunucu sistemi olarak kabul edilebilir. Aralarındaki en önemli fark, dağıtık sistemlerin, uygulamanın çeşitli bileşenlerine başka servislerin erişebilmesine izin veren dizin servisleri (directory services 2 ) gibi, bir takım ek servisler sağlamasıdır. Bu başka servisler, işlerin beraberce çalışmalarına izin veren bir hareket monitörü (transaction monitor 3 ) servisi ihtiva edebilirler. Dağıtık uygulamaları tasarlayıp yürütürken, tasarımcıya değişik uygulama geliştirme ortamları sunulur. Bu seçenekler uygulamanın geliştirildiği ortamdan, yürütme için kullanılan dilinin seçimine kadar farklılıklar gösterebilir. Şimdi bu farklı ortamları kısaca inceleyelim: 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.

15 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 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 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 CORBA Common Object Request Broker Architecture OMG (Object Management Group 1 - Nesne Yönetim Grubu) tarafından geliştirilen CORBA, bileşenler arasındaki arayüzleri tanımlamak için standart bir mekanizmaya sahiptir, 1 OSF den farklı olarak, OMG gerçek yazılım üretmez, sadece ayrıntılı tanımlar üretir.

16 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 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 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.

17 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.

18 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 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 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

19 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 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 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 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.

20 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ı

21 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.

22 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

23 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 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.

24 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 Ġ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 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ı)

25 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 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 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

26 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 Dil Eşlemeleri bölümüne bakınız Ġ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 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.

27 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 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 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ı,

28 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 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 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 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.

29 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 Ö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 Ġ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 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 Sistem-tabanlı ORB Güvenliği, kuvveti ve performansı arttırmak için, ORB, altında olan işletim sisteminin bir temel servisi olarak sağlanabilir. Nesne referansları, her istekteki kimlik sorgulama masrafını azaltarak, kalıcı yapılabilir. İşletim sisteminin istemcilerin ve yürütmelerin yerini ve yapısını bilebilmesi sayesinde, çok çeşitli iyileştirmelerin yerine getirilmesi mümkündür, örneğin, ikiside aynı makinedeyse dönüştürme (marshaling 1 ) işleminden sakınır. 1 ORB nin görevlerinden biri, method u çağıran bileşenden giriş parametrelerini almak, ve bunları ağ üzerinden aktarılabilecek bir biçime dönüştürmektir. Bu işleme dönüştürme (marshaling) denir. ORB, ağ üzerinden gelen dönüş parametrelerini de, çağıran bileşenin anlayabileceği biçime geri dönüştürür. Bu işleme de geri dönüştürme (unmarshaling) denir.

30 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 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.

31 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.

32 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 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.

33 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

34 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 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 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

35 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 Yabancı Nesne Sistemlerinin Entegrasyonunda Farklı Yöntemler

36 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.

37 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 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 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 ġ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.

38 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 $ gösterebilecek şekilde, parasal değerler için kullanılabilir 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 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 { // Yukardaki OMG IDL örneği ile aynı }; Object yarat();

39 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.

40 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 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 C++ EĢleme Tipi long, short long, short float, double float, double enum enum char char boolean bool octet unsigned char any Any sınıf struct struct union sınıf string char* wstring wchar_* sequence sınıf fixed Fixed şablon sınıfı nesne refereransı işaretçi veya nesne arayüz sınıf Tablo 2.1. OMG IDL Tipleri İçin Eşlemeler

41 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 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

42 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 CORBA nın Bugünü ve Yarını 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

43 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 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 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 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 CORBA de duyrulan ve 2002 de tanımlamalarının yayınlanması beklenen CORBA 3 ile getirilmesi düşünülen yenilikleri üç temel kategoride ele alabiliriz Java ve Internet Entegrasyonu 1. CORBA 2.3 ten beri varolan nesnelerin değer olarak geçirilebilmesi özelliği geliştirilecek.

44 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 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 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.

45 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++ AdaBroker the Computer Science department of the École Nationale Ücretsiz Supérieure des Télécommunications in Paris, France. Tablo 2.2. CORBA Yürütmeleri Ada İş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 & JDK 1.3 Solaris 2.6 (SunOS 5.6) Sun C (Forte 6.1) & JDK 1.3 Solaris 2.6 GCC Solaris 2.8 (SunOS 5.8) 32 & 64 bit Sun C (Forte 6.1) & JDK 1.3 HP-UX & 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 Visual Age 5.0 & JDK 1.3 Compaq Tru Compaq C & JDK 1.3 Tablo 2.3. ORBIX in Desteklediği Platformlar ve Derleyiciler

46 37 İşletim Sistemi Derleyici Solaris 2.6/7/8 Forte C++ 6 Update 2 Solaris 2.6/7/8 GCC HP-UX 11 HP ANSI C++ A Windows NT/2000 Visual C Linux GCC Compaq Tru C (024) AIX 4.3.x VA C with 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 Tru 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

47 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 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 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

48 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 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.

49 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 Stub COM Yerel Nesne İstemci Uygulama Yerel Nesne Proxy COM Uzak Nesne Proxy Uzak Makine Uzak Sunucu İşlemi Stub COM Yerel Nesne ġ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

50 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 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 *6. İstekleri direkt olarak çağır Sunucu Nesne 1. Bir nesne yarat COM 2. Sunucuyu Bul 3. DLL i yükle veya EXE yi çalıştır 4. Sınıf Fabrikasını elde et 5. 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.

51 42 Arayüzler IUnknown QueryInterface() AddRef() Release() Yürütmeler Motor Sınıfı Iunknown Yürütmesi Sınıflar Mirasların Alınması IMotor Baslat() Durdur() Ayarla() BenzinEkle() TipiniAl() HızıDegistir() IMotor IUnknown IMotor Yürütmesi motor_1 Motor Fabrikası Yaratımlar IMotor IUnknown Nesneler motor_2 ġ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 Ġ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

52 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 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 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.

53 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 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).

54 45 İstemci Nense (Bileşen) ġekil 3.4. Aynı işlemdeki COM bileşenleri İstemci Proxy Nesne Stub Nense (Bileşen) Güvenlik Sağlayıcı DCE RPC Güvenlik Sağlayıcı DCE RPC LPC LPC ġekil 3.5. Farklı işlemlerdeki COM bileşenleri İstemci Proxy Nesne Stub Bileşen Güvenlik Sağlayıcı DCE RPC Güvenlik Sağlayıcı DCE RPC Protokol Yığını Protokol Yığını DCOM Ağ Protokolü ġekil 3.6. Farklı makinelerdeki COM bileşenleri (DCOM) İstemci Proxy Nesne Stub Bileşen CoCreateInstance Güvenlik Sağlayıcı DCE RPC Güvenlik Sağlayıcı DCE RPC OLE32 Protokol Yığını Protokol Yığını CoCreateInstance (Remote) Activation SCM DCOM Ağ Protokolü SCM ġekil 3.7. DCOM Mimarisi

55 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 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 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

56 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 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.

57 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 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 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ğı

58 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 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 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 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:

59 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 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. /osf 1 anahtarını kullandığınızda, çoklu arayüzleri kullanamayacağınızı unutmayın 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.

60 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 Sabit Bildirimi (Constant Declaration) Sabit bildirimi Boolean, integer, character, wide-character, string, ve void * sabitlerini belirler 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 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 Örnekler [ uuid( abc), 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 word, // aranan kelime [out] short * ispresent // yoksa 0 );

61 IDL Nitelikleri (IDL Attributes) 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 iid_is transmit_as wire_marshal Uzağa gönderilemeyen bir fonksiyonu bir uzak prosedür çağrısı ile eşler. İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar. Bir veri tipini ağ üzerinden aktarılabilmesi için daha basit bir tipe çevirir. 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 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.

62 53 Nitelik Kullanımı async async_uuid maybe message 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. Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL derleyicisini yönlendirir. 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. 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 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 max_is length_is first_is last_is string range 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. Bir dizi indisi için maksimum değeri belirler. Aktarılacak dizi elemanlarının sayısını belirler. Aktarılacak ilk dizi elemanının indisini belirler. Aktarılacak son dizi elemanının indisini belirler. 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. Ç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).

63 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.

64 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 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 handle ms_union pipe transmit_as v1_enum wire_marshal 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. Uygulamaya özgü, özel bir işleyici (handle) tipi belirler. 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. 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. Özel dönüştürmede kullanılan bir veri tipinin ağ üzerinden nasıl aktarılacağını belirler. Belirlenen sayı tipinin 16-bit varsayılan değerle değil de, 32-bit olarak aktarılacağını belirler. 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

65 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 out Çağırandan çağrılan fonksiyona aktarılacak olan parametre Çağrılan fonksiyondan çağırana aktarılacak olan parametre Tablo 3.5. Yönlendirici Nitelikler 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 maybe broadcast idempotent callback call_as local 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. 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. 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. Çağrı durum değiştirmez, ve aynı giriş parametreleri ile her çağrıldığında aynı bilgiyi geri döndürür. Sunucunun istemciden bilgi almak için çağırabileceği istemci uygulamada bulunan bir fonksiyonu tatbik eder. Bir uzak prosedür çağrısı ile uzaklaştırılamayacak bir fonksiyonu eşler. 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.

66 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 uuid local ms_union object version pointer_default endpoint Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL derleyicisini yönlendirir. 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. 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. 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. 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. 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. 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. 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 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 local Wire_marshal 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. Bir fonksiyonun, uygulama için lokal olduğunu, ve MIDL ın stub kodunu üretmesine gerek olmadığını gösterir. 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

67 İşaretçi Tipi Nitelikleri kullanılırlar. Tablo 3.9 daki nitelikler, işaretçilerin karakteristik özelliklerini belirlemek için Nitelik Kullanımı ptr ref unique pointer_default iid_is string 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. Bazı verilerin adreslerini sağlayan, MIDL daki en basit işaretçi tipini belirtir. Referans işaretçiler hiçbir zaman boş (NULL) olamazlar. İşaretçinin boş (NULL) olmasına izin verir, ama örtüşmeyi desteklemez. 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. İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar. İşaretçinin bir karakter katarını gösterdiğini belirtir. Tablo 3.9. İşaretçi Tipi Nitelikleri 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 switch_is switch_type ignore Korunmuş (encapsulated) bir birleşim (union) için ayırtacı (discriminant) belirler. Korunmamış (nonencapsulated) bir birleşim için ayırtacı belirler. Korunmamış bir birleşim için ayırtacın tipini belirler. 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 Struct ve Union Nitelikleri struct ve union üyelerinin karakteristik özelliklerini belirlemek için Dizi ve Boyutlu-İşaretçi Niteliklerini de (bakınız ) kullanabilirsiniz.

68 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 aggregatable appobject bindable coclass control custom default defaultbind defaultcollelem defaultvalue defaultvtable dispinterface displaybind dllname(str) dual entry helpcontext helpfile helpstring helpstringdll hidden id immediatebind Kullanımı coclass ı, başka bir nesnenin arayüz işaretçisini direkt olarak gösterebilen destekleyen nesneler olarak belirler. coclass ı, bir tam EXE uygulaması ile ilişkilendirilmiş bir uygulama nesnesi olarak belirler. Ö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. Bir bileşen nesnesi için desteklenen arayüzlerin bir listesini sağlar. 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. MIDL da tanımlı olmayan özel bir nitelik tanımlar. Coclass içinde tanımlanan arayüzün varsayılan arayüzü temsil ettiğini gösterir. Nesneyi en iyi şekilde gösterecek bağlanabilir tekil özelliği gösterir. 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. Seçimlik bir parametre için varsayılan bir değerin belirlenmesine izin verir. Bir nesnenin iki farklı kaynak arayüzü olmasına izin verir. IDispatch::Invoke u çağırabileceğiniz özellikler ve yöntemlerin bir kümesini tanımlar. Kullanıcıya bağlanabilir olarak gösterilmesi gereken bir özellik gösterir. Bir modül için giriş noktalarını içeren DLL dosyasının ismini belirler. IDispatch ve Vtable üzerinden özellikleri ve yöntemleri teşhir edilecek arayüzü tanımlar. DLL de giriş noktasını belirleyerek ihraç edilmiş fonksiyon veya sabiti bir modülde belirler. Kullanıcının Yardım dosyasında bu üye ile ilgili bilgi bulabileceği bir içerik belirleyicisi tanımlar. Bir tip kütüphanesi için yardım dosyasının ismini belirler. Uygulandığı üyeyi tanımlamak için kullanılan bir karakter katarını belirler. Doküman karakter taraması yapmak için kullanılacak DLL in ismini belirler. Maddenin varolduğunu ama kullanıcıya gösterilmemesi gerektiğini ifade eder. Bir üye fonksiyon (arayüzdeki bir özellik veya bir yöntem) için bir DISPID belirler. Bir veri-bağı (data-bound) nesnesinin bir özelliğindeki tüm değişikliklerden veritabanının hemen haberdar edileceğini gösterir.

69 60 lcid library licensed nonbrowsable noncreatable nonextensible oleautomation optional propget propput propputref public readonly requestedit restricted retval source string uidefault usesgetlasterror uuid vararg version 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. İ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. Uygulandığı coclass ın lisanslı olduğunu gösterir, ve örnekler IClassFactory2 kullanarak oluşturulmalıdırlar. Ö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. İstemcinin, bir nesne arayüzünün örneklerini oluşturmak için varsayılan sınıf fabrikasını kullanmasını engeller. 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. Bir arayüzün otomasyon ile uyumlu olduğunu gösterir. Bir üye fonksiyonu için seçimlik bir parametre belirler. Bir özellik erişici fonksiyon belirler. Bir özellik yerleştirici fonksiyon belirler. Bir değer yerine bir referans kullanan bir özellik yerleştirici fonksiyon belirler. Typedef ile bildirilen bir alias ın, tip kütüphanesinin bir parçası haline gelmesini sağlar. Bir değişkene yeni bir değerin atanmasını engeller. Özelliğin OnRequestEdit bildirimini desteklediğini gösterir. Bir modülün veya bir arayüzün bir kütüphanesinin veya bir üyesinin keyfi olarak çağrılamayacağını belirler. Üyenin dönüş değerini alan parametreyi belirtir. Bir özellik, yöntem veya coclass ın bir üyesinin olayların kaynağı olduğunu gösterir. 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. Tip bilgi üyesinin, kullanıcı arayüzünde görünüm için varsayılan üye olduğunu gösterir. 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. Bir tip kütüphanesi, coclass, veya arayüz için tekil bir belirleyici belirtir. Fonksiyonun değişken sayıda argüman alabileceğini belirler. Bir tip kütüphanesinin belirli bir sürümünü belirtir. Tablo Tip Kütüphanesi Nitelikleri

70 MIDL Veri Tipleri Ö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 VARIANT_BOOL kullanılır. unsigned (işaretsiz) 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 gibi bir büyüklük sınırlayıcısı olmadan, uzak fonksiyonlarda yer alamaz. signed (işaretli) int32 32-bit tam sayı. long ile eşdeğer. int bit platformlarda 32-bit, ve 64-bit platformlarda 64-bit olan bir tam sayı. signed (işaretli) 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 Ön-tanımlı ve Temel Tipler

71 İş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 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 MIDL Dizileri alırlar: Dizi bildiricileri, IDL dosyasının arayüz gövdesinde aşağıdakilerden biri olarak yer 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.

72 63 /* IDL file interface body */ #define MAX_INDEX 10 typedef char ATYPE[MAX_INDEX]; typedef short BTYPE[]; // [*] ile aynı; typedef long CTYPE[*][10]; // [][10] ile aynı 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; İş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.

73 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 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: 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.

74 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; 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 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.

75 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 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

76 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 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 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.

77 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.

78 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

79 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() İstemci istemci stub ı tel protokolü yanıt Üst Katman Ara Katman Alt Katman Ağ ġekil 4.1. RPC Yapısı Sunucu sunucu stub ı tel protokolü 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 Nesne Temel Programlama Katmanı istemci stub ı (proxy) CORBA kütüphanesi ORB(ler) (orbixd) & Erişim Katmanı Yürütme Ambarı Sunucu Nesne İskeleti Nesne Adaptörü (CORBA kütüphanesi) ORB Tel Katmanı TCP Soketi ORB ġekil 4.2. CORBA Mimarisi

80 71 İstemci Sunucu Sınıf Fabrikası Temel Programlama Katmanı Nesne nesne proxy ara proxy COM Kütüphanesi SCM(ler) & Erişim Katmanı Registry ara stub nesne stub ı COM Kütüphanesi SCM Registry SCM Registry RPC Kanalı Tel Katmanı OXID çözümleyicisi OXID çözümleyicisi OXID nesnesi Nesne ihracatçısı istemci ping sunucu ping ġ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

81 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.

82 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.

83 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 { import "unknwn.idl"; HRESULT get([in] SHORT n, [in] SHORT m, [out] LONG *value); HRESULT set([in] SHORT n, [in] SHORT m, [in] LONG value); }; interface grid1 { long get(in short n, in short m); 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ı

84 75 DCOM sunucu sınıf tanımı (cgrid.h) CORBA sunucu sınıf tanımı (grid_i.h) #include "grid.h" // IDL tarafından oluşturulan arayüz // başlık dosyası #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 CORBA sunucu yürütmesi #include "cgrid.h" #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; } STDMETHODIMP CGrid::set(IN SHORT n, IN SHORT m, IN LONG value) { m_a[n][m] = value; return S_OK; } CORBA::Long grid_i::get(corba::short n, CORBA::Short m, CORBA::Environment &) { return m_a[n][m]; } void grid_i::set(corba::short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &) { m_a[n][m] = value; }

85 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; } 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; } 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; } 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" void main(int argc, char**argv) { IGrid1 *pigrid1; IGrid2 *pigrid2; LONG value; #include "grid.hh" 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ı

86 Ü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ı

87 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. 2. COM altyapısı olan CLSID_Grid için bir nesne sunucusu 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. Sunucu, kendisine artık ihtiyaç olmadığını bildiren bir sinyal gibi bir olayı bekliyor. Gelen istemci isteklerine başka thread ler hizmet edecekler. 1. İstemci, istemci stub ının statik bir fonksiyonu olan grid::_bind() ını çağırı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,tüm desteklenen nesneleri, örneklendirir. (Her constructor da, çağrılar bir nesne referansını yaratmak ve kaydetmek için yapılır.) 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.

88 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 İ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 Sınıf Fabrikası (3) Temel Programlama (6) Katmanı (1) (2) (4) Nesne (5) COM Kütüphanesi Erişim Katmanı 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.

89 80 İstemci Temel Programlama (4) Katmanı Nesne (1) ORB Sunucu istemci stub COM Kütüphanesi Erişim Katmanı (2) (3) Nesne Adaptörü [1] [2] 4.3. Ara Katman: EriĢim Mimarisi ġekil 4.5. Üst katmandaki CORBA adımları 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

90 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. 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. 3. Sunucu, desteklenen tüm sınıf fabrikalarını bir sınıf nesne tablosuna 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. grid::_bind() çağrısının gelmesi üzerine, istemci stub ı görevi ORB ye havale eder 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, 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. 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.

91 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 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. 9. COM kütüphanesi, arayüz proxy sine doğru olan bir IID_IGrid işaretçisini, istemciye pigrid1 olarak geri döndürür. 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. 6. İstemci stub ı nesne refernasını istemciye gridvar olarak geri döndürür. Yöntem Çağrımı 1. pigrid1->get() çağrısının gelmesi üzerine, arayüz proxy si gerekli parametreleri dönüştürür, ve isteği göndermek için RPC kanalı nesnesinde SendReceive() yöntemini başlatır. 2. RPC kanalı, isteği sunucu tarafına gönderir, hedef olan IID_IGrid1 arayüz stub ını bulur, ve Invoke() yöntemini onun üzerinde çağırır. 3. Arayüz stub ı parametreleri geri dönüştürür, bir yöntem numarası 1. gridvar->get() çağrısının gelmesi üzerine, proxy bir istek pseudo nesnesi yaratır, gerekli parametreleri burada dönüştürür, ve mesajı kanala koyması için CORBA::Request::send() i çağıran Request::invoke() u çağırır, ve CORBA::Request::get_response() ta cevap için bekler. 2. Mesaj sunucuya ulaştığında, BOA hedef olan iskeleti bulur, istenilen nesneyi yeniden oluşturur, ve iskelete gönderir. 3. İskelet parametreleri istenilen nesneden geri dönüştürür, bir 1 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.

92 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. 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. 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. 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. 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. 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 gelmesi üzerine, her zaman olduğu gibi IID_IGrid2 proxy si uzak çağrıyı yapar. 5. gridvar->reset() çağrısının gelmesi üzerine, proxy benzer bir prosedür takip eder. 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ı

93 84 İstemci (3) Temel Programlama Katmanı ara proxy [8] ara proxy nesne proxy COM Kütüphanesi [5] [9] (8) (7) (9) Sınıf Nesne Tablosu (4) (2) (1) SCM(ler) & (5) Erişim Katmanı Registry [1] [4] RPC Kanalı [6] Tel Katmanı [10] [7] [11] [2] Sunucu Sınıf Fabrikası Nesne nesne stub ı [3] (6) ara stub ara stub COM Kütüphanesi ġekil 4.6. Ara katmandaki DCOM adımları İstemci Nesne Temel Programlama Katmanı (6) istemci stub ı (proxy) CORBA kütüphanesi ORB(ler) (orbixd) & Erişim (1) Katmanı Yürütme Ambarı (5) (2) (3) Tel İletişim Katmanı Kanalı [1] [2] [4] Sunucu (4) Nesne İskeleti Nesne Adaptörü [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

94 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.

95 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. 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. 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.

96 87 Yöntem Çağrımı 1. pigrid1->get() çağrısının gelmesi üzerine, arayüz proxy si Ağ Veri Gösterimi (NDR - Network Data Representation) biçimindeki parametreleri dönüştürür. 2. RPC kanalı, OXID-çözümlü RPC bağlantısı tarafından tanımlanmış hedef nesne ihracatçısına isteği gönderir. 3. Sunucu tarafı RPC altyapısı, RPC başlığında bulunan IPID ye dayandırılan hedef arayüz stub ını bulur. 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. 1. gridvar->get() çağrısının gelmesi üzerine, proxy Genel Veri Gösterimi (CDR Common Data Representation) biçimindeki parametreleri dönüştürür. 2. İstek, kurulan soket bağlantısı üzerinden hedef sunucuya gönderilir. 3. Hedef iskelet, referans belirleyicisi veya object_key olarak teşhis edilir. 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 nesnesi 1 ü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.

97 88 İstemci Sunucu Temel Programlama Katmanı nesne proxy (6) ara proxy [1] COM Kütüphanesi [6] Erişim Katmanı (4) SCM Registry (1) OBJREF (3) SCM Registry Tel RPC Katmanı Kanalı [2] [3] Sınıf Fabrikası [4] ara stub Nesne [5] (5) OXID OXID çözümleyicisi çözümleyicisi (2) nesne stub ı OXID nesnesi COM Kütüphanesi Nesne ihracatçısı OXID ġekil 4.8. Alt katmandaki DCOM adımları Nesne Temel Programlama Katmanı istemci stub ı (proxy) İstemci [1] CORBA kütüphanesi (3) Erişim Katmanı yerleştirici ORB (1) Tel Katmanı TCP Soketi Yürütme Ambarı ORB (2) IOR Sunucu Nesne İskeleti Nesne Adaptörü [2] [3] [4] ġekil 4.9. Alt katmandaki CORBA adımları

98 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.

99 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() Nesne idaresi arayüz işaretçisi 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

100 91 KAYNAKLAR Microsoft, MSDN Microsoft Developer Network, ( Microsoft, 1998, DCOM Architecture White Paper, Microsoft Microsoft, 2001, Technical Introduction To DCOM, The Dalmatian Group, Inc., ( OMG, 2001, The Common Object Request Broker: Architecture and Specification, OMG, Editorial Revision: CORBA ( RAJ, G. S., 1997, A Detailed Comparison of CORBA, DCOM and Java/RMI, ( ROSENBERGER, J. L., 1998, Teach Yourself CORBA In 14 Days, SAMS Publishing ROY, M., EWALD, A., 1997, Inside DCOM, ( 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

101 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ı yılında bu bölümde yüksek lisans eğitimine başladı ve 2002 yılında yüksek lisansını tamamladı 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.

102 93 EKLER EK-1 TERĠMLER Terim Arayüz Bileşen Hareket İstemci Miras Alma Nesne (Nesne Örneği) Sınıf (Nesne Sınıfı) Stub Sunucu (Nesne Sunucusu) Thread Anlamı Bir fonksiyonellik gösteren belirli soyut işlerin (veya yöntemlerin) ismi olan bir kolleksiyonu. 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. 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. Bir nesnenin bir yöntemini çağıran bir işlem. 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. 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. Bir yada daha çok ismi olan somut bir yürütmesi. 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. Nesne örneklerini yaratma ve ev sahipliği yapmadan sorumlu işlem. Belirli bir servis isteğine veya bir kullanıcıya hizmet etmek için gerekli olan bilgi.

103 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

104 95 EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ 1989 OMG kuruldu ve CORBA üzerinde çalışmalara başlandı OMG, OMA'yı ve CORBA'yı olşturan temel parçaları tanımladı 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 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ü 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ı 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 İ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ı 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ı 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ı 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ı CORBA 3.0 ve MDA çalışmalarına başlandı.