2005 Octubre Archive at Serakesi

Octubre 18, 2005 No comments

Web Service

?Qu? es un Web Service?

Un Web Service es un componente de software que se comunica con otras aplicaciones codificando los mensaje en XML y enviando estos mensaje a trav?s de protocolos est?ndares de Internet como el HTTP. Es similar a un sitio web que no cuenta con un interfaz de usuario y que da servicio a las aplicaciones y no a las personas. En vez de obtener solicitudes desde el navegador y retornar p?ginas web como respuesta, lo que hace es recibir solicitudes a trav?s de un mensaje formateado en XML desde una aplicaci?n, realiza una tarea y devuelve un mensaje de respuesta tambi?n formateado en XML.

Para la comunicaci?n entre aplicaciones se utiliza SOAP, entre otras, como est?ndar de los mensajes para los Web Services. Un mensaje SOAP se parece mucho a una carta: es un sobre que contiene una cabecera con la direcci?n del receptor del mensaje, un conjunto de opciones de entrega (tal como la informaci?n de encriptaci?n), y un cuerpo o body con la informaci?n o data del mensaje.
Creando una capa de Web Services sobre una aplicaci?n corporativa existente, las organizaciones pueden permitir que sistemas externos puedan invocar las funciones de la aplicaci?n a trav?s de Internet (o una intranet corporativa) sin tener que modificar la aplicaci?n misma. Por ejemplo, varias compa??as est?n hoy en d?a creando Web Services que act?an como front end para aplicaciones de entrada de ?rdenes que est?n residentes internamente en un mainframe. Estas compa??as permiten a los sistemas de compras de sus clientes enviar ?rdenes de compra a trav?s de la Internet. Poner una capa de web services sobre las aplicaciones existentes es una soluci?n muy interesante para integrar las aplicaciones desarrolladas por los diferentes departamentos y as? reducir los costos de integraci?n.

Requisitos de un Web Service

Interoperabilidad: Un servicio remoto debe permitir su utilizaci?n por clientes de otras plataformas.
Amigabilidad con Internet: La soluci?n debe poder funcionar para soportar clientes que accedan a los servicios remotos desde internet.
Interfaces fuertemente tipadas: No deber?a haber ambig?edad acerca del tipo de dato enviado y recibido desde un servicio remoto. Los tipos de datos definidos en el servicio remoto deben poderse corresponder con los tipos de datos de la mayor?a de los lenguaje de programaci?n.
Posibilidad de aprovechar los est?ndares de Internet existentes: La implementaci?n del servicio remoto deber?a aprovechar est?ndares de Internet existentes tanto como sea posible y evitar reinventar soluciones a problema que ya se han resuelto.
Soporte para cualquier lenguaje: La soluci?n no deber?a ligarse a un lenguaje de programaci?n. Un cliente deber?a ser capaz de implementar un nuevo servicio Web existente independientemente del lenguaje de programaci?n en el que se halla escrito el cliente
Soporte para cualquier infraestructura de componente distribuida: La soluci?n no debe estar ligada a una infraestructura de componentes en particular. No se beber?a requerir el comprar, instalar o mantener una infraestructura de objetos distribuidos, solo construir un nuevo servicio remoto, utilizar un servicio existente.

Creo que con esto se puede tener una amplia noci?n del funcionamiento de un Web Service y su utilizaci?n.

Octubre 14, 2005 No comments

MVC como Patr?n de Dise?o

Todos los programadores, buscamos constantemente reutilizar c?digo una y otra vez en los proyectos en los que nos vamos metiendo. Cuando adquirimos experiencia, el sistema de programaci?n cada vez se acerca m?s a un sistema modular, basado en capas o grupos. Esto parece ser normal y ha dado lugar a los patrones de dise?o, que no son m?s que guiones a seguir para llegar a un mismo resultado.

De todos los patrones existentes, uno de ellos es el MVC que significa Modelo, Vista y Controlador.

Modelo Vista Controlador (MVC) es un patr?n de dise?o de software que separa los datos de una aplicaci?n, la interfaz de usuario y la l?gica de control en tres componentes distintos, de forma que las modificaciones al componente de la vista pueden ser hechas con un m?nimo impacto en el componente del Modelo de datos.

Definici?n de las partes:
El Modelo es todo acceso a base de datos, y las funciones llevan lo que llaman “L?gica de Negocio”. Se utiliza para manejar informaci?n y notificar los cambios realizados en dicha informaci?n.

La Vista es la responsable de mostrar los datos que recibe del Modelo. Cuando este cambia, la Vista redise?a autom?ticamente la parte afectada y solicita los servicios correctos al Modelo.

El Controlador es lo que une la Vista y el Modelo. Por ejemplo, son las funciones que toman los valores de un formulario, consultan la base de datos a trav?s del modelo y producen valores, que la Vista tomar? y convertir? en HTML. Regula el acceso del usuario a los datos y ordena que la Vista y el Modelo realicen las acciones basadas en la ese acceso. Si el usuario clica sobre un art?culo de un men?, el Controlador es el responsable de decidir cual va a ser la respuesta y la Vista la muestra.

El Modelo, la Vista y el Controlador, est?n constantemente en contacto, referenciados entre si.

En la figura siguiente, vemos la arquitectura MVC en su forma m?s general. Hay un Modelo, m?ltiples Controladores que manipulan ese Modelo y hay varias Vistas de los datos del Modelo, cambian cuando cambia el estado de ese Modelo.

Estructura MVC

Esta arquitectura presenta varias ventajas:

Hay una clara separaci?n entre los componentes de un programa; lo cual nos permite implementarlos por separado.

La conexi?n entre el Modelo y sus Vistas es din?mica; se produce en tiempo de ejecuci?n, no en tiempo de compilaci?n.

Al incorporar el modelo de arquitectura MVC a un dise?o, las piezas de un programa se pueden construir por separado y luego unirlas en tiempo de ejecuci?n. Si uno de los Componentes, posteriormente, se observa que funciona mal, puede reemplazarse sin que las otras piezas se vean afectadas.

Octubre 13, 2005 2 comentarios

Ajax

La primera vez que se habl? de la arquitectura AJAX fue a mediados de febrero. No se trata de una nueva tecnolog??a ni de un nuevo invento, sino de un concepto que aglutina tecnolog?as ya existentes, como la utilizaci?n de XHTML, CSS, DOM, Javascript, XML, XSL.
En las aplicaciones web tradicionales, los usuarios interact?an mediante formularios, que al enviarse, realizan una petici?n al servidor web. El servidor se comporta seg?n lo enviado y contesta enviando una nueva p?gina web. Se utiliza ancho de banda y normalmente la misma estructura de HTML devuelta est? presente en la p?gina de petici?n.

AJAX, puede enviar una petici?n al servidor y recibir ?nicamente la informaci?n necesaria, empleando SOAP para servicios web, basado en XML, y utilizando Javascript en el cliente para procesar la respuesta del servidor web. Procesando la informaci?n directamente en el cliente, liberamos al servidor de trabajo, consumiendo un m??nimo ancho de banda.

Esto da una sensaci?n de interacci?n parecida a las aplicaciones convencionales en local.

Una de las desventajas de AJAX, es que existe el riesgo de que el cliente tenga el Javascript de su navegador deshabilitado. Para ello se debe tener en cuenta y dar la posibilidad de trabajar con el refresco tradicional de las web sin el uso de AJAX.

Hay que saber que el usuario est? acostumbrado al sistema tradicional de refresco de la p?gina cuando cargan nuevos datos, con AJAX esto no sucede y por lo tanto se debe informar de alguna manera (mensaje de carga), que la p?gina est? cargando nuevos datos.

Tampoco es recomendable la utilizaci?n de grandes c?digos Javascript, ya que esto tambi?n puede afectar el ancho de banda y un aumento del tiempo de proceso, que puede llegar a bloquear el navegador y dejarlo colgado.

El concepto AJAX, est? siendo potenciado por numerosas aplicaciones realizadas por Google, como: Gmail, Google Groups, Google Suggest, Google Maps. As?? tambi?n Empresas en Crecimiento que actualmente est?n Desarrollando Aplicaciones en AJAX.

Enlaces a aplicaciones que utilizan AJAX: