Este tema describe el desarrollo de servicios Web ascendente, de encuentro en el medio y descendente en el contexto de desarrollo de un servicio Web completo que sea capaz de recopilar y procesar datos procedentes de varias aplicaciones CICS, de otros servicios Web o de ambos.
El método ascendente se utiliza en un proyecto de flujo de servicios cuando el objetivo es crear un servicio a partir de una aplicación existente.
El método de encuentro en el medio se utiliza en un proyecto de flujo de servicios cuando ya se dispone del archivo WSDL y el componente de implementación (aplicación) y es necesario crear el código de soporte adicional que los correlaciona.
El método de desarrollo descendente se utiliza en un proyecto de flujo de servicios cuando ya se dispone de la definición de un servicio Web determinado especificada en un archivo de definición de servicios Web (formato WSDL) y se desea generar archivos fuente de lenguaje de alto nivel (en este caso, archivos fuente COBOL) que contengan: (1) las versiones COBOL de las definiciones de esquema XML especificadas en el archivo WSDL para el mensaje de entrada y el de salida del servicio Web; y (2) los módulos de programa COBOL que copian ("correlacionan") el contenido de las versiones COBOL del mensaje de entrada y el de salida en las versiones de definición de esquema XML del mensaje de entrada y del de salida, y viceversa.
Estos tres métodos de desarrollo se describen en los subtemas siguientes.
Como se ha indicado anteriormente, las aplicaciones existentes que ya hayan sido probadas a lo largo del tiempo representan una inversión existente para cualquier empresa. La reutilización de las aplicaciones existentes, al tiempo que crean nuevos valores en la implementación como servicios, amplía la utilidad de estas aplicaciones y aumenta el valor que proporcionan a la corporación.
Puede utilizar un proyecto de flujo de servicios en un método ascendente cuando el objetivo sea crear un servicio a partir de una aplicación existente.
Al crear un servicio a partir de una aplicación existente, puede rehacer o redefinir el propósito de la aplicación para su participación en una arquitectura orientada a servicios. La función empresarial de la aplicación es utilizada de varias maneras por distintos usuarios. Este tipo de reutilización inteligente crea un nuevo valor y amplía la utilidad de las aplicaciones existentes.
Un objetivo del desarrollo ascendente sería conectar las funciones empresariales todavía relevantes en aplicaciones más antiguas con la tecnología más reciente. Por ejemplo, puede que quiera combinar la industria de los viajes y la informática generalizada transformando la aplicación de viajes existente, exponiéndola como un servicio y haciendo que el servicio esté disponible para su utilización por varios dispositivos en un entorno orientado a objetos. Más específicamente, podría ampliar la función de reserva de billetes a nuevos destinatarios para que utilizarse y accederse a la misma de distintas maneras.
El desarrollo de un servicio basado en los activos basados en los activos existentes se denomina un método ascendente ya que el desarrollo se inicia con la implementación (una aplicación existente) como base y, a continuación, se crea una definición de servicio de interfaz "encima" de la implementación.
La definición de servicio de interfaz es el componente clave para transformar cómo se utilizarán las aplicaciones existentes en una SOA. La definición de interfaz de servicios deriva de la interfaz programática de la aplicación existente. Mediante el desarrollo de proyectos de flujo, la interfaz programática de la aplicación se transforma en una interfaz adecuada para la arquitectura orientada a servicios.
En un método ascendente, se utiliza un proyecto de flujo de servicios para capturar la interfaz de la aplicación existente y, a continuación, se genera una descripción para la implementación de un archivo de operaciones de pantalla
Puede implementar y empaquetar el contenido del archivo de operaciones de pantalla como nodos en un flujo, donde cada nodo representa la invocación de una operación de servicios, controlando el flujo de la secuencia o realizando lógica empresarial reutilizable.
Por ejemplo, imagine una aplicación de terminal CICS existente que proporciona acceso a datos de reservas de billetes de avión. la aplicación incluye imágenes de pantalla, mapas BMS y navegación. Los desarrolladores pueden utilizar las herramientas de proyecto de flujo de servicios para importar y registrar la información necesaria para acceder a la aplicación CICS y, después de una serie de pasos, pueden generar el WSDL, operaciones y flujo que definen la aplicación como un servicio.
Los siguientes pasos describen un método de desarrollo ascendente al utilizar las herramientas de proyecto de flujo de servicios para crear un servicio a partir de una aplicación 3270 existente.
Los detalles acerca de cómo realizar las siguientes tareas están documentadas en los temas de ayuda correspondientes.
El proyecto de flujo de servicios es un repositorio y una estructura organizativa de los recursos que se importen, capture o registren utilizando los componentes de proyecto de flujo de servicios.
La conexión con el host contiene las propiedades que permiten acceder al sistema en el que se ejecuta la aplicación 3270.
Las herramientas de proyecto de flujo de servicios dan soporte a la conexión a aplicaciones de terminal 3270 y 5250.
Las herramientas de proyecto de flujo de servicios proporcionan varias opciones para capturar una función empresarial de las aplicaciones de terminal existentes.
El método seleccionado para capturar la función empresarial de una aplicación de terminal existente depende de la complejidad de la aplicación que esté transformando.
Utilizando este método automatizado, es posible:
El registro de flujos es la manera más rápida de crear un flujo, pero no promociona necesariamente la reutilización de los artefactos de host.
Puede reutilizar los recursos que cree mediante el registro de flujos para producir flujos rápidamente aunque es posible que sea necesario editar dichos recursos.
La utilización de la función de registros del editor de host para crear un flujo de una aplicación es más adecuada para aquellos usuarios que tienen conocimientos más limitados de los sistemas de fondo que alojan los datos y la información de los flujos de servicios.
Utilice el editor del sistema para navegar hasta cada pantalla encontrada y utilizada en la función empresarial de reserva de billetes, y realice una operación de captura de pantallas.
Cuando capture pantallas de aplicación de host, éstas se guardarán como mensajes en formato .sfmxsd.
Dependiendo del tiempo de ejecución del servidor en el que se despliegue el servicio, es posible que necesite añadir criterios de reconocimiento más detallados a los mensajes resultantes de la operación de captura.
Las herramientas de proyecto de flujo de servicios incluyen un editor de mensajes de pantallas para mejorar las descripciones de mensajes de pantalla.
Una operación de pantalla representa un conjunto de pantallas, sin más que una operación correspondiente a una descripción de pantalla proporcionada.
En este ejemplo, una operación de pantalla representa todas las rutas válidas a través de las pantallas de aplicación que forman parte de la función empresarial de reserva de billetes.
Estas vías en una operación de pantalla se almacenan en un documento WSDL que puede utilizarse como entrada para un flujo de la aplicación.
El flujo es una representación gráfica del servicio compuesto, en este caso una función empresarial de reserva de billetes de líneas aéreas.
El flujo está compuesto por una secuencia de operaciones, asignaciones y condicionales.
Un flujo tiene una interfaz de operación WSDL (salida del paso de registro de operación de pantalla), que dirige las acciones desde un punto inicial (nodo Receive o Input) a través de un número de operaciones hasta un punto final (nodo Reply o Output).
En un proyecto de flujo de servicios, el flujo representa la reutilización de la función empresarial existente como un servicio.
El editor de flujo se utiliza para conectar los nodos en una vía finita que procesa un mensaje de petición (reserva de billetes) y que resulta en un mensaje de respuesta (la reserva es procesada).
Los flujos creados utilizando las herramientas de proyecto de flujo de servicios pueden exponerse como un servicio, ser utilizados externamente por un servicio Web o por un adaptador de recursos J2EE Connector (J2C), como CICS ECI.
Utilice el asistente Propiedades de despliegue para establecer las propiedades de generación del flujo.
Utilice el asistente Generar código de tiempo de ejecución para crear el código para crear el código del entorno de tiempo de ejecución del servidor soportado.
El método ascendente descrito (consulte Desarrollo ascendente) comienza con la función de aplicación que está siendo encapsulada, el último paso resultando en una interfaz de servicios (que contiene un mensaje de entrada y de salida) que puede ser invocado.
En el ejemplo de reservas de líneas aéreas, el mensaje de entrada puede contener información de cliente e información mientras que el mensaje de salida puede contener información de reservas y un número de confirmación.
En el método ascendente, la interfaz se crea al final del proceso, después de haber creado el flujo que representa gráficamente aquellas pantallas de aplicaciones existentes procesadas para realizar la reserva de billetes.
El método de encuentro en el medio se utiliza en un proyecto de flujo de servicios cuando se dispone de un archivo WSDL y un componente de implementación (aplicación) durante la fase inicial del proyecto de flujo de servicios y es necesario crear código de soporte adicional que correlacione el archivo WSDL y el componente de implementación.
Puede que tenga acceso a la interfaz de servicio preexistente si se ha considerado necesario desarrollar una interfaz para poder satisfacer una necesidad empresarial determinada. Como parte del análisis que ha resultado en esta interfaz de servicios, el usuario conocería que los consumidores del servicio emitirían peticiones en un formato determinado y que el formato de las respuestas enviadas también sería conocido o predeterminado. En tal situación, necesitaría utilizar las herramientas de proyecto de flujo de servicios para crear los flujos que invocan las aplicaciones CICS existentes y, a continuación, "correlacionar" las secuencias a la definición de interfaz de servicio existente.
Tan método también puede aplicarse cuando la empresa tenga servicios ya creados. Por ejemplo, la empresa puede haber creado un servicio GetCustomerInfo con un modelo de respuesta para petición definido.
La expresión encuentro en el medio implica que hay varios desarrollos simultáneos, que en un extremo del espectro hay desarrolladores creando interfaces de operación de servicios mientras en el otro extremo del espectro de desarrollo hay analistas empresariales que están creando el flujo y correlacionándolo con la interfaz de operación de servicios existentes.
Utilizando este método puede crear un nuevo servicio conforme a una interfaz de servicio existente. Este tipo de interfaz es normalmente parte de un estándar, que puede ser implementado por un gran número de proveedores de servicios.
El proveedor de servicios debe encontrar la interfaz de servicios, implementar la interfaz contenida en esta definición y, a continuación, desplegar el nuevo servicio. La interfaz de servicio no puede ser propiedad del proveedor de servicios.
El método descendente será más relevante a medida que los grupos del sector acuerden interfaces WSDL estándares para funciones empresariales comunes.
Aunque teóricamente las herramientas de proyecto de flujo de servicios pueden utilizarse en un método descendiente, no será objeto de los temas de ayuda o de los ejemplos.