Informazioni su di noi

 

Mary Kirtland
Microsoft Corporation

3 gennaio 2001

Benvenuti in At Your Service, una nuova colonna dedicata ai servizi Web.

I servizi Web forniscono informazioni e servizi alle applicazioni tramite interfacce a livello di codice ben definite basate su protocolli Internet standard. Sono una parte fondamentale di Microsoft .NET. Naturalmente, in MSDN abbiamo pensato che dovremmo capire come crearli. Non solo come eseguire il push dei pulsanti in Visual Studio, ma come creare servizi Web scalabili, a disponibilità elevata, sicuri e affidabili.

Il nostro team ha acquisito un'esperienza preziosa nella creazione di applicazioni Web come Duwamish Online. Che cos'è la creazione di servizi Web? Quali problemi si verificano quando altri sviluppatori vogliono usare i servizi Web nelle applicazioni, ovvero le applicazioni ospitate in sistemi operativi diversi, scritte in linguaggi diversi e l'uso di implementazioni diverse di specifiche chiave, ad esempio SOAP?

Si ritiene che l'unico modo per scoprire è quello di costruire alcuni servizi stessi. Nel corso dei prossimi mesi, il team di linee guida di Servizi Web creerà, distribuirà e operarà alcuni servizi Web di esempio. Obiettivo: illustrare i problemi da considerare durante la progettazione, l'implementazione, la distribuzione e la gestione dei propri servizi Web. Si esaminerà anche l'utilizzo dei servizi Web. Ci auguriamo di rilasciare un servizio Web ogni tre mesi.

Tre mesi è un lungo periodo di tempo per farti aspettare nuove informazioni, tuttavia. Quindi, nella grande tradizione del Diario Duwamish, verrà usata questa colonna per seguire ogni progetto di esempio dalla concezione attraverso la progettazione, l'implementazione e la distribuzione. Almeno una volta ogni due settimane, pubblicheremo una voce diario in modo da poter seguire insieme a noi. Al termine di ogni progetto, verranno pubblicate le specifiche, le origini e altri artefatti di progetto qui su MSDN. Sarà sempre possibile accedere a tutte queste informazioni dal nuovo Centro per sviluppatori di servizi Web.

Incontra il team

Il team di linee guida dei servizi Web è attualmente costituito da sei persone:

• Io, Mary Kirtland, sono il capo cuoco e collo di bottiglia, cioè, architetto e program manager, per il team. Faccio la maggior parte di tutto, ma codice, test o gestire i nostri servizi di esempio. Alcuni di voi possono conoscermi dai miei giorni come program manager con il team OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it. Poi sono scomparso nel cono di silenzio che circonda .NET. Circa un anno fa, ho capito che mi piace scrivere su come usare le tecnologie per creare app molto di più di quanto mi piace creare le tecnologie stesse. Quindi, ad aprile, mi sono trasferito in MSDN per lavorare su ciò che è diventato il team di linee guida dei servizi Web. Gran parte del mio tempo è dedicata alla scrittura di questa colonna e contenuto per la pagina delle risorse servizi Web. Il resto è dedicato a cercare di mantenere aggiornate le specifiche di progetto e tenere traccia delle nuove tecnologie che vogliamo coprire lungo la strada.
• Matt Powell e Scott Seely costituiscono il nostro team di sviluppo. Matt è entrato a far parte del team di ottobre dal supporto per sviluppatori. Matt ha scritto il listener ISAPI in SOAP Toolkit per Visual Studio 6.0, coautore in esecuzione di Microsoft Information Server 4.0 per Microsoft Press e ha scritto diversi articoli per MSDN Magazine e i relativi predecessori, MSJ e MIND.
  Scott è entrato a far parte di Microsoft e del nostro team a dicembre dopo aver trascorso gli ultimi cinque anni nel mondo reale creando app reali con i prodotti Microsoft. Nel suo tempo libero copioso, ha scritto articoli per Windows Developer's Journal e un libro intitolato Programmazione di Windows Shell. Quando non lavora sul nostro servizio di esempio, sta lavorando a un libro su SOAP.
  Ci si può aspettare di vedere Matt e Scott scrivendo articoli sul lato di sviluppo delle cose nei mesi a venire.
• Il nostro team di test è costituito da Jan McCollum e Jim Francisco. Jan è entrato a far parte di ottobre come responsabile dei test ed è stato difficile lavorare con un piano di test per il nostro primo progetto. Jim si è unito a dicembre e sta lavorando a unit test e automazione dei test. Jim ha lavorato al team di test di Rete di Windows 98 e al team di test di compilazione/rilascio di Microsoft Host Integration Server. È venuto al nostro team dopo uno stint nel mondo dot-com sviluppare strumenti di distribuzione e amministrazione per applicazioni Web a più livelli. Si proverà a farli scrivere alcuni articoli sui test dei servizi Web quando ci troviamo più lontano.
• Bronwyn Calsyn è il nostro direttore operativo. Bronwyn è iniziato a novembre ed è stato impegnato a cercare di capire quali attrezzature dobbiamo distribuire i nostri servizi di esempio in Internet, insieme alle procedure operative che dobbiamo mantenere le cose in esecuzione senza problemi. Si proverà a farle scrivere anche alcuni articoli sul lato della distribuzione e delle operazioni.

Introduzione al servizio Preferiti

Il primo progetto è il servizio Preferiti. Come utentividi del Web, si riconosce che uno dei problemi riscontrati dagli utenti finali sta individuando le pagine visitate in precedenza, in particolare nei siti dinamici come MSDN Online o nei siti di notizie in cui gli articoli non sono accessibili dalla prima pagina per più di qualche giorno. Anche se è possibile usare i preferiti del browser per tenere traccia delle pagine preferite, i preferiti del browser sono locali in un computer specifico. Ma cosa accade se si usano più computer o dispositivi? Non sarebbe bello se i preferiti potevano essere archiviati in un server da qualche parte, facilmente accessibile da qualsiasi computer in uso?

Questo è esattamente ciò che fa il servizio Preferiti. Consente ai siti Web di archiviare i collegamenti alle pagine Web preferite di un utente finale. Ora, si potrebbe pensare che questo non sembri un servizio molto complicato. E dal punto di vista della logica di business, non lo è. Ciò significa che non è necessario dedicare molto tempo a spiegare la logica di business e non si avrà un sacco di codice specifico dell'applicazione per passare attraverso per trovare le tecniche che è possibile usare nei propri servizi Web. Sono stati tuttavia riscontrati diversi problemi interessanti con il servizio: problemi a cui molti altri sviluppatori abbiamo parlato sono in esecuzione.

Le prime colonne sono incentrate sui problemi riscontrati durante la fase di progettazione del progetto. Alcuni degli argomenti che stiamo prendendo in considerazione:

• Protezione della privacy degli utenti. Qualsiasi applicazione nel mondo dovrebbe essere in grado di eseguire query o modificare i preferiti di ogni utente finale, indipendentemente dall'applicazione salvata dai Preferiti al primo posto?
• Microsoft. Se ogni applicazione non può accedere a tutti i preferiti dell'utente finale, come si controlla l'accesso al servizio? Dovremmo pagare i soldi per il servizio? Quali modelli di business hanno senso?
• Autenticazione e autorizzazione. Se si intende limitare l'accesso al servizio, come si autenticano le applicazioni client e si decide cosa sono autorizzati a eseguire? Come si identificano comunque gli utenti finali?
• Stima dei requisiti di prestazioni. Come è possibile determinare il tipo di carico a cui verrà sottoposto il servizio? È possibile usare gli stessi metodi usati per stimare il carico in un sito Web? Come si determina il tipo di tempi di risposta e disponibilità richiesti dai clienti?
• Requisiti del licenziatario da operazioni di sviluppo, test e operazioni. Se si limita l'accesso al servizio, è possibile che si addestrano denaro in base all'utilizzo, in che modo gli sviluppatori di applicazioni client e i tester provano le app che si basano sul servizio? In che modo è possibile evitare di influire sugli archivi dati di produzione? Quali tipi di strumenti servono al personale addetto ai test e alle operazioni dei nostri clienti per risolvere i problemi che si trovano nelle applicazioni o nel nostro servizio? Quale tipo di documentazione è necessario fornire?
• Globalizzazione. Cosa è necessario fare per garantire che le applicazioni client in tutto il mondo possano usare il servizio Web?
• Facilità di gestione. Quali tipi di informazioni servono al personale operativo per gestire il servizio Web? Come vengono raccolte queste informazioni e presentate agli strumenti di gestione?

Se ci sono altri argomenti che si desidera visualizzare, inviare un messaggio di posta elettronica all'indirizzo wsgmsdn@microsoft.com. Si noti che in questo momento non è possibile rispondere tramite i commenti dell'utente in questa pagina. Tuttavia, leggiamo regolarmente i commenti. Se possiamo capire cosa devono fare i tuoi commenti con il contenuto, vedremo cosa possiamo fare per risolvere il problema in una colonna futura.

La prossima settimana verranno esaminati i problemi riscontrati nella definizione della visione per il progetto del servizio Preferiti. Vedi, allora!