Eines der wichtigsten Bestandteile des HAF ist das Providermodell zur Kommunikation mit dem Hostsystem. Das Providermodell sorgt dafür, dass bei der Entwicklung keine Rücksicht auf den Host und die Art der Kommunikation genommen werden muss. Zur Kommunikation mit Hostsystemen stehen mehrere Provider zur Verfügung (auch die Entwicklung eigener Provider ist problemlos möglich). Diese können später ohne Änderungen am Code getauscht werden. Somit ist es nicht mehr nötig sich auf eine Art der Kommunikation festzulegen. Dies ermöglicht es, bei einer kleinen Installation einen kostengünstigen Provider und bei einer sehr großen Installation einen Provider, der für solche Szenarien ausgelegt ist (z.B. Microsoft Host Integration Server Provider), zu nutzen.

Für clientseitige Aufrufe wird ein DataAccess-Layer (DAL) und ein BusinessRules-Layer (BRL) generiert. Der generierte Code arbeitet intern ausschließlich mit den Interfaces des Providermodells. Somit ist sichergestellt, dass es ohne Änderungen am Code möglich ist, den Provider zu wechseln.

Bei der Entwicklung des HAF stand die Flexibilität für dessen Benutzer immer im Vordergrund. Daher erstellt der Codegenerator des HAF u. a. für alle Klassen immer zwei Dateien – eine für den generierten Code und eine für den manuell implementierbaren Code. Somit ist es möglich, das Ergebnis auf allen Ebenen manuell anzupassen und beim nächsten Generierungslauf nichts von den manuellen Änderungen zu verlieren.

Um eine Funktion für ein Hostsystem aufrufbar zu machen wird im ersten Schritt die Schnittstelle der Funktion (Parameter, Typen, Längen etc.) im Host Abstractor definiert. Dieser generiert daraus ein .NET-Interface mit der gleichen Struktur. Dieses Interface kann dann in einer .NET-Assembly implementiert und auscodiert werden.

Die erstellte .NET-Assembly wird anschließend von der HAF-Runtime für Host Initiated Processing gehostet. Das HAF stellt hierfür bereits einen Windowsdienst bereit. Die Runtime kann aber auch mit sehr wenig Aufwand in einer eigenen Anwendung gehostet werden.

Hostseitige Aufrufe werden ebenfalls über ein Providermodell abgewickelt, denn jedes Backendsystem arbeitet etwas anders. In der Regel stellen Provider für Host Initiated Processing auch ein PlugIn für den Host Abstractor bereit, mit dessen Hilfe das Hostsystem für die Verwendung der windowsseitigen Funktionen vorbereitet werden kann. Der HIP-Provider für AS/400-Systeme erweitert z. B. den Host Abstractor um die Funktionalität für jede windowsseitige Funktion ein entsprechendes RPG-Programm zu generieren.

In manchen Szenarien (s. Beispiel 1+2) gestaltet sich der direkte Einsatz eines Providers als unmöglich. Für diese Fälle stellt das HAF sogenannte Provider-Gateways bereit, die die Kommunikation mit dem Host „umleiten“. Ein solches Gateway stellt nach außen die gleiche Schnittstelle bereit wie jeder andere Provider. Intern werden die Aufrufe, die das Gateway empfängt, an einen „echten“ Provider weitergereicht.

Das HAF beinhaltet standardmäßig zwei Gateways:

  • Remoting (Windowsdienst)
  • Webservice

Beispiel 1: Sie möchten eine Anwendung für Windows Mobile erstellen, die Funktionen des Hostsystems nutzen soll. Leider gibt es für diese Plattform derzeit keinen Provider, da diese in der Regel 32-Bit API’s nutzen. Der im HAF integrierte Proxy-Provider (leitet Anfragen an ein Gateway weiter) ist allerdings auch für Compact Framework verfügbar. Ein zentrales Gateway setzt diese Aufrufe dann mit Hilfe eines „echten“ Providers um.

Beispiel 2: Sie möchten Hostaufrufe durch eine Firewall mit Contentscan realisieren. Auch hier empfiehlt sich der Einsatz des Proxi-Providers zusammen mit dem Webservice-Gateway. In dieser Konstellation läuft die Kommunikation zwischen Client und Gateway über XML, das die Firewall prüfen kann.