Web Services - Aslan Payını Kim Kapacak?

Görüşler

FZ
yaklaşık 23 yıl önce

Web servisleri önemli ve bir o kadar da kafaları karıştıran bir kavram.

Microsoft ve diğerlerine gelince, diyorum ki, BEA 2002 sonunda geliştirme aracını çıkartana dek ortalık Microsoft Visual Studio.NET ile çoktan kaynıyor olacak! Orta ve biraz üzeri ölçekli işletmelerde bence Microsoft hemen her zaman olduğu gibi hakim teknoloji olacak ve bu sefer SOAP (Simple Object Access Protocol), WSDL (Web Services Description Langugage), XML (eXtensible Markup Language) ve UDDI (Universal.. gerisini unuttum, servislerin kolayca saptanmasını sağyalan bir protokol :) gibi standart iletişim ve tanımlama protokollerini kullandığı için bu sefer durum biraz daha farklı ve ilginç olacak.

Yani mesela ben çatır çatır Visual Studio.NET aracını kullanıp C# veya VB.NET ile bir servis geliştireceğim, bunu ilgili servislere kaydedeceğim, sonra sen ister UNIX ister Linux hangi sistemden bağlanırsan bağlan, UDDI protokolü ile benim servisimin adresini tespit ettikten sonra çatır çatır veri çekebileceksin çünkü ikimiz de XML, SOAP vs. kullanıyor olacağız veri aktarımı ve iletişim kontrolü için.

E bu bağlamda iletişim problemi olmadığına göre mesela ben gözüme hoş görünen ve kullanımı epey esnek ve kendi ortamımla entegre olan Visual Studio.NET ile güzel güzel program geliştirirken sen de istersen misal NuSphere, PHPEd falan kullanarak benim servisimdeki bilgiyi çeken yazılım geliştirebileceksin.

Sonuç olarak bana görünen o ki, web servis tabanlı yazılım ve bilgi sunum servisleri geliştirmede Visual Studio.NET epey kıvrak, kolay öğrenilebilir ve kullanılabilir bir araç olarak çok hızlı bir şekilde piyasayı kaplayacak.

Şu anda Şubat ayındayız, 6-7 ay sonra bilgisayar kitapçılarına ve BT sektöründen gelen iş ilanlarına bakın, ne demek istediğimi daha iyi anlayacaksınız.

Not: Noam Chomsky''yi sevmeye ve saymaya devam ediyorum! ;-)

SHiBuMi
yaklaşık 23 yıl önce

Studio.Net henüz çok yeni, o yüzden J2EE nin liderliğine pek şaşmamak lazım. Ancak Microsoft konusundaki tespitlerine katılıyorum, görünen o ki sene sonuna kalmadan Microsoft liderlik koltuğunu devralacak.

NuSphere konusunda ise durum teorik olarak dediğin gibi olmakla birlikte, Studio.Net in karşısına J2EE dışında yakın zamanda bir rakip çıkacağını zannetmiyorum. Open-source camiası Perl, Python, PHP gibi dillerin web services ile entegrasyonu konusunda çok geride kaldı, ellerinde .Net ile kapışabilecek bir IDE ya da stabil bir kütüphane mevcut değil. Bu haliyle open-source camiasının tek çıkış yolu yine Java olarak gözüküyor, ancak Linux + Java platformunun şu anki haliyle Microsoft ile performans ve geliştirme araçları, dolayısıyla geliştirme süreci itibariyle baş edebilmesi çok zor gözüküyor. Örnek olarak FZ nin verdiği linkteki Microsoft - J2EE karşılaştırmasını gözden geçirebilirsiniz.

FZ
yaklaşık 23 yıl önce

Sanırım bir kavram karmaşası çoğu kişinin kafasını karıştırabilir:

J2EE yani Java 2 Enterprise Edition teknolojisinin kabaca Microsoft muadili .NET

Microsoft Visual Studio.NET ise görsel bir yazılım geliştirme aracı dolayısı ile bunu mesela IBM'in Visual Age'i ile veya NetBeans(Forte) ile kıyaslamak gerekiyor. Bu durumda .NET - J2EE kıyaslaması bir yana, görsel yazılım geliştirme araçları konusunda Microsoft'un gücü kendini belli ediyor.

anonim
22 yıl önce

Mirosoft''un yeni vizyonu .Net piyasayı kasıp kavuracak belki ama güvenlik olayına tam olarak çözüp getirebileceği tartışma konusu olabilir.
IBM Visual Age bu konuda şimdilik lider gibi görünüyorsa da Benim kanaatim Microsoft silip süpürecek.Hak eden kazansın....
Serdar

FZ
yaklaşık 23 yıl önce

Türkiye''deki sitelerde ve gruplarda, eğer ki bunlar bilgi işlem teknolojilerine dair siteler ve gruplar ise, web servisleri kavramının geçmediği saptaması epey enteresan geldi, son altı aydır elimizi sallasak web servisi ile ilgili bir makaleye çarpıyor (yabancı sitelerde ve dergilerde).

Sırf web servisleri üzerine haber toplayıp sunan portal siteleri var : Search Web Services gibi.

Gerçekten bu kadar ilgisiz miyiz? Ekonomik kriz yüzünden insanlar teknolojiyi ve yeni eğilimleri falan takip edemez hale mi geldi? Günü kurtarma derdinde miyiz?

Not: Chomsky''yi hala çok seviyor ve kendisine saygı duyuyorum.

SHiBuMi
yaklaşık 23 yıl önce

Aslında mobil iletişim konusunda Türkiyede birçok çalışma yapılıyor. Ancak bunlar hakkında şahsen detaylı bilgiye sahip değilim, bu projelerin arasında bulunmuşluğum yok. Ama elbette mobil iletişim demek illa web services kullanılıyor demek değil, yalnızca en azından XML tabanlı bazı sistemlerin Türkiyede de kullanıldığına dair bir örnek teşkil edebilir.

İlgisizliğimize gelince, aslında bunun nedeni biraz da Web Services denilen kavramı .Net ile özdeşleştirmiş olmamız. Dolayısıyla konu Microsoft ile özdeşleşiyor ve sonuç olarak Microsoft önyargıları devreye girerek bunu Microsoftun diğer bir dünyayı ele geçirme taktiği olarak algılıyoruz. Birçok insanın sırf .Net Microsoft ile bağlantılı mantığı ile web services kavramıyla ilgilenmediğini, bildiklerinin de kulaktan dolma bilgiler olduğunu biliyoruz.

Web Services şu anda General Motors, Bank of America, American Express gibi kurumlar tarafından kullanılıyor. Bu verdiğim isimler işin boyutunun ne olduğu hakkında fikir sahibi olmaya yeterli heralde. FZ nin dediği gibi, elini sallasan web services ile ilgili bilgiye çarparken, Türkiyede insanların .Net mi bööö demesi gerçekten düşündürücü.

FZ
yaklaşık 23 yıl önce

Aslında en iyisi mesela web programcılarına web servisleri ile ilgili bir seminer vermek ve şöyle bir proje yapmalarını istemek:

-Bir portal ana sayfası hazırlayın, bu ana sayfada döviz bilgisi, üç beş manşet, hava durumu bilgisi, lotarya sonuçları, vs. olsun ve bunu web servisleri kullanmadan yapın ve bu sayfa birkaç ay boyunca ve hatta daha uzun süre düzgün çalışsın (ve görün ebenizinkini, söz konusu siteler formatlarını değiştirdiklerinde)

-Aynı portalin aynı ana sayfasını web servislerinin sunduğu bilgileri çeken arabirimle yapın (ve görün kod ne kadar daha kısa ve bir değişiklik olduğunda ne kadar az iş yapmanız gerekiyor ve hatta belki hiç gerekmiyor).

Sonuç :

Web Servisleri .NET !!!

Ama tabii .NET platformu windows ortamında web servisleri ve web istemcileri geliştirmek için çok güzel araçlar sunuyor, ama isterseniz açık standartlara uyduğunuz sürece isterseni Solaris üzerinde J2EE ve Visual Age, JSP ile falan da takılabilirsiniz, bunlar birbirlerini bağlamaz.

Yani bu şekilde düşününce o kadar da karmaşık öyle değil mi?

Ha bu arada, evet, Microsoft dünyayı ele geçirmeye çalışıyor! ;-) (Aksini iddia eden bir şirket var mı?)

FZ
yaklaşık 23 yıl önce

Yahu yukarıda Web Servisleri eşit değildir .NET ifadesini küçüktür ve büyüktür sembollerini yan yana yazmak sureti ile aktarmak istedim ama FM''nin ya da HTML cehaletimin azizliğine uğradım. Açıklama yapayım dedim, bir de şöyle deneyelim bakalım ne olacak:

Web_Servisleri != MS.NET

FZ
yaklaşık 23 yıl önce

J2EE ile gerçekleştirilmiş bir uygulama .NET teknolojisi ile geliştirilirse nasıl olur, güzel mi olur, kolay mı olur, performanslı mı olur, kısaca nedir yani diyorsanız:

Somut Uygulama Üzerinden J2EE ve .NET kıyaslaması.

Hazır kıyaslamalara girmişken:

C# Java''''ya benzer ama bazı bakımlardan neden daha güzel bir dildir?

Not: Büyük medyanın ve güçlü devletlerin son döneme dair içyüzünü somut örneklere gösterdiği için Chomsky'yi sevmeye ve kendisine saygı duymaya devam ediyorum ;-)

omniheurist
yaklaşık 23 yıl önce

Bundan daha taraflı bir kıyaslama sanırım ancak micro$oftun sitesinde bulunabilirdi!
Yani gotdotnet diye bi siteden daha ne beklenebilir ki?
hikayeyi bir de karşı taraftan dinlemek için şuraya bir göz atarsan sevinirim
Oracle9iAS vs. Microsoft .NET Benchmark Results

FZ
yaklaşık 23 yıl önce

Microsoft''un (genelde) .NET platformu ve (özelde) web servisleri ile ilgili ne kadar hırslı olduğuna dair bir örnek:

Yanlış hatırlamıyorsam, Eylül ya da Ekim ayında aldığım Dr.Dobb''s Journal CD''sinin içinden .NET SDK''sının ve Visual Studio.NET''in BETA 2 versiyonu DVD olarak çıkmıştı.

Dr.Dobb''s Journal olarak bahsi geçen dergi tüm dünyada satılan ve aylık satış rakamı 100.000 (!) civarı olan, profesyonel yazılım geliştiricilere yönelik (donanım değil sadece yazılım) çok önemli bir dergidir (ah be bi de bu kadar pahalı olmasa! :(

Not: Noam Chomsky''nin kitaplarını okuyalım, okutalım, tartışalım, tartıştıralım.

anonim
yaklaşık 23 yıl önce

belki yeri degil ama bu kadar cok yazinca dayanamadim.
Niye sadece Chomsky. (kendisini bende severim, son bir aydir adini duyup sirf reklam icin Chomsky okuyanlara da kil kapiyorum) Birilerinin ipligini pazara cikartmaktan bahsediyorsak bu listeye eklenecek cok isim var. Aklima Turkiye den I.Besikci geliyor mesela. Cok isim var cook.

FZ
yaklaşık 23 yıl önce

Açıklayayım: Ana sayfada sundance arkadaşımızın GPL ile ilgili bir yazısı var. Bu yazıya yorum yazan arkadaşlarımızdan SHIBUMI, yazısının bir yerinde Richard Stalmann'dan ve Noam Chomsky'den hazzetmediğini belirtiyor ve onların kendi ışıklarında kör olan insanlar olduğunu iddia ediyor.

Chomsky, Türk medyası ve kurumları tarafından konuk edilmeden epey bir süre önce adamla ilgili detaylı olarak okuma yapmış biri olarak, dayanamadım, bir miktar fanatik ;-) ve provoke edici :-O birkaç not ekledim mesajlarımın sonuna.

Yoksa tabii ki iktidar odaklarının ipliği pazara çıkarma konusunda burada adını anmadığımız pek çok üstadımız olduğu gibi, binlerce isimsiz kahraman da mevcut. Chomsky, biraz da simge isim, sembol isim haline geldiği ve bu sitedeki mesajlardan birinde 'hoşlanılmayan' bir isim olarak geçtiği için kendisinin adını öne sürdüm. Tepkimin sebebi ve söz konusu durumun açıklamasu bundan ibarettir.

skoylu
22 yıl önce

WebServíces degil ama bir hayli benzer ve enteresan bir uygulamada bizden geliyor. Hedefleri anlatan paperin Alpha versiyonunu geceyim size dedim.. Bu sistem bir veri tasima protokolu etrafinda sekillenen bir FrameWork ve bunun OpenSource implementasyonunu getiriyor. Temelde WebServices icin gelistirilmedi ama o amacla kullanmaya da yatkin.Her tur elestirilerinizi bekleriz. Bu ve bagli diger protokol specleri, yakinda www.clirp.org adresinde yayinlanacak baslayacak.Protokol ve bilesenlerin standart uygunlugu icin, bunlari ayni zamanda RFC olarak yayinlamayi dusunuyoruz.

Sene sonuna dogru bunun calisan ilk orneklerini gorebilecegiz gibime geliyor.

Elestiri ve Onerileriniz icin:

skoylu@fisek.com.tr

Original WhitePaper - inside from Gelecek A.S.

CLIRP v1.0
Dizayn Hedefleri:
1. Sistem üzerinde uniform bileşen yönetimi sağlamak.
2. Bileşenlerin birer object haline dönüşebilmesi gereken altyapıyıyı sağlamak. Object, bilindiği üzere veri ve onu işleyecek kodun birlikte bulunması halidir. CLIRP, sistem bileşenlerini bir nesne olarak yorumlar. Nesnenin içersinde onu konfigüre edecek ve raporlayacak her şey bulunmalıdır.
3. Bileşenler arasında maksimum veri uyumluluğu sağlamak.
4. Bileşen ithalini sağlamak.
Tarihçe:
Gelişen ve değişen endüstriyel ihtiyaçlar IT sistemlerinin dinamik olarak yönetilebilmesi sorununu gündeme getirmiştir. Buna paralel olarak bilgiye her yerden erişebilme sorunu doğmuştur. Bu ihtiyaç başta Internet olmak üzere çeşitli şekillerde aşılmaya çalışılmıştır. Fakat her ürünün farklı bir yaklaşım getirmesi, ürünler arasındaki veri taşınabilirliğini büyük ölçüde zorlaştırmıştır. Network seviyesinde kolaylıkla gerçekleştirilebilen saydamlık, uygulama seviyesinde bir türlü geliştirilememiştir. Bu sorunu aşmak üzere, Java ve .NET CLI gibi platform bağımsızlığı sağlamaya çalışan girişimler bu konuyu farklı bir açıdan ele alarak sunum seviyesinde uniform bir arabirim oluşturmayı yeğlemiştir. XML gibi, verileride unfiorm bir arabirimle taşıyabilme yönündeki çalışmalarda hızla ilerlemiş fakat tüm bunlar sistemin kendi işleyişi üzerine çok etkili olamamıştır.
CLIRP, bu noktada işletim sistemini ve üzerinde çalışan uygulamaları internet çapında birleştiren bir arabirim olarak düşünülmüştür. Öncelikle, işletim sistemine ve uygulamalara bakışımız uniform olarak dizayn edilmiş bir bileşen modeline çevrilmiştir. Bu modelde bir uygulama hedef ve istekleri açısından şu öğelere sahip olarak bir bileşen olarak addedilir.
1. Gerekli kaynaklar. Uygulamanın çalışması için gerekli olan sistem ve donanım bileşenleri. Bunlar dependencies olarak adlandırılmıştır.
2. İstenmeyen kaynaklar. Uygulamanın sistemde bulunmamasını istediği kaynaklardır. Örneğin bir serverin çalışması için, başka bir web server olmamalıdır.
3. Kurulum öncesi gerekenler. Gerekli kaynaklardan sistemde mevcut olanların yanında, sadece kurulum esnasında ihtiyaç duyulacak olan öğelerle, kurulum öncesinde sistemin o uygulamanın istediği özelliklere yönelik olarak yapılandırılmasını sağlayacak yordamlardır. Bunun yanında bu bileşenin sistemden kaldırılması ve bir önceki versiyondan yükseltilmesi için gereken öğelerde bu kapsamda mevcut olmalıdır.
Bir bileşen bunların tamamını açık olarak tarif etmelidir. Bu tariflerin uygun işlenebilmesi için bileşenin sundukları da aynı şekilde açık olarak tarif edilmelidir.
İşte bu şekilde tarif edilmiş olan bir bileşen internet üzerinde mevcut olan herhangi bir yerden:
1. Kullanılabilir. Bu bileşenin ürettiği veri, dileyen herkes tarafından edinilebilir. Bu bir tur RPC uygulaması gibi düşünülebilir. Güncel sistemlerin hemen hemen hepsi RPC servislerini desteklemektedir. Fakat bunlar terminal modu şeklinden daha öteye gidememiştir. Son dönemde yapılan XML-RPC ve SOAP gibi çalışmalar bu konuda büyük yol katedilmesini sağlamışlardır. CLIRP bu noktada sistemi daha radikal bir yaklaşımla yönetmektedir. CLIRP kendisi bir XML RPC sağlamaz, fakat, çeşitli verileri -örneğin- XML-RPC olarak gönderip alabilir.
2. Yüklenebilir. Bu noktada, bileşen kullanılmak üzere sisteme dahil edilir. Bir bileşenin sisteme dahil edilmesi ile işler hale getirilmesi birlikte gerçekleşir.
Bu, elbette bazı sorunlara yol açmaktadır. En başta güvenlik problemleri gelmektedir. Bu sorunu aşmanın çeşitli yolları mevcuttur. Microsoft, bunu method bazında güvenlik denetimi uygulayarak aşmayı düşünmektedir. Bir yerde dahiyane bir fikir olmasına rağmen, bir tür sanal makine ile çalışan bir uygulamada kod sekanslarının ne zaman ne yapacağını kestirmek son derece güç olabilir. Bu şekilde bir düşünce bir tür kod firewall oluşturmak olarak kabul edilebilir. Elbette bu gerekli bir metot olmasına karşın, garantili bir metot değildir. Bu noktada CLIRP yazılımların sertifikasyonunu sağlayarak bu sorunu halleder. CLIRP sisteminde dahil edilecek hiç bir komponent sertifikasyonsuz olamaz. Bu aynı zamanda hangi bileşenin nereye yüklendiğini de takip edeceğinden, olası bileşen güvenlik problemlerinde derhal müdahale edilebilmesini sağlayacaktır. .NET IL kodu, sadece bu kodla yazılmış olan uygulamaların bir yere kadar güvenli olduğunu teyit edebilir. Sistemin tamamının ise, .NET IL koduyla yazılması -şimdilik- mümkün değildir. Bu size bileşen sağlayanların dışındaki sistemin güvensizliği anlamına gelebilir. Oysa CLIRP, sistem kernelide dahil olmak üzere, her şeyi bu şekilde güvenli olmaya zorlar. CLIRP'in hedef işletim sistemleri, GPL ve diğer Free Software ürünleri olup, bunlar için sertifakasyon yapılması konusundaki endişeleri aşmak son derece kolaydır.
Portabilitiy, bir diğer sorun olmaktadır. CLIRP doğası gereği bir platform için özelleştirilmemiştir. Ayrıca, CLIRP'in taşıdığı bileşenlerin platform olarak taşınması çok kolaydır. Çünkü, CLIRP çalıştığı sisteme özel bir dependency verisi oluşturacaktır. Bu, bir CLIRP RETRIEVE verisinin tam olarak sizin platformunuza uygun olarak elde edileceğinin bir garantisidir. Bunun yanında, uzun vadede LI benzeri bir multiplatform kod oluşturulabilecektir.
Gelecekte neler olacak ?
CLIRP uniform olarak çalışan bir bileşen tespit ve temin etme protokolüdür. Bu protokol bu niteliği sağlamak için gereken herşeyi içermektedir. Aynı protokol diğer yandan yazılım bileşeni dışında kalan nesneleride bulmak üzere kullanılabilir. Bu, CLIRP protokol kurallarıyla bilgiye erişebildiğiniz gibi, örneğin satın almak üzere bir emtia'yada ulaşabilirsiniz anlamına gelmektedir. CLIRP, location inspect (yer tespiti) yanında RETRIEVE içinde gereken tüm bileşenleri içerir. Bu, bilhassa e-ticaret alanında CLIRP'in kullanılmasıyla son derece yetkin sistemler oluşturulabilmesini sağlayacakır. Tipik e-ticaret kavramları, son kullanıcıyla perakendecilere optimize olarak yapılmıştır. Oysa, CLIRP bileşenin tüm süreci üzerinde hakimiyet sağlar. Bu, örneğin akreditif uygulamasınında CLIRP ile sağlanabilmesini mümkün kılar. Siz ödemenin size teslim edildiğinin teyidiyle yapılmasını sağlayabilirsiniz. RETRIEVE fazı, bileşenin kaynak ve hedefini kurallandırabilmenizi sağlar. Öyleki, siz siparişinizin ve sevkiyatınızın o anda hangi fazda olduğunu, kolayca görebilirsiniz. Tüm süreç istenirse, finansman kurumu veya müşterinin belirleyeceği bir CLIRP Logger'ine kaydedilir. Bu, doğacak ihtilafların çözümünde gerekli olacaktır. Öyleki, kullanıcının verileri kullanıcının belirttiği key olmadan açılamaz. Bu da SPY problemlerini ortadan kaldırır.
CLIRP modeli.
CLIRP modeli bir tür peer-to-peer, proxy tabanlı sunucu sistemidir. Birbiriyle bağıntılı iki katmandan oluşur. CLI ve CRP. CLI, Component Location Inspector, CRP Component Retrieval Protocol. Bu ikisi birbirinden tam olarak yalıtılmış değildir. Bir component aranırken, bunu aramaya yarayacak componentde retrieve edilebilir. Ilk bakışta karmaşık olarak görünmesine rağmen, İkisini tek bir protokol olarak düşünmek CLIRP'i anlamayı kolaylaştırır. CLIRP Protokol olarak OSI Layer 5 ve 6 (gerektiginde 3 ve 4'te kullanılabilir) seviyelerinde çalışır. Bu seviyede çalışan pek çok uygulama, doğrudan görevleri kendi yerine getirecek şekilde düşünülmüştür. Oysa CLIRP, bu seviyede bir tür taşıma katmanı sunabilir. Bu, CLIRP'in değişik platformlara kolaylıkla intibakını sağlar. Örneğin WEB servisleri üzerinden CLIRP uygulamaları yapılabilir. Bunun yanında, CLIRP sadece bir veri taşıma katmanı olarak işe yaramayacaktır. Sistem yönetimi temel amaç olarak düşünüldüğünden, sistem seviyesinde CLIRP application framework oluşturulması bir zorunluluk olmaktadır. Fakat, CLIRP'in gelişimi ve genişletilebilir protokol altyapısı bunu zorunlu kılmaz, sadece CLIRP'i sistem yönetiminin bir parçası olarak kullanmak isteyenler için gereklidir. CLIRP bu aşamada, diğer ağ protokolleri gibi saydamlığı sağlamak üzere CLIRP implementasyonlarının uyması gereken kuralları da dokümanlaştırır.
Sonuç olarak, CLIRP bir Bileşen temin etme protokolünün yanında bu bileşenlerin kullanımı ile ilgili pek çok spesifikasyonuda betimler. Ayrıca, CLIRP bu işlev için elzem olabilecek noktalarda kendi alternatif bileşen mekanizmalarını da tarif eder. Örnek olarak, CLIRP protokolüne özel olarak bir kullanıcı doğrulama protokolü getirilmiştir. Bunun yanında CLIRP ihtiyaçlarını karşılayabilecek yepyeni bir dosya transfer protokolü de düşünülmüştür. Diğer yandan CLIRP kullanımı bunlara mahkum değildir. Dilediğiniz durumda, örneğin farklı bir kullanıcı doğrulama protokolünü CLIRP için kullanabilirsiniz.
CLIRP Mimarisi:
CLIRP temelde, endüstri standardı olmuş, popüler protokollerin bir sentezidir. Bu sayede implemantasyon süresi çok kısalmaktadır. Ayrıca başta POSIX olmak üzere, yaygın işletim sistemlerinin temel bileşenlerinin kullanılmasını amaçlamaktadır. Bu, CLIRP'in platform bağımsızlığını kolaylaştırmaktadır. CLIRP teorik olarak her işletim sistemine her noktadan uygulanabilir. Gerek sistem seviyesinde, gerek application seviyesinde faydalanılabilir. Bu, şu anlama gelmektedir. Siz, gerekli sistem framework bileşenleriyle, heterojen bir ağı homojen bir şekilde yönetebilirsiniz. Diğer yandan CLIRP'in size sunduğu gelişmiş bileşen toplama mekanizmasıyla uygulama seviyesinde çalışabilirsiniz. Tüm bunları iyi bilinen protokollerle sağladığınız için implemantasyon zamanından büyük tasarruf edebilirsiniz.
Bu tür bir sistemin mantıklı olarak görev yapabilmesinin ilk koşulu, ağların localize edilebilmesi olması gerektiği görülmektedir. Bu nedenle bir local ağda, CLIRP enabled makinelerden bir tanesi mutlak olarak Local MASTER görevini üstlenir. Local Master Bir üst masteri bulur. Bu şekilde alan çapında masterler birbirine eklenmiş olur. Protokol, masterlerin diğeri için gateway olarak çalışmasını varsayılan olarak kabul eder. Halbuki, Local masterin etki alanında bulunan makinelerin CLIRP servislerine erişim istenmeyen durumlar oluşturabilecektir. Bu nedenle gerekli görüldüğü zamanlarda, Local Master olarak bir makine adanır, bu makine aynı zamanda dış ağlar için bir proxy hizmeti verir. Ağ üzerinde CLIRP masterin seçimi otomatik olarak yapılır. Benzer protokollerden SMB'nin aksine bunun için tarif edilen kıstaslar ağ yükünde önemli bir artışa yol açmaz. Local ağ üzerinde etkili bir konfigürasyon sağlanması için, ağ IP yönetiminin CLIRP üzerinden sağlanması büyük kolaylık sağlayacaktır. Güncel olarak otomatik IP yapılandırması sağlayan DHCP protokolü, CLIRP IP yapılandırma protokolüyle uyumludur. Daha doğru bir tabirle, CLIRP OSI Level 2/3 uzantılarında tarif edilen IP yapılandırma protokolü, DHCP server yerine kullanılabilir. CLIRP enabled bir IP yapılandırma hizmet vericisi klasik DHCP istemcilerine hizmet verebilir. Diğer yandan, bu hizmet vericiyi kullanarak IP yapılandırma hizmeti isteyen bir CLIRP enabled sistem, tüm sistem bileşenlerine erişim için gerekli olan yapılandırma bilgisini edinmiş olur. CLIRP otomatik yedekleme sürecine sahiptir. Bu sayede, her CLIRP sistem servisi ve CLIRP Masteri, kendinin otomatik bir yedeğini oluşturabilir.
CLIRP veri taşıma işlemleri için XML'in bir tür subseti olan SimpleXML kullanır. Bu betimleme, XML'in standart olarak çok kapsamlı olan çeşitli bileşenlerinden arındırılmasıyla elde edilmiştir. SimpleXML, DTD, NameSpaces gibi universal bir veri taşıma sisteminde elzem olan bileşenler, CLIRP bağlantılarında kullanılmaz. Bu sayede, XML parse yükü ve XML'i yorumlama yükü çok azaltılmıştır. Örneğin, DTD tarif edilmiyor olması, sistemde bir HTTP istemcisi ile uzak olabilen serverlerden Doküman şablonu indirmek gereksinimini azaltır. Aynı şekilde, CLIRP-RPC servisleri de XML-RPC'ye benzer şekilde fakat, daha sade ve Header/Platform bağımsız olarak tarif edilmiştir.
Diğer yandan, Binary XML ile, CLIRP servislerin bilhassa host içindeki haberleşme ve sistem yükü arındırılmıştır. Host'un aynı binary formatları (HighEndian, BigEndian, Floating Point ve integer formatları vs.) kullanacağı, aynı host üzerinde aynı veri tipini (sıkıştırma, video/resim formatı vs.) işleyebilen bir bileşenin bulunacağı düşünülünce, Host içinde içindeki haberleşme için bunun çok daha verimli olacağı görülebilecektir. CLIRP'in sistemdeki diğer bileşenler için bir tür hizmet olduğu, sistem bileşenleri için maksimum kaynak ayrılması gerektiği düşünülmüştür.
Diğer yandan, ağ kullanımında karşınıza gelebilecek olan her şey bir CLIRP nesnesi olarak yorumlanmaktadır. Bir CLIRP nesnesi, ağ destekli bir bilgisayarın temel fonksiyonları kadar, ağın bir parçasını oluşturan makinelerin, CPU, storage, modem vs. gibi her bileşenini kapsamaktadır. Bu sayede, CLIRP için oluşturulacak genişletmelerle, ağdaki kaynakların kullanımı kolaylaşacaktır. CLIRP kaynak kullanımını tarif etmez. Fakat o kaynağın yerini kolayca bulmanızı, onu kullanma hakkınızı, hatta onun şu anki yüküne göre alternatif bir diğer kaynağı bulmanızı sağlar. Öyleki, bu kaynak, internet üzerinde bir yerlerde dahi olabilir. Basit bir örnekle durumu açmak istersek, Istanbul'daki işyerinden CLIRP sizin için DALLAS'taki bir modemi bulup bununla DALLAS içindeki bir yerden fax-back alabilmeniz için kullanılabilir. Öyleki, buradaki FAX hizmeti verecek modeme yapacağınız ödeme bile CLIRP ile otomatikman halledilebilir. Diğer yandan, siz izin verdiğiniz ölçüde, o modeme erişebilmeniz için gereken yazılımda otomatikman indirilip sisteminizde çalışır hale getirilebilir. Bu işlev o kadar otomatize edilebilirki, tamamı tek bir tıklamayla yerine getirilebilir.
Bu elbette iddiali bir yaklaşım. Elbette, bunun gerçekleştirilebilmesi için UDDI benzeri bir sisteme ihtiyaç duyulmaktadır. Bu sistemin yapılması için gerekli olan tüm bileşenler CLIRP FrameWork içersinde mevcut olup, protokol olarak CLIRP'in fonksiyonları yeterli olmaktadır.
CLIRP diğer yandan ağ bileşenlerine yeni bir bakış getirmektedir. Ağ üzerinde yer alabilen her şeyi bir CLIRP nesnesi olarak kullanma kabiliyeti. Bu durumda malum güvenlik ve erişim problemleri yaşanabilecektir. CLIRP bu nedenle ağ üzerinde tanımlamaya özel önem vermektedir. Bilhassa bu tür işlemlerde çok büyük sorunlar yaratan man-in-the-middle saldirilari, arada bulunan herhangi bir network bileşeninde oluşabilecektir. Bağlı olduğunuz ISP veya sizin hizmet aldığınız şirketin bağlantısı üzerinde oluşacak böyle bir durum sizi çok kötü durumlarda bırakabilir. CLIRP framework ve CLIRP kullanıcı doğrulama bu işlevleri son derece güvenli olarak halledebilir.
Bu, doğrulama bilgisinin iki noktada oluşturulması ile sağlanır. Sizi doğrulayan sistemin, size hizmet verecek sistemden farklı olması imkanı sağlanmıştır. Böylece, siz, doğrulama veya hizmet verici bir şekilde izleniyor olsa bile, sizin güvende olan bilgilerinize erişim sağlaması mümkün değildir. Diğer yandan bu doğrulama sistemi, işlevin geçerli olması için gerekli olan verileride taşır. Sizin, ödeme aracı kurum (banka) ve hizmet sağlayıcının kabul ettiği bir dördüncü kurumun işlemi onaylaması imaknı vardır. Bu bilhassa, uzaktan mal siparişlerinde çok faydalı olmaktadır. Şöyleki, eğer, banka, satıcı, siz ve kargo şirketi CLIRP kullanıyor iseniz, malın uluslararası teslim anlaşmasına göre, size tesliminde, kargoya tesliminde vs. ödemenin bankaca yapılması sağlanabilir.
Bu durum, bilhassa kredi kartı uygulamalarında yaşanan kargoda kaybolma, haksız ödeme vs. sorunlarını ortadan kaldıracaktır. Diğer yandan geleceğin internet servislerinde önemli bir yer tutan webservices hizmetleride CLIRP avantajlarıyla kolay ve güvenli olarak temin edilir. CLIRP transfer protokolünün bir parçası olan, CLIRP stream hizmeti web üzerinden sağlanan hizmetin kullanıcıya tam olarak ulaştığını teyit eder. Örneğin bir program satın almışsanız, bu programın tamamını indirdiğiniz teyit edilinceye kadar, Edindiğiniz download yetkisi geçerli olacaktır. Aynı şekilde, bir film seyretmek istediğinizde, filmin tamamını seyredinceye kadar filmin kalanını izleme hakkınız baki kalacaktır.
CLIRP doğrulama sistemi, doğrulanan kaynak üzerindeki yetkileri oturum bazında, zaman bazında, adet bazında veya kredi/jeton bazında sınırlandırabilir. Diğer yandan, mevcut doğrulama sistemleri (HTTP Basic, UNIX Shell, NCSA, Radius, PAM, vs.) CLIRP için kullanılabilir. CLIRP Retrieval uzantıları, bunların tümü için birer handler sağlayabilmenize ve bunu dilediğiniz formatta kullanabilmenize imkan tanır.
CLIRP stream uzantıları, bilgisayar tabanlı kaynakların takibi için son derece esnek bir metot sunar. Bu kaynaklarda, aynı şekilde bir CLIRP nesnesi olarak kabul edilir. CLIRP protokolü burada, kullanmak istediğiniz veri ile birlikte, o veriyi sisteminizde kullanmak için gereken bileşenleri beraberce sisteminize ekleyebilir. Burada, akıllara takılan en büyük soru, bu otomatik download mekanizmasının güvenilirliği ve yükleme problemlerinin nasıl aşılacağıdır.
Bir bilgisayar verisinin işlenmesi için gerekli olan kodlar, tamamen ayrık bir bileşen olarak kabul edilir. Bu, bileşenin temini, CLI için kolayca aşılabilecek bir durumdur. CLI sistem bileşen uzantıları, öncelikle mevcut sistemde ve en yakın makineler üzerinde bu tür bir kaynağın mevcudiyetini arar. En yakın makineler, öncelikle yerel ağ olacaktır. Eğer yerel ağ üzerinde istenen veriyi işleyebilecek bir uygulama mevcutsa, bu uygulama doğrudan sisteme entegre edilebilir. Hatta, desteklenen sistemlerde, uygulama doğrudan bulunduğu makinede çalıştırılarak sizin verinizi işlemesi sağlanır. Dizaynı en başından CLIRP sistemine uygun olarak geliştirilmiş bir işletim sisteminde (CLIRP Enabled OS), uygulamayı çalıştıran serverde, uygulamanın kullanıcı/grup kimliği, ev dizini vs. tamamen o uygulamanın kontrolüne geçer. Bu sayede uygulamanın asıl çalıştığı makinede bir güvenlik sorunu oluşturması riski en aza indirilmiş olur. Örnek olarak bir kelime işlemci dökümanını okumak üzere başka bir makinedeki programı çalıştırdıktan sonra, program ile yeni bir dosya açmak isterseniz, kendi ev dizininiz dışında başka dizinlere müdahale edemezsiniz.
Bu anlatılan veriler içinde, farklı hususları tekrar açıklamak faydalı olacaktır. CLIRP, size bileşen ile ilgili yer bilgilerini veren, istendiğinde bu bileşeni kullanmanız için gereken diğer bileşenleri bulup getiren bir protokoldür. Bu protokolü taban alan uygulamalar CLIRP Application olarak anılmaktadır. Örneğin, CLIRP ile kullanıcı doğrulama yapan bir uygulama. Diyelimki bir Proxy server kullanıcıları için CLIRP kullanıcı doğrulama uzantılarını kullanabilir. Bir Web uygulaması, CLIRP ile çalışarak, XML RPC benzeri bir hizmet verebilir. Bu uygulamalar, CLIRP'in getirdiği güçlü özelliklerle hayatınızı kolaylaştırmak için pek çok şey yapabilirler. CLIRP uygulamaları kolayca hazırlanabilir. Diğer yandan CLIRP protokolü kendisiyle uyumlu olmayan uygulamaların CLIRP çerçevesi içersinde işletilebilmesi için gerekli tanımları da yapar. Bu sayede siz uygulamaların ürettiği log bilgileri, hata mesajları vs. için CLIRP uzantıları yazarak o uygulamanın CLIRP hizmetlerinden faydalanmasını sağlayabilirsiniz. Örnek olarak, bir Web Serverin, log çıktısını yorumlayarak, Web Serverin PHP destekli olarak çalışması için gereken bileşenlerin yüklenmesini sağlayabilirsiniz. Diğer yandan native bir CLIRP uygulaması tanımadığı bir dosya tipi için, otomatikman bir CLIRP eventi oluşturup, gerekenin yapılmasını sağlayacaktır.
Bir diğer yapı ise, CLIRP implemented sistemlerdir. CLIRP'in uygulama bazında işlenmesinden ziyade sistem bileşenleri arasında avantajlarını kullanmak için oluşturulmuştur. Bu durumda sistemdeki CLIRP uygulamaları için makine üzerindeki CLIRP router arabirimi kullanılır. Bu arabirim sayesinde sistem üzerindeki tüm CLIRP uygulamaları birbirine ulaşabilir. Fakat CLIRP FrameWork'un sistem izleme gücünden faydalanmak imkanı bulunmaz.
En iyi yol, sistemin CLIRP enabled olmasıdır. Bu tür bir sistemde kaynak ve bileşen yönetimi tamamen CLIRP üzerinden yapılır. Öyleki, sistem üzerindeki tüm olağanüstü durumlar izlenebilir. CLIRP enabled bir sistemde, sisteme dışarıdan yapılan her türlü müdahale gözetim altındadır. Öyleki bir dosyanın kullanıcı tarafından yer değiştirmesi dahi handle edilebilir. Diğer yandan, sistemin tüm konfigürasyonu CLIRP ile sağlanabilir. Bu tür bir sistemde bilhassa CLIRP destekli uygulamalar kullanılması halinde sistem yönetimi olabilecek en kolay hale getirilebilecektir.
CLIRP temelde bir protokol adı olmasına rağmen, bu protokolü baz alarak saydam ve homojen bir ortamda çalışma imkanı sağlayabilirsiniz. Bu protokol, implementasyonu ve uygulama geliştirme için gerekli olan tüm spesifikasyonları ile birlikte bir bütün olarak ele alınmalıdır.
CLIRP ve diğer benzer teknolojiler:
CLIRP'in dizaynında temel amaç, mevcut teknolojilerin bir taklidini yapmak olmamıştır. CLIRP protokolü ve çevresinde şekillenen FrameWork, bilinen ihtiyaçların sağlanmasına yöneliktir. Bu nedenle, özellikle temiz oda yöntemine başvurulmuştur. Mevcut benzer özellikler gösteren uygulamaların nasıl çalışıp neler yaptığı, avantaj ve dezavantajları ortaya konmamıştır. Bu nedenle mevcut veya gelişmekte olan sistemlerin bu protokolün yaptıklarını ve daha fazlasını yapabiliyor olması mümkündür. CLIRP dizayn ekibi bu konuda, aynı yöntemi izlemeyi prensip olarak kabul etmiştir. CLIRP protokolü ve CLIRP FrameWork, her tür geliştirme önerisine açıktır. Fakat bu önerilerin foo ürünü bunu şöyle yapıyor şeklinde değil, Şu şekilde yapılırsa, böyle bir netice alınır, bu da şu problemlerin çözümünü sağlar şeklinde yapılması şarttır. Eğer, endüstri standardı olmuş, bilhassa özgür yazılımlarda kullanılabilmesi her hangi bir problem içermeyen mevcut protokollerin, CLIRP sistemine entegrasyonu temel hedeftir. Böylece, özgür yazılım felsefesinin gereksinimleri daha iyi sağlanabilmektedir.
Diğer yandan ayrık olarak işlenmiş ve bir türlü en başından entegre olarak düşünülmemiş olduğundan, interneti oluşturan dev bilgi havuzu bugüne dek verimli şekilde kullanılamamıştır. Bu yönde yapılan örnek çalışmalardan 1-2 tanesini anarak kabaca bir karşılaştırmak yapmak ihtiyacı duyulmaktadır.
Microsoft .NET ve CLIRP: MS .NET Teknolojisi CLIRP teknolojisinden çok farklı bir amaçla geliştirilmiştir. CLIRP verinin yerini bulma ve onu işleyecek bilgiyide bulma amacını taşırken, .NET, elinizdeki bilgiyi sunmanız için gerekenleri size sunar. CLIRP kullanarak siz size sunulan bilgi yerine, mevcut olan bilgilerden sizin istediğinizi alıp kullanırsınız. Bu sayede, platform bağımsızılığını sağlamak üzere kapsamlı ve ürkütücü RPC servislerine ihtiyacınız kalmaz. Diğer yandan CLIRP hiç kimseyi hiç bir kaynağı kullanmak konusunda mecbur bırakmaz. Sign on benzeri bir davranış içerisinde değildir.

Görüş belirtmek için giriş yapın...

Web Services - Aslan Payını Kim Kapacak?

Görüşler

İlgili Yazılar

Truva Linux 1.0 Beta Duyuruldu!

BIOS Logosunu Değiştirelim

Açık Kaynak ve Para Kazanmak

MyAsist Web Framework

StarLogo programının yeni sürümü duyuruldu