Condividi tramite

Utilizzo del moniker WCF con i client COM

Il questo esempio viene illustrato come utilizzare il moniker del servizio Windows Communication Foundation (WCF) per integrare i servizi Web in ambienti di sviluppo basati su COM, ad esempio Microsoft Office Visual Basic, Applications Edition (Office VBA) o Visual Basic 6.0. Questo esempio è costituito da un client Windows Script Host (.vbs), da una libreria client di supporto (.dll) e da una libreria di servizi (.dll) ospitati in Internet Information Services (IIS). Il servizio è un servizio di calcolatrice e il client COM chiama operazioni matematiche, Add, Subtract, Multiply e Divide, nel servizio. L'attività del client è visibile nella finestra di messaggio.

Nota

La procedura di installazione e le istruzioni di compilazione per questo esempio si trovano alla fine dell'argomento.

Il servizio implementa un contratto ICalculator definito nel modo seguente:

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples")]
public interface ICalculator
{
    [OperationContract]
    double Add(double n1, double n2);
    [OperationContract]
    double Subtract(double n1, double n2);
    [OperationContract]
    double Multiply(double n1, double n2);
    [OperationContract]
    double Divide(double n1, double n2);
}

Nell'esempio vengono descritti tre approcci alternativi per l'utilizzo del moniker:

  • Contratto tipizzato: il contratto viene registrato come tipo visibile a COM sul computer client.
  • Contratto WSDL: il contratto viene fornito sotto forma di documento WSDL.
  • Contratto MEX: il contratto viene recuperato in fase di esecuzione da un endpoint di scambio di metadati (MEX).

Contratto tipizzato

Per utilizzare il moniker con un utilizzo del contratto tipizzato, è necessario registrare con COM i tipi per il contratto di servizio forniti degli attribuiti appropriati. Prima di tutto, è necessario generare un client utilizzando lo strumento Service Model Metadata Utility Tool (Svcutil.exe). Eseguire il comando seguente da un prompt dei comandi nella directory del client per generare il proxy tipizzato:

svcutil.exe /n:http://Microsoft.ServiceModel.Samples,Microsoft.ServiceModel.Samples https://localhost/servicemodelsamples/service.svc /out:generatedClient.cs

Questa classe deve essere inclusa in un progetto e il progetto deve essere configurato per generare un assembly visibile a COM e firmato durante la compilazione. L'attributo seguente deve essere incluso nel file AssemblyInfo.cs:

[assembly: ComVisible(true)]

Dopo avere generato il progetto, registrare i tipi visibili a COM utilizzando regasm:

regasm.exe /tlb:CalcProxy.tlb client.dll

L'assembly creata deve essere aggiunta alla cache di assembly globale. Sebbene non sia strettamente obbligatoria, questa operazione semplifica il processo in cui la fase di esecuzione individua l'assembly. Il comando seguente aggiunge l'assembly alla cache di assembly globale.

gacutil.exe /i client.dll

Nota

Il moniker del servizio richiede solo la registrazione del tipo e non utilizza il proxy per comunicare con il servizio.

L'applicazione client ComCalcClient.vbs utilizza la funzione GetObject per costruire un proxy per il servizio, utilizzando la sintassi del moniker del servizio per specificare l'indirizzo, l'associazione e contratto per il servizio.

Set typedServiceMoniker = GetObject(
"service:address=https://localhost/ServiceModelSamples/service.svc, binding=wsHttpBinding, 
contractType={9213C6D2-5A6F-3D26-839B-3BA9B82228D3}")

I parametri utilizzati dal moniker specificano:

  • L'indirizzo dell'endpoint del servizio.
  • L'associazione che il client dovrebbe utilizzare per connettersi a quell'endpoint. In questo caso, il wsHttpBinding definito dal sistema viene utilizzato anche se le associazioni personalizzate possono essere definite nei file di configurazione del client. Per l'utilizzo con Windows Script Host, l'associazione personalizzata viene definita in un file Cscript.exe.config nella stessa directory di Cscript.exe.
  • Il tipo del contratto è supportato sull'endpoint. Questo è il tipo generato e registrato in precedenza. Poiché lo script di Visual Basic non fornisce un ambiente COM fortemente tipizzato, è necessario specificare un identificatore per il contratto. Questo GUID è l'interfaceID da CalcProxy.tlb e può essere visualizzato utilizzando gli strumenti COM, ad esempio il Visualizzatore oggetti OLE/COM (OleView.exe). Per ambienti fortemente tipizzati, ad esempio Office VBA o Visual Basic 6.0, è possibile aggiungere un riferimento esplicito alla libreria dei tipi e dichiarare quindi il tipo dell'oggetto proxy, invece di utilizzare il parametro del contratto. In questo modo si fornisce anche supporto IntelliSense durante lo sviluppo dell'applicazione client.

Una volta costruita l'istanza del proxy con il moniker del servizio, l'applicazione client può chiamare i metodi sul proxy e l'infrastruttura del moniker del servizio può chiamare le operazioni del servizio corrispondenti:

' Call the service operations using the moniker object
WScript.Echo "Typed service moniker: 100 + 15.99 = " & typedServiceMoniker.Add(100, 15.99)

Quando si esegue l'esempio, la risposta dell'operazione viene visualizzata in una finestra di messaggio di Windows Script Host. Viene descritto un client COM che esegue chiamate COM utilizzando il moniker tipizzato per comunicare con un servizio di WCF. Nonostante si utilizzi COM nell'applicazione client, la comunicazione con il servizio è costituita solo da chiamate del servizio Web.

Contratto WSDL

Per utilizzare il moniker con un contratto WSDL non è richiesta alcuna registrazione della libreria client, ma il contratto WSDL per il servizio deve essere recuperato tramite un meccanismo fuori banda, ad esempio utilizzando un browser per accedere all'endpoint WSDL per il servizio. Il moniker può accedere quindi a quel contratto in fase di esecuzione.

L'applicazione client ComCalcClient.vbs utilizza FileSystemObject per accedere al file WSDL salvato in locale quindi utilizza la funzione GetObject per costruire un proxy per il servizio:

' Open the WSDL contract file and read it all into the wsdlContract string
Const ForReading = 1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("serviceWsdl.xml", ForReading)
wsdlContract = objFile.ReadAll
objFile.Close

' Create a string for the service moniker including the content of the WSDL contract file
wsdlMonikerString = "service:address='https://localhost/ServiceModelSamples/service.svc'"
wsdlMonikerString = wsdlMonikerString + ", binding=WSHttpBinding_ICalculator, bindingNamespace='http://Microsoft.ServiceModel.Samples'"
wsdlMonikerString = wsdlMonikerString + ", wsdl='" & wsdlContract & "'"
wsdlMonikerString = wsdlMonikerString + ", contract=ICalculator, contractNamespace='http://Microsoft.ServiceModel.Samples'"

' Create the service moniker object
Set wsdlServiceMoniker = GetObject(wsdlMonikerString)

I parametri utilizzati dal moniker specificano:

  • L'indirizzo dell'endpoint del servizio.

  • L'associazione che il client deve utilizzare per connettersi con quell'endpoint e lo spazio dei nomi nel quale viene definita quell'associazione. In questo caso, viene utilizzata wsHttpBinding_ICalculator.

  • Il WSDL che definisce il contratto. In questo caso è la stringa letta dal file serviceWsdl.xml.

  • Il nome e lo spazio dei nomi del contratto. Questa identificazione è richiesta perché il WSDL potrebbe contenere più di un contratto.

    Nota

    Per impostazione predefinita, i servizi di WCF generano file WSDL separati per ogni spazio dei nomi che utilizzano. Questi vengono collegati utilizzando il costrutto di importazione di WSDL. Poiché il moniker si aspetta una sola definizione WSDL, il servizio deve utilizzare un solo spazio dei nomi, come illustrato in questo esempio, o i file separati devono essere uniti manualmente.

Una volta costruita l'istanza del proxy con il moniker del servizio, l'applicazione client può chiamare i metodi sul proxy e l'infrastruttura del moniker del servizio può chiamare le operazioni del servizio corrispondenti:

' Call the service operations using the moniker object
WScript.Echo "WSDL service moniker: 145 - 76.54 = " & wsdlServiceMoniker.Subtract(145, 76.54)

Quando si esegue l'esempio, la risposta dell'operazione viene visualizzata in una finestra di messaggio di Windows Script Host. Viene descritto un client COM che esegue chiamate COM utilizzando il moniker con un contratto WSDL per comunicare con un servizio di WCF.

Contratto di scambio di metadati

Per utilizzare il moniker con un contratto MEX, come per il contratto WSDL, non è richiesta alcuna registrazione client. Il contratto per il servizio viene recuperato in fase di esecuzione utilizzando lo scambio di metadati interno.

L'applicazione client ComCalcClient.vbs utilizza quindi la funzione GetObject per costruire un proxy per il servizio:

' Create a string for the service moniker specifying the address to retrieve the service metadata from
mexMonikerString = "service:mexAddress='https://localhost/servicemodelsamples/service.svc/mex'"
mexMonikerString = mexMonikerString + ", address='https://localhost/ServiceModelSamples/service.svc'"
mexMonikerString = mexMonikerString + ", binding=WSHttpBinding_ICalculator, bindingNamespace='http://Microsoft.ServiceModel.Samples'"
mexMonikerString = mexMonikerString + ", contract=ICalculator, contractNamespace='http://Microsoft.ServiceModel.Samples'"

' Create the service moniker object
Set mexServiceMoniker = GetObject(mexMonikerString)

I parametri utilizzati dal moniker specificano:

  • L'indirizzo dell'endpoint di scambio di metadati del servizio.
  • L'indirizzo dell'endpoint del servizio.
  • L'associazione che il client deve utilizzare per connettersi con quell'endpoint e lo spazio dei nomi nel quale viene definita quell'associazione. In questo caso, viene utilizzata wsHttpBinding_ICalculator.
  • Il nome e lo spazio dei nomi del contratto. Questa identificazione è richiesta perché il WSDL potrebbe contenere più di un contratto.

Una volta costruita l'istanza del proxy con il moniker del servizio, l'applicazione client può chiamare i metodi sul proxy e l'infrastruttura del moniker del servizio può chiamare le operazioni del servizio corrispondenti:

' Call the service operations using the moniker object
WScript.Echo "MEX service moniker: 9 * 81.25 = " & mexServiceMoniker.Multiply(9, 81.25)

Quando si esegue l'esempio, la risposta dell'operazione viene visualizzata in una finestra di messaggio di Windows Script Host. Viene descritto un client COM che esegue chiamate COM utilizzando il moniker con un contratto MEX per comunicare con un servizio di WCF.

Per impostare e compilare l'esempio

  1. Assicurarsi di aver eseguito la Procedura di installazione singola per gli esempi di Windows Communication Foundation.

  2. Per compilare l'edizione in C# o Visual Basic .NET della soluzione, seguire le istruzioni in Generazione degli esempi Windows Communication Foundation.

  3. Da un prompt dei comandi, aprire la cartella \client\bin\, nella cartella specifica della lingua. Se si utilizza Windows Vista o Windows Server 2008 assicurarsi di eseguire il prompt dei comandi come amministratore.

  4. Immettere regasm.exe /tlb: CalcProxy.tlb client.dll per registrare i tipi con COM. È previsto un "Avviso dell'utilità di esportazione della libreria dei tipi", ma ciò non rappresenta un problema, perché il tipo generico non è obbligatorio. Assicurarsi che il percorso sia stato impostato sulla cartella che contiene regasm.exe prima di eseguire il comando.

  5. Immettere gacutil.exe /i client.dll per aggiungere l'assembly alla cache di assembly globale. Assicurarsi che il percorso sia stato impostato sulla cartella che contiene gacutil.exe prima di eseguire il comando.

Per eseguire l'esempio sullo stesso computer

  1. Testare l'accesso al servizio in un browser immettendo l'indirizzo seguente: https://localhost/servicemodelsamples/service.svc. In risposta, viene visualizzata un pagina di conferma.

  2. Eseguire ComCalcClient.vbs da \client, nella cartella specifica della lingua. L'attività del client viene visualizzata nella finestra di messaggio.

  3. Se il client e il servizio non sono in grado di comunicare, vedere Suggerimenti per la risoluzione dei problemi.

Per eseguire l'esempio tra più computer

  1. Sul computer del servizio, creare una directory virtuale denominata ServiceModelSamples. Lo script Setupvroot.bat incluso nell'esempio può essere utilizzato per creare la directory del disco e quella virtuale.

  2. Copiare i file del programma del servizio da %SystemDrive%\Inetpub\wwwroot\servicemodelsamples alla directory virtuale di ServiceModelSamples sul computer del servizio. Assicurarsi di includere i file nella directory \bin.

  3. Copiare il file script del client dalla cartella \client, nella cartella specifica della lingua, al computer client.

  4. Nel file script, modificare il valore dell'indirizzo della definizione dell'endpoint affinché corrisponda al nuovo indirizzo del servizio. Sostituire qualsiasi riferimento a "localhost" con un nome di dominio completo nell'indirizzo.

  5. Nel file WSDL, serviceWsdl.xml, sostituire qualsiasi riferimento a "localhost" con un nome di dominio completo nell'indirizzo.

  6. Copiare la libreria Client.dll dalla cartella \client\bin\, nella cartella specifica della lingua, a una directory sul computer client.

  7. Da un prompt dei comandi, spostarsi a quella directory di destinazione sul computer client. Se si utilizza Windows Vista o Windows Server 2008 assicurarsi di eseguire il prompt dei comandi come amministratore.

  8. Immettere regasm.exe /tlb: CalcProxy.tlb client.dll per registrare i tipi con COM. Assicurarsi che il percorso sia stato impostato sulla cartella che contiene regasm.exe prima di eseguire il comando.

  9. Immettere gacutil.exe /i client.dll per aggiungere l'assembly alla cache di assembly globale. Assicurarsi che il percorso sia stato impostato sulla cartella che contiene gacutil.exe prima di eseguire il comando.

  10. Verificare che sia possibile accedere al servizio dal computer client utilizzando un browser.

  11. Sul computer client, avviare ComCalcClient.vbs.

Per eseguire la pulitura dopo l'esempio

  • Per motivi di sicurezza, rimuovere la definizione della directory virtuale e le autorizzazioni concesse durante l'installazione quando si è finito di lavorare con gli esempi eseguendo il file batch denominato Cleanupvroot.bat.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.

  • Last updated on