|
|
 Posted - 05/15/2014 : 08:58:59
|
Sono a conoscenza di una applicazione abbastanza importante e diretta a centinaia di migliaia di utenti che è sostanzialmente basata su due antipattern racchiudibili in una osservazione.
E' una web application costituita da un unico Ear,
ne consegue che:
1) non c'è una distinzione fisica tra web farm e server farm, conseguentemente potenzialmente apre grosse falle di sicurezza, ma quali effettivamente e che non possano essere arginate diversamente?
2) Un unico EAR quindi all'interno session bean e entity bean che lavorano tutti con l'interfaccia locale, anche qui, completamente fuori dai pattern tradizionali, ma in realtà la problematica della scalibilità può essere indirizzata clusterizzando quell'unico EAR.
In definitiva la domanda è, reggerà alla carica dei 100.000 utenti?
|
 CapoStecca 2008 & 2010 & Mutanda 2014 |
Country:  Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
|
iksyos
Starting Member
Status:
offline
| |
Posted - 05/15/2014 : 12:19:49
|
Ciao a tutti questo è il mio primo post in assoluto su questo forum e spero che dia un buon contributo alla discussione.
Inizio immediatamente con il punto 1. In realtà io non vedo un vero problema di sicurezza nella mancata separazione fisica tra web e server farm ma vedo un serio problema di scalabilità. Il mio parere è che le necessità di backend (dove vedrei solo gli EJB) e frontend (dove vedrei la sola GUI) non sono compatibili per quanto riguarda la scalabilità. Questo è il motivo principale per cui farei la divisione secondo me anche senza divisione il sistema può avere un buon grado di sicurezza.
Per quanto riguarda il punto 2 sono più preoccupato, l'uso delle interfacce locali è una palla al piede se successivamente si vuole cambiare la distribuzione del software. Basare la scalabilità solo sul fatto di potenziare il clustering è un limite ed è anti-economico.
Allo stato attuale io alla domanda "reggerà 100.000 utenti?" rispondo:
dipende da quanti soldi sono disposti a spendere  .
|
|
Country: Italy ~
Posts: 3 ~
Member Since: 05/15/2014 ~
Last Visit: 05/23/2014
|
Alert Moderator
|
|
|
|
|
Posted - 05/15/2014 : 12:51:32
|
Ciao iksyos e benvenuto,
sul punto 1) riflettendoci la problematica che vedo è quella che la macchina di web farm è aperta a tutti sul web (.. e naturalmente anche agli hacker della concorrenza) pertanto se la si separa dalla macchina di serverFarm che ha accesso hai dati si ha la possibilità di inserire tra le due un firewall che consente il traffico soltanto dalla macchina di webFarm e soltanto tramite gli ejb.
Per quanto riguarda la scalabilità di webFarm a tuo parere i carichi sono diversi? Ovvero Apache per quel che ricordo riesce a gestire grandi moli di connessioni, il dubbio riguarda il war (JSF), qui sinceramente non sò se può rappresentare un collo di bottiglia su un server come JBoss 5.
E' il primo progetto di Entity in cui incappo ed in effetti mi incuriosisce, il pattern è SessionBean stateless che richiama l'Entity, entrambi possono essere inseriti in un pool, quindi forse effettivamente dipende soltanto dalla capacità di JBoss di gestire grossi numeri.
Sono più aperto invece sul discorso delle interfacce locali, e se fosse un gran vantaggio tagliare fuori inutili lente connessioni tramite interfacce remote? |
CapoStecca 2008 & 2010 & Mutanda 2014 |
|
Country: Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
|
|
Posted - 05/15/2014 : 13:13:26
|
| quote: Sono a conoscenza di una applicazione abbastanza importante e diretta a centinaia di migliaia di utenti che è sostanzialmente basata su due antipattern racchiudibili in una osservazione. E' una web application costituita da un unico Ear, ne consegue che: 1) non c'è una distinzione fisica tra web farm e server farm, conseguentemente potenzialmente apre grosse falle di sicurezza, ma quali effettivamente e che non possano essere arginate diversamente? 2) Un unico EAR quindi all'interno session bean e entity bean che lavorano tutti con l'interfaccia locale, anche qui, completamente fuori dai pattern tradizionali, ma in realtà la problematica della scalibilità può essere indirizzata clusterizzando quell'unico EAR. In definitiva la domanda è, reggerà alla carica dei 100.000 utenti? Originally posted by etantonio - 05/15/2014 : 08:58:59
poni la questione per garantire i 100.000 utenti di questo sito? |
basta con Pioppi, voglio le onde! |
CapoStecca 2011 & 2013 & ViceCepoStecca 2014 & Mutanda 2012 |
|
Country: Italy ~
Posts: 1031 ~
Member Since: 09/08/2010 ~
Last Visit: 02/15/2024
|
Alert Moderator
|
|
|
|
|
Posted - 05/15/2014 : 13:54:31
|
Si francis,
ho ricevuto per il sito una proposta di gemellaggio con Facebook,
sono un pò titubante, non vorrei che ci sputt...aniamo |
CapoStecca 2008 & 2010 & Mutanda 2014 |
|
Country: Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
|
|
Posted - 05/15/2014 : 14:32:34
|
|
|
|
|
Posted - 05/18/2014 : 09:39:29
|
Sicuramente vedo i problemi di scalabilità, ma solo economici rispetto a scelte sbagliate. Se il backend dovesse richiedere molto lavoro rispetto al front devi uppare tutto ... specie se consideri che generalmente le macchine dedicate hanno specialità differenti.
Interfacce locali o remote non cambia poi molto... gli application server possono essere settati in modo da ridurre al minimo la differenza fra remoto e locale con opportuni caching.
Ancora coi 2.1 .. ma non sarà quello i problema principale?
|
----------------------
Tutto ciò che avete da fare è tenervi il vento alle spalle.
J. Conrad
----------------------
|
ViceCapoStecca 2009 & Panettone Oro 2009 & Panettone Oro Edizione Special |
Country:  Australia ~
Posts: 1583 ~
Member Since: 03/30/2006 ~
Last Visit: 10/17/2019
|
Alert Moderator
|
|
|
|
|
Posted - 05/18/2014 : 11:13:24
|
Qui Corrado apri un mio grosso dubbio,
in questo progetto ci son anche cose che partono da zero e quindi le stò facendo con ejb 3, li ho studiati un pò e sono giunto alla seguente osservazione che spero smentirete:
Tra Ejb 2.1 e 3 cambia soltanto la carrozzeria, il motore è esattamente lo stesso, in pratica per i session, MDB e Entity cambia soltanto che puoi definirli tramite annotazioni e che magari l'application server in alcuni casi da queste annotazioni deduce qualcosa che te invece con i 2.1 dovresti specificargli nel file di configurazione.
Credo che per un progetto già codificato non ha molto senso migrare ad ejb 3, il loro unico scopo credo sia semplificare la scrittura del codice, ma se il codice è già scritto ...
Per quanto riguarda la distinzione web farm/server farm, bhe, sono all'antica, una macchina che ha accesso diretto ad un db con dati sensibili non la metterei direttamente accessibile da internet. |
CapoStecca 2008 & 2010 & Mutanda 2014 |
|
Country: Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
|
|
Posted - 05/19/2014 : 08:27:32
|
Il fatto che gli ejb 3 non debbano portarsi per forza appresso tutto, come invece fanno i 2.1 lascia molto spazio all'ottimizzazione... Sono molto più snelli, il che lascia ampi spazi agli appServer di ottimizzare.
Poi, sempre, è come li progetti, scrivi e deploy che fa la differenza.
|
----------------------
Tutto ciò che avete da fare è tenervi il vento alle spalle.
J. Conrad
----------------------
|
ViceCapoStecca 2009 & Panettone Oro 2009 & Panettone Oro Edizione Special |
|
Country: Australia ~
Posts: 1583 ~
Member Since: 03/30/2006 ~
Last Visit: 10/17/2019
|
Alert Moderator
|
|
|
|
iksyos
Starting Member
Status:
offline
| |
Posted - 05/21/2014 : 14:18:48
|
Tornando alla separazione tra web e server farm io non la vedo una falla seria di sicurezza. Io parto dal presupposto che, solo dal punto di vista della sicurezza, un'architettura fisica ad un livello è più sicura di una multilivello in quanto fa meno transizioni sulla rete. Entrando solo nel merito del firewall basterebbe tenere aperta solo la porta per HTTP agli utenti esterni.
Per quanto riguarda la scalabilità avere la parte web e la parte business separate avrebbe permesso di implementare logiche che permettessero di sfruttare al meglio le architetture multiprocessore. Mi spiego megli. Nell'architettura attuale da te esposta quando arriva una richiesta web questa viene elaborata da un thread che si occupa della fase di unmarshalling dei parametri, dell'elaborazione della logica business e infine del marshalling dei risultati. Se l'elaborazione business diventa lunga hai molti thread che vanno in round robin. Separando la parte business avresti la possibilità di separare il carico su due macchine in modo da avere più thread su macchine diverse che fanno poca roba e limitano il round robin.
Sulla differenza tra interfacce locali e interfacce remote mi trovo d'accordo con corradino. Mi pare di ricordare che molti application server gestiscano in automatico il rebinding da interfaccia remota a locale se si accorgono che le applicazioni stanno deployate sulla stessa macchina. |
|
Country: Italy ~
Posts: 3 ~
Member Since: 05/15/2014 ~
Last Visit: 05/23/2014
|
Alert Moderator
|
|
|
|
|
Posted - 05/22/2014 : 22:55:35
|
Bhe, almeno stò sfatando nella mia mente l'approccio distribuito come unica strategia di deploy ..
http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patterns
sinceramente non sò che tipologie di falle può sfruttare un hacker, ossia se basta solo consentire l'accesso http visto che su http passa di tutto, compresi i file, buoni o cattivi, può un file del genere attivarsi da solo, ricavarsi una connessione e trasmettere le informazioni fuori?
Bha, vabbhe, comunque in realtà forse per questa applicazione non è difficile separare il war dai jar di business logic, mi preoccupano solo un pò i 950 ejb presenti nell'unico Ear.
Confermato, Jboss ottimizza le chiamate remote che sono sulla stessa macchina, mi auguro solo che l'ottimizzazione sia banale e non onerosa come nel caso della reflection.
Insomma forse conviene aver chiaro a priori il piano di deployment e impostare le chiamate conseguentemente. |
CapoStecca 2008 & 2010 & Mutanda 2014 |
|
Country: Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
|
iksyos
Starting Member
Status:
offline
| |
Posted - 05/23/2014 : 09:24:38
|
| quote: Bhe, almeno stò sfatando nella mia mente l'approccio distribuito come unica strategia di deploy .. http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patternssinceramente non sò che tipologie di falle può sfruttare un hacker, ossia se basta solo consentire l'accesso http visto che su http passa di tutto, compresi i file, buoni o cattivi, può un file del genere attivarsi da solo, ricavarsi una connessione e trasmettere le informazioni fuori? Bha, vabbhe, comunque in realtà forse per questa applicazione non è difficile separare il war dai jar di business logic, mi preoccupano solo un pò i 950 ejb presenti nell'unico Ear. Confermato, Jboss ottimizza le chiamate remote che sono sulla stessa macchina, mi auguro solo che l'ottimizzazione sia banale e non onerosa come nel caso della reflection. Insomma forse conviene aver chiaro a priori il piano di deployment e impostare le chiamate conseguentemente. Originally posted by etantonio - 05/22/2014 : 22:55:35
Interessante il link che hai postato. Per quanto riguarda le problematiche di sicurezza la guida OWASP è preziosissima
https://www.owasp.org/index.php/Category:OWASP_Guide_Project |
|
Country: Italy ~
Posts: 3 ~
Member Since: 05/15/2014 ~
Last Visit: 05/23/2014
|
Alert Moderator
|
|
|
|
|
Posted - 06/09/2014 : 20:10:30
|
| L'application Server si è freezato con un carico ben inferiore alle attese ed in assenza di alcuna contromisura rispetto alla architettura originaria, ma non ho altre informazioni per arricchire l'analisi, alla luce dei discorsi qui fatti sarebbe stato almeno auspicabile avere un application server per la parte web ed uno per la business logic. |
CapoStecca 2008 & 2010 & Mutanda 2014 |
|
Country: Italy ~
Posts: 8976 ~
Member Since: 10/21/2005 ~
Last Visit: 03/28/2024
|
Alert Moderator
|
|
|
Antipattern ma reggerà?
