Alternativas para extensiones de objeto del servidor

A veces, el ancho de los ArcObjects y el desafío de codificar un servicio web pueden causar que las extensiones de objeto de servidor (SOE) sean difíciles para los principiantes. En este tema se tratan algunas tareas comunes de SIG web para las cuales los desarrolladores tradicionalmente escriben el código ArcObjects y proporciona enfoques alternativos que no requieren escribir un SOE o conocer los ArcObjects.

Crear diseños para impresión

Muchos desarrolladores han utilizado ArcObjects para acceder al objeto de diseño del servicio de mapas, específicamente para dar una funcionalidad de impresión de alta calidad en sus aplicaciones web. Utilizan ArcObjects para trabajar con mapas con calidad como en ArcMap y sus elementos circundantes, generar documentos que se puedan imprimir en formatos grandes, etc.

ArcGIS 10.0 introdujo el módulo arcpy.mapping de Python que puede utilizar para crear una secuencia de comandos de la construcción de su diseño e impresión de mapas. Luego puede exponer la secuencia de comandos a través de un servicio de geoprocesamiento. Con arcpy.mapping puede manipular documentos de mapa con mucha sutileza: puede agregar capas dinámicamente al mapa, actualizar su simbología, etc. Además, puede acceder al diseño del mapa, manipular elementos como texto e imágenes.

En ArcGIS 10.1, se han mejorado las capacidades de arcpy.mapping. Específicamente, es más fácil cargar de forma dinámica el contenido de una aplicación de representación cartográfica en la red (incluyendo gráficos y servicios de mapas) en un documento de mapa utilizando arcpy.mapping.

Cambiar símbolos y renderizadores

Otra razón por la que los desarrolladores utilizaban ArcObjects en el pasado era para cambiar la simbología de una capa en particular en un servicio de mapas. Este flujo de trabajo a menudo requería el uso de servicios no agrupados, limitando la escalabilidad de las aplicaciones. Algunos desarrolladores lograban hacer esto con servicios agrupados, a pesar de que alternar el estado de un servicio para satisfacer las solicitudes de varios usuarios a menudo resultaba en un rendimiento deficiente y dejaba mucha responsabilidad al desarrollador para mantener un buen estado en la instancia del mapa en sí.

Las API Web de ArcGIS le proporcionan una manera fácil de simbolizar entidades mediante la capa de entidades del cliente o capa de gráficos, cuyas propiedades de representación en pantalla se pueden cambiar en cualquier momento. La idea es que la geometría y los atributos de entidades visibles se descarguen todas en el cliente y, de esta forma, sea más fácil para el cliente dibujar las entidades utilizando cualquier color, anchos o cortes de clase que defina el desarrollador de la aplicación.

La técnica de capa de entidades es particularmente efectiva para la representación cartográfica temática, interactuar con y resaltar entidades, y así sucesivamente, pero no es suficiente cuando trabaja con miles de entidades o entidades poligonales muy complejas. En esos casos, el mejor enfoque es solicitar cambios de simbología a nivel del servicio y hacer que el servicio de mapas represente en pantalla la imagen del mapa. Esto anteriormente requería ArcObjects.

ArcGIS 10.1 mejora el servicio de mapas de tal manera que puede alterar el contenido y simbología del mapa en tiempo de ejecución (como lo podría hacer con ArcIMS). Ya no necesita utilizar servicios no agrupados y ArcObjects con mucha precisión para cambiar la simbología en las capas de servicio de mapas. En lugar de esto, puede decidir, en base a cada solicitud, el contenido o simbología a utilizar en el mapa que desea crear.

Este realce puede hacer que las aplicaciones sean significativamente más escalables, a la vez que simplifica el desarrollo y mantenimiento. Definir la simbología de las capas en el servicio de mapas en tiempo de ejecución se logra al incluir la información del renderizador en la solicitud de servicio web para dibujar el mapa, junto con la información típica de visibilidad de capas, extensión, etc. Las versiones 3.0 de las API Web de ArcGIS incluyen clases de utilidad para que pueda definir con facilidad el contenido, los renderizadores, los cortes de clase, la simbología, etc.

Para obtener más información sobre cómo cambiar el contenido y la simbología al vuelo en un servicio de mapas, vea Acerca de capas dinámicas.

Edición Web

En las versiones anteriores de ArcGIS Server, la edición de datos en la web se debía lograr meramente a través del código personalizado de ArcObjects aprovechando las conexiones locales (DCOM). En la versión 9.2, se introdujo una tarea editor en el ADF Web que permite la edición básica como crear, mover y eliminar entidades. Cualquier personalización de esta tarea o la creación de herramientas de edición desde cero aún requerían la programación extensiva de ArcObjects.

Las API basadas en REST no exponían inicialmente la edición web; sin embargo, con la introducción del servicio de entidades en ArcGIS 10, fue posible editar mediante esas API. No solo editar es posible mediante REST, resulta muy práctico personalizar debido a que muchos métodos de edición comunes, como cortar, recortar, extender, autocompletar polígonos y cambiar la forma, se exponen a través de la implementación del servicio de geometría de REST. Por último, cuando edita con REST, puede utilizar servicios agrupados. Esto es una enorme ventaja para el rendimiento.

Existe un flujo de trabajo para el cual ArcGIS 10.1 ya no es compatible: las transacciones largas. En el ADF Web, podría aprovechar los servicios no agrupados para realizar ediciones obedeciendo a un modelo de transacción larga. En esencia, podría comenzar a actualizar entidades y deshacerlas en cualquier momento. Con el servicio de entidades, todas las operaciones están sin estado, lo que significa que no puede deshacerlas a nivel de base de datos (aunque podría con lógica de negocios en su aplicación). Un modelo de transacción larga para edición web es uno de los pocos flujos de trabajo donde la nueva arquitectura del servidor en ArcGIS 10.1 no ofrece alternativas.

Es importante resaltar que la falta de compatibilidad para transacciones largas no le impide implementar las operaciones deshacer/rehacer. De hecho, en las API de representación cartográfica en la red de ArcGIS, las operaciones deshacer/rehacer son posibles directamente desde la API a nivel de aplicación.

Otra capacidad única que los servicios no agrupados le proporcionan es poder cambiar las versiones mientras edita. Esto permite, por ejemplo, que los usuarios web almacenen sus cambios en versiones diferentes que luego se pueden conciliar en ArcGIS for Desktop. ArcGIS 10.1 mejora los servicios de entidades para que pueda destinar de forma eficiente las ediciones a una versión en tiempo de ejecución desde cualquier aplicación web.

Realizar lógica de negocios con geoprocesamiento

Algunas aplicaciones SIG ejecutan una serie de herramientas específicas para realizar una lógica de negocios avanzada de SIG. Estas herramientas pueden predecir la producción de madera de un bosque, identificar lugares aptos para un restaurante o estimar donde se podría expandir una nube tóxica. Muchos desarrolladores han utilizado ArcObjects para adaptar esto.

En muchos casos, estos procesos se pueden expresar en ArcGIS ModelBuilder, donde puede conectar en "cadena" las herramientas de forma gráfica. Esos modelos de geoprocesamiento se pueden exponer como servicios web y utilizar desde las aplicaciones web. Los beneficios son obvios: utilizar un servicio de geoprocesamiento puede ahorrarle muchos códigos. Además, puede aprovechar la ejecución asíncrona de los servicios de geoprocesamiento, que es un desafío lograr al escribir su propio código ArcObjects.

Aparte de la flexibilidad de tener cientos de herramientas de uso inmediato que puede combinar en ModelBuilder, el geoprocesamiento le proporciona la capacidad de desarrollar herramientas personalizadas. La forma más simple es crear secuencias de comandos Python que se puedan ejecutar ya sea individualmente o en combinación con otras herramientas dentro de un modelo. Este tema describió un ejemplo de lo anterior con el uso de arcpy.mapping para crear mapas de alta calidad en la web.

Para obtener aún más control, puede ir más allá de Python para crear una herramienta de geoprocesamiento personalizada con C#, Visual Basic .NET, C++ o Java. Esto le permite incorporar su propia lógica de ArcObjects con mucha precisión en sus modelos.

Si utiliza Python u otro lenguaje, la ventaja de crear herramientas personalizadas es que puede reutilizarlas en diferentes flujos de trabajo, ya que se comportan como cualquier otra herramienta de uso inmediato. Además, su código ArcObjects o Python puede ejecutarse dentro del modelo de ejecución asíncrona de los servicios de geoprocesamiento, lo cual es bastante útil para procesos de larga ejecución.

Realizar cálculos geométricos

Los servicios de geoprocesamiento son útiles, pero del mismo modo no debe precipitarse con el desarrollo de ArcObjects cuando algo se puede logar con mayor facilidad con geoprocesamiento, es aconsejable evitar hacer uso del geoprocesamiento si los servicios de uso inmediato puede hacer el trabajo. Verifique si el servicio de geometría basado en SOAP o REST ofrece los métodos que usted necesita. El servicio de geometría puede realizar operaciones SIG básicas como crear zonas de influencia, determinar relaciones espaciales y medir longitudes y áreas. Invocar a una serie de métodos en un servicio de geometría y combinarlas con los recursos de consulta de servicios de mapas y lógica del cliente puede ser más simple y rápido que utilizar un servicio de geoprocesamiento.