Client/Server-Interaktion

  • Artikel

Veröffentlicht: 15. Sep 2000 | Aktualisiert: 17. Jun 2004

Ihr Server arbeitet nicht allein. Verteilte Anwendungen erfordern bestimmte Verwaltungstasks einschließlich, aber nicht beschränkt auf, Bandbreite, Datenbanken, Clientlizenzen, Transaktionen, Speicherpartitionierung, Zwischenspeicherung usw.

Auf dieser Seite

Verwenden Sie XML-Zeichenfolgen oder Recordsets zum Austauschen von Daten zwischen Schichten Verwenden Sie XML-Zeichenfolgen oder Recordsets zum Austauschen von Daten zwischen Schichten
Übergeben Sie keine Clientobjektverweise an den Server  Übergeben Sie keine Clientobjektverweise an den Server
Deklarieren Sie XML-Funktionen und -Parameter als Zeichenfolgen und nicht als XML-Objekte Deklarieren Sie XML-Funktionen und -Parameter als Zeichenfolgen und nicht als XML-Objekte
Stellen Sie sicher, dass Sie Eigenschaftswerte und nicht Objekte als Parameter übergeben Stellen Sie sicher, dass Sie Eigenschaftswerte und nicht Objekte als Parameter übergeben

Verwenden Sie XML-Zeichenfolgen oder Recordsets zum Austauschen von Daten zwischen Schichten

Das Verschieben von Daten zwischen den Schichten ist eine der schwierigsten Aufgaben beim Erstellen von n-tier-Architekturen unter Verwendung von Windows DNA. Es gibt viele Verfahren zum Senden und Empfangen von Daten zwischen Client und Server, z.B. das Analysieren von XML-Zeichenfolgen oder Recordsetobjekten. Es folgt eine Liste der allgemeinen Verfahren sowie deren Vor- und Nachteile.

Besonders beliebt bei Programmierern sind getrennte ADO-Recordsets, jedoch erfreuen sich auch die XML-Zeichenfolgen einer zunehmenden Beliebtheit. In der Praxis stellten sich die XML-Zeichenfolgen für Windows DNA 2000-Anwendungen als die geeignetste Methode heraus. Die Gründe hierfür sind ihre zunehmende Verwendung, die industrieweite Umstellung auf HTTP- und Webdienste sowie die Effizienz und Flexibilität dieser Methode.

XML-Zeichenfolgen

Sie erhalten XML-Zeichenfolgen, indem Sie das ADODB.Stream-Objekt zum Speichern eines Recordsets verwenden, XML DOM-Objekte einsetzen oder eine Zeichenfolge manuell über VB verketten.

Übertragen Sie XML in beide Richtungen als einfache Zeichenfolge, nicht als XML DOM-Objekte oder ADODB.Stream-Verweise. Verwenden Sie wenn möglich ByVal, um unnötiges Vor- und Zurückmarshalling zu vermeiden, insbesondere bei der Verarbeitung großer Dokumente.

Der entscheidende Faktor beim Erstellen schneller, von MSXML abhängiger Middle-tier-Komponenten oder -Anwendungen ist die Verwendung möglichst kleiner und einfacher Dokumente. Ab einem bestimmten Punkt ist die Beziehung zwischen der Leistung und der Dokumentgröße nicht einmal mehr linear, und die Größe der verwendeten XML-Dokumente scheint entscheidenden Einfluss auf die Schnelligkeit von Anwendungen zu haben.

Vorteile:

  • Keine Verbindung zum Datenbank- und Anwendungsserver

  • Kann in Dateien, MSMQ-Nachrichten usw. aufrechterhalten werden bzw. daraus geladen werden

  • Leistungsfähige und neue Navigationssemantik

  • Einfache Transformation in verschiedene Strukturen mit XSL

  • Metadaten

  • Bei korrekter Strukturierung können sie als Recordsets geöffnet werden

  • Leicht erweiterbar

  • Einfache Integration in ASP- und HTML-Anwendungen

  • Geringe Leistungsbeeinträchtigung bei der Extrahierung aus ADO-Recordsets

  • Einfache Einbindung in Schema-/Datenvalidierungsframeworks

  • Einfache Integration in XML-basierte Dienste, z.B. BizTalk

Nachteile:

  • Geringe Anzahl von Steuerelementen für die Benutzeroberfläche, die an XML gebunden bzw. direkt über XML initialisiert werden können (aber die Anzahl nimmt zu)

  • Schwierige Bearbeitung – im Vergleich zu einem Array vom Typ Variant sind viele Schritte erforderlich, um eine bestimmte Menge von Daten aus einem XML-Dokument zu extrahieren

  • Kann bei großen Dokumenten die Zeichenfolgenverwaltung von Visual Basic belasten, wenn Sie viele manuelle Verkettungen durchführen

Getrennte ADO-Recordsets

Das Verwenden von ADO-Recordsets ist ein beliebtes Verfahren zur Datenübertragung. Die Vorteile der ADO-Recordsets wiegen normalerweise deren Nachteile auf, und die Einfachheit ihrer Entwicklung prädestiniert sie als eine schnelle und produktive Strategie.

Vorteile:

  • Keine Verbindung zum Datenbank- und Anwendungsserver

  • Kann in Dateien, MSMQ-Nachrichten usw. aufrechterhalten werden bzw. daraus geladen werden

  • Verfügt über eine gängige Navigationssemantik

  • Verfügt über Spaltenmetadaten (Verweis nach Name und Position)

  • Ermöglicht das Verwenden von datengebundenen Steuerelementen in Windows-Clients

  • Einfache Bearbeitung innerhalb der Geschäftsregelschichten

  • Kann so bearbeitet werden, dass die XML-Darstellung direkt in eine ASP-Seite ausgegeben wird

Nachteile:

  • Ist davon abhängig, dass ADO auf einem Client und Server bereitgestellt wird, es muss sich dabei aber nicht unbedingt um dieselbe Version handeln

  • Kann nur schwer um zusätzliche Informationen erweitert werden

Arrays vom Typ "Variant"

Obwohl sich die Arrays vom Typ Variant früher großer Beliebtheit erfeuten, wurden sie schnell von den XML-Zeichenfolgen abgelöst.

Vorteile:

  • Schnelle Erlernbarkeit und Bearbeitung auch ohne ADO-Kenntnisse

  • Flexibles Schema, keine enge Bindung an ein Schema mit fixierten Attributen und Datentypen

  • Einfache Übergabe nach Wert

Nachteile:

  • Nicht effizient bei der Leitungsübertragung, manchmal sind 50 Prozent mehr Pakete als für XML-Zeichenfolgen und weitaus mehr Pakete als für ein nach Wert gemarshalltes Recordset erforderlich

  • Das Abrufen eines Recordsets ist kostenaufwendig – ein GetRows-Aufruf kann, je nach Eigenschaften des Recordsets, erheblich länger dauern als das Abrufen einer XML-Zeichenfolge über ein ADODB.Stream-Objekt

  • Die Identifizierung von Spalten erfolgt über einen Index: Durch eine andere Anordnung von Spalten in einer SELECT-Anweisung kann ein Array mit einem ungeeigneten Layout dargestellt werden. Dieses Feature kann sich positiv oder negativ auf die Verwaltbarkeit auswirken, je nachdem, wie flexibel Ihre Komponenten und Ihre Benutzeroberfläche auf sich ändernde Bedingungen reagieren

  • Keine intrinsischen Metadaten (keine Feldnamen, Typen usw.), die sich negativ auf die Laufzeitflexibilität auswirken könnten

  • Einfache Änderungsfunktionen, z.B. Filtern, Sortieren usw.

Zu den weniger häufig verwendeten Optionen gehören:

  • Inhalt von Eigenschaftensammlungen/Bytearrays: Diese stellen eine interessante Möglichkeit zur Datenübertragung dar, sollten jedoch nicht als anwendungsübergreifendes Datenübertragungsverfahren verwendet werden. VB6-Objekte können sich selbst in Eigenschaftensammlungen speichern bzw. aus diesen laden und zeichnen sich durch eine hohe Flexibilität (die Fähigkeit zum Hinzufügen von Eigenschaften, wie in einer Auflistung) aus. Die XML-Zeichenfolgen sollten jedoch immer dann verwendet werden, wenn die Flexibilität für eine bessere Leistung und Verwaltbarkeit entscheidend ist.

  • Komma-/Trennzeichenbegrenzte Zeichenfolgen: Diese Strategie kann sich als nützlich erweisen, wenn eine Interoperabilität mit Daten erforderlich ist, die in Form von trennzeichenbegrenzten Zeichenfolgen vorliegen. Abgesehen von diesem Sonderfall ist dieser Mechanismus nur wenig attraktiv, da er die meisten Nachteile von allen oben genannten Verfahren in Bezug auf Verwaltbarkeit, einfache Bereitstellung, Flexibilität und Leistung in sich vereint.

Das direkte Verwenden von XML DOM-Objekten anstelle einer Zeichenfolge ist eine Option, die Sie nach Möglichkeit vermeiden sollten, es sei denn, es liegen bestimmte Bedingungen vor.

XML-Dokumentobjektverweise

Wenn Sie eine Funktion erstellen, die XML zurückgibt, sollten Sie diese

As String oder als [ein Mitglied der XML DOM-Familie]

deklarieren? Das Verwenden eines XML DOM-Objektverweises kann vorteilhaft erscheinen, der Verweis funktioniert jedoch bei Prozessen und Apartments nicht erwartungsgemäß und kann Ihren zukünftigen Wachstumspfad einschränken, wenn der XML DOM-Verweis sich weiterentwickelt und wandelt. Es gibt weitere Optionen, die Sie vermeiden sollten.

  • ADODB.Stream-Objekte: DasADODB Stream-Objekt ist ein Hilfsobjekt, das die Konvertierung eines Recordsets in einen Datenstrom unterstützt. Es wurde nicht zum Übergeben von Informationen zwischen Komponenten entwickelt bzw. getestet. Alle zuvor genannten Optionen eignen sich besser für diesen Task.

  • Dictionary-, Collection- oder PropertyBag-Objekte: Diese Datenstrukturen sind nicht darauf ausgerichtet, Informationen zwischen den Schichten auszutauschen. Sie kommen im Bereich der clientseitigen Programmierung und ggf. in ASP-Seiten zum Einsatz. Die meisten Versuche, ein Collection-, Dictionary- oder PropertyBag-Objekt zu verwenden, schlagen bei echten Testverfahren aufgrund von Leistungs-, Sicherheits- und Stabilitätsproblemen fehl.

Weitere Informationen

Getrennte Recordsets übertragen Daten intern mit Hilfe eines ADTG-Formats (Advanced Data Table Gram), einer binären Darstellung, die effizient gepackt wurde. XML-Zeichenfolgen scheinen ineffizienter segmentiert und auch länger zu sein, aber Vergleichstests haben ergeben, dass es hinsichtlich der Netzwerkauswirkung keine gravierenden Unterschiede gibt.

Durch das Verwenden von getrennten Recordsets haben Sie Anteil an der Weiterentwicklung von MDAC, der Bereitstellung von MDAC auf Clients und Servern sowie der Verwendung der von MDAC unterstützten Datenstrukturen, z.B. tabellarische, multidimensionale, hierarchische Datenstrukturen usw. Dies ist nicht unbedingt ein Nachteil. Diese Vorgänge sind verständlicher, und die Semantik ist bekannt, seit die Verwendung von DAO (Datenzugriffsobjekt) vor Jahren sehr erfolgreich wurde. ADO verfügt heute angesichts der zunehmenden (und schnellen) Weiterentwicklung der XML-Tools über viele Vorteile. Es können sogar immer mehr ADOs in XML transformiert werden und umgekehrt. Für Sie bedeutet dies, dass Sie sich durch die Entscheidung für ADO nicht auf eine Datenzugriffsstrategie festlegen, die keinen Raum für Entwicklung lässt.

Auf der anderen Seite erfordert die Verwendung von XML die Standardisierung einer Struktur, in der Daten zwischen Clients und Servern ausgetauscht werden. Normalerweise ist recordsetgenerierte XML ausreichend, aber wenn Sie hinsichtlich der Flexibilität und Bearbeitbarkeit höhere Anforderungen stellen, können Sie XML transformieren.

XML ist in Bezug auf Schnittstellendefinitionen flexibler, überträgt jedoch einen Teil der Last an die Schichten und ändert diese. Es sind mehrere Codezeilen erforderlich, um ein XML-Dokument zu öffnen und zu bestimmten Daten zu gelangen.

Während moderne Browser über eine integrierte Unterstützung für XML, XSL, Schemas und andere XML-bezogene Technologien zur Datenbearbeitung und -darstellung verfügen, besitzen die Windows NT 4.0- und Windows 9x-Clients nicht von vornherein diese Unterstützung, sofern nicht Internet Explorer 5.0 oder höher installiert ist. Auf Windows 2000-Computern ist eine XML-Unterstützung integriert.

Es gibt keine allgemein gültige Regel, mit der Sie die beste Wahl für Ihre spezielle Anwendung treffen können. Jede Option befreit Sie von einigen Technologien, bindet Sie jedoch gleichzeitig an andere, z.B. DCOM, ADO, XML usw. Jede Option besitzt Leistungsmerkmale, die sich je nach Art der Verwendung unterscheiden. Wenn Sie sicherstellen möchten, dass Sie die beste Wahl für Ihre Anwendung treffen, sollten Sie mit den Datasets, die Sie voraussichtlich verwenden werden, einen Test durchführen, wobei Sie die Anzahl von Zeilen, Datentypen, Anzahl von Spalten usw. berücksichtigen. Zudem sollten Sie bei diesem Test bedenken, dass ADO-Recordsets und von einem ADO-Recordset generierte XML-Zeichenfolgen einfach ausgetauscht werden können, da das eine Element aus dem anderen abgerufen werden kann, und zwar in beiden Richtungen. D.h., wenn Ihre Komponente eine XML-Zeichenfolge zurückgibt, kann Ihr Client weiterhin ein ADO-Recordset daraus öffnen und verwenden, ohne die Quelle zu kennen.

Arrays vom Typ Variant sind etwas schwieriger zu testen, da sich die Codeanweisung auf der Clientseite drastisch von den Codeanweisungen unterscheiden, die zum Arbeiten mit ADO-Recordsets verwendet werden.

Wie zuvor erwähnt, erfordert es einige Anstrengungen, um die beste Option für Ihre besondere Anwendung zu wählen. Sie müssen die Entwickleranforderungen, den Veröffentlichungstermin und die Laufzeitleistung gegeneinander abwägen und speziell auf jedes von Ihnen erstellte System ausrichten.

Referenzmaterial

Optimizing Interactions Between the COM+ Business Logic Tier and the Presentation Tier (in Englisch)
HOWTO: Get XML Representation Of an ADO Recordset in Visual Basic (Q252767) (in Englisch)
Beyond the Browser: An XML Parser in Visual Basic - MIND 1999 (in Englisch)
INFO: Using Disconnected Hierarchical Recordsets (Q213856) (in Englisch)
www.microsoft.com/data für MDAC-Updates auf Windows-Plattformen (in Englisch)

 

Übergeben Sie keine Clientobjektverweise an den Server

Beim Aufrufen einer Methode auf dem Server sind Sie u.U. versucht, eine Instanz eines Objekts oder Steuerelements, das sich auf dem Client befindet, als Parameter an den Server zu übergeben, damit der Server weitere Informationen von dem Objekt bzw. Steuerelement abfragen kann. Dies ist jedoch nicht ratsam. Die daraus resultierenden Folgen und Probleme sind für eine kurze Beschreibung zu umfassend, dazu gehören jedoch die folgenden beiden Aspekte:

  • Das Übergeben von Clientobjektverweisen an den Server bewirkt eine Kopplung zwischen der Geschäftsschicht und der Darstellungsschicht.

  • Zudem stellt es eine nichteffiziente Verwendung des Netzwerks dar und kann zu einer Beeinträchtigung Ihres Sicherheitssystems führen, da die Aufrufe vom Server an den Client gerichtet werden, wodurch der normale Kommunikationsfluss umgekehrt wird.

Vorgehensweise

Stellen Sie sicher, dass Ihre serverseitigen Komponenten bei jedem Methodenaufruf alle erforderlichen Daten abrufen, damit die Komponenten statusfrei sind. Wenn Sie der Meinung sind, dass ein Server den Client aufrufen muss, sollten Sie Folgendes sicherstellen:

  1. Die Clientinteroperabilität für Ihre Geschäftsschicht sollte nicht beeinträchtigt werden. Das heißt, was passiert, wenn der Client in ASP migriert werden muss bzw. in ein über Tasten bedientes Programm oder einen XML-Dienst ohne Benutzeroberfläche?

  2. Sie sollten nicht versuchen, ein asynchrones Szenario zu emulieren. D.h., der Server kann dem Client implizit mitteilen, wann er fertig ist.

  3. Die Sicherheit Ihrer Umgebung wird dadurch, dass die Aufrufe vom Server aus an den Client gerichtet werden, nicht erheblich beeinträchtigt.

Wenn Sie möchten, dass Ihr Server einen Client über etwas benachrichtigen muss, sollten Sie hierfür Queued Components oder ein asynchrones Benachrichtigungsschema verwenden. Vor allem sollten Sie die Geschäftslogik nicht durch eine Benutzeroberfläche beeinträchtigen.

 

Deklarieren Sie XML-Funktionen und -Parameter als Zeichenfolgen und nicht als XML-Objekte

Wenn Sie sich für die Verwendung von XML-Zeichenfolgen als Datenübertragungsstrategie entscheiden, werden Sie mit der einfachen Überlegung konfrontiert, wie die Funktionen und Parameter deklariert werden sollen. Parameter sollten als Zeichenfolgen und nicht als Elemente des XML-Objektmodells deklariert werden. Sie sollten eine Funktion daher wie folgt deklarien:

Public Function SaveAuthor(AuthorXML As String) As String

Und nicht auf diese Weise:

Public Function SaveAuthor(AuthorXML as MSXMLDOMDocument) _  
As MSXML.DOMDocument

Dies verringert die Abhängigkeit Ihrer Objekte von der aktuellen XML-Version auf den beteiligten Computern. Die Leistungskennzahlen zeigen, dass in den meisten Fällen (Dokumente normaler Größe, die nicht zu komplex sind) die Kosten für das Analysieren der Zeichenfolge minimal sind.

Übergeben Sie keine Auflistungen oder "Dictionary"-Objekte als Methodenargumente

Die Visual Basic-Auflistung oder die VBScript Dictionary-Objekte wurden nicht für diese Verwendung entwickelt, und die Anwendung kann ggf. willkürlich fehlschlagen. Versuchen Sie, für die komponentenübergreifende Kommunikation Recordsets, Arrays oder XML-Zeichenfolgen anstelle von Auflistungen oder Dictionary-Objekten zu verwenden.

Weitere Informationen

Es gibt viele Möglichkeiten, benannte Eigenschaftenauflistungen zu verwenden. Je nach der von Ihnen gewählten Art der Verwendung kann es sein, dass das Übergeben von Recordsets, Arrays, XML-Zeichenfolgen oder des Inhalts einer Property Bag-Auflistung geeigneter ist. Die Objekte Dictionary, Property Bag und Collection waren nie für die Remoteverarbeitung vorgesehen und wurden daher auch diesbezüglich nicht getestet.

Vorgehensweise

Stellen Sie sicher, dass Ihre Komponenten keine Parameter annehmen oder Rückgabewerte besitzen, die als Collections, Property Bags oder Dictionaries deklariert bzw. festgelegt sind.

Referenzmaterial

INFO: VB 6.0 Readme Part 13: Dictionary Object (Q191792) (in Englisch)

 

Stellen Sie sicher, dass Sie Eigenschaftswerte und nicht Objekte als Parameter übergeben

Details

Beim Programmieren einer Visual Basic-Clientanwendung werden normalerweise die Standardeigenschaften von Steuerelementen und anderen Objekten als Parameter für Funktionsaufrufe verwendet. Durch Verwenden von Standardeigenschaften können unerwartete Fehler auftreten, wenn Remotekomponenten oder ADO verwendet werden. Wenn Sie ein Remoteobjekt direkt von der Benutzeroberfläche aus aufrufen und die Aufrufe Parameter vom Typ Variant annehmen, sollten Sie sicherstellen, dass der tatsächliche Wert und nicht das Objekt selbst übergeben wird (z.B. TextBox).

Weitere Informationen

Wenn der Parameter einer Funktion vom Typ Variant ist, kann Visual Basic nicht feststellen, ob Sie tatsächlich das Objekt oder den Standardwert des Objekts übergeben möchten, und geht daher davon aus, dass Sie das übergeben möchten, was Sie explizit geschrieben haben. Viele Visual Basic-Programmierer verlassen sich darauf, dass Visual Basic sich mit der Mehrdeutigkeit bei der Verwendung von Objekten auseinandersetzt, indem die Standardeigenschaft implementiert wird. Diese Implementierung ist nicht die beste Lösung. Wenn Sie etwas übergeben möchten, sollten Sie dafür expliziten Code schreiben.

ADO-Parameter und Methodenargumente scheinen eine besondere Abneigung gegen Standardeigenschaften zu besitzen. In vielen Fällen werden ungewöhnliche Fehlermeldungen zurückgegeben, nur weil der Inhalt eines Textfelds als

txtFoo

anstatt als

txtFoo.Text

angegeben ist.

Vorgehensweise

Stellen Sie sicher, dass Sie einen korrekten Verweis auf die Eigenschaft verwenden, wie in

Text1.Text

.

Nutzen Sie die bedarfsgesteuerte Windows 2000-Clientregistrierung

Windows 2000 verfügt über eine neue Funktion, mit der die Clients Ihre Komponenten bei Bedarf automatisch suchen, installieren und registrieren können.

Durch das richtige Konfigurieren von Active Directory erkennt das Netzwerk das Vorhandensein bestimmter Klassen. Wenn beim Versuch eines Clients, unter Verwendung der korrekten Richtlinien ein Objekt zu erstellen, die Objektregistrierung fehlt, sucht Windows 2000 automatisch diesen zentralen Klassenspeicher. Anschließend werden die Komponenten downgeloadet und installiert. Die Anwendung wird weiter im Hintergrund ausgeführt.

Für das Verwenden dieser praktischen Funktion sind zwei Schritte erforderlich:

  1. Konfigurieren der Komponenten im Klassenspeicher.

  2. Aktivieren der Option Fehlende COM-Komponenten übertragen unter Gruppenrichtlinien-Snap-In, um das clientseitige COM-Laufzeitverhalten so zu ändern, dass der Klassenspeicher geprüft wird, wenn die Komponente nicht in der lokalen Registrierung gefunden wird.

Referenzmaterial

Deploying COM Applications Using the Class Store (in Englisch)
Publishing COM and COM+ Components (in Englisch)