zipdiff

Eğer J2EE teknolojilerini kullanarak geliştirme yapıyorsanız sıkça ear, war ve jar dosyaları ile haşır neşir oluyorsunuz demektir. Bu tip dosyalarla uğraşanların en büyük ihtiyacı farklı versiyondaki 2 aynı dosyanın içeriklerinin karşılaştırılmasıdır. ear ve war dosyaları içerisinde ayrıca jar gibi sıkıştırılmış dosyaların bulunması nedeniyle klasik programlarla komple bir karşılaştırma yapmak mümkün olmaz.

İşte bu ihtiyaçtan yola çıkarak açık kaynak dünyasının bir diğer cengaveri Sean C. Sullivan isimli kardeşimiz vakti zamanında zipdiff isimli basit ama süper faydalı bir uygulama geliştirmiş.

zipdiff kullanarak ear/war/jar/zip formatındaki dosyaları karşılaştırıp html veya text formatında çok güzel bir rapor elde edebilirsiniz. Tek yapmanız gereken http://zipdiff.sourceforge.net/ adresinden son zippdiff'in son versiyonunu indirmek, zipdiff.jar ve commons-cli-1.0.jar dosyalarını aynı klasörde olacak şekilde aşağıdaki örnek komutu çalıştırmak:

java -jar zipdiff.jar -file1 foo.zip -file2 bar.zip -outputfile diffs.html

Use the zipdiff tool when you need to compare the contents of two zip files. It is equally suited for comparing jar files, EAR files, WAR files or RAR files. Run it standalone or as an Ant task. The tool supports three output formats: plain text, XML, and HTML. zipdiff is written in Java.

http://zipdiff.sourceforge.net/

iphone & IMS Debate

iphone
Geçen hafta Steve Jobs yine yapacağını yaptı ve iphone ile piyasayı salladı. Ben de dahil olmak üzere çoğumuz iphone'un göz kamaştırıcı görünüşüne ve özelliklerine yoğunlaştık. Halbuki henüz FCC 'den onay almamış olan iphone'un bazı negatif yönleri mevcut:

iPhone is cool, but not for the masses!
Already people(including O’Reilly mac devcenter bloggers) talking about these, some of them are:
* No 3G, it works on Cingular EDGE platform, not on Cingular 3G network HSDPA.
* No OTA.
* Cannot install third party software.
* No expandable memory. I think 8GB is enough memory, but the for iPod video lovers, its a disadvantage.
* No removable battery. If the battery is broken, you send the phone to Apple instead of they sending you the battery. So no problem. Coming to using the extra battery, its definitely a disadvantage. But how many people are using extra batteries for their mobile phones? Its very small amount. So I don’t think its a big deal.

Yukarıda bahsi geçen olumsuzluklardan bence en önemlileri 3G desteğinin olmaması ve pilin cihazla bütünleşik olması. Ama yine de Apple çok güzel bir ürün çıkarmış ve de kesinlikle çıktığında piyasayı sallayacak.

IMS Debate

Cuma günü RSS okuyucumda gözüme çarpan IMS ile ilgili bir yazı , son zamanlarda okuduğum en müthiş makaleydi. Burada bu makale ile ilgili çok fazla alıntı yapmayacağım çünkü sizin de bu makaleyi baştan sona okumanızı istiyorum. Ama öncelikle bu makalenin yazarı Lee Dryburgh'u biraz tanıyalım:

Lee Dryburgh explores some of the concerns surrounding the IP Multimedia Subsystem (IMS) which will be used in next-generation operator networks and which lies at the core of their future strategies. Lee has been a consulting engineer for a number of telcos and equipment vendors and is the author of the best-selling book on SS7.

Lee Dryburgh bu makalesinde Telekom dünyasına ağır göndermeler yapmış. Örneğin:

"The world has changed a lot in a year. I'm not so concerned that telcos will be evil. Rather, I am concerned that they will be naïve and inept. And that the market overestimates the potential for this model to succeed. Most of all, I'm concerned that we may be distracting ourselves from the central issue: Infrastructure"

Ben lafı uzatmadan özellikle Telekom dünyası ile yakından ilgilenenleri bu müthiş yazı ile başbaşa bırakayım:
http://www.oreillynet.com/pub/a/etel/2007/01/11/the-ims-debate.html

Oracle JDBC Drivers & I-net

Oracle JDBC driver ile yaşanan sorunları birçoğunuz tecrübe etmiş veya duymuşsunuzdur. Her ne kadar Oracle 10g ile birlikte bu hatalar azalsa da hala ciddi sorunlar olabiliyor. Özellikle JIRA gibi platform (Database, Application Server ve Operating System) bağımsız ürünlerin JDBC driver’lardan beklentileri çok daha fazla oluyor.

JIRA dünya üzerinde 2200’den fazla müşteri tarafından kullanılıyor ve müşterilerinin çoğunluğu veritabanı olarak Oracle kullanıyor. Bu yüzden JIRA’cılar Oracle konusunda bayağı tecrübe edinmişler ve bu tecrübelerini dokümanlarına yansıtmışlar. Sonuç olarak Oracle JDBC driver yerine, 3 kat daha hızlı I-net software JDBC driver ‘i tavsiye ediyorlar. Belki lazım olur diye paylaşayım istedim:

WARNING: please make sure you get the 10.1.0.5 version of the driver. Every other version has problems:

• The 9i drivers don't support CLOBs, so are unusable.
• The 10g Release 2 JDBC driver (10.2.0.1.0) hangs with some databases.
• The 10g Release 1 JDBC driver (10.1.0.4) does not hang, but throws ArrayIndexOutOfBoundsExceptions. A second user reports that it silently fails to import workflows in Oracle 9i, and JIRA later dies with a NullPointerException.
• The latest 10.1.0.5 driver allegedly fixes the ArrayIndexOutOfBoundsException, and we have at least one report of it working without problems.

Anecdotally, these problems seem to affect 9i users more than 10g. Thus:

• If you are using Oracle 9i, we recommend you avoid Oracle's drivers altogether, and buy the I-net software JDBC driver, which is known to work without problems. Try the 10g driver at your own risk.
• If you are using Oracle 10g, download the 10.1.0.5 driver from Oracle's site.

Each of the problems listed above has been discovered at great cost to our users, and support cases have sometimes dragged for months. We thus strongly recommend avoiding Oracle if you have any choice in the matter, for the benefit of all concerned.

http://www.atlassian.com/software/jira/docs/v3.7.1/databases/oracle.html

i-net software - JDBC drivers for Oracle Server

i-net software offers a full range of JDBC drivers for Oracle Database Servers. From this product line you can pick the driver that fits your requirements best. All Oracle drivers are type 4 drivers, i.e., the drivers are completely written in Java and can be deployed on every platform.

Why should you choose an Oracle driver from i-net software?

* fast; compared with other drivers i-net drivers are up to 3 times as fast.
* small; The sizes of our drivers are between 90 KB to 200KB. By comparison, Oracle's driver is over 1 MB in size.
* very stable; Find out for yourself about the stability of other vendors' drivers - and compare!
* thread safe; This is a MUST for developers working with multiple threads!
* strictly complies with JDBC; i-net drivers have no extra API, all features were implemented complying with the standard JDBC API, therefore, it is very straightforward to generate an application accessing different DBMS without changing the code! This also makes sure i-net drivers can be easily used in third party tools.

Which driver edition should I use?

• The choice of the right JDBC driver depends on the Java version of your system.
• An overview about available JDBC features can be found in the Feature Matrix.
• If you have any questions please contact our sales team.

http://www.inetsoftware.de/products/jdbc/oracle/

Nokia joins Wimax train

Ağustos 2006'da Sprint Nextel'in öncülüğünde Intel, Motorola ve Samsung bir araya gelerek 4G standardı olarak Wimax'i (IEEE 802.16e) seçmiş ve Wimax konusunda ciddi yatırımlar yapma kararı almışlardı.

Sprint Nextel Announces 4G Wireless Broadband Initiative With Intel, Motorola and Samsung
Working together with Intel, Motorola and Samsung, Sprint Nextel will develop a nationwide network infrastructure as well as mobile WiMAX-enabled chipsets that will support advanced wireless broadband services for computing, portable multimedia, interactive and other consumer electronic devices. These efforts are intended to allow Sprint Nextel customers to experience a nationwide mobile data network that is designed to offer faster speeds, lower cost, and greater convenience and enhanced multimedia quality.

In working together with Intel, Motorola, and Samsung, Sprint Nextel has the experience, network infrastructure, spectrum and distribution channels to make 4G mobility services pervasive and indispensable for customers. The company?s deployment plans target a launch of the advanced wireless broadband services in trial markets by the end of 2007 with plans to deploy a network that reaches as many as 100 million people in 2008. Sprint Nextel plans to expand mobile WiMAX network coverage thereafter.

O zaman bu işbirliği haberi kimseyi şaşırtmamıştı. Çünkü İskandinavya kökenli şirketlerinin liderlik ettiği 2G döneminin GSM standardı tüm dünyada yaygınlaşırken, Amerika kökenli telekom ve teknoloji şirketleri mobil dünyadan istedikleri payı alamamışlardı.

Bu şirketler bu sefer işi sıkı tutup, güçlü bir işbirliği ile Wimax standardı üzerine yoğunlaştılar. 3G mi yoksa 4G mi tartışmasının devam ettiği bugünlerde, bu sefer İskandinav kökenli telekom firmaları hangi teknolojiye yatırım yapacakları konusunda kararsız. Bu firmalardan biri olan Nokia uzun süre 3G ve Wimax arasında kararsız kalmıştı ama nihayet 5 Ocak 2007'de çıkan bir haberle pozisyonlar netleşti :)

Nokia joins Sprint WiMax bandwidth-wagon
Nokia will supply infrastructure and client hardware for the high-speed network, which is designed to far outstrip cellular speeds, Sprint announced Friday. The Finnish mobile giant joins Intel, Samsung Electronics and Motorola as a vendor to Sprint, which plans its WiMax network as a 4G (fourth-generation) system to complement 3G (third generation).

When Sprint chose WiMax last year, it automatically boosted the prospects of the fledgling wireless broadband technology. The addition of Nokia, a dominant cellular supplier outside the U.S., is a boon to Sprint in its mission to foster a large vendor ecosystem around WiMax. Having more equipment providers, especially ones with a global presence, should put more products on the market and increase manufacturing volumes so device prices lower.

Nokia will supply network gear, including its Nokia Flexi WiMax base transceiver stations, and develop and market mobile devices including multimedia computers and Internet tablets, the carrier said. It will also help develop services and applications and foster global adoption of WiMax to make international roaming possible.

Diğer bir GSM lideri Ericsson da aslında geçenlerde artık IP ve genişbanta yatırım yapacağının sinyallerini vermiş ve 20 Aralıkta piyasa değerinin üstünde bir para vererek 1.9 milyar dolara Redback Networks'u satın aldığını duyurmuştu:

Ericsson, Redback'i 2,1 Milyar $'a Satın Aldı
İki şirketin güçlerini birleştirmesi müşteri ve hissederlar açısından önemli bir değer yaratacağı gibi, çalışanlar için de yeni fırsatlar ortaya çıkaracaktır. VOIP, IPTV ve video-on-demand gibi mobil ve sabit genişbant ağlara yönelik sürekli artan talep yeni IP-bazlı servisleri pazara sunmamızı gerektiriyor. Bu tür uygulamalar çok yüksek servis kalitesi istiyorlar ve halihazırda bulunan bantların genişlikliklerinin ve yönetim araçlarının yeterli olmaması bu servislerin verilmesini zorlaştırıyor. Bu ağlarda servis kalitesi yuksek kapasiteli akıllı routerların kullanılması gerekiyor.

Wimax'e öncülük eden şirketler sürekli Wimax'in 3G'ye bir rakip değil, tam aksine tamamlayıcı bir teknoloji olduğunu vurguluyorlar. Ama bu aslında Telekom devlerini ürkütmemek için dile getirilen bir söylem. Lisans bedellerinin, son kullanıcı ve operatör cihazlarının çok yüksek olması nedeniyle hiç kimse aynı amaca hizmet eden 2 teknolojiye birden para yatırmak istemeyecektir. Bakalım 2007 bize başka neler gösterecek.

Ruby ruled in 2006

TIOBE firması her ay arama motorlarını (Google, Yahoo, MSN, vs.) kullanarak programlama dillerinin kullanım oranlarını araştırıyor. Her sene başında da bir önceki yıl ile kıyaslayarak bir rapor hazırlıyor. 2006 yılı sonuçlarına göre Java liderliğini korumuş fakat Ruby en fazla artış göstererek 2006 yılının programlama dili seçilmiş.

TIOBE Programming Community Index for January 2007

Position Jan 2007	Position Jan 2006	Delta in Position	Programming Language	Ratings Jan 2007	Delta Jan 2006	Status
1	1		Java	19.160%	-3.10%	A
2	2		C	15.807%	-3.20%	A
3	3		C++	10.425%	-1.04%	A
4	5		(Visual) Basic	9.123%	+0.03%	A
5	4		PHP	7.943%	-1.46%	A
6	6		Perl	6.237%	-0.81%	A
7	7		C#	3.521%	-0.03%	A
8	8		Python	3.502%	+0.90%	A
9	10		JavaScript	2.845%	+1.31%	A
10	21	11 *	Ruby	2.519%	+2.15%	A
11	11		SAS	2.343%	+1.18%	A
12	9		Delphi	2.336%	+0.75%	A
13	12		PL/SQL	1.570%	+0.54%	A
14	22	8 *	D	1.335%	+0.97%	A-
15	20		ABAP	1.229%	+0.82%	A-
16	14		Lisp/Scheme	0.674%	+0.07%	B
17	18		Ada	0.638%	+0.17%	B
18	13		COBOL	0.637%	-0.13%	B
19	15		Pascal	0.570%	+0.04%	B
20	34	14 *	Transact-SQL	0.510%	+0.34%	B

We are glad to announce that Ruby has become "Programming Language of the Year 2006". Ruby has the highest popularity increase in a year of all programming languages (+2.15%). Runner up this year is JavaScript with +1.31%. Both languages are boosted by their corresponding frameworks, Ruby On Rails and Ajax. This might be a new trend. In the recent past it was necessary to have a large company behind the language to get it in the spotlight (Sun with Java, Microsoft with C#), but nowadays a killer app appears to be sufficient. Viral marketing via the Internet works! The winners of the last 2 years, PHP and Java, are the losers of this year. Other trends that are observed are the growth of dynamically typed languages and the fact that the difference in popularity between languages is getting less.

Category	Ratings Jan 2007	Delta Jan 2006
Object-Oriented Languages	52.3%	+1.4%
Procedural Languages	45.3%	-2.3%
Logical Languages	1.6%	+0.8%
Functional Languages	0.7%	+0.1%

Category	Ratings Jan 2007	Delta Jan 2006
Statically Typed Languages	57.9%	-5.1%
Dynamically Typed Languages	42.1%	+5.1%

Araştırmanın nasıl hazırlandığı ile ilgili detaylara ve daha fazla bilgiye http://www.tiobe.com/tpci.htm adresinden ulaşabilirsiniz.

XA : Needed More Often Than You Think

Java ile uygulama geliştirenleriniz mutlaka transaction, distributed transaction, XA, XA resources, two-phase commit (2PC) terimlerini duymuştur. Bu yazıda, aslında çok ihtiyaç duyulan ama çeşitli nedenlerden kullanılmayan/kullanılamayan XA bağlantısından bahsetmeye ve ayrıca aşağıdaki sorulara da kendimce cevap bulmaya çalışacağım.

# XA bağlantısına hangi durumda ihtiyacımız var?
# XA bağlantısının uygulamaya getirdiği maliyet nedir?
# XA bağlantısı kullanmak istemiyorsak, alternatifi nedir?
# XA kullanımının sistemin genel mimarisine bir etkisi veya mimariden bir beklentisi var mıdır?

Bu sorulara cevap aramadan evvel bahsi çok geçecek bazı kavramların sözlük tanımlarına bir göz atalım.

Transaction : a series of actions performed as a single logical unit of work in which either all of the actions are performed or none of them are (also called a local or simple transaction). A transaction is often described as ACID -- atomic, consistent, isolated, and durable.

Distributed transaction : An ACID transaction between two or more independent transactional resources (for example, two separate databases). For the transaction to commit successfully, all of the individual resources must commit successfully; if any of them are unsuccessful, the transaction must roll back in all of the resources.

XA : which describes the standard protocol that allows coordination, commitment, and recovery between transaction managers and resource managers.

XA Resources : databases, messaging queuing products such as JMS, mainframe applications, ERP packages, or anything else that can be coordinated with the transaction manager.

Two-phase commit : An approach for committing a distributed transaction in two steps: Phase 1, Prepare: Each of the resources votes on whether it's ready to commit -- usually by going ahead and persisting the new data but not yet deleting the old data. Phase 2, Commit: If all of the resources are ready, they all commit -- after which the old data is deleted and the transaction can no longer roll back. Two-phase commit ensures that a distributed transaction can always be committed or always rolled back, even if parts of the system crash while the transaction is being committed. Many, but not all, distributed transaction implementations use two-phase commit.

XA bağlantısına hangi durumda ihtiyacımız var?
Eğer aynı transaction içerisinde birden fazla veritabanında güncelleme (insert/delete/update) yapıyor iseniz ve veritabanları arasında data uyumsuzluğuna (data inconsistency) tahammülünüz yok ise o zaman XA bağlantısına ihtiyacınız var demektir.

Bu durumu çok meşhur basit bir örnekle anlatmaya çalışalım. Elimizde Uygulama Sunucusunda çalışan, EJB kullanarak geliştirdiğimiz bir muhasebe programı olsun. Diyelim ki birinde stok bilgilerini, diğerinde hesapları tuttuğumuz 2 ayrı veritabanımız olsun. (Bakınız Şekil-1) Bir satış yapıldığında bir EJB metodumuz (makeSales()) da önce StockDS'i kullanarak stok'tan ilgili ürünü düşsün ve ardından AccountDS'i kullanarak toplam satış değeri kadar parayı da hesaba aktarsın.

Figure-1. Local Connection Pools. makeSales() = t1 + t2 + t3

Bu örnekte tüm veritabanı bağlantıları hepinizin bildiği Local olarak tanımlanmış durumda. İlk bakışta herşey normalmiş gibi gözüküyor. Peki ya makeSales() metodu içerisinde gerçekleşen transaction StockDS bağlantısını commit() 'ledikten sonra tam AccountDS'e commit() komutunu gönderirken herhangi bir sorundan dolayı (network bağlantı hatası, vs.) hata alıp yarım kalırsa ne olur. Stok'umuz azalır ama hesabımıza para geçmez. Bunun sebebi de distributed transaction kullanmamız gereken bir yapıda local transaction kullanmamızdır. Yani yukarıdaki örnekteki datasource'ların kullandığı connection pool'lar local değil XA olmalıydı.

Bu tip sorunların yaşanma olasılığı düşük de olsa, günlük transaction miktarı yüksek olan sistemlerde veri tutarsızlığı (data inconsistency) çok fazla olacaktır. Hele işin için de bir de para varsa bazen 1 kuruşun bile hesabı sorulabilir.

Bazı developerlar hemen "Bizim uygulamalarımız tek bir veritabanı ile çalışıyor, bizim böyle bir sorunumuz yok" diyebilir. Eğer tek bir datasource kullanıyorsanız dediğiniz doğrudur. Lakin aynı veritabanına bakan farklı connection pool'lar tanımladıysanız ve aynı transaction içerisinde bu pool'ları kullanan datasource'lar var ise yukarıda bahsettiğimiz senaryonun aynısı gerçekleşmiş olur.

XA bağlantısının uygulamaya getirdiği maliyet nedir?

Eğer Uygulama Sunucusunda çalışan uygulamalar geliştiriyorsanız ve XA kullanmaya karar verdiyseniz tek yapmanız gereken datasource'larınızın kullandığı Connection Pool'ları Local'den XA'ye çevirmek. Fakat bu konuda hemen aksiyon almadan evvel aşağıdaki noktalara dikkat etmeniz gerekiyor.

* Öncelikle veritabanınızın XA bağlantısını destekliyor olması gerekiyor. Oracle gibi kurumsal veritabanlarının XA (distributed transaction) desteği mevcuttur. Maalesef open-source veritabanlarının çoğunda XA desteği bulunmaz.

* Uygulama Sunucunuzunda da XA transaction'ları destekliyor olması gerekiyor. Piyasadaki JBoss, Weblogic, WebSphere gibi open-source veya lisanslı bir çok uygulama sunucusunun XA desteği mevcut. Bu konuda veritabanlarına göre daha şanslıyız :)

* Teorikte birçok Uygulama Sunucusu ve Veritabanı XA desteği olduğunu söylese de, pratikte hepsinin XA desteğini başarılı bir şekilde verdiğini söyleyemeyiz. Örneğin Oracle XA konusunda senelerce çok fazla şikayet aldı. Özellikle Oracle'ın 8.x ve 9.x serisi veritabanı ve driver'ı uzun süre meşhur bug'ları ile yaşadı. (Bakınız: Oracle Thin Driver Known Issues and Workarounds) Hatta Oracle 10g çıkıncaya kadar bazı uygulama sunucuları Oracle'a bağlanmak için kendi geliştirdiği driver'larını kullandı. (Bakınız: WebLogic jDriver for Oracle (Deprecated) ) Benzer şekilde her Uygulama Sunucusunun XA desteği çok başarılı değil. Bu yüzden Uygulama Sunucusu seçiminde dikkatli olmak gerekiyor.

* XA bağlantısının performansı, doğal olarak Local bağlantıya göre biraz daha düşüktür. Bunun en büyük nedeni XA transaction'larının local transaction'lara göre sistem kaynaklarını daha fazla ve daha uzun süre meşgul etmesidir. XA bağlantısının veritabanı üzerindeki performans etkisi daha çok veritabınında kullanılan "isolation level" ve "locking" mekanizmaları ile ilgilidir. Bu konuda detaylı bilgiliyi Oracle Gurusu Hasan Tonguç Yılmaz'ın Oracle Concepts and Architecture - Part 1 blogunda bulabilirsiniz.

* XA kullanmak isteyenlerin (özellikle kurumsal şirketler) karşısına çıkan en büyük engellerden biri de Oracle store procedure ve dblink ikilisinin EJB'ler ile birlikte kullanılmasıdır. Bir XA transaction'ı içerisinde dblink kullanılıyorsa ve bu dblink'in bağlandığı veritabanı "shared" modda değilse meşhur "ORA-24777: use of non-migratable database link not allowed" hatası ile karşılaşılır. Günümüzde artık Oracle kurulumlarında daha performanslı olan "dedicated" mod kullanıldığı için bu durum XA ve dblink'in birlikte kullanımı açısından büyük bir sorun teşkil etmektedir.
XA Issues and Restrictions
Database Links : Oracle XA applications can access other Oracle Database instances through database links, with the following restrictions. Use the shared server (formerly known as Multi-Threaded Server) configuration.

Figure-2. XA Connection Pools with dblink. makeSales() = t1 + t2 + t3 + t4

Şekil-2'de bu durumu bir önceki örneğimize ilave yapıp somutlaştırmaya çalıştım. makeSales transaction'ı bu sefer hesaba para yatırdıktan sonra dblink ile Billing veritabanına bağlanıp fatura kesilebilmesi için fatura hareket tablosuna kayıt atmaya çalışıyor. Fakat Billing veritabanı "dedicated" modda olduğu için hata veriyor.

XA bağlantısı kullanmak istemiyorsak, alternatifi nedir?

XA kullanımı ile ilgili bu kadar sıkıntı gördükten sonra haklı olarak bir alternatif arayaşına gidebilirsiniz. Peki XA kullanmadan veritabanları arasındaki data uyumsuzluğunu nasıl önleyeceğiz? Bunun başlıca yöntemlerinden biri düzenli olarak manual veya otomatik veri uyumsuzluğu kontrolü (data integrity check) yapılması. Bunun için aşağıdaki adımlar izlenebilir.

# Muhtemel data uyuşmazlığı oluşabilecek tabloların ve kayıtların önceden tespit edilmesi.
# Data uyuşmazlıklarının nasıl düzeltileceği konusunda prosedürlerinin hazırlanması
# Tespit edilen bu tablolar arasında gün içinde veya gün sonunda manual/otomatik uyumsuzluk kontrolünün yapılması
# Tespit edilen uyuşmazlıkların düzeltilmesi için gerekli manual/otomatik aksiyonların alınması.

XA kullanımının sistemin genel mimarisine bir etkisi veya mimariden bir beklentisi var mıdır?

Yukarıda da bahsettiğimiz gibi XA kullanımına geçiş kararı aslında tamamen sisteminizin mimarisini etkileyecek bir karardır. Özellikle sunum, orta ve veritabanı katmanlarının farklı farklı yazılımcılar tarafından geliştirildiği, SOA tabanlı mimarilerin kullanıldığı sistemlerde XA stratejisi çok daha kritiktir.

XA konusunda Genel Mimari'yi ilgilendirecek konuları aşağıda sıralamaya çalıştım:

# Uygulama Sunucusu tercihi
# Veritabanı tercihi
# Veritabanı Oracle ise kurulum (shared/dedicated) modu ve dblink kullanımı tercihi
# XA olmasına gerek olmayan transaction ve pool'ların tespiti. (Örneğin sadece sorgulama yapan işlemler)
# Altayapıda kullanılan framework tercihi.

XA konusunda aslında daha çok şey söylenebilir. Bu tamamen sizin sisteminizin büyüklüğüne ve karmaşıklığına bağlı. Eğer bu konuda daha detaylı ve teknik bilgiye ulaşmak isterseniz aşağıdaki linklerden faydalanabilirsiniz. Ben çok faydalandım :)

Kaynaklar
XA Transactions
Configuring and using XA distributed transactions in WebSphere Studio
Distributed Transactions and the Transaction Manager
Weblogic JDBC Datasources
Weblogic Distributed Transactions and the Two-Phase Commit Protocol
JBoss OracleXA Tricks
OReilly J2EE Transaction Frameworks