Newsgroup: it.comp.java
Titolo: Esistono gestionali in Java?

Salve,
Questa domanda nasce dai dubbi relativi al funzionamento di Java sulle 
macchine IBM Power, credo sopratutto anche a causa del mostruoso WebSphere 
(ma qui credo andremmo un tantino OT :-P).
Quindi vi chiedo: Esistono sul mercato italiano ERP/MERP o similari scritti 
in Java con ovviamente architettura client-server che siano effettivamente 
venduti ed utilizzati in produzione?
Le prestazioni, l'affidabilit� ecc. come sono rispetto all'RPG?
Perch� la totalit� delle aziende che abbiamo sentito (intendo anche le pi� 
grandi, che comunque fanno anche sviluppo su Java) recitano tutte lo stesso 
leitmotiv: Java non funziona e non funzioner� mai in ambito gestionale, e 
comunque servono dei supercomputer per farlo funzionare (mi rendo conto che 
detto cos� sembri una trollata, ma � la sintesi dell'opinione diffusa).
La Vostra.
-- 
XBOX/PSN Tag: SydneyBlue120d
http://www.gamingcafe.it/forum/
http://www.bmwserie1virtualclub.it/
BMW E87 120d Attiva driver 

 venduti ed utilizzati in produzione?
Non ï¿œ il mio campo...ma comunque ne esistono. Ad esempio:
http://opencompiere.sourceforge.net/products.htm
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org
http://verona.javaday.it

Non sono aggiornato, ma sono certo che il primo, almeno a livello di
annuncio
è stato Movex di Intentia..
era circa... nel ' 98/99
Andrea

 BMW E87 120d Attiva driver
Per che ambiente ti serve ? Che hardware hai ?

Per che ambiente ti serve ? Che hardware hai ?
Era una domanda pi� accademica che altro, per capire meglio come inquadrare 
il linguaggio.
-- 
XBOX/PSN Tag: SydneyBlue120d
http://www.gamingcafe.it/forum/


 ha scritto nel messaggio 
news:7k8j1hF...@mid.individual.net...


 servono dei supercomputer per farlo funzionare
Ma che stupidata...


in RPG si possono fare sia applicazioni client/server
sia programmi cgi e quindi applicazioni web, che poi
sempre di client/server si tratta

 Ormai � tutto web.
Anche IBM ha fatto questa scelta, dimenticandosi per� del dataentry massivo 
che senza l'uso della tastiera risulta enormemente pi� lento rispetto 
all'applicazione standalone (sia essa Silverlight, 5250, Flex ecc.)


 far girare in emulazione terminale? Che c'entra il client-server?
In effetti forse mi sono spiegato male, intendevo comunque applicazioni 
standalone, in ogni caso ERP completo


 ha scritto nel messaggio 
news:7kei0lF...@mid.individual.net...


 ha scritto nel messaggio 
news:hbrvv9$oo8$1...@tdi.cu.mi.it...

NoNo mi sa che confondi 

 ha scritto nel messaggio 
news:vRoEm.15024$813....@tornado.fastwebnet.it...

cosa confonde?
che con l'RPG si possono fare programmi cgi?
che il web � client/server?
cosa?

 Non capisco?
Lavorando via browser hai le limitazioni nell'uso da tastiera che rendono 
molto pi� lente il data entry massivo (es. le classiche registrazioni di 
contabilit�, o qualunque altra cosa in effetti), mentre ovviamente se si 
lavora con applicazioni separate non legate al browser non c'� il problema.


 Le prestazioni, l'affidabilità ecc. come sono rispetto all'RPG?
Ovviamente non sono paragonabili... ma è come confrontare mele con
carciofi :)

 detto cosï¿œ sembri una trollata, ma ï¿œ la sintesi dell'opinione diffusa).
che java non funzioni in ambito gestionale sarï¿œ anche un leitmotiv, 
fatto sta che proprio in questo ambito java non solo ï¿œ diffusissimo ma 
pure con soddisfazione.
se poi parliamo di erp allora no, java dice la sua con alcuni prodotti 
ma non ï¿œ assolutamente il suo piatto forte. perï¿œ ï¿œ anche vero che giusto 
nelle grandi realtï¿œ industriali (che in italia non sono certo la 
maggioranza) si sente parlare ancora di erp mentre per la pmi ï¿œ un 
concetto che per loro fortuna ï¿œ stato superato ancor prima di 
attecchire. da questo punto di vista java scende in campo per quella che 
ï¿œ l'evoluzione successiva all'erp monolitico nell'ambito gestionale: 
integrazione, architetture service oriented, bpel, esb, eccetera.
quanto al discorso dei "supercomputer"... vabbeh, oggigiorno l'hardware 
si virtualizza perchï¿œ altrimenti non si sfrutta, figuriamoci se ï¿œ questo 
il problema :-)

carciofi :)
Beh, dato che ad es. nel caso di ACG sostituiscono proprio tale prodotto a 
me sembra siano da confrontare eccome :)
Grazie


 problema :-)
Infatti ï¿œ quel che penso anch'io. Certo, WS ï¿œ un discreto mostro...


 che il web � client/server?
L'ultima che hai detto.... 

 L'ultima che hai detto....
Il web non � client server? E perch� mai? 

 Il web non � client server? E perch� mai? 
Non � client-middleware-server? :)

 ha scritto nel messaggio 
news:hc3qaq$hfn$1...@tdi.cu.mi.it...


 Cosa installi sul Browser?????
Veramente � il browser stesso ad essere il client del sistema Web, che � 
evidentemente un sistema client/server.


 Cosa installi sul Browser?????
Un bel niente, visto che � un client HTTP.

 ha scritto nel messaggio 
news:4ae7dfa3$0$1111$4faf...@reader1.news.tin.it...


 
www.jugpadova.it
 
http://www.jugevents.org
E sei pure del JUG!!!
Ai tempi miei la selezione era + dura....
 

 
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherA�ejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers v�o � merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

 tutti i client, nel web no...
Perch� il Web ha un client generico, che � appunto il Browser Web (o 
client HTTP, se vogliamo chiamarlo con il suo nome).
Quindi in un applicazione Web si scrive soprattutto il codice che 
specializza il server, mentre il client rimane pressoch� invariato.
Perci� il Web � client/server, con client (e normalmente anche server, 
ma customizzabili) generici. Se non ne sei ancora convinto � meglio che 
studi un qualunque testo di informatica di base.
Il fatto che nel web non si debba installare il client � perch� di 
solito � gi� installato (chi non ha un browser Web gi� installato?). Il 
fatto che non lo si debba aggiornare ad ogni rilascio dell'applicazione 
dipende dal fatto che il protocollo HTTP,usato per la conversazione fra 
client Web e server Web, non cambia.
Ciao
   Lucio


 Ai tempi miei la selezione era + dura....
Giusto per capire, di che tempi stiamo parlano? Hai mai partecipato ad 
un JUG?
Evidentemente ai tuoi tempi non c'era nessuna selezione, se ti � rimasta 
questa confusione sul client/server.
Ciao
   Lucio
-- 


 evidentemente un sistema client/server.
proprio evidentemente direi di no :-)
chi esegue la logica di business è il middleware (in tutto o in parte) 
quindi il browser è come minimo un altro livello rispetto a quello.

 Un bel niente, visto che è un client HTTP.
certo. ma non di un client-server ma di un client-middleware-server.

 quindi il browser è come minimo un altro livello rispetto a quello.
http://it.wikipedia.org/wiki/Architettura_three-tier

rootkit ha scritto:

Veramente no. Se proprio vogliamo entrare nel dettaglio 
dell'architettura di un applicazione Web (che come sistema complessivo è 
  client/server), il browser Web ed il server Web giocano proprio il 
ruolo di middleware, cioè di quello strato software che viene usato per 
comunicare dall'applicazione Web, intesa come intefaccia utente presente 
nella pagina visualizzata dal browser e codice specifico 
dell'applicazione che risiede all'interno del server.
Ciao
   Lucio




mi quoti per conferma? :-)

Il Thu, 29 Oct 2009 10:09:34 +0100, Lucio Benfante ha scritto:
[...]
scusate se sono intervenuto con un altro nick (pino) ma è un profilo che 
aveva configurato su pan un altro utente e che non avevo cancellato...

 architettura con più di due livelli.
Veramente non di stava parlando di architetture a livelli, ma di 
client/server. Un sistema potrebbe essere strutturato a livelli, anche 
senza essere necessariamente client/server.
Per chiarire la faccenda del middleware. La presenza di un middleware 
non cambia la natura del sistema: semplicemente si affida al middleware 
alcune responsabilità. Nel caso delle applicazioni Web si affida al 
middleware (Web client e server) la responsabilità della comunicazione HHTP.
Fra l'altro niente vieta di costruirsi il proprio client (cosa che si fa 
in continuazione se si sviluppano Web Service).



No!
I terminali a fosfori verdi di IBM hanno un
polling contunuo (sincrono) con il server e
pertanto non rientrano nella categoria client/server
mentre l'architettura client/server invece prevede che
il client inoltri richieste al server e il server risponda,
ma il tutto in modo asincrono,
Il browser rientra perfettamente nella categoria
client/server poich� chiede una pagina web, per esempio
un form da compilare e mentre si compila il form
il non c'� pi� alcun collegamento con il server,
collegamento che viene ristabilito solo quando si
esegue il submit della form.

 Io s�, molte, tu? :)
Mi ci pago il mutuo e  da mangiare a tutta la mia famiglia
Lucio, il cliente/server non � un opinione, il termine nasce a fine anni 80 
ed ha avuto una sua evoluzione per essere superato di fatto dalla 
applicazioni web based. Sono stati gli anni d'oro dei sistemi unix con motif 
che si interacciavano a server oracle, SyBase, winzoz con visual basic, C++, 
sqlform ...ne hanno inventato d'ogni. Allora c'era la moda di migrare da 
mainframe a clientserver.
Anche il client-server mi ha dato da mangiare per parecchio tempo.
Io ho non sono esattamente di primo pelo � questa storia l'ho vissuta e so 
esattamente che riflessi aveva sulla gestione dei progetti e sulla 
manutenzione dei sistemi non solo quindi come paradigma di programmazione.
Con l'avvento del web tutti sono passati al web che in un certo senso � la 
"vendetta del mainframe" cucinato in altra salsa, non a caso le banche sono 
state le prime ad aderire.
Poi se vogliamo spaccare il capello in quattro in ogni applicazione c'e una 
parte server ed una client ma quando ad un responsabile IT gli parli di 
client/server � a quello che ti ho raccontato che fa riferimento e che 
capisce.
Ciao 

 Lucio, il cliente/server non � un opinione
esatto.
Non si pu� negare che il Web abbia un'architettura client/server, solo 
perch� esistono altre applicazioni che usano tale paradigma in maniera 
diversa.
Tu dici che ad un responsabile IT se dico client/server capisce una 
cosa, e se dico Web ne capisce un altra? Ovvio, ma appunto qui non 
stiamo parlando di comunicazione, stiamo parlando di architetture e 
paradigmi software.
Quanto alla "vendetta del mainframe", forse, per certe applicazioni. Ma 
secondo te quanto a funzionalit� e meccanismi di interazione, un browser 
� simile alla maggior parte dei terminali di un mainframe? E 
l'architettura di un'applicazione Web ti pare paragonabile a quella di 
un'applicazione da mainframe? Certo, ci sono delle possibili analogie, 
ma non oltre a ci�. Poi di opinioni, appunto, di analogie, e di 
espressioni ad effetto, si pu� discutere all'infinito.
Ciao
   Lucio
PS: vantare anzianit� in una discussione non conta..."questa storia l'ho 
vissuta"...beh, s�, anch'io, e allora?


 quindi il browser è come minimo un altro livello rispetto a quello.
Non mi torna: la logica di business risiede sul browser (generalmente 
sottoforma di Javascript) e ovviamente sul server.
Da un punto di vista software, l'architettura client/server è pienamente 
rispettata.

Il 03/11/09 21.56, cicap ha scritto:

e la persistenza dei dati?


Allora tecnicamente sarebbe un three tier, ma dipende da quale lente di 
ingrandimento vogliamo utilizzare.
Tendo a non considerare la persistenza come un ulteriore sottosistema 
dell'applicazione (se non in casi particolari), altrimenti l'unico 
applicativo client/server puro è un processo batch che si attacca ad un 
database.
E d'altra parte la componente di persitenza non è neppure obbligatoria 
in un'applicazione web, non per definizione almeno.
Quindi se la consideriamo un dettaglio (importante) se ne ricava che un' 
applicazione web è in generale di tipo client/server.

 mainframe?
Chiaramente mainframe e web sono diversi ma fatti raccontare da qualche 
cobolista come funziona un CICS (TP monitor transazionale di IBM)
Di fatto vedrai che ha le stesse funzionalit� di un application server java 
e che le schermate verdi avevano un logica di gestione alle form struts/HTML 
(che infatti in banca chiamano "maschere" come erano chiamate le schermate 
verdi IBM). Stessa logica sincrono domanda/risposta...
Chiaramente con ajax, il dom, javascript  le cose sono cambiate anche se qui 
si potrebbe parlare del "il cliente server colpisce ancora".
Stessi casini, + versioni di javascript, browser non compatibili, plugin da 
installare (per flash ad esempio) ma questo � il prezzo da pagare per 
usabilit� e performance. 

 in un'applicazione web, non per definizione almeno. 
certo come non lo è obbligatorio per nessun programma. infatti, anche 
nella definizione tradizionale un programma che gira sul client e non fa 
accesso a nessun db remoto non è detto client-server, se lo fa invece si.

 
https://jcompany.dev.java.net
http://www.compiere.com
http://opencompiere.sourceforge.net/products.htm
http://www.openbravo.com
http://www.ebineutrino.org
http://www.daobox.net
http://www.jazzgestionale.it
http://www.notasoftware.com
http://java-source.net/open-source/erp-crm
per le fatture c'ï¿œ:
http://www.invoicex.it