T.C. TRAKYA ÜNĠVERSĠTESĠ FEN BĠLĠMLERĠ...
104
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
Transcript of T.C. TRAKYA ÜNĠVERSĠTESĠ FEN BĠLĠMLERĠ...
T.C.
TRAKYA ÜNĠVERSĠTESĠ
FEN BĠLĠMLERĠ ENSTĠTÜSÜ
DAĞITIK NESNE YÖNETĠMĠ
MĠMARĠLERĠNĠN ĠNCELENMESĠ
Altan MESUT
Yüksek Lisans Tezi
Bilgisayar Mühendisliği Anabilim Dalı
DanıĢman: Yrd. Doç. Dr. Aydın CARUS
EDĠRNE-2002
T.C.
TRAKYA ÜNĠVERSĠTESĠ
FEN BĠLĠMLERĠ ENSTĠTÜSÜ
DAĞITIK NESNE YÖNETĠMĠ
MĠMARĠLERĠNĠN ĠNCELENMESĠ
Altan MESUT
YÜKSEK LĠSANS TEZĠ
BĠLGĠSAYAR MÜHENDĠSLĠĞĠ ANABĠLĠM DALI
Bu tez 10/01/2002 tarihinde aĢağıdaki jüri tarafından kabul edilmiĢtir.
Yrd. Doç. Dr. Aydın CARUS (DanıĢman)
Yrd. Doç. Dr. Erdem UÇAR Yrd. Doç. Dr. ġaban AKTAġ
i
ÖZET
Son on yılda çıkan nesneye yönelik programlama ve dağıtık sistem teknolojileri
modern yazılımları büyük ölçüde etkiledi. RPC (Remote Procedure Call – Uzak Prosedür
Çağrısı) gibi eski nesil istemci/sunucu mimarileri nesneye yönelik bir modele sahip
değildirler. Bu mimaride istemci, sunucuya nasıl ulaşması gerektiğini ve sunucunun yerini
bilmek, ve kodu eklenecek her yeni servis için değiştirilmek zorundadır. İstemci/sunucu
sistem teknolojisinin gelişiminin bir sonraki basamağı, dağıtık sistem ile nesneye yönelik
programlama teknolojilerinin birleşimi olan dağıtık nesne yönetimi sistemleridir. Dağıtık
sistemlerin gerçek faydası, ancak karmaşık uygulamaların yeniden kullanılabilir yazılım
bileşenleri kullanılarak meydana getirilmesine izin veren, dağıtık nesne yönetimi sistemlerinin
kullanılması ile mümkün olacaktır.
Bu çalışmanın amacı, değişik zamanlarda, farklı platformlar (işletim sistemleri &
donanımlar) ve farklı programlama dilleri ile, birbirinden bağımsız olarak tasarlanmış yazılım
bileşenlerinin, bir bütün olarak çalışabilmesi için kullanılan dağıtık nesne yönetimi
mimarilerinden CORBA (Common Object Request Broker Architecture – Genel Nesne İstek
Aracı Mimarisi) ve DCOM (Distributed Component Object Model – Dağıtık Bileşen Nesne
Modeli) mimarilerinin incelenmesi, aralarındaki benzerlikler ve farklılıkların belirlenmesidir.
Tezin giriş bölümünde, monolitik sistemlerden istemci/sunucu mimarilerine, ve daha
sonrasında dağıtık mimarilere kadar olan gelişim kısaca açıklanmıştır.
İkinci ve üçüncü bölümlerde, CORBA ve COM/DCOM mimarileri incelenmiş ve
dördüncü bölümde bu iki mimarinin yapısal olarak karşılaştırılması, temel programlama
mimarisi, erişim mimarisi ve tel mimarisi olmak üzere üç ayrı katmanda, iki boyutlu
tamsayılar üzerinde çalışan Grid adında bir uygulama kullanılarak gerçekleştirilmiştir.
Tezin son bölümünde karşılaştırmanın özeti yer almaktadır.
ii
ABSTRACT
The object-oriented programming and distributed computing techniques made
significant impact on modern software development over the past ten years. Older generation
client/server architectures, such as RPC (Remote Procedure Call), do not have an object-
oriented model. In these architectures, the client must be aware of where the server is located
and how to access the server, and its code must be modified to make use of new services that
become available. The next step in the evolution of the client/server architecture is the
distributed object management systems, which is the union of object-oriented programming
and distributed computing. The significant promise of this technology is that it enables
construction of complex applications from reusable software components.
The purpose of this thesis is to study CORBA (Common Object Request Broker
Architecture) and DCOM (Distributed Component Object Model) distributed object
management architectures, which provide interoperability of software components possibly
designed at different times, written in different programming languages and worked in
different platforms (hardware & operating systems).
The introductory first chapter includes a survey of the monolitic systems, the
client/server architecture and its evolution, and distributed systems.
The second and third chapters describe the CORBA and COM/DCOM architectures,
respectively.
The fourth chapter includes architectural comparison of DCOM and CORBA at three
different layers: basic programming architecture, remoting architecture, and the wire protocol
architecture, by using Grid, a program which performs computations on a two-dimensional
grid of integers.
The final chapter involves a summary of the thesis, and conclusions.
iii
TEġEKKÜR
Bu önemli konuda çalışmamı sağlayan, bana yol gösteren, destek ve yardımlarını
benden esirgemeyen danışman hocam Yrd. Doç. Dr. Aydın CARUS’a, konu hakkındaki
bilgisinden yararlandığım Dr. Bülent KÜÇÜK’e ve çalışabilmem için gerekli ortamın
yaratılmasını sağlayan ve tüm yoğun zamanlarımda anlayışlı davranan çalışma arkadaşlarıma
ve aileme teşekkürlerimi sunarım.
ĠÇĠNDEKĠLER
1. GĠRĠġ .............................................................................................................. 1
1.1. BaĢlangıç: Monolitik Sistemler ve Mainframeler ...................................................... 1
1.2. Devrim: Ġstemci/Sunucu Mimarisi .............................................................................. 2
1.3. Evrim: Çok Parçalı Ġstemci/Sunucu ........................................................................... 3
1.4. Yeni Nesil: Dağıtık Sistemler ....................................................................................... 4
1.4.1. Soket Programlama .................................................................................................. 5
1.4.2. RPC - Remote Procedure Call .................................................................................. 6
1.4.3. DCE – Distributed Computing Environment ........................................................... 6
1.4.4. CORBA – Common Object Request Broker Architecture ....................................... 6
1.4.5. DCOM – Microsoft Distributed Component Object Model ..................................... 7
1.4.6. RMI – Java Remote Method Invocation .................................................................. 7
2. CORBA ........................................................................................................... 8
2.1. OMA – Object Management Architecture ................................................................. 9
2.1.1. ORB .......................................................................................................................... 9
2.1.2. CORBA Servisleri (CORBA Services) .................................................................... 9
2.1.3. Dikey & Yatay CORBA Vasıtaları (Horizontal & Vertical CORBA Facilities) ... 10
2.1.4. Uygulama Nesneleri (Application Objects) ........................................................... 10
2.2. Bir ORB’nin (Object Request Broker) Yapısı ......................................................... 10
2.2.1. Object Request Broker (ORB) ................................................................................ 14
2.2.2. İstemciler ................................................................................................................ 15
2.2.3. Nesne Yürütmeleri .................................................................................................. 15
2.2.4. Nesne Referansları .................................................................................................. 16
2.2.5. OMG Arayüz Tanımlama Dili (IDL – Interface Definition Language) ................. 16
2.2.6. Programlama Dilleri ile OMG IDL’nin Eşlenmesi ................................................ 16
2.2.7. İstemci Stub’ları ..................................................................................................... 17
2.2.8. Dinamik Çağrı Arayüzü (DII – Dynamic Invocation Interface) ............................ 17
2.2.9. Yürütme İskeleti ..................................................................................................... 18
2.2.10. Dinamik İskelet Arayüzü (DSI – Dynamic Skeleton Interface) ............................. 18
2.2.11. Nesne Adaptörleri ................................................................................................... 18
2.2.12. ORB Arayüzü ......................................................................................................... 19
2.2.13. Arayüz Ambarı ....................................................................................................... 19
2.2.14. Yürütme Ambarı ..................................................................................................... 19
2.3. Örnek ORB’ler ........................................................................................................... 20
2.3.1. İstemci- ve Yürütme-Yerleşik ORB ....................................................................... 20
2.3.2. Sunucu-tabanlı ORB ............................................................................................... 20
2.3.3. Sistem-tabanlı ORB ................................................................................................ 20
2.3.4. Kütüphane-tabanlı ORB ......................................................................................... 21
2.4. Bir Ġstemcinin Yapısı .................................................................................................. 21
2.5. Bir Nesne Yürütmesinin Yapısı ................................................................................. 22
2.6. Bir Nesne Adaptörünün Yapısı ................................................................................. 23
2.7. CORBA’ya Ġhtiyaç Duyan Nesne Adaptörü ............................................................ 25
2.7.1. Taşınabilir Nesne Adaptörü (POA – Portable Object Adapter) ............................. 25
2.8. Yabancı Nesne Sistemlerinin Entegrasyonu ............................................................ 26
2.9. Arayüz Tanımlama Dili (IDL) ................................................................................... 27
2.9.1. Gömülü Tipler (Built-in Types) ............................................................................. 28
2.9.2. Yapısal Tipler (Constructed Types) ....................................................................... 28
2.9.3. Şablon Tipler (Template Types) ............................................................................. 28
2.9.4. Nesne Referans Tipleri (Object Reference Types) ................................................. 29
2.9.5. Arayüz Miras Alma (Interface Inheritence) ........................................................... 29
2.10. Dil EĢlemeleri .............................................................................................................. 31
2.11. Arayüz Ambarı ........................................................................................................... 32
2.12. CORBA’nın Bugünü ve Yarını ................................................................................. 33
2.12.1 MDA – Model Driven Architecture ....................................................................... 33
2.12.1.1 UML – Unified Modeling Language ................................................................ 34
2.12.1.2. MOF – Meta-Object Facility ........................................................................... 34
2.12.1.3 CWM – Common Warehouse Meta-model ....................................................... 34
2.12.2 CORBA 3 ............................................................................................................... 34
2.12.2.1 Java ve Internet Entegrasyonu ......................................................................... 34
2.12.2.2 Servis Kalitesi Kontrolü ................................................................................... 35
2.12.2.3 CORBAcomponents Mimarisi........................................................................... 35
5.12.3. CORBA Yürütmeleri .............................................................................................. 36
3. DCOM ........................................................................................................... 38
3.1. COM – Component Object Model ............................................................................ 38
3.1.1. Arayüzler ................................................................................................................ 38
3.1.2. Sınıflar ve Sunucular .............................................................................................. 39
3.1.3. Nesne Yaşam Döngüsü ........................................................................................... 41
3.1.4. İkili Birlikte Çalışabilirlik (Binary Interoperability) .............................................. 42
3.1.5. Paketleme Şeffaflığı ............................................................................................... 43
3.2. DCOM – Distributed Component Object Model .................................................... 43
3.2.1. Yer ve Paketleme Şeffaflığı .................................................................................... 44
3.2.2. Serbest Threading Modeli ...................................................................................... 46
3.2.3. Güvenlik ................................................................................................................. 46
3.2.4. Referans Sayımı ve Ping Gönderme ....................................................................... 47
3.2.5. Yönetim .................................................................................................................. 48
3.3. MIDL – Microsoft Interface Definition Language .................................................. 48
3.3.1. Tip Kütüphanesi ..................................................................................................... 49
3.3.2. Bir Arayüzün Karakteristik Özellikleri .................................................................. 49
3.3.3. MIDL Derleyicisi ................................................................................................... 49
3.3.4. Tip Tanımları, Yapı Bildirimleri, ve Import ....................................................... 50
3.3.4.1. Bildirilebilen Yapılar ........................................................................................ 50
3.3.4.2. Sabit Bildirimi (Constant Declaration) ............................................................ 51
3.3.4.3. Genel Bildirim (General Declaration) ............................................................. 51
3.3.4.4. Fonksiyon Bildirimi (Function Declaration) .................................................... 51
3.3.4.5. Örnekler ............................................................................................................ 51
3.3.5. IDL Nitelikleri (IDL Attributes) ............................................................................. 52
3.3.5.1. Dönüştürme ve Örtüşme Nitelikleri .................................................................. 52
3.3.5.2. Asenkron Nitelikler ........................................................................................... 52
3.3.5.3. Dizi ve Boyutlu-İşaretçi Nitelikleri ................................................................... 53
3.3.5.4. Veri Tipi Nitelikleri ........................................................................................... 55
3.3.5.5. Yönlendirici Nitelikler ...................................................................................... 56
3.3.5.6. Fonksiyon Çağrım Nitelikleri ........................................................................... 56
3.3.5.7. Arayüz Başlık Nitelikleri ................................................................................... 57
3.3.5.8. Performans Nitelikleri ...................................................................................... 57
3.3.5.9. İşaretçi Tipi Nitelikleri ..................................................................................... 58
3.3.5.10. Struct ve Union Nitelikleri ................................................................................ 58
3.3.5.11. Tip Kütüphanesi Nitelikleri .............................................................................. 59
3.3.6. MIDL Veri Tipleri .................................................................................................. 61
3.3.6.1. Ön-tanımlı ve Temel Tipler............................................................................... 61
3.3.6.2. İşaretli ve İşaretsiz Tipler ................................................................................. 62
3.3.6.3. Diğer MIDL Veri Tipleri .................................................................................. 62
3.3.7. MIDL Dizileri ......................................................................................................... 62
3.3.7.1. İşaretçilerin Dizileri ......................................................................................... 63
3.3.8. Yapılar (Structures) ve Birleşimler (Unions) ......................................................... 64
3.3.8.1. Korunmuş Birleşimler (Encapsulated Unions) ................................................ 64
3.3.8.2. Korunmamış Birleşimler (Nonencapsulated Unions) ...................................... 65
3.3.9. Bağlı İşleyiciler (Binding Handles) ........................................................................ 65
3.4. DCOM’un Bugünü ve Yarını .................................................................................... 66
3.4.1. COM+ ..................................................................................................................... 67
3.4.2. .NET ....................................................................................................................... 67
4. CORBA - DCOM KARġILAġTIRMASI .................................................. 69
4.1. Örnek Uygulama ........................................................................................................ 71
4.2. Üst Katman: Temel Programlama Mimarisi ........................................................... 77
4.3. Ara Katman: EriĢim Mimarisi .................................................................................. 80
4.4. Alt Katman: Tel Protokol Mimarisi ......................................................................... 84
5. SONUÇLAR ................................................................................................. 89
KAYNAKLAR ................................................................................................... 91
ÖZGEÇMĠġ ....................................................................................................... 92
EKLER ............................................................................................................... 93
EK-1 TERĠMLER ............................................................................................................... 93
EK-2 KISALTMALAR ....................................................................................................... 94
EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ ................................................ 95
1
1. GĠRĠġ
Bilgisayarlar arası haberleşmeye ihtiyaç duyulduğu andan itibaren, çözüm için çeşitli
yöntemler geliştirilmiştir. Dağıtık sistemler, günümüze kadar bu isimle değil de farklı
isimlerle anılmış olmalarına rağmen, bilgisayarlar arası haberleşmenin tarihinde daima
varolmuşlardır. Esas konumuz olan Dağıtık Nesne Yönetimi Mimarileri’ne girmeden önce
dağıtık sistemlerin günümüze kadar geçirdiği evrimleri incelemekte fayda vardır.
1.1. BaĢlangıç: Monolitik Sistemler ve Mainframeler
Mainframe’ler bilgisayarlar arası haberleşmenin tarihinde başlangıç noktasını teşkil
etmektedirler. Mainframe’ler ile birlikte hiyerarşik veritabani sistemleri ve yeşil ekranlar
olarak ta bilinen aptal terminaller kullanılmaya başlanmıştır. Bir mainframe sistemi,
bakımının yapılması oldukça zahmetli olmasına rağmen, bir çok kullanıcıya hizmet verebilme
ve tek bir noktadan yönetilebilme (ki bunun avantaj mı dezavantaj mı olduğu kişinin bakış
açısına göre değişebilir) gibi özelliklere sahiptir.
Mainframe’ler için geliştirilen yazılımlar genellikle monolitik yazılımlardır. Bunun
anlamı; kullanıcı arayüzü, iş kuralları ve veri erişimi fonksiyonelliği, oldukça büyük tek bir
uygulamanın içinde bulunur. Aptal terminaller kendileri işlem yapmayıp mainframe’leri
kullandıkları için, uygulamanın tamamı mainframe’de çalışır. Monolitik mimariyi gerekli
kılan şey de budur. Tipik bir monolitik uygulama mimarisi ġekil 1.1.’de gösterilmiştir.
ġekil 1.1. Monolitik Uygulama Mimarisi
Mainframe
Uygulama
Kullanıcı Arayüzü
İşKuralları
Veritabanı
Terminal Terminal Terminal
2
1.2. Devrim: Ġstemci/Sunucu Mimarisi
Monolitik mimaride tüm yükün mainframe’de olması kimilerine göre bir
dezavantajdır. PC’lerin yaygınlaşması ile kullanılmaya başlanan İstemci/Sunucu mimarisinde
ise yapılacak işlemlerin bir kısmının kullanıcı tarafındaki makinelerde yapılması sağlanarak
sunucu tarafındaki yük azaltılmıştır.
İstemci/Sunucu mimarisinin yayılması ile birlikte, UNIX tabanlı sunucuların da
kullanılmasına başlanmıştır. Bir çok uygulama yazılımı çalışabilmek için mainframe
sistemlerin sahip olduğu yüksek donanım gücüne ihtiyaç duymaz. Buna ek olarak
İstemci/Sunucu mimarisinde işlem yükünün bir kısmı istemci tarafında gerçekleştiğinden
dolayı, UNIX tabanlı sunucuların kullanılması, mainframe’lerin kullanılmasından daha ucuza
mal olacaktır. Bu da bütçesi sınırlı şirketler için ideal bir çalışma ortamı oluşturmaktadır.
İstemci/Sunucu mimarisinin başka bir avantajı da, bir şirket içinde farklı departmanların
kendilerine ait farklı sunucuları olmasına imkan tanımasıdır. Bu sayede belirli bir
departmanda çalışan bir işçi, kendi bölümüne özel bir bilgiye erişmek istiyorsa, mainframe
sistemlerde olduğu gibi büyük bir uygulama içinde istediğine ulaşmayı beklemek yerine,
kendi departmanındaki sunucuya erişerek ihtiyacı olan bilgiye daha kısa yoldan ulaşabilir.
Ayrıca, mainframe sistemlerdeki terminaller sadece mainframe üzerindeki uygulamaları
çalıştırabilirken, bir PC sunucusuna bağımlı değildir. Ondan bağımsız olarak kendisinde
yüklü olan değişik uygulamaları da çalıştırabilir.
İstemci/Sunucu mimarisi tipik olarak uygulamanın bileşenlerini ayırır. Buna göre
veritabanı sunucu tarafında, kullanıcı arayüzü istemci tarafında, iş kuralları da ya sunucu ya
da istemci tarafında yer almaktadır. Ancak istemci bileşeninin parçalarında değişiklik
olduğunda, istemci bileşeninin yeni kopyalarının (genellikle çalıştırılabilir dosyalar) diğer
kullanıcılara dağıtılması gerekir.
Çok parçalı İstemci/Sunucu mimarisinin kullanılmaya başlanması ile birlikte, orijinal
İstemci/Sunucu mimarisi artık iki parçalı istemci/sunucu (two-tier client/server) olarak
adlandırılmaya başlanmıştır. İki parçalı istemci/sunucu mimarisi ġekil 1.2’de gösterilmiştir.
3
ġ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.
Sunucu
Uygulama
İş Kuralları
İşKuralları
Veritabanı
İstemci İstemciKullanıcı Arayüzü
Başka Sunucular
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.
ġ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
Sunucu
Uygulama
Kullanıcı Arayüzü
İş Kuralları
Veritabanı
İstemci İstemci
Başka Sunucular
Kullanıcı Arayüzü
Kullanıcı Arayüzü
5
çok daha fazla esnektir. Özel bileşen arayüzlerinin (interface1) tanımını teşvik ederek (veya
mecbur ederek), bu esnekliği kazanır. Bir bileşenin arayüzü, diğer bileşenlere, o bileşen
tarafından sunulan servisleri ve bu servislerin nasıl kullanılacağı bilgisini sunar. Buna göre bir
bileşenin arayüzü değişmediği sürece, bileşenin yürütmesi diğer bileşenleri etkilemeden
değişebilir. Örneğin, bir firma için müşteri bilgisi sağlayan bir bileşen bu bilgiyi ilişkisel bir
veritabanında tutabilir. Daha sonra, uygulama tasarımcıları bir nesne tabanlı veritabanının
daha uygun olacağına karar verebilirler. Tasarımcılar, bileşenin arayüzüne dokunmadıkları
sürece, bileşenin yürütmesinde istedikleri değişiklikleri yapabilirler.
Dağıtık sistemler, istemci ve sunucu sayısı çok fazla olan, çok parçalı istemci/sunucu
sistemi olarak kabul edilebilir. Aralarındaki en önemli fark, dağıtık sistemlerin, uygulamanın
çeşitli bileşenlerine başka servislerin erişebilmesine izin veren dizin servisleri (directory
services2) gibi, bir takım ek servisler sağlamasıdır. Bu başka servisler, işlerin beraberce
çalışmalarına izin veren bir hareket monitörü (transaction monitor3) servisi ihtiva edebilirler.
Dağıtık uygulamaları tasarlayıp yürütürken, tasarımcıya değişik uygulama geliştirme
ortamları sunulur. Bu seçenekler uygulamanın geliştirildiği ortamdan, yürütme için kullanılan
dilinin seçimine kadar farklılıklar gösterebilir. Şimdi bu farklı ortamları kısaca inceleyelim:
1.4.1. Soket Programlama
Modern sistemlerin çoğunda, makineler arasındaki ve bazen aynı makinedeki işlemler
arasındaki iletişim, soketler kullanılarak yapılır. Bir soket uygulamaların kendi aralarında
bağlanabilmeleri ve haberleşebilmeleri için bir kanaldır. Uygulama bileşenleri arasında
haberleşmeyi sağlamak için en uygun yol soketleri direkt olarak kullanmaktır (bu soket
programlama olarak bilinir). Geliştirici veriyi sokete yazar ve/veya veriyi soketten okur.
1 Arayüz, bir sistemin iki farklı bileşeni arasındaki haberleşme protokolünü tanımlar. Bu bileşenler,
farklı işler, farklı nesneler, bir kullanıcı, bir uygulama,…vb sistemde birbirleriyle haberleşme ihtiyacı duyan
herhangi iki farklı varlık olabilir. Arayüz, bir bileşenin hangi servisleri sunduğunu, ve bu servisleri kullanmak
için gerekli protokolü tanımlar. Nesne tarafından bakıldığında, arayüz, o nesne tarafından tanımlanmış, giriş ve
çıkış parametreleri olan, yöntemler kümesi olarak düşünülebilir.
2 Dizin Servisini bir telefon defteri gibi düşünebiliriz. Nasıl telefon defterinde değişik isimler ve telefon
numaraları tutuluyorsa, bir dizin servisi de sistemdeki nesnelerin bilgilerini grup halinde tutar, ve ihtiyaç
duyulduğunda dizin servisinden bu bilgilere erişilir.
3 Hareket monitörü servisi, diğer nesneler adına işleri idare eder. Bir hareket (transaction), otomatik
olarak yapılması gereken bir iş veya iş kümesidir. Harekette olan tüm nesneler hareketi ya commit (kayıt
yenileme) etmeli, yada hareketi abort (hareketin oluşumundan önceki duruma dönme) etmelidirler. Hareket ister
commit edilsin ister abort edilsin, içerilen tüm nesneler tutarlı bir durumda olacaklardır. Diğer nesnelere hareket-
bağlantılı servislerin sağlanması iş yapma monitörünün görevidir.
6
Soket Programlama’da kullanılan Uygulama Programlama Arayüzü (API –
Application Programming Interface), oldukça düşük seviyelidir. Bu yüzden soket
programlama karmaşık uygulamalar için uygun değildir. Örneğin uygulama bileşenleri farklı
tipten makinelerde bulunuyorlarsa veya farklı programlama dillerinde yürütülmüşlerse,
karmaşık veri tiplerini elde etmek için soket programlama uygun değildir. Direkt soket
programlama çok ufak ve etkili uygulamalarda sonuç verebilir, ama genel kanı karmaşık
uygulama geliştirmesi için uygun olmadığıdır.
1.4.2. RPC - Remote Procedure Call
Soket programlamanın bir üst basamağı RPC’dir. RPC, soket seviyesindeki
iletişimlere fonksiyon-tabanlı bir arayüz sağlar. RPC kullanarak, verinin akarak bir soket
oluşturmasını direkt olarak sağlamak yerine, geliştirici, C gibi fonksiyonel dillerdekine benzer
şekilde bir fonksiyon tanımlayıp, bu fonksiyonun çağırana normal bir fonksiyon gibi
görünmesini sağlayan bir kod oluşturur. Fonksiyon, uzaktaki bir sunucuyla (remote server)
iletişim kurmak için, arka planda soketleri kullanır.
Fonksiyon-tabanlı bir arayüz sağladığı için, RPC’yi kullanmak çoğu kez ham soket
programlamayı kullanmaktan daha kolaydır. RPC aynı zamanda, birçok istemci/sunucu
uygulamaları için temel oluşturabilecek kadar güçlüdür. RPC protokolünün uyumsuz birçok
yürütmesi olmasına rağmen, birçok platforma uyumlu olan standart bir RPC protokolü vardır.
1.4.3. DCE – Distributed Computing Environment
OSF (Open Software Foundation – Açık Yazılım Kuruluşu) tarafından geliştirilmiş bir
yöntem olan DCE (Dağıtık Hesaplama Ortamı), daha çok dağıtık ortamlar için çeşitli
standartlar tanımlamak amacıyla üretilmiştir. Bu standartları tanımlarken de RPC’yi
kullanmıştır. DCE standardı bir süre kullanılmış, fakat tam sonuç alınamadan yerine geçecek
değişik yöntemlerin çıkması (CORBA, DCOM) sonucu, bugün çok az uygulamada
kullanılmaktadır. Microsoft COM’u geliştirirken, DCE RPC’yi temel almıştır.
1.4.4. CORBA – Common Object Request Broker Architecture
OMG (Object Management Group1 - Nesne Yönetim Grubu) tarafından geliştirilen
CORBA, bileşenler arasındaki arayüzleri tanımlamak için standart bir mekanizmaya sahiptir,
1 OSF’den farklı olarak, OMG gerçek yazılım üretmez, sadece ayrıntılı tanımlar üretir.
7
ve bu arayüzlerin gerçeklenmesini kolaylaştırmak için geliştiricinin seçeceği programlama
dilini kullanan bazı araçlar içerir. CORBA, bir uygulamanın veya farklı uygulamaların çeşitli
bileşenlerinin, kendi aralarında haberleşebilmeleri için gerekli olan tüm altyapıyı sağlar.
CORBA, bilgisayar yazılım dünyasında nadir olarak sağlanabilen “platform
bağımsızlığı” ve “dil bağımsızlığı” özelliklerini içerir. Platform bağımsızlığı, üzerinde
CORBA ORB yürütmesi olan her türlü platform (modern işletim sistemleri) üzerinde
CORBA nesnelerinin kullanılabilmesi demektir. Dil bağımsızlığı ise, CORBA nesnelerinin
hemen hemen istenilen tüm programlama dillerinde gerçeklenebileceği, haberleştikleri diğer
CORBA nesnelerinin hangi dili kullandıklarını bilmek zorunda olmadıkları anlamına gelir.
1.4.5. DCOM – Microsoft Distributed Component Object Model
1993 yılında duyurduğu COM (Component Object Model) ile farklı sistemler
üzerindeki bileşenlere erişim sağlayan Microsoft, 1996 yılında duyurduğu DCOM modeli ile
de bileşenlerden oluşan ağ uygulamaları yaratmayı mümkün hale getirerek, dağıtık sistemler
piyasasına giriş yapmıştır. DCOM, CORBA ile benzer imkanlara sahiptir. DCOM Microsoft
işletim sistemlerine (Windows 9x, NT, 2000) entegre edilmiştir. Fakat Windows işletim
sistemleri dışında seyrek kullanılır.
CORBA-DCOM köprüleri sayesinde CORBA nesneleri DCOM nesneleri ile, ve
DCOM nesneleri de CORBA nesneleri ile haberleşebilirler. Mevcut uyumsuzluklar nedeni ile
iki sistemi uzlaştırmak zordur. Bu köprüler her ne kadar mükemmel çözüm olmasalar da,
DCOM ve CORBA nesnelerinin bir arada kullanılması gerektiği durumlarda kullanışlıdırlar.
1.4.6. RMI – Java Remote Method Invocation
RMI, bir kaç özelliği dışında CORBA’ya çok benzer. RMI’nin avantajlarından biri
nesneleri CORBA’nın aksine referans olarak değil de değer olarak geçirmesidir. (CORBA’nın
2.0 sürümünden itibaren nesnelerin değer olarak geçirilmesine destek verilmiştir.) Ancak
RMI’nin en büyük dezavantajı sadece Java destekli olmasıdır. Yani hem istemci hem sunucu
tarafı programları tamamen Java ile yazılmış olmalıdır.
8
2. CORBA
CORBA, OMG (The Object Management Group) tarafından geliştirilmiştir. OMG,
Nisan 1989’da, içlerinde 3Com Corporation, American Airlines, Canon, Inc., Data General,
Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems ve Unisys
Corporation’ın da bulunduğu 11 şirket ortaklığında, dağıtık nesneye yönelik uygulamaların
beraber çalışabilirliğini ve taşınabilirliğini sağlayan standartları oluşturmak amacıyla
kurulmuştur. Şu anda 800 kadar üyesi olan konsorsiyum, yazılım endüstrisi için firma
bağımsız ayrıntılı tanımlar geliştirmeye devam etmektedir. Günümüzde birçok işletim
sisteminde bu ayrıntılı tanımların olduğunu görebilirsiniz. Bu ayrıntılı tanımlar, Dağıtık
Nesne Hesaplamaları için gerekli standart arayüzleri, detayı ile anlatır.
OMG’nin 1989 yılındaki kuruluşunu takiben, Aralık 1990 yılında CORBA 1.0
piyasaya sürülmüştür. Bunu, 1991 yılının başlarında, IDL (Interface Definition Language) ve
uygulamaların bir ORB ile haberleşebilmeleri için API’lerin tanımlandığı CORBA 1.1 takip
etmiştir. CORBA 1.x sürümleri ile birlikte farklı mimarilerde, farklı makinelerde ve farklı
dillerde yazılmış nesnelerin birbirleriyle haberleşmelerini sağlayarak nesneler arası ilişkilere
ayrı bir boyut kazandırmıştır.
CORBA 1.x sürümleri dağıtık nesnelerin ilişkilendirilmesi açısından atılmış önemli
adımlardı, fakat bazı eksiklikleri vardı. IDL için ve bir uygulama üzerinden bir ORB’ye
erişmek için standartlar tanımlanmış olsa da, en büyük eksiklik ORB’ların birbirleriyle
haberleşebilmeleri için standart bir protokol tanımlanmamış olmasıydı. Bu yüzden bir
üreticinin ürettiği bir ORB ile farklı bir üreticinin ORB’u haberleşemeyecekti. Bu da dağıtık
sistemlerin amacına sınırlama getirmekteydi.
Aralık 1994’de tamamlanan CORBA 2.0 sürümünün en büyük başarısı, farklı ORB’ler
arası haberleşmenin sağlanabilmesi için standart bir protokolün tanımlanmış olmasıydı. IIOP
(Internet InterORB Protocol) olarak adlandırılan bu protokol sayesinde CORBA uygulamaları
daha fazla üreticiden bağımsız hale geldiler. IIOP protokolü sadece, Internet ve birçok
intraneti bünyesinde barındıran TCP/IP tabanlı ağlarda kullanılabilir.
CORBA, Nesne Yönetim Mimarisinin (OMA – Object Management Architecture) bir
parçasıdır. CORBA’nın OMA içerisindeki görevi ORB (Object Request Broker – Nesne İstek
Aracı) fonksiyonlarını yerine getirmektir. CORBA’yı anlatmaya başlamadan önce OMA
hakkında biraz bilgi vermek konunun daha rahat anlaşılmasını sağlayacaktır.
9
2.1. OMA – Object Management Architecture
Nesne Yönetim Mimarisi, nesne teknolojisine dayandırılan bir tak-ve-çalıştır bileşen
yazılım ortamı yaratmak için, bileşen arayüzlerinin nasıl standartlaştırılacağına rehberlik eder.
OMA bir Nesne Modeli ve bir Referans Modeli’nden oluşur. Nesne Modeli, heterojen
bir bölgede dağılmış olan nesnelerin nasıl tanımlanacağını belirlerken, Referans Modeli de bu
nesneler arasındaki etkileşimi tanımlar.
OMA Nesne Modeli’nde bir nesne, servislerine sadece tanımlanmış arayüzler
üzerinden erişilebilen, tekil sabit bir kimliği olan korunmuş bir varlıktır. İstemciler, servisleri
kendi taraflarında icra etmek için nesnelere istek gönderirler. Her nesnenin bulunması ve
yürütülmesi isteği yapan istemciden saklanır.
ġekil 2.1. OMA Referans Modeli
ġekil 2.1’de gösterilen OMA Referans Modeli, OMA’yı oluşturan bileşenleri,
arayüzleri ve protokolleri teşhis eder ve tanımlar.
2.1.1. ORB
Modelin merkezinde, istemcilerin ve nesnelerin dağıtık bir ortamda haberleşmelerini
sağlayan, modelin haberleşme merkezi sayılan ORB bileşeni yer alır. ORB, adreslenmiş
nesnelerin yürütülmesinde kullanılan platformlardan ve tekniklerden bağımsız olarak,
nesnelerin haberleşebilmelerini sağlamak için bir alt yapı sağlar.
2.1.2. CORBA Servisleri (CORBA Services)
Bu bileşen, nesnelerin yaşam döngüsü yönetimini standartlaştırır. Nesneleri yaratmak,
nesnelere erişimi kontrol etmek, tekrar aranan nesnelerin izini saklamak, ve nesnelerin
ORB
Uygulama Nesneleri
Dikey CORBAVasıtaları
Yatay CORBAVasıtaları
CORBA Servisleri
10
grupları arasındaki ilişkiyi sürekli olarak muhafaza etmek için fonksiyonlar sağlanır. CORBA
Servisleri bileşenleri tek nesnelerin görevlerini yerine getirebilecekleri soysal ortam sağlarlar.
CORBA Servislerinin standartlaştırılması, farklı uygulamaların uyumuna önderlik etmiş, ve
geliştirici için verimliliği arttırmıştır. CORBA Servisleri bazı kaynaklarda Nesne Servisleri
olarak geçer. Bu servislere örnek olarak, istemcilerin nesneleri isimlerine göre bulmalarını
sağlayan İsimlendirme Servisi (Naming Service), ve özelliklerine göre bulmalarını sağlayan
Takas Servisi (Trading Service), sayılabilir.
2.1.3. Dikey & Yatay CORBA Vasıtaları (Horizontal & Vertical CORBA Facilities)
Dikey vasıtalar, alana özel vasıtalar olarak ta adlandırılır. Özel bir dikey pazarda (ör:
sağlık, üretim, finans) yer alan iş problemlerine çözümler sağlayan bileşenleri temsil eder.
Genel vasıtalar da denilen yatay vasıtalar (Vertical CORBA Facilities) ise, şirketlerin ve
işlerin üstünde bir destek sağlayan bileşenleri temsil eder. Bu vasıtalara örnek olarak, Sayısal
Mal Yönetimi (Digital Asset Management) bileşeni ve Dağıtık Doküman Bileşen Vasıtası
(DDCF – Distributed Docment Component Facility) sayılabilir. DDCF bir doküman modeline
dayalı olarak nesnelerin gösterimine ve takasına izin verir.
2.1.4. Uygulama Nesneleri (Application Objects)
Kullanıcılar için özel işleri yerine getiren nesnelerdir. OMG tarafından
standartlaştırılmış olsun yada olmasın, bu arayüzler dağıtık bir ortamda ORB üzerinden uzak
nesnelerdeki yöntemleri dinamik veya statik olarak çağırabilen uygulama nesnelerine erişim
sağlarlar. Bir uygulama tipik olarak çok sayıda temel nesne sınıfının bir araya getirilmesi ile
oluşur. Uygulama nesnelerinin yeni sınıfları, CORBA Servisleri tarafından sağlanan varolan
sınıfların genelleştirilmesi ve özelleştirilmesi vasıtasıyla, varolan sınıfların değiştirilmesi ile
oluşturulabilir. Uygulama geliştirmedeki çoklu-nesne sınıfı yaklaşımı, geliştirici için
verimliliği arttırırken, son kullanıcı için de uygulamalarını bir araya getirmek ve en iyi şekilde
çalıştırabilmek için çeşitliliği arttırır.
2.2. Bir ORB’nin (Object Request Broker) Yapısı
ġekil 2.2, bir istemci tarafından bir nesne yürütmesine gönderilmiş bir isteği
gösteriyor. İstemci, nesne üzerinde bir işlem yapmak isteyen varlıktır, ve nesne yürütmesi
gerçekte nesneyi yürüten kod ve veridir.
11
ġekil 2.2. ORB Üzerinden Gönderilen Bir İstek
ORB, istek için nesne yürütmesini bulmada, nesne yürütmesini isteği almak için
hazırlamada, ve isteği oluşturan veri ile iletişim kurmada gerekli tüm mekanizmalardan
sorumludur. İstemci arayüzünün görünüşü, nesnenin nerde konumlandığından, hangi
programlama dilinde yürütüldüğünden, veya nesnenin arayüzüne yansımayan herhangi başka
bir durumdan tamamen bağımsızdır.
ġekil 2.3. Nesne İstek Arayüzlerinin Yapısı
12
ġekil 2.3 başlı başına bir Object Request Broker (ORB)’ın yapısını gösterir. ORB’ye
doğru olan arayüzler kutular ile gösterilmiştir, ve oklar ya ORB’nin çağrıldığını yada arayüz
üzerinden bir üst-çağrı yapıldığını gösterir.
Bir çağrı yapmak için İstemci, Dinamik Çağrı Arayüzü’nü (DII – Dynamic Invocation
Interface – hedef nesnenin arayüzünden bağımsız olan aynı arayüz) veya bir OMG IDL
stub’ını (hedef nesnenin arayüzüne bağlı olan özel stub) kullanabilir. İstemci bazı
fonksiyonlar için ORB ile direkt olarak temas ta kurabilir.
Nesne Yürütmesi bir çağrıyı, OMG IDL tarafından üretilen iskelet üzerinden veya bir
dinamik iskelet üzerinden, bir üst-çağrı olarak alır. Nesne Yürütmesi bir isteği işlerken veya
başka durumlarda, Nesne Adaptörünü ve ORB’yi çağırabilir.
Arayüzlerin nesnelere tanımlanması iki yolla yapılabilir. Arayüzler, arayüz tanımlama
dilinde (IDL) statik olarak tarif edilebilir. Bu dil, nesnelerin tiplerini, üzerlerinde
yapılabilecek işlemlere, ve bu işlemlerin alabileceği parametrelere göre tanımlar. Alternatif
olarak, arayüzler aynı zamanda bir Arayüz Ambarı (Interface Repository) servisine
eklenebilir; bu servis bir arayüzün bileşenlerini, bu bileşenlere çalışma zamanı (run-time)
erişime izin vererek, nesneler olarak gösterir. Her ORB yürütmesinde, Arayüz Tanımlama
Dili ve Arayüz Ambarı eşit güçtedirler.
ġekil 2.4. Stub’ı veya Dinamik Çağrı Arayüzünü Kullanan Bir İstemci.
13
İstemci, nesnenin tipini ve yapılması gereken işlemi bilerek, ve nesne için bir Nesne
Referansına erişerek, bir çağrı yapar. İstemci çağrıyı, nesneye özel stub rutinlerini çağırarak,
veya çağrıyı dinamik olarak yapılandırarak, başlatır (ġekil 2.4).
Bir çağrıyı başlatmak için dinamik ve stub arayüzü aynı çağrı semantiklerini yerine
getirirler, ve mesajın alıcısı çağrının nasıl başlatıldığını bilemez.
ORB uygun yürütme kodunu yerleştirir, parametreleri aktarır, ve IDL iskeleti veya
dinamik iskelet üzerinden Nesne Yürütmesine kontrolü geçirir (ġekil 2.5). İskeletler arayüze
ve nesne adaptörüne özeldir. Çağrıyı gerçekleştirirken, nesne yürütmesi, Nesne Adaptörü
vasıtasıyla ORB’den bazı servisleri bulabilir. Çağrı tamamlandığında, kontrol ve çıktı
değerleri istemciye geri döner.
Nesne Yürütmesi hangi Nesne Adapörünün kullanılacağını seçebilir. Bu karar, Nesne
Yürütmesinin hangi tipte servislere ihtiyaç duyduğuna bağlıdır.
ġekil 2.6, arayüz ve yürütme bilgisinin, istemciler ve nesne yürütmeleri üzerinde, nasıl
hazır hale getirilebileceğini gösterir. Arayüz OMG IDL’de ve/veya Arayüz Ambarında
tanımlanır; tanımlama istemci stub’larını ve nesne yürütme iskeletlerini oluşturmak için
kullanılır.
ġekil 2.5. İstek Alan Bir Nesne Yürütmesi
14
ġekil 2.6. Arayüz ve Yürütme Ambarları
Nesne yürütme bilgisi yükleme sırasında sağlanır, ve çağrı teslimatı sırasında
kullanılmak üzere Yürütme Ambarında saklanır.
2.2.1. Object Request Broker (ORB)
Mimaride, ORB’nin tek bir bileşen gibi yürütülmesinden ziyade, arayüzleri vasıtasıyla
tanımlanması makbuldür. Uygun arayüzü sağlayan herhangi bir ORB yürütmesi kabul
edilebilir. Arayüz üç kategoride düzenlenir:
1. Tüm ORB yürütmeleri için aynı olan işlemler
2. Nesnelerin belirli tiplerine özel olan işlemler
3. Nesne yürütmelerinin belirli tarzlarına özel olan işlemler
Farklı ORB’ler farklı yürütme seçeneklerini gerçekleştirebilirler, ve IDL derleyicileri,
ambarlar, ve çeşitli Nesne Adaptörleri ile birlikte, farklı seçeneklere ve özelliklere sahip
nesnelerin yürütmeleri ve istemcilere bir takım servisler sağarlar.
Nesne referansları için farklı gösterimlere sahip, ve çağrıların gerçekleşmesinde
farklılıkları olan birçok ORB yürütmesi olabilir. Bir istemcinin, farklı ORB yürütmeleri
tarafından idare edilen iki nesne referansına, aynı anda erişmesi mümkündür. İki ORB beraber
çalışmak üzere tasarlanmışsa, bu ORB’ler kendi nesne referanslarını ayırt edebilmeliler. Bu
istemcinin sorumluluğunda değildir.
15
ORB çekirdeği, nesnelerin, ve isteklerin iletişiminin temel gösterimini sağlayan
ORB’nin bir kısmıdır. CORBA, farklı nesne mekanizmalarını desteklemek üzere
tasarlanmıştır, ve ORB çekirdeğinin üstünde olan, ORB çekirdekleri arasındaki farklılıkları
gizleyebilen arayüzleri sağlayan bileşenlerle ORB’yi oluşturarak bunu yapar.
2.2.2. Ġstemciler
Bir nesnenin bir istemcisi, nesne için bir nesne referansına erişir, ve nesnedeki
işlemleri çağırır. İstemci, arayüzüne göre nesnenin sadece mantıksal yapısını bilir ve çağrılara
karşı nesnenin davranışını dener. Her ne kadar bir istemcinin, bir nesne üzerindeki istekleri
başlatan bir program veya işlem olduğunu genellikle düşüneceksek te, bir istemcinin belirli
bir nesneye bağlı bir şey olduğunu kabul etmek önemlidir. Örneğin bir nesnenin yürütmesi,
başka nesnelerin istemcisi olabilir.
İstemciler genellikle nesneleri ve ORB arayüzlerini, ORB’yi programcıların
seviyesine çıkartan bir dil eşlemesinin görüş açısı vasıtası ile görürler. İstemciler
taşınabilirler, ve istenilen arayüzü yürüten herhangi bir nesne örneği ile istenilen dil
eşlemesini destekleyen herhangi bir ORB’deki kaynak değişiklikleri olmadan da
çalışabilmeye elverişli olmalıdırlar. İstemciler nesnenin yürütülmesi, hangi nesne adaptörünün
yürütme tarafından kullanılacağı, veya hangi ORB’nin ona erişeceği hakkında herhangi bir
bilgiye sahip değildirler.
İstemciler hakkında daha fazla bilgi için 2.4. Bir İstemcinin Yapısı bölümüne bakınız.
2.2.3. Nesne Yürütmeleri
Bir nesne yürütmesi, genellikle nesne örneği için veriyi ve nesnenin yöntemleri için
kodu tanımlayarak, nesnenin semantiklerini sağlar. Yürütme çoğu kez, nesnenin davranışını
yerine getirmek için, diğer nesneleri veya ek yazılımları kullanacaktır. Bazı durumlarda,
nesnenin birincil görevi, nesne olmayan şeylerin üzerinde yan etki oluşturmaktır.
Ayrı sunucular, kütüphaneler, yöntem vasıtasıyla bir program, korunmuş bir
uygulama, nesneye yönelik bir veritabanı gibi şeyler içeren çok çeşitli nesne yürütmeleri
desteklenebilir. Ek nesne adaptörlerinin kullanımı doğrultusunda, nesne yürütmesinin
herhangi bir tipini sanal olarak sağlamak mümkündür.
Genellikle, nesne yürütmeleri ORB’ye veya istemcinin nesneyi nasıl çağırdığına bağlı
değildirler. Nesne yürütmeleri, nesne adaptörünün tercihi ile ORB’ye bağlı servislere
arayüzler seçebilirler. (Detaylı bilgi için: 2.5. Bir Nesne Yürütmesinin Yapısı)
16
2.2.4. Nesne Referansları
Bir Nesne Referansı, bir ORB içinde bir nesne tanımlamak için gerekli olan bilgidir.
Hem istemciler hem de nesne yürütmeleri, dil eşlemesine bağlı olarak nesne referansının
donuk bir tasarımına sahiptirler, ve böylece gerçek gösterimlerinden yalıtılırlar. İki ORB
yürütmesi nesne referansı gösterim tercihlerine göre farklılık gösterebilirler.
Bir istemciye verilen bir nesne referansının gösterimi, ancak o istemcinin ömrü kadar
geçerlidir.
Tüm ORB’ler, belirli bir programlama dili için, bir nesne referansına (çoğunlukla bir
Nesne olarak işaret edilir) aynı dil eşlemesini sağlamalıdırlar. Bu, belirli ORB’den bağımsız
nesne referanslarına, belirli bir dilde yazılmış bir programın erişmesine izin verir.
Programcının rahatlığı için, nesne referanslarına erişmek için dil eşlemesi de ek yollar
sağlayabilir.
Tüm nesne referanslarından farklı olması garanti edilmiş ayrı bir nesne referansı
vardır, ki bu da hiç nesne olmadığının gösterimidir.
2.2.5. OMG Arayüz Tanımlama Dili (IDL – Interface Definition Language)
OMG Arayüz Tanımlama Dili nesnelerin tiplerini arayüzlerini tayin ederek tanımlar.
Arayüz, bir isimlendirilmiş işler kümesi ve bu işlerin parametrelerinden oluşur. IDL’in, ORB
tarafından oluşturulan nesnelerin tanımlanması için kavramsal bir kafes sağlamasına rağmen,
ORB’nin çalışması için IDL kaynak kodunun varlığına gerek yoktur. Stub rutinlerinde veya
bir çalışma zamanı arayüz ambarında eş bir bilgi olduğu sürece, belirli bir ORB düzgün
çalışma yeteneğine sahip olabilecektir.
IDL belirli bir nesne yürütmesi için, hangi işlerin hazır olduğunu ve onların nasıl
çağrılması gerektiğini potansiyel istemcilerine söylemekle görevlidir. IDL tanımlamalarından,
CORBA nesnelerini belirli programlama dillerinin veya nesne sistemlerinin içine yerleştirmek
mümkündür.
Daha detaylı bilgi için 2.9. Arayüz Tanımlama Dili bölümüne bakınız
2.2.6. Programlama Dilleri ile OMG IDL’nin EĢlenmesi
Farklı olan nesneye yönelik veya nesneye yönelik olmayan programlama dilleri,
CORBA nesnelerine farklı yollardan erişmeyi tercih edebilirler. Nesneye yönelik diller için,
CORBA nesnelerini programlama dili nesneleri gibi görmek istenebilir. Nesneye yönelik
olmayan dillerde, nesne referansı, yöntem isimleri gibi şeylerin gerçek ORB gösterimini
17
gizlemek iyi bir fikirdir. Bir programlama dili ile belirli bir OMG IDL’nin eşlenmesi, tüm
ORB yürütmeleri için aynı olmalıdır. Dil eşlemesi, ORB üzerinden nesnelere ulaşmak için,
dile özgü veri tiplerinin ve prosedür arayüzlerinin tanımlamalarını içerir. İstemci stub
arayüzünün (nesneye yönelik diller için gerekli değil), dinamik çağrı arayüzünün, yürütme
iskeletinin, nesne adaptörlerinin, ve direkt ORB arayüzünün yapılarını içerir.
Bir dil eşlemesi, nesne çağrıları ile yürütme veya istemcideki kontrol thread’lerinin
arasındaki etkileşimi de tanımlar. En genel eşlemeler, nesne işi bitince rutini geri döndüren
senkron çağrılarını sağlarlar. Ek eşlemeler bir çağrının başlatılmasını sağlatabilirler, ve
kontrolü programa geri verirler. Bu gibi durumlarda, nesne çağrımı ile programın kontrol
thread’leri arasındaki senkronizasyonu sağlamak için, dile-özgü ek rutinler olmalıdır.
Daha detaylı bilgi için 2.10. Dil Eşlemeleri bölümüne bakınız.
2.2.7. Ġstemci Stub’ları
Nesneye yönelik olmayan bir dilin eşlenmesi için, her arayüz tipi için stub’lara doğru
bir programlama arayüzü olacaktır. Genellikle, stub’lar bir nesne üzerindeki OMG IDL
tanımlı işlere, OMG IDL’ye ve belirli bir programla dili için dil eşlemesine aşina olan
programcılar için kolay olan bir yol ile, erişim sağlarlar. Stub’lar, belirli bir ORB çekirdeğine
özel olan, ve tahminen ona göre ayarlanmış olan, arayüzleri kullanarak ORB’nin diğer
kısmına çağrı yaparlar. Eğer birden fazla ORB hazır durumdaysa, farklı ORB’lere tekabül
eden farklı stub’lar olabilir. Bu durumda ORB ve dil eşlemesinin, belirli nesne referansı ile
doğru stub’ları birleştirmek üzere beraber çalışmaları gereklidir.
C++ ve Smalltalk gibi nesneye yönelik diller stub arayüzlerine ihtiyaç duymazlar.
2.2.8. Dinamik Çağrı Arayüzü (DII – Dynamic Invocation Interface)
Arayüz aynı zamanda, nesne çağrılarının dinamik yapılandırılmasına izin vermeye de
hazırdır. Bunun anlamı, belirli bir nesne üzerinde belirli bir iş yapmaya özel bir stub rutinini
çağırmaktansa, istemci çağrılacak nesneyi, yapılacak işlemi, ve bir çağrı veya çağrılar
dizisinden geçen işin parametreler kümesini belirleyebilir. İstemci kodu yapılacak iş ve
geçirilecek parametreler hakkında bilgi içermelidir (muhtemelen bunu Arayüz Ambarı’ndan
veya başka bir çalışma zamanı kaynaktan elde eder). Dinamik çağrı arayüzünün doğası,
aslında bir programlama dili eşlemesinden diğerine farklılıklar gösterebilir.
18
2.2.9. Yürütme Ġskeleti
Belirli bir dil eşlemesi için, ve muhtemelen nesne adaptörüne bağlı olarak, her tipten
nesneyi yürüten yöntemlere doğru bir arayüz olacaktır. Arayüz genellikle üst-çağrı (up-call)
arayüzü olacaktır. Bunun anlamı; nesne yürütmesi arayüze uyan rutinler yazar ve ORB iskelet
üzerinden onları çağırır.
Bir iskeletin varlığı, ona uyan bir istemci stub’ının varlığını ifade etmez (istemciler
aynı zamanda dinamik çağrı arayüzü vasıtasıyla da istek yapabilirler).
Yürütme yöntemlerini çağırmak için iskelet kullanmayan bir nesne adaptörü yazmak
ta mümkündür. Örneğin, Smalltalk gibi diller için yürütmeleri dinamik olarak yaratmak
mümkün olabilir.
2.2.10. Dinamik Ġskelet Arayüzü (DSI – Dynamic Skeleton Interface)
Nesne çağrılarının dinamik olarak tutulmasını sağlayan bir arayüz vardır. İstemci
tarafının Dinamik Çağrı Arayüzü’ne benzer şekilde, bir nesnenin yürütmesi, belirli bir işe özel
bir iskelet üzerinden erişim yerine, iş isimleri ve parametrelere erişim sağlayan bir arayüz
üzerinden ulaşır. Sadece bu parametrelerin statik bilgisi kullanılabilir, veya parametreleri
tayin etmek için, dinamik bilgi (muhtemelen Arayüz Ambarı’ndan alınır) de kullanılabilir.
Yürütme Kodu ORB’ye tüm iş parametrelerinin tanımlamalarını sağlamalıdır, ve ORB
de işi yaparken kullanılabilecek her giriş parametresinin değerini sağlamalıdır. Arayüz kodu
her çıkış parametresinin değerini, veya başka bir şeyi, işi yaptıktan sonra ORB’ye vermelidir.
Dinamik iskelet arayüzünün doğası, aslında bir programlama dili eşlemesinden veya nesne
adaptöründen diğerine farklılıklar gösterebilir, ama tipik olarak bir üst-çağrı arayüzü
olacaktır.
Dinamik iskeletler, hem istemci stub’ları tarafından, hem de dinamik çağrı arayüzü
tarafından çağrılabilirler; her ikisinde de istemci istek yapısı arayüzünün tarzı aynı sonuçları
sağlar.
2.2.11. Nesne Adaptörleri
Bir nesne adaptörü, bir nesne yürütmesinin ORB tarafından sağlanan servislere
erişmesinin temel yoludur. Nesnelerin özel çeşitleri için uygun olan arayüzler ile birkaç nesne
adaptörünün, yaygın olarak hazır durumda olması beklenecektir. Bir nesne adaptörü vasıtası
ile ORB tarafından sağlanan servisler çoğu kez, nesne referanslarının oluşumunu ve izahını,
19
çağrı yöntemini, birbirine tesir etmenin güvenliğini, nesne ve yürütme aktivasyonunu ve de-
aktivasyonunu, nesne referanslarının yürütmelerle eşlenmesini, ve yürütmelerin kaydını içerir.
Nesnelerin sayıları, ömürleri, idareleri, yürütme tarzları, ve diğer özelliklerinin geniş
bir yelpazesi, ORB çekirdeğinin tüm nesneler için uygun ve etkili tek bir arayüz sağlamasını
zorlaştırır. Bunun için, nesne adaptörleri vasıtasıyla, ORB’nin, onlara uydurulmuş arayüzlerle
benzer ihtiyaçları olan nesne yürütmelerinin belirli gruplarını hedeflemesi mümkündür.
Daha detaylı bilgi için 2.6 Bir Nesne Adaptörünün Yapısı bölümüne bakınız.
2.2.12. ORB Arayüzü
ORB Arayüzü, tüm ORB’ler için aynı olan ve nesnenin arayüzüne veya nesne
adaptörüne bağlı olmayan, direkt olarak ORB’ye giden arayüzdür. ORB’nin görevlerinin çoğu
nesne adaptörü, stub’lar, iskelet, veya dinamik çağrı üzerinden sağlandığı için, tüm nesneler
için genel olan sadece birkaç iş vardır. Bu işler hem istemciler hem de nesnelerin yürütmeleri
için kullanışlıdırlar.
2.2.13. Arayüz Ambarı
Arayüz Ambarı, çalışma zamanında hazır durumda olan bir form içinde IDL bilgisini
temsil eden sürekli nesneler sağlayan bir servistir. Arayüz Ambarı bilgisi istekleri yapmak
için ORB tarafından kullanılabilir. Üstelik, Arayüz Ambarı’ndaki bilgiyi kullanarak, program
derlendiği sırada arayüzü henüz bilinmeyen bir nesne ile karşılaşan bir program, nesne
üzerinde hangi işlerin yapılabileceğine karar verme ve onun üzerinde çağrı yapma imkanına
sahip olur.
ORB’nin çalışmasındaki rolüne ek olarak Arayüz Ambarı, ORB nesnelerine
arayüzlerle birleştirilmiş ek bilgileri saklamak için genel bir yerdir. Örneğin, hata giderme
(debugging) bilgisi, stub’ların veya iskeletlerin kütüphanesi, belirli nesne çeşitleri ile
görüntülenebilen veya biçimlendirilebilen rutinler Arayüz Ambarı ile birleştirilebilirler.
Daha detaylı bilgi için 2.11 Arayüz Ambarı bölümüne bakınız.
2.2.14. Yürütme Ambarı
Yürütme Ambarı, ORB’nin nesnelerin yürütmelerini seçmesi ve aktif hale getirmesi
için gerekli bilgiyi içerir. Yürütme Ambarı’ndaki birçok bilginin bir ORB’ye veya işletim
birimine özel olmasına rağmen, Yürütme Ambarı böyle bir bilgiyi saklamak için geleneksel
yerdir. Çoğunlukla yürütmelerin kurulumu ve politikaların kontrolü aktivasyona bağlıdır, ve
nesne yürütmelerinin çalıştırılması Yürütme Ambarı’ndaki işler üzerinden yapılır.
20
ORB’nin çalışmasındaki rolüne ek olarak Yürütme Ambarı, ORB nesnelerinin
yürütmeleri ile birleştirilmiş ek bilgileri saklamak için genel bir yerdir. Örneğin, hata giderme
bilgisi, idari kontrol, kaynak ayrımı, güvenlik gibi şeyler Yürütme Ambarı ile
birleştirilebilirler.
2.3. Örnek ORB’ler
Genel ORB mimarisi içinde ORB yürütmelerinin bir çok çeşidi vardır. Bu bölüm bazı
farklı seçenekleri anlatacaktır. Belirli bir ORB’nin iletişim için çok yönlü seçenek ve
protokolleri destekleyebileceği unutulmamalıdır.
2.3.1. Ġstemci- ve Yürütme-YerleĢik ORB
Eğer uygun bir iletişim mekanizması varsa, bir ORB istemcilerde ve yürütmelerde
bulunan rutinlerde yürütülebilir. İstemcideki stub’lar, yürütmelerle iletişimi kurmak için, bir
şeffaf-konum (location-transparent) IPC mekanizmasını kullanabilirler veya bir konum
servisine direkt ulaşabilirler. Yürütme ile bağlanmış kod, istemciler tarafından kullanılması
için ilgili veritabanlarını kurmakla görevlidir.
2.3.2. Sunucu-tabanlı ORB
ORB’nin idaresini merkezileştirmek için, tüm istemciler ve yürütmeler, görevleri
istekleri istemcilerden yürütmelere yönlendirmek olan bir yada daha çok sunucu ile
haberleşebilirler. Altında olan işletim sistemine kalırsa ORB normal bir program olabilir, ve
ORB ile haberleşmek için normal IPC kullanılabilir.
2.3.3. Sistem-tabanlı ORB
Güvenliği, kuvveti ve performansı arttırmak için, ORB, altında olan işletim sisteminin
bir temel servisi olarak sağlanabilir. Nesne referansları, her istekteki kimlik sorgulama
masrafını azaltarak, kalıcı yapılabilir. İşletim sisteminin istemcilerin ve yürütmelerin yerini ve
yapısını bilebilmesi sayesinde, çok çeşitli iyileştirmelerin yerine getirilmesi mümkündür,
örneğin, ikiside aynı makinedeyse dönüştürme (marshaling1) işleminden sakınır.
1 ORB’nin görevlerinden biri, method’u çağıran bileşenden giriş parametrelerini almak, ve bunları ağ
üzerinden aktarılabilecek bir biçime dönüştürmektir. Bu işleme dönüştürme (marshaling) denir. ORB, ağ
üzerinden gelen dönüş parametrelerini de, çağıran bileşenin anlayabileceği biçime geri dönüştürür. Bu işleme de
geri dönüştürme (unmarshaling) denir.
21
2.3.4. Kütüphane-tabanlı ORB
Yürütmeleri paylaştırılabilen ve hafif olan nesneler için, yürütme gerçekte bir
kütüphanede olmalıdır. Bu durumda, stub’lar gerçek yöntemler olabilir. Bu, bir istemci
programın nesneler için olan verilere erişmesinin mümkün olduğunu, ve yürütmenin veriye
zarar vermemesi konusunda istemciye güvendiğini farz eder.
2.4. Bir Ġstemcinin Yapısı
Bir nesnenin bir istemcisi o nesneye işaret eden bir nesne referansına sahiptir. Bir
nesne referansı, farklı bir nesne üzerindeki bir çağrıya bir parametre olarak aktarılan veya
çağrılabilen bir işaret (token)’tir. Bir nesnenin çağrımı, çağrılan nesnenin, yapılan işin, işe
gönderilen veya işten dönen parametrelerin belirtilmesini gerektirir.
ORB, nesne yürütmesine doğru olan kontrol aktarımını ve veri aktarımını, ve
istemciye geri dönüşünü idare eder. ORB’nin çağrıyı tamamlayamaması durumu için, istisna
bir cevap sağlanmıştır. Genellikle, bir istemci çağrıyı yapan programının içindeki bir rutini
çağırır, ve iş bitince geri döner.
İstemciler programlarında, kütüphane rutinlerine erişir gibi nesne-tipine-özel stub’lara
erişebilirler (ġekil 2.7). İstemci programı böylece, kendi programlama dilinde, rutinleri
normal bir biçimde çağrılabilir olarak görür. Tüm yürütmeler nesneleri işaret etmek için
dillere özgü bir veri tipi sağlayacaklardır, bu genelde bir donuk işaretçi (opaque pointer)’dir.
Daha sonra istemci, çağrıyı başlatmak için o nesne referansını stub rutinlerine geçirir. Stub’lar
nesne referans gösterimine ulaşabilirler, ve çağrıyı gerçekleştirmek için ORB ile etkileşim
içine girerler.
Kütüphane kodunun alternatif bir kümesi nesneler üzerinde çağrılar yapmak için hazır
durumdadır. Örneğin, nesne derleme zamanında tanımlı değilse, bu küme kullanılır. Bu
durumda, istemci program, nesnenin tipini ve çağrılan yöntemi adlandırmak için ek bilgi
sağlar, ve parametreleri belirlemek ve çağrıyı başlatmak için bir sıra çağrılar gerçekleştirir.
İstemciler nesne referanslarını genellikle, referanslarının bulunduğu başka nesneler
üzerindeki çağrılardan çıkış parametresi biçiminde alarak bulurlar. Bir istemci aynı zamanda
bir yürütme olduğunda, nesne referanslarını, yürüttüğü nesnelere olan çağrılardaki giriş
parametreleri olarak alır. Bir nesne referansı, dosyalarda saklanabilen veya korunan yada
farklı anlamlarda ifade edilen, ve sonradan karakter kümesini oluşturan ORB tarafından bir
nesne referansına tekrar dönüştürülen, bir karakter kümesine (string) de çevrilebilir.
22
ġekil 2.7. Tipik bir İstemcinin Yapısı
2.5. Bir Nesne Yürütmesinin Yapısı
Bir nesne yürütmesi bir nesnenin gerçek durumunu ve davranışını sağlar. Nesne
yürütmesi çok değişik şekillerde yapılandırılabilir. İşlerin kendileri için yöntemler
tanımlamalarının yanında, bir yürütme, genellikle nesneleri aktive ve de-aktive etmek için
prosedürler tanımlayacak ve nesne durumunun devamlılığı ve nesneye erişimin kontrolü için
başka nesneleri veya nesne olmayan vasıtaları, yöntemleri yürütür gibi kullanacaktır.
Nesne Yürütmesi (ġekil 2.8), varlığını tayin etmek, yeni nesneler yaratmak, ve ORB-
bağımlı servisleri bulmak için, ORB ile bir çok değişik biçimde etkileşir. Temel olarak, nesne
yürütmesinin belirli bir çeşidi için uygun olan ORB servislerine bir arayüz sağlayan, bir nesne
adaptörüne erişerek bunu yapar.
Mümkün nesne yürütmelerinin çokluğu yüzünden, bir nesne yürütmesinin nasıl
yapılandırılacağı konusunda kesin konuşmak zordur.
Bir çağrı oluştuğunda, ORB çekirdeği, nesne adaptörü, ve iskelet, yürütmenin ilgili
yöntemine bir çağrı yapıldığı konusunda anlaşmaya varırlar. Çağrılmakta olan nesneyi,
yöntemin nesne için veriyi yerleştirmesinde kullanabileceği, bu yönteme doğru bir paramete
tayin eder. Ek parametreler iskelet tanımına göre temin edilirler. Yöntem tamamlandığında,
meydana gelen çıkış parametrelerini veya iletilen diğer sonuçları istemciye geri verir.
23
ġekil 2.8. Tipik bir Nesne Yürütmesinin Yapısı
Yeni bir nesne yaratıldığında, ORB bu nesne için yürütmeyi nerden bulacağını bilmesi
konusunda uyarılabilir. Genellikle, yürütme aynı zamanda kendini belli bir arayüzün
yürütülmüş nesneleri olarak kaydeder, ve eğer yürütme çalışır durumda değilse onu nasıl
çalıştıracağını belirler.
Çoğu nesne yürütmeleri, ORB ve nesne adaptörüne ek olarak, davranışlarını vasıtalar
kullanarak sağlarlar. Örneğin, taşınabilir nesne adaptörü bir nesne (kendi OID’si veya Nesne
ID’si) ile ilişkilendirilmiş bazı sürekli veriler sağlamasına rağmen, nispeten küçük boyuttaki
bu veri tipik olarak nesne yürütmesinin seçtiği bir depolama servisinde saklanan gerçek nesne
verisi için bir teşhis edici olarak kullanılır. Bu yapı ile, sadece farklı nesne yürütmelerinin
aynı depolama servisini kullanması değil, nesnelerin kendilerine en uygun servisi seçmeleri
de mümkündür.
2.6. Bir Nesne Adaptörünün Yapısı
Bir nesne adaptörü, nesne referans oluşturması gibi ORB servislerine erişmek için bir
nesne yürütmesinin temel aracıdır. Bir nesne adaptörü, nesne yürütmesine genel bir arayüz, ve
iskelete de özel bir arayüz ihraç eder. Özel bir ORB-bağımlı arayüz üzerine kuruludur.
24
Nesne adaptörleri aşağıdaki fonksiyonlardan sorumludurlar:
Nesne referanslarının oluşturulması ve açıklamaları
Yöntem çağrısı
Etkileşimlerin güvenliği
Nesne ve yürütme aktivasyonu ve de-aktivasyonu
Nesne referansları ile ilgili nesne yürütmelerini eşleştirmek
Yürütmelerin kaydı
Bu fonksiyonlar ORB çekirdeği ve bazı gerekli ek bileşenler kullanılarak yapılır. Çoğu
kez, bir nesne yürütmesi görevlerinin üstesinden gelmek için kendi durumunu muhafaza
edecektir. Belirli bir nesne adaptörünün, bir yada daha çok sorumluluğunu üzerine
yapılandırıldığı çekirdeğe emanet etmesi mümkündür.
ġekil 2.9’da görüldüğü gibi, direkt arayüz iskeletler üzerinden olmasına rağmen,
Nesne Adaptörü yöntemlerin çağrımına tamamıyla bağlanmıştır. Örneğin, Nesne Adaptörü
yürütmeyi aktif hale getirmek veya isteği onaylamak için kullanılabilir.
ġekil 2.9. Tipik bir Nesne Adaptörünün Yapısı
Nesne Adaptörü, Nesne Yürütmesinin bağlanabileceği servislerin büyük bir bölümünü
ORB’den ayırır. Farklı ORB’ler farklı seviyelerde servis sağlayacaklardır, ve farklı işletim
birimleri bazı özellikleri tamamıyla sağlayabilecek ve diğerlerinin Nesne Adaptörü tarafından
eklenmesine ihtiyaç duyacaklardır. Örneğin, bir çağrıda nesnenin kolay belirlenmesi için
25
nesne referansındaki belirli değerleri saklamayı istemek, Nesne Yürütmeleri için genel bir
şeydir. Eğer nesne adaptörü, yeni bir nesne yaratıldığında yürütmenin bu gibi değerleri
belirlemesine izin verirse, buna izin veren ORB’ler için bu değerleri nesne referansında
saklamayı becerebilir. Eğer ORB çekirdeği bu özelliği içermiyorsa, Nesne Adaptörü değeri
kendi deposunda saklayacak, ve bir çağrı üzerindeki yürütmeye verecektir. Nesne Adaptörleri
sayesinde, ORB çekirdeğinde yürütülüyor olsun yada olmasın bir nesne yürütmesinin bir
servise erişmesi mümkündür. Eğer ORB çekirdeği bu özelliği içeriyorsa, adaptör basitçe ona
bir arayüz sağlayacaktır; aksi halde, adaptör onu ORB çekirdeğinin tepesinde yürütmelidir.
Belirli bir adaptörün her örneği, yürütülmekte olduğu tüm ORB’ler için aynı arayüzü ve
servisi sağlamalıdır.
Aynı zamanda, tüm Nesne Adaptörleri için aynı arayüzü veya görevselliği sağlamak ta
gerekli değildir. Bazı Nesne Yürütmelerinin özel gereksinimleri vardır. Örneğin, bir nesneye
yönelik veritabanı sistemi, binlerce nesnesini, Nesne Adaptörüne ayrı ayrı çağrılar yapmadan
tümüyle kaydetmek isteyebilir. Böyle bir durumda, nesne adaptörü için herhangi bir nesne-
başına (per-object) durumunu muhafaza etmek elverişsiz ve gereksiz olacaktır. Bu gibi nesne
yürütmeleri için hazırlanan nesne adaptörü arayüzünü kullanarak, ORB’ye en etkili erişimi
sağlamak için belirli ORB çekirdeğinin detaylarından faydalanmak mümkündür.
2.7. CORBA’ya Ġhtiyaç Duyan Nesne Adaptörü
Birçok mümkün nesne adaptörü vardır; ama, nesne adaptörü arayüzü nesne
yürütmelerinin bağlı olduğu birşey olmasından dolayı, pratik olarak kullanılabileceği kadar az
olması caziptir. Nesne adaptörlerinin çoğu, nesne yürütmelerinin bir kısımını kapsamak üzere
tasarlanmışlardır. Yalnızca, bir yürütme temelden farklı servislere veya arayüzlere ihtiyaç
duyduğunda, yeni bir nesne adaptörü düşünülmelidir.
2.7.1. TaĢınabilir Nesne Adaptörü (POA – Portable Object Adapter)
Taşınabilir Nesne Adaptörü, birçok ORB nesnesi tarafından geleneksel yürütmeler ile
kullanılabilir. POA’nın amacı, adından da anlaşılabileceği gibi, farklı üreticilerin yürütmeleri
ile ilgili, minimum yeniden yazma ihtiyacı olan birçok ORB ile kullanılabilen Nesne
Adaptörü sağlamaktır.
Bu tanımlama sunucuların birkaç şekilde kullanılmasına izin verir, ama sunucu
programlarının başlatılmasının idari meseleleri ile ilgili değildir. Ama, bir defa başlatıldığında
bir tekil yöntem çağrısı için bir hizmetçi başlatılıp bitirilebilir, her nesne için ayrı bir hizmetçi
olabilir, veya nesne tipinin tüm örnekleri için paylaşılan bir hizmetçi olabilir. Bu, POA
26
nesnesinin farklı örnekleri ile kayıtlı olması vasıtasıyla nesne gruplarının ilişkilendirilmesine,
ve yürütmelerin kendi aktivasyon tekniklerini belirlemelerine izin verir. Çağrı yapıldığında
yürütme aktif değilse, POA bir tane başlatır. POA IDL’de tanımlanır, böylece dillerle
eşlenmesi, dil eşleme kurallarını takiben büyük oranda otomatiktir. (Bir dil eşlemesinden
geriye kalan temel görev, hizmetçi tipinin tanımlanmasıdır.)
2.8. Yabancı Nesne Sistemlerinin Entegrasyonu
Genel ORB Mimarisi, nesne sistemlerinin geniş bir kısmının birbirleri ile iş yapmasına
izin vermek üzere tasarlanmıştır (ġekil 2.10). Çünkü varolan birçok nesne sistemi vardır,
genel bir istek, ORB vasıtasıyla erişilebilen sistemlerdeki nesnelere izin verilmesi olacaktır.
Kendileri ORB olan nesne sistemlerinin bazı mekanizmalar sayesinde başka ORB’lere
bağlanmaları mümkündür.
ORB nesneleri ile kendi nesnelerini basitçe eşleştirmek ve ORB üzerinden çağrılar
almak isteyen nesne sistemleri için, bir yaklaşım bu nesne sistemlerinin ilgili ORB
nesnelerinin yürütmeleri olarak gösterilmesidir. Nesne sistemi nesnelerini ORB ile
kaydedecek ve gelen istekleri kabul edecektir, ve bir istemci gibi davranıp istek
gönderebilecektir.
Bazı durumlarda, başka nesne sisteminin bir POA nesne yürütmesi gibi davranması
elverişsiz olacaktır. Bir nesne adaptörü, ORB ile birleşme yerinde yaratılan ve temel olarak
ORB üzerinden çağrılabilen nesneler için tasarlanabilir. Başka bir nesne sistemi, ORB’ye
danışmadan nesneleri yaratmayı isteyebilir, ve çağrıların çoğunun ORB üzerinden
olmasındansa kendi üzerinden olmasını tercih edebilir. Bu gibi bir durumda, daha uygun bir
nesne adaptörü, nesneler ORB üzerinden geçerken tamamıyla kayıtlı olmalarına izin verebilir.
ġekil 2.10. Yabancı Nesne Sistemlerinin Entegrasyonunda Farklı Yöntemler
27
2.9. Arayüz Tanımlama Dili (IDL)
Bir istemcinin bir nesneye istek yapabilmesi için, nesne tarafından desteklenen iş
tiplerini bilmesi gerekir. Bir nesnenin arayüzü, nesnenin desteklediği tipleri ve işleri belirler,
ve böylece nesne üzerinde yapılabilecek istekleri tayin eder. Nesneler için arayüzler IDL’de
tanımlanır. Arayüzler, C++’taki sınıflarla, ve Java’daki arayüzlerle benzerdir. Bir IDL arayüz
tanımlama örneği aşağıdaki gibidir:
// OMG IDL
interface Fabrika {
Object yarat();
};
Bu tanımlama, bir işi (yarat) destekleyen Fabrika adında bir arayüzü belirtir.
yarat işi hiçbir parametre almaz ve Object tipinde bir nesne referansı döndürür.
Fabrika tipinde bir nesne için verilen bir nesne referansını, bir istemci yeni bir CORBA
nesnesini yaratmak için çağırabilir. Bu arayüz, daha önce bahsedilen Fabrika nesnelerinden
biri tarafından desteklenebilir.
IDL’nin önemli bir özelliği de dil bağımsız olmasıdır. IDL bir programlama dili değil,
bir tanımlama dili olduğundan, arayüzlerin nesne yürütmesinden bağımsız tanımlanmalarını
mecbur kılar. Bu, nesnelerin farklı programlama dilleri kullanılarak oluşturulmasına, ve buna
rağmen birbirleri ile haberleşmelerine izin verir. Dil bağımsız arayüzler, tüm programlama
dilleri tüm platformlarda bulunmadığı veya desteklenmediğinden dolayı, heterojen
sistemlerde önemlidirler.
IDL, programlama dillerinin çoğunda bulunan veri tiplerine benzer tipler ihtiva eder.
long, double ve boolean gibi temel tipler, struct, union gibi yapısal tipler, ile
sequence ve string gibi şablon tipleri içerir. Tipler, işlerin parametre tiplerini ve geri
dönüş tiplerini tayin etmek için kullanılır. Yukarıdaki örnekte görüldüğü gibi, belirli arayüz
tipini destekleyen nesneler tarafından sağlanan servisleri belirlemek için, işler arayüzlerin
(interface) içinde kullanılır. IDL, bir işin rotasında ortaya çıkabilecek istisnai durumları
belirlemek için, exception tanımlamalarını içerir. struct’lar gibi, exception’lar da
herhangi bir IDL tipinden bir yada daha çok veri üyesi içerebilirler. IDL module yapısı, isim
çakışmalarını engellemek için, tanımlama isimlerinin faaliyet alanının belirlenmesine izin
verir.
28
2.9.1. Gömülü Tipler (Built-in Types)
IDL aşağıdaki gömülü tipleri destekler:
long (signed ve unsigned) 32-bit aritmetik tipleri.
long long (signed ve unsigned) 64-bit aritmetik tipleri.
short (signed ve unsigned) 16-bit aritmetik tipleri.
float, double, ve long double IEEE 754-1985 kayan nokta tipleri
char ve wchar – karakter ve geniş karakter tipleri.
boolean – mantıksal tip.
octet – 8-bit değer.
enum – sayı tipi.
any – gömülü tipleri ve kullanıcının tanımladığı tipleri de içeren OMG IDL
tiplerinden, bir değer tutabilen ek tip.
CORBA tanımı, heterojen donanım platformları üzerinde çalışabilirliği sağlamak için,
tüm temel tiplerin büyüklüklerini kesin bir biçimde tanımlar.
2.9.2. Yapısal Tipler (Constructed Types)
OMG IDL yapısal tipleri de destekler:
struct – veri bütünleştirme yapısı (C/C++’taki struct ile benzer)
union – union tanımında belirtilen mümkün OMG IDL tiplerinden birinin bir
değeri ile, bir tip ayırıcısından oluşan tip. OMG IDL union’ları C/C++’taki
union’larla benzerdir. Fakat hangi alternatifin geçerli olduğu bilgisini de
tutarlar.
2.9.3. ġablon Tipler (Template Types)
OMG IDL, gerçek davranışı tanımlama anında tarif edilen şablon tipleri de destekler:
string ve wstring – katar (string) ve geniş-karakter katarı tipleri. Her iki tip
te, sınırlı veya sınırsız olarak tanımlanabilirler. Örneğin, 10 karakter uzunluk ile
sınırlı bir string string<10> şeklinde tanımlanırken, sınırsız olarak
tanımlamak için sadece string yazmak yeterlidir.
29
sequence – maksimum uzunluğu ve eleman tipi “< >” içinde tanımlanabilen
dinamik uzunluklu lineer bir taşıyıcıdır. Örneğin, sequence<Fabrika>,
Fabrika nesne referansının sınırsız bir serisini tanımlarken,
sequence<string,10>, 10 karakter katarından fazla olamayacak sınırlı bir
seri tanımlar.
fixed – 31 adet anlamlı rakamdan fazla olmayan sabit noktalı ondalık değer.
Örneğin fixed<5,2>, beş adet rakamda oluşur (2 tanesi ondalık), en fazla
$999.99 gösterebilecek şekilde, parasal değerler için kullanılabilir.
2.9.4. Nesne Referans Tipleri (Object Reference Types)
OMG IDL Nesne Referans Tipleri, istenilen arayüz tipini isimlendirerek kolaylıkla
tanımlanabilir. Örneğin:
// OMG IDL
interface FabrikaBulucu {
// bir Fabrika nesne referansları serisi tanımı
typedef sequence<Fabrika> FabrikaSerisi;
FabrikaSerisi fabrikalari_bul(in string
interface_name);
};
Bu OMG IDL tanımlaması, FabrikaSerisi adında bir tipin tanımını içeren,
FabrikaBulucu isimli bir arayüzü tanımlar. FabrikaSerisi tipi, Fabrika nesne
referanslarının sınırsız bir serisi olarak tanımlanır. fabrikalari_bul işi, sınırsız bir
string tipini giriş argümanı olarak alır, ve Fabrika nesne referansları serisi döndürür.
2.9.5. Arayüz Miras Alma (Interface Inheritence)
OMG IDL arayüzlerinin önemli bir özelliği, bir yada daha çok arayüzden miras
alabilmeleridir. Bu, yeni servisler tanımlandığında, varolan arayüzleri tekrar kullanmayı
mümkün kılar.
interface Fabrika { // Yukardaki OMG IDL örneği ile aynı
Object yarat();
};
30
// Dosya arayüzünün ön tanımı, tam tanımı burada yok
interface Dosya;
// FabrikaDosyasi, Fabrika’dan türetiliyor
interface FabrikaDosyasi : Fabrika {
Dosya dosya_yarat;
};
Bu örnekte, FabrikaDosyasi arayüzü Fabrika arayüzünden miras alınmıştır,
böylece FabrikaDosyasi arayüzünü destekleyen bir nesne, iki iş sağlar:
1. Fabrika’dan miras alınmış yarat işi.
2. FabrikaDosyasi arayüzünün içinde tanımlanmış dosya_yarat işi.
Arayüz miras alma CORBA’da çok önemlidir. Değişiklik için sistemi kapalı tutarken
genişleme için sistemin açık olmasına izin verir (Açık-Kapalı Prensibi). Türetilmiş bir arayüz,
tüm temel arayüzlerinde tanımlı tüm işleri miras aldığından dolayı, türetilmiş arayüzü
destekleyen nesneler tüm miras alınmış işleri de desteklemelidirler. Bu, türetilmiş arayüzler
için nesne referanslarının, temel arayüzler için nesne referanslarının kabul edildiği her yere
yedeklenebilmesine izin verir.
Örneğin, bir FabrikaDosyasi nesne referansı, bir Fabrika nesne referansının
kabul edildiği her yerde kullanılabilir, çünkü FabrikaDosyasi tüm Fabrika işlerini
destekler. Böylece FabrikaDosyasi nesnelerinin yeni yetenekleri, Fabrika arayüzünü
kullanan varolan uygulamaları veya Fabrika arayüzünün kendisini değiştirmeden sisteme
eklenebilir.
OMG IDL arayüz miras almanın özel bir durumuna sahiptir: tüm arayüzler, tamamıyla
CORBA modülünde tanımlı Object arayüzünden türetilmiştir. Tüm arayüz tanımlamaları
aşağıdaki gibidir:
// CORBA::Object tüm arayüzler için temel arayüzdür
interface Fabrika : Object { ... };
CORBA::Object’ten alınan bu miras tüm OMG IDL arayüzleri için otomatik
olduğundan, burada görüldüğü gibi açıkça tanımlanmasına gerek yoktur.
31
OMG IDL tip sistemi birçok dağıtık uygulama için yeterlidir, ve aynı zamanda
minimaldir ve bu düzeyde tutulmaya devam edilmektedir. OMG IDL’yi olabildiğince basit
tutmak demek, onun çok daha fazla programlama dili ile kullanılabilmesi demektir. Bazı
programlama dillerinde gerçeklenemeyecek tipleri içerseydi bu dillerle kullanılamazdı. OMG
IDL’nin basitliği CORBA’nın entegrasyon teknolojisindeki başarısında önemli rol oynar.
2.10. Dil EĢlemeleri
Daha önce de bahsettiğimiz gibi, OMG IDL tam olgunlaşmış bir programlama dili
değil, sadece tanımsal bir dildir. Böyle olunca, kontrol yapıları gibi özellikleri ihtiva etmez,
dağıtık uygulamaların yürütülmesinde direkt olarak kullanılamaz. Dil eşlemeleri, OMG IDL
özelliklerinin verilen bir programlama dilinin imkanları ile nasıl eşleneceğini belirler.
Bir dil eşlemesinin neleri içerdiğini anlamak için, C++ dili için eşlemeyi göz önüne
alalım. OMG IDL arayüzleri C++ sınıfları ile, bu sınıfların üye fonksiyonları ile işlerin
eşlenmesi yoluyla eşlenir. Nesne referansları operator-> fonksiyonunu destekleyen
nesnelerle eşlenir (örn., arayüz sınıfına normal bir C++ işaretçisi (pointer), veya bir
overloaded operator-> ile nesne örneği). Module’ler C++ namespace’leri ile eşlenir
(veya henüz namespace’leri desteklemeyen, C++ derleyicileri için iç içe geçmiş (nested)
sınıflarla). OMG IDL tiplerinin geri kalanı ile eşlemeler Tablo 2.1’de gösterilmiştir.
OMG IDL Tipi 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
32
OMG IDL dilinin CORBA tanımında bulunan ORB arayüzü ve diğer sahte-nesneler
(pseudo-objects) ile nasıl eşlendiği de başka bir önemli noktadır. Sahte-nesneler tamamen
CORBA::Object’ten türetilmemiş ORB arayüzleridir. Başka bir deyişle, sahte-nesneler
gerçek CORBA nesneleri değildirler. Ama bu arayüzleri normal nesne arayüzleri gibi
tanımlamak, uygulamaların normal nesneleri idare eder gibi ORB’yi de idare etmesine izin
verir. CORBA’nın yeni sürümlerinde, sahte-nesneler yavaş yavaş elimine edilmekte, ve tüm
CORBA arayüzleri normal OMG IDL’de tanımlanmaktadırlar.
CORBA nesnelerinin dil içinde nasıl yürütüldükleri de önemlidir. Java, Smalltalk ve
C++ gibi nesneye yönelik dillerde, CORBA nesneleri programlama dili nesneleri gibi
yürütülürler. C’de ise, nesneler soyut veri tipleri olarak yazılırlar. Örneğin, tipik bir yürütme,
nesnenin durumunu tutan bir struct ile bu durumu idare eden bir grup C fonksiyonundan
(nesne tarafından desteklenen OMG işleri ile ilgili olan fonksiyonlar) oluşur.
OMG IDL dil eşlemeleri, yürütmenin “gerçek dünyası” ile CORBA’da tanımlanan
kavramların buluşma noktasında yer alır. Bu yüzden CORBA uygulamalarındaki önemleri
göz ardı edilemez. Verilen bir dil için zayıf veya yarım kalmış bir eşleme tanımlaması,
programcıların CORBA teknolojisini bu dilde verimli bir şekilde kullanmalarını imkansız
kılar. Dil eşleme tanımlamaları, yeni uygulamalar yazıldıkça ortaya çıkan yeni ihtiyaçları
yerine getiren özellikleri eklemek gibi, programlama dillerinin evrimi ile birlikte, periyodik
olarak ilerlemelidirler.
2.11. Arayüz Ambarı
Her CORBA-tabanlı uygulama çalıştırıldığı zaman OMG IDL tip sistemine erişmeye
ihtiyaç duyarlar. Bu gereklidir, çünkü uygulama istenilen argümanlar olarak geçirilecek
değerlerin tiplerini bilmek zorundadır. Uygulama, kullanılan nesneler tarafından desteklenen
arayüzlerin tipini de bilmek zorundadır.
Birçok uygulama, sadece OMG IDL tip sisteminin statik bilgisine ihtiyaç duyar. Tipik
olarak, bir OMG IDL tanımlaması uygulamanın programlama dilinde derlenir, veya kendi dil
eşlemesi tarafından tanımlandığı gibi, bu dil için dönüştürme kurallarını takip ederek
dönüştürülür. Daha sonra, oluşturulan bu kod uygulamanın içine direkt olarak yerleştirilir. Bu
yaklaşımla, uygulamanın OMG IDL tip sistemi bilgisi kurulduğu anda sabitlenir. Eğer dağıtık
sistemin geri kalanının tip sistemi uygulamaya yerleştirilen tip sistemine uyumsuz bir biçimde
değişirse, uygulama yeniden yapılandırılmalıdır (rebuilt). Örneğin, bir istemci uygulaması
Fabrika arayüzüne bağlı ise, ve Fabrika arayüzündeki yarat işinin ismi
33
fabrika_yarat olarak değiştirilirse, uygulama herhangi bir Fabrika nesnesine istek
yapmadan önce yeniden yapılandırılmalıdır.
Bununla beraber, OMG IDL tip sisteminin statik bilgisinin elverişsiz olduğu
uygulamalar da vardır. Örneğin, bir yabancı nesne sistemindeki uygulamaların (Microsoft
Component Object Model uygulamaları gibi) CORBA nesnelerine erişmelerine izin veren bir
Geçit (Gateway) düşünelim. Birileri sisteme yeni bir OMG IDL arayüz tipi ekledikçe geçidi
yeniden derlemek ve yeniden yapılandırmak, çok büyük bir idare ve bakım problemi yaratır.
Bunun yerine, geçidin tip bilgisini gerekli oldukça dinamik olarak bulması ve istifade etmesi
daha iyi olacaktır.
CORBA Arayüz Ambarı (IR – Interface Repository), OMG IDL tip sistemine çalışma
zamanında erişilmesine izin verir. IR’ın kendisi, diğer CORBA nesnelerinde olduğu gibi işleri
çağrılabilen bir CORBA nesnesidir. IR arayüzünü kullanarak, uygulamalar OMG IDL
bilgisinin tüm hiyerarşisini tarayabilirler. Örneğin, bir uygulama IR’ın üst düzey sahasından
başlayıp orada tanımlanmış tüm module tanımlamalarını tarayabilir. Aranan module
bulunduğunda, onu açabilir ve benzer bir biçimde içindeki tüm tanımlamalar üzerinde tarama
yapabilir. Bu hiyerarşik arama yaklaşımı, bir IR içinde saklanan tüm bilgileri bulmak için
kullanılabilir.
IR bilgisine erişmek için başka (ve muhtemelen daha verimli) bir yol,
CORBA::Object arayüzünde tanımlanmış get_interface işinden InterfaceDef
nesne referansını elde etmektir. Tüm arayüzler CORBA::Object’ten türetildikleri için, tüm
nesneler get_interface işini destekler. Bunun için, InterfaceDef nesne referansı her
nesneden, o nesne tarafından desteklenen arayüzlerin türetilmiş tiplerini bilmeye gerek
olmadan da, elde edilebilir.
Uygulamaların tip bilgisini çalışma zamanında araştırmalarına izin vermesi sayesinde,
IR’ın gerçek faydası CORBA dinamik çağrısını desteklemesinin altında yatar. Aynı zamanda,
IR’daki OMG IDL tanımlamaları, OMG IDL dosyasında yazılanlar ile aynı olduğundan,
uygulamalar için statik destek kodu oluşturmada bir kaynak olarak kullanılabilir.
2.12. CORBA’nın Bugünü ve Yarını
2.12.1. MDA – Model Driven Architecture
MDA (Model Güdümlü Mimari) OMA’nın geliştirilmesi ile oluşturulmuştur. MDA,
UML (Unified Modeling Language – Birleştirilmiş Modelleme Dili), MOF (Meta-Object
34
Facility – Meta-Nesne Vasıtası), ve CWM (Common Warehouse Meta-model – Genel Depo
Meta-modeli) gibi OMG’nin geliştirdiği modelleme standartlarını biraraya getirmektedir. Bu
modelleme standartları kullanılarak yapılmış platform bağımsız uygulama tanımları, CORBA,
Java, .NET, XMI/XML ve Web-tabanlı platformlar gibi, herhangi bir açık veya özel platform
kullanılarak gerçeklenebilmektedir.
2.12.1.1. UML – Unified Modeling Language
UML, yazılım sistemlerinin olduğu kadar iş modellerinin ve diğer sistemlerin de
yapısını tanımlamak, canlandırmak, yapılandırmak ve belgelemek için geliştirilmiş bir dildir.
Büyük ve karmaşık sistemlerin modellenmesinde başarılılığı ispatlanmış en iyi mühendislik
pratiklerinin bir koleksiyonunu sunar.
UML, National Software ve ortakları tarafından geliştirilmiştir. Birçok firma, iş
modelleme, ihtiyaç yönetimi, analiz & tasarım, programlama ve test etme gibi disiplinleri
kapsayan ürünlerini geliştirirken UML’yi bir standart olarak kullanırlar.
2.12.1.2. MOF – Meta-Object Facility
MOF, OMG’nin tüm modelleme özellikleri için genel bir meta-model tanımlayarak,
türetilmiş özelliklerin doğal bir biçimde bir arada çalışmasına izin verir. MOF aynı zamanda
meta-modeller, ve dolayısıyla da modeller için (bir meta-model bir modelin özel bir durumu
olduğu için) standart bir ambar tanımlar.
2.12.1.3. CWM – Common Warehouse Meta-model
CWM, bir şirket içindeki veya daha uzaktaki veritabanı sınırları içinde veriyi bulup
getirmeye izin veren tamamlanmış geniş kapsamlı bir meta-model standardı sunar. OMG ve
MDC (Meta-Data Coalition) ortak çalışmasının bir ürünü olan CWM, UML’nin uygulama
modeli için yaptığını veritabanı modeli için yapar da diyebiliriz.
2.12.2. CORBA 3
2001’de duyrulan ve 2002’de tanımlamalarının yayınlanması beklenen CORBA 3 ile
getirilmesi düşünülen yenilikleri üç temel kategoride ele alabiliriz.
2.12.2.1. Java ve Internet Entegrasyonu
1. CORBA 2.3’ten beri varolan nesnelerin değer olarak geçirilebilmesi özelliği
geliştirilecek.
35
2. Java-to-IDL eşlemesi sayesinde, Java RMI nesneleri ağ üzerinde CORBA
nesneleri gibi çalışabilecekler, CORBA nesne referansları olacak, ve IIOP protokolünü
kullanacaklar. Yani uygulamalarda CORBA bileşenlerinin ve EJB’lerin (Enterprise Java
Beans) kütüphanelerinin beraber çalışabilmesi sağlanacak.
3. Nesne referansları URL biçiminde tanımlanabilecek. Bu özelliği sağlayan
Interoperable Name Service 2000’in sonlarına doğru çıkan CORBA 2.4’te de vardı.
4. CORBA’nın firewall’lardan güvenli bir biçimde geçebilmesi için gerekli
yetenekler arttırılacak.
2.12.2.2. Servis Kalitesi Kontrolü
1. Yeni mesaj gönderme özelliği, CORBA için hem statik hem de dinamik olarak
çağrılabilecek birçok zaman-bağımlı ve asenkron çağrı biçimleri tanımlamıştır. Politikalar
çağrıların servis kalitesinin kontrolüne izin verirler. Bu özellik te 2.4 sürümünde eklenmiştir.
2. Yine 2.4 sürümünde eklenmiş olan minimumCORBA, gömülü ve kart tabanlı
sistemlerde kullanılmak üzere tasarlanmıştır. Bu sistemler yongalar üzerinde yer aldıkları ve
güncellenmedikleri için CORBA’nın dinamik özelliklerine ihtiyaç duymazlar. Bu sebepten,
Dinamik Çağrı Arayüzü ve Arayüz Ambarı gibi özellikler minimumCORBA’da yer almazlar.
3. Yine 2.4 sürümünde eklenmiş olan Gerçek-zamanlı CORBA, kaynak kontrol
thread’leri, protokoller, bağlantılar, ve bunlar gibi şeyleri öncelik modelleri kullanarak
standartlaştırır.
4. Henüz eklenmemiş olan hata toleranslı CORBA, yazılım konfigürasyonlarını ve
sistemlerini standartlaştırarak daha fazla güvenilirlik ve daha sağlam performans sağlayacak.
2.12.2.3. CORBAcomponents Mimarisi
1. OMG’nin CORBA 2 için geliştirdiği IIOP’den sonra yaptığı en önemli
gelişmelerden biri olan CORBAcomponents, hareketlilik, güvenlik ve devamlılığı paketleyen,
ve arayüz ile olay çözümü sağlayan bir taşıyıcı ortam içerecek. Bunun yanında,
CORBAcomponent yazılım pazarına imkan verecek bir yazılım yayımlama biçimi, ve EJB ile
entegrasyonu da içerecek. Bir kurulum ve XML-tabanlı konfigürasyon aracı da içerecek.
2. Script diller CORBA istemci ve nesnelerine erişebilecekler. Şu anda biri Python
diğeri de CORBA-özel script dili olmak üzere iki script dili desteklenmektedir.
36
5.12.3. CORBA Yürütmeleri
OMG gerçek yazılım üretmez, sadece ayrıntılı tanımlar üretir. CORBA yürütmelerini,
OMG’ye üye olan veya olmayan yazılım üreticileri, OMG’nin tanımladığı standartlar
doğrultusunda üretirler.
OMG bugüne kadar CORBA için, Ada, C, C++, COBOL, CORBA Scripting
Language, Java, Lisp, Python ve Smalltalk dillerine yönelik dil eşlemeleri tanımları
oluşturmuştur. Bu dil eşlemelerini kullanarak, üreticiler Windows’ta ve diğer platformlarda
çalışan CORBA yürütmeleri gerçekleştirmişlerdir. Bu yürütmelerden bazıları Tablo 2.2’de
verilmiştir. Orbix ve ORBacus yürütmelerinin destekledikleri platformlar ve derleyiciler de
örnek teşkil etmesi açısından Tablo 2.3 ve Tablo 2.4’te gösterilmiştir.
Tablo 2.2. CORBA Yürütmeleri
İşletim Sistemi Derleyici
Windows NT4 (SP6a) C6.0 (SP3) & JDK 1.3
Windows 2000 VC6.0 (SP3) & JDK 1.3
Windows 98 2nd Edition (Client only) VC6.0 (SP3) & JDK 1.3
Linux RedHat 6.2 GCC 2.95.2 & JDK 1.3
Solaris 2.6 (SunOS 5.6) Sun C++ 5.2 (Forte 6.1) & JDK 1.3
Solaris 2.6 GCC 2.95.2
Solaris 2.8 (SunOS 5.8) 32 & 64 bit Sun C++ 5.2 (Forte 6.1) & JDK 1.3
HP-UX 11.0 - 32 & 64 bit HP ANSI C++ aCC A03.25 & JDK 1.3
HP-UX 11i - 32 bit HP ANSI C++ aCC A03.25 & JDK 1.3
AIX 4.3.3 Visual Age 5.0 & JDK 1.3
Compaq Tru64 5.1 Compaq C++ 6.2 & JDK 1.3
Tablo 2.3. ORBIX’in Desteklediği Platformlar ve Derleyiciler
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
Supérieure des Télécommunications in Paris, France. Ücretsiz Ada
37
İşletim Sistemi Derleyici
Solaris 2.6/7/8 Forte C++ 6 Update 2
Solaris 2.6/7/8 GCC 2.95.3
HP-UX 11 HP ANSI C++ A.03.27
Windows NT/2000 Visual C++ 6.0
Linux GCC 2.95.3
Compaq Tru64 5.1 C++ 6.2 (024)
AIX 4.3.x VA C++ 5.0 with 5.0.0.2 PTF
Solaris 2.6/7/8 JDK 1.3
HP-UX 11 JDK 1.3
Windows NT/2000 JDK 1.3
Linux JDK 1.3
Compaq Tru64 5.1 JDK 1.3
AIX 4.3.x JDK 1.3
SGI IRIX 6.5 JDK 1.3
Tablo 2.4. ORBacus’ün Desteklediği Platformlar ve Derleyiciler
38
3. DCOM
DCOM, OLE’nin ve ActiveX’in altyapısını oluşturan COM (Component Object
Model)’dan geliştirilerek oluşturulmuştur. COM, yazılım bileşenlerini geliştirmek ve yaymak
amacıyla kullanılan nesne tabanlı bir çatıdır. COM, geliştiricilerin soyutlamaları bileşen
arayüzleri olarak elde etmelerine izin verir, ve bu arayüzleri yürüten sınıfları sağlar. İstemci
uygulamaları sadece bir nesnenin arayüzünde tanımlı olan fonksiyonları çağırabilirler
(encapsulation).
COM’un ikili birlikte çalışabilirlik (binary interoperability) standardı, yazılım
bileşenlerinin geliştirilmesini ve bu bileşenlerin ikili (binary) biçimde yayılmasını sağlar.
Sonuç olarak bağımsız yazılım geliştiriciler, tekrar kullanılabilen yapı bloklarını geliştirebilir
ve kaynak kodunu taşımadan paketleyebilirler.
DCOM (Distributed COM), uzak yöntem çağrıları, güvenilirlik, ölçeklenebilirlik ve
yer şeffaflığı sağlayarak, COM’un ağ üzerinde çalışmasını sağlamıştır. DCOM’un COM’u ne
yönden geliştirerek ağ üzerinde çalışmasını sağladığını anlatmadan önce, COM mimarisinin
temellerine biraz değinelim.
3.1. COM – Component Object Model
COM, farklı zamanlarda, farklı üreticilerin, çeşitli diller, araçlar ve platformlar
kullanarak oluşturdukları yazılım bileşenlerinin geliştirilmesine izin vermek üzere
tasarlanmış, bir nesne-tabanlı programlama modelidir. COM bileşenleri kolaylıkla yayılabilir
ve müşterinin sistemine entegre edilebilir.
3.1.1. Arayüzler
Bir COM arayüzü, bir yazılım bileşeninin davranışlarını ve yeteneklerini, bir
yöntemler ve özellikler kümesi olarak tanımlar. Bir arayüz, onu destekleyen nesnelerden
anlamsal olarak tutarlı bilgileri alacağını garanti altına alan bir anlaşmadır. Her COM nesnesi
birden çok arayüzü aynı anda destekleyebilir. Nesneler en az bir arayüzü (IUnknown
arayüzü) mutlaka desteklemelidirler.
Bileşen tasarımcıları arayüzleri DCE RPC IDL’nin nesneye-yönelik olacak şekilde
geliştirilmiş hali olan MIDL (Microsoft's Interface Definition Language) kullanarak
tanımlarlar. Microsoft, bir arayüz tanımından C veya C++ dillerinde proxy ve stub kodu
oluşturan bir MIDL derleyicisi sağlar. Oluşturulan proxy kodu, arayüzü destekleyen nesneler
39
için, bir istemci tarafı uygulama programlama arayüzü (API – Application Programming
Interface) sağlar. Stub nesneleri gelen istemci isteklerinin şifresini çözer (decode) ve
sunucudaki ilgili nesneye bunları iletirler. Arka planda, istekleri ve cevapları değerlendirmek
için proxy ve stub kodları ilgili çalışma zamanı kütüphanelerle etkileşime girerler. COM
çalışma zamanı yazılımı, nesneler istemci ile aynı işlemde bulunuyorsa, bu fazladan işi
yapmayacak kadar akıllıdır.
Bileşen tasarımcıları, her arayüze, her zaman ve her yerde tek olan bir belirleyici
(UUID – Universally Unique Identifier) atayarak, isim çakışmalarından doğabilecek
belirsizlikleri ortadan kaldırırlar. Arayüz belirleyicisi (IID – Interface Identifier) olarak
adlandırılan bu belirleyici, aynı zamanda COM’un arayüz uyarlama modelinin temel taşıdır.
Her COM nesnesinin en azından IUnknown standart arayüzünü desteklemesi
gerektiğini söylemiştik. IUnknown, nesne yaşam döngüsünün yönetilmesi için temel yapı
bloklarını sağlayan, ve bir nesne tarafından desteklenen arayüzlerin gelişimine izin veren
yöntemleri tanımlar.
IUnknown arayüzünün QueryInterface yöntemi, bir IID olarak tanımlanan
belirli bir arayüzün bir nesne tarafından desteklenip desteklemediğini belirlemek için
istemciler tarafından kullanılır. Zamanla, bir nesne yeni arayüzleri veya her birinin farklı
IID’si olan aynı mantıksal arayüzün yeni sürümlerini destekleyebilir. Varolan istemciler,
yeniden derlenmeden bir arayüzün daha eski bir sürümünü kullanmaya devam edebilirler, ve
yeni istemciler arayüzün son sürümünü sorgulayabilir ve bu sayede eklenen yeniliklerden
faydalanabilirler.
QueryInterface, arayüz işaretçisi (interface pointer) denilen bir işaretçi döndürür.
Arkaplanda, bir arayüz işaretçisi COM’un ikili birlikte çalışabilirlik standardı tarafından dikte
ettirilen bir veri yapısına işaret eder. Standart, istemci ve sunucu programlarının yürütme
bileşenleri arasındaki farkları önemsemeden, çağrılması gereken yön arayüz fonksiyonlarını
dikte eder.
3.1.2. Sınıflar ve Sunucular
Arayüzler kendi başlarına COM uygulamaları oluşturmak için yeterli değildirler. Bir
COM sınıfı, bir yada daha çok COM arayüzünün bir yürütmesi olan bir kaynak kodunun
gövdesidir. Desteklediği her arayüz yöntemi için, desteklenen herhangi bir programlama
dilinde, gerçek fonksiyonlar sağlar.
40
Her arayüz bir IID tarafından tekil olarak tanımlandığından, her COM sınıfı CLSID
adı verilen bir tekil belirleyici ihtiva eder. Bir istemci uygulamanın, bir bileşenle etkileşime
girmesi için, en az bir CLSID ve bu sınıf tarafından desteklenen arayüz için bir IID hakkında
bilgi sahibi olması veya öğrenebilecek konumda olması gerekmektedir. Bir istemci bu bilgiyi
kullanarak, bir nesne üretmek ve bir ilgili arayüz işaretçisi döndürmek için COM’dan izin
ister.
Bir yada daha çok COM sınıfı, kullanılabilecek çeşitli tekniklerden biri kullanılarak
bir sunucunun içine yerleştirilir. Sunucunun içindeki bir sınıfa bir istemci tarafından ilk kez
erişildiğinde, bir COM sunucusu istemci işleminde yüklenen bir dinamik bağlantı kütüphanesi
(DLL – dynamic link library) olarak paketlenebilir. Buna, işlem içi sunucu (in-process server)
denir. ActiveX kontrolü, bir işlem içi COM sunucusudur. Bir COM sunucusu ayrı ayrı
çalışabilecek şekilde de paketlenebilir. Bu tip bir sunucu, bir istemci ile aynı makinede veya
DCOM kullanılarak erişilebilen uzak bir makinede yürütülebilir. Bu sunuculara, işlem dışı
sunucular (out-of-process server) denir. Aynı istemci kodu, farklı COM sunucu tipleri ile
etkileşebilir.
ġ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
İstemci İşlemi
Uzak Makine
Yerel Sunucu İşlemi
İstemci Uygulama
İşlem-içi Sunucu
COM
İşlem-içi Nesne
İşlem-içi Nesne Yerel
Nesne
COM
Stub
Uzak Sunucu İşlemi
Yerel Nesne
COM
Stub
Yerel Nesne Proxy
Yerel Nesne Proxy
Uzak Nesne Proxy
Uzak Nesne Proxy
41
nesnesine gönderir. ġekil 3.1, farklı biçimlerde paketlenmiş COM nesneleri ile etkileşime
giren bir COM nesnesini gösteriyor.
ġekil 3.1’de görüldüğü gibi, DCOM yer ve paketleme şeffaflığı sağlar. Bir nesne,
işlem içi, yerel makinede işlem dışı, veya uzak bir makinede işlem dışı olabilir. İşlem dışı
sunucular söz konusu olduğunda, DCOM arayüze-özel proxy ve stub kodu (tipik olarak bir
IDL dosyasından oluşturulur) ile bir RPC mekanizması kullanır.
3.1.3. Nesne YaĢam Döngüsü
Arayüz ve sınıf kavramları, ve COM istemcisi ile sunucusu arasındaki haberleşme
konuları hakkında fikir edindikten sonra, şimdi de bir istemcinin, bir COM nesnesini nasıl
oluşturduğunu inceleyelim. Her COM nesnesi bir COM sınıfının bir örneğidir. Her COM
sınıfı, görevi bir COM sınıfının örneklerini oluşturmak olan, sınıf fabrikası denilen başka bir
COM sınıfı ile ilişkilidir. COM’un fabrika mekanizması ġekil 3.2’de gösterilmiştir. Fabrika
tipik olarak, COM tarafından tanımlanmış standart bir arayüz olan IClassFactory’i
destekler. Verilen bir CLSID ve ilgili COM sunucusunun bir tanımı ile, COM çalışma-zamanı
(run-time) verilen CLSID için bir fabrika tayin edebilir.
ġ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.
İstemciNesne
Sınıf Fabrikası
Sunucu
COM
2. Sunucuyu Bul3. DLL’i yükle veya EXE’yi çalıştır4. Sınıf Fabrikasını elde et5. Fabrikadan yaratma izni al
1. Bir nesne yarat
*6. İstekleri direkt olarak çağır
42
ġekil 3.3. Arayüzler, Sınıflar ve Nesneler
ġekil 3.3’te görüldüğü gibi, bir COM arayüzü, ilgili yöntemler kümesini tanımlar, ve
tekil bir arayüz belirleyicisine atanır. Bir COM sınıfı, bir yada daha çok arayüzü yürütür, ve
tekil bir sınıf belirleyicisine atanır. Her COM sınıfı, COM nesneleri yaratmaktan sorumlu olan
bir sınıf fabrikasına sahiptir.
Bir COM nesnesi oluşturulduğunda, COM bir nesneye doğru ne kadar önemli referans
bulunduğunu, ve bu nesnenin ne zaman yok edilebileceğini takip etmek için standart bir
protokol belirler. COM nesneleri, IUnknown arayüzünde tanımlanan AddRef ve Release
yöntemleri ile işletilen bir referans sayısı muhafaza eder. Her COM sınıfı, örneklerinin
varolan kullanımlarının sayısını takip etmek için bu yöntemleri yürütmelidir. Geliştiricinin
tercihine bağlı olarak bu referans takibi, nesnenin tümü için tek bir sayı ile yapılabileceği gibi,
nesnenin desteklediği her arayüz için ayrı sayılar ile de yapılabilir.
Referans sayısı sıfır olduğunda, bu nesneye işaret eden herhangi bir istemci kalmadığı,
ve bu yüzden artık yok edilebileceği kabul edilir. QueryInterface’in de aralarında
bulunduğu arayüz işaretçileri döndüren yöntemler, bir nesneye yeni bir referans belirtmek için
AddRef’i çağırmalıdırlar. Arayüz işaretçileri kullanan istemciler, arayüz işaretçisine
erişimlerini tamamladıklarında Release’i çağırmalıdırlar.
3.1.4. Ġkili Birlikte ÇalıĢabilirlik (Binary Interoperability)
COM’un ana teması bileşenlerin birbirleri ile çalışabilmeleridir. Buraya kadar, COM
tüm yöntem çağrımları için arama yığınının (call stack) planını dikte eden bir ikili arama
standardı tanımlamıştır. DCOM bu birlikte çalışabilirliği, bir ağ birlikte çalışabilirlik
Motor Fabrikası
Nesneler
IUnknown
QueryInterface()
AddRef()
Release()
IMotor
Baslat()
Durdur()
Ayarla()
BenzinEkle()
TipiniAl()
HızıDegistir()
Motor Sınıfı
Iunknown Yürütmesi
IMotor Yürütmesi
SınıflarArayüzler
Mirasların Alınması
Yürütmeler
Yaratımlar
motor_1
IMotor
IUnknown motor_1
IMotor
IUnknown motor_2
IMotor
IUnknown motor_2
IMotor
IUnknown
43
protokolü tanımlayarak büyütür. Bu birlikte çalışabilirlik tanımlamaları, geliştiricilerin farklı
istemci ortamları için özelleştirme yapmalarına gerek bırakmadan, sadece bileşenlerin
yapılandırılması ile ilgilenmelerini sağlar. İkili standart, kaynak koduna erişim olmadan hazır
bileşenlerin kullanılmasını kolaylaştırır.
İkili standart, bir arayüz işaretçisini, bir fonksiyon tablosuna doğru bir işaretçiye işaret
eden bir işaretçi gibi tanımlar. İşlem içi sunucular için, fonksiyon tablosu gerçek nesne
yürütme fonksiyonlarına işaret eder. İşlem dışı sunucular için, fonksiyon tablosu proxy
fonksiyonlarına işaret eder.
3.1.5. Paketleme ġeffaflığı
COM mimarisinin temel özelliklerinden biri paketleme şeffaflığıdır. Geliştiriciler
nesneleri DLL veya EXE olarak yayabilirler. COM istemci uygulamaları bir sunucunun nasıl
paketlendiği ile veya DLL’inin veya EXE’sinin nerede olduğu ile ilgilenmek zorunda
değildirler. Bunun yerine, uygulama istenilen bir CLSID’ye dayandırılan nesneleri yaratmak
için COM’u kullanır. İstemci sunucu çeşitlerini sınırlayabilir, ama bunu yapmaya ihtiyacı
yoktur. İşlem içi sunucular ile etkileşimli olan istemci kodu, işlem dışı sunucular ile de
etkileşime girebilir.
COM kütüphanesi istenilen bir sınıfın yürütmesine konumlanır ve istemci ile sunucu
arasında bir iletişim kurar. COM, COM sınıflarının geliştiricilerinin sunucunun tipi
hakkındaki bilgileri ve DLL’inin veya yerel bir kayıttaki EXE’nin yerini kayıt etmelerine
ihtiyaç duyarak, bu servisi teklif eder.
COM’un Servis Kontrol Yöneticisi (SCM – Service Control Manager)’nin görevi,
kayıtlardan CLSID’yi aramak, ve sunucuyu aktif hale getirmek için ilgili faaliyeti yerine
getirmektir. Geliştiriciler SCM ile direkt olarak etkileşimde bulunmazlar; bunun yerine, COM
kütüphanesi bir nesne yaratılacağı veya bir sınıf fabrikası bulunacağı zaman SCM’yi kullanır.
3.2. DCOM – Distributed Component Object Model
Dağıtık COM, COM tarafından duyurulan programlama modelini ağ üzerinden
çalışabilecek şekilde geliştirmiştir. Bu geliştirmelerin içinde daha fazla yer ve paketleme
şeffaflığı, ek threading modelleri, yeni güvenlik seçenekleri, ve ek yönetimsel yetenekler
vardır. Önce DCOM’un COM’u nasıl geliştirdiğini şekiller üzerinde inceleyecek, sonra da bu
geliştirmelere kısaca değineceğiz.
44
COM, bileşenlerin ve istemcilerinin nasıl etkileşeceğini tanımlar. Bu etkileşim,
istemci ve bileşenin, hiçbir ara sistem bileşenine ihtiyaç duymadan haberleşebilecekleri
şekilde tanımlanır. İstemcinin bileşendeki yöntemleri doğrudan çağırması ġekil 3.4’te
gösterilmiştir.
Günümüz işletim sistemlerinde, işlemler birbirlerinden ayrı şekilde muhafaza
edilirler. Başka bir işlemdeki bir bileşenle haberleşmek isteyen bir istemci, bileşeni direkt
olarak değil de, işletim sistemi tarafından sağlanan bazı ara işlemleri kullanarak çağırır. COM
bu haberleşmeyi tamamen şeffaf bir biçimde sağlar. İstemci çağrılarının yolunu keserek,
onları başka bir işlemdeki bileşene gönderir. COM/DCOM çalışma zamanı kütüphanelerinin
istemci ve bileşen arasındaki bağlantıyı nasıl sağladıkları ġekil 3.5’te gösterilmiştir.
İstemci ve bileşen farklı makinelerde yer aldıklarında, DCOM’un yaptığı iş, yerel
birlikte çalışabilirlik haberleşmesini bir ağ protokolü ile değiştirmektir. Ne istemci ne de
bileşen, aralarındaki bağlantıyı kuran telin biraz daha uzun olduğundan haberdar olmazlar.
ġekil 3.6, DCOM mimarisini ana hatlarıyla gösterir. COM çalışma zamanı, istemcilere
ve bileşenlere nesneye yönelik servisler sağlar, ve DCOM protokol standardına uyan standart
ağ paketleri oluşturmak için, RPC ve güvenlik sağlayıcıyı kullanır.
3.2.1. Yer ve Paketleme ġeffaflığı
COM ile, istemci uygulamaları sunucunun paketlenmesinden bağımsız olarak yazılır.
COM nesneleri istemci işlemine yüklenebilir veya aynı makinede ayrı bir işlemde
başlatılabilir. DCOM, nesnelerin ağda herhangi bir yerde olmalarına izin vererek yer şeffaflığı
sağlamak için, bu şeffaflığı geliştirmiştir.
DCOM “Nesne RPC” (ORPC – Object RPC)’si DCE RPC’yi temel alır. Bir nesne
referans veri tipi içererek ve hedef nesne için her çağrımda bir parametre ekleyerek RPC’yi
geliştirmiştir. Bir istemci, uzak nesne için bir COM sınıf fabrikasına başvurduğunda, yerel
SCM uzak makinedeki SCM ile bağlantı kurar. Uzak SCM sunucuyu yerleştirir ve onu
başlatır, ve sunucu tarafından sağlanan istenilen sınıf fabrikasına bir RPC bağlantısı döndürür.
İstemci uygulaması için bir sınıf fabrikası proxy’si yaratılır, ve nesne yaratılması dağıtık
olmayan durumda olduğu gibi devam eder. Önceki şeklimize SCM’nin görevini de eklersek,
DCOM Mimarisi’nin daha ayrıntılı bir görünümünü elde etmiş oluruz (ġekil 3.7).
45
ġekil 3.4. Aynı işlemdeki COM bileşenleri
ġekil 3.5. Farklı işlemlerdeki COM bileşenleri
ġekil 3.6. Farklı makinelerdeki COM bileşenleri (DCOM)
ġekil 3.7. DCOM Mimarisi
İstemciNense
(Bileşen)
İstemciProxy Nesne
Stub
Güvenlik Sağlayıcı
DCE RPC
LPC
Güvenlik Sağlayıcı
DCE RPC
LPC
Nense (Bileşen)
CoCreateInstance
İstemci BileşenProxy Nesne
Stub
Güvenlik Sağlayıcı
DCE RPC
Protokol Yığını
Güvenlik Sağlayıcı
DCE RPC
Protokol Yığını
DCOM
Ağ Protokolü
DCOM
Ağ Protokolü
SCM SCM
OLE32
CoCreateInstance
(Remote) Activation
İstemci BileşenProxy Nesne
Stub
Güvenlik Sağlayıcı
DCE RPC
Protokol Yığını
Güvenlik Sağlayıcı
DCE RPC
Protokol Yığını
DCOM
Ağ Protokolü
DCOM
Ağ Protokolü
46
İlgili yönetimsel ayarlar ile, istemciler ağ için özel kodlamalar olmadan uzak
makinelerdeki DCOM nesnelerine erişebilirler. Bir yönetici, performans ve ayarlanabilirlikten
en iyi şekilde istifade etmek için, çeşitli sunucu paketleme ve yerleştirme seçeneklerini
deneyebilir. Alternatif olarak, istemciler yeni bir DCOM nesnesi yaratılırken erişilmesi
gereken uzak ana bilgisayarı belirleyebilirler. Bu girdi, son kullanıcı tarafından kontrol edilen
uygulama seçeneklerinden gelebilir.
DCOM ile duyurulan başka bir paketleme seçeneği de, bir DCOM sunucusunu bir NT
Servisi olarak yayabilme becerisidir. Bu yetenek, belirli bir sunucu makinesi çalıştığında
sunucuyu idare etmek için ihtiyaç duyulan tutarlı ve elverişli bir mekanizma sağlar.
3.2.2. Serbest Threading Modeli
Birçok faktör dağıtık nesne sistemlerinin ayarlanabilirliğini etkileyebilir. Tek
makinede en yüksek verime ulaşmak için, geliştiriciler multithreaded sunucular kurmaya
ihtiyaç duymuşlardır. Bu tip nesne eşzamanlılığı, sunucunun bir çok işlemcili sunucu
makinesinin gücünde olmasına olanak sağlar. Önceden de belirttiğimiz gibi DCOM, sunucu
paketleme modellerinden birindeki multithreaded sunucuların gelişimi için COM’un verdiği
desteği geliştirmiştir.
DCOM’un Windows NT 4.0 üzerinde standart olarak kullanılmaya başlanmasından
önce, multithreaded COM sunucular, apartman modeli threading olarak adlandırılan bir
threading biçimi ile sınırlandırılmışlardı. Bu model, her COM nesnesini, sadece o nesneyi
yaratan tek bir thread tarafından erişilebilmesi ile sınırlıyordu. Windows NT 4.0 serbest
threading adında bir eşzamanlı modeli duyurmuştur.
Serbest threading ile, her gelen nesne çağrımı ayrı bir thread ile idare edilebilir, ve
birçok gelen çağrı, tek bir nesne üzerinden, aynı zamanda ve farklı thread’lerle gönderilebilir.
Gönderme işlemi, COM kütüphanesi tarafından, RPC çalışma zamanı kütüphanesi ile
birleşme noktasından yönetilir. Yüksek performansa ihtiyaç duyan uygulamalar için, tüm
nesnelerin thread güvenliğini sağlamak için mutex’ler gibi eş zamanlı ilkeller kullanma
sorumluluğu geliştiricinin üzerindedir.
3.2.3. Güvenlik
Herhangi bir dağıtık mimarinin güvenlik desteği, onun en önemli bölümlerinden
biridir. DCOM, geliştirici ve yönetici tarafından ihtiyaç duyulduğunda seçilebilecek çok
kademeli bir güvenlik sağlar. Bir bileşenin güvenliğini belirleyebilme becerisi, geliştiriciler
için başka bir şeffaflık biçimi sağlar: Aynı ikili bileşen, hiç güvenliğe ihtiyaç olmayan bir
47
ortamda kullanılabileceği gibi, çok sıkı güvenlik gerektiren başka bir ortamda da
kullanılabilir.
DCOM, COM bileşenleri üzerinde Erişim Kontrol Listelerini (ACL – Access Control
Lists) sağlayarak bu şeffaflığa ulaşır. Eğer istek yapan kullanıcının bileşene erişme izni yoksa,
bileşen kodundan önce davranan DCOM, isteği reddedecektir.
Yüksek güvenlik için, ACL’leri DCOMCNFG adlı bir araç ile yönetebilirsiniz. Bir
yönetici bu aracı kullanarak, belirli bir makinedeki özel nesne sunucularına hangi
kullanıcıların ve grupların erişebileceğini idare edebilir. Aynı zamanda, sadece yöneticilerin
DCOM nesnelerine uzaktan erişmelerine izin veren makine bazlı varsayılan durumlar da
geçerlidir. DCOM’un önerdiği bir ek güvenlik katmanı seviyesi de, hangi kullanıcıların ve
grupların bir sunucu başlatmasına izin verildiğinin kontrol edilmesi yeteneğidir. Varsayılan
durum, sadece yöneticilerin uzak DCOM nesnelerini başlatabilmelerine izin verilmesidir.
Daha iyi güvenlik seviyelerine ulaşmak için, DCOM yöntemleri ayrık yöntem
çağrımlarının kimlik denetimlerini program ile kontrol edebilir. Kayıt anahtarlarının (registry
keys) ve Windows NT API’lerinin bir kombinasyonunun kullanılmasıyla, bir yöntem
geleneksel güvenlik politikalarını yürütebilir.
3.2.4. Referans Sayımı ve Ping Gönderme
Dağıtık uygulama geliştiricilerin karşılaştığı sorunlardan biri, istemcileri öldüğünde
bunu algılayabilen sunucular yazmaktır. Bir nesnenin ne zaman gitmesi gerektiğine karar
veren referans sayımının kullanılması nedeniyle, bu sorun DCOM’da özellikle önemlidir.
Tipik çözüm, işlemin hala hayatta olduğunu, periyodik ping gönderimleri ile algılamaktır.
Dağıtık nesneler dünyasında, ilgili işlemlerin durumunu bu şekilde takip etmek, istemciler ve
sunucular arasında büyük bir ağ trafiğine neden olur. Neyse ki, DCOM mimarları yüksek
performanslı ping gönderme desteği tasarlamışlardır.
Ping göndermeyi en iyi şekilde kullanmak için, DCOM her makine için hayatta kalma
mesajlarını kullanır. Bir ping mesajı makineler arasında, bir makinedeki istemci işlemleri
sayısından ve belirli bir uzak makinede erişilmekte olan bileşen sunucularının sayısından
bağımsız olarak, kullanılır. Eğer istemci işlemi ölürse, DCOM durumu algılar ve ilgili sunucu
arayüz işaretçilerinde Release çağrılarını başlatır. Sıradan istekler üzerinde yüklü
(piggybacking) ping mesajları, ve tüm uzak referanslar kümesini sürekli transfer etmek yerine
sadece yapılan değişiklikleri takip etmek, DCOM’da bulunan ek özelliklerden bazılarıdır.
48
DCOM, bu takibi başarmak için, başka makineler tarafından değiştirilmiş nesneleri ve
nesne referanslarını takip eden, Nesne İhracatçısı (Object Exporter) adında bir bileşen yürütür.
Nesne İhracatçısı, verilen bir makine üzerindeki istemci işlemlerinin yaşayıp yaşamadıklarını
takip etmekle sorumludur.
3.2.5. Yönetim
Dağıtık nesne uygulamaları, son birkaç senede önemli bir şekilde gelişmiştir. Ama
hala, geniş çaplı dağıtık nesne ortamlarının konfigürasyonu ve idaresi göz korkutan işlerdir.
DCOM bu işi daha kolay hale getirmek için bazı araçlar sağlar, ama yeterli değildir.
Her yayılan bileşenin, bir yada daha çok sunucu makinesinde kayıtlı olması gerektiği
gibi ayrı istemci makinelerinde da kayıtlı olmaları gerekir. Ufak bir dağıtımda, kurulum ve
muhafaza sorun değildir. İstemci ve sunucu makineleri ve bileşenlerinin sayılarının
artmasıyla, ağ yöneticilerinin istemci isteklerinin yükünün birçok sunucu makineleri
üzerindeki dengeli dağıtımı ile ilgilenmeleri gerekecektir. DCOM yük dengelemesi için
yapısal bir destek içermez. Eğer bir uygulama yükü dinamik olarak dengeleyemiyorsa, ağ
yöneticileri, belirli istemci makinelerinin belirli sunucuları kullanmalarını sağlamak gibi
yöntemlerle, ortamı statik olarak düzenlemelidirler. Eğer bileşen farklı bir sunucu makinesine
taşınmak zorunda kalınırsa, eski makineye yapılan her referans güncellenmelidir. DCOM’da,
bir istemcinin özel bir makine yerine makinelerin bir listesinde sunucuyu araması gerektiğini
gösterecek açıkça bir yol yoktur.
3.3. MIDL – Microsoft Interface Definition Language
Microsoft Arayüz Tanımlama Dili (MIDL), dağıtık uygulamalarda kullanılan
arayüzlerin yürütülmesi için geliştirilmiştir. COM ve DCOM tabanlı uygulamalar,
arayüzlerini MIDL kullanarak tanımlarlar. MIDL, OSF-DCE IDL’den geliştirilerek
üretilmiştir, ve birçok yönden C ve C++ dilleri ile benzerlikler gösterir. MIDL sayesinde bir
uygulama bir yada daha çok arayüze sahip olabilir. Her arayüz, istemci ve sunucu programları
arasında tekil bir dağıtık anlaşma belirler. Bir arayüz, farklı ortamlarda ve farklı koşullar
altındaki programların birlikte çalışabilmelerini sağlamak için, tanımlamalar ve uzak
fonksiyonlar içerir. COM’un ve DCOM’un arka planda RPC kullandığını söylemiştik. Bir
RPC uygulamasında, arayüz şunları belirler:
İstemci ve sunucu uygulamalarının birbirlerine kendilerini nasıl tanıtacakları
İstemci ve sunucu arasında verinin nasıl aktarılacağı
49
İstemci uygulamanın çağırabileceği uzaktaki prosedürleri
Uzaktaki prosedürlerin geri dönüş değerleri ve parametreleri için veri tipleri
Bir COM veya DCOM arayüzü, bir COM nesnesinin kimliğini ve dış özelliklerini
tanımlar. İstemcilere, nesnelerin yöntemlerine ve verilerine erişme yeteneği kazandırır.
DCOM’da, nesnenin aynı işlemde yada farklı işlemlerde olmasına, veya aynı makine üzerinde
yada farklı makineler üzerinde olmasına bakılmaksızın erişim yapılabilir. RPC istemci/sunucu
arayüzleri ile, bir COM yada DCOM nesnesi, fonksiyonelliğini çok değişik yollarla ve birden
çok arayüz üzerinden gösterebilir.
3.3.1. Tip Kütüphanesi
Bir tip kütüphanesi (.tlb), çalışma zamanında diğer uygulamaların erişebileceği bir
şekilde bulunan, bir COM veya DCOM nesnesinin özellikleri ve yöntemleriyle ilgili bilgilerin
saklandığı bir binary dosyadır. Tip kütüphanesini kullanarak, bir uygulama veya gezgin
(browser) nesnenin hangi arayüzleri desteklediğine karar verebilir, ve nesnenin arayüz
yöntemlerine çağrı yapabilir. COM/DCOM çalışma zamanı birimleri de, tip kütüphanelerinde
tanımlanan arayüzler için işlemler arası ve makineler arası otomatik dönüştürme sağlamak
üzere, bir tip kütüphanesi kullanabilirler.
3.3.2. Bir Arayüzün Karakteristik Özellikleri
Bir arayüzün karakteristik özellikleri bir IDL dosyasında tanımlanabileceği gibi, isteğe
bağlı olarak bir uygulama konfigürasyon dosyasında (ACF – application configuration file) da
tanımlanabilir. IDL dosyası uygulamanın arayüzlerinin alt seviyedeki karakteristik
özelliklerini belirler. Yani, istemci ve sunucu arasında veya COM nesneleri arasında verinin
nasıl aktarılacağı ile ilgilenir. ACF dosyası ise yerel işletim birimleri ile ilgisi olmayan arayüz
karakteristik özelliklerini belirler. ACF dosyası aynı zamanda, karmaşık bir veri tipinin
makine bağımsız bir şekle nasıl dönüştürüleceğini ve aktarılacağını da belirleyebilir. Her iki
dosya da MIDL script’leri ile oluşturulurlar.
3.3.3. MIDL Derleyicisi
Midl.exe derleyicisi hem C dili stub’larını ve başlık (header) dosyalarını, hem de tip
kütüphanesi dosyalarını oluşturmak için MIDL script’lerini kullanır. IDL dosyasının içeriğine
göre MIDL derleyicisi aşağıdaki dosyalardan herhangi birini üretir:
50
MIDL derleyicisi, bir arayüz nitelik listesinde nesne niteliği ile karşılaştığında; C
dilinde bir proxy/stub dosyası, bir arayüz belirleyici dosyası, bir DLL veri dosyası,
ve belirli bir COM arayüzü için ilgili bir başlık dosyası oluşturur.
MIDL derleyicisi, IDL dosyasında kütüphane (library) ifadesi ile karşılaştığında
Derlenmiş tip kütüphanesi dosyasını (.tlb) ve ilgili başlık dosyasını oluşturur.
IDL dosyasında nesne niteliği taşımayan arayüzler varsa; C/C++ dilinde istemci ve
sunucu stub dosyaları, ve RPC arayüzü için ilgili başlık dosyası oluşturulur.
3.3.4. Tip Tanımları, Yapı Bildirimleri, ve Import
Tip tanımları (type definitions), yapı bildirimleri (construct declarations), ve
import’lar, arayüz bedeninin dışında meydana gelirler. Temel IDL dosyasındaki tüm
tanımlamalar oluşturulan başlık dosyasında yer alacak, ve temel IDL dosyasındaki tüm
arayüzlerdeki tüm prosedürler stub rutinlerini oluşturacaklardır. Bu, birden çok arayüzü
destekleyen uygulamaların, IDL dosyalarını birleşik bir IDL dosyasında toplamalarına imkan
verir.
Sonuç olarak, dosyaları derlemek daha az zaman alır, ve aynı zamanda oluşturulan
stub’larda MIDL’ın fazlalıkları azaltmasına izin verir. Temel arayüzler ve türetilmiş arayüzler
için temel kod paylaşımı yeteneği ile, nesne arayüzlerinin değerleri önemli ölçüde
arttırılabilir. Nesnesiz arayüzler için, prosedür isimleri tüm arayüzlerde tek olmalıdır. Nesne
arayüzleri için ise, prosedür isimleri sadece bir arayüzün içinde tek olmalıdır. /osf1
anahtarını kullandığınızda, çoklu arayüzleri kullanamayacağınızı unutmayın.
3.3.4.1. Bildirilebilen Yapılar
IDL dilindeki bildirilebilen yapılar için sentaks, C dilindekine benzer. MIDL,
aşağıdaki istisnalar dışında, tüm Microsoft C/C++ bildirilebilen yapılarını destekler.
Bildiricinin tip belirleyicisi olmadan belirlenmesine izin veren eski tip bildiricileri
desteklemez. Örneğin x(y) gibi değil, short x(y) gibi olmalıdır.
İlk değer atayan bildirileri desteklemez. Sadece MIDL’ın const sentaksına uyan
bildirileri destekler.
1 /osf anahtarı, OSF DCE standartları ile uyumluluğu sağlar.
51
import kelimesi ithal edilecek bir yada daha çok IDL dosyası ismini belirler.
import deyimi C’deki include’a benzer, ama ithal edilen IDL dosyasına sadece veri
tipleri bağdaştırılır.
3.3.4.2. Sabit Bildirimi (Constant Declaration)
Sabit bildirimi Boolean, integer, character, wide-character, string,
ve void * sabitlerini belirler.
3.3.4.3. Genel Bildirim (General Declaration)
C’deki typedef ifadesi ile benzerdir, fazladan IDL tip nitelikleri de eklenmiştir.
/osf anahtarı kullanıldığında, MIDL derleyicisi değişken tanımı biçimindeki kesin bildiriye
de izin verir.
3.3.4.4. Fonksiyon Bildirimi (Function Declaration)
Fonksiyon birdiricisi, genel bildirimin özel bir şeklidir. IDL nitelikleri, fonksiyon geri
dönüş tipinin ve parametrelerin her birinin davranışlarını belirlemek için kullanılabilir.
3.3.4.5. Örnekler
[
uuid(12345678-1234-1234-1234-123456789ABC),
version(3.1),
pointer_default(unique)
]
interface IdlGrammarExample {
import "windows.idl", "other.idl";
const wchar_t * NAME = L"Example Program";
typedef char * PCHAR;
HRESULT DictCheckSpelling(
[in, string] PCHAR word, // aranan kelime
[out] short * isPresent // yoksa 0
);
}
52
3.3.5. IDL Nitelikleri (IDL Attributes)
3.3.5.1. Dönüştürme ve Örtüşme Nitelikleri
Dağıtık uygulamalar, arayüz prosedürlerini çağırdıklarında, istemci ve sunucu
programlar arasında veri aktarırlar. Geliştiriciler, istemci ve sunucu programları arasında
verilerin standart bir biçimde aktarılabilmesi için, veri tanımlamada MIDL kullanırlar. MIDL
derleyicisi, veriyi ağ üzerinden aktarılabilecek standart bir biçime dönüştüren istemci ve
sunucu için uygulama stub veya proxy programları yaratır. Ağ Veri Gösterimi (NDR –
Network Data Representation) olarak adlandırılan bu standart biçime, çoğu zaman verinin tel
biçimi (wire format) de denir. CORBA’da olduğu gibi, COM’da da veri tel üzerinden
aktarılmadan önce dönüştürülme (marshaling) işlemi yapılır, ve aktarıldıktan sonra da yine
eski haline geri dönüştürülür (unmarshaling).
Verinin NDR biçimine nasıl dönüştürüleceği ve ağ üzerinden nasıl aktarılacağını
kontrol etmek için dönüştürme ve örtüşme nitelikleri (Tablo 3.1) kullanılır.
Nitelik Kullanımı
call_as Uzağa gönderilemeyen bir fonksiyonu bir uzak prosedür çağrısı ile eşler.
iid_is İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar.
transmit_as Bir veri tipini ağ üzerinden aktarılabilmesi için daha basit bir tipe çevirir.
wire_marshal transmit_as ile benzerdir, ama veriyi boyutlandırmak, dönüştürmek, geri dönüştürmek,
ve bırakmak için rutinleri siz yürütürsünüz.
Tablo 3.1. Dönüştürme ve Örtüşme Nitelikleri
3.3.5.2. Asenkron Nitelikler
Bir program bir arayüzdeki bir prosedürü çağırdığında, program senkron veya
asenkron olarak çalışabilir. Senkron bir prosedür, çağıran programın, prosedürün geri
dönüşünü beklemesine neden olur. Asenkron bir prosedür ise sonuçları beklemeden geri
dönebilir. Çağıran program veriyi almak için daha sonra tekrar arayüz prosedürü ile
senkronize edilmelidir.
Asenkron uzak prosedür çağrıları için destek sağlamak istiyorsanız, Tablo 3.2’deki
nitelikleri kullanabilirsiniz.
53
Nitelik Kullanımı
async Bir fonksiyon parametresinde yer aldığında, çağıranın asenkron bir çağrı yapmasına ve sonuçları
beklemeden geri dönmesine izin veren bir işleyici (handle) tanımlar. async niteliği, ACF dosya-
larında bir prosedür veya bir tam arayüz için bir asenkron işleyici tanımlamak için de kullanılır.
COM arayüzleri için tam arayüz modası geçmiş bir arayüzdür ve yeni arayüzlerle kullanılamaz.
async_uuid Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL
derleyicisini yönlendirir.
maybe Bu uzak prosedür çağrısını yapan istemci, teslimat veya çağrının bitirilmesi ile ilgili herhangi bir
yanıt beklentisinde bulunmaz, ve teslimat garantisi yoktur. Yanıt beklentisi olmayan ama
teslimat garantisi olan mesaj işlemlerine zıttır.
message Uzak prosedür çağrısına istemciden sunucuya bir asenkron mesajmış gibi davranılır. İstemci
çağrıyı yapar, ve gerçek çağrı mesaj-kuyruk taşıması (ncadg_mq) tarafından ele alınırken sonuç
beklenilmeden hemen geri döner.
Tablo 3.2. Asenkron Nitelikler
3.3.5.3. Dizi ve Boyutlu-İşaretçi Nitelikleri
MIDL, veri işaretçileri ve verilerin dizilerini aktarmak için zengin bir özellikler
kümesi sağlar. Tablo 3.3’teki nitelikleri kullanarak dizilerin karakteristik özelliklerini ve
işaretçilerin boyutlarını belirleyebilirsiniz.
Nitelik Kullanımı
size_is Boyutlu işaretçiler, boyutlu işaretçilere boyutlu işaretçiler, ve tek veya çok boyutlu diziler
için ayrılacak hafıza bölgesinin büyüklüğünü belirler.
max_is Bir dizi indisi için maksimum değeri belirler.
length_is Aktarılacak dizi elemanlarının sayısını belirler.
first_is Aktarılacak ilk dizi elemanının indisini belirler.
last_is Aktarılacak son dizi elemanının indisini belirler.
string Tek boyutlu char, wchar_t, byte dizilerin (veya eşdeğerleri), veya böyle bir diziye
işaretçilerin string olarak ele alınacağını gösterir.
range Çalışma zamanında değerleri belirlenen argümanlar veya alanlar için kabul edilebilir
değer aralığını belirler.
Tablo 3.3. Dizi ve Boyutlu-İşaretçi Nitelikleri
MIDL üç tip işaretçi destekler, referans işaretçiler (ref), tekil işaretçiler (unique)
ve tam işaretçiler (ptr).
54
Bir işaretçi niteliği, bir type niteliği gibi; bir structure üyesi, union üyesi veya
parametreye uygulanan bir alan niteliği gibi, veya fonksiyon geri dönüş tipine uygulanan bir
fonksiyon niteliği gibi, tahsis edilebilir. İşaretçi niteliği pointer_default kelimesi ile de
görünebilir.
Uzak bir fonksiyonun çağrımı sırasında bir işaretçi parametresinin değiştirilmesini,
çoklu işaretçi bildiricilerini destekleyerek dolaylı yoldan sağlamak gerekir. Parametreye
uygulanan kapalı işaretçi niteliği, sadece parametre için en sağdaki işaretçi bildiricisini etkiler.
Bir parametre bildiriminde birden çok işaretçi bildiricisi olduğunda, diğer belirleyiciler
pointer_default niteliği ile belirlenen işaretçi niteliğine bağlıdırlar. Birden çok işaretçi
bildiricisine farklı işaretçi nitelikleri uygulamak için, açık işaretçi niteliklerini belirleyen ayrı
tipler tanımlanmalıdır.
Varsayılan ĠĢaretçi-Niteliği Değerleri
Parametre olan bir işaretçi ile hiçbir işaretçi niteliği ilişkilendirilmediğinde, işaretçi bir
ref işaretçisi olarak kabul edilir.
Bir structure’ın veya bir union’ın bir elemanı olan bir işaretçi ile hiçbir işaretçi
niteliği ilişkilendirilmediğinde, MIDL işaretçi niteliklerini aşağıdaki öncelik sırasını
kullanarak atar:
1. İşaretçi tipine açık bir şekilde atanan nitelikler
2. İşaretçi parametre veya üyeye açık bir şekilde atanan nitelikler
3. Tipi tanımlayan IDL dosyasındaki pointer_default niteliği
4. Tipi ithal eden IDL dosyasındaki pointer_default niteliği
5. ptr (osf iken); unique (Microsoft RPC iken)
IDL dosyası varsayılan şekilde derlendiğinde, ithal eden dosyalar işaretçi niteliklerini
ithal edilen dosyalardan miras alabilirler. /osf anahtarı kullanılarak derleme yapıldığında bu
özellik geçerli değildir.
Fonksiyon DönüĢ Tipleri
Bir fonksiyon tarafından döndürülen işaretçi, bir tekil işaretçi veya bir tam işaretçi
olmalıdır. Bir fonksiyonun sonucu bir referans işaretçi olursa, MIDL derleyicisi varsayılan
biçimde veya açık bir şekilde bir hata üretir. Dönen işaretçi her zaman yeni bir yerde
saklanmalıdır.
55
Bir işaretçi değeri döndüren fonksiyonlar, bir işaretçi niteliğini bir fonksiyon niteliği
gibi belirleyebilirler. Eğer bir işaretçi niteliği bulunmuyorsa, fonksiyon-sonuç işaretçisi,
sağlanan değeri pointer_default niteliği olarak kullanır.
Tip Tanımlamalarında ĠĢaretçi Nitelikleri
Bir typedef ifadesinin en üst basamağında bir işaretçi niteliği belirlendiyse,
belirlenen nitelik beklendiği gibi işaretçi bildiricisine uygulanır. Eğer hiç işaretçi niteliği
belirlenmediyse, bir typedef ifadesinin en üst basamağında, işaretçi bildiricileri kullanıldığı
zaman işaretçi nitelik tipini miras alırlar.
DCE IDL, açık bir şekilde iki defa uygulanan (örn: hem typedef bildiriminde hem
de parametre niteliği listesinde uygulandıysa) aynı işaretçi niteliğine izin vermez. MIDL
derleyicisinin varsayılan durumunu kullandığınızda bu kısıtlama gevşetilir.
3.3.5.4. Veri Tipi Nitelikleri
Bir typedef ifadesindeki veri tiplerine, veri tipinin etkisine veya kullanımına ek
özellikler kazandırmak için, Tablo 3.4’teki nitelikleri uygulayabilirsiniz.
Nitelik Kullanımı
context_handle Belirli bir istemciden gelen uzak prosedür çağrıları ile belirli bir sunucu arasındaki içerik
(context) bilgisini muhafaza eden bir bağlı işleyici tanımlar. Nesne arayüz fonksiyonları
için geçerli değildir.
handle Uygulamaya özgü, özel bir işleyici (handle) tipi belirler.
ms_union Korunmamış (nonencapsulated) union’ların NDR düzenlemesini kontol eder. MIDL 1.0 ve
2.0 ile oluşturulmuş arayüzler ile geriye dönük uyumluluk için typedef’lerde kullanılır.
pipe Sonu belirlenmemiş bir dizinin bir uzak prosedür çağrısı üzerinden aktarımına izin verir.
Bir in pipe parametresi, bir uzak prosedür çağrısı sırasında sunucunun istemciden veri
dizisini çekmesine izin verir. Bir out pipe parametresi, sunucunun veriyi dizisini istemciye
geri göndermesine izin verir.
transmit_as Özel dönüştürmede kullanılan bir veri tipinin ağ üzerinden nasıl aktarılacağını belirler.
v1_enum Belirlenen sayı tipinin 16-bit varsayılan değerle değil de, 32-bit olarak aktarılacağını
belirler.
wire_marshal transmit_as ile benzerdir, ama veriyi boyutlandırmak, dönüştürmek, geri dönüştürmek,
ve bırakmak için rutinleri siz yürütürsünüz.
Tablo 3.4. Veri Tipi Nitelikleri
56
3.3.5.5. Yönlendirici Nitelikler
Verinin aktarılacağı yönü göstermek için, yönlendirici nitelikler parametrelere
uygulanır. Her iki nitelik te tek bir parametreye uygulanabilir, ama bunu yapmak bir çağrı ile
ilişkilendirilmiş masrafları arttırır.
Nitelik Kullanımı
in Çağırandan çağrılan fonksiyona aktarılacak olan parametre
out Çağrılan fonksiyondan çağırana aktarılacak olan parametre
Tablo 3.5. Yönlendirici Nitelikler
3.3.5.6. Fonksiyon Çağrım Nitelikleri
Programlar bu nitelikleri ayrık fonksiyonlarda arayüzler içinde kullanabilirler, ve
sadece o fonksiyonu etkiler.
Nitelik Kullanımı
message Uzak prosedür çağrısına istemciden sunucuya bir asenkron mesajmış gibi davranılır.
İstemci çağrıyı yapar, ve gerçek çağrı mesaj-kuyruk taşıması (ncadg_mq) tarafından ele
alınırken sonuç beklenilmeden hemen geri döner.
maybe Bu uzak prosedür çağrısını yapan istemci, teslimat veya çağrının bitirilmesi ile ilgili
herhangi bir yanıt beklentisinde bulunmaz, ve teslimat garantisi yoktur. Yanıt beklentisi
olmayan ama teslimat garantisi olan mesaj işlemlerine zıttır.
broadcast Uzak prosedür çağrısı ağ üzerindeki tüm sunuculara gönderilir. İstemci ilk geri dönüşü
kabul eder, diğer sunuculardan gelen takip eden yanıtlar önemsenmez.
idempotent Çağrı durum değiştirmez, ve aynı giriş parametreleri ile her çağrıldığında aynı bilgiyi geri
döndürür.
callback Sunucunun istemciden bilgi almak için çağırabileceği istemci uygulamada bulunan bir
fonksiyonu tatbik eder.
call_as Bir uzak prosedür çağrısı ile uzaklaştırılamayacak bir fonksiyonu eşler.
local MIDL’ın stub kodunu oluşturmayacağı bir yerel prosedür tatbik eder. Nesne arayüz
fonksiyonları için geçerli değildir.
Tablo 3.6. Fonksiyon Çağrım Nitelikleri
Nesne olmayan arayüzlerde, string, ptr ve context_handle niteliklerini de geri dönüş
değerinin karakteristik özelliklerini belirlemek için bir fonksiyona uygulayabilirsiniz.
57
3.3.5.7. Arayüz Başlık Nitelikleri
Tüm arayüz hakkında bilgi taşımak için arayüz başlığında bu nitelikler birleştirilir.
Nitelik Kullanımı
async_uuid Bir COM arayüzünün hem senkron hem de asenkron sürümlerini tanımlamak için MIDL
derleyicisini yönlendirir.
uuid Belirli bir arayüzü tüm diğer arayüzlerden ayırmak için 128-bit’lik bir değer verir. Gerçek
değer, bir GUID, bir CLSID, veya bir IID’yi temsil edebilir.
local MIDL derleyicisini sadece başlık dosyalarını oluşturması için yönlendirir. Bir arayüz ya
uuid yada yerel bir nitelik sahibi olmalıdır.
ms_union Korunmamış (nonencapsulated) union’ların NDR düzenlemesini kontol eder. MIDL 1.0 ve
2.0 ile oluşturulmuş arayüzler ile geriye dönük uyumluluk için typedef’lerde kullanılır.
object Arayüzü bir COM arayüzü olarak belirler ve MIDL derleyicisini RPC istemci ve sunucu
stub’ları yerine proxy/stub kodu üretmesi için yönlendirir.
version Arayüzün birden çok sürümünün bulunması olasılığına karşı bir arayüzün belirli bir
sürümünü belirler. Çünkü COM arayüzlerinin değişmezliği yüzünden, nesne arayüzünün
üstünde version niteliğini kullanamazsınız.
pointer_default Parametre listesindekiler haricindeki tüm işaretçiler için varsayılan işaretçi tipini belirler.
Varsayılan tip unique, ref veya ptr olabilir.
endpoint Sunucu uygulamanın uzak prosedür çağrılarını dinleyeceği, statik bir son nokta belirler.
Tablo 3.7. Arayüz Başlık Nitelikleri
3.3.5.8. Performans Nitelikleri
Tablo 3.8’deki nitelikleri bir IDL dosyasında, stub kodunun boyutunu azaltmak veya
performansı arttırmak için kullanabilirsiniz.
Nitelik Kullanımı
ignore Bir işaretçinin, bir struct veya union tarafından kapsandığını gösterir, ve işaretçi
tarafından gösterilen nesne aktarılmayacaktır.
local Bir fonksiyonun, uygulama için lokal olduğunu, ve MIDL’ın stub kodunu üretmesine gerek
olmadığını gösterir.
Wire_marshal Bir veri tipini, ağ üzerinden aktarılabilmesi için daha basit bir tip olarak tanımlar, ve tip
için dönüştürme ve geri dönüştürme rutinlerinin yürütülmesine olanak sağlar.
Tablo 3.8. Performans Nitelikleri
58
3.3.5.9. İşaretçi Tipi Nitelikleri
Tablo 3.9’daki nitelikler, işaretçilerin karakteristik özelliklerini belirlemek için
kullanılırlar.
Nitelik Kullanımı
ptr Bir işaretçiyi, bir C dili işaretçisinin örtüşme (aliasing) özelliği de dahil, tüm nitelikleri ile
bir tam işaretçi olarak belirtir.
ref Bazı verilerin adreslerini sağlayan, MIDL’daki en basit işaretçi tipini belirtir. Referans
işaretçiler hiçbir zaman boş (NULL) olamazlar.
unique İşaretçinin boş (NULL) olmasına izin verir, ama örtüşmeyi desteklemez.
pointer_default Bir arayüze, varsayılan değeri ref olan üst-düzey parametre işaretçileri dışında, o
arayüzdeki tüm işaretçiler için varsayılan işaretçi tipini belirlemek üzere uygulanır.
iid_is İşaretçinin nesnesi olan COM arayüzünün arayüz belirleyicisini sağlar.
string İşaretçinin bir karakter katarını gösterdiğini belirtir.
Tablo 3.9. İşaretçi Tipi Nitelikleri
3.3.5.10. Struct ve Union Nitelikleri
Bir union’ın bir uzak prosedür çağrısındaki karakteristiğini belirlemek için
switch_* nitelikleri kullanılır. Belirli miktardaki struct veya union üyelerini istemci
uygulamaya yerel olarak göstermek için ignore niteliği kullanılır.
Nitelik Kullanımı
switch Korunmuş (encapsulated) bir birleşim (union) için ayırtacı (discriminant) belirler.
switch_is Korunmamış (nonencapsulated) bir birleşim için ayırtacı belirler.
switch_type Korunmamış bir birleşim için ayırtacın tipini belirler.
ignore Bir işaretçinin, bir struct veya union tarafından kapsandığını gösterir, ve işaretçi
tarafından gösterilen nesne aktarılmayacaktır.
Tablo 3.10. Struct ve Union Nitelikleri
struct ve union üyelerinin karakteristik özelliklerini belirlemek için Dizi ve
Boyutlu-İşaretçi Niteliklerini de (bakınız 3.3.5.3) kullanabilirsiniz.
59
3.3.5.11. Tip Kütüphanesi Nitelikleri
ġekil 3.11’deki nitelikler, IDL dosyasında bir library ifadesinin içerdiği kısımda
tip kütüphanesi bilgisini belirler.
Nitelik Kullanımı
aggregatable coclass’ı, başka bir nesnenin arayüz işaretçisini direkt olarak gösterebilen destekleyen
nesneler olarak belirler.
appobject coclass’ı, bir tam EXE uygulaması ile ilişkilendirilmiş bir uygulama nesnesi olarak belirler.
bindable Özelliğin veri bağlantısını desteklediğini gösterir. Bu, bir özellik değerini değiştirdiği
zaman istemcinin bilgilendirilmesini sağlar.
coclass Bir bileşen nesnesi için desteklenen arayüzlerin bir listesini sağlar.
control Bir coclass’ı veya kütüphaneyi, kapsayan yerin ek tip kütüphaneleri veya bileşen nesne
sınıfları türeteceği bir COM kontrolü olarak belirler.
custom MIDL’da tanımlı olmayan özel bir nitelik tanımlar.
default Coclass içinde tanımlanan arayüzün varsayılan arayüzü temsil ettiğini gösterir.
defaultbind Nesneyi en iyi şekilde gösterecek bağlanabilir tekil özelliği gösterir.
defaultcollelem Varsayılan koleksiyonun bir üyesi için bir erişici fonksiyon olarak özelliği işaretler.
Microsoft Visual Basic kod optimizasyonu için kullanılır.
defaultvalue Seçimlik bir parametre için varsayılan bir değerin belirlenmesine izin verir.
defaultvtable Bir nesnenin iki farklı kaynak arayüzü olmasına izin verir.
dispinterface IDispatch::Invoke’u çağırabileceğiniz özellikler ve yöntemlerin bir kümesini tanımlar.
displaybind Kullanıcıya bağlanabilir olarak gösterilmesi gereken bir özellik gösterir.
dllname(str) Bir modül için giriş noktalarını içeren DLL dosyasının ismini belirler.
dual IDispatch ve Vtable üzerinden özellikleri ve yöntemleri teşhir edilecek arayüzü tanımlar.
entry DLL’de giriş noktasını belirleyerek ihraç edilmiş fonksiyon veya sabiti bir modülde belirler.
helpcontext Kullanıcının Yardım dosyasında bu üye ile ilgili bilgi bulabileceği bir içerik belirleyicisi
tanımlar.
helpfile Bir tip kütüphanesi için yardım dosyasının ismini belirler.
helpstring Uygulandığı üyeyi tanımlamak için kullanılan bir karakter katarını belirler.
helpstringdll Doküman karakter taraması yapmak için kullanılacak DLL’in ismini belirler.
hidden Maddenin varolduğunu ama kullanıcıya gösterilmemesi gerektiğini ifade eder.
id Bir üye fonksiyon (arayüzdeki bir özellik veya bir yöntem) için bir DISPID belirler.
immediatebind Bir veri-bağı (data-bound) nesnesinin bir özelliğindeki tüm değişikliklerden veritabanının
hemen haberdar edileceğini gösterir.
60
lcid Bir kütüphane ifadesine bir localeID argümanıyla beraber uygulandığında, bir tip
kütüphanesi veya bir fonksiyon argümanı için yer belirler, ve kütüphane bloğu içinde
enternasyonal karakterlerin kullanılmasına izin verir.
library İfade içinde referans edilen arayüzler ve sınıflar için tip kütüphanesi bilgisini oluşturması
için, MIDL derleyicisine talimat verir.
licensed Uygulandığı coclass’ın lisanslı olduğunu gösterir, ve örnekler IClassFactory2 kullanarak
oluşturulmalıdırlar.
nonbrowsable Özelliğin bir nesne gezgininde (özellik değerlerini göstermeyen) yer alacağını, ama
özellikler gezgininde (özellik değerlerini gösteren) yer almayacağını gösterir.
noncreatable İstemcinin, bir nesne arayüzünün örneklerini oluşturmak için varsayılan sınıf fabrikasını
kullanmasını engeller.
nonextensible IDispatch yürütmesinin sadece arayüz tanımında yer alan özellikleri ve yöntemleri
içereceğini, ve yürütme zamanında ek üyelerle genişletilemeyeceğini belirler.
oleautomation Bir arayüzün otomasyon ile uyumlu olduğunu gösterir.
optional Bir üye fonksiyonu için seçimlik bir parametre belirler.
propget Bir özellik erişici fonksiyon belirler.
propput Bir özellik yerleştirici fonksiyon belirler.
propputref Bir değer yerine bir referans kullanan bir özellik yerleştirici fonksiyon belirler.
public Typedef ile bildirilen bir alias’ın, tip kütüphanesinin bir parçası haline gelmesini sağlar.
readonly Bir değişkene yeni bir değerin atanmasını engeller.
requestedit Özelliğin OnRequestEdit bildirimini desteklediğini gösterir.
restricted Bir modülün veya bir arayüzün bir kütüphanesinin veya bir üyesinin keyfi olarak
çağrılamayacağını belirler.
retval Üyenin dönüş değerini alan parametreyi belirtir.
source Bir özellik, yöntem veya coclass’ın bir üyesinin olayların kaynağı olduğunu gösterir.
string Tek boyutlu char, wchar_t, byte dizilerinin (veya eşdeğerlerinin) veya bu gibi dizilere
işaretçinin, string olarak davranması gerektiğini gösterir.
uidefault Tip bilgi üyesinin, kullanıcı arayüzünde görünüm için varsayılan üye olduğunu gösterir.
usesgetlasterror Bir modül giriş noktasının geri dönen hata kodları için SetLastError kullandığını, ve eğer
bir fonksiyona girişte bir hata varsa çağıranın hata kodunu almak için GetLastError’u
çağırabileceğini gösterir.
uuid Bir tip kütüphanesi, coclass, veya arayüz için tekil bir belirleyici belirtir.
vararg Fonksiyonun değişken sayıda argüman alabileceğini belirler.
version Bir tip kütüphanesinin belirli bir sürümünü belirtir.
Tablo 3.11. Tip Kütüphanesi Nitelikleri
61
3.3.6. MIDL Veri Tipleri
3.3.6.1. Ön-tanımlı ve Temel Tipler
MIDL aşağıdaki temel ve ön-tanımlı tipleri destekler.
Veri tipi Açıklama Varsayılan iĢaret
Boolean 8 bit. oleautomation arayüzleri ile uyumlu değil; bu arayüzlerde
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.
__int3264 32-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 3.12. Ön-tanımlı ve Temel Tipler
62
3.3.6.2. İşaretli ve İşaretsiz Tipler
İşaretli ve işaretsiz tipler için farklı varsayılan durumlar kullanan derleyiciler, dağıtık
uygulamalarda yazılım hatalarına sebep olabilirler. Karakter tipleri işaretli (signed) veya
işaretsiz (unsigned) olarak kesin bir biçimde belirlenirse, bu problemler ortaya çıkmaz.
DCE IDL derleyicileri signed kelimesini kabul etmezler. Bu durumda /osf anahtarı
kullanıldığında bu kelime kullanılamayacaktır.
MIDL, C derleyicisindeki char tipi ile aynı varsayılan işareti elde etmek için small
tipini tanımlamıştır. Eğer derleyici char’ın işaretsiz olduğunu farz ettiyse, small da
işaretsiz olarak tanımlanacaktır. Birçok C derleyicisi varsayılan değerin bir komut satırı
seçeneği ile değiştirilmesine izin verir. Örneğin Microsoft Visual C++’de, /J komut satırı
seçeneği, char’ın varsayılan işaretini, işaretliden işaretsize çevirir.
MIDL derleyicisindeki /char komut satırı anahtarı ile, char ve small tiplerindeki
değişkenlerin işaretleri kontrol edilebilir. Bu anahtar, derleyicinin kullandığı varsayılan işareti
belirlemeye izin verir. MIDL derleyicisi, oluşturulan başlık dosyasında C derleyicinizin
varsayılan tipi ile uyuşmayan tüm char tiplerinin işaretlerini, açıkça bildirir.
3.3.6.3. Diğer MIDL Veri Tipleri
MIDL, BSTR, VARIANT, ve SAFEARRAY, gibi birçok COM ve otomasyon
(Automation) veri tipini, ve HMETAFILE_PICT, HENHMETAFILE, HMETAFILE,
HBITMAP, HPALETTE, ve HGLOBAL gibi birçok COM işleyicisini kabul eder.
3.3.7. MIDL Dizileri
Dizi bildiricileri, IDL dosyasının arayüz gövdesinde aşağıdakilerden biri olarak yer
alırlar:
Bir genel bildirimin parçası olarak
Bir struct veya union bildiriminin bir üyesi olarak
Uzak bir prosedür çağrısına bir parametre olarak
Microsoft RPC’nin C dilini baz alması nedeniyle, dizi bildirimleri C dilindekine
benzer. Dizinin her boyutunun sınırları ayrı ayrı köşeli parantezler içerisinde verilir. Köşeli
parantezin içinin boş bırakılması veya “*” işaretinin bulunması, dizinin alt sınırının sıfır
olduğunu, ve üst sınırının çalışma zamanı içerisinde belirleneceğini gösterir. C dilinde olduğu
gibi, çok boyutlu dizilerde sadece ilk boyutun çalışma zamanında belirlenmesine izin verilir.
63
/* IDL file interface body */
#define MAX_INDEX 10
typedef char ATYPE[MAX_INDEX];
typedef short BTYPE[]; // [*] ile aynı;
typedef long 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;
3.3.7.1. İşaretçilerin Dizileri
Referans işaretçileri geçerli bir veriyi işaret etmelidirler. İstemci uygulama referans
işaretçilerinin bir [in] veya bir [in, out] dizisi için, özellikle de dizi [in] veya [in,
out], [length_is] veya [last_is] değerleri ile ilişkilendirildiyse, tüm hafızayı tahsis
etmelidir. İstemci uygulama aynı zamanda çağrıdan önce tüm dizi elemanlarını başlatmalıdır.
Sunucu uygulama, istemciye geri dönmeden önce, aktarılan aralıktaki tüm dizi elemanlarının
geçerli depolama yerine işaret ettiklerini doğrulamalıdır.
Sunucu tarafında stub, çağrı zamanındaki [length_is] veya [last_is] değerini
önemsemeden tüm dizi elamanları için yer tahsis etmelidir. Bu özellik uygulamanızın
performansına etki edebilir.
64
unique işaretçilerin dizilerinde hiçbir kısıtlama bulunmaz. Hem istemcide hem de
sunucuda, boş işaretçiler için yer tahsis edilir. İşaretçiler dolduğunda, veri önceden tahsis
edilmiş yere yerleştirilir.
Seçimlik bir işaretçi bildiricisi, dizi bildiricisinin önünden gidebilir.
Gömülü referans işaretçileri sadece [out] parametreler olduklarında, sunucu-
yönetici kodu, referans işaretçilerinin dizisine geçerli değerleri atamalıdır. Örneğin:
typedef [ref] short * ARefPointer;
typedef ARefPointer ArrayOfRef[10];
HRESULT proc1( [out] ArrayOfRef Parameter );
Oluşturulan stub’lar diziyi tahsis ederler ve dizide gömülü olan tüm işaretçilere NULL
değerler atarlar.
3.3.8. Yapılar (Structures) ve BirleĢimler (Unions)
Temel tiplerin alanlarına normal C semantikleri uygulanır. İşaretçiler, diziler ve diğer
yapısal tipler gibi daha karmaşık tiplerin alanları, tip veya field_attributes ile
değiştirilebilir.
MIDL, C/C++ union ifadesinin bir üst kümesini destekler. MIDL, union’ların iki
türünü destekler:
3.3.8.1. Korunmuş Birleşimler (Encapsulated Unions)
Ayırtacı (discriminant) ile beraber bir yapı içerisinde olan birleşime, korunmuş
birleşim denir. Korunmuş birleşim, switch kelimesinin varlığı ile gösterilir. Bu tip bir
birleşimde, MIDL derleyicisi bir uzak prosedür çağrısı sırasındaki aktarım için birleşimi ve
ayırtacı bir yapı içinde otomatik olarak korur.
Eğer birleşim etiketi (örnekteki U1_TYPE) yoksa, derleyici yapıyı tagged_union
adındaki birleşim alanı ile oluşturur.
Birbirleriyle bağlantılı olmalarını sağlamak için, birleşimlerin biçimleri tüm
platformlarda aynı olmalıdır.
65
typedef union _S1_TYPE switch (long l1) U1_TYPE
{
case 1024:
float f1;
case 2048:
double d2;
} S1_TYPE;
/* in generated header file */
typedef struct _S1_TYPE
{
long l1;
union
{
float f1;
double d2;
} U1_TYPE;
} S1_TYPE;
3.3.8.2. Korunmamış Birleşimler (Nonencapsulated Unions)
Ayırtacı ile beraber bir yapı içerisinde olmayan birleşime, korunmamış birleşim denir.
Korunmamış birleşim, switch_type tip niteliğinin ve switch_is alan niteliğinin varlığı
ile gösterilir. Bu tip bir birleşimde, MIDL derleyicisi bir uzak prosedür çağrısı sırasındaki
aktarım için birleşimi ve ayırtacı bir yapı içinde otomatik olarak korur.
3.3.9. Bağlı ĠĢleyiciler (Binding Handles)
Bağlı handle’lar, istemci ile sunucu arasındaki bağı gösteren veri nesneleridir.
MIDL, handle_t temel tipini destekler. Bu tipin işleyicileri, ilkel işleyiciler
(primitive handles) olarak bilinirler.
[handle] niteliğini kullanarak kendi özel işleyicilerinizi tanımlayabilirsiniz. Bu
şekilde tanımlanmış işleyiciler, kullanıcı-tanımlı (user-defined) veya özelleştirilmiş
(customized) veya soysal (generic) işleyiciler olarak bilinirler.
66
[context_handle] niteliğini kullanarak durum bilgisini muhafaza eden bir
işleyici tanımlayabilirsiniz. Bu şekilde tanımlanmış işleyiciler “içerik” (context) işleyicileri
olarak bilinirler.
Eğer durum bilgisine ihtiyaç yoksa, ve işleyici yönetmek için RPC çalışma zamanı
kütüphanelerini çağırmayı seçmediyseniz, çalışma zamanı kütüphanelerinin otomatik bağlantı
yapmalarını isteyebilirsiniz. Bu, [auto_handle] ACF anahtar kelimesi kullanılarak
yapılır.
[implicit_handle] ACF anahtar kelimesini kullanarak global bir değişkeni bir
bağlı işleyici olarak belirleyebilirsiniz. [explicit_handle] anahtar kelimesi, her uzak
fonksiyonun açıkça belirlenmiş bir işleyicisi olduğunu belirtmek için kullanılır.
3.4. DCOM’un Bugünü ve Yarını
DCOM, 1996 yılında piyasaya sürülen Windows NT 4.0 ile Windows işletim
sistemlerinin bir parçası haline gelmiş, ve bu tarihten sonra çıkan tüm Windows sürümlerinde
yerini almıştır. Windows dışındaki ortamlarda da DCOM’un söz sahibi olabilmesi için,
Microsoft, Software AG ve Digital Equipment Corp. ile ortaklığa gitmiştir. Bunun sonucunda
Solaris, IBM MVS, HP-UX, DEC UNIX ve Siemens Nixdorf SINIX gibi platformlarda
DCOM kullanılabilir duruma gelmiştir. COM/DCOM nesneleri, C++, Visual Basic, Java
programlama dilleriyle ve VBScript, JScript script programlama dilleriyle kullanılabilirler.
DCOM, MTS (Microsoft Transaction Server) ve Dizin Hizmetleri (Directory
Services) gibi sonradan ortaya çıkan bazı Microsoft teknolojilerinin de temel taşı olmuştur.
MTS, COM ve DCOM nesnelerinden oluşmuş multitier uygulamaların geliştirilmesi,
yayılması ve idaresi sağlayan bir hareket işlem sistemidir. DCOM, makineler arasındaki tüm
nesne haberleşmelerinde kullanılır. MTS ise, nesnelere hareket desteği sağlamanın yanında,
thread’leri, işlemleri, veritabanı bağlantılarını, iş nesnelerini sağlarken geliştiricilerin
başvurabilecekleri paylaşım özelliklerini yönetir. SQL Server ile sıkı bir entegrasyonu
olmasına rağmen, diğer veritabanı sistemlerine de destek verecek şekilde tasarlanmıştır. Dizin
Hizmetleri ve Aktif Dizin (Active Directory), ilk defa Windows 2000’de yer almıştır. Ağ
üzerinde bulunan tüm bilgilerin (kullanıcılar, gruplar, bilgisayarlar, yazıcılar, ...) dizin mantığı
ile depolanması sayesinde, bu bilgilerin kullanıcılar ve yöneticiler tarafından kolayca
bulunması ve kullanılması sağlanmıştır.
COM ve DCOM’un önemli olduğu başka bir alan da veritabanı erişimidir.
Microsoft’un geliştirdiği OLE DB, veritabanları arasındaki işlemlerin nasıl olması gerektiğini
67
ve uygulamaların nasıl veritabanlarına bağlanacaklarını belirler. OLE DB, herhangi bir veri
haznesinin veriyi bir cetvel (tabular) biçiminde göstermesine izin veren bir bileşen kümesi
sağlar. OLE DB’nin ODBC’nin yerini alması düşünülmemiştir. Hatta OLE DB, ODBC
üzerinden ilişkisel veritabanlarına bağlanır.
COM ve DCOM mimarilerini takiben, bu teknolojilerin gelişimlerinin bir evresi
olarak kabul edilebilecek olan COM+ ve .NET teknolojileri piyasaya çıkmıştır. Şimdi bu iki
teknolojiye biraz daha yakından bakarak, getirdikleri yeniliklere göz atalım.
3.4.1. COM+
COM+, Microsoft Visual Studio 6.0 ile ilk defa ortaya çıkmış ve Windows2000’de
ağırlıklı olarak kullanılmaya başlanmıştır. COM+’ın getirdiği yenilikler şunlardır:
Yayınlama ve abonelik servisi: Birden çok istemcinin yayınlamış çeşitli olaylara
abone olmalarını sağlayan genel bir olay mekanizması sağlar. Yayıncı bir olayı harekete
geçirdiğinde, COM+ olay sistemi, abonelik veritabanı vasıtasıyla tüm abonelere haber verir.
Kuyruğa atılmıĢ bileĢenler: İstemcilerin COM bileşenleri üzerinde asenkron
modeli kullanarak yöntemleri çağırmasına izin verir. Böyle bir model, güvenilir olmayan
ağlarda ve bağlantısız kullanım senaryolarında kullanılabilir.
Dinamik yük dengeleme: İstemci isteklerini eşdeğer COM bileşenlerine otomatik
olarak dağıtır.
MTS’nin COM’da tam entegrasyonu: Nitelik tabanlı programlama, hareketler
gibi varolan servislerden istifade etmek, güvenlik ve yönetim için daha geniş destek içerir.
Aynı zamanda desteklediği TIP (Transaction Internet Protocol) sayesinde başka hareket
tabanlı ortamlarla birlikte çalışabilirliği arttırır.
3.4.2. .NET
2000 yılında sözü edilmeye başlanan bu kavram, ilk olarak WindowsXP işletim
sisteminde kullanılmaya başlanmıştır. Visual Studio.NET yazılım geliştirme araçları .NET
tabanlı yazılım geliştirmeyi destekler. Yakın bir zamanda .NET tabanlı çalışan Windows.NET
ve Office.NET ile de tanışacağız.
.NET’in getirdiği yenilikler arasında şunları sayabiliriz:
.NET yazılım geliştirme sürecinde verimi ve esnekliği artıracak bir çok olanak
sağlamaktadır.
68
.NET ile yazılım geliştirmek için COM ile gerçekleştirilen yatırımlardan vazgeçme
zorunluluğu yoktur. Aksine .NET sayesinde mevcut altyapı değiştirilmeden yeni projeler
tasarlanabilir, ve COM temelli yazılımlar uzun süre kullanılabilir.
COM ve .NET arasında gerekli iletişim .NET tarafından otomatik olarak
sağlanmakta, ve bu konuda kullanıcıya fazla bir iş düşmemektedir.
COM hataları belirlemek için fonksiyonlardan dönen kodları kullanırken, .NET
exception handling üzerine kurulu bir error handling mekanizması kullanmaktadır.
69
4. CORBA - DCOM KARġILAġTIRMASI
Bir COM sunucusu, birden çok nesne sınıfının nesne örneklerini yaratabilir. Bir COM
nesnesi, her biri nesnenin farklı bir görünümünü veya davranışını temsil eden birden çok
arayüz destekleyebilir. Bir arayüz, fonksiyonellikle ilgili bir yöntemler kümesinden ibarettir.
Eğer nesne istemcinin adres uzayında yer alıyorsa, bir COM istemcisi bir COM nesnesi ile, o
nesnenin arayüzlerine doğru olan bir işaretçiyi elde ederek etkileşime girer, ve bu işaretçi
üzerinden yöntemleri başlatır. COM, C++ sanal fonksiyon tablosunda olduğu gibi, herhangi
bir arayüzün standart hafıza planını takip etmesini zorunlu kılar. Tanımlama ikili seviyede
olduğundan, C++, Java ve Visual Basic gibi faklı dillerde yazılması muhtemel ikili
bileşenlerin entegrasyonuna izin verir.
Bir CORBA nesnesi, dış dünyaya bir yöntemler kümesi ile bir arayüz vasıtasıyla
anlatılır. Bir nesnenin belirli bir örneği, bir nesne referansı ile tayin edilir. Eğer nesne
istemcinin adres uzayında yer alıyorsa, bir CORBA nesnesinin istemcisi, kendi nesne
referansını elde eder ve bunu yöntem çağrıları yapmak için kullanır. Nesnenin yürütmesinin
bulunması, isteği alması için hazırlanması, isteğin onunla haberleşmesi, ve eğer varsa yanıtın
istemciye taşınması için gerekli tüm mekanizmalardan ORB sorumludur. Nesne yürütmesi, ya
bir Nesne Adaptörü, yada ORB arayüzü vasıtasıyla ORB ile etkileşime girer.
Hem DCOM hem de CORBA, istemci-sunucu tipi haberleşmeleri sağlarlar. Bir
istemci, bir servise istek yapmak için, istemci-sunucu modelinde sunucu olarak rol oynayan
bir uzak nesne tarafından yürütülen bir yöntemi başlatır. Sunucu tarafından sağlanan servis bir
nesne olarak korunur ve bir nesnenin arayüzü bir IDL’de tanımlanır. IDL dosyasında
tanımlanan arayüzler, bir sunucu ile istemcileri arasında bir anlaşma vazifesi görür. İstemciler
IDL’de tanımlanan yöntemleri başlatarak bir sunucu ile etkileşime girerler. Gerçek nesne
yürütmesi istemciden saklanır. Veri korunması, polymorphism ve tekli miras gibi bazı
nesneye yönelik programlama özellikleri IDL düzeyinde vardır. CORBA, IDL düzeyinde
çoklu miras özelliğini de destekler, ama DCOM desteklemez. Bunun yerine, DCOM aynı
amaç için birden çok arayüze sahip nesne kavramını kullanır. CORBA IDL’de istisnai hatalar
da tanımlıdır (exceptions).
Hem DCOM’da hem de CORBA’da, bir istemci işlemi ile bir nesne sunucusu
arasındaki etkileşimler nesneye yönelik RPC tipi haberleşmelerle yürütülür. ġekil 4.1, tipik
bir RPC yapısını gösterir. İstemci, uzak fonksiyonu başlatmak için, istemci stub’a bir çağrı
yapar. Stub, çağrı parametrelerini bir istek mesajı içine paketler, ve mesajı sunucuya iletmek
70
için bir tel protokolü başlatır. Sunucu tarafında, tel protokolü mesajı sunucu stub’ına iletir.
Sunucu stub’ı mesajın paketini açar ve nesnedeki gerçek fonksiyonu çağırır. DCOM’da istem-
ci 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.
ġekil 4.1. RPC Yapısı
CORBA ve DCOM mimarilerinin ayrıntılı yapıları sırasıyla ġekil 4.2 ve ġekil 4.3’te
gösterilmiştir. Sonraki bölümlerde, hem DCOM’da hem de CORBA’da yürütülmüş bir örneği
inceleyecek, ve şekillerde görülen üç farklı katman üzerinde nesne aktivasyonlarının ve
yöntem çağrılarının adım adım tanımlamalarını vereceğiz. Üst katman, istemci ve nesne
sunucusu programlarının geliştiricilerinin gördüğü temel programlama mimarisi’dir. Ara
katman, arayüz işaretçilerinin ve nesne referanslarının farklı işlemler üzerinde anlamlı
olmasını sağlayan eriĢim mimarisi’dir. Alt katman ise, erişim mimarisini farklı makineler
üzerinde çalışabilecek şekilde genişleten tel protokol mimarisi’dir.
ġekil 4.2. CORBA Mimarisi
İstemci Sunucu
istemci stub’ı
tel protokolü
Ağ
sunucu stub’ı
tel protokolü
Ara Katman
Alt Katman
Üst Katman
işlem()
yanıt
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
istemcistub’ı
(proxy)
ORB
TCP Soketi
Nesne İskeleti
ORB
CORBAkütüphanesi Nesne Adaptörü
(CORBA kütüphanesi)
ORB(ler) (orbixd) &Yürütme Ambarı
Nesne
71
ġ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
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
nesneproxy
SCM
RPC Kanalı
Sınıf Fabrikası
SCM
COMKütüp-hanesi
COM Kütüp-hanesi
SCM(ler) &Registry
Nesne
nesnestub’ı
arastub
OXIDnesnesi
Registry Registry
araproxy
Nesne ihracatçısı
OXIDçözümleyicisi
OXIDçözümleyicisi
sunucu pingistemci ping
72
(3) grid arayüzü: grid1’den ve grid2’den mirasları biraraya getirmek için
DCOM’da ise iki arayüz tanımlanmıştır:
(1) IGrid1 arayüzü: get() ve set()için
(2) IGrid2 arayüzü: reset() için
DCOM’da, Grid nesnesinin yürütmesi, iki arayüzlü bir nesneyi yürümek için,
IGrid1 ve IGrid2’den çoklu miras alma özelliğini kullanır. CORBA’da olduğu gibi,
arayüz tekli miras özelliğini kullanarak, tüm yöntemleri bir arayüzde bir araya getirebilirdik.
Ama DCOM birden çok arayüze sahip nesnelere verdiği destek, bir nesnenin her ayrık
özelliğinin farklı arayüzlerde olmasına izin verir.
Her yürütme için, kaynak kodları 5 dosya halinde yazılmıştır. Gösterimi basitleştirmek
için sadece gerekli kodlar gösterilecektir. Tablo 4.1’de gösterilen ilk dosya, arayüzlerin ve
yöntemlerinin tanımlandığı IDL dosyasıdır. DCOM IDL dosyası, coclass kısmında
görüldüğü gibi, bir nesne sınıfı ile birden çok arayüzü ilişkilendirir. DCOM’da da,
CORBA’da da, Bir IDL dosyasını bir IDL derleyicisinden geçirmek, proxy/stub/iskelet
kodunu ve hem sunucu hem de istemci tarafından kullanılan arayüz başlık dosyasını
(grid.h veya grid.hh) oluşturur. DCOM’da her arayüzün bir arayüz belirleyicisi (IID –
Interface ID) denilen UUID’ye atandığına dikkat edin. Benzer bir şekilde, her nesne sınıfı da
tekil bir sınıf belirleyicisine (CLSID) atanır. Aynı zamanda, her COM arayüzü IUnknown
arayüzünden miras alınmış olmalıdır. Bu arayüz, aynı nesnenin farklı arayüzleri arasında
gezinmek için kullanılan QueryInterface() yönteminden, ve referans sayımı için
kullanılan AddRef() ve Release() yöntemlerinden oluşur. DCOM’u anlatırken de
belirtildiği gibi, nesne sayımı, bir COM nesnesinin istemcilerinin izini takip etmesine yarayan
bir yaşam zamanı kontrol mekanizması sağlar, ve artık gerekli olmadığında kendisini siler.
Tablo 4.2’de gösterilen ikinci dosya, sunucu yürütme sınıfının arayüzlerden nasıl
türetildiğini gösteren, yürütme başlık dosyasıdır. DCOM dosyası, sık sık kullanılan ama
gerekli olmayan, bir sınıf fabrikasının (CClassFActory) tanımını da içerir. Önceden
söylediğimiz gibi, CGrid yürütme sınıfı, IDL’den oluşan arayüz başlık dosyasında
(grid.h) tanımlanan, iki saf soyut temel sınıftan mirasları alarak biraraya getirir. CGrid
sınıfında, AddRef() referans sayısını arttırırken, Release() azaltır. Referans sayısı sıfıra
düştüğünde, sunucu nesnesi kendini siler. Bu da sıklıkla kullanılır ama gerekli değildir.
Sonuçta, sunucu nesnesi kendi yaşam zamanını kontrol eder.
73
CORBA yürütmesinde, IDL derleyicisi grid arayüz sınıfını, grid.hh başlık
dosyasında arayüz tanımından faydalanarak oluşturur. Uygulama geliştirici yürütme sınıfı
grid_i’yi yazar. Yürütme sınıfını arayüz sınıfı ile ilişkilendirmenin iki yolu vardır; miras
yaklaşımı veya delegasyon yaklaşımı. Bu örnekte miras yaklaşımı kullanılmıştır. Bu
yaklaşımda, Orbix’teki IDL derleyicisi, iskelet sınıfını örneklendirmekle (instantiating)
yükümlü olan gridBOAImpl adlı bir sınıf oluşturur. gridBOAImpl sınıfı,
CORBA::Object sınıfından miras alan grid sınıfından miras alır. grid_i yürütme sınıfı,
arayüz sınıfı ile yürütme sınıfı arasındaki eşleşmeyi tamamlamak için gridBOAImpl
sınıfından miras alır. POA (Portable Object Adaptor) geliştirilmeden önce, CORBA iskelet
sınıfının neye benzeyeceğini ve temel sınıfın ismini belirlemediği için, bu sınıf sadece Orbix’e
özeldir. POA’nın geliştirilmesiyle, bu problem giderilmiş, ve temel sınıf için bir isim
belirlenmiştir. Bu örnekte POA kullanılsaydı, temel sınıfın ismi POA_grid olacaktı.
Tablo 4.3’te gösterilen üçüncü dosya, sunucu sınıfın yöntemlerini yürütür. DCOM
dosyası aynı zamanda sınıf fabrikasının bazı yöntemlerini de yürütür. Tablo 4.4’te gösterilen
dördüncü dosya, sunucu için ana programdır. DCOM programı, tüm aktif sunucu nesneleri
silindiğinde uyaracak ve sunucunun kapanmasını sağlayacak bir olay (event) yaratır ve bu
olayda bekler. Gerçek istemci çağrıları, bir thread havuzundaki farklı thread’ler tarafından
aynı anda elde edilir. (Başka bir DCOM thread modeli, tek bir thread kullanarak istekleri seri
olarak elde eder.)
Benzer şekilde, CORBA sunucu programı grid_i sınıfının bir örneğini (instance)
örneklendirir (instantiate), ve gelen istemci isteklerini almak için impl_is_ready()’de
durur. Eğer sunucu varsayılan zaman aşımı içinde herhangi bir istek almazsa kapanır. İstemci
istekleri, nesne sunucusu için kullanılan aktivasyon politikasına bağlı olarak, seri olarak veya
farklı thread’ler vasıtasıyla elde edilir.
Tablo 4.5’te gösterilen son dosya istemci kodudur. Ek IUnknown yöntem çağrıları
yüzünden, DCOM kodu CORBA kodundan daha uzundur. Java veya Visual Basic’te yazılan
DCOM istemcileri, sanal makine katmanı IUnknown yöntem çağrıları ile ilgilendiği ve
onları programcılardan gizlediği için, daha kısa olabilir. C++ istemcisinde de, referans
sayımını gizlemek için akıllı arayüz işaretçileri kullanılabilir.
Programları derledikten sonra ve çalıştırmadan önce, hem DCOM hem de CORBA
sunucu için bir kayıt işlemine ihtiyaç duyar. CORBA’da, arayüz ismi ile sunucu EXE’sinin
yol (path) ismi arasındaki ilişki yürütme ambarında (implementation repository) tutulur.
74
DCOM’da, CLSID ile sunucu EXE’sinin yol (path) ismi arasındaki ilişki registry’de tutulur.
DCOM arayüz proxy/stub’ı da bir COM nesnesi olduğundan, DLL biçimindeki bağlı olduğu
sunucusu da benzer şekilde kayıt edilmelidir.
Yer darlığından, derleme zamanında (compile-time) statik tip bilgisine ihtiyaç
duymayan dinamik çağrılara değinmedik. DCOM’da, arayüz yöntemleri için tip bilgileri, IDL
derleyicisi tarafından oluşturulan bir tip kütüphanesi’nde saklanır. IDispatch arayüzü
vasıtasıyla dinamik çağrı yapmak için kullanılabilir. Tip kütüphanesi güdümlü dönüĢtürme
(Soysal bir dönüştürücü, bir arayüze özel bir bilgi içeren ayrı bir proxy/stub DLL’i kullanmak
yerine, tip kütüphanesi bilgisini okuyarak dönüştürmeyi yapabilir.) için de kullanılabilir.
CORBA’da, IDL derleyicisi bir arayüzdeki her yöntem için tip bilgisini oluşturur, ve arayüz
ambarı’nda saklar. İstemci arayüz ambarını ilgili bir arayüzle ilgili çalışma zamanı bilgisini
almak için sorgulayabilir, ve bu bilgiyi dinamik çağrı arayüzü vasıtasıyla dinamik olarak
nesne üzerindeki bir yöntemi yaratmak ve başlatmak için kullanabilir. Benzer şekilde, sunucu
tarafındaki dinamik iskelet arayüzü, yürüttüğü nesnenin tipinin derleme zamanı bilgisi
olmayan nesne üzerindeki bir işlemin, bir istemci tarafından başlatılmasına izin verir.
DCOM IDL CORBA IDL
// IGrid1’in tanımlanması ve uuid
[ object,
uuid(3CFDB283-CCC5-11D0-BA0B-00A0C90DF8BC),
helpstring("IGrid1 Interface"),
pointer_default(unique)
]
interface IGrid1 : IUnknown {
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);
};
// 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 grid1
{
long get(in short n, in short m);
void set(in short n, in short m, in long value);
};
interface grid2
{
void reset(in long value);
};
// arayüzlerin çoklu miras alma olayı
interface grid: grid1, grid2
{
};
Tablo 4.1. IDL (Arayüz Tanımlama Dili) dosyaları
75
DCOM sunucu sınıf tanımı (cgrid.h) CORBA sunucu sınıf tanımı (grid_i.h)
#include "grid.h" // 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;
};
#include "grid.hh" // IDL tarafından oluşturulan arayüz
// başlık dosyası
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"
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;
}
#include "grid_i.h"
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;
}
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;
}
extern HANDLE hevtDone;
CGrid::~CGrid () {
for (int i=0; i < m_height; i++)
delete[] m_a[i];
delete[] m_a;
SetEvent(hevtDone);
}
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];
}
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;
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();
}
#include "grid.hh"
void main (int argc, char **argv)
{
grid_var gridVar;
CORBA::Long value;
// "grid" nesnesine bağlanma (Orbix’e özel)
gridVar = grid::_bind(":grid");
value = gridVar->get(0, 0);
gridVar->reset(value+1);
}
Tablo 4.5. İstemci ana progamları
77
4.2. Üst Katman: Temel Programlama Mimarisi
Üst katmanda, DCOM’un ve CORBA’nın programcılar için olan görünümü yer alır.
Bir istemcinin bir nesneye nasıl istek yapacağı ve yöntemlerini çağıracağı, ve bir sunucunun
nasıl bir nesne örneğini yaratacağı ve istemci için hazır hale getireceği bu katmanda
açıklanacaktır. Gerçekte istemcinin sunucuya nasıl bağlanacağı programcılardan tamamen
gizlenmiştir. İstemci ve sunucu programları aynı makinedeki aynı adres alanında yer
alıyorlarsa etkileşirler. Bu katmandaki DCOM ile CORBA arasındaki temel farklardan biri,
istemcinin arayüzü nasıl tanımlayacağı, diğeri de COM’un sınıf fabrikaları ve IUnknown
yöntemleridir. Tablo 4.6’da adım adım karşılaştırma verilmiş, ġekil 4.4’te DCOM için, ġekil
4.5’te de CORBA için gösterilmiştir. (Parantez içindeki numaralar nesne aktivasyon adımları
için, köşeli parantez içindekiler ise yöntem çağrı adımları içindir.)
Her ne kadar Tablo 4.6 genel bir DCOM çağrı sırası verse de, iki noktaya değinmek
gerekmektedir. Bunlardan ilki, COM’da sınıf fabrikası kullanımının seçime bağlı olmasıdır.
Bir sunucu nesnesi gerçekte herhangi bir arayüz işaretçisini kaydetmek için
CoRegisterClassObject() nesnesini çağırır, ve istemciler bu işaretçiyi kazanmak için
CoGetClassObject() adında başka bir COM API’sini çağırabilirler. İkinci önemli nokta
ise, CoCreateInstance() yeni bir boş örnek yaratamaz. Bir sunucu,
IClassFActory::CreateInstance() içinde, farklı istemcilerin aynı nesne örneğine
belirli bir durumda bağlanabilmelerini sağlamak için, her zaman aynı arayüz işaretçisini
döndürmeyi seçebilir. İsimlendirilmiş sunucu nesne örneğine bağlanmanın başka bir yolu da
moniker’ları ve/veya Çalışan Nesne Tablolarını (ROT – Running Object Table) kullanmaktır.
CORBA’da bir nesne, varolan bir nesne referansındaki herhangi bir yöntemin
çağrılması ile aktif hale getirilir. Bazı üreticiler özel yöntem çağrıları sağlarlar. Örneğin
Orbix’te _bind() işlemi bir sunucu nesnesini aktif hale getirir ve nesne referansını elde
eder. Eğer istenilen tipe uyan varolan bir örnek varsa, istemci yeni bir örnek yerine varolan bu
örneğe eklenebilir. Bir istemci, bir nesne referansını object_to_string() kullanarak
karakterlere dönüştürüp saklayabilir, ve daha sonra string_to_object() ile tekrar eski
haline dönüştürerek kullanabilir.
DCOM ile CORBA arasındaki programlama katmanı farklarından bir diğeri de,
istisnai hataları ele alma biçimleridir. CORBA standart C++ hatalarını ve CORBA’ya özel
bazı hataları destekler. Buna ek olarak, kullanıcı tanımlı istisnai hataların da IDL içinde
tanımlanmasına izin verir. IDL derleyicisi kullanıcı tanımlı istisnai hata ile bir C++ sınıfını
78
eşleştirir. Bunun aksine, DCOM tüm yöntemlerin HRESULT adı verilen 32-bit’lik hata kodu
döndürmesine ihtiyaç duyar. Dil/araç katmanında, bir anlaşmalar ve sistem destekli servisler
kümesi (IErrorInfo nesnesi), hatalı HRESULT’ların dile özgü bir biçimde istisnai hatalara
dönüştürülmesine izin verir. Örneğin Microsoft Visual C++’ta, istemci programcıları standart
C++ try/catch bloklarını kullanarak COM yöntem çağrılarından hataları yakalayabilirler.
Derleyici hatalı dönüş kodunu bir istisnai hataya dönüştürerek, HRESULT’ı
IErrorInfo’nun doğru kullanımı ile eşleştirir. DCOM tel protokolü, body extensions diye
bilinen zengin istisnai hata bilgisinin taşınmasına izin veren bir mekanizma içerir.
DCOM CORBA
Nesne Aktivasyonu
1. İstemci COM kütüphanesinin
CoCreateInstance()’ını CLSID_Grid
ve IID_IGrid1 ile çağırır.
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.
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.
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. ORB grid için nesne referansını
gridVar olarak istemciye geri
döndürür.
79
Yöntem Çağrımı
1. İstemci ilerde sunucuda
CGrid::get()’i çağıracak olan
pIGrid1->get()’i çağırır.
2. Aynı nesne örneğinin başka bir
IID_IGrid2 arayüzüne bir işaretçi
sağlamak için, istemci
CGrid::QueryInterface’i çağıran
pIGrid1->QueryInterface()’i
çağırır.
3. pIGrid1’in kullanımı bittiğinde
istemci, CGrid::Release()’i
çağırmayabilecek olan
pIGrid1->Release()’i çağırır.1
4. İstemci CGrid::reset()’i çağıran
pIGrid2->reset()’i çağırır.
5. İstemci CGrid::Release()’i
çağıran pIGrid2->Release()’i
çağırır.
1. İstemci ilerde sunucuda
grid_i::get()’i çağıracak olan
GridVar->get()’i çağırır.
2. İstemci grid_i::reset()’i çağıran
GridVar->reset()’i çağırır.
Tablo 4.6. Üst katman tanımlaması
ġ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.
Erişim Katmanı
Temel Programlama Katmanı
İstemci Sunucu
Sınıf Fabrikası
COMKütüp-hanesi
COM Kütüp-hanesi
COM çalışma zamanı
sistemi
Nesne
(4)
(1) (2)
(3) (5)(6)
[1] [2] [3]
[4] [5]
80
ġekil 4.5. Üst katmandaki CORBA adımları
4.3. Ara Katman: EriĢim Mimarisi
Altyapıdan oluşan ara katman istemciyi ve sunucuyu aynı adres alanında olduklarına
inandırmak için gereklidir. Tablo 4.7’deki tanımlama, farklı işlemler üzerinde bir yöntem
çağrımı meydana geldiğinde, altyapının istek yapılan sunucuya ve içerdiği varlıklara nasıl
eriştiğini ve onu nasıl başlattığını gösterir. DCOM için ġekil 4.6’da, CORBA için de ġekil
4.7’de ilgili çizimler verilmiştir. Bu katmanda CORBA ile DCOM arasındaki en önemli
farklar; sunucu nesnenin nasıl kaydedileceği ve proxy/stub/iskelet örneklerinin ne zaman
yaratılacağı konularını içerir.
Verinin farklı adres alanları üzerinde aktarımı, dönüştürme (marshaling) ve geri
dönüştürme (unmarshaling) denilen bir işlem gerektirir. Dönüştürme, bir yöntem çağrımının
parametrelerinin istemcinin alanında, veya geri dönüş değerlerinin sunucunun alanında,
taşıma için standart biçimde paketlenmesidir. Geri dönüştürme ise, gelen işlemin adres
alanında, bu paketlerin açılarak ilgili veri biçimine dönüştürülmesidir. Bu bölümde anlatılan
dönüştürme DCOM terminolojisinde standart dönüştürme olarak geçer. DCOM, standart
dönüştürme prosedürünün haricinde bir özel dönüştürme mekanizması da içerir. Bir sunucu
nesnesi, bir IMarshal arayüzünü yürüterek, hangi verinin ve nasıl dönüştürüleceği ve geri
dönüştürüleceğini, ve istemcinin sunucuyla nasıl iletişim kurması gerektiğini kontrol etmek
istediğini beyan eder.
Tablo 4.7’de kullanılan bazı CORBA terimlerini açıklayalım. Nesne adaptörünün
nesne yürütmeleri ile ORB arasındaki haberleşmeden sorumlu olduğunu 2. bölümde (2.2.11)
görmüştük. Nesne adaptörleri, nesne referanslarının oluşturulması ve izahı, yöntem çağrıları,
nesne aktivasyonu, ve nesne referansları ile yürütmelerin eşlenmesi ile ilgili servisler
sağlarlar. Farklı nesne yürütme biçimlerinin farklı ihtiyaçları vardır, ve farklı nesne
Erişim Katmanı
Temel Programlama Katmanı
İstemci Sunucu
istemci stubCOM
Kütüp-hanesi Nesne Adaptörü
ORB
Nesne(4)(1)
(2) (3)
[1] [2]
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.1
2. ORB grid ile sunucusunun yol
ismini eşleştirmek için Yürütme
Ambarına danışır, ve sunucuyu
aktive eder (Orbix’te, orbixd
cini sunucu işlemini ayırır).
3. Sunucu, 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.
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.
6. Nesne stub’ı arayüz işaretçisini
dönüştürür, IID_IGrid1 için bir
arayüz stub’ı yaratmak için
registry’e danışır, ve sunucu
nesnesinin gerçek IID_IGrid1
arayüzü ile onu ilişkilendirir.
7. SCM, dönüştürülmüş işaretçiyi
istemci tarafına geri
taşıdığında, COM nesne örneği
için bir nesne proxy’si yaratır.
8. Nesne proxy’si işaretçiyi geri
dönüştürür, IID_IGrid1 için bir
arayüz proxy’si yaratmak üzere
registry’e danışır, ve onu stub’a
bağlı olan RPC kanal nesnesi ile
ilişkilendirir.
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.
4. grid_i sınıfı için constructor
iskelet sınıfının örneğini de
yaratır.1
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.
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.
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çi-
sinin 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.
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.
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.
5. gridVar->reset() çağrısının
gelmesi üzerine, proxy benzer bir
prosedür takip eder.
Tablo 4.7. Ara katman tanımlaması
84
ġekil 4.6. Ara katmandaki DCOM adımları
ġ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
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
nesneproxy
RPC Kanalı
Sınıf Fabrikası
COMKütüp-hanesi
COM Kütüp-hanesi
SCM(ler) &Registry
Nesne
nesnestub’ı
arastub
araproxy
arastub
araproxy
SınıfNesne
Tablosu
(2)
(3)
(4)
(5)
(6)
(1)
[1][2]
[3]
[4]
[5][6]
(7)(8)
(9)
[7]
[8]
[9]
[10][11]
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
istemcistub’ı
(proxy)
İletişim Kanalı
Nesne İskeletiCORBA
kütüphanesiNesne Adaptörü
ORB(ler) (orbixd) &Yürütme Ambarı
Nesne
(2)
(3)
(4)
(5)
(6)
(1)
[1] [2]
[3][4]
85
referanslarının sunucunun son nokta (endpoint) bilgisini istemciye taşınması için nasıl
gösterileceği, ve bir heterojen ortamdaki aktarım için dönüştürülen verideki standart biçim
konularını içerir.
CORBA, aynı firma tarafından sağlanmış ORB’ler üzerinde çalışan bir nesne
sunucusu ile bir istemci arasındaki iletişim için bir protokol belirlememiştir. Aynı firma
ORB’ları arasındaki ORB’lar arası iletişim için protokol, firmaya bağımlıdır. Ama, farklı
ORB ürünlerinin birbirleriyle etkileşebilmelerini sağlamak üzere, bir Genel ORB’lar arası
protokol (GIOP - General Inter-ORB Protocol) belirlenmiştir. GIOP’un TCP/IP bağlantıları
üzerindeki spesifik bir eşlenmesi tanımlanmıştır, ve IIOP (Internet Inter-ORB Protocol) olarak
bilinir. CORBA için, hem IIOP hem de Orbix yürütmeleri için tanımlamalar verilmiştir.
DCOM tel protokolü birkaç istisna dışında, çoğunlukla OSF DCE RPC tanımlamasına
dayandırılmıştır. Uzak nesne referans gösterimini, uzak IUnknown yöntem çağrılarının
performansını en iyi hale getirmek için bir IRemUnknown arayüzünü, ve bir ping’leme
protokolünü içerir. 3. bölümde de değindiğimiz gibi ping’leme, uzak istemci anormal bir
şekilde sonlandığında, sunucu nesnesinin uzak nesne referanslarının artıklarını toplamasına
izin verir. Bir istemci ilk defa uzak bir nesneye işaretçi elde ettiğinde, istemci makinesindeki
ping istemci kodu nesneyi bir ping listesine ekler, ve istemcinin hala hayatta olduğundan
haberdar etmek için periyodik olarak sunucu makineye ping gönderir. Ardışık ping’lerin
önceden tanımlanmış sayıdaki bir kaybı, istemcinin anormal bir biçimde sonlandığını, ve
tuttuğu arayüz işaretçilerin bırakılabileceğini gösterir. Performansı en iyi seviyeye getirmek
için, ping’ler makine bazlı ve artan bir sırada gönderilir. Normal mesajların içine gömülü de
olabilirler. Gerektiğinde, ağ trafiğini azaltmak için ping işlevi kapatılabilir.
DCOM CORBA
Nesne Aktivasyonu
1. Havale edilen CoCreateInstance()
isteğinin gelmesi üzerine, eğer
istemci tarafı SCM yerel
registy’e danıştığında grid
nesnesinin farklı bir sunucu
makinesine yerleştirilmesi
gerektiğini görürse, sunucu
tarafı SCM üzerindeki
IRemoteActivation RPC arayüzünün
bir yöntemini çağırır.
1. Havale edilen grid::_bind()
isteğinin gelmesi üzerine,
istemci tarafı ORB gridi
destekleyen makineyi seçmek için
bir yer belirleyici dosyaya
danışır ve TCP/IP üzerinden
sunucu tarafı ORB’ye bir istek
gönderir.
86
2. Sunucu, sunucu tarafı SCM
tarafından başlatıldığında, bir
nesne ihracatçısı ile
eşleştirilir, ve bir nesne
ihracatçısı belirleyicisine
(OXID) atanır. OXID ile sunucuya
ulaşmak için kullanılabilecek RPC
bağı eşleştirilmesi, sunucu
tarafı OXID tasarlayıcısı ile
kaydedilir.
3. Nesne stub’ı CreateInstance()
tarafından döndürülen IID_IGrid1
işaretçisini dönüştürdüğünde,
işaretçi sunucu içinde tekil olan
bir arayüz işaretçi
belirleyicisine (IPID) atanır.
Bir nesne referansı da (OBJREF)
işaretçiyi temsil etmek için
yaratılır. Bir OBJREF, IPID,
OXID, OXID çözümleyicilerinin
adresleri (her protokole bir
tane) gibi bilgileri içerir.
4. Dönüştürülmüş arayüz işaretçisi,
sunucu tarafı ve istemci tarafı
SCM’lerinin üzerinden istemci
tarafına geri döndüğünde, nesne
proxy’si OBJREF’ten OXID ve OXID
çözümleyicilerinin adreslerini
çıkarır, ve yerel OXID
çözümleyicisinin
IOXIDResolver:ResolveOxid()
yöntemini çağırır.
5. İstemci tarafı IXID çözümleyicisi
OXID için bir tampon eşlemesinin
olup olmadığına bakar; yok ise,
kayıtlı RPC bağlantısını döndüren
sunucu tarafı OXID çözümleyicisi-
nin IOXIDResolver:ResolveOxid()
yöntemini çağırır.
6. İstemci tarafı çözümleyicisi
eşlemeyi tampona alır, ve nesne
proxy’sine RPC bağlantısını geri
döndürür. Bu, nesne ihracatçısına
bağlı olan bir RPC kanalını
yaratmak üzere, nesne proxy’sinin
kendisine ve arayüz proxy’lerine
bağlanmasına izin verir.
2. Sunucu, sunucu tarafı ORB
tarafından başlatıldığında, bir
grid nesnesi sunucu tarafından
örneklendirilir, CORBA::Object
constructor’ı çağrılır, ve
BOA::create() başlatılır.
BOA::create()’in içinde, BOA bir
soket son noktası (endpoint)
üretir, grid nesnesi sunucu
içinde tekil olan bir nesne
belirleyicisine atanır, arayüz ve
yürütme isimlerini, referans
belirleyicisini ve son nokta
adresini içeren bir nesne
referansı yaratılır. IIOP
protokolünde konuşan istemciler
için, sunucu bir makine ismi, bir
TCP/IP port numarası, ve bir
object_key içeren, birbirleriyle
etkileşebilen nesne referansı
(IOR – Interoperable Object
Reference) oluşturur. BOA nesne
referansını ORB ile kaydeder.
3. Nesne referansı istemci tarafına
geri döndüğünde, proxy son nokta
adresini çıkarır ve sunucuya bir
soket bağlantısı kurar.
87
Yöntem Çağrımı
1. pIGrid1->get() çağrısının gelmesi
ü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.
5. havale edilen
pIGrid1->QueryInterface()
çağrısının gelmesi üzerine, nesne
proxy’si hedef nesne ihracatçı-
sındaki OXID nesnesi1 üzerinde
IRemUnknown::RemQueryInterface()
yöntemini çağırır. OXID nesnesi
daha sonra QueryInterface()
yöntemini ihracatçı içindeki
arayüzler (muhtemelen birden çok
olurlar) üzerinde çağırır.
6. havale edilen pIGrid1->Release()
çağrısının gelmesi üzerine, nesne
proxy’si hedef nesne ihracatçı-
sındaki OXID nesnesi üzerinde
IRemUnknown::RemRelease yöntemini
çağırır. OXID nesnesi daha sonra
Release() yöntemini ihracatçı
içindeki arayüzler üzerinde
çağırır.
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.
Tablo 4.8. Alt katman tanımlaması
1 Her nesne ihracatçısı için bir OXID vardır. Her OXID nesnesi RemQueryInterface(), RemAddRef(),
ve RemRelease() yöntemlerinden oluşan bir IRemUnknown arayüzünü destekler. Bu yöntemler performansı
arttırmak için, aynı nesne ihracatçısına tahsis edilen birden çok uzak IUnknown yöntem çağrılarına izin verirler.
Bu tip çağrıların hepsi ilk önce OXID nesnesi tarafından elde edilir, ve daha sonra hedef arayüze yönlendirilir.
Bu ve diğer alt katman API’leri aslında yürütme detaylarıdırlar. Uygulama programcıları bunlarla
karşılaşmazlar.
88
ġekil 4.8. Alt katmandaki DCOM adımları
ġekil 4.9. Alt katmandaki CORBA adımları
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
nesneproxy
SCM
RPC Kanalı
Sınıf Fabrikası
SCM
COMKütüp-hanesi
COM Kütüp-hanesi
Nesne
nesnestub’ı
arastub
OXIDnesnesi
Registry Registry
araproxy
Nesne ihracatçısı
OXIDçözümleyicisi
OXIDçözümleyicisi (2)
(3)
(4)
(5)
(6)
(1)
[1]
[2]
[3]
[4]
[5]
[6]
OBJREF
OXID
Tel Katmanı
Temel Programlama Katmanı
Erişim Katmanı
İstemci Sunucu
istemcistub’ı
(proxy)
ORB
TCP Soketi
Nesne İskeleti
ORB
CORBAkütüphanesi
Nesne Adaptörü
Nesne
(2)
(3)
(1)
[2]
[3]
[4]
[1]
YürütmeAmbarı
yerleştirici
IOR
89
5. SONUÇLAR
Değişik zamanlarda, farklı platformlar ve farklı programlama dilleri ile, birbirinden
bağımsız olarak tasarlanmış yazılım bileşenlerinin, birlikte çalışabilmelerine imkan sağlayan
dağıtık nesne yönetimi mimarilerinin önümüzdeki yıllarda da kullanım oranlarının giderek
daha fazla artması beklenmektedir.
DCOM ve CORBA mimarilerinin geleceğine baktığımızda; COM ve DCOM’un .NET
altında çalışmaya devam edeceğini, ve CORBA’nın da MDA altında varlığını sürdüreceğini
söyleyebiliriz. Diğer dağıtık nesne yönetimi mimarilerinin, şu an için bu iki mimari ile
rekabet edebilecek seviyelerde olmadıklarını görmekteyiz.
Üç katmanlı adım adım tanımlamalar, DCOM ve CORBA mimarilerinin temel olarak
benzer olduklarını göstermiştir. Her ikisi de şeffaf aktivasyonlar ve uzak nesne erişimi için
dağıtık nesne altyapısı sağlar. Aralarındaki temel farklar şunlardır:
1. DCOM birden çok arayüzlü nesneleri destekler ve arayüzler arasında gezinmek
için QueryInterface() yöntemini sağlar. Bu aynı zamanda, bir nesne proxy’sinin (stub)
erişim katmanında birden çok proxy’i dinamik olarak yüklemesi fikrini ortaya çıkarır.
CORBA’da bunun yerine çoklu miras alma özelliği vardır.
2. Her CORBA arayüzü, nesne kaydı, nesne referans oluşumu, iskelet
örneklendirilmesi, gibi genel görevleri açık bir biçimde yerine getiren constructor olan
CORBA::Object’ten miras alır. DCOM’da, bu gibi görevler ya sunucu programları
tarafından üstü kapalı bir şekilde yerine getirilir, ya da DCOM çalışma zamanı sistemi
tarafından dinamik olarak elde alınır.
3. DCOM’un tel protokolü RPC’ye sıkı bir şekilde bağlanmıştır. CORBA bu konuda
serbesttir.
4. DCOM tanımlaması yürütme konusu olarak düşünülen ve CORBA tarafından
belirlenmeyen bir çok detayı içerir.
İki mimarideki birbirinin yerini tutan terimler, Temel Programlama Mimarisi, Erişim
Mimarisi ve Tel Mimarisi katmanları için ayrı ayrı olarak, Tablo 5.1’de özetlenmiştir.
90
DCOM CORBA
Üst katman: Temel Programlama Mimarisi
Temel sınıf IUnknown CORBA::Object
Nesne sınıf belirleyicisi CLSID arayüz ismi
Arayüz belirleyicisi IID arayüz ismi
İstemci tarafı nesne aktivasyonu CoCreateInstance() bir yöntem çağrısı/bind()
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
91
KAYNAKLAR
Microsoft, “MSDN – Microsoft Developer Network”, (http://msdn.microsoft.com)
Microsoft, 1998, “DCOM Architecture White Paper”, Microsoft
Microsoft, 2001, “Technical Introduction To DCOM”, The Dalmatian Group, Inc.,
(http://www.dalmatian.com/com_dcom.htm)
OMG, 2001, “The Common Object Request Broker: Architecture and
Specification”, OMG, Editorial Revision: CORBA 2.4.2 (http://www.omg.org)
RAJ, G. S., 1997, “A Detailed Comparison of CORBA, DCOM and Java/RMI”,
(http://www.execpc.com/~gopalan/misc/compare.html)
ROSENBERGER, J. L., 1998, “Teach Yourself CORBA In 14 Days”, SAMS
Publishing
ROY, M., EWALD, A., 1997, “Inside DCOM”,
(http://www.dbmsmag.com/9704d13.html)
VINOSKI, S., 1997, “CORBA: Integrating Diverse Applications Within Distributed
Heterogeneous Environments”, IEEE Communications Magazine,
VINOSKI, S., 1993, “Distributed Object Computing With CORBA”, C++ Report
Magazine
92
ÖZGEÇMĠġ
1976’da Bulgaristan’ın Varna şehrinde dünyaya gelen Altan Mesut, 1978’de
Türkiye’ye gelip İstanbul’a yerleşti. İlk öğrenimine İstanbul’da başlayıp, Edirne’de
tamamladı. Orta öğrenimini Edirne Anadolu Lisesi’nde 1994’te bitirdi. Aynı yıl İstanbul
Üniversitesi Bilgisayar Bilimleri Mühendisliği Bölümü’nü kazandı ve 1998’de bu bölümden
mezun oldu. Bir yazılım firmasında kısa süre çalıştıktan sonra, 1998 yılının Kasım ayında
Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü’nde araştırma görevlisi olarak göreve
başladı. 1999 yılında bu bölümde yüksek lisans eğitimine başladı ve 2002 yılında yüksek
lisansını tamamladı. 2005 yılında Trakya Üniversitesi Bilgisayar Mühendisliği Bölümü’ne
öğretim görevlisi olarak atandı ve halen bu görevini sürdürmektedir.
93
EKLER
EK-1 TERĠMLER
Terim Anlamı
Arayüz Bir fonksiyonellik gösteren belirli soyut işlerin (veya yöntemlerin) ismi olan bir kolleksiyonu.
Bileşen Dağıtık bir ağda bir uygulama oluşturmak için, aynı bilgisayarda yada farklı bilgisayarlarda bulunan diğer bileşenlerle birleştirilebilecek yapı bloğu.
Hareket Veritabanı bütünlüğünü sağlamak için bir birim gibi davranan ilgili işin (veritabanı güncelleme gibi) ve bilgi takasının bir serisi.
İstemci Bir nesnenin bir yöntemini çağıran bir işlem.
Miras Alma Bir alt sınıfın, türetildiği genel sınıf yada sınıfların tanımlamalarını, tekrar tanımlamaya ihtiyaç duymadan kullanabilmesi.
Nesne (Nesne Örneği) Bazı nesne sınıflarının örneklendirilmesi. Her nesne belirli bir sınıfın yada alt sınıfın bir örneğidir.
Sınıf (Nesne Sınıfı) Bir yada daha çok ismi olan somut bir yürütmesi.
Stub Büyük bir programın yerine geçebilen ufak bir program rutini. RPC’de stub, uzak prosedür ile isteği yapan program arasındaki iletişimi idare eder.
Sunucu (Nesne Sunucusu) Nesne örneklerini yaratma ve ev sahipliği yapmadan sorumlu işlem.
Thread Belirli bir servis isteğine veya bir kullanıcıya hizmet etmek için gerekli olan bilgi.
94
EK-2 KISALTMALAR
Kısaltma Açılımı Türkçesi
ACF Application Configuration File Uygulama Konfigürasyon Dosyası
ACL Access Control Lists Erişim Kontrol Listeleri
ASP Active Server Pages Aktif Sunucu Sayfaları
CILabs Component Integration Laboratories Bileşen Entegrasyon Laboratuarları
CLSID Class Identifier Sınıf Belirleyicisi
COM Component Object Model Bileşen Nesne Modeli
CORBA Common Object Request Broker Architecture Genel Nesne İstek Aracı Mimarisi
CWM Common Warehouse Meta-model Genel Depo Meta-modeli
DCE Distributed Computing Environment Dağıtık Hesaplama Ortamı
DCOM Distributed Component Object Model Dağıtık Bileşen Nesne Modeli
DII Dynamic Invocation Interface Dinamik Çağrı Arayüzü
DSI Dynamic Skeleton Interface Dinamik İskelet Arayüzü
EJB Enterprise JavaBeans Kurumsal JavaBeans
IDL Interface Definition Language Arayüz Tanımlama Dili
IIOP Internet Inter-ORB Protocol Internet ORB’lar arası Protokol
IID Interface Identifier Arayüz Belirleyicisi
IIS Internet Information Server Internet Bilgi Sunucusu
J2EE Java 2 Platform Enterprise Edition Java 2 Platformu Kurumsal Baskısı
J2SE Java 2 Platform Standard Edition Java 2 Platformu Standart Baskısı
LPC Local Procedure Call Yerel Prosedür Çağrısı
MDA Model Driven Architecture Model Güdümlü Mimari
MIDL Microsoft Interface Definition Language Microsoft Arayüz Tanımlama Dili
MOF Meta-Object Facility Meta-Nesne Vasıtası
MTS Microsoft Transaction Server Microsoft Hareket Sunucusu
NDR Network Data Representation Ağ Veri Gösterimi
OMA Object Management Architecture Nesne Yönetim Mimarisi
OMG Object Management Group Nesne Yönetim Grubu
ORB Object Request Broker Nesne İstek Aracı
OSF Open Software Foundation Açık Yazılım Kuruluşu
PDC Professional Developers Conference Profesyonel Geliştiriciler Konferansı
POA Portable Object Adapter Taşınabilir Nesne Adaptörü
RMI Remote Method Invocation Uzak Yöntem Çağrımı
ROT Running Object Table Çalışan Nesne Tablosu
RPC Remote Procedure Call Uzak Prosedür Çağrısı
SCM Service Control Manager Servis Kontrol Yöneticisi
SOM System Object Model Sistem Nesne Modeli
TIP Transaction Internet Protocol Hareket Internet Protokolü
UML Unified Modeling Language Birleştirilmiş Modelleme Dili
XMI XML Metadata Interchanger XML Meta-veri Takasçısı
XML Extensible Markup Language Uzatılabilir Biçimlendirme Dili
95
EK-3 TEKNOLOJĠK GELĠġĠM ZAMAN ÇĠZELGESĠ
1989 OMG kuruldu ve CORBA üzerinde çalışmalara başlandı.
1990 OMG, OMA'yı ve CORBA'yı olşturan temel parçaları tanımladı.
1992 DEC, HP, Hyperdesk, NCR, ODI, ve SunSoft'un katkılarıyla oluşturulan CORBA 1.1 tamamlandı.
IBM OS/2 2.0 tamamlandı. SOM adında CORBA 1.1 ile uyumlu olan bir nesne modeli de içeriyordu.
Apple, IBM ve Lotus OpenDoc'u geliştirmeye başladılar.
1993 Microsoft COM'un ilk sürümünü tamamladı.
OpenDoc CILabs tarafından lisaslandı. CILabs'ın ilk destekçileri Apple, IBM, Novell, Oracle, SunSoft, Taligent, WordPerfect, ve Xerox oldu.
IONA (kuruluşunda Trinity College'ın bir parçasıydı) ORBIX ürününü piyasaya sürdü.
1994 IIOP sayesinde farklı üreticilerin ORB'lerinin birlikte çalışabilmesini sağlayan CORBA 2.0 tamamlandı.
OMG öncülüğünde geliştirilen UML ilk şeklini aldı.
1995 COM tabanı üzerinde kurulu olan OLE'nin desteklendiği Windows 95 işletim sistemi piyasaya sürüldü.
OLE/COM tabanı üzerine kurulan, başlarda adı Network OLE olan mimarinin adının DCOM olacağı açıklandı.
SOMobjects IBM tarafından duyruldu.
1996 İlk JavaOne konferansında, JavaBeans tabanlı bileşenler duyruldu.
Mart ayındaki Internet PDC'de Microsoft, ActiveX'i duyurdu
ActiveX ile sıkı bir bağı bulunan DCOM'un özellikleri yayınlandı.
1997 Sun, JavaBeans Development Kit'i piyasaya sürdü.
Sun, RMI'ı içeren JDK 1.1'i piyasaya sürdü.
Sun, Enterprise JavaBeans (EJB) teknolojisini tanıttı.
Web uygulamaları için COM bileşenleri ile entegrasyon sağlayan ASP, IIS 3.0 ile birlikte piyasaya
sürüldü
1998 IIS 4.0, ASP 2.0 ve MTS 2.0 ile birlikte piyasaya sürüldü.
Visual Studio 6.0 ile birlikte COM+ ortaya çıktı.
1999 Sun J2EE'yi piyasaya sürdü. Java 2 platformu ile RMI ile IIOP entegre edildi, Java IDL, Java ORB ve CORBA desteği sağlandı.
2000 Microsoft, IIS 5.0 ve ASP 3.0'ı içeren Windows 2000'i piyasaya sürdü. Windows 2000 COM+ desteği de sağlıyordu.
IBM'in Web services, HP'nin e-speak, Sun'ın ONE, ve Microsoft'un .NET Web servislerini duyurması.
IBM, Java servlets, JavaServer Pages, XML, EJB bileşenleri, ve CORBA desteği sağlayan WebSphere'i piyasaya sürdü.
CORBA 2.4 özellikleri yayınlandı.
2001 CORBA 3.0 ve MDA çalışmalarına başlandı.
