Washington (USA) – Ieri Intel e AMD si sono affrontate di fronte alla Corte Suprema degli Stati Uniti in merito ad una vecchia questione che le contrappone. AMD vorrebbe che si obbligasse l’avversaria a rilasciare della documentazione ritenuta di fondamentale importanza per l’inchiesta antitrust che, dal 2000, l’Unione Europea sta conducendo sul gigante dei chip.
Questo documenti, circa 60.000 pagine, sono stati già esibiti da Intel in una precedente causa con Intergraph ( accomodata proprio di recente ). Per rendere disponibili tali carteggi all’antitrust europeo, AMD chiama in causa una vecchia legge che consente ad un tribunale statunitense di trasmettere la documentazione di un processo ad una corte straniera.
“Vogliamo essere sicuri che gli inquirenti della UE possano accedere ai dati che dovrebbero esser resi loro disponibili”, ha detto Michael Simonoff, portavoce di AMD.
Il chipmaker di Sunnyvale sostiene che tale documentazione potrebbe fornire informazioni preziose circa le pratiche di mercato di Intel e, in modo particolare, sulle presunte ritorsioni che questa avrebbe minacciato nei confronti di alcuni produttori di computer che adottano i chip di AMD. Ed è qui, evidentemente, l’interesse principale di AMD nella vicenda.
Intel ha fatto ricorso alla Corte Superiore dopo che AMD, lo scorso ottobre, ha vinto la causa in un tribunale distrettuale. In sua difesa il chipmaker di Santa Clara reclama il fatto che l’inchidesta antitrust dell’UE non è ancora sfociata in una causa legale e, pertanto, la legge tirata in ballo AMD sarebbe in questo caso inapplicabile.
Va notato che la UE, pur interessata ai documenti, è d’accordo con gli avvocati di Intel. La Commissione teme infatti che la vittoria di AMD apra un rischioso precedente, e dia l’avvio ad un’incontrollata condivisione di documenti fra corti americane ed europee: condivisione che, secondo alcuni avvocati, dovrebbe invece avvenire solo in rare e particolari circostanze.
Sebbene la decisione della Corte Suprema potrebbe avere un ruolo determinante sul proseguimento dell’indagine antitrust europea, gli analisti sostengono che il caso non dovrebbe avere un impatto immediato sul valore azionario del big di Santa Clara.
-
E WS-Transaction quando?
Finchè non ho WS-Transaction standardizzaro e un framework (+ server) che mi permetta di implementarlo, io non scrivo applicazioni con WS. Sia in Java che in .NET.Più di qualche RPC autenticata, senza le transazioni, non si può fare.Mi sembra chiaro.We're waiting...AnonimoRe: E WS-Transaction quando?
Confermo.Inoltre come per tutte le applicazioni ed i componenti del mondo, bisognerà aspettare che questi web-services siano utilizzati da una massa critica di programmatori e di utenti, e infine vedere quanto resistono agli attacchi hacker.Farsi i propri componenti o scegliersi le proprie tecnologie aumenta la sicurezza, disorientando chi vuole attaccare un servizio. Affidarsi tutti a componenti standard, che poi magari vengono "bucati", cosa provocherebbe?Romeo- Scritto da: Anonimo> Finchè non ho WS-Transaction> standardizzaro e un framework (+ server) che> mi permetta di implementarlo, io non scrivo> applicazioni con WS. Sia in Java che in> .NET.> > Più di qualche RPC autenticata, senza> le transazioni, non si può fare.> Mi sembra chiaro.> > We're waiting...AnonimoNon basterà un browser...
"In prospettiva, affermano, quando basterà un browser e una connessione a larga banda per accedere ad applicativi e giochi, i sistemi operativi potrebbero perdere parte della loro attuale importanza, divenendo - soprattutto per gli utenti desktop - una sorta di interfaccia tuttofare al "sistema operativo globale": il Web."I web services sono l'esatto contrario: sono un meccanismo di "remoting" (invocazione remota di codice) e non una "interfaccia" come HTML. L'unico punto in comune è che usano HTTP per la comunicazione client/server (e per questo sono poco performanti, per ora).Sono perfettamente utilizzabili senza un browser, anzi un browser non serve a nulla perché non è in grado di utilizzarli.Il vantaggio di SOAP è di essere uno standard indipendente dalla piattaforma (i metodi di un web services scritto in java sono facilmente invocabili da un'applicazione nativa Windows o Linux, e viceversa) e di usare HTTP come trasporto e quindi di passare agevolmente attraverso i firewall. Potrebbero permettere di costruire agevolmente applicazioni distribuite che sfruttino servizi disponibili in rete, ma potrebbero anche segnare la fine del browser così come lo conosciamo. Invece di richiamare pagine HTML si chiameranno servizi. Ad esempio invece di ottenere una pagina HTML con lo stato del mio conto corrente potrei ricevere un file XML con gli stessi dati, che a quel punto potrei processare con qualsiasi programma in grado di leggere quel formato, programma che potrebbe benissimo non essere un browser. Lo stesso programma potrebbe invocare un metodo del servizio per effettuare un bonifico, di nuovo senza dover passare per un browsers e HTML. Con i web services è finalmente possibile separare i dati dall'interfaccia.ldsandonRe: E WS-Transaction quando?
concordo in pienomassimoAnonimoRe: Non basterà un browser...
- Scritto da: ldsandon> I web services sono l'esatto contrario: sono> un meccanismo di "remoting" (invocazione> remota di codice) e non una "interfaccia"> come HTML. L'unico punto in comune èTi sfugge il concetto di web-service: un web-service *NON* è l'applicazione in sè (e.g. il cgi-bin che "esegue" il servizio), ma è l'insieme *astratto* delle sue componenti (protocollo, bussiness-logic, registro etc.).> che usano HTTP per la comunicazione> client/server (e per questo sono poco> performanti, per ora).> Sono perfettamente utilizzabili senza un> browser, anzi un browser non serve a nulla> perché non è in grado di> utilizzarli.??? Da quando?> Il vantaggio di SOAP è di essere uno> standard indipendente dalla piattaforma (i> metodi di un web services scritto in java> sono facilmente invocabili da> un'applicazione nativa Windows o Linux, e> viceversa) e di usare HTTP come trasporto eUsare _anche_ l'http. Ti manca il concetto di binding.> quindi di passare agevolmente attraverso i> firewall. Potrebbero permettere di costruire> agevolmente applicazioni distribuite che> sfruttino servizi disponibili in rete, ma> potrebbero anche segnare la fine del browser> così come lo conosciamo. Invece di> richiamare pagine HTML si chiameranno> servizi. Ad esempio invece di ottenere una> pagina HTML con lo stato del mio conto> corrente potrei ricevere un file XML con gli> stessi dati, che a quel punto potrei> processare con qualsiasi programma in> grado di leggere quel formato, programma che> potrebbe benissimo non essere un browser. Lo> stesso programma potrebbe invocare un metodo> del servizio per effettuare un bonifico, di> nuovo senza dover passare per un browsers e> HTML. Con i web services è finalmente> possibile separare i dati dall'interfaccia.Hai una visione un po' riduttiva dei web-services.==================================Modificato dall'autore il 21/04/2004 10.48.50logitechRe: Non basterà un browser...
> Ti sfugge il concetto di web-service: unSfugge a te: un web services è una classe che espone una interfaccia invocabile da remoto. Non è nient'altro che una forma di RPC con la sua serie di protocolli - niente di più, niente di meno.> ??? Da quando?Quale browser capisce SOAP? O è in grado di creare da solo un'interfaccia per un WS? Un browser non è in grado di essere un consumer, è costruito per parsare HTML e eseguire Javascript, più di questo non fa. Casomai il web server può usare un web service per creare una pagina HTML per il client, ma questa è un'altra storia. > Hai una visione un po' riduttiva dei> web-services.Tu ne hai una visione da commerciale, direi, i web services che salvano il mondo fino alla prossima idea da vendere.ldsandonRe: Non basterà un browser...
- Scritto da: ldsandon> > Ti sfugge il concetto di web-service: un> > Sfugge a te: un web services è una> classe che espone una interfaccia invocabile> da remoto. Non è nient'altro che una> forma di RPC con la sua serie di protocolli> - niente di più, niente di meno.E questa definizione dove l'hai trovata, su "Web Service for dummies"???Prova a leggere qualcosa del w3c, per esempio: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/ > > ??? Da quando?> > Quale browser capisce SOAP? O è inMa hai mai sentito parlare di binding? Tutti i linguaggi creati per i WS hanno dei biniding per l'HTML (molti hanno binding _solo_ per html).> > Hai una visione un po' riduttiva dei> > web-services.> > Tu ne hai una visione da commerciale, direi,> i web services che salvano il mondo fino> alla prossima idea da vendere.Io non devo vendere prorpio niente, i WS sono solo l'argomento della mia tesi...logitechRe: Non basterà un browser...
- Scritto da: logitech>> Ma hai mai sentito parlare di binding? Tutti> i linguaggi creati per i WS hanno dei> biniding per l'HTML (molti hanno binding> _solo_ per html).Casomai sarà HTTP. Comunque consiglio a tutti di vedere cosa stanno facendo MS e IBM con Indigo e l'Enterprise Bus.AnonimoRe: Non basterà un browser...
> E questa definizione dove l'hai trovata, su> "Web Service for dummies"???No, non leggo i libri che leggi tu...> Ma hai mai sentito parlare di binding? Tutti> i linguaggi creati per i WS hanno dei> biniding per l'HTML (molti hanno binding> _solo_ per html).Sono solo un modo di utilizzare i WS, e non quello principale.> Io non devo vendere prorpio niente, i WS> sono solo l'argomento della mia tesi...Io ci lavoro con i WS... quando avrai imparato qualcosa di serio ripassa....ldsandonRe: Non basterà un browser...
- Scritto da: ldsandon> > E questa definizione dove l'hai> trovata, su> > "Web Service for dummies"???> > No, non leggo i libri che leggi tu...Dei libri che leggo io non riusciresti a capire nemmeno il titolo...> > Io non devo vendere prorpio niente, i WS> > sono solo l'argomento della mia tesi...> > Io ci lavoro con i WS... quando avrai> imparato qualcosa di serio ripassa....Fammi capire...Hai fatto un corso di due settimane su "Cosa sono i WS?" finanziato da qualche fondo sociale, poi hai iniziato a lavorare ripetendo le tre cose tre che ti avevano spiegato ai clienti, su cui facevi una buona impressione, perchè per loro è già difficile configurare la posta elettronica.A quel punto hai pensato di sapere tutto di informatica...Caro mio, le cose serie le impari nei dipartimenti. Noi stiamo lavorando su delle implementazioni di WS usando specifiche che sono ancora degli RFP, perchè bisogna portarsi avanti.Ci sono un sacco di problematiche dietro alle interfacce grafiche che i cosidetti "programmatori" amano usare.Se sei invidioso di che fa ricerca, sfogati sui tuoi clienti.logitechRe: Non basterà un browser...
> Io ci lavoro con i WS... quando avrai> imparato qualcosa di serio ripassa....c'e' da dire xo' che ne hai una visione limitata,i WS non sono *solo* RPC (non per altro in SOAP l'rpc/encoded e' sulla strada del deprecated e si consiglia gia' da ora l'utilizzo del doc/literal ovvero dello scambio di documenti XML non encodati come chiamata a procedura remota)EcioAnonimoRe: Non basterà un browser...
dimenticavo,alla domanda "quale browser capisce SOAP",se non erro l'XPCom di Mozilla lo supporta...EcioAnonimoRe: Non basterà un browser...
> Dei libri che leggo io non riusciresti a> capire nemmeno il titolo...Leggi libri in cinese antico? Sì, lì ho dei problemi. > Hai fatto un corso di due settimane su "Cosa> sono i WS?" finanziato da qualche fondo> sociale, poi hai iniziato a lavorareNo, al massimo i corsi di programmazione io li tengo.> Se sei invidioso di che fa ricerca, sfogati> sui tuoi clienti.Invidioso di un pivello? Suvvia, aspetta tu di trovarne dei clienti... con questo atteggiamento non so quanta strada farai. Impara a rispettare il tuo prossimo e le sue idee. Ti aiuterà nella vita.ldsandonRe: Non basterà un browser...
> c'e' da dire xo' che ne hai una visione> limitata,Cioè? Dimmi cos'è un WS più di una chiamata remota.> i WS non sono *solo* RPC (non per altro in> SOAP l'rpc/encoded e' sulla strada del> deprecated e si consiglia gia' da ora> l'utilizzo del doc/literal ovvero dello> scambio di documenti XML non encodati come> chiamata a procedura remota)Cambia l'encoding della chiamata, ma sempre di chiamata procedura remota si tratta, cioè Remote Procedure Call aka RPC.ldsandonRe: E WS-Transaction quando?
- Scritto da: Anonimo> Confermo.> Farsi i propri componenti o scegliersi le> proprie tecnologie aumenta la sicurezza,> disorientando chi vuole attaccare un> servizio. Affidarsi tutti a componenti> standard, che poi magari vengono "bucati",> cosa provocherebbe?DA quando una specifica proprietaria e' piu' affidabile di una standard pubblica?Non c'e' nessuna correlazione.Le dimostrazioni si sprecano.AnonimoRe: E WS-Transaction quando?
- Scritto da: Anonimo> Confermo.> > Inoltre come per tutte le applicazioni ed i> componenti del mondo, bisognerà> aspettare che questi web-services siano> utilizzati da una massa critica di> programmatori e di utenti, e infine vedere> quanto resistono agli attacchi hacker.> > Farsi i propri componenti o scegliersi le> proprie tecnologie aumenta la sicurezza,> disorientando chi vuole attaccare un> servizio. Affidarsi tutti a componenti> standard, che poi magari vengono "bucati",> cosa provocherebbe?WS-X sono protocolli (in forma XML). Tu stai parlando di buchi sulle implementazioni degli stack di protocolli. E' un'altra cosa.Quello che dicevo io (sono l'autore del primo post) è che finchè non ho anche la specifica di WS-Transaction e le correlate a posto, neanche ci penso a progettare qualcosina.....AnonimoRe: Non basterà un browser...
> Cambia l'encoding della chiamata, ma sempre> di chiamata procedura remota si tratta,> cioè Remote Procedure Call aka RPC. Vi sono due modalità di chiamate nei WS.RPC come la intendi tu: faccio una domanda in SOAP e ricevo una risposta.Poi vi è la modalità, diciamo, message-based: Compilo un messaggio, lo riempio di header di sicurezza,transazioni, routing, reliability ecc e lo lascio andare per la sua strada.Questa seconda modalità è quella consigliata, la prima è deprecata.Evidentemente tu ci lavori, ma non studi molto. Con rispetto... 8)AnonimoRe: Non basterà un browser...
- Scritto da: ldsandon> > E questa definizione dove l'hai> trovata, su> > "Web Service for dummies"???> > No, non leggo i libri che leggi tu...> > > > Ma hai mai sentito parlare di binding?> Tutti> > i linguaggi creati per i WS hanno dei> > biniding per l'HTML (molti hanno binding> > _solo_ per html).> > Sono solo un modo di utilizzare i WS, e non> quello principale.> > > Io non devo vendere prorpio niente, i WS> > sono solo l'argomento della mia tesi...> > Io ci lavoro con i WS... quando avrai> imparato qualcosa di serio ripassa....Se lavori con l'attuale implementazione M$ cestina tutto. La visione corretta dei WS è quella Service-Oriented e non RPC.Far l'early adopter di M$ è un grande rischio.AnonimoRe: Non basterà un browser...
Ok, giocate pure con le buzzwords... ai clienti piacciono, ai commerciali IBM e MS pure, poi gratta gratta trovi sempre le stesse cose.http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.htmGuarda caso parla di DCOM e CORBA, che non sono altro che modelli di RPC object-oriented.Se mi parlate di architettura "service oriented" per il partizionamento di una applicazione distribuita è una cosa, i "web services" sono un'altra. Potete implementare un'architettura service oriented con qualsiasi tecnologia di remoting. Che i web services siano comodi se i servizi devono essere raggiungibili via internet e attraverso firewall è vero, che siano l'architettura non è vero.ldsandonRe: Non basterà un browser...
> Poi vi è la modalità, diciamo,> message-based: Compilo un messaggio, lo> riempio di header di sicurezza,transazioni,> routing, reliability ecc e lo lascio andare> per la sua strada.Ok, message queue invece di remoting. Ma sono due cose diverse - con campi di applicazione diversi. > Questa seconda modalità è> quella consigliata, la prima è> deprecata.Consigliata da chi? Se la comunicazione è asincrona mi va bene la seconda, altrimenti no.> Evidentemente tu ci lavori, ma non studi> molto. Con rispetto... 8)Lavoro con gli strumenti di oggi per risolvere i problemi di domani, per quelli di dopodomani devo aspettare il rilascio di specifiche e strumenti...ldsandonRe: Non basterà un browser...
> Se lavori con l'attuale implementazione M$> cestina tutto. La visione corretta dei WS> è quella Service-Oriented e non RPC.veramente e' il contrario, .NET utilizza come approccio di default quello doc/literal mentre axis usa rpc/encodedEcioAnonimoRe: Non basterà un browser...
- Scritto da: ldsandon> > Poi vi è la modalità,> diciamo,> > message-based: Compilo un messaggio, lo> > riempio di header di> sicurezza,transazioni,> > routing, reliability ecc e lo lascio> andare> > per la sua strada.> > Ok, message queue invece di remoting. Ma> sono due cose diverse - con campi di> applicazione diversi.appunto, sei tu che dicevi che i WS sono *solo* RPC ;) > > Questa seconda modalità è> > quella consigliata, la prima è> > deprecata.> > Consigliata da chi? Se la comunicazione> è asincrona mi va bene la seconda,> altrimenti no.ho letto anchio da qualche parte che si consiglia l'approccio doc/literal invece di quello rpc/encoded, teoricamente la cosa dovrebbe prendere piede con wsdl 2.0....> > Lavoro con gli strumenti di oggi per> risolvere i problemi di domani, per quelli> di dopodomani devo aspettare il rilascio di> specifiche e strumenti...Da questo punto di vista hai ragione, tutte le maggiori implementazioni sono basate su wsdl1.2 e non su 2.0AnonimoRe: Non basterà un browser...
> appunto, sei tu che dicevi che i WS sono> *solo* RPC ;)Io ho detto che sono un metodo di "remoting". Che sia basato su chiamate sincrone o messaggi asincroni sempre remoting è, IMHO ;)Altrimenti sarebbero un semplice protocollo di trasporto, nulla di più.ldsandonRe: Non basterà un browser...
- Scritto da: ldsandon> > appunto, sei tu che dicevi che i WS sono> > *solo* RPC ;)> > Io ho detto che sono un metodo di> "remoting". Che sia basato su chiamate> sincrone o messaggi asincroni sempre> remoting è, IMHO ;)> > Altrimenti sarebbero un semplice protocollo> di trasporto, nulla di più. > vabbe' non stiamo qui a scornarci sulle definizioni, gia' ognuno (sun, ibm, ms etc) da' quella che preferisce, chi li considera una architettura a se' stante, chi una interfaccia per creare una architettura orientata ai servizi, chi li vede come un'estensione delle pagine web, senza contare le sono decine e decine di protocolli solo parzialmente sviluppati che non sappiamo neanche se verranno mai usati :)ciao,EcioAnonimoRe: Non basterà un browser...
- Scritto da: ldsandon> No, al massimo i corsi di programmazione io> li tengo.Se vantarti in un forum come quello di PI fa aumentare la tua autostima, fa pure, ma ti dà un'aria da sfigato...> Invidioso di un pivello? Suvvia, aspetta tu> di trovarne dei clienti... con questoIo i clienti li ho già, solo che non sono "lo scopo della mia vita", ma semplicemente un modo per raccimolare qualche soldo.Essere ingegneri e fare ricerca allo stato dell'arte permette di scegliersi i clienti...> atteggiamento non so quanta strada farai.> Impara a rispettare il tuo prossimo e le sue> idee. Ti aiuterà nella vita.Ah sì? Sono io quello che ha sparato a zero sugli autori del WSDL? O sei stato tu? E' questo il tuo concetto di rispetto?Ah, ma ho capito: tu tieni corsi di programmazione, sei molto meglo di quelli dell'WSDL!!!!logitechRe: Non basterà un browser...
> Se vantarti in un forum come quello di PI fa> aumentare la tua autostima, fa pure, ma ti> dà un'aria da sfigato...Sei tu che ti vanti attaccando gli altri... e questo ti dà un'aria da sfigato invidioso... > Io i clienti li ho già, solo che non> sono "lo scopo della mia vita", ma> semplicemente un modo per raccimolare> qualche soldo.A parte l'ortografia, solo per i commerciali i clienti sono lo scopo della vita...> Essere ingegneri e fare ricerca allo stato> dell'arte permette di scegliersi i> clienti...Stato dell'arte della ricerca i web services? :-) ROTFL!> Ah sì? Sono io quello che ha sparato> a zero sugli autori del WSDL? O sei stato> tu? E' questo il tuo concetto di rispetto?Io sparare a zero sugli autori del WSDL? Ma hai mai imparato a leggere? Io ho solo sottolineato che l'affermazione riportata nel testo dell'articolo era esagerata. Poi sei tu che hai cominciato a sparare a zero su di me... come ogni zelota novellino.> Ah, ma ho capito: tu tieni corsi di> programmazione, sei molto meglo di quelli> dell'WSDL!!!!Mai detto questo. Ma a leggere quello che hai scritto manie di grandezza le hai solo tu.ldsandonRe: Non basterà un browser...
- Scritto da: ldsandon> > Se vantarti in un forum come quello di> PI fa> > aumentare la tua autostima, fa pure, ma> ti> > dà un'aria da sfigato...> > Sei tu che ti vanti attaccando gli altri... Riporta precisamente dove mi vanto attacando gli altri: io dico ciò che faccio notare a chi si sopravvaluta dove sbaglia.> e questo ti dà un'aria da sfigato> invidioso...Quando mi ridurrò ad essere invidioso di una persona come te, sarà l'ora di suicidarmi!> A parte l'ortografia, solo per i commerciali> i clienti sono lo scopo della vita...A parte che dovresti farmi notare *quale* errore di ortografia ho commesso, noto che ritorni continuamente con questa storia dei "commerciali". Mi sa tanto che sono l'incubo della tua piccola vita!> > Essere ingegneri e fare ricerca allo> stato> > dell'arte permette di scegliersi i> > clienti...> > Stato dell'arte della ricerca i web> services? :) ROTFL!Hai problemi di comprensione, adesso non mi stupiscono più tutte le cavolate che spari. Io ho affermato che faccio ricerca allo stato dell'arte sui WS (infatti qui in dipartimento circolano perlopiù RFP), non che i WS sono lo stato dell'arte della ricerca!!!!> > Ah sì? Sono io quello che ha> sparato> > a zero sugli autori del WSDL? O sei> stato> > tu? E' questo il tuo concetto di> rispetto?> > Io sparare a zero sugli autori del WSDL? Ma> hai mai imparato a leggere? Io ho soloAllora, nel tuo intervento iniziale parti citando le affermazioni dell'OASIS, dopodichè affermi "I web services sono l'esatto contrario". Ogni altro commento mi sembra superfluo.> Mai detto questo. Ma a leggere quello che> hai scritto manie di grandezza le hai solo> tu.Sì, bravo. Torno al tuo lavoro e pensa al tuo nemico giurato: "il commerciale"!!!logitechGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoGrazie per esserti iscritto alla nostra newsletterOops, la registrazione alla newsletter non è andata a buon fine. Riprova.Leggi gli altri commentiPubblicato il 21 apr 2004Ti potrebbe interessare