This project is read-only.
OBJETIVO DEL DOCUMENTO
El objetivo de este documento es definir las alternativas tecnológicas que serán utilizadas para la construcción del SGEESS (Sistema de gestión de Estaciones de Servicio) del Automóvil Club Argentino (ACA). Es el resultado de decisiones de negocio tomadas por el ACA y de decisiones tecnológicas tomadas por el equipo del ACA y M3.
La elaboración de este documento abarca aspectos de Arquitectura, Topología, Estrategias de Construcción del Software y las características del producto que se generara.
La referencia al sistema en construcción dentro del documento se realizara mediante el acrónimo SGEESS.

Alcance
Este documento aplica al Proyecto del SGEESS y a las interfaces con otros sistemas con los que interactúa.


Referencias
Documentos de discusión de arquitectura catalogados para el proyecto como “Serie de discusiones técnicas sobre la arquitectura y topologías”

Discusiones: Conjunto de documentos denominado “Discusiones Técnicas sobre Arquitectura y Topologías”
Diseño técnico: ACA Sistema de Gestión de Estaciones -Especificación Migracion.doc
Arquitectura: ACA Sistema de Gestión de Estaciones -Especificación Arquitectura Parte II.doc



OBJETIVOS DEL NEGOCIO, CONTEXTO, HIPÓTESIS Y SUPUESTOS

El Automóvil Club Argentino (al que llamaremos con el acrónimo que se conoce en el mercado A.C.A.), cuenta con una línea de negocios que es la venta minorista (retail) en estaciones de servicio. Estas estaciones de servicio provén combustibles y lubricantes de la línea YPF, ofrecen productos de utilidad para el viajante, repuestos para el automotor, servicios al socio y servicios adicionales como lavado, engrase, mecánica menor, gomería y estacionamiento.-
La atención de este modelo de negocios se basa en dos modalidades: explotación directa o por concesión. Es decir existe un área física donde el negocio se produce y a la que llamaremos ESTACION DE SERVICIO o DEPENDENCIA.
En la DEPENDENCIA se prestan los SERVICIOS de:
Venta de combustibles y lubricantes de la línea YPF
Venta de productos comprados por el ACA a terceros y comercializados en forma minorista
Servicios de mini-mercado, desayuno y comidas rápidas
Servicios adicionales como gomería, lavado, engrase, estacionamiento, etc.
Estos SERVICIOS, desde el punto de vista del negocio del A.C.A. son la composición de prestaciones que brindan uno o más CONCESIONARIOS del SERVICIO en la DEPENDENCIA o el ACA en forma directa.
Los CONCESIONARIOS o el ACA en forma directa operan el negocio en la DEPENDENCIA en todas o algunas de estas modalidades según se detalla:

Vendiendo los productos que entrega el ACA (PRODUCTOS CONSIGNADOS o CONSIGNADOS sencillamente) (Ambos)
Vendiendo el combustible y lubricante para automotores, que provee YPF en acuerdo con el ACA (Ambos)
Prestan los SERVICIOS ADICIONALES al automotor (gomería, engrase,…) (Ambos)
Venden los productos no consignados por el ACA (PRODUCTOS PROPIOS o PROPIOS sencillamente) (concesionario)
Prestan SERVICIOS ADICIONALES al viajante como mini mercado y comida rápida con productos PROPIOS o CONSIGNADOS (Ambos)
Servicios varios de cobranzas y pagos (ACA)

En esta operación del negocio existen entonces las siguientes figuras:

EL A.C.A. (representado por un JEFE de DEPENDENCIA y su equipo) son los administradores de la dependencia y quienes controlan la operación y los intereses del A.C.A. en el negocio.

El CONCESIONARIO, que actúa en la dependencia prestando un SERVICIO. Observar que habiendo varios servicios en la dependencia, existirá la posibilidad de que exista más de un concesionario en la misma

YPF. Que es el proveedor de combustibles y lubricantes y de la tecnología de administración e interfaz de los aforadores y tanques

EL CLIENTE que es cualquier persona física que consume productos, servicios, combustibles o lubricantes.

El PLAYERO que es quien despacha en las islas de carga de combustible despachando productos, servicios, combustibles o lubricantes y emite facturas por los servicios que se prestan y los productos que se venden.

El CAJERO que es quien despacha en el local/mini-shopping/mini mercado y emite facturas por los servicios que se prestan y los productos que se venden tanto en el local como opcionalmente en la playa.

El CAJERO ACA que es quien despacha en el local y realiza cobranzas por los servicios que se prestan al socio y los productos que se venden en el local y pagos a proveedores del ACA



VALOR

La heterogeneidad de participantes y actores (DEPENDENCIA del ACA, ADMINISTRADOR del ACA, CONCESIONARIO, PROVEEDOR DE COMBUSTIBLE) así como los escenarios de lo que se vende (SERVICIO ADICIONAL al automotor, repuestos, productos varios, PROPIOS, CONSIGNADOS, SERVICIO ADICIONAL al viajante .etc.) y los posibles formas de venta (CONTADO, CUENTA CORRIENTE, PAGO CASH, PAGO TRAJETA) crean escenarios variados y en ciertos casos complejos.
El valor percibido por el cliente sobre la solución propuesta estará basado en (el orden no indica relevancia):

Trazabilidad de la operación. El sistema debe informar el estado de la operación de la dependencia tanto al JEFE de la DEPENDENCIA (A.C.A.) como al CONCESIONARIO, así como a los ADMINISTRADORES CENTRALES del A.C.A. de cada operación consolidada durante un día de actividad.

Sencillez de comunicación. Las figuras del JEFE de la DEPENDENCIA y los CONCESIONARIOS del SERVICIO indican la existencia de intereses y empresas distintas. La operatoria de venta sin embargo es el objetivo común de los participantes. Y el control de esta operatoria debe realizarse de modo que la información se comunique a cada parte del modo más sencillo conforme los intereses de cada parte.

Alta disponibilidad para la facturación. El sistema debe asegurar la operación en línea de la facturación, ya que el expendio y la logística son manejados por otros sistemas u otras mecánicas. La alta disponibilidad de la facturación dependerá de características de la instalación de hardware, la confiabilidad del cableado, las comunicaciones y los mecanismos de redundancia. Todo esto se considero en la propuesta de arquitectura de infraestructura y el software desarrollado se adecuara a los distintos modos de operación normal y de contingencia. Las variantes de infraestructura y desarrollo para esta disponibilidad del sistema forman parte de los trade-offs con los que se presenta la arquitectura del producto.

Sencillez de administración. EL A.C.A. considera de valor que siendo un sistema:

 Distribuido de aplicaciones cliente
 Trabajando como cliente servidor
 Con bases de datos en cada dependencia y sincronizadas a través de replicas mediante archivos con un repositorio central
 Con operaciones que deben considerarse ON LINE (pedido a la espera de respuesta) y ASAP (envío tan pronto como sea posible)

, la administración del sistema mantenga sencillez.
Las discusiones que se mantuvieron sobre la arquitectura topológica, reflejadas en el Documento de Migración, analizaron esta sencillez compatibilizándola del mejor modo posible con la operatoria del negocio, la plataforma de hardware, el servicio de comunicaciones, el software de infraestructura y los servicios previstos de soporte para proveer la decisión que se entendió más equilibrada entre sencillez, robustez y costo.

Panorama de servicio. La operatoria dentro de la DEPENDENCIA es compleja, pudiendo un cliente utilizar distintos servicios ADICIONALES del automotor así como la carga de combustible y lubricantes. El sistema permitirá que toda la operación en la dependencia sea manejado como una única orden de trabajo en la que las actividades de todos los servicios (quizás distintos CONCESIONARIOS)

A los efectos de acordar el valor de los aspectos centrales de la propuesta trabajaremos estos puntos y otros que se considere preciso agregar y estableceremos con el cliente una clasificación de utilidad ordinal como la siguiente tabla u otra similar que el equipo considere adecuada:

F Nulo Beneficios que provee son nulos. Indica que el cliente no ve valor en lo propuesto
D Adecuado Hay beneficios, pero apenas alcanzan la expectativa
C Satisfactorio Beneficios al nivel esperado de prestación del producto
B Deseable Beneficios adicionales, por encima de lo esperado
A Ideal Beneficios que se ven como nuevo valor al negocio

El valor no es cuantificable, sino que es la percepción del beneficio. Sera habilidad de los arquitectos del producto y los del sistema informático poder mostrar el costo implícito de cada beneficio percibido.



Características y Restricciones de Diseño

Como contexto de las discusiones que incluyen a la Arquitectura de diseño del producto SGEESS, se indican elecciones y decisiones del cliente. La mayoría reflejadas en el documento de la ronda previa “Documento de Migración”.

A) Utilizar versiones con funcionalidad reducida para los servicios de bases de datos como SQL Server 2008 Express. Aun cuando habrá sitios en los que puedan instalarse las versiones SQL Server Estándar, la arquitectura y la topología deberán diseñarse considerando esta restricción.
B) Comunicaciones entre los nodos (Estaciones de servicio) y la casa central (V-sat como el de menor prestación), permitiendo que a través de los vínculos de comunicación puedan utilizarse servicios WCF para TRANSFERENCIA DE ARCHIVOS, consultas ON LINE y envíos ASAP
C) Cada EESS tendrá al menos un servidor de bases de datos (SQL Server 2008) y un servidor de aplicaciones de servicios de Internet (IIS). Esto permitirá la comunicación utilizando los protocolos de Internet (HTTP, SMTP), ello se podrá utilizar procesos críticos para la arquitectura general del sistema, como la transferencia de archivos y la comunicación on-line que requieren ciertas y puntuales operaciones de venta.
D) Cada EESS o dependencia, tendrá una única base de datos centralizada en la que desarrollaran sus actividades los distintos concesionarios. En algunas de ellas, las de mayor volumen de actividad , nivel de facturación, o valor de negocio para el ACA, existirán esquemas de alta disponibilidad como equipos con versiones de SQL Server donde se contara con opciones de mirroring y log shipping de modo de garantizar la disponibilidad y el recupero ante caídas. En otras se contara con versiones de SQL Server Express y las tareas de backup para recupero de caídas deberán hacerse mediante scripts Transact SQL y servicios escritos ad-hoc.

Requerimientos no Funcionales

Marcas de Tecnología e Infraestructura

El sistema SGEESS será construido para plataformas del SO Windows y su lógica estará escrita en C# de tecnología .NET y usara como backend un motor SQL Server (2008)

La elección del SO Windows sobre el que se ejecutara es una decisión corporativa del cliente. Se utilizara Windows Server 2008 en los servidores de aplicaciones y base de datos de las EESS y sistemas operativos Windows XP o superior en los puestos cliente.
La elección del lenguaje de construcción es por considerarlo el fabricante (Microsoft) la “Lingua Franca” de las tecnologías de desarrollo de .NET
La base de datos, SQL Server 2008 (en versiones Express y Estándar) se ha elegido por considerarla la mejor mezcla de prestación, consistencia tecnológica y seguramente costos, frente otras opciones posibles como por ejemplo ORACLE.


Todas las opciones son avaladas como las mejores elecciones para el entorno elegido en tanto el cliente ha decidido utilizar tecnologías de Microsoft.

Modelos de Construcción

A) Si bien existe una tendencia actual en los desarrollos de sistemas informáticos en los que se considera a los motores de bases de datos como meros repositorios de datos, esta no es la visión en el diseño de la arquitectura del sistema.
Parte importante de la operación reposara en objetos de la base (Stored procedures, vistas y triggers) que estarán relacionados o con lógica de objetos de las aplicaciones o con servicios escritos al efecto. La elección de colocar lógica en objetos de la base de datos se hará de modo racional reservándose esta opción para aquellos procesos que por su naturaleza hacen uso intensivo de consultas y transacciones para la obtención del resultado final. Un ejemplo de esto son los procesos de generación de información para transferencia de archivos de novedades.

B) Las aplicaciones punto de venta, BackOffice y administración que son parte del SGEESS serán construidas como aplicaciones clientes Windows (WinForms). Esto presentara la ventaja de la mejor prestación visual y de respuesta a los usuarios, no previéndose que ninguno de los aplicativos creados para este proyecto sean aplicaciones WEB



C) Existirán casos donde la comunicación entre nodos de la red debe realizarse como una consulta en la que se establece un dialogo a la espera de respuesta. Llamamos en general a estos procesos ON LINE entendiéndose así a los procesos que en el medio de una operación necesitan de un servicio de llamada remota y deben esperar dicha respuesta para poder continuar. Un caso clásico es la consulta sobre la característica de un cliente que se presenta como socio o el envío de una transacción de la que se espera confirmación de recibo para continuar como el caso de la entrega de ciertos premios. Los procesos ON LINE serán desarrollados como servicios en la tecnología Windows Comunication Foundation. La técnica permitirá que dicha lógica encapsulada, puede posteriormente migrarse a otro tipo de protocolo de transporte provisto por Microsoft

D) Existirán otros casos en los que la comunicación entre los nodos de la red puede hacerse mediante secuencias planificadas de envió. Llamamos a esta operación TRANSFERENCIA de ARCHIVOS entendiéndose así a los procesos que pueden trabajar independientemente, pero que reposan en mecanismos por naturaleza asíncronos, que realizan envío de información a los nodos de la red. La transferencia de archivos opera con procesos de la base de datos que extraen información de novedades, envío desde el nodo en el que es generada a un nodo de concentración y transacción de esta información en los nodos destinos. La transferencia de archivos reposa en el diseño STORE and FORWARD del sistema. Este es por ejemplo el modo de replicar información que permitirá que las operaciones de venta, altas, etc. realizadas en las EESS o en la CC puedan ser conocidas por los nodos de la red que deban informarse.

E) Existirán casos en los que la comunicación será realizada enviando novedades de la operación desde las EESS a la CC mediante procesos a los que denominaremos ASAP (As Soon As Possible). La característica de estos procesos es que correrán por periodos de tiempo planificado con rondas de tiempo pequeñas (quizás del orden de ejecución cada 1, 3 o 5 minutos (este periodo deberá ser configurable)) y que el delivery de la información lo realizaran contra servicios instalados en el sistema central que los recibirán y lo entregaran para que terceros sistemas finalmente los procesen. Si este delivery se realiza contra el sistema que finalmente los procesa o contra uno intermedio dependerá si el sistema de terceros mencionado, expone servicios WEB o no. En el caso que el receptor en CC sea parte de este sistema SGEESS el mismo tendrá las características de un Servicio WEB o WCF que expondrá métodos para recibir esta información y el delivery contra sistemas de terceros será a través de archivos planos en formatos a acordar.

F) Uso del modelo de construcción conocido como ORM (Object-Relational Model). Este paradigma es el aceptado como estado del arte para la construcción de software mediante objetos y la comunicación con la capa de persistencia. La construcción del software utilizara este modelo que ejemplifica la pieza de código siguiente:


public void PersistirPlanFid()
{
FormulariosView form = new FormulariosView();

form.FrmCod = "TNF";
form.FrmDsc = "TKT No Fiscal";
form.FrmCantVias = 1;

FormulariosHandler.Persist(form);

PlanFidView plan = new PlanFidView();

plan.PFCodigo = "SOC";
plan.PFDescrip = "ACA SOCIOS";
plan.Formularios = form;

PlanFidHandler.Persist(plan);
}

G) Generación automática de entidades persistibles y CRUD. Otra característica que se utilizara de las operaciones que ofrece un ORM es la generación de las tablas del modelo a partir de las entidades (clases de lógica C#) y la generación de los procesos de Insert, Delete y Update de estas entidades bajo el modo de stored procedures estándar. La pieza de código siguiente muestra un estándar posible de generación de scripts de entidades (en el ejemplo para la acción de DELETE)

CREATE PROCEDURE dbo.f_Atributo_Delete
(
@pId INT
)
AS
SET NOCOUNT ON

DELETE
Atributo
WHERE
Atributo.Id = @pId

--


Atributos de calidad del producto de software

Eficiencia de los procesos en la base de datos: Todos los procesos que se ejecuten sobre la misma base de datos a los efectos de tareas de acciones de negocio como por ejemplo las actualizaciones de precios, la generación de archivos de transferencia y el envío de información ASAP se escribirán y diseñaran con los máximos criterios de eficiencia. Entendiéndose por esto que harán el menor uso posible en tiempo de los recursos críticos del procesador para otras operaciones: Memoria, Procesador y Bus de Entrada y salida a disco.

Eficiencia de la operación en los puntos de venta: Todo el diseño de la interfaz de usuario y la lógica de operación de la aplicación debe asegurar la mayor eficiencia de la operación de los playeros y cajeros. Esta eficiencia se medirá en la sencillez y rapidez con la que se accede a la información de despacho. Sobre todo en la operación del playero, el acceso a la información de despacho (mangueras) y la consulta de servicios al socio, deben ser las guías para medir esta eficiencia.

Mantenible: A los efectos de ser un software mantenible, deberá construirse conforme a patrones de diseño aceptados. Todos los entornos tienen indicadores o normas para esta actividad denominada genéricamente CODE ANALYISIS o STATIC CODE ANALYSIS. En el caso particular del entorno .NET en el que se realizaran los desarrollos centrales del sistema el grado de complejidad será medida con la herramienta (Plugin) incluida en el Visual Studio Team System 2008Ver información al respecto en: http://blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx.


Sobre el cálculo y significado del “Maintainability Index”: http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx.


Portabilidad El sistema no está pensado para ser portable entre sistemas operativos. Esto en tanto el lenguaje origen (C#) y la tecnología de contenedores usado (.NET) es exclusiva del SO Windows. Si el fabricante de esta tecnología .NET (Microsoft) y terceros proveedores acordasen versiones de contenedores .NET que al igual que las maquinas virtuales Java, corriesen sobre distintos SO, el software debería ejecutarse de un modo transparente

Seguridad Los conceptos de seguridad del SGEESS están centrados en el modo en el que se proveen servicios de acceso a los datos, en el modo en el que se exponen los servicios que proveen (WCF) y como viaja la información entre nodos.

Entendible La confección del software, la relación de sus partes y el modo en que se documenta la construcción, deben hacerlo entendible. El logro de esta cualidad se buscara en el código, la estructura de módulos, el agrupamiento de espacios nominados (namespaces) y la herramienta que se utiliza (TFS) para gestionar configuración. Esta última será utilizada de modo de producir trazabilidad entre los pedidos y el código construido. Se lograra mediante el uso racionalizado del Framework CIRCO que se adapta a una aplicación totalmente transaccional y constituida esencialmente por relaciones entre entidades de negocio.

Modularidad El software estará construido por módulos del menor tamaño posible conservando estos la funcionalidad y la coherencia. Este objetivo se alcanza si se logra modificar el modo de trabajo del modulo sin afectar (grandemente) a los otros módulos que interactúan con el (se utilizará como referencia al documento de Microsoft “App Arch Guide2.0a”).

Interfaz de usuario consistente. Se trabajara presentando interfaces de operación del usuario para los distintos usos previstos. En esencia deben generarse los siguientes modelos de interfaces de usuario (GUI):

1- Para el puesto de venta en playa para su tarea de venta de combustibles y lubricantes
2- Para el cajero de shopping
3- Para los Jefes de la dependencia y los administradores de las EESS
4- Para las operaciones de configuración y mantenimiento de los distintos administradores del sistema (BackOffice)

Los colores e iconos serán los mismos a lo largo de cualquier aplicación del sistema. Las aplicaciones administrativas (es decir aquellas que no van en el punto de venta) tendrán el modelo de construcción que llamamos MDI (Multiple Document Interface). Ya que es una Interfaz contenedora que permite incluir documentos variados.



Aquellas aplicaciones que tengan el patrón de ABMs o Configuradores presentaran los menús
En la misma secuencia, utilizando el mismo modo de acceso mediante teclas rápidas.

Los menús presentaran sub-menús cubriéndose reglas de uso que ayuden al usuario a visualizar claramente




Confiabilidad. Llamemos así al periodo en el que el software permanece consistente, estable y uniforme sin mayor intervención humana que la prevista para su operación (uso y mantenimiento). Esta característica se la dará el buen diseño, así como las pruebas que se realicen antes de la salida en vivo. Este es un aspecto esencial para decidir sobre la confiabilidad del producto.
Las pruebas (test) funcionales y de operación se deberán realizar basados en casos (casos de prueba) y laboratorios (escenarios de prueba). Esto último es crítico para tener medidas reales sobre tiempos de duración de una transacción de venta, consultas on line a CC, envíos de archivos de novedades, etc.
También existirán, para los casos que así lo requieran, test unitarios sobre reglas de negocio específicas y también sobre procesos que deban ser medidos ante una carga específica (de stress). Estos serán previamente consensuados entre los equipos de arquitectura de M3 y ACA.



Para eso definamos un neologismo que va de la mano con la confiabilidad:

Testeabilidad: Definamos este atributo como la característica que tendrá el sistema para facilitar y establecer criterios de prueba y determinar que dichos criterios se han cumplido.

Trazabilidad: Se asumen los siguientes criterios de trazabilidad de Requerimientos:
Las funcionalidades del software a construir salen de la lista de requerimientos y las discusiones sobre requerimientos guiadas a través de historias.
Estas funcionalidades se pueden resumir a través de procesos de negocios relatados en documentos funcionales.
Existe una lista acordada de relaciones entre Requerimientos vs. Procesos de Negocio en Especificaciones Funcionales que permite definir los procesos de negocios principales. Estas relaciones se plasman en una planilla de matriz de trazabilidad, activo que actualmente se encuentra en desarrollo y que en breve se entregará al ACA, en donde se establecen las relaciones entre los requerimientos y los casos de uso, y los casos de prueba.

Los procesos de negocios principales son:

ARTICULOS: Referido al modo en el que los artículos (combustibles, lubricantes y otros productos) son agregados y clasificados dentro del sistema

CAJA: Referido al modo en el que la operación de una dependencia es controlada a través de cierres parciales durante el día y el cierre al finalizar el mismo. Incluye las rendiciones de playeros y cajeros de shopping

CONCESIONARIO ADMINISTRACION: Referido al modo en el que el concesionario y el administrador de la dependencia rinden sus ventas, clasifican la cuenta gestión y determinan el cierre denominado liquido-producto

CUENTAS CORRIENTES: referido al modo en el que se maneja esta modalidad de venta entre el concesionario y sus clientes y los clientes autorizados por el ACA que trabajan en esta modalidad

FACTURAR: Referido al proceso general que ocurre teas la venta que está compuesto por la IMPRESIÓN y los procesos de CIERRE (asiento en caja, en stock, en liquido producto, etc.)
IMPUESTOS: referido al proceso de cálculo de impuestos en los productos por sus propias características, las del cliente que compra y/o las de la localidad en la que se realiza la venta

PRECIOS: referido a los precios de los artículos, así como los momentos de aplicación de los cambios de precios (vigencia) y las categorizaciones de los mismos por familias

PROMOCIONES: referido a las políticas de beneficios para socios, clientes y público en general en la que determinados productos, combinaciones de productos o formas de pago tienen ventajas de compra

SOCIOS CLIENTES: referidos a la consulta de características y beneficios de los socios, las políticas de beneficios en el momento de las ventas y el envío de la información de estas ventas al sistema central del ACA

STOCK: Referido al stock físico de artículos, y sus puntos de reposición

VENTA EN PLAYA: referido a toda la actividad de venta del playero, la auto facturación y la comunicación con el CEM

VENTA DE PRODUCTOS Y SERVICIOS: referido a la venta de artículos en shopping y la prestación de servicios como lavado, engrase, gomería, etc.





SOLUCIONES TECNOLÓGICAS

Alternativas tecnológicas

Las alternativas analizadas durante las discusiones cubrieron:

A) Cantidad de servidores de base de datos en cada EESS
B) Mecánicas de backup y recupero de caídas en las estaciones con versiones SQL Server Express
C) Operación del puesto de venta en modo stand alone. Cantidad minina de información con la que puede resultar operable
D) Características físicas de los servidores de base de datos.
E) Implicancias de licenciamiento de las distintas versiones de SQL Server 2008.
F) Mecanismos de mirroring de base de datos y simulaciones posibles del mismo.
G) Vínculos entre estaciones de servicio y casa central
H) Uso de servicios WCF, Servicios Web y/o FTP para las transferencias de archivos, comunicaciones ON LINE y comunicaciones ASAP.
I) Como asegurar disponibilidad en las estaciones de servicio criticas

De dichas discusiones quedaron establecidos los criterios indicados en el Documento de Migración.



Alternativas Seleccionadas para la construcción e implantación del producto

Para la construcción y puesta operativa del SGEESS se han elegido las siguientes alternativas tecnológicas:

El sistema SGEESS será construido para plataformas del SO Windows dentro del Framework .NET. (3.0 y 3.5 compatible) Esta elección de construcción (versus la otra posible que es sobre las APIs de WIn32) se basa en la política e indicación de Microsoft respecto de cuál será la evolución de sus sistemas operativos y las tecnologías asociadas.-

La lógica estará escrita en C#, entendiendo quienes hacemos este diseño que es la “lingua franca” de la tecnología .NET y sobre la que deben entrenarse a los programadores que desarrollen en esta tecnología.
Esta elección nos parece por tanto como natural para desarrollos en SO Windows dentro de la plataforma .NET.


El modelo en el que se persistirá la información del SGEESS estará adecuado a un motor SQL Server 2008 Estándar o Express. Este es otro producto del fabricante del sistema operativo y de las tecnologías de desarrollo. El producto se considera maduro existiendo versiones corporativas del mismo desde el año 2000 (con SQL Server 2000).

El uso de Forms de Windows para las aplicaciones interactivas. Esto se ha decidido visto que la aplicación por su propia característica y distribución será lo que se llama una aplicación cliente pesado. Es decir las aplicaciones del SGEESS se instalaran en cada puesto de uso con sus componentes ejecutables, bibliotecas de enlace dinámico, assemblies y archivos de configuración.
En ese sentido la riqueza de interfaz que proveen los WinForms los hacen la elección adecuada para estos desarrollos.

El uso de WCF y servicios ad-hoc sobre clases WCF (Windows Common Foundation) para realizar comunicaciones ON LINE y ASAP (tal como se definieron en párrafos previos) es una elección preferida sobre otros mecanismos de transferencia. La construcción de Web Services para comunicación de servicios ON LINE y el consumo de los mismos se centra en operaciones que se realizan en el POS (Punto de venta) y que requieren de una confirmación inmediata de lo consultado para seguir adelante con la operación.
Esto significa que esas operaciones ON LINE se estarán haciendo entre un punto de venta y un servidor central del ACA.
El uso de servidores y clientes WCF se desarrollara y se utilizara para el modo de comunicación que hemos denominado ASAP. Esto permitirá que la información a transmitir sea atendida por procesos paralelos al que genero la información. De este modo será posible aplicar técnicas de reintentos y estados de envío que terminen asegurando el delivery a menos que alguna acción externa de un operador indique lo contrario.
Los servidores y clientes WCF también se utilizaran para el envió de los paquetes de archivos de transferencia.

Estrategias de Backup y restore. Estas estrategias estarán enmarcadas en los tiempos de respuesta que se acuerden para puesta en servicio de una caída. Estas estrategias serán producto de pruebas de laboratorio para mediciones reales de tiempo de operación para salir de fallas. EL detalle de estas actividades excede el marco de este documento. Pero lo que interesa marcar acá es que parte del producto esperado es contar con esta estrategia de Disaster Recovery, diferenciando la misma de la Disponibilidad del sistema. Esta última la ligamos a aspectos de hardware y software de Infraestructura, algunos de los cuales están mencionados en el Documento de Migración.


Last edited Jan 6, 2012 at 12:21 PM by eduardob, version 1

Comments

No comments yet.