El trmino POA es usado para referirse a varias tecnologas relacionadas como los mtodos adaptivos, los filtros de composicin, la programacin orientada a sujetos o la separacin multidimensional de competencias, no es un paradigma en si, ni tampoco una expansin de la programacin orientada a objetos, es una nueva metodologa de programacin que aspira a soportar la separacin de competencias para los aspectos, esta expansin se da debido a que en a POO se escribe bastante cdigo para realizar una accin en si, lo cual ocasiona que ese cdigo se disperse y se vuelva difcil de controlar para programacin, los objetos a modo de ejemplo se pueden hacer referencia a un animal, en este caso un perro, con sus distantas caractersticas.

La programacin orientada a aspectos es soportado por los llamados lenguajes de aspectos, que proporcionan constructores para capturar los elementos que se diseminan por todo el sistema. Los lenguajes orientados a aspectos definen una nueva unidad de programacin de software para encapsular aquellos conceptos que cruzan todo el cdigo. los diferentes mecanismos de abstraccin y composicin que aparecen tanto en los lenguajes de aspectos, como en los lenguajes de componentes, guiado por los puntos de enlace. Mientras que un aspecto no se puede encapsular en un procedimiento con los lenguajes tradicionales

Los lenguajes orientados a aspectos definen una nueva unidad de programacin de software para encapsular las funcionalidades que cruzan todo el cdigo. Adems, estos lenguajes deben soportar la separacin de aspectos como la sincronizacin, la distribucin, el manejo de errores, la optimizacin de memoria, la gestin de seguridad, la persistencia. De todas formas, estos conceptos no son totalmente independientes, y est claro que hay una relacin entre los componentes y los aspectos, y que por lo tanto,El cdigo de los componentes y de estas nuevas unidades de programacin tienen que interactuar de alguna manera. El encargado de realizar este proceso de mezcla se conoce como tejedor (del trmino ingls weaver).La estructura general de una implementacin basada en aspectos difiere de la estructura de una implementacin tradicional. Una implementacin tradicional consiste de un lenguaje, un compilador, o interprete para ese lenguaje, y finalmente, un programa escrito

Un lenguaje para definir la funcionalidad bsica. Este lenguaje se conoce como lenguaje base. Suele ser un lenguaje de propsito general, tal como C++ o Java. En general, se podran utilizar tambin lenguajes no imperativos. Uno o varios lenguajes de aspectos. El lenguaje de aspectos define la forma de los aspectos por ejemplo, los aspectos de AspectJ se programan de forma muy parecida a las clases. Un tejedor de aspectos. El tejedor se encargar de combinar los lenguajes. El proceso de mezcla se puede retrasar para hacerse en tiempo de ejecucin, o hacerse en tiempo de compilacin.

Considera la implementacin del protocolo TFTP (Trivial File Transfer Protocol) con y sin aspectos, con el objetivo de aplicar y evaluar la POA. La versin sin aspectos es la versin TFTP 0.8 de Mark Benvenuto, realizada en Java, de distribucin libre.Sin embargo, se debieron introducir algunas modificaciones especficas para el tratamiento de los aspectos.La comparacin de ambas implementaciones permite obtener relevantes conclusiones y evaluar con resultados concretos la verdadera dimensin de las ventajas de la POA.

Tejiendo clases y aspectos

Los aspectos describen apndices al comportamiento de los objetos. Hacen referencia a las clases de los objetos y definen en qu punto se han de colocar estos apndices. Puntos de enlace que pueden ser tanto mtodos como asignaciones devariables.

Las clases y los aspectos se pueden entrelazar de dos formas distintas: de manera esttica o bien de manera dinmica:

Entrelazado esttico:

Implica modificar el cdigo fuente de una clase insertando sentencias en estos puntos de enlace. Es decir, que el cdigo del aspecto se introduce en el de la clase. Un ejemplo de este tipo de tejedor es el Tejedor de Aspectos de AspectJ .

La principal ventaja de esta forma de entrelazado es que se evita que el nivel de abstraccin que se introduce con la programacin orientada a aspectos se derive en un impacto negativo en el rendimiento de la aplicacin. Pero, por el contrario, es bastante difcil identificar los aspectos en el cdigo una vez que ste ya se ha tejido, lo cual implica que si se desea adaptar o reemplazar los aspectos de forma dinmica en tiempo de ejecucin nos encontremos con un problema de eficiencia, e incluso imposible de resolver a veces.

Entrelazado dinmico

Una precodicin o requisito para que se pueda realizar un entrelazado dinmico es que los aspectos existan de forma explcita tanto en tiempo de compilacin como en tiempo de ejecucin .

Para conseguir esto, tanto los aspectos como las estructuras entrelazadas se deben modelar como objetos y deben mantenerse en el ejecutable. Dado un interfaz de reflexin, el tejedor es capaz de aadir, adaptar y borrar aspectos de forma dinmica, si as se desea, durante la ejecucin. Un ejemplo de este tipo de tejedores es el Tejedor AOP/ST , que no modifica el cdigo fuente de las clases mientras se entrelazan los aspectos. En su lugar utiliza la herencia para aadir el cdigo especfico del aspecto a sus clases.

Estado del Arte en el Diseo de Lenguajes de Aspectos

En este apartado se comentan las distintas tendencias que se siguen en loslenguajes de aspectos.

Hasta ahora se han distinguido dos enfoques diferentes en el diseo de los lenguajes de aspectos: los lenguajes de aspectos de dominio especfico y los lenguajes de aspectos de propsito general.

Esta Compuesto por:

Lenguajes de Aspectos de Propsito General vs. Dominio Especfico.

Un lenguaje de dominio especfico: COOL

Un lenguaje de propsito general: AspectJ

Lenguajes de Aspectos de Propsito General vs. Dominio EspecficoLos lenguajes de aspectos de dominio especfico soportan uno o ms de estos sistemas de aspectos que se han ido mencionando en las secciones anteriores (distribucin, coordinacin, manejo de errores, ...), pero no pueden soportar otros aspectos distintos de aquellos para los que fueron diseados. Los lenguajes de aspectos de dominio especfico normalmente tienen un nivel de abstraccin mayor que el lenguaje base y, por tanto, expresan los conceptos del dominio especfico del aspecto en un nivel de representacin ms alto.

Estos lenguajes normalmente imponen restricciones en la utilizacin del lenguaje base. Esto se hace para garantizar que los conceptos del dominio del aspecto se programen utilizando el lenguaje diseado para este fin y evitar as interferencias entre ambos. Se quiere evitar que los aspectos se programen en ambos lenguajes lo cual podra conducir a un conflicto. Como ejemplos de lenguajes de dominio especfico estn COOL , que trata el aspecto de sincronizacin, y RIDL , para el aspecto de distribucin.

Un lenguaje de dominio especfico: COOCOOL es un lenguaje de dominio especfico creado por Xerox [2] cuya finalidad es la sincronizacin de hilos concurrentes. El lenguaje base que utiliza es una versin restringida de Java, ya que se han de eliminar los mtodos wait, notify y notifyAll, y la palabra clave synchronized para evitar que se produzcan situaciones de duplicidad al intentar sincronizar los hilos en el aspecto y en la clase.

En COOL, la sincronizacin de los hilos se especifica de forma declarativa y, por lo tanto, ms abstracta que la correspondiente codificacin en Java.

COOL proporciona mecanismos para trabajar con la exclusin mutua de hilos de ejecucin, el estado de sincronizacin, la suspensin con guardas, y la notificacin de forma separada de las clases.

Un lenguaje de propsito general: AspectJ

AspectJ es una extensin a JavaTM orientada a aspectos y de propsito general [14]. AspectJ extiende Java con una nueva clase de mdulos llamado aspecto. Los aspectos cortan las clases, las interfaces y a otros aspectos. Los aspectos mejoran la separacin de competencias haciendo posible localizar de forma limpia los conceptos de diseo del corte.En AspectJ, un aspecto es una clase, exactamente igual que las clases Java, pero con una particularidad, que pueden contener unos constructores de corte, que no existen en Java. Los cortes de AspectJ capturan colecciones de eventos en la ejecucin de un programa. Estos eventos pueden ser invocaciones de mtodos, invocaciones de constructores, y excepciones de seales y gestin. Los cortes no definen acciones, sino que describen eventos.

En defnitiva, en AspectJ los aspectos son constructores que trabajan al cortar de forma transversal la modularidad de las clases de forma limpia y cuidadosamente diseada [18]. Por lo tanto, un aspecto puede afectar a la implementacin de un nmero de mtodos en un nmero de clases, lo que permite capturar la estructura de corte modular de este tipo de conceptos de forma limpia.

En general, un aspecto en AspectJ est formado por una serie de elementosCortes:Los cortes (pointcut) capturan colecciones de eventos en la ejecucin de un programa. Estos eventos pueden ser invocaciones de mtodos, invocaciones de constructores, y sealizacin y gestin de excepciones. Los cortes no definen acciones, simplemente describen eventos. Un corte est formado por una parte izquierda y una parte derecha, separadas ambas por dos puntos. En la parte izquierda se define el nombre del corte y el contexto del corte. La parte derecha define los eventos del corte.

Los cortes se utilizan para definir el cdigo de los aspectos utilizando avisos.

A los descriptores de eventos de la parte derecha de la definicin del corte se les llama designadores. Un designador puede ser:

Un mtodo. Un constructor.Un manejador de excepciones.

Se pueden componer utilizando los operadores o (|), y (&) y no (!).

Tambin se pueden utilizar caracteres comodines en la descripcin de los eventos.

Introducciones:

Las introducciones (introduction) se utilizan para introducir elementos completamente nuevos en las clases dadas. Entre estos elementos podemos aadir:

Un nuevo mtodo a la clase.Un nuevo constructor.Un atributo.Varios de los elementos anteriores a la vez.Varios de los elementos anteriores en varias clases.

Avisos:

Las declaraciones de avisos (advice) definen partes de la implementacin del aspecto que se ejecutan en puntos bien definidos. Estos puntos pueden venir dados bien por cortes con nombre, bien por cortes annimos. En las dos siguientes figuras se puede ver el mismo aviso, primero definido mediante un corte con nombre, y despus mediante uno annimo.

El cuerpo de un aviso puede aadir en distintos puntos del cdigo, cada uno de los cuales se define mediante una palabra clave:

Aviso before.- Se ejecuta justo antes de que lo hagan las acciones asociadas con los eventos del corte.

Aviso after.- Se ejecuta justo despus de que lo hayan hecho las acciones asociadas con los eventos del corte.

Aviso catch.- Se ejecuta cuando durante la ejecucin de las acciones asociadas con los eventos definidos en el corte se ha elevado una excepcin del tipo definido en la propia clusula catch.

Aviso finally.- Se ejecuta justo despus de la ejecucin de las acciones asociadas con los eventos del corte, incluso aunque se haya producido una excepcin durante la misma.

Aviso around.- Atrapan la ejecucin de los mtodos designados por el evento. La accin original asociada con el mismo se puede invocar utilizando thisJoinPoint.runNext().

Los avisos se pueden declarar con el modificador static, indicado esto que se ejecuta el mismo aviso para todas las instancias de las clases designadas.Si se omite indica que solamente se ejecuta para ciertas instancias.

Arquitectura orientada a servicios

La Arquitectura Orientada a Servicios (en ingls Service-Oriented Architecture o SOA), es un concepto de arquitectura de software que define la utilizacin de servicios para dar soporte a los requerimientos de software del usuario.

SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integracin y consolidacin.

En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayora de las definiciones de SOA identifican la utilizacin de Servicios Web

Definiciones SOA Servicio Una funcin sin estado auto-contenida, que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden tambin ejecutar unidades discretas de trabajo como seran editar y procesar una transaccin. Los servicios no dependen del estado de otras funciones o procesos.Orquestacin Secuenciar los servicios y proveer la lgica adicional para procesar datos. No incluye la presentacin de los datos. Coordinacin.Sin estado No mantiene ni depende de condicin pre-existente alguna. En una SOA los servicios no son dependientes de la condicin de ningn otro servicio. Reciben en la llamada toda la informacin que necesitan para dar una respuesta.Proveedor La funcin que brinda un servicio en respuesta a una llamada o peticin desde un consumidor.Consumidor La funcin que consume el resultado del servicio provisto por un proveedor.

Diseo y desarrollo de SOA

La metodologa de modelado y diseo para aplicaciones SOA se conoce como anlisis y diseo orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantacin. Cuando la mayora de la gente habla de una arquitectura orientada a servicios estn hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios Web. Hay un juego de estndares de los que se habla ligados a los servicios Web. Incluyen los siguientes:

XML Es extensible, lo que quiere decir que una vez diseado un lenguaje y puesto en produccin, igual es posible extenderlo con la adicin de nuevas etiquetas de manera de que los antiguos consumidores de la vieja versin todava puedan entender el nuevo formato.

Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo. Mejora la compatibilidad entre aplicaciones. La tecnologa XML busca dar solucin al problema de expresar informacin estructurada de la manera ms abstracta y reutilizable posible.

HTTP es el protocolo usado en cada transaccin de la Web.HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de "sesin", y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

SOAP desarrolladores de aplicaciones pueden utilizar la infraestructura de correo electrnico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrnico de texto o como adjuntos. Los ejemplos que se muestran a continuacin muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estndar de hacerlo. Las especificaciones SOAP Versin 1.2 no especifican tal vnculo

WSDL describe la interfaz pblica a los servicios Web. Est basado en XML y describe la forma de comunicacin, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catlogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan despus al protocolo concreto de red y al formato del mensaje. As, WSDL se usa a menudo en combinacin con SOAP y XML Schema. Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar que funciones estn disponibles en el servidor.

UDDI son las siglas del catlogo de negocios de Internet denominado Universal Description, Discovery and Integration. El registro en el catlogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes:Pginas blancas - direccin, contacto y otros identificadores conocidos. Pginas amarillas - categorizacin industrial basada en taxonomas. Pginas verdes - informacin tcnica sobre los servicios que aportan las propias empresas.

Nos permite observar tambin, que los lenguajes orientados a aspectos actuales, no cuentan con mecanismos lingsticos suficientemente poderosos. Estos mecanismos son necesarios para respetar por completo todos los principios de diseo, como por ejemplo, el encapsulamiento.Debido a esto, plantea nuevas lneas de investigacin tales como: analizar como aplicar aspectos en las otras etapas del ciclo de vida del software, en el anlisis, en el diseo.En primer termino, al separar la funcionalidad bsica de los aspectos, se aplica con mayor intensidad el principio de dividir y conquistar.