Java ve .NET : Derin Rekabet

0
FZ
Son günlerdeki anketleri inceleyen, yazışmalara,sorulara kulak ve göz misafiri olan FZ dayanamadı ve bulduğu bir röportajı tercüme ederek FM camiası ile paylaşmaya karar verdi. Söz konusu röportaj Java dünyasındaki en kıvrak ve yetkin firmalardan biri olma özelliğini halen koruyan BEA'nın Baş Teknoloji Sorumlusu (Chief Technology Officer - CTO) Dr. Scott Dietzen ile 13 Aralık tarihinde gerçekleştirilmiş. Dr. Dietzen Java camiasında, sunucu tarafındaki Java standartlarının geliştirilmesinde yani J2EE (Java 2 Enterprise Edition) teknolojisinin olgulaşmasındaki öncü rolü ile saygı duyulan bir isim. Kendisi aynı zamanda Java Community Process kurucularından. Bu röportajın ana konusu: Java, .NET, web servisleri, vs.
İşletme dünyasında hem Java hem de .NET için yer var mı?
Evet. Java ve .Net birlikte yaşayacak ve rekabet edecekler. Günümüzde Java ile geliştirilmiş onbinlerce uygulama var ve açıktır ki Java'nın kısa vadede işletme dünyasından .Net yüzünden çıkıp gitmesi beklenemez.

Ayrıca inanıyorum ki .Net teknolojisi de epey geniş bir kitleye ulaşacak. Bunun sebebi sadece Microsoft'un ticari gücü değil, .Net mimarisi oldukça iyi bir mimari. .Net mimarisi Java camiasından bazı fikirleri alıp uyarladı ama dürüst olmak gerekirse aynı zamanda Java camiasının da taklit etmekte gecikmeyeceği birtakım akıllıca teknolojik fikirleri de ortaya koymasını bildi.

Sizce bu iyi bir şey mi?
Rekabet son kullanıcı için iyidir, sizi yenilikçi olmaya zorlar, fiyatlar düşer, vs. Samimi düşüncem şu ki Microsoft'un yarattığı rekabet Java camiasını daha da motive ediyor ve ilerlemesini sağlıyor.

Rekabet nasıl görünüyor?
Hem Java hem de .Net pek çok farklı platformu hedefliyor. Her iki teknoloji de hem cep telefonları ve PDA gibi küçük telsiz cihazlarda hem de PC ortamlarında çalışabiliyor.

Java camiası -- ve BEA -- sunucu tarafına (server side) epey yatırım yaptı. .NET uygulama sunucusu, ki gelecek yıl içinde piyasaya sürülmesi planlanıyormuş, Microsoft'un bizim yatırım yaptığımız bu alanda da rekabete hazırlandığın gösteriyor.

Bu insanları sadece şu ya da bu platformu seçmeye zorlayacak mı?
Hayır, hiç kimse Java ya da .Net arasında yekpare bir seçime gitmek zorunda değil. Aslında pek çok büyük bilgi işlem departmanı istese de bunu yapamaz çünkü her iki teknolojiyi de yoğun olarak kullanıyor olacaklar.

Ve Web servisleri bu iki farklı teknolojinin haberleşmesine izin verecek mi?
İşte tam da bu aşamada XML Web servisleri devreye giriyor. Bu teknoloji sayesinde bir kişi PC'de Visual Studio ile geliştirdiği uygulamayı cep telefonundan ya da PocketPC'den kullanıp bu uygulamanın doğrudan bir WebLogic ya da WebSphere (ya da başka bir J2EE teknolojisi) sunucu sistemi ile konuşmasını sağlayabiliyor.

Ve aynı model tersinden de düşünülebilir J2ME, J2SE gibi teknolojile için. Bunları kullanan bir istemci araç Web servisi protokollerini kullanarak .Net servisleri ile bağlantı kurabilir. Bir arada yaşamak derken kast ettiğim anahtar faktör işte bu.

Bu arada Java'yı Windows üzerinde de çalıştırabildiğinizi sakın unutmayın. Windows bugün bizim için ikinci en büyük sunucu platformu. İnsanlar HP-UX ya da diğer RISC işlemcili makinalar kadar büyük çaplı olmasa da WebLogic yazılımını Windows sunucuları üzerinde de çalıştırıyorlar. Yani Windows bir uygulama sunum ortamı olarak da epey popüler görünüyor, sadece bir uygulama geliştirme platformu olarak değil.

Yani her iki dünyayı entegre eden uygulamalar geliştirilebilir?
Elbette. Zaten bir süredir gördüğümüz kadarı ile bir kısım yazılım geliştirici istemci tarafını .Net ve sunucu tarafını da Java ile geliştiriyor. Tabii ki tek bir platform olsa işler daha kolay olur, bunu inkâr edemeyiz. Bazı özel sunucu uygulamalarında tamamen .Net ya da Java platformunda kalmak isteyebilir, uyguluma için heterojenliğin uygun olmadığını düşünebilirsiniz. O halde bugün sunucu tarafında WebLogic çalıştıran ve istemci olarak da Windows makinaları kullanan biri bunları nasıl konuşturur?
Eğer mevcut bir Visual Basic veya Visual C++ application uygulaması ise en yaygın yöntem COM teknolojisini kullanmaktır. BEA hem istemcide hem de sunucuda COM teknolojisini destekleyen bir yapıya sahiptir. Ancak eğer sıfırdan bir Visual Studio uygulaması geliştiriyorsanız o zaman takip etmeniz gereken yol Web servisleridir.

Web servisleri söz konusu olduğunda bir performans kaybı oluyor mu?
Evet. XML gerçekten de iki sistem arasında tamamen ikili sistemde (binary) kodlanmış veri değiştokuşuna kıyasla biraz daha maliyetli bir kodlama yöntemi. Hem veri boyu hem de veri işleme zamanı bakımından maliyetli. Ancak boy meselesi o kadar dert değil. Yani bir XML belgesini ZIP ile sıkıştırırsanız muhtemelen düşünebileceğiniz herhangi bir ikili kodlamadan daha az yer kaplayacaktır. Bu da demek oluyor ki bant genişliği büyük olmayan ağlar için XML belgelerinin boyu ile bir şekilde başa çıkılabilir.

Esas maliyet getiren XML belgelerinin işlenmesi. XML verisinin işlenmesi ikili sistemde kodlanmış verinin işlenmesine kıyasla nerede ise iki katı daha çok işlemci zamanı çalıyor.

Ancak aynı argümanların HTML için de geçerli olduğunu iddia edebilirim. HTML'in başarısı tam da bu gevçek kodlama nosyonundan gelmektedir. HTML ve XML, uyumsuzluğu bozmadan, ağın iki tafında da kolayca değişikli yapmanıza izin verir.

Eğer yeni ve homojen bir uygulama geliştiriyorsanız Java ya da .Net'ten birini tercih etmeniz anlamlıdır. Ancak farklı uygulamaları birbirleri ile konuşturmayı düşünüyorsanız en mantıklı yöntem XML ve web servislerinden faydalanmaktır. İşlemci zamanı bakımından biraz daha obur olmakla birlikte nihai olarak getirdikleri esneklik ve hızlı, kolay uygulama geliştirme gibi avantajlardan ötürü buna fazlası ile değdiğini söyleyebilirim.

Görüşler

0
conan
Web servisleri konusunda hic bir deneyimi/bilgisi olmayan ve sadece okuduklarinin sonucuna gore konusan bir insan olarak soruyorum:

Peki web servisleri tercuman olmaktan baska bir ise de yariyorlar mi? Yoksa asil yaratilma amaci tercumanlik mi? Iki birbiriyle konusamayan sistemi ortak bir noktada bulusturabilmek disinda da baska islevleri var mi? Bunlar yapilirken tek standart XML mi aliniyor? XML parserlar gelistirmek yerine standardizasyonla uyusmaya calismak mi daha mantikli? Yoksa inatci sirketlerin baskisi sonucu kimsenin uyusamamasi yuzunden bu parserlara zaman hacamak mi? XML`in kaybettirdigi performans ile kazandirdigi uyumluluk tradeoff`u su anda nasil olculebiliyor.

Cok uctum galiba... Bi ton soru. Tartisalim...
0
FZ
Benim de pek bir pratik deneyimim o yüzden sadece okuduklarıma ve algıladıklarıma dayanarak cevap verebilirim.

Bildiğim kadarı ile web servisleri senin tabirinle tercüman olmaktan başka pek bir işe yaramıyor ancak bu tercümanlık işinin bu sefer çok daha kolay ve standardize yapılacağı düşünüldüğü ve bunda da XML'e pay biçildiği için son 1 yıldır süper reklamı yapılıyor. Bu arada yanlış anlaşılmak istemem yani bu tercümanlık işine sadece statik veri aktarımı değil aynı zamanda fonksiyon çağırma da yani bir nevi RPC - Remote Procedure Call da dahil. Tabii bunu da en genel şekli ile bir tür tercümanlık olarak görebiliriz ki yani yeni bir kavram da değil, UNIX ortamlarında olsun Windows ortamlarında olsun yıllardır RPC, CORBA, COM+ gibi teknolojiler ile yapılmaya çalışılan bir şey. Ancak bu sefer benzer işi böyle low-level binary yapılar kullanarak değil de hemen her bir şeyciği XML ile kodlayarak çözmeye çalışıyorlar, burada tabii XML bağlamında SOAP (Simple Object Access Protocol) gibi standartlar da devreye giriyor.

Standart XML derken tam olarak neyi kast ettiğini anlayamadım. Yani standart olmayan XML gibi bir şey olabiliyor mu? Sonuçta tek bir XML standardı var ama mesele bu değil mesele bu XML standardını kullanarak yeni standartlar, belli sektörlerdeki firmaların aralarında standart olarak kullanabileceği XML tabanlı protokoller, diller inşa etmek.

XML parser geliştirmek demişsin, bildiğim kadarı ile XML parser geliştirmene gerek yok, yani programlama ortamındaki XML parserlardan herhangi biri işini görür.

Son soruna gelince, gördüğüm o ki evet yani XML, binary veriye göre biraz daha fazla overheade yol açıyor ama bu şuna benzetilebilir: adamlar nasıl ki Assembly dili yerine misal Java, C++, Delphi ile program geliştirmeyi tercih ediyorlarsa, işte büyük ve kurumsal sistemler arası bilgi işlem sistemlerini konuşturmaya çalışanlar da artık ufaktan XML kullanmaya başlıyor çünkü XML standart olması yüzünden ve text tabanlı olması yüzünden çok farklı ortamlarda, çok farklı araçlarla ve çok farklı insanlarca düzenlenmeye daha elverişli.

Ne kadar açıklayıcı oldu bilemiyorum ancak başka sorular da gelirse de elimden geldiğince cevap vermeye çalışırım. Lütfen yine de bu konuda uzman olmadığımı aklınızdan çıkarmayın ( e o zaman ne ukalalık ediyorsun be adam da diyebilirsiniz tabii :)



0
anonim
XML kucuk bir ek olarak tercih edilmesinin belki ana nedenlerinden en onemlisi kodun hem bilgisayar hemde bizim tarafımızdan aynı netlikte anlasilmasi .
0
anonim
Burada anahtar kelime aslında SOAP, SOAP sadece microsofta ait değil borland IBM vs. gibi bir çok şirketin ortak çalışması. işte SOAP''''ı kulandıktan sonra (protokol desteklerse başka şeylerde olur.) aynı web servisini çözebilirler. ÇÖZEBİLMEK: istenen veri ne geri dönen verinin türü ne gibi bunu çözen zımbırtıda WSDL aslında bu iki kelimeyi aratmanız sizi sonuca götürebilir. birde UDDI denilen bir terim var. web servisini kaydetmeniz yada ihtişacınızı karşılayacak web servisi bulmanızı sağlar vesaire....
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Bir MPEG Çözücü Nasıl Çözülür ;-)

FZ

Meşhur çip seti ve anakart üreticisi VIA´nın EPIA-M anakartları üzerinde gömülü bir CLE266 MPEG çözücü (decoder) mevcut. Bu özellik söz konusu anakartı multimedya uygulamaları için ideal hale getiriyor. Ancak küçük bir problem var, VIA´nın ürettiği yegane sürücü kapalı kod olarak geliyor. Tabii bu durumda da devreye `hacking´ ve `reverse engineering´ ruhu giriyor! Tabii planlı programlı çalışmanın da önemi yadsınamaz ;-)

Bir Türk Programcısı Sinirlenirse: CORSIS - Açık Kodlu Derlem Analiz Yazılımı

FZ

Stallman bir yazıcı sürücüsünün kapalı olması yüzünden çıldırıp işe girişmişti. Linus, okulda eğitim için kullandığı Sun Solaris işletim sistemini evde kullanamayacağını görünce Linux çekirdeğini yazmaya başlamıştı. Ian Murdock Linux kurmanın uzman olmayanlar için hiç de kolay olmayacağını fark edip Debian dağıtımını geliştirmeye başlamıştı. Bilgisayar tarihi sinirli programcıların başlarının çaresine bakarken çevreye de epey fayda sağlamalarının örnekleri ile dolu. Şimdi böyle bir örneğin haberini okuyacaksınız:

Çetin Sert, Almanya'da bilgisayarla dil işleme (NLP - Natural Language Processing) konusunda çalışan 23 yaşında genç bir araştırmacı. Sert, Mike Scott tarafından geliştirilmiş ve dil işleme bağlamında sık kullanılan bir yazılım olan Wordsmith'in kısıtlayıcı lisansını, ödenmesi gereken paraları ve bunu evindeki PC'de rahatça kullanamayacağını görüp bu konuda profesörlerinin uyarıları ile karşılaşınca...

Vim 7 çıktı!

sundance

Unix camiasının en eski editörlerinden vi'ın steroidli hali, VİM'in 7.0 sürümü Bram Moolenar tarafından anons edildi.

Yeni özelliklerini görmek ve kullanmak istiyorsanız buradan indirebilirsiniz. Daha Amiga sürümü çıkmadı, Amiga'cılar bir zahmet Subversion'a.

Tabi bir de unutmadan; cat flames.txt > /dev/null

GNU/Linux Üzerinde Cinelerra Profesyonel Video Düzenleme

FZ

Mac ustaları Final Cut Pro, Windows çılgınları Adobe Premiere kullanırken elbet GNU/Linux´a gönül veren videocuların da eli boş durmadı. 1996 yılında ilk kez kamuoyuna sunulan Cinerella halen geliştirilmeye olanca hızı ile devam ediyor. Yazılımın profesyonel özelliklerinin arasında gerçek zamanlı görsel etkiler, FireWire G/Ç, render-farm, HDTV, OggVorbis desteği, vs. bulunuyor.

GNU/Linux´un ortaya çıkışından önceki karanlık çağlarda bu tür bir yazılım ve donanım sistemi için 100.000$ civarı bir parayı gözden çıkarmanız gerekirdi. Oysa projenin anonim programcılarından Jack Crossfire takma isimli yazılımcıya göre artık bu kadar harcama yapmanıza gerek yok.

Bu usta programcı ile yapılan bir röportajın da yer aldığı O´Reilly makalesinde belki de en ilginç kısım yazının başında Jack Crossfire´ın kimlikleri saklamak konusunda söylediği sözler: "Bizimki gibi küçülen bir sektörde, yöneticiler şimdilik yetenekli mühendislerin günlük işleri haricinde harika uygulamalar geliştirmelerine hazır değiller. Bu tür yöneticiler sistemi görmezden gelen mühendislerden kurtulmak konusunda bir an bile tereddüt etmezler, sizi kapının önüne koyarlar. Bu ve benzeri sebeplerden ötürü yazılımınızı kendi isminiz altında insanlara sunamazsınız dolayısı ile `Heroine Virtual Ltd.´ tüm geliştirdiğimiz araçları bünyesinde barındıran kuruluşun ismi oldu. Bu özgür yazılım kurumunun arkasında kaç kişinin ne ölçüde emeği olduğunu ise hayalgücünüze bırakıyoruz."

Yapay Zeka ve GAWK

FZ

Neden Yapay Zekâ için GAWK?

YZ programlama sınıfında kullandığımız programlama dilinin GAWK olduğunu duyan insanların çoğu epey şaşırıyor. Bunu anlayabiliyorum. Evet, GAWK kullanıyoruz. GAWK, Aho, Weinberger ve Kerninghan tarafından geliştirilmiş ve pek çok kişi tarafından programlama dili olarak bile kabul edilmeyen şu eski kalıp tanıma dilinin Gnu versiyonudur. PERL veya TCL örneklerinde olduğu gibi pek çok kişi bu dili "scripting dili" olarak ele alır. İçinde nesneler yoktur, fonksiyonel değildir, gömülü olarak mantık programlama öğelerini barındırmaz. İnsanların şaşkınlığı şunları duyunca tam bir kafa karışıklığına dönüşüyor: (a) her ne kadar öğrenciler projelerinde istedikleri dili kullanma hakkına sahip olsalar da; (b) sadece tek bir istisna hariç, en iyi sonuca ulaşan öğrenciler GAWK ile proje geliştirenler (not: söz konusu istisnanın sahibi PASCAL kullanmış olan bir programcı, kendisi şu anda NSF bursu ile Harvard'da matematik doktorası yapıyor.) C, C++ ve LISP programcıları GAWK ile çalışanların performanslarına yaklaşamadılar (PROLOG ve JAVA kullanarak proje yapan bir öğrencimiz çıkmadı henüz).