Que es el Objeto XMLHttpRequest

XMLHttpRequest (XHR), también referida como XMLHTTP (Extensible Markup Language / Hypertext Transfer Protocol), es una interfaz empleada para realizar peticiones HTTP y HTTPS a servidores Web. Para los datos transferidos se usa cualquier codificación basada en texto, incluyendo: texto plano, XML, JSON, HTML y codificaciones particulares específicas. La interfaz se implementa como una clase de la que una aplicación cliente puede generar tantas instancias como necesite para manejar el diálogo con el servidor.

El uso más popular, si bien no el único, de esta interfaz es proporcionar contenido dinámico y actualizaciones asíncronas en páginas WEB mediante tecnologías construidas sobre ella como por ejemplo AJAX.

La primera versión de la interfaz XMLHttpRequest fue desarrollada por Microsoft que la introdujo en la versión 5.0 de Internet Explorer.1 Esta primera versión se publicó utilizando un objeto ActiveX, lo que significa que podía ser utilizada desde cualquier entorno de desarrollo de software con soporte para esta tecnología, es decir, la práctica totalidad de plataformas generalistas de desarrollo para Microsoft Windows. Microsoft ha seguido manteniendo y actualizando esta tecnología incluyendo la funcionalidad dentro del Microsoft XML Parser (MSXML) en sus sucesivas versiones. A partir de la versión 7 de Internet Explorer la interfaz se ofrece de manera integrada.1 Al ser integrada, el acceso a la interfaz se realiza enteramente con objetos (JScript o VBScript) proporcionados por el navegador y no mediante bibliotecas externas.

El proyecto Mozilla incorporó la primera implementación integrada de XMLHttpRequest en la versión 1.0 de la Suite Mozilla en 2002. Esta implementación sería seguida por Apple a partir de Safari 1.2, Konqueror, Opera Software a partir del Opera 8.0 e iCab desde la versión 3.0b352.

El World Wide Web Consortium presentó el 27 de septiembre de 2006 el primer borrador de una especificación estándar de la interfaz.2 La versión actual de 17 de enero de 2012, denominada XMLHttpRequest Level 2 es el resultado de varias revisiones.3

Mientras no se alcance una versión definitiva, los desarrolladores de aplicaciones WEB deberán tener en cuenta las diferencias entre implementaciones o bien utilizar paquetes o frameworks que realicen esta función.

El 25 de febrero de 2008 se publicó la primera versión de la especificación XMLHttpRequest Level 2. Esta nueva especificación, que se inicia antes de haber publicado la versión definitiva de la interfaz, pretende añadir nuevas funciones como: peticiones entre dominios (cross-site), eventos de progreso y manejo de flujos de bytes (streams) tanto para el envío como para la recepción.

XMLHttpRequest es una interfaz para realizar llamadas mediante HTTP, por lo que es recomendable un buen conocimiento de este protocolo. Es importante el manejo correcto de la cache en el servidor HTTP, en los proxy cache intermedios y en el navegador WEB.

La interfaz se implementa en una clase de la que se debe crear una nueva instancia mediante el constructor adecuado. Es posible realizar peticiones síncronas y asíncronas al servidor. Cuando las operaciones son síncronas la ejecución del programa se detiene hasta que se completa la operación. En una llamada asíncrona el flujo de proceso no se detiene a esperar la respuesta sino que esta continúa en segundo plano y se define un manejador de evento que se ejecutará cuando se complete la petición.

Otro elemento importante en la especificación, es el manejo de juegos de caracteres u hojas de códigos. La codificación y decodificación de texto y su la identificación de los juegos de caracteres mediante cabeceras HTTP y tipos MIME. El estándar XMLHttpRequest recomienda UTF-8 para la codificación de cadenas de texto.3

Para determinar la codificación de los datos transmitidos se usa el siguiente algoritmo, utilizando la primera opción que se cumpla:

Si los datos transmitidos son XML o HTML, y así se identifica mediante la correspondiente cabecera Content-Type de HTTP, la codificación se detectará siguiendo las reglas de XML o HTML según corresponda.
Si la cabecera HTTP especifica un tipo MIME mediante Content-Type e identifica un juego de caracteres se utiliza dicho juego de caracteres.
Si los datos enviados especifican un BOM válido, se utilizará la variante UTF determinada por dicho BOM.
Utilizar UTF-8.

Si no se identifica correctamente la codificación, existe el riesgo de que en un sistema en el que se mezclen varias codificaciones puedan producirse errores de visualización de caracteres. Por ejemplo al incorporar funcionalidad AJAX, que por defecto utiliza UTF-8, a una página WEB codificada con ISO 8859-1.

fuente.http://es.wikipedia.org/wiki/XMLHttpRequest

SOAP – Server y Cliente en PHP con Nusoap

Introducción

Antes que nada no voy a entrar en detalles del protocolo sino de como implementarlo con php, pero me consta que lo correcto es al menos aclarar, aunque sea repetitivo, que significan estas siglas.
Sin meterme mucho en el tema puedo contarles que SOAP son las siglas de siglas de Simple Object Access Protocol, el cual obviamente es un protocolo que fue creado por varios grosos (MS, IBM, Etc), y su fuente de datos es el XML con un diseño que cumple el patrón Cabecera-Desarrollo y que actualmente está auspiciado por la W3C.

Es un protocolo que se usa mucho para webservices, y por lo tanto, para hacer una petición desde un cliente se necesita una respuesta desde un servidor.

Si lo que se desea es crear un cliente, el cual hace peticiones a un SOAP servidor que no es nuestro, la tarea será más simple. Ahora, si lo que se desea es tener un cliente, ya el enfoque es otro aunque nada complicado, ya lo verán.

Lo único a tener en cuenta es que debemos contar con una directiva del php.ini indispensable para su funcionamiento, ésta es la directiva always_populate_raw_post_data la cual debe estar en ON.

Otra necesidad es poder tener algo con cual poder escribir y parsear este xml, para ellos tenemos dos opciones: una es usar las funciones que nos da php al habilitar una dll, para más información de esto pueden ver la documentación de php en php.net/soap; dos, usar nusoap, una clase hecha para esta tarea, la cual permite crear cliente, servidor.

Para ser más prácticos les mostraré un simple ejemplo de un servidor y un cliente.

Primer paso, tener nuestro servidor.

Para comenzar no podremos avanzar sin antes tener nuestra querida librería nusoap. En este ejemplo he usado la versión 0.7.2, la cual pueden descargar desde aqui.

Una vez en sus máquinas, pueden descomprimir el directorio lib del zip en un directorio nuestro llamado “include” (o el nombre que más les guste). No es necesario mover los ejemplos, pero si gustan pueden darle una mirada, cosa que nunca está de más.

Para usar esta clase todo lo que debemos hacer en nuestro php es incluirla. Entonces, creamos un php que se llame server.php, y en él escribimos:

<?
require_once(’includes/nusoap.php’);
?>

Ahora bien, necesitamos crear un objeto del tipo servidor, eso es simple, lo hacemos instanciando el método soap_server, nos quedaría algo así:

<?
require_once(’includes/nusoap.php’);
$server = new soap_server;
?>

Bien, hasta acá venimos bárbaro, pero me olvide de comentarles que la tarea de un servidor es la de servir. Claro que este comentario es obvio!, pero para el caso no se preguntan que es lo que servirá mi servidor? Pues no más que datos es la respuesta que pensarán y es correcta. El tema es nuestros datos se servirán en base a una petición del cliente mediante funciones, tal cual cuando usamos funciones nuestras del tipo getUser( $id ).

Entonces, para procesar de manera simple una petición haremos una función en php, una simple función, por ejemplo:

function hola( $name ){
return “Hola {$name}”;
}

De más esta decir que puedo tener todas las funciones necesarias y estas estar en un archivo aparte, pero para el ejemplo es lo mismo.

Ahora bien, aquí viene lo interesante del servidor y es que registraremos en nuestro SOAP la función que acabamos de crear de la siguiente manera:

$server->register( ‘hola’ );

Solo nos resta tomar toda la petición del cliente, y esto lo haremos con la variable de php llamada $HTTP_RAW_POST_DATA la cual contiene el post en bruto. En caso de no contar con la directiva always_populate_raw_post_data en ON como dijimos, pueden intentar setearla de la siguiente manera, aunque no garantizo su funcionamiento ya que depende de otras configuaraciones del servidor web y OS:

$rawPost = strcasecmp($_SERVER[‘REQUEST_METHOD’], ‘POST’) == 0? (isset($GLOBALS[‘HTTP_RAW_POST_DATA’])? $GLOBALS[‘HTTP_RAW_POST_DATA’] : file_get_contents(”php://input”)) : NULL;

Una cosa que no esta de más es validar el dato que nos manda el cliente, para esto podemos modificar la función para crear un fault, quedando así:

function hola( $name ){
return empty( $name ) ? new soap_fault(’Client’,”,’Ingrese un nombre válido’) : “Hola ” . $name;
}

Ahora, como está todo en partes, para sintetizar quedaría así nuestro achivo que llamaremos para el ejemplo servidor.php:

<?
$rawPost = strcasecmp($_SERVER[‘REQUEST_METHOD’], ‘POST’) == 0? (isset($GLOBALS[‘HTTP_RAW_POST_DATA’])? $GLOBALS[‘HTTP_RAW_POST_DATA’] : file_get_contents(”php://input”)) : NULL;
require_once(’includes/nusoap.php’);
$server = new soap_server;
$server->register(”hola”);
$server->service($rawPost);
function hola( $name ){
return empty( $name ) ? new soap_fault(’Client’,”,’Ingrese un nombre válido’) : “Hola ” . $name;
}
?>

Solo resta nuestro cliente para poder probarlo, que como les decía es mucho más simple.
El mismo todo lo que debe hacer es llamar a nuestro servidor haciendo llamada a la función hola y pasarle un parámetro que es lo que ésta espera.

Para ellos creamos cliente.php, incluimos nuevamente la clase nusoap, e instanciamos al método soapclient pasándole como parámetro la url de nuestro servidor. Una vez creado el objeto haremos un método call a nuestra función hola y le pasaremos los parámetros necesarios, tan simple como esto:

<?
require_once(’includes/nusoap.php’);
$soapclient = new soapclient(’http://tudominio.com/nusoaptest/server.php’);
echo $soapclient->call( ‘hola’ , array(’name’ => ‘Mundo’) );
?>

Ya tenemos nuestro servidor y nuestro cliente…

Con el servidor podemos servir o procesar peticiones de un cliente cualquiera. Con nuestro cliente podemos llamar a un servidor y usar sus prestaciones.

Historia de los Web Services

Los Servicios Web surgieron ante una necesidad de estandarizar la comunicación entre distintas plataformas (PC, Mainframe, Mac, etc.) y lenguajes de programación (PHP, C#, Java, etc.).

Anteriormente se habían realizado intentos de crear estándares pero fracasaron o no tuvieron el suficiente éxito, algunos de ellos son DCOM y CORBA, por ser dependientes de la implementación del vendedor DCOM – Microsoft, y CORBA – ORB (a pesar que CORBA de múltiples vendedores pueden operar entre si, hay ciertas limitaciones para aplicaciones de niveles más altos en los cuales se necesite seguridad o administración de transacciones).

Otro gran problema es que se hacía uso de RPC (Remote Procedure Call) para realizar la comunicación entre diferentes nodos. Esto, además de presentar ciertos problemas de seguridad, tiene la desventaja de que su implementación en un ambiente como es Internet, es casi imposible (muchos firewalls bloquean este tipo de mensajes, lo que hace prácticamente imposible a dos computadoras conectadas por Internet comunicarse).

Los Web Services surgieron para finalmente poder lograr la tan esperada comunicación entre diferentes plataformas. En la actualidad muchos sistemas legacy están pasando a ser web services.

Es por esto que en 1999 se comenzó a plantear un nuevo estándar, el cual terminaría utilizando XML, SOAP, WSDL, y UDDI.

¿Los Web services pueden ser solo utilizados con HTTP?

A pesar de mucho limitar el uso de los Web services al protocolo HTTP, los Web services no fueron pensados para un protocolo en particular, es decir, nada nos impide utilizar SOAP sobre algún otro protocolo de Internet (SMTP, FTP, etc.).

Se utiliza principalmente HTTP por ser un protocolo ampliamente difundido y que se encuentra menos restringido por firewalls (generalmente se bloquean puertos como el FTP, pero el HTTP es muy probable que no este bloqueado).

¿Que es NuSOAP? webservices rápido..

NuSOAP es un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP. Está compuesto por una serie de clases que nos harán mucho más fácil el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aquellos que consumen los Web Services) y de servidores (aquellos que los proveen). NuSOAP está basado en SOAP 1.1, WSDL 1.1 y HTTP 1.0/1.1

¿NuSOAP es el único soporte para Web Services en PHP?

No, no es el único, existen otros, pero es uno de los que están en una fase de desarrollo mucho más avanzada. Sin ir más lejos, PHP a partir de su versión 5 comienza a dar soporte para SOAP, pero aún está en fase experimental.

¿Por qué NuSOAP y no otro?

  1. Está en una fase madura de desarrollo.
  2. No necesita módulos adicionales.
  3. Es muy fácil su instalación y uso

¿Cómo instalo NuSOAP?

La instalación es bastante sencilla, sólo basta ir a la pagina en sourceforge de NuSOAP http://sourceforge.net/projects/nusoap/ y bajar el archivo comprimido (es un .zip).

Lo descomprimimos en un directorio de nuestro servidor web (como puede ser /lib que es el directorio por default), y listo, ya podemos hacer uso de NuSOAP.

Quees SOAP?

SOAP es Simple Object Access Protocol, un estándar propuesto por Microsoft, IBM y otros al Consorcio WWW (W3C) para el intercambio de mensajes entre servicios web y los consumidores de estos servicios.

El protocolo SOAP esta construido sobre XML y solo describe el formato de los mensajes dejando abierta la posibilidad de usar varios transportes, aunque actualmente el transporte usado es HTTP. La elección de HTTP como transporte se debe a que es el transporte más usado, y si una organización de cualquier tipo provee una sola salida o conexion con el mundo exterior (internet) lo mas probable es que sea HTTP.

El protocolo define un “sobre” (envelope) en el que se empaqueta el requerimiento donde se especifica el destinatario de la llamada, el nombre del método que se invoca y opcionalmente una serie de parametros con tipos definidos. La respuesta a este requerimiento se empaqueta de la misma forma, en un “sobre” que contiene el resultado del método invocado.

Para qué sirve?
La utilidad de este mecanismo consiste en que con un conjunto de servicios simples se puede implementar aplicaciones que entreguen funcionalidad valiosa mediante la integración de estos servicios básicos o mediante el uso programático de estos.

SOAP se enmarca dentro de lo que se llama “component based arquitectures”, o sea arquitecturas basadas en componentes. Aqui la idea básica es que es mas facil identificar ciertas tareas que se programan muchas veces y en lugar de programarlas cada vez que se requieren es mas eficiente hacerlas una vez de manera que puedan ser invocadas desde una variedad de aplicaciones clientes o, para usar un termino mas moderno, “consumidores de servicios”. De esto se desprende una de las cualidades fundamentales que debe tener la tecnología necesaria para crear componentes y es que debe ser muy flexible permitiendo incorporarla con la misma facilidad a aplicaciones en plataformas muy diversas, por ejemplo una aplicación web escrita en PHP o JSP, una aplicación de escritorio en Visual Basic o C++ o una aplicación servidor en Java.

Otras tecnologías que persiguen estos objetivos son por ejemplo la arquitectura COM de Microsoft o la arquitectura CORBA de OMG que permiten la invocación de métodos de objetos que pueden ser remotos. La ventaja de SOAP frente a estos esquemas es que es mas sencillo de implementar y dado que es XML via HTTP el vocabulario y el método de transporte son ubicuos en la actualidad.