En los sistemas basados en red de gran escala, los flujos pueden abarcar una importante cantidad de nodos de red y de enlaces de comunicación, en los que el comportamiento de los servicios invocados no siempre se puede conocer y predecir. En este ambiente, se deben gestionar una variedad de Factores Inciertos (Uncertainty Factors), que incluyen:
• Función imprevisible. Un servicio puede ser provisto por componentes COTS o por un Proveedor de Servicio Externo de funcionamiento y disponibilidad imprevisibles que pueden no realizar las operaciones esperadas o en el momento en que son invocadas. • Función comprometida. Un servicio puede haber sido comprometido o interrumpido
por una intrusión o un ataque físico y puede no ser capaz de realizar su función o hacer- lo de manera correcta.
• Función de alto riesgo.Un servicio puede no proveer los adecuados niveles de atributos de calidad (QoS) requeridos por el flujo.
• Función asincrónica. Un servicio puede ser usado simultáneamente y en forma asin- crónica por otros flujos y, en consecuencia, producir resultados dependientes de una impredecible historia de uso, tanto legítimo como ilegítimo.
Estos factores son realidades siempre presentes en el comportamiento de los sistemas basados en red de gran escala [Schneider 99]. Tratar con ellos es un problema de gestión del riesgo de la organización con potenciales consecuencias serias. Resulta importante detectar cuándo han ocu- rrido y tomar las acciones apropiadas para continuar operando dentro de los ambientes que ellos han creado. Para el caso de los flujos de misión crítica, estas acciones deben asegurar la super-
vivencia, sin importar cuáles sean los ambientes que se presenten [Mead 00a].
En el mundo actual, es imprudente desde una perspectiva de la gestión del riesgo fallar en la aten- ción de los Factores Inciertos en todos los niveles de operación de la organización y del sistema. Se han definido semánticas matemáticas de las Estructuras de Flujos de soporte para el desarro- llo y la verificación de flujos para estos ambientes inciertos como una práctica estándar de inge- niería. Para permitir un comportamiento imprevisible de los servicios, las semánticas de flujos permiten especificar sólo el procesamiento que realiza un flujo por sí mismo, y no el procesa- miento de los servicios que él invoca. La ingeniería de Estructuras de Flujos requiere de la defi- nición de las acciones apropiadas mediante aquellos flujos de todas las posibles respuestas de los servicios claves, tanto deseados como indeseados. En consecuencia, si el comportamiento de los servicios invocados cambia por cualquier razón, la especificación y verificación del flujo invocante no necesita cambiar. Esta solución da cabida a las realidades de los actuales sistemas basados en red y ofrece importantes ventajas. Para la supervivencia de la misión, requiere que los Factores Inciertos sean tratados de manera explícita durante el diseño, y de esta manera, se contemplan importantes aspectos de la gestión del riesgo de la organización. Esto permite que los flujos y el razonamiento asociados a ellos se encuentren localizados y completos. Y permite definir los flujos mediante simples estructuras determinísticas a pesar del comportamiento asin- crónico subyacente de los servicios que los constituyen. Estas estructuras determinísticas se pueden refinar, abstraer, y verificar mediante métodos de composición directos para la com- prensión y el control intelectual humanos.
Resulta evidente que estos objetivos requieren de la extensión del modelo tradicional de las semánticas funcionales. El modelo semántico FSQ está basado en el concepto bien conocido de servicios como reglas para las funciones matemáticas(o relaciones si los flujos incluyen opera- ciones concurrentes), esto es, asociaciones desde dominios (entradas, estímulos) hacia rango (salidas, respuestas) [Linger 79, Mills 86, Prowell 99, Hoffman 01, Mills 02]. La extensión clave requerida para encarar sistemáticamente los Factores Inciertos es la construcción de las historias de las invocaciones de servicios como parte de la conducta especificada de los flujos. Matemáticamente, esto se logra mediante la inclusión de la Historia de Invocación de Estímu- losISH (Invocation Stimulus History) de cada servicio dentro del rango de la función que repre- senta la especificación de un flujo. Además, debido a que el subsiguiente procesamiento del flujo puede depender de las respuestas a estas invocaciones, la Historia de Respuestas de Invo- caciones IRH (Invocation Response History) debe ser parte del dominio de la función matemá- tica que representa la especificación de un flujo. El diagrama de la Figura 34 ilustra estas se- mánticas para un flujo F que invoca a un servicio A.
Figura 34. Elementos de las semánticas de Flujo-Servicio
I es e conjunto de posibles entradas del flujo F, y O es el conjunto de posibles salidas desde el flujo F. En consecuencia, las semánticas de F pueden estar expresadas mediante una función matemática f dentro del dominio IxIRH y el rango OxISH. Es esta inclusión nada intuitiva de las respuestas del servicio dentro del dominio de F y del estímulo del servicio dentro del rango de F lo que permite que los flujos manejen los Factores Inciertos. En particular, IRH representa el rango de las respuestas posibles del servicio y, en consecuencia, representa las posibilidades del Factor Incierto que tendría que tenerse en cuenta en el diseño del flujo. Hacer frente a los Factores Inciertos requiere de valorar y poner en práctica todas las respuestas posibles, desea- das e indeseadas, que pueden producir las invocaciones de servicio. Por supuesto, ninguna se- mántica puede forzar tal diseño, sino que sólo puede iluminar lo que resulta deseable de hacer. En este modelo semántico, no se requiere la especificación del flujo F para representar los com- portamientos que resultan debido a la invocación del servicio; simplemente define la invocación del servicio A con ciertos parámetros, y de qué manera la respuesta a esa invocación afecta el subsiguiente procesamiento de F. Esto significa, por ejemplo, que cualquier servicio de bajo nivel invocado por el servicio A no necesita ser parte del ISH y del IRH del flujo F. Si así fuera, la especificación de F no debería cambiar si el servicio A fuera modificado, por ejemplo, para invocar diferentes servicios de bajo nivel. Esta solución difiere de las semánticas funcionales tradicionales, en las que la especificación de F debería requerir la inclusión de todos los efectos sobre todas las invocaciones de servicios de bajo nivel por parte del servicio A como una parte de su especificación funcional.
Esta solución para la especificación es clave para el mantenimiento del control intelectual sobre la especificación y diseño del flujo. Como se denotara, se pueden modelar flujos determinísticos que invocan servicios no-determinísticos asincrónicos mediante funciones matemáticas deter- minísticas, haciendo mucho más simple el razonamiento y el análisis humano. Alternativamen- te, si el comportamiento de los flujos fuera no-determinístico, entonces los mismos flujos se podrían volver mucho más complicados, y podrían necesitar que sus semánticas fueran expresa- das como una relación matemática desde el dominio IxIRH hacia el rango OxISH. Esta situa- ción compleja se evita mediante las semánticas FSQ.
Las semánticas de flujos descriptas anteriormente se adecúan de manera particular con la situación Flujo F Servicio A O IRH ISH I
común en la que el servicio A ya existe sobre una red, o es provisto por componentes COTS o a medida con funciones complejas y, posiblemente, desconocidas. En casos en los que el servicio A es nuevo y debe ser diseñado como parte de la implementación del flujo F, estas semánticas de flujos se pueden combinar con métodos tradicionales de diseño y verificación tal como aquéllas que se encuentran en las estructuras basadas en objetos [Mills 86] para soportar el razonamiento acerca del comportamiento combinado del sistemas compuesto por F y A. De esta manera, el comportamiento deseado de F y de A se puede utilizar para guiar la construcción de A. En particu- lar, las estructuras proveen representaciones orientadas a la historia, el estado y el procedimiento de flujos y servicios, y métodos para su abstracción, refinamiento y verificación.
Los conceptos y técnicas de las Estructuras de Flujos aplicados a los flujos de red se pueden escribir en casi cualquier lenguaje imperativo, incluidos C++ y Java, siempre que el lenguaje incluya el conjunto básico de estructuras de control, en particular, secuencia, alternancia e itera- ción. Las especializaciones y extensiones de estas estructuras también resultan valiosas. Las invocaciones de servicio en estos lenguajes son llamados a métodos sobre objetos. Se puede definir un Lenguaje de Estructura de Flujo FSL (Flow Structure Lenguaje) que captura la esencia de los conceptos FSQ independientemente de la sintaxis del lenguaje de implementación específico. Para hacer frente a la concurrencia dentro del propio flujo, también se ha incluido en FSL una estructura concurrente. Debido a que los aspectos específicos de los tipos de datos y la sintaxis de declaración del lenguaje no afectan la aplicabilidad de FSQ, estas características pueden perder énfasis en el FSL. La Figura 35 ilustra las típicas estructuras de control de FSL.
Figura 35. Estructuras de control típicas de FSL.
El comportamiento global de un flujo particular es el siguiente: se invoca un flujo con valores asignados a sus parámetros de entrada, y al finalizar la ejecución del flujo, los valores finales de salida de los parámetros se devuelven al invocador del flujo, ya sea un usuario humano u otro flujo. Un flujo puede definir datos locales no persistentes para almacenar valor intermedios pro- ducidos por las computaciones del flujo. Finalmente, un flujo puede invocar servicios para rea- lizar varias actividades en red o locales, incluidas almacenado, acceso o modificación de datos persistentes. El diseño del flujo implica que el estado persistente requerido por un flujo debería estar encapsulado dentro de los servicios.
Además de las estructuras de secuencia, alternancia, iteración y concurrencia, el FSL contiene una sentencia “use” para invocar servicios. La sentencia invoca predicados post-fix para evaluar y poner en práctica equivalencias de clases definidas por el diseñador sobre el conjunto de todas las posibles respuestas, tanto deseado como no-deseadas. Esta división y análisis de equivalen- cia de clases de la respuesta atiende el requerimiento de hacer frente a los Factores Inciertos característicos del comportamiento en red, y a las implicancias sobre la supervivencia que ellos imponen. Los diseñadores de flujos seleccionan los servicios claves para este análisis de res- puesta. La sintaxis general de la sentencia use es la siguiente:
use <service>.<method>(<parameters>) response <status_variable> is
<enumerated_value_1> when <expression> | <enumerated_value_2> when <expression> | ...
| <enumerated_value_n> when <expression>;
Por ejemplo, la siguiente sentencia use ilustra la invocación a una base de datos de reservas de avión para realizar una reserva en un vuelo:
use Airline.reserve(customer, flight, date, result, seat) response status is
NOTRESERVED when result = false
| RESERVEDNOSEAT when (result = true) and (seat = “”) | RESERVEDWITHSEAT when (result = true) and (seat !=””); Además de la enumeración explícita de las equivalencias de clases sobre la respuesta, también se pueden evaluar los parámetros basados en la red y el estado del componente (por ejemplo, NOTCONNECTED, NORESPONSE). Tales evaluaciones son importantes en cuanto a la valo- ración y puesta en práctica de las propiedades dinámicas de una red.
Un conjunto de Teoremas FSQ captan y exploran los fundamentos de las semánticas FSQ. En
el Anexo 5 se describen teoremas de ejemplo. Las pruebas están más allá del alcance de este trabajo, y se pueden encontrar en [Pleszkoch 02].