KURUMSAL BİLGİ İŞLEMDE

CORBA

İlk Sürüm : Kasım 2000

Sürüm Adedi : 1
Son Sürüm : Kasım 2000

Prof.Dr. Oğuz Manas

BÖLÜM 1

CORBA (Commen Object Broker Architecture) Nedir ?

1.1 Genel tanıtım

Ortakyol Beyaz Kitapçığımızın Obje İstemcisi Klavuzu (Object Request

Broker-ORB) bölümünde CORBA’dan kısaca söz etmiştik. Bu Beyaz
Kitapçığımızda ise CORBA’yı daha ayrıntılı ele alacak ve özellikle
CORBA’nın ağ yönetimindeki yerini tanıtmaya çalışacağız..

Yazıma başlamadan önce Ağlar Arası İşlem (Interoperability) nin

geniş ve açık bir tarifini yapmak istiyorum. Her türlü yazılım yapıtaşlarının
(component) , bulunduğu yere , platform ‘a , isletim sistemine , programlama
diline veya ağ donanımı ve yazılımının vizyonuna bakmadan , birbirleriyle
yumuşak bir şekilde geçişle çalışmasıdır.
Ağlar arası işlem 1996 da CORBA 2.0 ( The Commen Object Request
Broker Architecture 2.0 ) tanımlamaları ile güven altına alınmasından sonra iki
dikkati çeken olaya meydana geldi.
1- Alt yapı yönelimli OMG (Object Manegement Group ), ki bu grup
1989 da kuruldu , üyeleri CORBA üzerine dikkatlerini yoğunlaştırdılar ve bu
grubun ortaya koyduklarına Yatay CORBA olanakları adı verildi. Bunun
sonucu CORBA Obje modeli , her obje için çoklu arayüzlerin yapıtaşı
modellerini içine alacak şekilde genişletildi ve Gerçek Zamanlı , Hata
Tolaranslı ve Embedded CORBA yı destekler hale dönüştü.
2- OMG tarafından DOMAINS olarak adlandırılan diğer grup , hepsinin
ortaklaşa kullanacağı standart objeleri tanımlayan ve OMG-IDL (Interface
Difinition Language ) yi kullanmaya başladılar. Bu durum 1996 yılının
başlarında OMG nin , yeniden yapılanarak Domain Technology Committee sini
 yaratmasına neden oldu. Bu komite aşağıda isimlerini bildirdiğim alt gruplara
bölünerek büyüdü ;
• Finans / Sigorta
• Elektronik Ticaret ,
• Sağlık ,
• Üretim ,
• Haberleşme ,
• İletişim ,
• Hayat Bilimleri Araştırmaları ,
• İş Ögeleri
Bunlarla tam anlamı ile uyum içinde olan ve yazılım analiz ve
tasarımının özelliklerini uyarlamakla yükümlü OMG ‘nin Analiz ve Tasarım İş
Grubu (Domain Task Force ) kuruldu. Bu grubun ortaya koyduklarına da Dikey
CORBA adı verildi.
Sonuç Sekil-1 de görülmektedir.

CORBA CORBA CORBA

DOMAİN DOMAİN DOMAİN
Meta-Obje Güvenlik
Olanakları
Common Business Object ( * )

Business Object Facility (* )

CORBA Facilities

CORBA Services

UML Interoperability (*)

Modelleme
Real Time(*), Embeded (*) Options

Components (*)

IDL Interfaces , Mapping ve ORB

 Şekil-1 : OMG Özellikleri Katmanları

( * ) İle Gösterilenler Üzerinde Çalışmalar Halen Devam

Etmektedir

Şekil-1 de görülen bu yapının en üst katmanları henüz gelişmektedir.

Ancak CORBA için oluşturulan bu temel yapı mükemmel bir şekilde test
edilmiştir ve pek çok hayati öneme sahip kurumsal uygulamalarda başarılı
olarak kullanılmaktadır. Örnekler aşağıdaki adresten sağlanabilir ;

http://www.corba.org

Ayrıca yapısal bir bakış için ;

http://www.omg.org/Library/specindx.htm.
 1.3 Analiz ve Tasarımı Desteklemek Üzere ; UML ve MDF

Endüstriyel – güçlü kurumsal yazılım sistemlerinin yaratılmasında ilk

anahtar adım Modelleme dir. OMG ‘nin UML (Unifield Modelling Language)
nin tanımlamalarının ilk yapıldığı dönemde bir modelleme tool ‘unun , bir
modelden diğerine aktarılması olanaksızdı , zira piyasadaki tool lar oldukça
benzer destek sağlamalarına karşılık özdeş metamodel ( yazımızın ileri
bölümlerinde açıklanacaktır) yapıda değillerdi.
UML yazılım geliştirme için çok iyi tanımlanmış modellerin karşılıklı
alışverişini ve geliştirilmesini sağlayan görüntülenen (visual ) bir dildir. UML
lisanı yapı taşları kullanıcıların gereksinme duyduğu etkinliklerin pek çoğunu
sağlar. Ayrıca UML standart yapı taşlarının yetersiz kaldığı alanlarda genişleme
ve özelleştirme makanizmalarının kullanımına da izin vermektedir. UML
Çerçeveleri (framework) , Yapıları (pathers) ve Yapıtaşlarını kullanarak tool
‘ları ve birlikte çalışmaları destekler.
UML aşağıda isimlerini verdiğimiz standart diyagram tiplerini
kullanarak grafiksel notasyonları tanımlar

• Use-Case Diyagramlar
• Sınıf Diyagramları ,
• Davranış Diyagramları
• Etkinlik Diyagramları
• Etkileşim Diyagramları,
• Uygulama Diyagramları ,
• Kullanma Diyagramları.
Bunların içinde Veri Akış Diyagramı yoktur. Ancak Davranış
Diyagramlarının alt bölümü olan Etkinlik Diyagramı bu etkinliği ve hattağa
fazlasını sağlamaktadır.
UML ‘in sağlanmasında MOF (Meta Object Facility) CORBA
yapısında metadata için standart bir bilgi deposu oluşturur.
 1.3 CORBA Bilgi İşlem Modeli

OBJE
İSTEMCİ UYGULANMASI

IDL IDL

ORB

Şekil-2 : İstemciden , Obje Uygulamalarına İstemin Geçişi

Şekil-2 de CORBA yapısında bir istemciden obje uygulamasına bir

istemin geçişi görüntülenmektedir.

İstemci ve objelerin uygulanması OMG-IDL aracılığı ile ORB ( The

Object Request Broker ) den soyutlanmışlardır. İstemci sadece objelerin
arayüzünü görür ve asla uygulama ayrıntısına girmez Ancak CORBA her
objenin arayüzünün OMG-IDL açıklaması zorunluluğunu getirir.
Bir istek , istemciden objelerin uygulamasına direkt olarak geçmez ve
istek daima ORB tarafından yönlendirilir. Obje , ORB ye CORBA ‘nın daveti
üzerine geçer. Dağıtım ayrıntıları ORB de bulunur ve orada bunları yazılım
yönlendirir , kullanıcı bunları hazır olarak alır ve bunları hiç bir zaman kendisi
yaratmaz. ORB etkinliği , istemci ve obje uygulamalarının içinde bulunduğu
uygulanabilir modüllerle bağlantı kuran kütüphane routinlerince sağlanır. ORB
nin varlığı , hem istemcilerin hem de uygulanabilir modüllerde objelerin
desteği ile , uzak erişimli davetlerin ve iç işlemlerin uygulamasını , olanaklı
kılar. İç işlemlerdeki davetlerde ORB çok az etken olur ve işlemi büyük bir
hızla gerçekleştirir.
 CORBA’da objelerin arayüzleri OGM-IDL de tanımlanır. İşlemlerin
özelliklerini tanımlayan arayüzdeki objelerin her biri istenilen giriş/çıkış
paremetrelerini ve işlem sırasında ortaya çıkan beklenmedik durumların
platformlarını hazırlar. Bu arayüz , davetleri işleme sokmak ve oluşturmak için
ayni arayüz tanımlarını kullanan objelerin istemcileri ile bir anlaşma oluşturur.
Bu tasarım çok büyük bir esneklik kazandırdığı gibi beraberinde büyük yarar
da getirir. Bu tasarım ayni zamanda Encapsulation (kılıf içine alınmış hücre
(cell) ve paketlerin kılıftan arındırılması işlemi) işini zorunlu hale getirir ve her
bir programlama dilinde bağımsız olarak istemcilerin obje uygulamalarına
ulaşmasını olanaklı kılar.
İstemci ve kullanıcı bakış açısıyle OMG-IDL ara yüzünün iki önemli
sonucu vardır ;
1- Yapılma Sözü . İstemci kendi arayüzü aracılığı ile uygun bir davet
gönderdiğinde kendisine bu konuda bir yanıtın hemen dönmesini
beklemektedir.
2- Zorunluluk . Arayüzde var olan özelleştirilmiş işlemlerin tümü
uygulayıcı tarafından kesinlikle uygulanmalıdır.

1.4 CORBA Dağıtım Modeli

İstemci Obje Uygu. İstemci Obje Uygu.

IDL
IDL
IDL
ORB ORB

Bilgisayar Ağı

Şekil-3 : CORBA Yapısında İstemciden Obje Uygulamasına Bir

İstemin Gidişi.
 Şekil-3 de CORBA dağılımının temeli görülmektedir ve bu temel ORB
(Object Request Broker ) dan bir başka ORB ‘ye iletişimdir. Bu dağılım ağ
üzerindeki ORB ‘lerin IDL (Interface Difinition Language ) lere ulaşımını
garanti altına almaktadır.
Bunu gerçekleştirebilmek için OMG (Object Management Group )
nın standardı GIOP (General Inter ORB Protocol ) ağlar arası iletişimde
ağlar arası işlemde (Interoperability) bütün yönlerini tanımlar : Örneğin GIOP
küçük bir Standart ileti (message) seti tanımlamıştır. Böylece istemci ve
objelerin obje-uyumlu davetleri ve cevapları kolaylıkla görmeleri olanaklı
kılınmaktadır. GIOP , TCP/IP den daha yukarı katmanlarda görev yapar ve
IIOP ( The Internet Inter- ORB Protocol ) , OMG nin CORBA uyumlu
dağılımı için zorunlu bir standardıdır. CORBA ; bütün hedef platformlar için
servis ve etkili amaçları gerçekleştirmek için tek bir protokolun yeterli olması
şeklinde bir felsefe benimsememiştir.
CORBA da ek protokolları destekleyen özellikler iki temel mantık
üzerine yoğunlaşmıştır ;
1- GIOP , TCP/IP , OSI , IPX, ATM ve iletişimde SS7 dan daha
güvenilir protokollar üzerine katmanlaştırılmıştır.
2- Seçenek (altarnative) protokollar GIOP dan farklı olarak uygun
formatlar temeli üzerine oturtulur.
Geçit kapıları seçenek protokollarla IIOP arasında köprü oluşturma
görevini üstlenirler. Diğer protokollara ek olarak ORB iletişimde IIOP yi
kullanır veya IIOP olmayan protokolları kullandığında IIOP ile köprü görevini
üstlenen bu protokollar CORBA uyumlu olarak seçilirler.İstemcilerin objelerle
iletişiminde IOR (Interoperable Object Reference) formatı kullanılır.

1.5 CORBA Yapıtaşı Modeli (CORBAbeans)

CORBA yapıtaşları , dağıtık sistemler için çok önemli bazı özellikleri

içine alan OMG ‘nin obje modelini kapsıyacak şekilde genişletme çalışmaları
henüz sonuçlanmamıştır. Halen var olan CORBA obje modelinin genişletilmiş
bir şekilde yapılandırılmış CORBA sistemi için yapıtaşı modeline yeni
tanımlamaların eklenmesi için OMG isteklerine RFP (Request For Proposal )
uygulamalarına açmış bulunmaktadır. Hali hazırdaki tanımlamalar her obje için
çoklu arayüzler yaratır ve objeler değerler (values) olarak aktarılırlar. Buna
karşılık yeni tanımlamalarda yeni yaratılan mesaj iletim servisi bir bölüm
olarak yer alacaktır. CORBA arayüzleri ve CORBA objeleri birbirleri ile bire-
bir haberleşmiyeceklerdir. İşte RFP ile , bu işe katkı vereceklerden yapıtaşları
ile arayüzlerin bir seti arasında gerçek ilişkinin kurulmasını sağlayacak ,
desteği beklenmektedir. CORBA yapıtaşları yanlızca desteklenen programlama
dillerini haritalamakla kalmayarak ayni zamanda JAVAbeans gibi ticari olarak
var olan yapıtaşı modellerini de destekleyecektir.

1.6 Gerçek Zamanlı , Hata Tolaranslı ve Minimal Embadded

CORBA
 CORBA nın kapsamını çok çeşitli ortama gerçek zamanlı dağıtım
desteği içine alacak şekilde genişletilmesi onun üst düzeyde kabul görmesinde
etken olan en önemli nedenlerden biridir.1998 yılının ortasında OMG bu alanda
ilk standartları ortaya koydu ve ancak geniş ve ayrıntılı bir açıklama yapılmadı
(daha açık bir deyişle ben bu yazımı kaleme aldığımda böyle bir ayrıntılı rapor
elde edemedim) . Gerçek zamanlı CORBA bütün ORB ler için seçimlik bir
uygulamadır , başka bir deyişle ORB ‘lerin gerçek zamanlı uygulamaları
destekleme zorunluğu yoktur. Ancak ORB ler gerçek zamanlı uygulamaları
desteklediğini iddea ediyorsa özel arayüzler kullanarak ve yine özel yollarla
bunu sağlaması gerekmektedir.
OMG gerçek zamanlı tanımlamalarını birkaç yıl içinde ortaya koymayı
planlamaktadır.İlk tanımlamalar sondan-sona esnek iletim için ORB kaynakları
üzerinden sabit-periyotta programlama (scheduling) konusunu kapsayacağı
tahmin edilmektedir. Nitekim ilk uygulamalar bu yılın başında devreye girmeye
başlamıştır.
ORB ‘nin obje – uygulaması ile bir çift oluşturan POA (the Portable
Object Adaptor) , CORBA kuruluşunun hata-tolaranslı , yedekli olarak
uygulanmasını sağlayan esnek ve yeteri kadar güçlü bir yapıdadır. Ancak halen
daha işlemlerin standartlaştırılmasında kat edilmesi gerekli çok uzun bir yol
bulunmaktadır. Bu nedenledir ki OMG ; başta ilk olarak aktif ve pasif
yedekleme mode ‘larını içine alan tanımlamaları ile hata tolaranslı CORBA için
standartların uyumlanması ile işe başlamıştır.
 1.7 CORBA Servisleri

Uygulama Vertical CORBA Horizontal CORBA

Objeleri Olanakları Olanakları

ORB (Object Request Broker)

CORBA Servisleri

Şekil-4 : OMA (the Object Management Architecture )

Şekil-4 de görülen OMA , OMG nin tak ve kullan yapıtaşı yazılımının

vizyonunu gerçekleştirmek üzere CORBA yapısı ve ağlar arası işlem temeli
üzerine kurulmuştur.
Standart servisler , standart arayüzler kullanılarak davet edilirler. Bunun
alt yapısını , ağlar arası işlemin en alt sistem seviyesinden başlanarak
uygulamanın yapıtaşlarına kadar yükselmesini sağlayan , OMA oluşturur. OMA
ayrıca uygulamalar temel etkinlikleri sağladığında , onların standart arayüzler
aracılığı ile etkinliklerini sürdürmelerini sağlar
CORBA servisleri obje uyumlu uygulamalar ve onların yapıtaşlarına
temel ve hemen hemen sistem seviyesinde servis sağlar. Bugün için 15
dolayında tariflenmiş servis bulunmaktadır. Bu servisler ile ilgili ayrıntılı bilgi
ikinci bölümde ele alınacaktır.

1.8 Yatay CORBA Olanakları

Şekil-4 de de görüldüğü gibi , CORBA nın Yatay ve Dikey olanakları ,

pazarın sağladığı Uygulama Objeleri ile birlikte OMA nın ana yapısını
oluşturmaktadır. Eğer tam yapı hazır ürünlerle gerçekleştirilebilirse , uygulama-
seviyesindeki verileri ve etkinlikleri ortak kullanabilir ve onları bilgi sistemleri
ile tümleştirebilir. Evvelce de değindiğimiz gibi , bugün için üst katmandaki
uygulama objeleri henüz tam anlamı ile gerçekleştirilemediği için , istemciler
uygulamaları için orta katmandaki CORBA olanaklarını kullanmak
zorundadırlar.
 OMA ‘ın Yatay CORBA olanakları için planı çok açıktır ; Bunun için
dört temel bölüm belirlemiştir.
1- Kullanıcı arayüzü ,
2- Bilgi Yönetimi ,
3- Sistemlerin Yönetimi ,
4- İşlemlerin Yönetimi.
Ancak hemen belirtelim ki , OMA nın bu konudaki projeleri tam anlamı
ile yerime getirebilmesi için daha pek çok çalışmaya gerek duyulmaktadır.

1.9 Dikey CORBA Olanakları

Standartların özellikleri , objelerin ortaklaşa kullanılabilmesi için bir dil

olarak IDL nin kullanılmasının pek çok nedeni vardır: Öncelikle , IDL bu
amaçla tasarlanmıştır. OMG tarafından tariflenmiş haritalama özelliğine sahip
bütün programlama dillerinde IDL resmi olarak tariflenmiştir. 1997 nin son
günlerinde OMG-IDL , ISO standardı olarak tanımlanmıştır (14750 numara
ile ) . Böylece resmi standart organizasyonların IDL arayüzü kurmaları olanaklı
kılınmıştır.
OMG’nin DTF (Domain Task Force ) oluşturduğundan söz etmiştim. Bu
grup yeni tanımlamalar için RFP leri duyurmuş bulunmaktadır. Gelecek
öneriler ile ilgili son karar OMG nin yönetim kurulu tarafından verilecek ve
daha sonra uygulamalara geçilecektir.

BÖLÜM 2
 CORBA Temelli Ağ Yönetimi

2.1 Tanıtım

Ağ yönetim sistemi , bugünün bilgisayar ağlarının artan bir şekilde

önemli bir parçası haline gelmiş bulunmaktadır. Bilgisayar ağlarının giderek
karmaşık bir yapıya dönüşmeleri , bu ağların yönetimini daha da zor bir
konuma getirmiştir. Daha önceleri pek büyük bir önem taşımayan veya hiç
bulunmayan bazı gereksinimler bugünün ağ yönetiminin temel taşlarını
oluşturur hale gelmiştir. İşte bu gereksinimlerden bazıları ;
1- Yönetim sistemleri arasında bilgi kullanımı için standart arayüzlerin
sağlanması ,
2- Hızla değişen uygulamaları içine alacak şekilde genişleyebilirliğin
sağlanması ,
3- Geniş ağların yönetiminin sağlanması ,
İşte bu gereksinimleri karşılamak üzere izlenecek yollardan biri ,
CORBA kullanarak açık , standart temelli , genişleyebilir ve dağıtık yönetim
sistemlerini oluşturacak şekilde ağı tasarlamaktır. CORBA sistem olanakları ,
sistemin diğer sistemlerle iletişiminde arayüz görevini yerine getirir.
Genişleyebilirlik özelliği de gelecekte sistemin büyüyebilmesine olanak sağlar.
Son olarak CORBA nın dağıtık özelliği onun çok fazla miktardaki ağ
ayrıntılarını yönetebilmesini olanaklı kılar.
Yazımın bu bölümünde sizlere bu özelliğe sahip CORBA temelli dağıtık
özel bir yönetim sistemini tanıtacağım. Amacım bir kuruluşun ürününün
reklamını yapmak değil ve fakat bu ürünü örnek olarak kullanıp CORBA –
Temelli ağ yönetiminin ne yararlar sağlayacağını gözler önüne sermektir.
Bu ürün General Data Com (GDC) nin ATM ürün hattıdır. Bu ürün
hattında ATM anahtarları vardır ve özellikle Amerikada pek çok iletişim
taşıyıcısı (bizdeki TT karşılığı) tarafından kullanılmaktadır ve ürünün adı
ProSphere dir.
ProSphere yapısı (architecture) , Ağ Yönetimi ve içinde grafiksel
arayüzler bulunan , sunucularda var olan bilgileri alan , Java istemci
uygulamalarını olanaklı kılan , CORBA sunucularının bir setinden
oluşmaktadır. Yapı , var olan yazılımda çok az veya hiç değişikliğe gereksinme
duymadan yeni ağ aygıtlarının eklenmesini olanaklı kılar. Yapı ayni zamanda
son kullanıcıların CORBA-IDL (Interface Defination Language ) arayüzleri
aracılığı ile tümleşmesini çok basite indirgemeye açık bir sistemdir. Yapı , Java
istemcilerinin her hangi bir tip ana sistemde veya WEB tarayıcısında
çalışmasını sağlayacak şekilde , taşınabilirdir. Son olarak ProSpere sistem
yapıtaşlarının (istemciler , sunucular , objeler ) farklı istemcilerde veya ana
sistemlerde bulunmasının sorun olmadığı bir dağıtık yapıdadır.
 2.2 Yapı

İSTEMCİ
SEVİYESİ
Seviye-1

YÖNETİM UYGULAMALARI
Objeler ve Sunucular
Seviye-2

GERÇEK YÖNETİLEN
AĞ
Seviye-3

Şekil-5: ProSphere ‘nin Mantıksal Görünüşü

Şekil-5 de görüldüğü gibi yapı üç seviyeden oluşmaktadır. Şimdi bu

seviyeler hakkında kısaca bilgi verelim :

Seviye-1 Bu seviye , var olan kullanıcıların ProSphere obje ‘lerine

arayüzler aracılığı ile ulaşmasını sağlayan grafiksel uygulamaların bulunduğu
seviyedir.
İçlerinde Java kullanıcı arayüzleri ve HP OpenView haritalarının
bulunduğu bu uygulamalar , ikinci seviyede bulunan objelerle iletişimde
bulunan CORBA istemcileridir. Bu seviyede ayni zamanda üçüncü parti
kullanıcıların bulunduğu dış sistemlere ait istemci uygulamalarında temsil
edildiği seviyedir.
Seviye-2 ve 3 İkinci seviye , ağ üzerinde ağ kaynaklarını ve yönetim
etkinliklerini oluşturan , CORBA sunucu ve objelerin bulunduğu seviyedir. Bu
seviyedeki ilkeller( entiti ‘ler) SNMP gibi ağ yönetim protokollarını kullanarak
en alt seviyedeki , yani üçüncü seviyedeki , ağ elemanları ile iletişim kurarlar.
 ProSpher’in Müşterek
Ağ ProSpher’in Uygulama
Yönetim Objeleri Objeleri

ORB (Object Request Broker)

Müşterek CORBA Servisleri

Şekil-6 : Seviye 2’ nin Ayrıntı Görünümü

Şekil-6 de ikinci seviyeyi oluşturan yapı taşlarının durumu

görülmektedir. Bu yapı taşları üç tipe bölünmektedir.
Tip-1: OMG (Object Management Group ) ortaya koyduğu CORBA ‘ın
Naming ve Event servislerini taşımaktadır Bunlar dış CORBA sistemleri ile
ProSphere uygulamaları için Ağlar Arası İşlem (Interoperability) mi olanaklı
kılan temel servisleri sağlar
Tip-2: İkinci tip yapı taşları tüm sistemde kullanılan ağ yönetim
servislerini yönlendirirler. Bunlar
Trap Servis Yönetimi ,
Topoloji Servis Yönetimi ,
Log İşlemlerinin Yönetimi , servisleridir.
Tip-3 : Bu grup yapı taşları ;
Alarm Görüntüleme ,
Element Yönetimi ,
MOM (Managed Object Manager ) gibi özel ağ
yönetim uygulamalarını yönlendirmektedir.
Şimdi bu üç tip yapı taşının sağladığı servisleri kısaca tanıtalım.
Hatırlanacağı gibi Bölüm-1 de bu servislerin varlığından söz etmiş bunların
etkinliklerini ikinci bölümde ele alacağımızı açıklamıştık.
Sonuç Dağıtım Servisi ; Ağ yönetimi tümüyle sonucu esas alan yapıda
olduğundan bu servis ProSphere yapısı için çok önemli bir parçadır.
Bu servis SNMP trap ‘eleri gibi ağ element sonuçları ile objeden objeye
tanımlamalarını sağlayan uygulama sonuçlarını dağıtma görevini yürütür.
İsimlendirme Servisi ; Bu servis objelere kolaylıkla ulaşılmasını
sağlamak üzere bir isim atar ve daha sonra bu objeye baş vuru olduğu taktirde
bu ismi çözümlemede görev yapar.
 Trap Servis Yöneticisi ; Bu servis esas olarak , ana makine için SNMP
trap çoklayıcısı olarak görev yapar.
Topoloji Servis Yöneticisi ; Bu servis yönetim özellikleri arasında
ilişkiyi belirler ve depolar. Ayrıca sorgulama işlemleri ilişkilerini sağlar. Bu
servis yönlendirilmiş objeler arasında ilişkilerin doğmasını sağlayan MOM
tarafından kullanılır. Bu servis ayrıca bu ilişkileri sorgulayan ve yönetilmiş
objeler ve diğer ilkeller arasında yeni ilişkilerin oluşturulması , işlerinde de
kullanılır.
Log ‘ ların Yönetimi Servisi ; Bu servis sisteme log edenlerle ilgili
bilgileri belirler , depolar ve log’larla ilgili inceleme yapmak isteyenlere arayüz
desteği sağlar. Ayrıca oluşan alarm bilgilerinin de belirlenmesi ve log’larla ilgili
bilgilerde olduğu gibi özel bir veri tabanında depolanmasını sağlar.Bu servis
ayni zamanda güvenlik için de çok önemlidir.
Alarm Görüntüleme ; Bu servis trap eventleri ve polling
makanizmalarını kullanarak ağ elementlerinin alarm durumlarını görüntüler.
Element Yöneticisi ; Bu servis aygıt seviyesinde yapının
(configuration) kontrolünü ve ağ aygıtları için tarama işlemlerini yerine getirir.
Yönetilmiş-Obje’lerin Yönetimi (MOM) ; Ağ özelliklerini ve
kaynaklarını temsil eden Yönetilmiş-Obje ‘lerin taşıyıcısıdır. Bu objelerin
yaratılması veya yok edilmesi görevlerini de yerine getirir.

HP OpenView GUI GUI

Yönetilmiş Obje Yöneticisi Log

Yöneticisi

Trap Servis Alarm Görüntüleme

NE NE
 Şekil-7 : ProSphere Yapısında Yapıtaşları İlişkileri

Şekil-7 de görülen sistemin temel yapısı MOM da bulunan topoloji

objeleri üzerine bina edilmiştir. Topoloji objeleri ağı temsil ederler ve
adresleme , tip , kaynaklar, durumlar gibi bilgileri taşırlar. Bu bilgiler
sistemdeki bütün uygulamalar tarafından ortaklaşa olarak kullanılır. Bu objeler
MOM ‘a yardımcı olarak görev yapan HP OpenView tarafından yaratılır.
Alarm Görüntüleme ; Ağ üzerinde oluşan hataları işler ve toplar .
Ayrıca Trap Servis Yöneticisinden gelen sonuçları da toplar. Alarm
Görüntüleme bunlara ek olarak ağ elementlerinden gelen alarm durumlarını da
biriktirir. Alarm Görüntüleme durumda herhangi bir değişiklik olduğunu
belirler ise MOM ‘a hemen bir sonuç gönderir. Eğer sonuç olarak alarm
durumu değişmiş ise alarm sonucu , sonuç kanalı içine itilir. Log yöneticisi ve
OpenView Map Programı gibi çoklu kullanıcılar bu alarm sonuçlarını alırlar ve
değerlendirirler.

2.3 Genişleyebilir Uygulama Çerçevesi Yaratabilmesi ,

Ağ yönetim uygulamasında en önemli sorun ağ teknolojisinde meydana

gelen hızlı değişme ve bu değişmenin kaçınılmaz sonucu ağ yönetim
yazılımının değişikliğe uğramasıdır. Ağ protokolları , fiziksel ortam ve
donanımda yapılan değişiklikler ve güncelleştirilmeleri , ağ yönetim sisteminde
yeni destek özellikleri isteklerini gündeme getirir. Bu nedenledir ki , ağ
yönetim yapısı (architecture) önemli bir yeniden tasarlama ve kotlamaya
gereksinim duymadan , ağ işlem teknolojisinde oluşan değişmeler ve yeni
özellikleri çok kolaylıkla yönlendirebilecek yetenekte olmalıdır.
İşte CORBA temelli ağ yönetim yazılımı , örneğin ProSphere , bu
sorunu en basit yönden çözümleyen bir yaklaşımdır.
 Yönetim Objeleri

Kökler Yönetilmiş Eleman Ağ Ekipman

Bağlantı Yürütücü

Şekil-8: Yaratılan Ağ Modeli

Şekil-8 de verilen ağ modelinde bütün objeler , yönetim objesi

tarafından yaratılır. Yönetim objesi tüm objeler için temel nitelikleri (attribute)
leri ve işlemleri tanımlayan IDL ( Interface Definition Languade) arayüzünü
destekler. Bütün objeler bir isme sahiptir ve yaratılan bu model bütün olası ağ
ilkelleri (entitileri) ve topolojileri destekler.
Şimdi durumu bir örnekle açıklayalım. Örneğin sisteme yeni bir sunucu
girecek veya ana sistem değiştirilecektir. Bu durumda sadece yeni girecek
sunucunun obje tanımlamasının yapılması yeterlidir ve bu otamatik olarak
model içine yerleştirilir. Ana sistem büyütülecek ise bu konuda var olan objenin
düzeltmeye tabi tutulması yeterli olacaktır.
Görüldüğü gibi yalnız objelerle oynayarak ve fakat tasarım ve yazılıma
dokunmadan gerekli genişlemeler yapılmaktadır. Bu genişleme çok geniş bir
alana dağılmış tüm kurum bazında da kolaylıkla gerçekleştirilebilmektedir.

2.4 Ölçeklenebilir (Scalable) Olması ,

Bilgisayar ağlarının genişliği ve dolayısiyle karmaşıklığı arttıkça

sistemde çok daha fazla başarım (performance) kapasitesine ve yönetim için
daha fazla ağ kaynaklarına gereksinim duyulmaktadır. Ağ yönetiminde
ölçeklenebilirliğin önem kazandığı iki alan bulunmaktadır.
 a- Yönetim sistemi , başarım sorunu veya bilgisayar kaynak kısıtlaması
gibi sorunlar yaratmadan , çok geniş objeler topluluğunu
yönetebilmelidir.
b- Yönetim sistemi yapıtaşları , ağ elementleri üzerine çok fazla
yönetim isteği yüklemeden ve çok az bilgi kaybı ile ağ üzerindeki
verileri bir araya getirebilme ve görüntüleyebilme gücüne sahip
olmalıdır.

Şimdi konuya açıklık getirebilmek için bir uygulamayı ela alalım ; Her
bir düğüme (node) 64 fiziksel arayüzün bağlandığı 50 ATM anahtar taşıyan
küçük boyutta bir ATM ağının bulunduğunu var sayalım. Bu ağ için yönetim
sistemi ; her bir düğüm için bir obje , düğümün her bir fiziksel yapı taşı için bir
obje , her bir arayüz için bir obje , arayüzler arası bağlantı modellemeleri için
objeler , ağda her bir bağlantı için objeler , taşıyacaktır. Bu durumda tam bir
sistemde objelerin adedi onbinleri bulacaktır. İşte çok sayıda ve dağıtılmış
durumdaki bu objelerin yönlendirebilmek ancak CORBA temelli bir ağ
yönetim sistemi ile olanaklıdır. Sistemde objelerin yerleşme alanları tamamen
geçirgendir , yani objeler birbirleriyle bulundukları yere bağlı olmaksızın
kolaylıkla etkileşebilirler.
Ağdaki bu dağıtık yapı ayni zamanda çok sayıda verinin toplanıp
değerlendirilmesine ve görüntülenmesine olanak sağlamaktadır.

2.5 Açık / Standart Arayüz Sağlaması ,

Karmaşık iletişim ağlarının başarılı yönetimi için standart arayüzler

kullanılarak yönetsel bilgilerin değiş tokuşuna olanak sağlayan bir destek
verilebilmelidir. Başka bir deyişle , çok farklı şirketlere ait ekipmanlardan
oluşan bir ağda servis sağlanabilmesi için , farklı şirketlerin ağı oluşturan
elemanlarından gelen bilgiler standart bir formatta sunulabilmelidir. Eğer bu
arayüzler şirket bağımlı ise , yukarda belirtilen düzeyde bir servis sağlanması
olanaksızdır. Buna karşılık standart arayüzlerle çalışan yönetim sistemleri
şirket bağımlı bilgilere gereksinim duymaz ve ağ kaynak yönetimini kolaylıkla
yönlendirebilir. Gerçi bu arayüzler için sonuçta hangi teknolojinin kullanılacağı
yüzde yüz açık değildir , ancak iletişim endüstrisinin CORBA’nın bu amaçla
desteklenmesi yönünde büyük çabası bulunmaktadır.
Ek olarak , pek çok şirket önerilen yönetim sistemini halen kullandığı
sistemle desteklemeyi istemektedir. Bunda da temel mantık şudur ; arayüzler
kendi sistem yapısı , işletim sistemi , kullandığı programlama dilleri ile uyum
içindedir. Böylece CORBA işletim sistemi ve programlama dili olarak
kurumların bu isteklerine yanıt verecek bir düzeyde görülmektedir.

2.6 Programlama Dili Bağımsızlığının Sağlanması

Objelerin ve sunucuların uygulanmasında örneğin C++ ve kullanıcı

arayüz yazılımında java kullanılması buna tipik bir örnektir. Bu durum Java
istemcilerinin taşınabilirlik , basitlik ve esnekliklerinin , C ++ sunucularının
başarım üstünlükleri ile bir araya getirilmesini sağlar. Bu olanaklıdır , zira
CORBA programlama dili bağımlı değildir. Başka bir deyişle IDL , C ++ , C ,
Smalltalk ve Java gibi çok farklı programlama dili kullanılarak uygulamaya
sokulabilir.
Bu dil bağımsızlığı , daha sonra çok kolaylıkla birbirleri ile
tümleştirilebilecek , farklı dilde yazılmış sistem parçacıklarının kullanımına
izin verir.
Özetlersek ; CORBA sunucu bir dille kurulurken , sunucu objeleri
istemci uygulamaları başka bir dilde uygulanabilir.

2.7 WEB – Temelli Yönetim Desteği Sağlanması

Ağ yönetiminde Web- temelli uygulamalar giderek büyük bir önem

kazanmaktadır. Gerçi Internet Servis Sağlayıcıları müşterilerine oldukça ucuz
ağ yönetim ürünleri sunmakta ve ek olarak Web tarayıcıları Internet ortamında
ulaşılabilirlik , taşınabilirlik ve basitlik yönünde oldukça başarılı destek
sağlamaktadır. Ancak hemen belirtmeliyi ki , Web temelli yönetim sadece
CORBA-Temelli ağ yönetimi ile sağlanabilmektedir.

2.8 Lider NMS ( Network Management System ) leriyle Kolayca

Tümleşme Sağlanması

Hemen belirtelim ki , başta OMG (Object Management Group ) ve

üyeleri olmak üzere pek müşteri de ağ yönetim uygulamalarının , lider NMS
ürünleri ile kolayca tümleşmesini istemekte ve desteklemektedir. Bu nedenle
ProSphere başta olmak üzere tüm CORBA-Temelli ağ yönetim yazılımları bu
yönde gelişmektedir.