Servizi Web COM+: route Check-Box ai servizi Web XML

John Noss e Jonathan Hawkins
Microsoft Corporation

Novembre 2001

Riepilogo: COM+ Web Services aggiunge funzionalità che si integrano con Microsoft .NET Remoting per fornire l'attivazione della casella di controllo della pubblicazione del servizio Web XML tramite SOAP per i componenti COM+. Questo documento include diversi esempi e procedure dettagliate che coprono l'interoperabilità di base, la configurazione e la distribuzione di componenti COM+ gestiti pubblicati come servizi Web XML in Microsoft Windows Server 2003 e Microsoft Windows XP Professional. (26 pagine stampate)

Contenuto

Introduzione
Esempi di oggetti di Well-Known semplice (WKO)
Esempi di oggetti CAO (Simple Client-Activated Object)
Esempi di componenti transazionali
Un inizio, non una fine...

Introduzione

COM+ Web Services aggiunge funzionalità che si integrano con Microsoft .NET Remoting per fornire l'attivazione della casella di controllo della pubblicazione del servizio Web XML tramite SOAP per i componenti COM+. Questo documento include diversi esempi e procedure dettagliate che coprono l'interoperabilità di base, la configurazione e la distribuzione di componenti COM+ gestiti pubblicati come servizi Web XML in Microsoft® Windows Server 2003 e Microsoft Windows® XP Professional. Sono disponibili anche esempi di nuove funzionalità disponibili per i client che eseguono Windows XP per accedere ai servizi Web XML nei server remoti.

L'obiettivo di queste funzionalità è semplificare e semplificare il processo di migrazione quando gli sviluppatori iniziano a usare .NET Remoting e codice gestito per integrare il codice COM+ e il codice client non gestito esistente. Durante le fasi beta di .NET Framework, sono state frequenti le domande degli utenti su come configurare .NET Remoting per eseguire semplici attivazioni tra computer. La soluzione COM+ Web Services consiste nel configurare automaticamente sia i computer server (Microsoft Windows Server 2003) sia i computer client (Microsoft Windows XP Professional) per usare .NET Remoting per fornire SOAP come alternativa a DCOM.

Due delle più grandi versioni software di quest'anno saranno Microsoft Windows XP e Microsoft .NET Framework. L'obiettivo di ognuno è semplificare ed estendere le funzionalità degli sviluppatori software, quindi è un passaggio naturale per sfruttare i due prodotti e fornire una soluzione integrata e facile da usare che incorpora i punti di forza di entrambi i prodotti. COM+ Web Services offre un modo semplice per pubblicare componenti COM+ come servizi Web XML e offre anche nuove funzionalità integrate per accedere ai servizi Web XML da un computer client. Questa facilità d'uso può essere vista dall'esempio seguente di Microsoft Visual Basic Scripting Edition (VBScript), che determina la temperatura corrente in Fairbanks, Alaska. Questo esempio viene eseguito in Windows XP (con .NET Framework installato) o in Windows Server 2003 (per cui è necessaria la compilazione di .NET Framework Release Candidate o successiva):

set SoapObj = GetObject
   ("soap:wsdl=http://www.xmethods.net/sd/TemperatureService.wsdl")
WScript.Echo "Fairbanks Temperature = " & SoapObj.getTemp("99707")

Nell'esempio precedente il server è un server Apache SOAP in esecuzione in Linux, anche se potrebbe essere qualsiasi server SOAP versione 1.1 con una descrizione WSDL (Standard Web Services Description Language).

Nota Se viene visualizzato un errore "server non trovato", è necessario configurare manualmente le impostazioni del firewall in Opzioni Internet in Pannello di controllo.

Uno dei vantaggi dell'uso di SOAP come protocollo di comunicazione tra computer è che aumenta la varietà di computer che possono interoperabilità. La comunicazione remota .NET include le due modalità di base seguenti:

Oggetto noto (WKO) WKO è il modello di Servizi Web XML più comune supportato da SOAP versione 1.1. Consente l'interoperabilità con altri computer che eseguono stack SOAP versione 1.1 conformi. I server e i client possono variare da server non Windows che eseguono Apache SOAP a PC Pocket che eseguono pocketSOAP, oltre ai server e ai client basati su Windows. L'unico requisito è che un server deve avere una descrizione compatibile con WSDL versione 1.1 in modo che sia possibile generare un proxy appropriato. Questo proxy viene generato in fase di esecuzione, senza alcun intervento dell'utente in base al primo uso di un moniker WSDL.
Oggetto attivato dal client (CAO) CAO offre un ambiente di sviluppo più avanzato, tra cui connessioni permanenti con stato più simile al modello DCOM rispetto al modello di servizi Web XML tipico, ma richiede una versione di .NET Framework a entrambe le estremità.

Con COM+ Web Services, i modelli di attivazione WKO e CAO sono entrambi disponibili e tutte le applicazioni server vengono pubblicate per fornire endpoint WKO e CAO. Usando questa combinazione di modelli di attivazione, servizi Web XML e .NET Remoting, uno sviluppatore può facilmente combinare e trovare la corrispondenza tra client e server gestiti e non gestiti. Gli esempi di scenari supportati per ogni modello di attivazione sono illustrati nelle tabelle seguenti.

Tabella 1. Scenari supportati per il modello WKO

WKO Client	WKO Server
Visual Basic 6.0 o C++ non gestito	Visual Basic 6.0 o C++ non gestito
Visual Basic 6.0 o C++ non gestito	Visual Basic .NET o C#
Visual Basic 6.0 o C++ non gestito	SOAP v1.1 (descritto in WSDL)
Visual Basic 6.0 o C++ non gestito	Microsoft SOAP (ATL Server, SOAP TK)
C# o Visual Basic .NET	SOAP v1.1 (descritto in WSDL)
C# o Visual Basic .NET	Visual Basic 6.0 o C++ non gestito
C# o Visual Basic .NET	Visual Basic .NET o C#
C# o Visual Basic .NET	Microsoft SOAP (ATL Server, SOAP TK)
Microsoft SOAP Toolkit V2.0	Visual Basic 6.0 o C++ non gestito
Microsoft SOAP Toolkit V2.0	C# o Visual Basic .NET
SOAP v1.1	Visual Basic 6.0 o C++ non gestito
SOAP v1.1	C# o Visual Basic .NET

Tabella 2. Scenari supportati per il modello CAO

CAO Client	CAO Server
C# o Visual Basic .NET (associazione anticipata)	Visual Basic 6.0 o C++ non gestito
Visual Basic 6.0 o C++ non gestito	Visual Basic 6.0 o C++ non gestito
Visual Basic 6.0 o C++ non gestito	C# o Visual Basic .NET
C# o Visual Basic .NET	C# o Visual Basic .NET

Il pubblico di destinazione per questo nuovo servizio Web COM+ include gli utenti seguenti:

I clienti COM+ correnti che hanno Microsoft® Visual Basic® 6.0 o non gestiti Microsoft Visual C++ ® applicazioni COM+ che devono passare attraverso un firewall per alcune attivazioni. L'uso di SOAP non impedisce l'accesso allo stesso componente in un server tramite DCOM. La scelta del protocollo viene lasciata al computer client. Per questi clienti, l'uso dell'esportazione del proxy client e il modello CAO non devono richiedere modifiche nelle applicazioni client o server per usare SOAP anziché DCOM. È sufficiente abilitare SOAP nell'applicazione server, esportarla come proxy client e installare il proxy nei computer Windows XP che si desidera usare come client SOAP.
Le aziende che passano interamente al codice gestito in Windows XP e Windows Server 2003. I servizi Web COM+ facilitano la configurazione degli endpoint di comunicazione remota in entrambe le estremità della connessione.
Gli sviluppatori che devono combinare e abbinare vari servizi all'interno dei due scenari precedenti e che scrivono componenti server gestiti o applicazioni client gestite con componenti server non gestiti. In quest'ultimo caso, gli sviluppatori possono usare SERVIZI Web COM+ per ottimizzare l'uso di componenti non gestiti meno recenti prima di sostituirli con il codice gestito.

Esempi di oggetti di Well-Known semplice (WKO)

Oltre a fornire supporto SOAP a Linux e Apache, l'uso di servizi Web COM+ con altri prodotti Microsoft, ad esempio un servizio Web ATL Server, è anche molto semplice. Usare Solo Microsoft Visual Studio® .NET per generare, compilare e distribuire un servizio Web ATL predefinito in un server. Il codice client per accedervi sarà il seguente (sostituendo MyServer con il nome del server Web che ospita l'applicazione ATL Server e sostituendo JALTServer con il nome della DLL del server ATL):

mon="soap:wsdl=http://MyServer/JALTServer/JALTServer.dll?
   Handler=GenJALTServerWSDL"
set c = GetObject(mon)
WScript.Echo c.HelloWorld("COM+ Web Services")

L'esempio precedente fornisce una semplice figura di uno dei nuovi moniker SOAP inclusi in Microsoft Windows XP e nella famiglia Microsoft Windows Server 2003. Per usare il moniker per usare un servizio Web ASP.NET, il servizio Web deve avere l'attributo di classe System.Web.Services.Protocols.SoapRpcService .

Pubblicazione dati

Cosa succede se si desidera fornire dati anziché usarli? È sufficiente selezionare una casella di controllo e immettere un valore per un nome radice virtuale IIS. Per creare un servizio Web COM+ completo, seguire questa procedura:

Con Visual Basic 6.0 si crea una semplice DLL Microsoft ActiveX® e si digita nel codice seguente:

Function Add(ByVal Value1 As Double, ByVal Value2 As Double) As Double
 Add = Value1 + Value2
End Function

Nella scheda Generale della pagina Proprietà progetto Visual Basic impostare Esecuzione automatica e Conservazione in memoria e nella scheda Componente selezionare File server remoti. Compilare questa DLL usando l'ambiente di sviluppo di Visual Basic.

Dopo aver creato l'applicazione Visual Basic, deve essere registrata come applicazione COM+. Avviare lo strumento di amministrazione di Servizi componenti e creare un'applicazione COM+ in Windows XP. In questo esempio l'applicazione è denominata VB6Soap. Importare la DLL creata come componente. Passare quindi alla scheda Attivazione della pagina Proprietà dell'applicazione COM+, selezionare Usa SOAP, immettere un Vroot SOAP, ad esempio VB6Soap e fare clic su OK, come illustrato nella figura 1.

Figura 1. Pagina Proprietà dell'applicazione COM+ VB6Soap

L'applicazione viene ora pubblicata come servizio Web XML e può essere attivata tramite SOAP. Usando Internet Explorer, è possibile passare a https://localhost/VB6Soap/default.aspx, dove si troverà un collegamento ipertestuale nella pagina aspx al WSDL prodotto dal componente. Il codice VBScript seguente attiverà il componente:

set c = GetObject
   ("soap:wsdl=https://localhost/VB6Soap/VB6Soap.Calc.soap?WSDL")
for i = 1 to 10
 WScript.Echo i & " " & c.Add(i,i) & " " & Time
next

Se si sostituisce il nome del server per localhost nello script precedente, funziona altrettanto bene da un computer client remoto. Il riferimento alla pagina (in questo esempio VB6Soap.Calc.soap) è il componente ProgID seguito dal suffisso .soap.

Per accedere allo stesso endpoint tramite SOAP Toolkit che viene fornito come parte di Windows XP Professional e non usa .NET Remoting, eseguire il codice VBScript seguente:

set c = CreateObject("MSSOAP.SOAPClient")
c.mssoapinit("https://localhost/VB6Soap/VB6Soap.Calc.soap?WSDL")
for i = 1 to 10
 WScript.Echo i & " " & c.Add(i,i) & " " & Time
next

Per un approccio ancora più semplice alla pubblicazione SOAP in un server, è possibile usare Microsoft C# ™ o Visual Basic .NET e ereditare da ServicedComponent. Di seguito è riportato un esempio di codice gestito per un componente gestito semplice (questi esempi di ServicedComponent funzioneranno su .NET Server Beta 3 o versione successiva e con il candidato alla versione di .NET Framework o alla compilazione successiva. La funzionalità SoapVRoot verrà portata a Windows XP Pro in un service Pack futuro:

using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.EnterpriseServices;

[assembly: ApplicationName("CSSoap")]
[assembly: ApplicationActivation(ActivationOption.Server, 
   SoapVRoot="CSSoap")]
[assembly: AssemblyKeyFile("CSSoap.snk")]
namespace CSSoap
{
  public interface ICalc
  {
   double Add (double Value1, double Value2);
  }

  [ClassInterface(ClassInterfaceType.AutoDual)]
  [TransactionAttribute(TransactionOption.None)]
  public class Calc : ServicedComponent, ICalc
  {
   public double Add (double Value1, double Value2);
   {
      return (Value1 + Value2);
   } 
  }
}

L'aspetto interessante dell'esempio precedente è l'attributo ApplicationActivation :

[assembly: ApplicationActivation(ActivationOption.Server, 
   SoapVRoot="CSSoap")]

Dopo aver compilato questo componente C#, installarlo nella global assembly cache ed eseguire regsvcs.exe per registrarlo come applicazione COM+, viene pubblicato come radice virtuale IIS e come endpoint SOAP. Per il corretto funzionamento della comunicazione remota con servicedComponent, è anche necessario inserire questo assembly compilato nella global assembly cache (GAC) usando gacutil.exe o l'interfaccia utente di .NET Framework. Per accedere a questo endpoint SOAP tramite WSDL, usare il codice VBScript seguente:

set c = GetObject
   ("soap:wsdl=https://localhost/CSSoap/CSSoap.Calc.soap?WSDL")
for i = 1 to 10
 WScript.Echo i & " " & c.Add(i,i) & " " & Time
next

Come esempio semplice di interoperabilità SOAP, SOAP Toolkit viene fornito con Windows XP Professional e il vbScript seguente accederà all'endpoint SOAP COM+ anche se .NET Framework non è installato nel computer client che esegue Windows XP:

set c = CreateObject("MSSOAP.SOAPClient")
c.mssoapinit("https://localhost/CSSoap/CSSoap.Calc.soap?WSDL")
for i = 1 to 10
 WScript.Echo i & " " & c.Add(i,i) & " " & Time
next

Per brevità, tutti gli esempi precedenti hanno usato VBScript per accedere a questi servizi Web. Gli esempi potrebbero essere stati scritti in Visual C++, Visual Basic 6.0, Visual Basic .NET o C#, usando il moniker WSDL soap. Ad esempio, Visual Basic .NET accederà allo stesso oggetto usando codice gestito compilato, come illustrato nell'esempio seguente:

Imports System
Imports System.Runtime.InteropServices
Module WKOClient
 Sub Main()
    Dim WSDLMoniker = 
      "soap:wsdl=https://localhost/CSSoap/CSSoap.Calc.soap?WSDL"
      Dim obj as Object
   obj = Marshal.BindToMoniker(WSDLMoniker)
   Console.WriteLine(obj.Add(1,2))
 End Sub
End Module

Il punto in cui si usa VBScript consiste nel mostrare che i client gestiti o non gestiti possono accedere ai componenti COM+ pubblicati come SERVIZI Web COM+. In organizzazioni o applicazioni di grandi dimensioni, è difficile passare da tutte le parti in una sola volta. I servizi Web COM+ consentono la conversione di parti di applicazioni nel codice gestito senza richiedere una riscrittura completa immediata delle applicazioni esistenti.

Esempi di oggetti CAO (Simple Client-Activated Object)

La pubblicazione di SERVIZI Web COM+ nel server pubblica sia WKO che CAO per ogni componente, quindi non è necessaria alcuna configurazione server aggiuntiva. L'unico passaggio necessario nel server consiste nell'esportare l'applicazione COM+ come applicazione proxy dopo aver selezionato la casella di controllo Uses SOAP (nella scheda Attivazione della pagina Proprietà dell'applicazione COM+) e immettendo un valore nella casella di testo SOAP VRoot . La figura seguente illustra i passaggi necessari per esportare un'applicazione proxy:

Fare clic con il pulsante destro del mouse sull'applicazione COM+ VB6Soap nello strumento di amministrazione servizi componenti e scegliere Esporta, come illustrato nella figura 2.

Figura 2. Strumento di amministrazione di Servizi componenti
Nella Procedura guidata esportazione applicazione COM+ illustrata nella figura 3 immettere il percorso e il nome per il file di .msi proxy.

Figura 3. Procedura guidata di esportazione dell'applicazione COM+
In un computer client separato installare il file proxy .msi come applicazione COM+ predefinita.

Quando installato in un computer client, il proxy verrà configurato correttamente per accedere al server corretto e alla radice virtuale tramite SOAP. Per l'attivazione client, anziché usare il moniker WSDL, è possibile usare l'attivazione COM+ normale non gestita (CoCreateInstance, CreateObject e così via). Dopo aver creato un proxy dell'applicazione per l'esempio di calcolatore Visual Basic indicato in precedenza in un server e viene installato in un computer client separato, il codice VBScript seguente accederà al server tramite SOAP:
```
set c = CreateObject("VB6Soap.Calc")
for i = 1 to 10
 WScript.Echo i & " " & c.Add(i,i) & " " & Time
next 
```
Lo stesso codice VBScript accederebbe a un'applicazione server usando DCOM se l'applicazione proxy non disponeva di servizi Web COM+ abilitati.

Esempi di componenti transazionali

I calcolatori semplici sono piuttosto lontano dalle applicazioni aziendali pesanti, quindi il tipo di applicazione che è adatto per i componenti transazionali COM+, con pool di oggetti, sarà ora considerato.

Il componente più semplice da gestire e configurare è un componente di codice gestito derivato da ServicedComponent, come illustrato nell'esempio C# seguente(Questi esempi servicedComponent funzioneranno su .NET Server Beta 3 o versione successiva e con .NET Framework Release Candidate o versione successiva. La funzionalità SoapVRoot verrà portata a Windows XP Pro in un service Pack futuro:

using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.EnterpriseServices;
using System.Data;
using System.Data.SqlClient;

[assembly: ApplicationName("SCTrans")]
[assembly: ApplicationActivation(ActivationOption.Server, 
   SoapVRoot="SCTrans")]
[assembly: AssemblyKeyFile("SCTrans.snk")]
namespace SCTrans
{
  public interface ISCTrans
  {
   string CountUp (string Key);
  }

  [ObjectPooling(MinPoolSize=0, MaxPoolSize=25)]
  [JustInTimeActivation(true)]
  [ClassInterface(ClassInterfaceType.AutoDual)]
  [TransactionAttribute(TransactionOption.RequiresNew)]
  public class SCTransSQLNC : ServicedComponent, ISCTrans
  {
   [AutoComplete]
   public string CountUp (string Key)
   {
      _command = new SqlCommand("", _connection);
      _command.CommandType = CommandType.Text;
      _command.Connection.Open();
     _command.CommandText = "UPDATE CallCount WITH (ROWLOCK) SET 
      CallCount = CallCount + 1 WHERE Machine='" + Key + "'";
     _command.ExecuteNonQuery();
      _command.Connection.Close();
     _numcalls++;
     return (_numcalls + " NC " + _guid);
   } 

   protected override bool CanBePooled()
   {
     return true; 
   }
   private int _numcalls = 0;
   private string _guid = Guid.NewGuid().ToString();
   private SqlConnection _connection = 
   new SqlConnection("user id=MyUser;password=My!Password;
   database=SoapTest;server=MyServer");
   private SqlCommand _command; 
   
  }
}

Per compilare ed eseguire questo componente C#, dopo aver modificato i valori di connessione per connettersi al database di microsoft SQL Server ™, è necessario usare sn.exe per generare un file di chiave del nome sicuro Sctrans.snk e quindi compilarlo con riferimenti agli assembly nelle istruzioni using. L'assembly deve essere inserito nella gaC usando gacutil.exe (se si usa l'SDK) o tramite l'interfaccia utente di .NET Framework se si esegue la distribuzione in un server. È quindi necessario eseguire regsvcs.exe per registrare il componente gestito con COM+. Regsvcs.exe userà l'attributo seguente per pubblicare il componente come endpoint SOAP nel server e come attivazione non elaborata del server:

[assembly: ApplicationActivation(ActivationOption.Server, 
   SoapVRoot="CSSoapSQL")]

Questo componente richiede una nuova transazione in ogni chiamata al metodo, dispone di un singolo metodo di completamento automatico e viene configurato per il pool. Usando componenti COM+ gestiti e non gestiti, il pool di oggetti e le transazioni funzionano come previsto tramite SOAP. Ad esempio, se il vbScript seguente viene usato per accedere ai seguenti servizi ServicedComponent su SOAP:

mon = "soap:wsdl=http://jnoss3/sctrans/SCTrans.SCTransSQLNC.soap?WSDL"
WScript.Echo(mon)
for i = 1 to 2
 set c = GetObject(mon)
 for j = 1 to 10
  WScript.Echo i & " " & j & " " & c.CountUp("SCWKONC") 
 next
next

Verrà visualizzato l'output seguente:

C:\moniker>actscwko
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

soap:wsdl=http://jnoss3/sctrans/SCTrans.SCTransSQLNC.soap?WSDL
1 1 486 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 2 487 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 3 488 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 4 489 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 5 490 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 6  8 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
1 7  9 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
1 8 10 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
1 9 494 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
1 10 495 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
2 1 13 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 2 14 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 3 15 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 4 499 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
2 5 17 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 6 501 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
2 7 502 NC 6e41f32f-74be-45f0-94c0-989e7e1c5672 
2 8 19 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 9 20 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce 
2 10 21 NC af26b53b-4a1f-48c8-8880-518c2b55a7ce

Si tratta di ciò che dovrebbe essere previsto per i componenti in pool: gli oggetti vengono estratti dal pool e riutilizzati. Il comportamento per i componenti in pool che usano l'attivazione client è lo stesso.

Il pool di oggetti e le transazioni funzionano anche come previsto per i componenti non gestiti(anche se i componenti di Visual Basic 6.0 non supportano il pool di oggetti). Gli attributi di pooling e transazione devono essere impostati tramite lo strumento di amministrazione COM+ per la maggior parte delle applicazioni non gestite.

Passaggio di riferimenti

Una delle differenze principali tra i modelli WKO e CAO è la possibilità di passare riferimenti a oggetti con stato. Di seguito è riportato un esempio C# ServicedComponent che mostra le nozioni di base di questa operazione (questi esempi di ServicedComponent funzioneranno su .NET Server Beta 3 o versione successiva e con il candidato alla versione di .NET Framework o successiva. La funzionalità SoapVRoot verrà portata a Windows XP Pro in un service Pack futuro:

using System;
using System.Reflection;
using System.EnterpriseServices;
using System.Runtime.InteropServices;

[assembly: ApplicationName("RefPass")]
[assembly: ApplicationActivation(ActivationOption.Server, 
   SoapVRoot="RefPass")]
[assembly: AssemblyKeyFile("RefPass.snk")]
namespace RefPass
{
  public interface IParent
  {
    string SetRef(object inKid);
    object GetRef();
    string CountUp(object obj); 
  }

  public interface IChild
  {
    string GetValue ();
    string CountUp();
    void SetName(string key);
  }

  [ClassInterface(ClassInterfaceType.AutoDual)]
  public class Parent: ServicedComponent, IParent
  {
    protected Child _kid = null;

    public string SetRef(object inKid)
    {
      _kid = (Child)inKid;
      return _kid.GetValue();
    }

    public object GetRef()
    {
      return (object)_kid;
    }

    public string CountUp(object obj)
    {
      Child kid = (Child)obj;
      if (kid == null) return _kid.CountUp();
      else return kid.CountUp();
    }
 }

  [ClassInterface(ClassInterfaceType.AutoDual)]
  public class Child : ServicedComponent, IChild
  {
    private int _counter = 0;
    private string _name = "none";
    public string CountUp() { _counter++; return GetValue(); }
    public string GetValue() { return (_name + " " 
   +_counter.ToString()); }
    public void SetName(string key) { _name = key; }
  }
}

Questo programma C# include due classi: figlio e padre. Le differenze tra i modelli WKO e CAO sono abbastanza chiare se vengono eseguiti gli esempi VBScript seguenti:

set c1 = GetObject
   ("soap:wsdl=http://jnoss4/refpass/RefPass.Child.soap?wsdl")
set c2 = GetObject
   ("soap:wsdl=http://jnoss4/refpass/RefPass.Child.soap?wsdl")
c1.SetName("C1")
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
C2.SetName("C2")
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()

Quando viene eseguito, l'output è il seguente:

C:\moniker>refpasswko
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

none 1
none 1
none 1
none 1
none 1
none 1
none 1
none 1
none 1
none 1

Il nome e il valore illustrano la natura senza stato di singoli oggetti noti; né nomi né valori vengono mantenuti tra chiamate al metodo perché il componente viene creato con ogni chiamata al metodo.

Se un proxy client viene esportato e quindi importato in un altro computer e viene eseguito il codice VBScript seguente, l'attivazione SOAP sarà CAO anziché WKO:

'Create two objects directly
set c1=CreateObject("RefPass.Child")
set c2=CreateObject("RefPass.Child")
'Set the name of the first object, and call it several times
'to increment the object internal counter
c1.SetName("C1")
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
WScript.Echo c1.Countup()
WScript.Echo c1.CountUp()
WScript.Echo c1.Countup()
'Set the name of the first object, and call it several times
'to increment the object internal counter
c2.SetName("C2")
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()
WScript.Echo c2.Countup()
WScript.Echo c2.CountUp()
WScript.Echo c2.Countup()
'Create a parent object
set p=CreateObject("RefPass.Parent")
'Pass the child objects to the parent and call it from the parent
WScript.Echo p.SetRef(c1)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
'Now call the child object stored internally in the parent
dim c9
WScript.Echo p.CountUp(c9)
'Get the object back from the parent and call it directly
Set c3 = p.GetRef()
WScript.Echo c3.CountUp()

Quando viene eseguito dalla riga di comando, viene visualizzato l'output seguente:

C:\moniker>refpasscl
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

C1 1
C1 2
C1 3
C1 4
C1 5
C2 1
C2 2
C2 3
C2 4
C2 5
C1 5
C2 6
C2 7
C2 8
C2 9
C1 6
C1 7

L'attivazione CAO mantiene lo stato, anche quando viene chiamato su SOAP e consente di passare i riferimenti a oggetti da passare indietro e indietro su SOAP. Sia i nomi che i valori vengono conservati nelle istanze della classe nel server e i riferimenti funzionano correttamente. Entrambi questi script chiamano lo stesso componente C# compilato; differiscono solo nei modelli di attivazione remota .NET.

Oltre a richiamare le attivazioni CAO usando CreateObject, viene fornito un moniker con COM+ che fornisce l'attivazione CAO anziché WKO, ovvero il moniker typename e assembly. Lo script seguente:

'Create two objects directly
set c1=GetObject("soap:typename=RefPass.Child,assembly=RefPass")
set c2=GetObject("soap:typename=RefPass.Child,assembly=RefPass")
'Set the name of the first object, and call it several times
'to increment the object internal counter
c1.SetName("C1")
WScript.Echo c1.CountUp()
WScript.Echo c1.CountUp()
WScript.Echo c1.Countup()
WScript.Echo c1.CountUp()
WScript.Echo c1.Countup()
'Set the name of the second object, and call it several times
'to increment the object internal counter
c2.SetName("C2")
WScript.Echo c2.CountUp()
WScript.Echo c2.CountUp()
WScript.Echo c2.Countup()
WScript.Echo c2.CountUp()
WScript.Echo c2.Countup()
'Create a parent object
set p=GetObject("soap:typename=RefPass.Parent,assembly=RefPass")
'Pass the child objects to the parent and call it from the parent
WScript.Echo p.SetRef(c1)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
WScript.Echo p.CountUp(c2)
'Now call the child object stored internally in the parent
dim c9
WScript.Echo p.CountUp(c9)
'Get the object back from the parent and call it directly
Set c3 = p.GetRef()
WScript.Echo c3.CountUp()

produce l'output seguente:

C:\moniker>refpassca
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

C1 1
C1 2
C1 3
C1 4
C1 5
C2 1
C2 2
C2 3
C2 4
C2 5
C1 5
C2 6
C2 7
C2 8
C2 9
C1 6
C1 7

Si tratta dello stesso output dell'esempio di VBScript CreateObject(ProgID) usato in precedenza . Poiché il normale percorso di attivazione COM+ è intercettato per le applicazioni proxy SOAP, CoCreateInstance, CreateInstance e altri metodi di attivazione COM+ tradizionali possono essere usati per richiamare oggetti attivati dal client tramite SERVIZI Web COM+.

Il moniker assembly e typename è utile anche per ottenere la comunicazione remota preconfigurata attivata dal client da un client di codice gestito, come illustrato nell'esempio seguente:

Imports System
Imports System.Runtime.InteropServices
Module RefPassCl
Sub Main()
    Dim ChildMoniker = "soap:assembly=RefPass,typename=RefPass.Child"
    Dim ParentMoniker = "soap:assembly=RefPass,typename=RefPass.Parent"
    Dim c1,c2,p as Object
    c1 = Marshal.BindToMoniker(ChildMoniker)
    Console.WriteLine(c1.SetName("C1"))
    Console.WriteLine(c1.CountUp())
    Console.WriteLine(c1.CountUp())
    Console.WriteLine(c1.CountUp())
    Console.WriteLine(c1.CountUp())
    Console.WriteLine(c1.CountUp())
    c2 = Marshal.BindToMoniker(ChildMoniker)
    Console.WriteLine(c2.SetName("c2"))
    Console.WriteLine(c2.CountUp())
    Console.WriteLine(c2.CountUp())
    Console.WriteLine(c2.CountUp())
    Console.WriteLine(c2.CountUp())
    Console.WriteLine(c2.CountUp())
    p = Marshal.BindToMoniker(ParentMoniker)
    Console.WriteLine(p.SetRef(c1))
    Console.WriteLine(p.CountUp(c2))
    Console.WriteLine(p.CountUp(c2))
    Console.WriteLine(p.CountUp(c2))
    Console.WriteLine(p.CountUp(c2))
    Dim c9
    Console.WriteLine(p.CountUp(c9))
    Dim c3 = p.GetRef()
    Console.WriteLine(c3.CountUp())
 End Sub
End Module

La compilazione di questa applicazione .NET di Visual Basic e l'esecuzione produrrà lo stesso output dei due esempi CAO VBScript precedenti.

Poiché la pubblicazione del server pubblica il componente come CAO e WKO, la scelta del metodo di attivazione viene effettuata dal client remoto. Anche se probabilmente di solo interesse accademico, un singolo computer client può accedere alla stessa radice virtuale pubblicata da SOAP in un server remoto usando entrambi i metodi di attivazione remota per lo stesso componente.

Limitazioni e differenze di SOAP e DCOM

Uno degli obiettivi della comunicazione remota .NET è fornire un ambiente distribuito avanzato in cui uno sviluppatore può combinare e associare protocolli di serializzazione (formattatori) ai protocolli di rete (canali). COM+ Web Services nella versione 1.0 di .NET Framework supporta solo un formattatore (SOAP) e un canale (HTTP). Ciò non significa che altri canali e formattatori non funzionino con ServicedComponents o COM+, ma che non esiste alcuna configurazione automatica per fornire endpoint client e server per questi canali e formattatori alternativi.

Un numero enorme di componenti COM+ sono stati scritti usando un'ampia gamma di lingue. Sarebbe ideale se tutti questi componenti potrebbero essere abilitati come servizi Web tramite SERVIZI Web COM+. Come per .NET Framework versione 1.0, non tutti i componenti COM esistenti funzioneranno con i servizi Web COM+ . Anche se la maggior parte dei componenti esistenti con librerie di tipi deve funzionare abbastanza bene, alcuni componenti, ad esempio Windows Script Components (WSC), non sono supportati in questa versione. Alcune librerie di tipi complessi in cui le interfacce hanno più livelli di ereditarietà o dipendono da più librerie di tipi, potrebbero non funzionare correttamente. Inoltre, a causa delle limitazioni della conversione della libreria dei tipi, solo l'interfaccia predefinita in una libreria dei tipi sarà disponibile come servizio Web.

COM+ Web Services non è una soluzione completa per ogni componente COM+ non gestito esistente. Esiste un numero molto elevato di componenti COM+ non gestiti esistenti scritti in un'ampia gamma di linguaggi di programmazione. Non è possibile testare tutte le possibili librerie di tipi generate da ogni compilatore che supporta COM+, pertanto alcuni componenti COM+ non gestiti non verranno pubblicati correttamente usando i servizi Web COM+. Uno degli obiettivi di COM+ Web Services è ridurre al minimo il tempo e gli sforzi necessari per effettuare questa valutazione. È sufficiente pubblicare il componente COM+ non gestito come servizio Web COM+ e lo sviluppatore può determinare rapidamente se si verificano problemi con l'uso previsto come servizio Web. Se si verificano problemi, esistono diverse alternative che possono essere usate con componenti non gestiti esistenti. Queste alternative includono la scrittura di wrapper gestiti o non gestiti che forniscono un'interfaccia compatibile che può essere pubblicata come servizio Web. Nella maggior parte dei casi, la scrittura di un wrapper è molto meno lavoro rispetto alla riscrittura di un intero componente. Questo riduce al minimo lo sforzo di sviluppo e test per inserire un'applicazione in produzione come servizio Web XML.

Quando si usano server non gestiti (Visual Basic 6.0 o Visual C++), con applicazioni client gestite e SOAP, l'associazione anticipata funziona in genere meglio dell'associazione tardiva. In alcuni casi, i metadati generati potrebbero non funzionare correttamente quando vengono usati come proxy di comunicazione remota tra computer con associazione tardiva.

Nell'area di autenticazione dell'uso del formattatore SOAP su HTTP, a seconda dell'ambiente di distribuzione di destinazione, è comunque possibile usare diverse opzioni. COM+ Web Services genera file di configurazione remoti basati su XML sia per le configurazioni client DEL server che per le configurazioni client CAO. I riferimenti URL per le attivazioni WKO sono incorporati nel proxy client generato, quindi non è necessario alcun file di configurazione. COM+ Web Services genera file di configurazione semplici e funzionali che possono essere personalizzati dall'utente per soddisfare qualsiasi esigenza oltre alla comunicazione SOAP semplice tramite HTTP. Le aree che possono essere personalizzate includono l'autenticazione utente, come nell'esempio seguente:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.runtime.remoting>
  <application>
   <service>
    <wellknown mode="SingleCall" type="SCTrans.SCTransSQL, SCTrans, 
      Version=0.0.0.0, Culture=neutral, 
      PublicKeyToken=9c6052078b454cee" 
      objectUri="SCTrans.SCTransSQL.soap" />
    <activated type="SCTrans.SCTransSQL, SCTrans" />
   </service>
  </application>
 </system.runtime.remoting>
 <identity impersonate="true" />
</configuration>

L'aggiunta della riga evidenziata in precedenza determina l'uso dell'identità utente nell'attivazione dei componenti COM+ quando viene chiamato su SOAP. Per impostazione predefinita, la radice virtuale IIS usa l'autenticazione IIS standard. Ciò consente l'uso del partizionamento COM+ (una funzionalità COM+ Windows Server 2003) con SOAP, in cui l'implementazione effettiva del componente richiamata può variare in base all'identità dell'utente.

Un'altra area che può essere personalizzata include la gestione della durata per gli oggetti attivati dal client, come nell'esempio seguente:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.runtime.remoting>
  <application>
   <service>
    <wellknown mode="SingleCall" type="SCTrans.SCTransSQL, SCTrans, 
      Version=0.0.0.0, Culture=neutral, 
      PublicKeyToken=9c6052078b454cee" 
      objectUri="SCTrans.SCTransSQL.soap" />
    <activated type="SCTrans.SCTransSQL, SCTrans" />
   </service>
   <lifetime leaseTime="30S" renewOnCallTime="30S" />
  </application>
 </system.runtime.remoting>
</configuration>

L'aggiunta della riga evidenziata al file di web.config modificherà la durata degli oggetti attivati dal client in questa VRoot iis da 6 minuti a 30 secondi. Se si modifica l'attributo SingleCall dell'elemento wellknown in Singleton , il comportamento di attivazione verrà modificato in modo da instradare tutte le chiamate di metodo in ingresso a una singola istanza di un componente anziché attivare un nuovo componente in ogni chiamata al metodo.

La comunicazione remota .NET (come il resto di .NET Framework) supporta l'operazione di Garbage Collection anziché il conteggio dei riferimenti. Ciò significa che in alcune situazioni i componenti COM+ transazionali non gestiti si comportano in modo diverso usando i servizi Web COM+ rispetto all'uso di DCOM. Per un metodo transazionale pubblicato tramite una singola chiamata WKO, è essenziale chiamare o eseguire automaticamente SetComplete selezionando la casella di controllo Disattiva automaticamente questo oggetto quando questo metodo restituisce la pagina delle proprietà del metodo componente. Ciò è essenziale perché, finché il componente non viene sottoposto a Garbage Collection, il componente non verrà rilasciato. Quando si usa DCOM, il conteggio dei riferimenti determina in genere il commit o l'interruzione della transazione quando il componente viene rilasciato anche se questa regola viene ignorata. Quando si passa all'ambiente dei servizi Web COM+, questa operazione non è garantita prima del timeout della transazione in un ambiente di Garbage Collection. Un errore durante la chiamata a SetComplete o per configurare il metodo per il completamento automatico si manifesterà in un errore intermittente di commit delle transazioni perché si verifica un timeout prima che il componente venga sottoposto a Garbage Collection.

Considerazioni sulla progettazione

In Servizi Web COM+, quando viene selezionata la casella di controllo Usa SOAP (tramite lo strumento di amministrazione di Servizi componenti), vengono esposti due modelli di attivazione diversi in una radice virtuale IIS: WKO e CAO. Quale è meglio e quale è consigliabile usare?

Il modello di attivazione con chiamata singola WKO sembra molto costoso. Con ogni chiamata al metodo viene creato un nuovo componente, la chiamata al metodo eseguita e il componente inviato al Garbage Collector. Tuttavia, nelle aree in cui le prestazioni sono critiche e dove WKO è il modello corretto per il processo aziendale a portata di mano, ServicedComponents o componenti C++ non gestiti in pool ridurranno gran parte dell'elaborazione delle attivazioni di singole chiamate. Quando vengono utilizzati componenti in pool, un oggetto viene recuperato dal pool quando viene attivata l'attivazione WKO, viene eseguita la chiamata e l'oggetto viene restituito al pool. La natura senza stato di questo protocollo e l'uso del pooling migliorano il potenziale per una maggiore scalabilità. In una singola chiamata WKO in cui l'oggetto non è in pool, la durata dell'oggetto è solo per la durata della chiamata.

CAO, d'altra parte, offre il vantaggio delle prestazioni di una singola attivazione nel server e la comunicazione continua con quella singola istanza di un componente. L'overhead di attivazione viene evitato in più chiamate di metodo da un client a un server. Se il componente server ( componente C++ ServicedComponent o non gestito) viene inserito in pool, un oggetto viene recuperato dal pool e quindi restituito al pool al termine della chiamata al metodo. Se l'oggetto non è in pool, la durata dell'oggetto dipende dalla durata del lease specificata nel file web.config o viene impostata a livello di codice dal componente stesso. La durata è importante perché il Garbage Collector non rilascia la memoria per un componente fino alla scadenza della durata. In una configurazione CAO con volume elevato, ciò comporterà alcune decisioni di progettazione da parte di uno sviluppatore.

Sotto le copertine

Se si vuole solo pubblicare o utilizzare un servizio Web usando i servizi Web COM+, è possibile interrompere la lettura qui. Se, tuttavia, si vuole personalizzare, estendere o semplicemente comprendere il processo usato, continuare a leggere. Le informazioni seguenti non sono necessarie per usare questa funzionalità, ma potrebbero essere utili se si desidera estendere manualmente le funzionalità. I servizi Web COM+ sono un wrapper semplice, su un set molto completo di servizi offerti dalla comunicazione remota .NET che può essere facilmente esteso da uno sviluppatore o da un amministratore.

Radici virtuali iis server

Per fare in modo che questa funzionalità funzioni, non sono stati aggiunti hook nascosti alla comunicazione remota .NET. Invece, il codice COM+ è stato scritto per eseguire la configurazione necessaria per pubblicare endpoint COM+ come radici virtuali IIS. Nel server questo comporta la creazione di una directory fisica da usare come radice virtuale e la generazione di un file web.config per rendere i componenti accessibili tramite comunicazione remota. Se il componente non è gestito (Visual C++ o Visual Basic 6.0), vengono generati anche metadati proxy in modo che la comunicazione remota possa accedere al componente. Se la directory di sistema di Windows XP è c:\windows, i file di configurazione del server e tutti i metadati generati si trovano nell'albero di directory seguente:

C:\windows\system32\com\SoapVRoots\vrootname\

I file generati seguenti vengono inseriti in questa directory quando viene pubblicato un endpoint SOAP nel server:

web.config Il file di configurazione della comunicazione remota di base per vroot, che include diverse opzioni che possono essere aggiunte o modificate dallo sviluppatore o dall'amministratore di sistema per ottimizzare le prestazioni e la sicurezza della comunicazione remota.
default.disco Un file che può essere usato con Visual Studio .NET per generare un riferimento al servizio Web pubblicato se si sviluppa un client di codice gestito. Questo è particolarmente utile in un caso extranet in cui i partner vogliono sviluppare i propri clienti.
default.aspx Una pagina semplice di Microsoft ASP.NET che pubblica ogni componente come collegamento ipertestuale.

Tutti i file precedenti vengono generati per impostazione predefinita. Per rimuovere alcune di queste funzionalità, è sufficiente modificare o eliminare il file appropriato. Se si elimina il file web.config, tuttavia, tutte le pubblicazioni SOAP dalla radice virtuale IIS verranno arrestate.

Tutti i metadati generati vengono inseriti nella directory seguente e nella GAC:

C:\windows\system32\com\SoapVRoots\vrootname\bin

In .NET Remoting la directory bin è una posizione speciale. Quando una richiesta HTTP viene inviata a IIS, gli assembly verranno cercati in questa directory, quindi in molti casi la pubblicazione nella directory bin è l'unico passaggio necessario. Quando si pubblica un endpoint SOAP, tuttavia, l'assembly generato viene inserito anche nella GAC. Ciò è dovuto al fatto che l'ambito della risoluzione dell'assembly per una radice virtuale è limitato alla directory bin e alla GAC. Se il codice passa un riferimento a un oggetto da una radice virtuale a un'altra nello stesso computer, la risoluzione del riferimento nella radice virtuale di destinazione avrà esito negativo a meno che l'assembly non si trova nella GAC. Se si usano metadati generati per i componenti Visual Basic 6.0 o Visual C++ non gestiti, è possibile rimuovere l'assembly generato dalla GAC se non si passano riferimenti.

Una nota importante su .NET Framework in questa versione è che se un assembly viene caricato e System.Reflection viene usato per accedere al file di assembly, il file verrà bloccato in memoria fino al termine del processo. La reflection viene usata quando WSDL viene generato in modo dinamico per la generazione di un proxy, quindi per una radice virtuale IIS attiva a cui si accede dai processi client, è possibile che i file di assembly vengano bloccati. È improbabile che si presenti un problema in un ambiente di produzione, ma per uno sviluppatore che cambia spesso un componente, è qualcosa che deve essere tenuto presente.

Se si usano ServicedComponents con i servizi Web COM+, è anche necessario che l'assembly si trovi nella GAC, a meno che non si inserisca originariamente l'assembly nella directory bin ed esegua regsvcs.exe nell'assembly in tale directory. Se è stato caricato Microsoft .NET Framework SDK, è possibile usare l'utilità della riga di comando gacutil.exe per inserire servicedComponent nella GAC. Se Si dispone di Windows Server 2003 con .NET Framework predefinito o se è stato caricato .NET Framework ridistribuibile in un computer Windows XP, è possibile usare l'interfaccia utente di Configurazione di Microsoft .NET Framework, accessibile dal menu Strumenti di amministrazione , per aggiungere un assembly alla GAC.

Inoltre, quando si usa Windows XP o Windows Server 2003, assicurarsi che IIS sia installato e configurato per fornire ASP.NET servizi dell'applicazione. Queste impostazioni sono necessarie per fornire il contenuto dinamico necessario per usare SOAP.

Cache assembly proxy generata

Per pubblicare un componente COM+ non gestito tramite .NET Remoting come endpoint SOAP, è necessario generare un proxy per rendere disponibili i componenti non gestiti per .NET Framework. Questa operazione viene eseguita a livello di codice eseguendo gli stessi passaggi di tlbimp.exe, lo strumento .NET Framework SDK usato per convertire librerie di tipi COM+ non gestite in assembly di metadati proxy. Affinché l'attivazione del client su SOAP abbia esito positivo, tuttavia, i computer client e server devono condividere gli stessi proxy di metadati firmati con nome sicuro. Per questo motivo, quando viene generato un assembly proxy gestito per un componente COM+ non gestito, viene generata anche una chiave con nome sicuro e usata per firmare l'assembly proxy.

Una chiave con nome sicuro può essere generata una sola volta e non esiste alcun concetto di chiave con nome sicuro nei componenti COM+ non gestiti. Ciò significa che se si genera il proxy più volte, si creano chiavi con nome sicuro diverse. Ciò avrebbe effetto sulla creazione di identità gestite separate per lo stesso componente COM+ non gestito. Per ridurre al minimo gli effetti di questo problema, tutti gli assembly proxy generati per i componenti COM+ non gestiti vengono scritti anche nella directory SoapCache seguente:

C:\windows\system32\com\SoapCache\componentdirectory\proxymetdata.dll

dove componentdirectory è del formato:

ATLTrans.dll_40960_2001_6_27_15_4_16

Il nome della directory viene creato da nome file, dimensioni file e data e ora dell'ultima compilazione. Questo schema si basa sul presupposto che quando un componente COM+ non gestito viene ricompilato, deve avere un nuovo proxy generato. Ciò, a sua volta, si basa sul presupposto che il codice venga ricompilato negli ambienti di produzione solo quando sono state apportate modifiche.

Questa directory SoapCache esiste in modo che, se lo stesso componente non gestito viene pubblicato in un'altra radice virtuale nello stesso computer, anziché generare un assembly proxy, quello nella cache verrà riutilizzato. Ciò consente di garantire che la firma del nome sicuro (e quindi l'identità) del componente venga condivisa tra le radici virtuali.

Se si esporta un componente COM+ non gestito abilitato per SOAP come applicazione server e lo si importa in un altro server, i metadati proxy memorizzati nella cache verranno trasportati, in modo che server diversi possano condividere la stessa identità gestita per assembly non gestiti identici. In alternativa, per generare o scrivere e firmare il proprio proxy, gli utenti possono semplicemente inserire i metadati nella directory cache appropriata e verranno usati quando si verifica la pubblicazione SOAP nel server. La regola di base è che, per evitare la proliferazione non necessaria di proxy firmati per lo stesso proxy componente non gestito, gli assembly non vengono mai generati se è possibile usare un file dalla cache.

Configurazione del client

L'impianto idraulico è necessario anche sul lato client. Il caso più semplice (almeno in termini di impegno dell'utente) è il primo programma di esempio fornito in questo articolo:

set SoapObj = 
   GetObject("soap:wsdl=http://www.xmethods.net/sd
                   /TemperatureService.wsdl")
WScript.Echo "Fairbanks  Temperature = " & SoapObj.getTemp("99707")

Quando viene elaborato il moniker WSDL, vengono eseguiti i passaggi seguenti:

Viene eseguito un controllo per verificare se un proxy è stato generato per questo URL in precedenza. In tal caso, viene usato di nuovo. (Andare al passaggio 4.
Se il controllo ha esito negativo, il linguaggio WSDL viene recuperato dall'URL e viene generato un programma proxy C#, usando essenzialmente la stessa logica usata dall'utilità della riga di comando soapsuds.exe fornita con .NET Framework SDK.
Il programma C# viene compilato in una DLL e dato un nome corrispondente all'URL (con caratteri non validi convertiti in caratteri accettabili in un nome file).
Il proxy generato viene quindi usato per comunicare tramite .NET Remoting (WKO) al server remoto specificato in WSDL.

Questi proxy vengono generati e archiviati nella cartella seguente:

C:\windows\system32\com\SoapAssembly\

Nel caso dell'attivazione client, nel computer client è necessaria un'importazione proxy client di un'applicazione COM+ esportata. L'esportazione/importazione dell'applicazione consente di eseguire gli assembly di metadati firmati dal server necessari per l'attivazione del client. Durante il processo di importazione, vengono generati anche i file di configurazione e inseriti nella directory SoapAssembly. Un tipico file di configurazione client ha il formato seguente:

<configuration>
 <system.runtime.remoting>
  <application>
   <client url="http://MyServer/VB6Soap">
    <activated type="VB6SoapSoapLib.CalcClass, VB6SoapSoapLib"/>
   </client>
  </application>
 </system.runtime.remoting>
</configuration>

I servizi Web COM+ leggono questo file di configurazione prima di attivare il componente, quindi il modello di attivazione potrebbe essere potenzialmente modificato nei computer client modificando o sostituendo questo file di configurazione.

Un inizio, non un finale...

I servizi Web COM+ sono stati progettati con l'obiettivo di semplificare alcuni passaggi per combinare .NET Remoting con i servizi COM+ inclusi in Windows XP e nella famiglia Windows Server 2003. Non è stato progettato per includere ogni opzione o coprire qualsiasi emergenza utente, ma piuttosto per semplificare le attività comuni. In modo simile all'uso di una procedura guidata per creare un programma in Visual Studio .NET, alcune attività avanzate vengono lasciate all'utente. Per consentire l'estendibilità dell'utente, gli elementi generati vengono raramente eliminati completamente. Inoltre, le classi XML vengono usate per modificare i file di configurazione generati e, se sono già presenti file di configurazione, i nodi verranno aggiunti ed eliminati da essi in risposta alle modifiche apportate dallo strumento di amministrazione del servizio componenti o da Microsoft COM+ Administration SDK. I servizi Web COM+ sono progettati per semplificare l'estensione o la personalizzazione di ciò che è stato generato da un utente.

In sintesi, i servizi Web COM+ offrono un'introduzione semplice ai servizi Web XML e SOAP per i componenti COM+ esistenti di Visual Basic e Visual C++ e per i nuovi servicedComponent gestiti scritti in Visual Basic .NET e C#.

Last updated on 2007-04-05

Condividi tramite