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

Ebat: px
Şu sayfadan göstermeyi başlat:

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

Transkript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DAĞITIK NESNE YÖNETİMİ MİMARİLERİNDEN CORBA VE DCOM MİMARİLERİNİN KARŞILAŞTIRMASI

DAĞITIK NESNE YÖNETİMİ MİMARİLERİNDEN CORBA VE DCOM MİMARİLERİNİN KARŞILAŞTIRMASI http://www.trakya.edu.tr/enstituler/fenbilimleri/dergi/net/index.htm Trakya Üniversitesi Bilimsel Araştırmalar Dergisi B Serisi Fen Bilimleri, 4(1): 37-45, 2003 ISSN 1302 647X DIC: 77AMACET/4106030703

Detaylı

ĐSTEMCĐ SUNUCU SĐSTEMLER DERSĐ FĐNAL ÇALIŞMASI SORULAR YANITLAR

ĐSTEMCĐ SUNUCU SĐSTEMLER DERSĐ FĐNAL ÇALIŞMASI SORULAR YANITLAR ĐSTEMCĐ SUNUCU SĐSTEMLER DERSĐ FĐNAL ÇALIŞMASI SORULAR YANITLAR 4.ÜNĐTE Đyi bir DNS in içermesi gereken özellikler nelerdir? ( 5 ) Đsimlendirme imlası açık ve süphesiz olmalıdır; Bir kullanıcı bir isme

Detaylı

Öğr. Gör. Serkan AKSU http://www.serkanaksu.net. http://www.serkanaksu.net/ 1

Öğr. Gör. Serkan AKSU http://www.serkanaksu.net. http://www.serkanaksu.net/ 1 Öğr. Gör. Serkan AKSU http://www.serkanaksu.net http://www.serkanaksu.net/ 1 JavaScript JavaScript Nedir? Nestcape firması tarafından C dilinden esinlenerek yazılmış, Netscape Navigator 2.0 ile birlikte

Detaylı

İŞLETİM SİSTEMİ KATMANLARI (Çekirdek, kabuk ve diğer temel kavramlar) Bir işletim sisteminin yazılım tasarımında ele alınması gereken iki önemli konu

İŞLETİM SİSTEMİ KATMANLARI (Çekirdek, kabuk ve diğer temel kavramlar) Bir işletim sisteminin yazılım tasarımında ele alınması gereken iki önemli konu İŞLETİM SİSTEMİ KATMANLARI (Çekirdek, kabuk ve diğer temel kavramlar) Bir işletim sisteminin yazılım tasarımında ele alınması gereken iki önemli konu bulunmaktadır; 1. Performans: İşletim sistemi, makine

Detaylı

OPC Data Access (DA) Temelleri

OPC Data Access (DA) Temelleri OPC Data Access (DA) Temelleri Hazırlayan Kepware Technologies Türkçe Meal Salih GÖK Anket Data Access nedir? Data Access in getirileri OPC DA e giriş (Data Access) OPC DA Özelliklerine bakış Hızlı bir

Detaylı

Mobil Cihazlardan Web Servis Sunumu

Mobil Cihazlardan Web Servis Sunumu Mobil Cihazlardan Web Servis Sunumu Özlem Özgöbek Ege Üniversitesi Bilgisayar Mühendisliği Bölümü 2010 İnternet erişiminin yaygınlaşması ve artık mobil cihazlar üzerinden bile yüksek hızlı veri iletişimine

Detaylı

O P C S T A N D A R D I

O P C S T A N D A R D I O P C S T A N D A R D I ASP OTOMASYON LTD. Sadık ŞENOL İsmail YAKIN 12/08/2008 OPC Standardı İnsan gücüne dayalı üretimden otomasyona dayalı, daha kontrollü bir üretime geçiş endüstride üretim hızını ve

Detaylı

Servis olarak Altyapı

Servis olarak Altyapı Servis olarak Altyapı Servis olarak Altyapı (Infrastructure as a Servis, IaaS) fiziksel makineler, sanal makineler ve sanal depolama gibi temel kaynaklara erişebilmeyi sağlar. Bu kaynaklardan başka IaaS

Detaylı

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011. Mustafa Atanak Sefai Tandoğan Doç. Dr.

DGridSim Gerçek Zamanlı Veri Grid Simülatörü. Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011. Mustafa Atanak Sefai Tandoğan Doç. Dr. DGridSim Gerçek Zamanlı Veri Grid Simülatörü Yazılım Tasarımı Dokümanı v 1.0.1 01.08.2011 Mustafa Atanak Sefai Tandoğan Doç. Dr. Atakan Doğan 1. Sistem Mimarisi DGridSim katmanlı bir yapı göz önünde bulundurularak

Detaylı

Bilgi Servisleri (IS)

Bilgi Servisleri (IS) Bilgi Servisleri (IS) GRID Kullanıcı Eğitimi Boğaziçi Üniversitesi 2007, İstanbul Emrah AKKOYUN Konu Başlığı Neden ihtiyaç duyulur? Kullanıcılar kimlerdir? Bilgi Servisi türleri MDS ve BDII LDAP Bilgi

Detaylı

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay.

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay. PROGRAMLAMAYA GİRİŞ Öğr. Gör. Ayhan KOÇ Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay., 2007 Algoritma ve Programlamaya Giriş, Ebubekir YAŞAR, Murathan Yay., 2011

Detaylı

Kepware Veritabanı Ürünleri. Teknolojiye Genel Bir Bakış

Kepware Veritabanı Ürünleri. Teknolojiye Genel Bir Bakış Kepware Veritabanı Ürünleri Teknolojiye Genel Bir Bakış Gündem Veritabanı Client API teknolojisinin gözden geçirilmesi ODBC istemci sürücüsü- bir KEPServerEX Plug-In Haberleşme Sürücüsüdür. DataLogger-

Detaylı

JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması

JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması JAVA RMI ve Hibernate teknolojileri kullanılarak çok amaçlı bir yazılım altyapısı hazırlanması Hakan ALBAĞ Tahsin Barış AKAN Bitirme Projesi 05.06.2006 Giriş Ticari yazılımlarda ortak ihtiyaçlar Birden

Detaylı

Bölüm 28 ve 29 : İstemci Sunucu Etkileşimi ve Soket API sine Giriş. Internet Protokolleri ve Ağ Uygulamaları. Internet Protokolleri Üzerinden İletişim

Bölüm 28 ve 29 : İstemci Sunucu Etkileşimi ve Soket API sine Giriş. Internet Protokolleri ve Ağ Uygulamaları. Internet Protokolleri Üzerinden İletişim Bölüm 28 ve 29 : İstemci Sunucu Etkileşimi ve Soket API sine Giriş Kaynak : Douglas E. Comer, Computer Networks and Internets With Internet Applications, 4. Baskı, 2004, Prentice Hall Hazırlayan : Tacettin

Detaylı

VERİ KAYNAKLARI. Bilgi sisteminin öğelerinden biride veri

VERİ KAYNAKLARI. Bilgi sisteminin öğelerinden biride veri VERİ KAYNAKLARI YÖNETİMİ İ İ 5. ÜNİTE GİRİŞ Bilgi sisteminin öğelerinden biride veri yönetimidir. Geleneksel yada çağdaş, birinci yada ikinci elden derlenen veriler amaca uygun veri formlarında tutulur.

Detaylı

Uzaktan Kurulum Kılavuzu

Uzaktan Kurulum Kılavuzu Uzaktan Kurulum Kılavuzu Uzak yönetim konsolu aracılığı ile ShadowProtect kurulumu ve yönetimi. Sürüm: 4.0+ Tarih: 30.03.2011 Copyright StorageCraft Technology Corporation 2008 Sayfa 1 / 10 ShadowProtect

Detaylı

Bilgisayarda Programlama. Temel Kavramlar

Bilgisayarda Programlama. Temel Kavramlar Bilgisayarda Programlama Temel Kavramlar KAVRAMLAR Programlama, yaşadığımız gerçek dünyadaki problemlere ilişkin çözümlerin bilgisayarın anlayabileceği bir biçime dönüştürülmesi / ifade edilmesidir. Bunu

Detaylı

Grid Bilgi Sistemleri (Grid Information Systems)

Grid Bilgi Sistemleri (Grid Information Systems) Grid Bilgi Sistemleri (Grid Information Systems) TR-Grid Kullanıcı Eğitimi (9-10 Temmuz 2007) Hakan Bayındır Bu Sunumda Grid Bilgi Sistemleri glite Bilgi Sistemi GLUE Şeması Grid Elemanları LCG Bilgi Sistemi

Detaylı

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 KONU BAŞLIKLARI 1. Yazılım Mimarisi nedir? 2. Yazılımda Karmaşıklık 3. Üç Katmanlı Mimari nedir? 4. Üç Katmanlı Mimari

Detaylı

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri

Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri Veritabanı Yönetim Sistemleri (Veritabanı Kavramı) Veri Modelleri Konular Veritabanı Tasarım Aşamaları Veri Modeli Nedir? Veri Modeli Temel Bileşenleri İş Kuralları (Business Rules) İş Kurallarını Veri

Detaylı

Akıllı telefonlar, avuçiçi bilgisayarlar ile taşınabilir (cep) telefonların özelliklerini birleştiren cihazlardır. Akıllı telefonlar kullanıcıların

Akıllı telefonlar, avuçiçi bilgisayarlar ile taşınabilir (cep) telefonların özelliklerini birleştiren cihazlardır. Akıllı telefonlar kullanıcıların Akıllı telefonlar, avuçiçi bilgisayarlar ile taşınabilir (cep) telefonların özelliklerini birleştiren cihazlardır. Akıllı telefonlar kullanıcıların bilgilerini saklamalarına, program yüklemelerine izin

Detaylı

FARKLI BAKIŞ AÇILARINDAN JAVA RMI VE CORBA NIN KARŞILAŞTIRILMASI

FARKLI BAKIŞ AÇILARINDAN JAVA RMI VE CORBA NIN KARŞILAŞTIRILMASI PAMUKKALE ÜNİ VERSİ TESİ MÜHENDİ SLİ K FAKÜLTESİ PAMUKKALE UNIVERSITY ENGINEERING COLLEGE MÜHENDİ SLİ K Bİ L İ MLERİ DERGİ S İ JOURNAL OF ENGINEERING SCIENCES YIL CİLT SAYI SAYFA : 2001 : 7 : 1 : 63-69

Detaylı

Bilgisayar İşletim Sistemleri BLG 312

Bilgisayar İşletim Sistemleri BLG 312 Bilgisayar İşletim Sistemleri BLG 312 İşletim Sistemlerine Giriş Bilgisayar Sistemi uygulama programları derleyici editör komut yorumlayıcı işletim sistemi makina dilinde programlar mikroprogram (ROM da)

Detaylı

İŞLETİM SİSTEMLERİNE GİRİŞ - 2. Sistem, sistem kaynaklarını belli bir hiyerarşi içinde kullanıcının hizmetine

İŞLETİM SİSTEMLERİNE GİRİŞ - 2. Sistem, sistem kaynaklarını belli bir hiyerarşi içinde kullanıcının hizmetine İŞLETİM SİSTEMLERİNE GİRİŞ - 2 Kaynakların Paylaşımı (Resource Sharing) Sistem, sistem kaynaklarını belli bir hiyerarşi içinde kullanıcının hizmetine sunar. Bir işletim sisteminde paylaşılan kaynaklar

Detaylı

Ağ Yönetiminin Fonksiyonel Mimarisi

Ağ Yönetiminin Fonksiyonel Mimarisi Bölüm 7 Ağ Yönetimi Ağ Yönetiminin Fonksiyonel Mimarisi a) Performans (Performance) Yönetimi b) Sistem Ayarları (Configuration) Yönetimi c) Hesap (Account) t)yönetimi i d) Hata (Fault) Yönetimi e) Güvenlik

Detaylı

Algoritma Geliştirme ve Veri Yapıları 2 Veri Modelleri. Mustafa Kemal Üniversitesi

Algoritma Geliştirme ve Veri Yapıları 2 Veri Modelleri. Mustafa Kemal Üniversitesi Algoritma Geliştirme ve Veri Yapıları 2 Veri Modelleri Veri modelleri, veriler arasında ilişkisel ve sırasal düzeni gösteren kavramsal tanımlardır. Her program en azından bir veri modeline dayanır. Uygun

Detaylı

NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf Eylül 2010

NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf Eylül 2010 NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf Eylül 2010 Copyright 2010 dojop Teknoloji Hizmetleri Tic. Ltd. Şti Bilgi Teknolojilerinizde Devrim Yapın NComputing Erişim cihazları kişisel çalışma

Detaylı

BİL 542 Paralel Hesaplama. Dersi Projesi. MPJ Express Java Paralel Programlama

BİL 542 Paralel Hesaplama. Dersi Projesi. MPJ Express Java Paralel Programlama BİL 542 Paralel Hesaplama Dersi Projesi MPJ Express Java Paralel Programlama Recep Ali YILMAZ 131419106 Fen Bilimleri Enstitüsü Bilgisayar Mühendisliği Bölümü Bilgisayar Mühendisliği Yüksek Lisans Programı

Detaylı

DAĞITIK PROGRAMLA. Bütün işler tek bir kod, hatta tek bir bilgisayar tarafından yürütülmez. Her bir katmanı ayrı bir bilgisayar tarafından koşturulur.

DAĞITIK PROGRAMLA. Bütün işler tek bir kod, hatta tek bir bilgisayar tarafından yürütülmez. Her bir katmanı ayrı bir bilgisayar tarafından koşturulur. DAĞITIK PROGRAMLA Dağıtık programlama, dağıtık, açık, ölçeklenir, saydam ve hataları giderebilen bir programlama modelidir. Uzak yordam çağrıları (RPC), işletim sistemi komutlarını bir ağ bağlantısı üzerinde

Detaylı

1 Temel Kavramlar. Veritabanı 1

1 Temel Kavramlar. Veritabanı 1 1 Temel Kavramlar Veritabanı 1 Veri Saklama Gerekliliği Bilgisayarların ilk bulunduğu yıllardan itibaren veri saklama tüm kurum ve kuruluşlarda kullanılmaktadır. Veri saklamada kullanılan yöntemler; Geleneksel

Detaylı

Veri Tabanı-I 1.Hafta

Veri Tabanı-I 1.Hafta Veri Tabanı-I 1.Hafta 2010-2011 Bahar Dönemi Mehmet Akif Ersoy Üniversitesi Meslek Yüksekokulu Burdur 2011 Muhammer İLKUÇAR 1 Veri ve Veri Tabanı Nedir? Veri Bir anlamı olan ve kaydedilebilen

Detaylı

Yazılım Destek Hizmeti

Yazılım Destek Hizmeti Veri sayfası Yazılım Destek Hizmeti HP Care Hizmetleri kapsamında Care Pack ve Sözleşmeli Hizmetler Hizmetin sağladığı avantajlar Sorun çözme amacıyla HP teknik kaynaklarına Yazılım güncellemelerini ayrı

Detaylı

Üst Düzey Programlama

Üst Düzey Programlama Üst Düzey Programlama JDBC (Java Database Connectivity) Üst Düzey Programlama-ders07/ 1 JDBC JDBC ilişkisel veritabanlarına erişim için Java dilinde kullanılan standart bir kütüphanedir. Bu kütüphanedeki

Detaylı

w w w. a n k a r a b t. c o m

w w w. a n k a r a b t. c o m Şirket Profili w w w. a n k a r a b t. c o m AnkaraBT, yazılım geliştirme alanında faaliyet gösteren ve uzman kadrosuyla Türkiye'nin önde gelen kurumsal çözümlerini üreten %100 Türk sermayeli bilgi teknolojisi

Detaylı

BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER

BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER BSM 532 KABLOSUZ AĞLARIN MODELLEMESİ VE ANALİZİ OPNET MODELER Yazılımı ve Genel Özellikleri Doç.Dr. Cüneyt BAYILMIŞ Kablosuz Ağların Modellemesi ve Analizi 1 OPNET OPNET Modeler, iletişim sistemleri ve

Detaylı

Bulut Bilişim. Ege Üniversitesi Bilgisayar Mühendisliği Web Servisleri

Bulut Bilişim. Ege Üniversitesi Bilgisayar Mühendisliği Web Servisleri Bulut Bilişim Ege Üniversitesi Bilgisayar Mühendisliği Web Servisleri Ediz TÜRKOĞLU 05-07-8509 Özlem GÜRSES 05-07-8496 Savaş YILDIZ 05-07-8569 Umut BENZER 05-06-7670 İ çerik İçerik...2 Bulut Bilişim Nedir?...3

Detaylı

UZAKTAN EĞİTİM MERKEZİ

UZAKTAN EĞİTİM MERKEZİ ÜNİTE 2 VERİ TABANI İÇİNDEKİLER Veri Tabanı Veri Tabanı İle İlgili Temel Kavramlar Tablo Alan Sorgu Veri Tabanı Yapısı BAYBURT ÜNİVERSİTESİ UZAKTAN EĞİTİM MERKEZİ BİLGİSAYAR II HEDEFLER Veri tabanı kavramını

Detaylı

Nagios XI Günümüzün talep gören kurumsal gereksinimleri için en güçlü BT altyapısı gözetim ve uyarı çözümüdür.

Nagios XI Günümüzün talep gören kurumsal gereksinimleri için en güçlü BT altyapısı gözetim ve uyarı çözümüdür. Nagios Enterprises, kurumsal ölçekte, BT altyapı gözetiminde endüstri standardı olan Nagios için resmi ürünler, hizmetler ve çözümler sunuyor. Dünya çapında yüz binlerce kullanıcıyla Nagios bilgi teknolojileri

Detaylı

Küme Bilgisayarlar. Enabling Grids for E-sciencE. Onur Temizsoylu. Grid ve Küme Bilgisayarlarda Uygulama Geliştirme Eğitimi ODTÜ, Ankara

Küme Bilgisayarlar. Enabling Grids for E-sciencE. Onur Temizsoylu. Grid ve Küme Bilgisayarlarda Uygulama Geliştirme Eğitimi ODTÜ, Ankara Küme Bilgisayarlar Onur Temizsoylu ODTÜ, Ankara www.eu-egee.org EGEE and glite are registered trademarks İçerik Neden hesaplamada kümeleme? Kümeleme nedir? Yüksek kullanılabilirlik kümeleri Yük dengeleme

Detaylı

BİLGİSAYAR AĞLARI Bilgisayar İletişimi Nedir? Veri İşleme Modelleri ve Ağ Gelişimi Merkezi İşleme

BİLGİSAYAR AĞLARI Bilgisayar İletişimi Nedir? Veri İşleme Modelleri ve Ağ Gelişimi Merkezi İşleme BİLGİSAYAR AĞLARI Bilgisayar ağlarının kullanımındaki temel amaç bilgi ve servislerin paylaşımıdır. Bu bölümde bilgisayar ağlarının sınıflandırılması ve kullanım amaçları anlatılmaktadır. Bu bilgi ve servislerin

Detaylı

Enterprise Resource Planning - ERP - Kurumsal kaynak planlaması ya da iş letme kaynak planlaması,

Enterprise Resource Planning - ERP - Kurumsal kaynak planlaması ya da iş letme kaynak planlaması, Enterprise Resource Planning - ERP - Kurumsal kaynak planlaması ya da iş letme kaynak planlaması, işletmelerde mal ve hizmet üretimi için gereken işgücü, makine, malzeme gibi kaynakların verimli bir şekilde

Detaylı

Ünite-3 Bilgisayar Yazılımı. www.cengizcetin.net

Ünite-3 Bilgisayar Yazılımı. www.cengizcetin.net Ünite-3 Bilgisayar Yazılımı Yazılım Kavramı Bilgisayarın belirli bir işi gerçekleştirebilmesi için kullanıcı tarafından her adımda ne yapacağı tarif edilmiş olmalıdır. Yani kullanıcı bilgisayara uygun

Detaylı

Bilgisayar Mühendisliğine Giriş. Yrd.Doç.Dr.Hacer KARACAN

Bilgisayar Mühendisliğine Giriş. Yrd.Doç.Dr.Hacer KARACAN Bilgisayar Mühendisliğine Giriş Yrd.Doç.Dr.Hacer KARACAN İçerik Dosya Organizasyonu (File Organization) Veritabanı Sistemleri (Database Systems) BM307 Dosya Organizasyonu (File Organization) İçerik Dosya

Detaylı

Göstericiler (Pointers)

Göstericiler (Pointers) C PROGRAMLAMA Göstericiler (Pointers) C programlama dilinin en güçlü özelliklerinden biridir. Göstericiler, işaretçiler yada pointer adı da verilmektedir. Gösterici (pointer); içerisinde bellek adresi

Detaylı

FIRAT ÜNİVERSİTESİ BİLGİSAYAR MÜH.

FIRAT ÜNİVERSİTESİ BİLGİSAYAR MÜH. FIRAT ÜNİVERSİTESİ BİLGİSAYAR MÜH. WSDL-SOAP MURAT TEZGİDER Web Servisi Nedir? web servisi :standart formatları kullanarak programlama dili, işletim sistemi ve platformdan bağımsız olarak bilgiyi paylaşan

Detaylı

Küme Bilgisayarlarda PBS Kuyruk Sistemi

Küme Bilgisayarlarda PBS Kuyruk Sistemi Küme Bilgisayarlarda PBS Kuyruk Sistemi Aslı Zengin asli@ulakbim.gov.tr Ankara, Ekim 2007 www.grid.org.tr İÇERİK Küme Bilgisayar Bileşenleri Küme Bilgisayar Kuyruk Sistemi PBS Kuyruk Sistemi Özellikleri

Detaylı

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım

Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım Yazılım Mimari Tasarımından Yazılım Geliştirme Çatısının Üretilmesinde Model Güdümlü Bir Yaklaşım İbrahim Onuralp Yiğit 1, Nafiye Kübra Turhan 2, Ahmet Erdinç Yılmaz 3, Bülent Durak 4 1,2,3,4 ASELSAN A.Ş.

Detaylı

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime Bulut Bilişim-Planlama Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime geçemden önce dikkat edilmesi

Detaylı

5. PROGRAMLA DİLLERİ. 5.1 Giriş

5. PROGRAMLA DİLLERİ. 5.1 Giriş 5. PROGRAMLA DİLLERİ 8.1 Giriş 8.2 Yazılım Geliştirme Süreci 8.3 Yazılım Geliştirme Sürecinde Programlama Dilinin Önemi 8.4 Programlama Dillerinin Tarihçesi 8.5 Programlama Dillerinin Sınıflandırılması

Detaylı

ÖZGÜR YAZILIMLAR İLE J2EE

ÖZGÜR YAZILIMLAR İLE J2EE ÖZGÜR YAZILIMLAR İLE J2EE Buğra Çakır bugra@ibrahimcakir.com Seminer İçeriği 1. İki ve üç katmanlı yazılım mimarileri 2. Java ve J2EE platformu 3. Özgür yazılımlar ile J2EE 4. Eclipse, Lomboz ve JBoss

Detaylı

Script. Statik Sayfa. Dinamik Sayfa. Dinamik Web Sitelerinin Avantajları. İçerik Yönetim Sistemi. PHP Nedir? Avantajları.

Script. Statik Sayfa. Dinamik Sayfa. Dinamik Web Sitelerinin Avantajları. İçerik Yönetim Sistemi. PHP Nedir? Avantajları. Script Statik Sayfa Dinamik Sayfa Dinamik Web Sitelerinin Avantajları İçerik Yönetim Sistemi PHP Nedir? Avantajları Dezavantajları Script HTML kodları arasına yerleştirilen küçük kodlardır. Web sayfalarında

Detaylı

ClientAceDA Bağlantısı. ClientAce DA bağlantısı, Visual Basic.NET veya C# programcılarının rahatlıkla. serverlarla bağlantı kurabilen

ClientAceDA Bağlantısı. ClientAce DA bağlantısı, Visual Basic.NET veya C# programcılarının rahatlıkla. serverlarla bağlantı kurabilen Kepware'in ClientAce OPC.NET Toolkiti, bir OPC client uygulaması yapmak isteyen programcılara kullanımı kolay bir tool sunar. ClientAce, iki ana parça içeren bir nesne temelli programlama tool dur: DA

Detaylı

Güvenlik Java ve Web Uygulama Güvenliği

Güvenlik Java ve Web Uygulama Güvenliği Güvenlik Java ve Web Uygulama Güvenliği Melih Sakarya www.melihsakarya.com melih.sakarya@gmail.com www.mergecons.com Olası Açıklar Donanımsal açıklar Sistemsel Açıklar Yazılımsal Açıklar Sosyal Mühendislik

Detaylı

COM API v2.0 Belge sürümü : 2.0.3

COM API v2.0 Belge sürümü : 2.0.3 COM API v2.0 Belge sürümü : 2.0.3 1. Đçindekiler 1. Đçindekiler...2 2. Bu belgenin amacı...3 3. Belge sürümleri...3 4. Sistem gereksinimleri...3 5. Kullanım şekli...4 5.1 Genel...4 5.2 Uyarılar...4 5.3

Detaylı

WiFi RS232 Converter Sayfa 1 / 12. WiFi RS232 Converter. Teknik Döküman

WiFi RS232 Converter Sayfa 1 / 12. WiFi RS232 Converter. Teknik Döküman WiFi RS232 Converter Sayfa 1 / 12 WiFi RS232 Converter Teknik Döküman WiFi RS232 Converter Sayfa 2 / 12 1. ÖZELLĐKLER 60.20mm x 40.0mm devre boyutları (5-15)VDC giriş gerilimi Giriş ve çalışma gerilimini

Detaylı

OMNET++ 4.2.2. Ağ Benzetim Yazılımı (Network Simulation Framework) BİL 372 Bilgisayar Ağları. GYTE - Bilgisayar Mühendisliği Bölümü

OMNET++ 4.2.2. Ağ Benzetim Yazılımı (Network Simulation Framework) BİL 372 Bilgisayar Ağları. GYTE - Bilgisayar Mühendisliği Bölümü Bilgisayar Mühendisliği Bölümü OMNET++ 4.2.2 Ağ Benzetim Yazılımı (Network Simulation Framework) BİL 372 Bilgisayar Ağları OMNET++ OMNET++ (Objective Modular Network Testbed in C++), nesneye yönelik (objectoriented)

Detaylı

Bil101 Bilgisayar Yazılımı I. M. Erdem ÇORAPÇIOĞLU Bilgisayar Yüksek Mühendisi

Bil101 Bilgisayar Yazılımı I. M. Erdem ÇORAPÇIOĞLU Bilgisayar Yüksek Mühendisi Bil101 Bilgisayar Yazılımı I Bilgisayar Yüksek Mühendisi Kullanıcıdan aldığı veri ya da bilgilerle kullanıcının isteği doğrultusunda işlem ve karşılaştırmalar yapabilen, veri ya da bilgileri sabit disk,

Detaylı

Öğr.Gör. Gökhan TURAN www.gokhanturan.com.tr. Gölhisar Meslek Yüksekokulu

Öğr.Gör. Gökhan TURAN www.gokhanturan.com.tr. Gölhisar Meslek Yüksekokulu Öğr.Gör. Gökhan TURAN www.gokhanturan.com.tr Gölhisar Meslek Yüksekokulu Bilgisayarın Yapısı Donanım (Hardware): Bir bilgisayara genel olarak bakıldığında; Kasa, Ekran, Klavye, Fare, Yazıcı, Hoparlör,

Detaylı

JAVA API v2.0 Belge sürümü: 2.0.2

JAVA API v2.0 Belge sürümü: 2.0.2 JAVA API v2.0 Belge sürümü: 2.0.2 1. İçindekiler 1. İÇİNDEKİLER... 2 2. BU BELGENİN AMACI... 3 3. BELGE SÜRÜMLERİ... 3 4. SİSTEM GEREKSİNİMLERİ... 3 5. KULLANIM ŞEKLİ... 4 5.1. GENEL... 4 5.2. UYARILAR...

Detaylı

emon: Gerçek Zamanlı Gömülü Sistemlerin Çalışma Zamanı Görselleştirilmesi İçin Monitör Yazılımı

emon: Gerçek Zamanlı Gömülü Sistemlerin Çalışma Zamanı Görselleştirilmesi İçin Monitör Yazılımı emon: Gerçek Zamanlı Gömülü Sistemlerin Çalışma Zamanı Görselleştirilmesi İçin Monitör Yazılımı 1 Berkant AKIN Mehmet GÖKÇAY, Kaan DOĞAN TUBİTAK-SAGE Ulusal Yazılım Mimarisi Konferansı Ankara, 2010 Neden

Detaylı

Kılavuz içerisinde sisteme ait tüm özellikler anlatılmakta olup, yapacağınız konfigürasyonlar satın aldığınız lisans ile sınırlıdır.

Kılavuz içerisinde sisteme ait tüm özellikler anlatılmakta olup, yapacağınız konfigürasyonlar satın aldığınız lisans ile sınırlıdır. 1 HAKKIMIZDA Aktiftelecom, 1994 yılından bu yana deneyimli kadrosu ile telekomünikasyon sektöründe hizmet vermektedir. Satış sonrası hizmetler konusunda uzmanlaşmış teknik destek ekibi ve yurt çapında

Detaylı

AĞ HİZMETLERİ. Öğr.Gör.Volkan ALTINTAŞ. Version 4.0

AĞ HİZMETLERİ. Öğr.Gör.Volkan ALTINTAŞ. Version 4.0 AĞ HİZMETLERİ Öğr.Gör.Volkan ALTINTAŞ Version 4.0 İSTEMCİ SUNUCU İLİŞKİSİ İnsanlar her gün başkalarıyla iletişim kurmak ve rutin görevlerini yerine getirmek için ağ ve İnternet üzerinden sağlanan hizmetleri

Detaylı

NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf

NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf NComputing Erişim Cihazları Maksimum Esneklik ve Tasarruf Eylül 2010 Copyright 2010 dojop Teknoloji Hizmetleri Tic. Ltd. Şti Bilgi Teknolojilerinizde Devrim Yapın NComputing Erişim cihazları kişisel çalışma

Detaylı

VERİ TABANI SİSTEMLERİ

VERİ TABANI SİSTEMLERİ VERİ TABANI SİSTEMLERİ 1- Günümüzde bilgi sistemleri Teknoloji ve bilgi. 2- Bilgi sistemlerinin Geliştirilmesi İşlevsel Gereksinimleri 1.AŞAMA Gereksinim Belirleme ve Analiz Veri Gereksinimleri Gereksinimler

Detaylı

UHeM ve Bulut Bilişim

UHeM ve Bulut Bilişim UHeM ve Bulut Bilişim Özden AKINCI Ulusal Yüksek Başarımlı Hesaplama Merkezi (UHeM) Bilim ve Mühendislik Uygulamalar Müdürü 11.07.2012 UHeM hakkında Vizyon: Yüksek başarımlı hesaplama, bilgi teknolojileri

Detaylı

Sistem Programlama. (*)Dersimizin amaçları Kullanılan programlama dili: C. Giriş/Cıkış( I/O) Sürücülerinin programlaması

Sistem Programlama. (*)Dersimizin amaçları Kullanılan programlama dili: C. Giriş/Cıkış( I/O) Sürücülerinin programlaması Sistem Programlama Sistem programlama bilgisayar mühendisliğinin bir alanı olup karmaşık sistemlerin ve bu sistemlerin parçalarının ile ilgilenir. İşletim Sistemlerinin Programlaması Giriş/Cıkış( I/O)

Detaylı

Gezgin Etmen Sistemlerinin Başarım Ölçümü: Benzetim Tekniği

Gezgin Etmen Sistemlerinin Başarım Ölçümü: Benzetim Tekniği Gezgin Etmen Sistemlerinin Başarım Ölçümü: Benzetim Tekniği Gürol Erdoğan 1, Mustafa Yıldız 1, Mehmet Erdem Türsem 2, Selahattin Kuru 1 1 Enformatik Uygulama ve Araştırma Merkezi, Işık Üniversitesi, İstanbul

Detaylı

Bilgisayar İşletim Sistemleri BLG 312

Bilgisayar İşletim Sistemleri BLG 312 Giriş Bilgisayar İşletim Sistemleri BLG 312 İplikler geleneksel işletim sistemlerinde her prosesin özel adres uzayı ve tek akış kontrolü vardır bazı durumlarda, aynı adres uzayında birden fazla akış kontrolü

Detaylı

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC)

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem analistlerinin ve kullanıcı faaliyetlerinin spesifik döngüsünün kullanılmasıyla En iyi geliştirilmiş sistemin oluşmasını

Detaylı

Dr. Fatih AY Tel: 0 388 225 22 55 fatihay@fatihay.net www.fatihay.net

Dr. Fatih AY Tel: 0 388 225 22 55 fatihay@fatihay.net www.fatihay.net Bilgisayar Programlama Ders 1 Dr. Fatih AY Tel: 0 388 225 22 55 fatihay@fatihay.net www.fatihay.net Bilgisayar Programlamaya C ile Programlamaya Yazılım: Bilgisayarın işlemler yapması ve karar vermesi

Detaylı

LOGO İş Zekası çözümü ile kurumsal raporlama ve analizler. Cem Yılmaz Genel Müdür LOGOBI Yazılım

LOGO İş Zekası çözümü ile kurumsal raporlama ve analizler. Cem Yılmaz Genel Müdür LOGOBI Yazılım LOGO İş Zekası çözümü ile kurumsal raporlama ve analizler Cem Yılmaz Genel Müdür LOGOBI Yazılım Hakkımızda LOGOBI Yazılım A.Ş. iş zekası alanında faaliyet gösteren, Türkiye de sahip olduğu yüzlerce müşterinin

Detaylı

COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ

COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ COĞRAFİ BİLGİ SİSTEMLERİ SERVER MİMARİSİ SERVER UYGULAMA GELİŞTİRME EĞİTİMİ http://facebook.com/esriturkey https://twitter.com/esriturkiye egitim@esriturkey.com.tr Kursun Süresi: 5 Gün 30 Saat COĞRAFİ

Detaylı

MailStore tüm şirket e-postalarınızı uzun yıllar güvenle saklayabileceğiniz bir mail arşivleme sistemidir.

MailStore tüm şirket e-postalarınızı uzun yıllar güvenle saklayabileceğiniz bir mail arşivleme sistemidir. Neden MailStore! Hatırlatma : Arşivleme, posta sunucusunda herhangi bir değişiklik gerektirmez MailStore tüm şirket e-postalarınızı uzun yıllar güvenle saklayabileceğiniz bir mail arşivleme sistemidir.

Detaylı

Bilgisayar Mühendisliği. Bilgisayar Mühendisliğine Giriş 1

Bilgisayar Mühendisliği. Bilgisayar Mühendisliğine Giriş 1 Bilgisayar Mühendisliği Bilgisayar Mühendisliğine Giriş 1 Mühendislik Nedir? Mühendislik, bilim ve matematiğin yararlı cihaz ve sistemlerin üretimine uygulanmasıdır. Örn: Elektrik mühendisleri, elektronik

Detaylı

www.smsmakinesi.com destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1

www.smsmakinesi.com destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1 destek@hermesiletisim.net COM API v.1.1 BELGE SÜRÜMÜ : 1.1 1 1. İÇİNDEKİLER 1. İçindekiler 2 2. Bu Belgenin Amacı 3 3. Kullanım Şekli.3 4. Uyarılar.4 5. Hata Kodları.4 6. Kullanıcı Bilgileri Kontrolü..5

Detaylı

ÖNDER BİLGİSAYAR KURSU. Sistem ve Ağ Uzmanlığı Eğitimi İçeriği

ÖNDER BİLGİSAYAR KURSU. Sistem ve Ağ Uzmanlığı Eğitimi İçeriği ÖNDER BİLGİSAYAR KURSU Sistem ve Ağ Uzmanlığı Eğitimi İçeriği BÖLÜM 1 KİŞİSEL BİLGİSAYAR DONANIMI 1.1. Kişisel Bilgisayarlar ve Uygulamalar Bilgisayarların Kullanım Şekli ve Yeri Bilgisayar Tipleri (Sunucular,

Detaylı

Görsel Programlama DERS 12. Görsel Programlama - Ders12/

Görsel Programlama DERS 12. Görsel Programlama - Ders12/ Görsel Programlama DERS 12 1 Java Ağ İşlemleri (Java Networking) Birbirleri ile ağ araçları ve kabloları ile bağlantılı bilgisayarlar bir ağ sistemi oluştururlar. İnternet, şirketlerin yerel bilgisayar

Detaylı

Compiere Açık kodlu ERP + CRM yazılımı. Hüseyin Ergün Önsel Armağan Serkan Demir

Compiere Açık kodlu ERP + CRM yazılımı. Hüseyin Ergün Önsel Armağan Serkan Demir Compiere Açık kodlu ERP + CRM yazılımı Hüseyin Ergün Önsel Armağan Serkan Demir ERP Nedir? ERP = Kurumsal Kaynak Planlama Organizasyonların farklı fonksiyonlarının ve departmanlarının kullandığı enformasyonu

Detaylı

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER Dr. Hayrettin Bahşi bahsi@uekae.tubitak.gov.tr 11 Mart 2010 Gündem Bulut Hesaplama Sistemleri ve Bilgi Güvenliği Güvenli Yazılım Geliştirme Hayat Döngüsü

Detaylı

Atılım Üniversitesi Bilgi & Đletişim Teknolojileri Müdürlüğü Sistem Yönetim Uzmanı Görev Tanımı

Atılım Üniversitesi Bilgi & Đletişim Teknolojileri Müdürlüğü Sistem Yönetim Uzmanı Görev Tanımı Atılım Üniversitesi Bilgi & Đletişim Teknolojileri Müdürlüğü Sistem Yönetim Uzmanı Görev Tanımı Formal Doküman Detayları Hazırlanma Tarihi 17 Eylül 2012 Yayın Taslak Hazırlayan Ersun Ersoy Doküman Numarası

Detaylı

PARALOG POS AKTARIMLARI. Derece Yazılım 2009

PARALOG POS AKTARIMLARI. Derece Yazılım 2009 PARALOG POS AKTARIMLARI Derece Yazılım 2009 POS (Point of Sale) Satış Noktası anlamına gelen bu terim perakende ticarette kullanılan gelişmiş yazarkasalar için de kullanılmaktadır. POS cihazları sahip

Detaylı

Bölüm 10. Altprogramların gerçeklenmesi ISBN 0-0-321-49362-1

Bölüm 10. Altprogramların gerçeklenmesi ISBN 0-0-321-49362-1 Bölüm 10 Altprogramların gerçeklenmesi ISBN 0-0-321-49362-1 10. Bölüm konuları Çağırma / geri dönme semantiği Yığıt-dinamik yerel değişkeni olan altprogramların gerçeklenmesi İçiçe altprogramlar Statik

Detaylı

RotamNet Ticari Programı Kısa Tanıtım Dökümanı

RotamNet Ticari Programı Kısa Tanıtım Dökümanı RotamNet Ticari Programı Kısa Tanıtım Dökümanı RotamNet ; Kolay kurulumu ve kullanımıyla ön plana çıkan, teknolojik alt yapısıyla işletmelere pratik çözümler sunan ve büyük avantajlar sağlayan tam bir

Detaylı

Yrd. Doç. Dr. Gökçe BECİT İŞÇİTÜRK. Gökçe BECİT İŞÇİTÜRK 1

Yrd. Doç. Dr. Gökçe BECİT İŞÇİTÜRK. Gökçe BECİT İŞÇİTÜRK 1 Yrd. Doç. Dr. Gökçe BECİT İŞÇİTÜRK Gökçe BECİT İŞÇİTÜRK 1 Gökçe BECİT İŞÇİTÜRK 2 Kullanıcıların site içeriğini belirlemede rol oynadığı, Dinamik, Teknik bilgi gerektirmeyen, Çok yönlü etkileşim sağlayan,

Detaylı

Windows Live ID ve parolanızı giriniz.

Windows Live ID ve parolanızı giriniz. Ücretsiz Deneme Hesabı Oluşturma ve Temel Özelliklerin Kullanım Kılavuzu Bilgi girilmesi gerekli alanlar Kişisel bilgi içeren alanlar http://www.windowsazure.com/tr-tr/pricing/free-trial/ adresine gidiniz

Detaylı

İlk Konsol Uygulamamız 2 İlk Windows Uygulamamız 9.Net Framework Yapısı 18 Neler Öğrendik 19. Veri Tipleri 24 Tanımlı Veri Tipleri 27 Basit Tipler 28

İlk Konsol Uygulamamız 2 İlk Windows Uygulamamız 9.Net Framework Yapısı 18 Neler Öğrendik 19. Veri Tipleri 24 Tanımlı Veri Tipleri 27 Basit Tipler 28 ix 1 İlk Konsol Uygulamamız 2 İlk Windows Uygulamamız 9.Net Framework Yapısı 18 Neler Öğrendik 19 23 Veri Tipleri 24 Tanımlı Veri Tipleri 27 Basit Tipler 28 Kayan Nokta Tipleri 30 Sayısal Veri Tipi Dönüşümleri

Detaylı

VERİ TABANI UYGULAMALARI

VERİ TABANI UYGULAMALARI VERİ TABANI UYGULAMALARI VERİ TABANI NEDİR? Bir konuyla ilgili çok sayıda verinin tutulmasına, depolanmasına ve belli bir mantık içerisinde gruplara ayrılmasına veri tabanı denir. Veri tabanı programları;

Detaylı

Açık Kaynak Kodlu Yazılım

Açık Kaynak Kodlu Yazılım Temel Kavramlar İşletim Sistemi Bilgisayar kullanıcısı ile bilgisayarı oluşturan donanım arasındaki iletişimi sağlayan, aynı zamanda diğer uygulama yazılımlarını çalıştırmaktan sorumlu olan sistem yazılımıdır.

Detaylı

Ders Adı Kodu Yarıyılı T+U Saati Ulusal Kredisi AKTS

Ders Adı Kodu Yarıyılı T+U Saati Ulusal Kredisi AKTS DERS BİLGİLERİ Ders Adı Kodu Yarıyılı T+U Saati Ulusal Kredisi AKTS Nesneye Yönelik Programlama BIL205 1 3+0 3 5 Ön Koşul Dersleri Yok Dersin Dili Dersin Seviyesi Dersin Türü Türkçe Lisans Zorunlu / Yüz

Detaylı

Film Arşiv Sistemi. Yazılım Tasarım Belgesi

Film Arşiv Sistemi. Yazılım Tasarım Belgesi 1. Sürüm Tarihçesi Film Arşiv Sitesi Yazılım Tasarım Belgesi Sürüm Tarih Yazarlar Açıklamalar 1.0 28.12.2010 Rana ALGAN Elif BONCUK Bu belge sistemin tasarım detaylarını içerir. 2. Giriş 2.1 Amaç ve Kapsam

Detaylı

Veri Tabanı-I 1.Hafta

Veri Tabanı-I 1.Hafta Veri Tabanı-I 1.Hafta 2015-2016 Bahar Dönemi Mehmet Akif Ersoy Üniversitesi Teknik Bilimler Meslek Yüksekokulu Burdur 2015 Yrd.Doç.Dr. M. İLKUÇAR 1Muhammer İLKUÇAR, MAKÜ-2011 BURDUR

Detaylı

Görsel Programlama DERS 03. Görsel Programlama - Ders03/ 1

Görsel Programlama DERS 03. Görsel Programlama - Ders03/ 1 Görsel Programlama DERS 03 Görsel Programlama - Ders03/ 1 Java Dili, Veri Tipleri ve Operatörleri İlkel(primitive) Veri Tipleri İLKEL TİP boolean byte short int long float double char void BOYUTU 1 bit

Detaylı

Bölüm 28 ve 29 : İstemci Sunucu Etkileşimi ve Soket API sine Giriş. Internet Protokolleri ve Ağ Uygulamaları. Internet Protokolleri Üzerinden İletişim

Bölüm 28 ve 29 : İstemci Sunucu Etkileşimi ve Soket API sine Giriş. Internet Protokolleri ve Ağ Uygulamaları. Internet Protokolleri Üzerinden İletişim Bölüm 28 29 : İstemci Sunucu Etkileşimi Soket API sine Giriş Kaynak : Douglas E. Comer, Computer Networks and Internets With Internet Applications, 4. Baskı, 2004, Prentice Hall Hazırlayan : Tacettin Ayar

Detaylı

ELN1001 BİLGİSAYAR PROGRAMLAMA I

ELN1001 BİLGİSAYAR PROGRAMLAMA I ELN1001 BİLGİSAYAR PROGRAMLAMA I DEPOLAMA SINIFLARI DEĞİŞKEN MENZİLLERİ YİNELEMELİ FONKSİYONLAR Depolama Sınıfları Tanıtıcılar için şu ana kadar görülmüş olan özellikler: Ad Tip Boyut Değer Bunlara ilave

Detaylı

API geliştiricileri. Web server ile yapılan entegrasyonun neticeleri. API Dokumantasyonu

API geliştiricileri. Web server ile yapılan entegrasyonun neticeleri. API Dokumantasyonu API geliştiricileri Open API serverınızın tüm kontrolünü, groupware erişim izini, kullanıcı ve domain yonetimi, server ayarları, tasarlanma, istatistikler ve daha fazlasına bu script programı ile erişebilirsiniz.

Detaylı

İŞLETİM SİSTEMLERİNE GİRİŞ. Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği

İŞLETİM SİSTEMLERİNE GİRİŞ. Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği İŞLETİM SİSTEMLERİNE GİRİŞ Von Neumann Mimarisi Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği mimariyi temel almaktadır. Merkezi İşlem Birimi Aritmetik ve Mantık Birimi Kontrol

Detaylı

Hazırlayan: Ahmet Alper ÇALIŞKAN Probiz Yazılım Proje Mühendisi

Hazırlayan: Ahmet Alper ÇALIŞKAN Probiz Yazılım Proje Mühendisi İŞLETMELERDE İŞ SÜREÇ YÖNETİMİ (BPM) UYGULAMASI Hazırlayan: Ahmet Alper ÇALIŞKAN Probiz Yazılım Proje Mühendisi Ajanda 1) İş Süreç Yönetimi Nedir? 2) İş Süreç Yönetim Yazılımı 3) Neden İş Süreç Yönetim

Detaylı

Hızlı Başlangıç Kılavuzu

Hızlı Başlangıç Kılavuzu Hızlı Başlangıç Kılavuzu 1. Adım Windows Server 2012'yi Yükleme Bilgisayarınız Windows Server 2012 yüklenmiş olarak teslim edildiyse, 1. Adım'ı atlayabilirsiniz. Yükleme Yönergeleri Yükleme yönergeleri,

Detaylı

WINDESKCONCENTO. sıgnum. Kurumsal İş Süreçleri Uygulamaları. windesk.com.tr

WINDESKCONCENTO. sıgnum. Kurumsal İş Süreçleri Uygulamaları. windesk.com.tr windesk.com.tr WINDESKCONCENTO Kurumsal İş Süreçleri Uygulamaları Kurumsal İş & Operasyonel süreçlerin performans tabanlı otomasyonu ile hizmet verimliliği ve kalitesinde artış sağlanır. sıgnum WINDESK

Detaylı