Hosting w Usłudze aktywacji procesów systemu Windows
Usługa aktywacji procesów systemu Windows (WAS) zarządza aktywacją i okresem istnienia procesów roboczych zawierających aplikacje hostujące usługi Windows Communication Foundation (WCF). Model procesów WAS uogólnia model przetwarzania usług IIS 6.0 dla serwera HTTP, usuwając zależność od protokołu HTTP. Dzięki temu usługi WCF mogą używać protokołów HTTP i innych niż HTTP, takich jak Net.TCP, w środowisku hostingu obsługującym aktywację opartą na komunikatach i umożliwia hostowanie dużej liczby aplikacji na danej maszynie.
Aby uzyskać więcej informacji na temat tworzenia usługi WCF działającej w środowisku hostingu WAS, zobacz Instrukcje: hostowanie usługi WCF w programie WAS.
Model procesów WAS udostępnia kilka funkcji, które umożliwiają hostowanie aplikacji w sposób, który jest bardziej niezawodny, bardziej zarządzany i który wykorzystuje zasoby wydajniej:
Aktywacja oparta na komunikatach aplikacji i aplikacji procesów roboczych jest uruchamiana i zatrzymywana dynamicznie w odpowiedzi na przychodzące elementy robocze odbierane przy użyciu protokołów sieciowych HTTP i innych niż HTTP.
Niezawodne odtwarzanie aplikacji i procesów roboczych w celu utrzymania kondycji uruchomionych aplikacji.
Scentralizowana konfiguracja aplikacji i zarządzanie nimi.
Umożliwia aplikacjom korzystanie z modelu procesów usług IIS bez konieczności wdrażania pełnej instalacji usług IIS.
System Windows Server AppFabric współpracuje z usługami IIS 7.0 i Usługą aktywacji procesów systemu Windows (WAS), aby zapewnić rozbudowane środowisko hostingu aplikacji dla usług NET4 WCF i WF. Te korzyści obejmują zarządzanie cyklem życia procesów, recykling procesów, hosting udostępniony, szybką ochronę przed awariami, oddzielonie procesów, aktywację na żądanie i monitorowanie kondycji. Aby uzyskać szczegółowe informacje, zobacz AppFabric Hosting Features and AppFabric Hosting Concepts (Funkcje hostingu appFabric i pojęcia dotyczące hostingu appFabric).
Elementy modelu adresowania WAS
Aplikacje mają adresy uniform Resource Identifier (URI), które są jednostkami kodu, których okres istnienia i środowisko wykonywania są zarządzane przez serwer. Pojedyncze wystąpienie serwera WAS może być domem dla wielu różnych aplikacji. Serwery organizują aplikacje w grupy nazywane witrynami. W obrębie lokacji aplikacje są rozmieszczane w sposób hierarchiczny, który odzwierciedla strukturę identyfikatorów URI, które pełnią rolę ich adresów zewnętrznych.
Adresy aplikacji mają dwie części: podstawowy prefiks identyfikatora URI i specyficzny dla aplikacji adres względny (ścieżka), który udostępnia adres zewnętrzny dla aplikacji po połączeniu ze sobą. Prefiks podstawowego identyfikatora URI jest tworzony na podstawie powiązania lokacji i jest używany dla wszystkich aplikacji w lokacji. Następnie adresy aplikacji są tworzone przez pobranie fragmentów ścieżki specyficznych dla aplikacji (takich jak "/applicationOne") i dołączenie ich do podstawowego prefiksu identyfikatora URI (na przykład "net.tcp://localhost"), aby uzyskać pełny identyfikator URI aplikacji.
W poniższej tabeli przedstawiono kilka możliwych scenariuszy adresowania dla lokacji WAS z powiązaniami lokacji HTTP i innych niż HTTP.
| Scenariusz | Powiązania witryny | Application path | Podstawowe identyfikatory URI aplikacji |
|---|---|---|---|
| Tylko HTTP | http: *:80:* | /appTwo | http://localhost/appTwo/ |
| Zarówno HTTP, jak i inny niż HTTP | http: *:80:* net.tcp: 808:* |
/appTwo | http://localhost/appTwo/net.tcp://localhost/appTwo/ |
| Tylko bez protokołu HTTP | Net.pipe:* | /appThree | net.pipe://appThree/ |
Usługi i zasoby w aplikacji można również rozwiązać. W aplikacji zasoby aplikacji są adresowane względem podstawowej ścieżki aplikacji. Załóżmy na przykład, że lokacja na nazwie komputera, contoso.com ma powiązania lokacji dla protokołów HTTP i Net.TCP. Załóżmy również, że witryna zawiera jedną aplikację znajdującą się w lokalizacji /Billing, która uwidacznia usługę w witrynie GetOrders.svc. Następnie, jeśli usługa GetOrders.svc uwidoczniła punkt końcowy z względnym adresem SecureEndpoint, punkt końcowy usługi zostanie uwidoczniony w następujących dwóch identyfikatorach URI:
http://contoso.com/Billing/GetOrders.svc/SecureEndpointnet.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
Środowisko uruchomieniowe WAS
Aplikacje są zorganizowane w lokacje na potrzeby adresowania i zarządzania. W czasie wykonywania aplikacje są również grupowane w pule aplikacji. Pula aplikacji może pomieścić wiele różnych aplikacji z wielu różnych witryn. Wszystkie aplikacje w puli aplikacji mają wspólny zestaw cech czasu wykonywania. Na przykład wszystkie są uruchamiane w tej samej wersji środowiska uruchomieniowego języka wspólnego (CLR) i mają wspólną tożsamość procesu. Każda pula aplikacji odpowiada wystąpieniu procesu roboczego (w3wp.exe). Każda zarządzana aplikacja działająca wewnątrz udostępnionej puli aplikacji jest odizolowana od innych aplikacji za pomocą domeny aplikacji CLR.