Erweitern von Services
In diesem Thema
- Serverobjekterweiterungen (SOEs)
- Serverobjekt-Interceptoren (SOIs)
- Was Sie zum Entwickeln einer Erweiterung wissen müssen
Hinweis:
Serverobjekt-Interceptoren (SOIs) sind eine neue Funktion in 10.3.1. Die Informationen in diesem Thema zu SOIs gelten nur für 10.3.1.
Sie können ArcGIS-Server-Karten- und Image-Services (einschließlich Karten- und Image-Service-Erweiterungen wie Feature-Services) mit benutzerdefinierter Logik erweitern, die in ArcGIS-Clients ausgeführt werden kann. Es gibt zwei Möglichkeiten, diese Service-Typen zu erweitern.
- Serverobjekterweiterungen (SOEs) – Ermöglichen Ihnen die Erstellung neuer Service-Operationen, um die Basisfunktionalität von Karten- und Image-Services zu erweitern. SOEs sind geeignet, wenn Sie eine gut definierte Geschäftslogik ausführen müssen, was mithilfe der ArcGIS-Client-APIs nur schwer erreicht werden kann. Die meisten SOEs verwenden dazu ArcObjects-Code, um mit GIS-Daten und -Karten zu arbeiten. ArcObjects sind die Kernkomponenten, auf denen ArcGIS basiert. Sie ermöglichen Ihnen die größtmögliche Flexibilität beim Schreiben von GIS-Funktionen.
- Serverobjekt-Interceptoren (SOIs) – Ermöglichen Ihnen das Abfangen von Anforderungen für vorhandene integrierte Operationen von Karten- und Image-Services. Dadurch haben Sie die Möglichkeit, benutzerdefinierte Logik auszuführen und das Verhalten dieser Services zu ändern. So lassen sich vorhandene Operationen überschrieben und nathlos in die Clients integrieren. Bei diesen Clients kann es sich um Anwendungen handeln, die mit ArcGIS API for JavaScript, ArcGIS Runtime SDK usw. erstellt wurden.
In den folgenden Abschnitten werden die einzelnen Typen näher beschrieben.
Serverobjekterweiterungen (SOEs)
SOEs sind geeignet, wenn Sie neue Service-Operationen erstellen möchten, um die Basisfunktionalität von Karten- und Image-Services zu erweitern (einschließlich Karten- und Image-Service-Erweiterungen wie Feature-Services). SOEs bieten die folgenden Vorteile:
- Sie können eine SOE als REST (Representational State Transfer)- und/oder SOAP (Simple Object Access Protocol)-Web-Service bereitstellen, sodass benutzerdefinierte Clients auf die ArcGIS-Client-APIs aufsetzen und andere REST- oder SOAP-Clients sie leicht aufrufen können. In der Tat werden die REST-SOEs im ArcGIS Server Services Directory angezeigt und können die typischen Objekttypen bereitstellen, die die ArcGIS-Client-APIs verstehen, meistens im JSON-Format.
- Wenn Sie eine SOE erstellen, stellen Sie einfache Methoden bereit, die Arbeiten auf ArcGIS-Server ausführen, anstatt eine große Anzahl von Aufrufen vom Client zum Server zu tätigen. SOEs kapseln die ArcObjects-Logik sehr effizient und stellen eine ideale Umgebung bereit, um die Aufrufe schnell auszuführen.
Sie können eine SOE entwickeln, wenn Sie ArcObjects-Funktionen bereitstellen möchten, die auf keine andere Weise verfügbar sind oder eine schnelle Ausführung erfordern. SOEs eignen sich für erfahrene Entwickler und erfordern Kenntnisse verschiedener Entwicklungsplattformen. Das ArcObjects SDK for Java enthält mehrere SOE-Beispiele, die Sie untersuchen können.
Wann eine SOE notwendig ist
SOEs erfordern Kenntnisse in der Web-Entwicklung, von ArcObjects und Programmiersprachen wie Java oder einer .NET-basierte Sprache wie C#. Sie müssen außerdem einen Bereitstellungsprozess durchlaufen, um auf dem Server verfügbar gemacht zu werden. Bevor Sie eine Serverobjekterweiterung entwickeln, sollten Sie einige einfachere Alternativen erwägen.
Die einfachste Alternative zum Entwickeln einer SOE ist möglicherweise das Erstellen eines Geoverarbeitungsmodells, das die Geschäftslogik erfüllt, und deren Veröffentlichung als Service. Sie können ModelBuilder verwenden, um die benötigten Werkzeuge interaktiv zu ziehen, abzulegen und zu verbinden, anstatt ArcObjects-Code zu schreiben. Geoverarbeitungsservices unterstützten auch die asynchrone Ausführung, sodass Sie einen Auftrag starten, dann zu etwas Anderem wechseln und später zum Auftrag zurückkehren können, um die Ergebnisse zu überprüfen.
Ein Nachteil von Geoverarbeitungsservices ist, dass sie einen relativ großen Speicherbedarf haben und möglicherweise langsamer als SOEs ausgeführt werden. Wenn Sie einen Prozess nur wenige Male am Tag ausführen, sollte dies kein Problem sein.Wenn Sie einen Prozess allerdings häufig am Tag oder mit vielen Benutzern gleichzeitig ausführen, könnte es sinnvoll sein, die Zeit in die Erstellung einer SOE zu investieren.
Viele Entwickler haben in der Vergangenheit ArcObjects-Code für verschiedene Aufgaben geschrieben, die jetzt ohne ArcObjects durchführbar sind. Eine ausführliche Diskussion der Möglichkeiten, sich den Herausforderungen des Web Mapping zu nähern, ohne ArcObjects zu verwenden, finden Sie unter Alternativen zu Serverobjekterweiterungen.
Serverobjekt-Interceptoren (SOIs)
SOIs sind geeignet, wenn Sie das Verhalten vorhandener Karten- oder Image-Service-Operationen (einschließlich Karten- und Image-Service-Erweiterungen wie Feature-Service-Operationen) ändern möchten. Sie können beispielsweise das Verhalten einer Anforderung für eine Abfrage oder einen Kartenbildexport ändern. SOIs können beispielsweise für Folgendes verwendet werden:
- Hinzufügen eines Wasserzeichens zu allen Kartenbildern
- Bereitstellen von Sicherheit auf Layer-Ebene
- Gewähren oder Verweigern des Zugriffs auf bestimmte Operationen durch die Benutzerrolle
Wann eine SOI notwendig ist
SOIs erfordern Kenntnisse in der Web-Entwicklung, von ArcObjects und Programmiersprachen wie Java oder einer .NET-basierte Sprache wie C#. Sie müssen außerdem einen Bereitstellungsprozess durchlaufen, um auf dem Server verfügbar gemacht zu werden. Ermitteln Sie vor der Entwicklung eines SOI, ob dies die Funktionalität ist, die Sie benötigen.
Wenn Sie Ihren Server mit neuen Funktionen erweitern möchten, sollten Sie eine SOE oder Geoverarbeitungsmodelle und -skripte in Betracht ziehen. SOIs sind geeignet, um neue Funktionen oder Verhalten zu vorhandenen ArcGIS-Server-Operationen so hinzuzufügen, dass sie für vorhandene Client-Anwendungen transparent sind.
Sie können beispielsweise einen SOI erstellen, wenn Sie benutzerdefinierte Geschäftslogik wie Sicherheits- oder Überwachungsanforderungen implementieren müssen, die vom Standardkarten- oder Image-Service nicht erfüllt werden. Beispiel:
- Fügen Sie ein Wasserzeichen in alle Kartenbilder ein, die vom Server erstellt wurden – ein SOI kann erstellt werden, um Kartenbilder, die vom Server erstellt wurden, mit einem benutzerdefinierten Wasserzeichen zu überlagern. Dadurch können Organisationen oder Hostingunternehmen das ordnungsgemäße Branding auf allen Bildern sicherstellen.
- Überwachen und Protokollieren aller Anforderungen – Sie können zu Debugging-Zwecken einen SOI erstellen, der detaillierte Informationen zu eingehenden Anforderungen protokolliert, wie etwa vollständige Informationen zu den mit der Anforderung übergebenen Eingabeparametern und Anmeldeinformationen der Benutzer.
- Post-processing Antworten – Zusätzliche Informationen aus getrennten Unternehmenssystemen, die nicht von ArcGIS-Server unterstützt werden, können zu ausgehenden Antworten hinzugefügt werden, um räumliche Daten mit anderen Typen von Business Intelligence-Daten zu verbinden.
- Zugriffssteuerung auf Operationsebene für Karten-Services – ArcGIS-Server unterstützt lediglich die Aktivierung von Service-Operationen für alle Benutzer des Service oder die vollständige Deaktivierung des Zugriffs. Ein SOI kann eingehende Anforderungen basierend auf der Rolle des Benutzers filtern, um den Zugriff auf Operationsebene für den Service zu implementieren.
- Zugriffssteuerung auf Layer-Ebene für Karten-Services – ArcGIS-Server unterstützt lediglich den Datenzugriff auf Service-Ebene; ein Benutzer hat entweder vollständigen Zugriff auf alle Service-Daten oder keinen Zugriff. Ein SOI kann implementiert werden, um den Zugriff auf bestimmte Layer oder sogar Daten in einem Layer basierend auf der Rolle des Benutzers zu filtern.
Was Sie zum Entwickeln einer Erweiterung wissen müssen
Eine Erweiterung kann nur für einen bestimmten Service-Typ entwickelt werden, entweder einen Karten- oder einen Image-Service. Sie können beispielsweise keine generische Erweiterung entwickeln, die mit einem Karten- und Image-Service funktioniert. In diesem Fall müssen Sie einzelne Erweiterungen für jeden Service-Typ entwickeln, eine für einen Karten-Service und die andere für einen Image-Service.
Zur Erweiterungsentwicklung sind Kenntnisse der ArcObjects-Verwendung durch Java erforderlich. Außerdem ist ein Verständnis der REST- oder SOAP-Prinzipien erforderlich. Mit Java entwickelte Erweiterungen können in ArcGIS for Server (Windows) und ArcGIS for Server (Linux) bereitgestellt werden. Mit .NET entwickelte Erweiterungen können nicht in ArcGIS for Server (Linux) bereitgestellt werden.
Wenn Sie darüber hinaus benutzerdefinierte Eigenschaftenseiten für die Erweiterung jenseits der automatisch generierten schreiben möchten, benötigen Sie Kenntnisse in der Entwicklung mit Java Swing (für ArcCatalog-Seiten) oder in der Entwicklung mit Web Forms mithilfe von Hypertext Markup Language (HTML) und JavaScript (für Manager-Seiten).