1 DESARROLLO BASADO EN COMPONENTES
Un componente es una entidad de software que puede ser utilizado sin necesidad de ser modificado en las aplicaciones de software las cuales están bajo el control de los desarrolladores del componente. Los usuarios de los componentes pueden ajustar el comportamiento según las parametrizaciones permitidas por los creadores del componente sin necesidad de acceder al código fuente.
Los componentes ofrecen su funcionalidad a través de interfaces de exportación y pueden utilizar la funcionalidad ofrecida por otros componentes para implementar las funcionalidades ofrecidas a través de las interfaces para importar.
Como ventajas se tiene que el cambio de un componente no implica la actualización en los demás componentes ya que el ofrecimiento y consumo de las funcionalidades es independiente de su implementación actual, ofreciendo múltiples posibilidades para desarrollos futuros de implementación. Otra ventaja comparada con los conceptos orientados a objetos es que ofrece ambientes de ejecución estandarizados en forma de servidores de aplicaciones o plataformas ligeras las cuales ofrecen un uso declarativo de servicios especiales, independientes como autorización, localización, persistencia o administración de transacciones por componentes. Para que un componente pueda ser usado la funcionalidad de la plataforma, los contratos de los componentes especiales de la plataforma deben ser implementados.
2 ARQUITECTURA DE SOFTWARE BASADA EN SERVICIOS (SOA)
Es una arquitectura diseñada para crear ambientes organizados de servicios interconectados que pueden ser compuestos e interoperables. SOA es un estilo de arquitectura en donde
Pág. 55 de 58
funcionalidades nuevas o existentes son empaquetadas como servicios12 que hacen disponibles sus funcionalidades a través de interfaces de forma transparente para el usuario. La funcionalidad de los nuevos servicios implementados es soportada por componentes.,La funcionalidad de sistemas existentes puede ser encapsulada utilizando conectores para estar disponible como un servicio.
Los servicios se pueden utilizar directamente o integrarse en los procesos de negocio de los usuarios. Estos procesos resultan de la composición de actividades individuales donde cada actividad puede requerir acceso manual o ser implementada para el uso de servicios. Su implementación puede ser soportada en un servicio aislado o con una composición de servicios. La composición de servicios existentes ofrece un servicio de mayor valor para los procesos de negocio y los usuarios.
3 ARQUITECTURA MULTINIVEL
A continuación se presenta el porqué la arquitectura multinivel ayuda a cumplir con los requerimientos de No funcionales explicados anteriormente:
• Separación de lógica de negocio y almacenamiento de datos: permite independizar los desarrollos de los tipos de bases de datos (relacionales y orientadas a objetos) y de los desarrolladores de bases de datos. Permite responder a crecimiento de requerimientos (disponibilidad y rendimiento), por lo que la base de datos puede ser cambiada sin necesidad de cambiar la lógica de negocio.
• Separación de presentación y lógica de negocio: permite ofrecer una solución técnica con soporte óptimo a la presentación multicanal, permite mejorar la capacidad de actualización, flexibilidad, reusabilidad y reproducibilidad, al tiempo que permite reducir los costos en el mediano plazo. Durante la operación de la aplicación, esta tendrá efecto positivo en mejorar la escalabilidad, capacidad de actualización y la seguridad. Sin embargo es necesario poner especial atención en la comunicación, para evitar que una distribución poco óptima, afecte el rendimiento.
• Separación de cliente y presentación: para no tener que instalar clientes separados por cada aplicación, el acceso uniforme a través del browser es recomendado. Se pueden generar diferentes presentaciones para diferentes clientes de acuerdo con los respectivos requerimientos.
Pág. 55 de 58
Pág. 55 de 58
Pág. 56 de 58
• La separación de cliente, lógica de presentación, lógica de negocio, y almacenamiento de datos, convierten una arquitectura en multinivel de 4 capas:
o Capa cliente: es donde los usuarios y el software interactúan. Se visualizan los datos procesados por la lógica de presentación y la interfaz de usuario. La capa del cliente representa diferentes canales de acceso reflejando los diferentes usuarios, terminales, rutas de transmisión, al igual que la interacción con otras aplicaciones especiales. Como posibles terminales de presentación están:
Acceso Web a través de browser
Teléfonos móviles y Asistentes digitales personales (PDA’s) Aplicaciones externas
o Capa presentación: procesa los datos de aplicación por el cliente y la interacción entre los usuarios y la aplicación. Incluye todos los estándares para comunicación con los terminales relevantes en la capa del cliente.
o Capa intermedia: se refiere a la capa de negocios. Implementa la lógica de negocios separada de la presentación y de los procesos de datos de la capa de persistencia. Está soportada por las bases de servicios y componentes. Es donde la secuencia del programa es controlada y dirige la interacción entre los servicios y componentes.
o Capa persistencia: es la responsable del almacenamiento de los objetos de datos. Esta capa abstrae de la base de datos.
Pág. 57 de 58
Anexo 2. PALABRAS CLAVE A UTILIZAR PARA INDICAR NIVELES DE
REQUERIMIENTO (RFC 2119)
Network Working Group S.Bradner
Request for Comments: 2119 Harvard University
BCP: 14 Marzo 1997
Categoría: Mejor práctica actual
Palabras clave a utilizar en RFC para indicar Niveles de Requerimiento. ESTATUS DE ESTE MEMORANDUM:
Este documento especifica una mejor práctica actual de Internet para la comunidad Internet, y solicita su discusión y sugerencias para posibles mejoras. La distribución de este memorándum es ilimitada.
RESUMEN:
En muchos documentos de seguimiento estándar se usan varias palabras para indicar los requerimientos de la especificación. Estas palabras a menudo están en mayúsculas. Este documento define cómo deberían ser interpretadas estas palabras en documentos IETF. Los autores que sigan estas instrucciones deberían incorporar esta frase cerca del principio de sus documentos:
Las palabras claves "DEBE", "NO DEBE", "REQUERIDO", "OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este documento serán interpretadas como se describe en RFC 2119.
Nótese que la contundencia de estas palabras está modificada por el nivel de requerimiento del documento en el que son usadas.
1. DEBE: esta palabra, o los términos "REQUERIDO", "OBLIGATORIO" o "DEBERÁ", significa que la definición es un requerimiento insoslayable de la especificación.
2. NO DEBE: esta frase, o la frase "NO DEBERÁ", significa que la definición es una prohibición insoslayable de la especificación.
3. DEBERÁ: esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir razones válidas en determinadas circunstancias para ignorar un elemento determinado, pero que la totalidad de las consecuencias deben ser comprendidas y cuidadosamente sopesadas antes de elegir otros derroteros.
Pág. 58 de 58
4. NO DEBERÁ: esta frase, o la frase "NO RECOMENDADO", significa que pueden existir razones válidas en determinadas circunstancias en las que el comportamiento en particular sea útil o incluso aconsejable, pero que la totalidad de las consecuencias deben ser comprendidas y cuidadosamente sopesadas antes de implementar cualquier comportamiento descrito bajo esta etiqueta.
5. PUEDE: esta palabra, o el adjetivo "OPCIONAL", significa que un elemento es realmente opcional. Un proveedor puede elegir incluir el elemento porque un mercado en particular lo necesite o porque el proveedor sienta que realza el producto aunque otro proveedor pueda omitir el mismo elemento. Una implementación que no incluya una opción determinada DEBE estar preparada para interoperar con otra implementación que incluya la opción, aunque quizá con reducida funcionalidad. En el mismo orden de cosas, una implementación que incluya una opción en particular DEBE estar preparada para interoperar con otra implementación que no incluya la opción (excepto, por supuesto, para la característica que aporte la opción).
6. Guía de uso de estos imperativos: los imperativos del tipo definido en este memorando deben ser usados con cuidado y con mesura. En particular, sólo DEBEN ser utilizados donde sea realmente necesario para la interoperación o para limitar un comportamiento potencialmente dañino (por ejemplo, limitando retransmisiones). Esto es, no deben ser usados para intentar imponer un método concreto a los implementadores cuando el método no sea necesario para la interoperabilidad.
7. Consideraciones de seguridad: estos términos se utilizan normalmente para especificar comportamientos con implicaciones de seguridad. Los efectos sobre la seguridad de no implementar un DEBE o DEBERÍA, o hacer algo que la especificación dice NO DEBE o NO DEBERÍA ser hecho, pueden ser muy sutiles. Los autores de documentos deberían tomarse su tiempo para elaborar las implicaciones de seguridad respecto a no seguir recomendaciones o requerimientos, ya que la mayoría de los implementadores no tienen el beneficio de la experiencia y de la discusión que produjo la especificación.
8. Agradecimientos: las definiciones de estos términos son una amalgama de las definiciones tomadas de numerosos documentos RFC. Además, se han incorporado sugerencias de numerosas personas incluyendo a Robert Ullmann, Thomas Nartenm Neal McBurnett, y Robert Elz.
DIRECCIÓN DEL AUTOR:
Scott Bradner Harvard University 1350 Mass. Ave. Cambridge, MA 02138 Phone - +1 617 495 3864
Email - [email protected]