Sun e IBM verso uno standard per i portali

I due colossi uniscono le forze per sviluppare un nuovo standard Java che porti interoperabilità fra prodotti di marche differenti nel settore dei portali

Roma - Durante la conferenza JavaOne che si terrà la prossima settimana, Sun e IBM annunceranno un piano comune per sviluppare una serie di specifiche standard intese a rendere la costruzione dei portali più semplice e veloce.

Le specifiche, denominate Java Specification Request (JSR) 168, avranno l'obiettivo di standardizzare il modo in cui dati, informazioni, applicazioni vengono aggregati all'interno di un portale, occupandosi anche di gestire le localizzazioni e la personalizzazione dei contenuti, nonché la sicurezza.

Alla base dello standard vi sono dei componenti detti "portlets" che, similmente ai "servlets", sono applicazioni Java specificamente progettate per essere assemblate fra loro all'interno di un sito Web.
Lo standard, secondo Sun, renderà più semplice per i clienti combinare fra loro i prodotti di vendor differenti che supportano JSR 168: ad esempio, gli sviluppatori saranno in grado di prendere un file Java Server Pages (JSP) creato con IBM WebSphere e renderlo disponibile attraverso il server di BEA.

Sun e IBM sperano che lo Java Community Process (JCP) approvi le specifiche entro la fine dell'anno, in modo che esse possano poi essere integrate nei primi prodotti commerciali a partire dalla prima metà del 2003.
TAG: sw
9 Commenti alla Notizia Sun e IBM verso uno standard per i portali
Ordina
  • più la pubblicita di ibm su punto-informatico.
    oltre a dar fastidio con quel colorito verde (verde come le tasche di chi ha compra i loro prodotti)ma quello che fa girare ancora di più le gonadi e la promessa di maggior sicurezza specifichiamo please, sicurezza dagli hacheronzoli (ma se non erro i db dovrebbe per loro stessa natura stare dietro una DMZ quindi fuori da qualunque attacco poi c'è sempre il pir.. che lo istalla sul server web ma questi sono casi pietosi) oppure sicurezza nel non perdere i dati peccato che lavoro in un ced dove sfortunatamente sta ca.... viene usata e le notti che ho passato per ripristinare dati persi le metterei tutte in conto alla IBlemme.

    scalabilità ma avete mai visto un database db2 scalare e poi cosa il monte bianco.
    non+autenticato

  • dato che produrranno portali-fotocopia di qualità superiore
    non+autenticato
  • > dato che produrranno portali-fotocopia di
    > qualità superiore

    Sarebbe pure l'ora delle fotocopie a colori no?Sorride
    non+autenticato
  • La vita dello sviluppatore sta diventando un incubo: escono fuori continuamente nuove tecnologie, protocolli, ecc. che dovrebbero migliorarne la vita ma nella realtà la complicano e servono solo a gonfiare d'orgoglio i relatori aziendali con le loro ridicole slides.
    Java sembra sempre più un'operazione commerciale.. anziché perdere tempo perché non si decidono a realizzare un vero compilatore?
    non+autenticato
  • Sarebbe carino un compilatore che dai .class possa compilare degli eseguibili, vero ?

    Ma sarebbe troppo facile e bello: bisogna che sia compilato il tutto "al volo" con il JIT e -poi- dopo l'esecuzione, buttato tutto via (per sprecare -al prossimo avvio dell'applicazione-, un'altra volta la stessa CPU ... altrimenti che te ne fai ?).
    Java è un ottimo linguaggio ed una splendida tecnologia (.NET è semplicemente una copia rivista e corretta) lanciati però prevalentemente per scopi commerciali (cioè senza alcune features che possono risultare "scomode").

    E' per questo che ci sono delle iniziative OpenSource che stanno lavorando per risolvere questo serio problema: gcj, classpath, ecc. ti dicono nulla ?
    Nessuno a carattere commerciale potrebbe fare cose simili senza incorrere nelle ire di Sun.
    Dai un'occhiata.

    Gano
    non+autenticato
  • >>Java è un ottimo linguaggio ed una splendida
    >>tecnologia (.NET è semplicemente una copia
    >>rivista e corretta) lanciati però
    >>prevalentemente per scopi commerciali (cioè
    >>senza alcune features che possono
    >>risultare "scomode").

    potresti motivare _tecnicamente_ le tue affermazioni? potrebbe venirne fuori un dialogo costruttivo ed interessante...

    non+autenticato


  • - Scritto da: Gano
    > Sarebbe carino un compilatore che dai .class
    > possa compilare degli eseguibili, vero ?
    >
    > Ma sarebbe troppo facile e bello: bisogna
    > che sia compilato il tutto "al volo" con il
    > JIT e -poi- dopo l'esecuzione, buttato tutto
    > via (per sprecare -al prossimo avvio
    > dell'applicazione-, un'altra volta la stessa
    > CPU ... altrimenti che te ne fai ?).

    Guarda che è impossibile compilare java. Ci sono delle problematiche che ne impediscono una vera compilazione. In particolare le metodologie di controllo della sicurezza e soprattutto il meccanismo di caricamento delle classi prevedono che la compilazione sia fatta al volo. Quindi non si potrà andare oltre il JIT a meno di troncare alcune sue caratteristiche intrinseche che lo rendono interessante per applicazioni come gli agenti mobili ed altro.
    Purtroppo non si può avere tutto.
    Ciao
    non+autenticato
  • E' dal 98 (se non ricordo male) che partecipo alle Java COnference, ed è sempre la stessa storia: ora facciamo lo standard, write once run everywhere etc
    all'inizio ero molto entusiasta, ora non ci credo più
    non+autenticato
  • Comunque era ora che si rendessero conto che non era possibile continuare a scrivere una servlet o una jsp per un application server e ritrovarsi a doverlo/a correggere totalmente se bisogna portarlo/a su un'altro.
    Fino ad oggi era molto furbo scriversi in proprio dei wrappers e "fregare" in questo modo i fornitori dei vari appserver: se vuoi rimanere indipendente (cambiare l'appserver), reimplementi il wrapper ed il gioco è fatto.

    Di sicuro la prossima volta sarà per i web services, dove -ancora una volta- ognuno ha deciso di andare per la sua strada.

    Personalmente anch'io ne ho abbastanza: quando dovrò implementare il primo web service i casi sono due: o tutti gli application server avranno già tutti le stesse API (100% compatibili) o tanto vale che affronti i web services con altre tecnologie

    Gano
    non+autenticato