TROIA neden "client-server" değil, "application server merkezli" bir platform

Klasik bir web uygulamasında mantık genelde sunucu ile istemci arasında bölünür — bazı doğrulamalar tarayıcıda JavaScript ile, asıl iş mantığı sunucuda çalışır. TROIA'da bu ayrım yok: TROIA kodu yalnızca application server üzerinde çalışır. Masaüstü (Java/Swing), web ve web servis istemcilerinin hiçbiri tek satır TROIA kodu yürütmez; yaptıkları tek şey kullanıcı etkileşimini sunucuya iletmek ve dönen sonucu ekrana basmaktır. Bu, CANIAS ile ilk çalışan .NET/Java geliştiricilerin en çok kafa karıştıran noktası: "bu buton tıklanınca hangi katmanda kod çalışıyor?" sorusunun cevabı her zaman aynı — application server.

Beş bileşen ve her birinin gerçek görevi

  • Application Server: TROIA kodunu çalıştırabilen tek bileşen. Kullanıcı oturumlarını, uygulama yaşam döngüsünü ve veritabanı transaction'larını yönetir. Bir CANIAS ortamında "sunucu" dendiğinde genelde bu kastedilir.
  • İstemciler: Masaüstü, web ve web servis istemcileri kod çalıştırmaz; sadece etkileşimi taşır. Bu yüzden bir dialog'da performans sorunu yaşıyorsanız suçlu neredeyse hiçbir zaman istemci tarafı değildir — application server'daki kod ya da veritabanı sorgusudur.
  • License Server: Kullanıcı sayısına ve modüllere göre lisanslama yapar. Erişilemezse application server kullanıcı girişine izin vermez — yani license server'ın çökmesi, koddan bağımsız olarak tüm sistemi login ekranında kilitler.
  • RMI Registry: Platformun tüm bileşenleri arasındaki iletişim altyapısı, Java RMI protokolü üzerinden çalışır. Varsayılan port 1099'un tüm bileşenlerden erişilebilir olması gerekir; bu port bir güvenlik duvarı arkasında kapalı kalırsa istemciler sunucuya "bağlanıyor gibi görünüp" hiçbir işlem yapamaz — klasik bir "arayüz açılıyor ama hiçbir ekran yüklenmiyor" belirtisi verir.
  • Destek bileşenleri: Yük dengeleyiciler, SSO gateway'leri, SMS/IoT gateway'leri, Workbench (yönetim aracı) ve System Reporter.

Veri neden şu sırayla akar

İletişim akışı özetle şöyle işler: veritabanı → application server → RMI registry → istemciler (masaüstü/web). Bu sıralamayı bilmek, canlı ortamda bir sorunu teşhis ederken işe yarar — örneğin kullanıcılar "sisteme giremiyoruz" diyorsa, önce veritabanı bağlantısını, sonra application server'ın ayakta olup olmadığını, en son RMI registry/network erişimini kontrol edersiniz; bu sıra genelde en hızlı kök nedene ulaştıran yoldur.

Platform bağımsızlığı gerçekte ne kazandırıyor

TROIA uygulamaları Windows, Linux, Unix üzerinde ve farklı tarayıcılarda değişiklik gerektirmeden çalışabiliyor; veritabanı tarafında da MSSQL, MySQL, PostgreSQL, Oracle, DB2 gibi seçenekler destekleniyor. Pratikte bunun asıl değeri şurada: bir müşteri projesinde veritabanı motoru değişse (örneğin Oracle'dan MSSQL'e geçilse) bile TROIA kodunun büyük kısmı aynı kalır — SQL'e özgü fonksiyonlar kullanılmadığı sürece. 43DatabaseAccessI yazısında bahsedeceğim "database-specific syntax functions" tam olarak bu noktada devreye giriyor; onlardan kaçınmak taşınabilirliği doğrudan etkiliyor.

Cross mekanizması: neden recompile'a gerek kalmıyor

Platform, nesnelerin oluşturulduğu noktayı değiştirmeden davranışı özelleştirmeyi sağlayan bir "Cross" özelliği sunuyor. Bu, ERP projelerinde standart bir modülü (örneğin sipariş işleme transaction'ını) müşteriye özel ihtiyaçlar için "override" etmenin yolu — kaynak kodu kopyalamadan, orijinal transaction'ın davranışını bir üst katmanda değiştirebiliyorsunuz. 55InheritanceCross yazısında bu mekanizmayı örnekle ele alacağım.

Konfigürasyon tarafında dikkat edilmesi gerekenler

  • Veritabanı sunucularının application server'lardan erişilebilir olması gerekir.
  • RMI registry portu (varsayılan 1099) tüm bileşenlerden erişilebilir olmalı.
  • Web istemcileri ve JNLP dosyaları için web sunucusu olarak Apache Tomcat 9.x kullanılır.
  • Java 1.8, Java 21 ve OpenJDK 11 desteklenir — bir yükseltme projesinde önce hedef Java sürümünün mevcut TROIA build'iyle uyumlu olup olmadığını kontrol etmek, sonradan çıkabilecek en can sıkıcı sürprizlerden birini baştan önler.

Pratik not: "hangi build'de çalışıyoruz" sorusu

Platformun büyük sürümleri 2006'daki 3.08'den 2023'teki 9.03'e kadar uzanıyor ve uyumluluk ReleaseNotes.txt üzerinden takip ediliyor. Bir hata raporu aldığınızda ilk sorulması gereken sorulardan biri her zaman "hangi build'de görüldü" olmalı — TROIA'nın 4GL doğası nedeniyle bazı davranış farklılıkları (özellikle tarih/saat ve string fonksiyonlarında) build'ler arası değişebiliyor, ve bu notu atlamak teşhis sürecini gereksiz uzatıyor.