Pazar, Kasım 19, 2006

3G looking for a way out : X-Series

3 X-Series: Flat Rate 3G
Hutchison Whampoa, owner of the 3 mobile network has announced their curiously named "X-Series". No, the X-Series is not a phone, but it's a tariff.


What makes X-Series special is that (as far as we know) it's the first flate rate 3G call plan anywhere - subscribers pay a fixed monthly fee for access to pretty much anything they want. 3 say: "X-Series customers will only pay a flat access fee on top of their basic subscription and then what?s free to use on the internet should be free to use on mobile broadband (subject to fair usage and international roaming conditions, of course)"


3G sanırım artık ayakta kalmak için son hamlelerini deniyor. 3G'nin başarısız olmasının en büyük nedeni maliyetiydi. Kullandıkça öde modeli, son kullanıcıya cazip gelmediği için 3G'ye yapılan yatırım operatörleri zor durumda bırakıyordu.

Bu yüzden 3G üreticileri X-Series ile Internet devlerini de (Google, Yahoo, Skype, ebay, vs.) arkalarına alarak cep telefonları üzerinden sabit fiyata sınırsız internet imkanı sunmaya karar vermişler:

Initially, 3 have partnered up with a variety of internet content and service providers. Yes, we've seen Google, Yahoo, Microsoft (for Windows Live Messenger) and eBay before, and frankly these are the staple diets of most internet users. However two of the services are pretty novel for a mobile phone network - Skype and Slingbox support. Skype is pretty well known for its ultra-cheap or free internet telephony. But the Slingbox is something quite different - this allows you to stream media from your home to another device, so for example you could stream your digital TV signal from home to your mobile phone, so you can watch just about anything, anywhere. There are a number of other multimedia features too.

Fakat
şu an X-Series uyumlu sadece 2 cep telefonu modeli (Nokia N73 ve Sony Ericsson W950i) mevcut. Bu cep telefonları kullanılarak laptop'lara sınırsız internet erişimi kazandırmak da mümkün, lakin bağlantı hızı çok yüksek değil. (<384kbps)

This is a bold move from 3, and it acknowledges the fact that the old style of charging per megabyte wasn't that attractive to customers - and indeed, most customers were just using their 3G phones for talking and texting, particularly on the 3 network which has offered very good value in order to build market share. Indeed, it's hard to see how other operators can continue to offer their current 3G data plans against a flat rate competition.

3G'NİN ÖNÜ AÇIK AMA BİR ŞARTLA
Ericsson araştırması, Türkiye'de henüz lisansı çıkmadığı için operatörlerin hazır olmasına karşın tüketiciye ulaşamayan 3G uygulamalarına karşı tüketicilerin istekli olduğunu ortaya koyuyor. Kullanıcıların yüzde 48'si video telefonu, yüzde 47'si cepten internet, yüzde 38'i mobil TV gibi uygulamalara talep beyan etti. Ancak, Kulabaş'ın altını çizdiği nokta ise tüketicilerin 3G uygulamasında kesinlikle tek fiyata limitsiz kullanımdan yana olduğu, zira katılımcıların yüzde 78'i tek sabit fiyat istiyor.


Benim merak ettiğim zararına yapılan bu promosyonun 3G balonunu ne kadar daha ayakta tutacağı:

The problem is that mobile networks have paid billions for their licenses, and as yet have made precious little return on their investment. For example in the UK, the 5 3G operators shelled out a massive £22 billion for licenses in a country with around 45 million handsets. In order to recoup costs, operators will have to earn a whopping £500 per subscriber, and this doesn't seem to be happening.

3 haven't said how much the X-Series call plan will cost, but they have said that it will be available from 1st December 2006 in the UK, then during 2007 in other Hutchison 3 territories.

Telekom dünyası da büyük bir değişime gebe demiştik ama açıkçası ben bile bu kadar erken beklemiyordum.

Professional Open Source
Telekom sektörü bu aralar 3G vs. Wimax rekabetinin yarattığı etkiyle sessiz sedasız ama sancılı bir değişim yaşıyor. Aslında rekabet Kapalı ve Açık Sistemler arasında. Bu rekabette 3G Kapalı Sistemleri, Wimax ise Açık Sistemleri temsil ediyor. Özellikle 3G'nin bir çok ülkedeki ticari başarısızlığı ve beklentileri karşılayamaması rekabeti iyice kızıştırıyor.

Bakalım bu yakınlarda daha neler duyacağız...

Cumartesi, Kasım 18, 2006

Professional Open Source

Aslında bu hafta sonu için farklı bir konuda blog yazmayı planlamıştım ama perşembe günü RSS Reader 'ima düşen aşağıdaki blogu okuyunca fikrim değişti.

Nokia, Vienna to don Red Hat
Nokia plans to use Red Hat Enterprise Linux as its primary operating system for carrier-grade telecommunications equipment through a partnership announced Wednesday. Red Hat staff will be located at Nokia to provide consulting, support, certification and training services, but terms of the deal weren't disclosed.

Nokia gibi bir telekom devinin alt yapısını bir Open Source firması olan Red Hat'a emanet etmesine bir çoğunuz şaşırmış olabilir. Bildiğiniz gibi geçen nisan ayında Red Hat JBoss'u 320 milyon dolara satın almıştı. Open Source dünyasını yakından takip edenler Red Hat'ın bu hareketine pek anlam verememişlerdi. Anlaşılan Red Hat büyük işlere hazırlık yapıyormuş.

Telekom sektörü bu aralar 3G vs. Wimax rekabetinin yarattığı etkiyle sessiz sedasız ama sancılı bir değişim yaşıyor. Aslında rekabet Kapalı ve Açık Sistemler arasında. Bu rekabette 3G Kapalı Sistemleri, Wimax ise Açık Sistemleri temsil ediyor. Özellikle 3G'nin bir çok ülkedeki ticari başarısızlığı ve beklentileri karşılayamaması rekabeti iyice kızıştırıyor.

Bu değişimin benzeri aslında yaklaşık 5 sene ilk evvel IT sektöründe, Open Source ile başladı ve hala da devam ediyor. Telekom sektöründeki bu değişim üzerinde konuşmadan evvel öncelikle IT dünyasındaki değişime bir göz atmak gerekiyor.

Open Source hareketinin ve etrafındaki topluluğun gücü ilk başta birçok IT vendor'u tarafından görmezden gelindi veya küçük görüldü. IT vendor'ları Open Source'u 3-5 gencin evinde hobi olarak geliştirdiği, ticari sistemlerin production ortamlarında kesinlikle kullanılamayacak ve kendilerine rakip olamayacak uygulamalar olarak görüyordu. JBoss'un 2. numaralı adamı olarak kabul edilen Sacha Labourey bir blogunda bu görmezden gelişi şu şekilde tanımlıyor:

Open Source Positioning

The sixth category, the "in-denial", prefer not to see Open Source and will make sure to mention its existence as less as possible. When you speak about OSS to such a company representative, (s)he will usually stare at a virtual spot on the ceiling and start whistling a well-known song. Like for the second category ("mixed-codebase"), I also see this category as a transition stage. Abuse of that stage usually leads to stage five ("head-less chicken").

Halbuki Open Source başlangıçta amatör bir hobi olarak başladıysa bile zamanda içinde www.apache.org , www.jboss.org , www.objectweb.org, www.opensymphony.com, www.codehaus.org gibi toplulukların öncülüğünde profesyonel ve ciddi bir iş haline dönüştü.

Professional Open Source diye adlandırılan bu yeni yazılım ve iş geliştirme metodolojisinin öncülerinden olan JBoss'un kurucusu Marc Fluery de bir blogunda Professional Open Source'u şöyle açıklıyor:

From Volunteer Open Source to Professional Open Source
Something that some people don't know about Jboss is that we ALL STARTED AS VOLUNTEERS. Some people wrongly assume we started as a company that embraced FOSS (Free & Open Source Software) for marketing purposes. While the marketing is great make no mistakes. We DO NOT HIRE someone that has not started as a volunteer. I and ALL of the JBoss developers came out of the volunteer open source community.
...
Also the reality of Enterprise IT FOSS software is that most of the core development is done by a handful of people, the top 5% of the development ranks. I ***LOVE*** THESE PEOPLE, I WANT THESE PEOPLE TO GET FULL TIME COMPENSATION AND A NICE UPSIDE AS WELL. They need to be full-time paid professionals, these are the guys we hire at JBoss. They may work for a Professional Open Source company like JBoss or MySQL, first-generation OS packager like Red Hat, or their work may be subsidized by academia, governments or corporations in the loss-leader open source model practiced by companies like IBM, but the point is that somebody is paying the bills; there is no free lunch. Romantic myth perpetrating the contrary (FREE DEVELOPERS!) are disgusting to me, which is why I come across as strongly as I do. OUR MODEL AT JBOSS IS THAT THE BEST VOLUNTEERS BECOME FULL TIME EMPLOYEES HERE, which is why Jboss looks like it is developed by Jboss employees, a great contributor will become a Jboss employee with stock options and the whole nine yards.

Marc Fluery'nin de blog'unda belirttiği gibi Professional Open Source gücünü dünyanın en iyi gönüllü developer orudusundan alıyor ve ayrıca bu işi hayır amaçlı yapmıyorlar. Marc Fluery gönüllüler ordusundan başka bir blog'unda şu şekilde bahsetmiş:

Will Professional Open Source become dominant in Middleware?
  • JBoss Employee Contributions. Of course the company has done well, so many former contributors to the projects now have real, paying jobs that allow them to develop on a full time basis for JBoss, Inc. This of course is the core of the company - people moving from contributors to making their living from this business. This is a lot of people writing free software for the rest of the community.
  • Over 400,000 Developers now use JBoss. They contribute in many ways - from testing and finding bugs to creating added value components on top of JBoss.
  • Over 5,000 Forum Contributors help each other to find the best way to use JBoss and come up with new and interesting ideas on how to improve the software.
  • Over 500 Developer Contributors are signed up to participate in our developer forum and email list. Over time nearly 1,000 people have contributed code to the JBoss code base. Some are simple bug fixes, some are major pieces of functionality, some are great ideas for the next version, or even good ideas on what new projects JBoss should be creating.
Eğer vaktiniz varsa yukarıda alıntı yaptığım blogların tamamını okumanızı öneririm. Professional Open Source'u daha iyi anlamak için önemli mesajlar içeriyorlar.

IT dünyasındaki Professional Open Source'un yarattığı bu değişim zaman içinde istemeye istemeye de olsa IT vendor'ları tarafından kabul gördü ve Oracle, IBM gibi büyük vendor'lar gönülsüz gönüllü open-source'a destek vermeye başladılar. Geçenlerde SUN'ın Java'yı da open-source yapacağını duyurması (FOSS Java, Finally!) IT dünyasındaki open source değişiminin sonuna gelindiğinin ayak sesleri gibiydi.

Bir sonraki blog'umda IT dünyasında yaşanan bu gelişmelerin önümüzdeki yıllarda Telekom dünyasını nasıl etkileyeceğinden bahsedeceğim.

İyi hafta sonları...

Log4A (Log for Admins)

Hepimizin bildiği gibi test ve production ortamlarında bir hata alındığında, bu hatanın esas kaynağını tespit etmek epey vakit alan bir işlemdir. Eğer hata bir de kritik bir süreci durduruyorsa, bir sürü insan seferber edilmek zorunda kalınır. Hataların kaynağının tespitinin zor olmasının başlıca nedenlerinden biri de Java'da exception durumunda yapılan loglamanın System Admin'ler düşünerek yapılmıyor olmasıdır.

Bir Developer olarak eğer daha evvel Application veya Database Adminliği yapmadıysanız, kodlarınız içinde yapacağınız loglama daha çok development amaçlı olacaktır. Halbuki test ve production ortamlarında ihtiyaç duyulan loglama çok farklıdır. Log4j kullanıyor dahi olsalar eğer loglama yaparken kendini Admin yerine koyabilenler çok daha yararlı loglar yazdırdığınızı fark edeceklerdir.

Peki bir Developer kodlama yaparken kendini Admin yerine nasıl koyar. Öncelikle local'inizde development yaparken, sorunun nerden kaynaklandığını bir bakışta anlayamadığınız bir hata almayı bekleyin. Bu hatayı aldığınızda normalde ilk olarak yaptığınız şey debug etmek olacaktır. İşte bu noktada kesinlikle debug yapmayın, unutmayın kendinizi Admin yerine koydunuz, production ortamında debug imkanı yok. Şimdi debug yapmadan mevcut loglara bakarak hatanızı bulmaya çalışın, yarım saat geçtikten sonra hala bulamadıysanız, bir de akşam saatleri ise artık kesin Admin gibi hissetmeye başlamış olmanız lazım. Bu kadar duygu sömürüsü yaptıktan sonra isterseniz Log4A örneklerine geçelim ve hangi durumlardaki loglamaların önemli olduğuna bir bakalım.

Test ve production ortamlarındaki hataların yaklaşık %75'i entegrasyon hatalarından oluşur. Özellikle bir çok katmanın bulunduğu mimarilerde bu tip entegrasyon hataları daha çok olur. Bu tip hataların en çok çıktığı durumları özetlersek:
  1. Database Connection (JDBC Connection)
  2. File System Access (file read, write)
  3. Classpath Access (Configuration file, class loading, etc.)
  4. Remote Application Server Access (RMI, Remote EJB Call, etc.)
Yukarıdaki özetlediğimiz şekilde, kod içerisinde uygulamanızın dışındaki bir ortama erişimde bir hata alındığında aşağıdaki örneklerdeki gibi loglama yapmanız çok faydalı olacaktır. Öncelikle bir tane loglama yapılmış ama Log4A kullanılmamış bir kod örneğine bakalım. Aşağıdaki kod parçasında sql query'sindeki tablonun production ortamına atılmamış olduğunu varsayalım:

public static String getCustomerName(String customerID){

String customerName="";
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
Connection connection = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:TEST", USERNAME, PASSWORD);
String query = "SELECT * from CUSTOMER_INFO where CUSTOMER_ID="+customerID;
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);
while (rs.next()) {
customerName = rs.getString("CUSTOMER_NAME");
}
connection.close();
} catch (Exception e) {
logger.error(e);
e.printStackTrace();
}
return customerName;
}

Bu kodu çalıştırdığımızda şu şekilde bir hata alıyoruz.

java.sql.SQLException: ORA-00942: tablo veya görüntü mevcut degil

Gördüğünüz gibi Admin olarak tablonun hangisi olduğunu, hangi veritabanında olduğunu bilmemiz mümkün değil. Saolsun Oracle da tablo adını vermediği için elimiz ayağımız bağlı. Developer'a ulaşıp yardım almaktan başka çaremiz yok. Stacktrace'ten koda bakıp tabloyu tespit etmeye de çalışabiliriz ama aynı metod içinde birden fazla sql de olduğu durumlar olabilir. Bunun yerine aşağıdaki şekilde Log4A yaparsak Admin'lerin hatanın kaynağını hemen tespit edebilir:

public static String getCustomerName(String customerID){
String query = "";
String dbUrl = "";
String customerName="";
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
dbUrl = "jdbc:oracle:thin:@localhost:1521:TEST";
Connection connection = DriverManager.getConnection(dbUrl, USERNAME, PASSWORD);

String query = "SELECT * from CUSTOMER_INFO where CUSTOMER_ID="+customerID;
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);
while (rs.next()) {
customerName = rs.getString("CUSTOMER_NAME");
}
connection.close();
} catch (Exception e) {
logger.error("query= "+query); //Log4A
logger.error("dbUrl= "+dbUrl); //Log4A

logger.error(e);
e.printStackTrace();
}
return customerName;
}


Bu kodu çalıştırdığımızda ise şu şekilde çok daha açıklayıcı bir hata alıyoruz:

query= SELECT * from CUSTOMER_INFO where CUSTOMER_ID=12345678
dbUrl= jdbc:oracle:thin:@localhost:1521:TEST
java.sql.SQLException: ORA-00942: tablo veya görüntü mevcut degil

Gördüğünüz gibi hatanın hangi veritabanında, hangi tabloda olduğu apaçık belli. Bu sayede hatanın sebebini tespit etmek artık çok daha kolay. Bizim örneğimizde parametre olarak
connection url vardı , EJB uygulamalarında bu parametre DataSource olabilir, sql yerine store procedure olabilir. Benzer örnekleri aynı mantıkla çoğaltabiliriz ama sanırım gerek yok.

Özetle bir hata alındığında hataya sebep olabilecek kritik parametrelerin try bloğundan önce initiliaze edilip, exception bloğunda loglanmasına Log4A diyoruz. Bu sayede Adminler test ortamlarında günlerce, production ortamlarında saatlerce hataların sebeplerini aramak zorunda kalmazlar.

Salı, Kasım 14, 2006

Evolved EDGE

3G'ye henüz geçmemiş operatörler, Evolved EDGE ile ilgili haberleri okuyunca herhalde ucuz kurtulduklarının farkındadırlar. Eğer 3G'ye dünya kadar yatırım yapmış bir operatör olsaydım, 3G teknolojisini satan firmanın yakasına yapışır "Madem mevcut 2G altyapısı ve lisansı ile 3G'nin sağladığı veri hızı sağlanabiliyordu niye bize sattınız bu gereksiz teknolojiyi" diye sorardım.

Evolved EDGE is Emerging as an Attractive Alternative to 3G

According to a new Research Brief from ABI Research, GSM operators are increasingly focused on Evolved EDGE as a viable alternative to 3G network upgrades in 2008 and beyond, following the forthcoming release of a new 3GPP standard. With spectral efficiency similar to HSDPA and 1xEV-DO, Evolved EDGE promises to deliver data rates equivalent to 3G while utilizing existing GSM spectrum licenses.

"The radio spectrum can be used more efficiently to provide data service continuity between GSM and W-CDMA," notes Cox. "Evolved EDGE, which uses the same spectrum as GSM and EDGE, will allow broadband data speeds to be supported across the network."

Pazar, Kasım 12, 2006

TinyMCE: What You See Is What You Get

Son yıllarda Wiki ve Blog sitelerinin artmaya başlamasıyla son kullanıcının html ekranlarını kullanarak rich format diye tabir edilen Word tadında veri girişi ihtiyacı ortaya çıktı. Normalde bir html ekranına koyacağınız TextArea işinizi görse de, kullanıcı girdiği metini formatlayamadığı için çok kullanışlı olmuyordu.

Bunun yerine genelde kullanıcılar formatlanmış metnini Word'de yazıp uygulamaya attach ediyordu. Tabii ki Word dokümanı içerisindeki metinde arama yapmak, düzeltme yapmak, vs. büyük sorun oluyordu.

Son yıllarda JavaScript teknolojisinin gelişmesiyle Javascript HTML WYSIWYG diye adlandırılan editörler gelişmeye başladı. İşte bu yazının konusu bu editörlerin en meşhuru TinyMCE.

TinyMCE Features
  • Easy to integrate, takes only two lines of code.
  • Customizable through themes and plugins.
  • Customizable XHTML 1.0 output. Block invalid elements and force attributes.
  • International language support (Language packs)
  • Multiple browser support, Mozilla, MSIE, FireFox, Opera and Safari (experimental).
  • PHP/.NET/JSP/Coldfusion GZip compressor, Makes TinyMCE 75% smaller and a lot faster to load.
  • Open-source
Eğer herhangi bir download yapmadan neymiş bu TinyMCE, bir görelim diyorsanız Full featured example sayfasına tıklayıp TinyMCE ile neler yapabileceğinizi hemen görebilirsiniz.

Confluence , Blogger , XWiki gibi meşhur wiki/blog uygulamaları da editor olarak TinyMCE kullanıyor. Örneğin şu an okumakta olduğunuz yazıyı da
Blogger 'ın TinyMCE editöründe yazıyorum. Bazılarınızın aklına hemen "Google'ın Gmail'i de editör olarak TinyMCE mi kullanıyor?" sorusu gelebilir. Sorunuzun cevabı hayır. Google genelde bu tip uygulamaları kendi geliştiriyor çünkü kendine has bir çok özelleştirmeler yapıyor.

TinyMCE 'yi wiki/blog haricindeki uygulamalarınızda özellikle son kullanıcılardan feedback almak için kullandığınız Şikayet, Öneri, Raporlama, vs. gibi ekranlarınızda kullanabilirsiniz.

Detaylı bilgi için: http://tinymce.moxiecode.com/

Cumartesi, Kasım 11, 2006

XML: The Performance Killer

Bu yazımın esas amacı aslında Java uygulamarında XML kullanmanın getirdiği maliyetleri ve Dennis Sosnoski amcamızın meşhur XML Model Benchmark Test'lerini tanıtmak.

XML teknolojisi yazılım dünyasının işlerini bir çok noktada kolaylaştıran ama bir o kadar da zorlaştıran bir teknoloji. Özellikle Java ile uygulama geliştiriyorsanız XML'den olabildiğince uzak durmak gerekiyor. XML parsing & generating operasyonları sırasında çok fazla String işlemi olduğu için JVM memory ve CPU kullanımı korkunç artıyor. XML'e performance killer diye boşu boşuna dememişler.

XML'in
performance killer 'dan nasıl project killer 'a dönüşebileceğine bakmadan evvel öncelikle neden uygulamalarımızda XML kullanmak zorunda kaldığımıza bir bakalım.

XML kullanımı,
özellikle Java dünyasında Web Service'lerin yaygınlaşması ile artmaya başladı. Web Service kullanımını arttıran da hepimizin yakından bildiği SOA (Service Oriented Architecture) oldu. 2000'li yılların başında SOA'nın moda olmaya başlamasıyla, dünyaca ünlü vendor'larımız her zaman yaptıkları gibi bu kavramı da hemen suistimal etmeye başladılar. Bir metodoloji çok tuttuğunda vendor'larımızın ilk yaptığı şey, satabilmek için ortaya zorlama bir ürün çıkarmaktır. SOA'nın bu ürünü de Web Servis implemantasyonları oldu. Web Service ailesi (XML-RPC , REST, SOAP) içinde de en fazla öne çıkarılan SOAP mesajları oldu.

Halbuki
SOA'nın felsefisinde tüm servis hizmetlerinin web servisler aracılığı ile verilmesi diye bir zorunluluk yoktur. SOA'da bir servise dış veya iç sistemden erişim ihtiyacı varsa öncelikle servis hizmetini veren (server) ile alanın (client) ortamlarına bakmak gerekir.

1. Durum Servis hizmetini veren ve alanın aynı java container'ında olması.
2. Durum Servis hizmetini verenin ve alanın farklı java container'larında olması
3. Durum Servis hizmetini verenin java fakat alanın farklı bir dile (ASP,C#,vs.) ait container'da olması.

1. Durumda istemci ve sunucu aynı JVM'de olduğu için zaten web servis kullanmaya gerek yoktur. Fakat dikkat edilmesi gereken konu, SOA'nın şartlarından biri olan servisler arası bağımsızlığın (loose coupling) korunmasıdır. Spring Framework 'unun da kullandığı Inversion of Control diye adlandırılan patterni bu duruma güzel bir örnektir.

2. Durumda istemci ve sunucu farklı container'da olmasına rağmen iki taraf da java olduğu için yine web servis kullanmaya gerek yoktur. İlk bakışta servis çağırmak için RMI kullanmak en mantıklı çözüm gibi gözüksede, RMI teknolojisinin http protokolü kullanmaması nedeniyle firewall ve proxy'lerde problem yaşaması, farklı java versiyonları kullanan istemci/sunucu mimarilerinde sorun yaşanması gibi sebeplerden pek tercih edilmemektedir.

Bunun yerine en mantıklı çözüm serialized java objects kullanmaktır. Serializable java nesnelerini aynı web servis mantığı ile örnekteki gibi byte array'e çevirip container'lar arasında http üzerinden transfer edebilirsiniz. Objelerin serialVersionUID 'lerini değiştirmediğiniz sürece JDK 1.3 - 1.5 arasındaki container'lar arasında bile servis çağırabilirsiniz. Serialization&DeSerialization, XML parsing'e göre çok daha hızlı, daha az memory kullanan, binary olduğu için daha az data büyüklüğü oluşturan bir işlemdir. Vakti zamanında yaptığımız testlerde özellikle büyük datalarda 30 kata yakın performans elde etmiştik. Eğer bu konuda daha yetenekli, productionda kullanmaya hazır bir API'ye ihtiyaç duyarsanız JBoss Remoting 'e bir göz atabilirsiniz.

3. Durumda istemci java'dan başka bir container olduğunda web servis kullanmaktan başka bir çare yok. Fakat bu konuda da alınabilecek önlemler var. Eğer standart web servis implementasyonlarından herhangi birini seçme imkanınız var ise SOAP'dan kesinlike uzak durun derim. SOAP çok genel amaçlar için tasarlanmış ve sistem performansını en çok düşüren bir XML protokolüdür.

XML'in sisteminizin performansına olan etkisini belirleyen 3 önemli unsur vardır:

1. XML'in yapısı

Varsayalım elimizde 100KB. büyüklüğünde 2 farklı yapıda XML dosyası olsun. Birincisinin ağaç yapısında aşağıdaki örnekteki gibi olduğunu varsayalım:

<service name="GET_CUSTOMER_INFO">
<input>
<param name="CUSTOMER_ID"></param>
</input>
<output>
<param name="CUSTOMER_NAME">MUSTAFA</param>
<param name="CUSTOMER_SURNAME">MUSTAFA</param>
........................................................................
</output>
</service>

İkincinin ise tek nod'dan oluştuğunu varsayalım:

<data name="CUSTOMER_INFO">asdjhadhadas89789adjkahsdjk........sdhjh567sdf</param>

Herhangi bir XML parser ile (DOM, SAX, PULL farketmez) yukarıdaki aynı büyüklükteki 2 farklı yapıdaki dosyayı parse ettiğinizde çok farklı sonuçlar (hız, cpu ve memory kullanımı) elde ettiğinizi göreceksiniz. Birazdan bahsedeceğimiz XML Parser'in seçimi ile XML'in yapısı arasında çok yakından bir ilişki vardır.

2. XML'in büyüklüğü

XML data'sı büyüdükçe sistem performansı doğal olarak düşer. Fakat XML verisinin büyüklüğü ile sistem performansı arasındaki oran logaritmiktir. Bunun sebebi ise XML'in daha evvel bahsettiğimiz gibi çok fazla memory ve cpu kullanmasıdır. Bir JVM'de aynı anda çok fazla XML parsing işlemi olduğunda CPU bu işlemleri sıraya koymaya başlıyacak, sırada bekleyen XML nesneleri çok fazla memory kullandığından heap'i doldurmaya başlıyacak, JVM heap'in dolduğunu görünce sık sık GC (Garbage Collector) çalıştırmaya başlıyacak, GC çalışırken çok fazla CPU kullandığı ve tüm sistemi çalıştığı sürece suspend ettiği için tüm sistem tabir yerinde ise ağır çekimde ilerleyecektir. Tabii bu durum son kullanıcıya program çöktü olarak yansıyacaktır.

3. XML Model

Buraya kadar anlattıklarımıza rağmen data alışverişlerinde hala XML kullanmaya kararlı iseniz o zaman yapmanız gereken doğru XML parseri seçmek. Aynı zamanda bir SOA danışmanı olan Dennis Sosnoski 'nin eski ama hala meşhur XML Model Benchmark sonuçlarını incelerseniz, farklı test tipleri için meşhur XML API'lerin nasıl değişik test sonuçları verdiğini görebilirsiniz.

Ben genelde parser olarak çok daha hızlı olan ve az memory kullanan PULL parser'ları tercih ediyorum. Bu konuda size de XPP3 'i önerebilirim. Fakat son yıllarda VTD-XML isminde XML datasını String olarak değilde byte olarak işleyen çok hızlı bir XML parser ön plana çıktı. (world's fastest XML processor benchmark results).

Sonuç

Buraya kadar anlattıklarımızı özetlersek çok çok mecbur kalmadıkça konfigürasyon dosyası dışında XML kullanmayın derim. (Bu konfigürasyon dosyalarını okumak için de lütfen kendiniz bir API yazmaya kalkmayın, Apache Commons Configuration'ı kullanın.) Diyelimki çok mecbur kaldınız o zaman aşağıdaki önerilere kulak asmanızda fayda var:

1) SOAP'tan uzak durun ve XML'in yapısını oldukça basit tutun. XML'in yapısı ne kadar basit ise o kadar hızlı işlenir.
2) Farklı yapılarda XML veriniz var ise hepsi için aynı XML Model'ini kullanmayan. Hatta process etmeden evvel, XML'in büyüklüğüne ve yapısına bakıp en uygun XML Model'ini seçen generic bir API bile yazabilirsiniz.
3) Veri büyüklüğünün üst sınırını bilemediğiniz servislerinizi XML ile sunmayın ya da limit koyun. Test ortamlarında ortalama 100Kb.'lık datalar ile çalışırken, production'da bir servis sonucu 10MB.'lık bir XML oluşursa çok ciddi üzülürsünüz :)
4) XML operasyonlarını servisi hazırladığınız veya karşıladığınız katmanda yapın ve XML objelerini hemen basit java objelerine çevirin. Business metodları içine XML objelerini geçirmeyin.
5) Vendorların her söylediğine hemen kanmayın (hatta şüphe ile yaklaşın). Unutmayın onların hedefi daha fazla ürün satmak, sizin hedefiniz ise projenin başarılı olması.

Bu aralar AJAX'ın çok moda olması nedeniyle XML konusunda bir hatırlatma daha yapmak istiyorum. Bildiğiniz gibi AJAX 'da client/server arasındaki data alışverişini mecburen XML ile yapıyor. Developer'lar AJAX kullanırken XML yüzünden sisteme binen yükün farkında değiller. Konu açılmışken AJAX'a henüz giriş yapmayanlar Sezer Yeşiltaş'ın AJAX konusundaki blog'una bir göz atabilirler

Performans katili, projenizin katili olmasın.

İyi çalışmalar...





Etiketler: , , , ,

Pazar, Kasım 05, 2006

3G and Turkey

Bir önceki 3G ile ilgili blogumda bir sonraki blogumun Wimax ile ilgili olacağını yazmıştım ama 3G ile ilgili o kadar çok haber çıkıyor ki şu aralar. Bu haberlerin ortak özelliği 3G 'den bahsederken aslında farkında olmadan bize Wimax lazım diyor olmaları.

Son haber Ericcson'un küresel mobil iletişim araştırmasından. Bakın bu araştırmanın 3G ile ilgili kısmından nasıl bir sonuç çıkmış:

3G'NİN ÖNÜ AÇIK AMA BİR ŞARTLA

Ericsson araştırması, Türkiye'de henüz lisansı çıkmadığı için operatörlerin hazır olmasına karşın tüketiciye ulaşamayan 3G uygulamalarına karşı tüketicilerin istekli olduğunu ortaya koyuyor. Kullanıcıların yüzde 48'si video telefonu, yüzde 47'si cepten internet, yüzde 38'i mobil TV gibi uygulamalara talep beyan etti. Ancak, Kulabaş'ın altını çizdiği nokta ise tüketicilerin 3G uygulamasında kesinlikle tek fiyata limitsiz kullanımdan yana olduğu, zira katılımcıların yüzde 78'i tek sabit fiyat istiyor.

Kulabaş, her yıl yaklaşık 1.5 milyon "teknoloji kullanıcısı" gencin mobil pazara dahil olduğunu, bunun da 3G için en azından 5 milyon'luk potansiyel bir pazar yarattığını savunuyor. Kulabaş'a göre, Türkiye'nin 3G pazarı İsveç, Norveç, Belçika gibi birçok gelişmiş Avrupa ülkesinin tüm mobil pazarıyla denk bir hacme sahip olacak.

Gördüğünüz gibi son kullanıcı aynen evindeki internet bağlantısında olduğu sabit fiyata sınırsız bağlantı istiyor. Maalesef operatörlerin
3G ile müşterilerinin bu talebini yerine getirmesine imkan yok. Bunun sebebi ise daha evvel bahsettiğimiz gibi 3G altyapısının getirdiği yüksek operasyonel maliyetler.

3G 'nin yapamadığını Wimax nasıl yapacak diyorsunuz. Beklediğinize deyecek merak etmeyin :)