# zdalne wywoływanie metod (ang. Remote Method Invocation),
RMI i EJB (które wykorzystuje RMI), zostało zastąpione WebService’ami i mało kto używa teraz tego inaczej

# wielowątkowość (ang. Threading),
kulała, kuleje, ale już nie długo. Ale po co wątki w enterprise? Wątkowanie się na poziomie serwera raczej używa, nie na poziomie aplikacji.

# współpraca z bazami danych i systemami spadkowymi (ang. Back-end integration),
Było, jest i będzie

# transakcje,
w domyśle rozproszone, na razie brak

# równoważenie obciążenia (ang. Load balancing),
To znowu nie zależy od technologi a od konfiguracji serwerów, było jest i będzie dla php, rails, javy i czego kto sobie zażyczy

# płynne przejmowanie zadań od komponentów, które uległy awarii (ang. Transparent failover),
W rails na poziomie konfiguracji serwerów (ale w Javie wspomagane przez serwer aplikacyjny), przy architekturze rails zasadzie nie potrzebne.

# czy stan serwera, który uległ awarii jest replikowany na inne serwery (ang. Clustering),
servery bez stanowe, nie dotyczy

# uaktualnienia działającego systemu (ang. Dynamic redeployment),
Przyszło do railsów niedawno wraz z Serverem Unicorn

# prowadzenie dziennika i audyt (ang. Logging and auditing),
Trzeba używać zewnętrznego oprogramowanie (np New Relic RPM, hoptoad, etc)

# monitorowanie i administrowanie działającym systemem (ang. System management),
Zewnętrzne narzędzia again

# luźne sprzężenie przy pomocy komunikatów (ang. Message-oriented middleware),
Można używać np RabitMQ

# tworzenie/niszczenie komponentów w zależności od obciążenia (ang. Component life cycle),
Niestety, nie ma i nie widać kompnentów, ale znowu, czy nie od tego jest architektura Webservice’ów aby zapomnieć o komponentach?

# pule zasobów (ang. Resource pooling),
są

# kontrola bezpieczeństwa na poziomie operacji (ang. Security),
nie ma i raczej nie będzie

# pamięć podręczna (and. Caching),
jest

W sumie:
trochę wcześnie, żeby Banki atakować, ale jak ktoś by się uparł to by się dało