• Generan código solo referente a los métodos básicos en las conexiones a la Base de datos, es decir, insertar, modificar, eliminar y en casos muy específicos consultas.
• No están orientados a una arquitectura, y para especificarle una se debe realizar todos los modelos correspondientes a la misma, siendo esto un trabajo muy engorroso y difícil de modelar.
• A veces deben ser demasiado detallados los diagramas para generar un simple código y otras veces no es posible a través de diagramas especificar lo que se quiere hacer.
• La mayoría de los generadores de código son aplicaciones de escritorio.

El análisis de la mayoría de las soluciones basadas en modelos de componentes por capas muestra que existen varios tipos de componentes habituales. En la figura 1.1 se muestra una ilustración completa en la que se indican estos tipos de componentes. Aunque la lista que se muestra en la figura no es completa, representa los tipos de componentes de software más comunes encontrados en la mayoría de las soluciones con una arquitectura en capas, orientada a objetos y servicios.

Componentes de lógica de negocio o empresariales. Independientemente de si el proceso consta de un único paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en la aplicación comercial, deberá implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente por el envío del mismo. Los componentes empresariales implementan la lógica empresarial de la aplicación.

Componentes de acceso a datos. La mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para obtener acceso a los datos en una capa independiente de componentes lógicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma.

4. Servicios. Cuando un componente empresarial requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la semántica de la comunicación con dicho servicio. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el servicio al formato que requiere la aplicación.

5. Componentes de seguridad: La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoria y administración de perfiles.

Cada componente tiene sus especificidades las cuales cumple funcionalidades de acuerdo al rol que tienen en la aplicación. A continuación se muestra una descripción un poco mas detallada por cada componente, para una mucha mejor comprensión de la arquitectura.

• No inicializan, participan ni votan en transacciones.
• Presentan una referencia al componente de proceso de usuario actual si necesitan mostrar sus datos o actuar en su estado.
• Pueden encapsular tanto la funcionalidad de visualización como un controlador.

Al aceptar la entrada del usuario, los componentes de la interfaz:

• Adquieren los datos del usuario y atienden su entrada utilizando guías visuales (como informaciones sobre herramientas) y sistemas de validación, así como los controles necesarios para realizar la tarea en cuestión.
• Capturan los eventos del usuario y llaman a las funciones de control para indicar a los elementos de la interfaz de usuario que cambien el modo de visualización de los datos, bien inicializando una acción en el proceso de usuario actual, o bien, modificando los datos del mismo.
• Restringen los tipos de entrada del usuario. Por ejemplo, un campo puede limitar las entradas del usuario a valores numéricos.
• Realizan la validación de entrada de datos, por ejemplo, restringiendo el intervalo de valores que se pueden escribir en un campo determinado, o garantizando que se escriben los datos obligatorios.
• Llevan a cabo la asignación y transformación simple de la información proporcionada por los controles del usuario en los valores necesarios para que los componentes subyacentes realicen su trabajo (por ejemplo, un componente de interfaz de usuario puede mostrar el nombre de un producto pero pasar el Id. del mismo a los componentes subyacentes).
• Interpretar las acciones del usuario (como las operaciones de arrastrar y colocar o los clics de botones) y llamar a una función de control.
• Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché.
• Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente, especialmente en las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados. Asimismo, se suele disponer de un componente de ayuda para realizar el seguimiento de la página actual en la que se encuentra el usuario y, por tanto, invocar a las funciones de consulta paginada de los componentes lógicos de acceso a datos con los valores adecuados relativos al tamaño de página y página actual. La paginación se puede realizar sin la interacción del componente de proceso de usuario.

• Básese lo más que pueda en la comunicación basada en mensajes.
• Asegúrese de que los procesos expuestos en las interfaces de servicios no se pueden alterar y que, por tanto, el estado de la aplicación o el servicio no perderá su coherencia si se recibe el mensaje dos veces.
• Elija con cuidado los límites de la transacción de modo que se puedan realizar reintentos y composiciones. Esto se aplica tanto a las transacciones atómicas como a las de ejecución larga. Asimismo, debe considerar el uso de reintentos para sistemas basados en mensajes, sobre todo al exponer la funcionalidad de la aplicación como un servicio.
• Los componentes empresariales se deben poder ejecutar en el contexto de cualquier usuario de servicio; no necesariamente suplantando a un usuario de una aplicación específica. Esto permite su invocación con mecanismos que ni transmiten ni delegan la identidad del usuario.
• Elija y mantenga un formato de datos coherente (como XML, conjunto de datos, etc.) para los parámetros de entrada y los valores de devolución.

Los componentes empresariales son llamados por los siguientes clientes:

• Interfaces de servicios.
• Componentes de proceso de usuario.
• Flujos de trabajo empresariales.
• Otros componentes empresariales.

En la figura1.2 se muestra un componente empresarial típico que interactúa con los componentes lógicos de acceso a datos, las interfaces y los agentes de servicios y otros componentes empresariales.

Obsérvese los siguientes puntos:

1. Los componentes empresariales pueden ser invocados por los componentes de las capas de presentación.
2. Los componentes empresariales pueden ser invocados por interfaces de servicios (por ejemplo, un servicio Web XML).
3. Los componentes empresariales pueden llamar a componentes lógicos de acceso a datos para recuperar y actualizar datos, y pueden invocar a otros componentes empresariales.
4. Los componentes empresariales también pueden invocar a agentes de servicios. Tenga especial cuidado al diseñar la lógica de compensación en caso de que el servicio al que desea tener acceso no esté disponible o lleve demasiado tiempo devolver una respuesta.

Al trabajar con datos debe determinar:

1. El almacén de datos que utiliza.
2. El diseño de los componentes utilizados para obtener acceso al almacén de datos.
3. El formato de los datos pasados entre componentes y el modelo de programación necesario para ello.

La aplicación o servicio puede disponer de uno o varios orígenes de datos, los cuales pueden ser de tipos diferentes. La lógica utilizada para obtener acceso a los datos de un origen de datos se encapsulará en componentes lógicos de acceso a datos que proporcionan los métodos necesarios para la consulta y actualización de datos. Los datos con los que la lógica de la aplicación debe trabajar están relacionados con entidades del mundo empresarial que forman parte de la empresa. En determinados escenarios, puede disponer de componentes personalizados que representan estas entidades, mientras que en otros puede decidir trabajar con datos utilizando directamente conjuntos de datos o documentos XML. La mayoría de las aplicaciones utilizan una base de datos relacional como almacén principal de los datos de la aplicación.

La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoría y administración de perfiles, tal como muestra la figura 1.3.

• Siempre que sea posible, se debe recurrir a sistemas de seguridad que se hayan comprobado y demostrado su eficacia en lugar de generar su propia solución personalizada.
• Nunca confiar en las aportaciones externas. Deberá validar todos los datos que introduzcan los usuarios o envíen otros servicios.
• Considerar por principio que los sistemas externos no son seguros. Si su aplicación recibe datos confidenciales sin cifrar desde un sistema externo, asuma que dicha información no es segura.
• Aplicar el principio del menor privilegio. No habilitar más atributos en las cuentas de servicios que los que resulten estrictamente necesarios para la aplicación. Obtener acceso a los recursos con cuentas que tengan los mínimos permisos necesarios.
• Reducir el área de superficie. El riesgo se incrementa según aumenta el número de componentes y datos que haya expuesto a través de la aplicación y, por lo tanto, se deberá exponer únicamente la funcionalidad que se crea que otros van a utilizar.
• Establecer como predeterminado un modo seguro. No habilitar servicios, tecnologías y derechos de cuenta que no sean absolutamente necesarios. Cuando se implemente la aplicación en equipos cliente o servidor, la configuración predeterminada de esta deberá ser segura.
• No confiar en la seguridad a través del ocultamiento. El cifrado de los datos implica disponer de claves y de un algoritmo de cifrado demostrado. El almacenamiento de los datos seguros evitará el acceso a ésta en cualquier circunstancia. No se puede considerar seguridad la mezcla de diversas cadenas, el almacenamiento de la información en rutas de archivo inesperadas y demás técnicas similares.
• Seguir los principios de STRIDE. (STRIDE responde a las siglas inglesas de Simulación, Alteración, Repudio, Revelación de información, Denegación de servicio y Elevación de privilegios). Todas estas son clases de vulnerabilidades de la seguridad contra los que un sistema se debe proteger.
• Realizar la comprobación desde la misma puerta. No permitir que los procesos vayan más allá del lugar para el que los usuarios están autorizados.
• Bloquear su sistema interna y externamente: los usuarios y operadores internos pueden representar un riesgo igual que los intrusos externos.

Además, con un buen uso una arquitectura en componentes se puede llegar a obtener un máximo rendimiento del generador de código que se utilice, así como una buena practica de lo métodos de construcción de software utilizando capas o componentes.

Referente al Autor:

Año de nacimiento: 1983.

Titulo: Ingeniero en Ciencias Informáticas.

Datos Adicionales: Trabajador de la Universidad de Ciencias Informáticas. Graduado con Titulo de Oro de Ingeniero en Ciencias Informáticas en dicha universidad.

Referente al Trabajo:

Ciudad: Ciudad de la Habana.

País: Cuba.

Fecha de Realización: febrero del 2008.