Archive

Archive for the ‘Informática e Internet’ Category

Crear un Web Service con PHP y MySQL (Introducción)

4 septiembre, 2013 Deja un comentario

Una API (Application Programming Interface o Interfaz de programación de aplicaciones) es un conjunto de funciones y métodos que ofrece una biblioteca que permite su utilización de forma remota como una capa de abstracción. Google, por ejemplo, tiene la Google SOAP Search API que permite a los desarrolladores consultar entre los millones de páginas web indexadas por Google directamente desde una aplicación cualquiera usando un Web Service, a través de los estándar SOAP y WDSL.

Un Web Service o Servicio Web, por su parte, es un sistema software diseñado para soportar la interoperabilidad de máquina a máquina en una red. En el contexto de aplicaciones Web, usualmente se refiere a un conjunto de APIs que se pueden acceder a través de Internet y ejecutar en un sistema remoto que aloja el servicio solicitado. Las máquinas interactúan con el Web service utilizando unos mensajes especiales llamodos SOAP que se han de establecer previamente.

Para conocer cómo se realiza el intercambio de mensajes en los Web Services debemos primero debemos entender los elementos fundamentales que lo componen. Estos son el XML, SOAP, WSDL, y UDDI.

XML (Extensible Markup Language)

Es un subconjunto simplificado del SGML (Standard Generalized Markup Language o Estándar de Lenguaje de Marcado Generalizado) que fue diseñado principalmente para documentos Web. Se caracteriza porque permite crear “etiquetas o tags propias (véase <libro>), habilitando la definición, transmisión, validación, y la interpretación de datos entre aplicaciones y entre organizaciones. Un punto que es importante aclarar es que el HTML y el XML tienen funciones diferentes. El HTML tiene por objeto mostrar información, mientras que el XML se ocupa de la información propiamente dicha (el contenido). Este concepto es importante tenerlo en cuenta, ya que muchas personas al escuchar sobre XML piensan que es el sucesor de HTML.

Ejemplo de un documento XML sobre información de autos:

<?xml version="1.0" encoding="UTF-8"?> 
<vehiculos> 
  <coche> 
      <marca>Toyota</marca> 
      <modelo>Corolla</modelo> 
      <fechaCompra>2002</fechaCompra> 
  </coche> 
  <coche> 
      <marca>Honda</marca> 
      <modelo>Civic</modelo> 
      <fechaCompra>2003</fechaCompra> 
  </coche> 
</vehiculos>

SOAP (Simple Object Access Protocol)

Es un protocolo que permite la comunicación entre aplicaciones a través de mensajes por medio de Internet. Es independiente de la plataforma, y del lenguaje. Está basado en XML y es la base principal de los Web Services. Los mensajes SOAP son documento XML propiamente dicho.

<?xml version="1.0"?>
<soap:Envelope  xmlns:soap="http://www.w3.org/2001/12/soap-envelope" 
        soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> 
    <soap:Header> 
        // Definición de la cabecera del mensaje. Incluye información específica del mensaje, 
        // como puede ser la autenticación.
    </soap:Header> 
    <soap:Body> 
        // Definición o descripción del cuerpo del mensaje, en esta sección se incorpora toda la información 
        // necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una
        // petición.
        <soap:Fault> 
            // Todos los fallos que se puedan producir se deben notificar aquí.
        </soap:Fault> 
    </soap:Body> 
</soap:Envelope>

Explicación del código anterior

  • <?xml version=”1.0″?> Como se puede apreciar, SOAP, es un documento XML, y como tal, debe comenzar con el tag <?xml….?> y la versión correspondiente.
  • <soap:Envelope indica que comienza el envelope (sobre) del mensaje.
  • xmlns:soap = “http://www.w3.org/2001/12/soap-envelope&#8221; que viene a decir que en un mensaje SOAP siempre se debe asociar el elemento envelope al namespace (espacio de nombres) http://www.w3.org/2001/12/soap-envelope.
  • soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”&gt; indica dónde se encuentran definidos los tipos de datos utilizados en el documento.
  • <soap:Header> indica el comienzo del Header (encabezado). En esta sección se incluye información específica del mensaje, como puede ser la autenticación.
  • </soap:Header> indica el final del Header (encabezado).
  • <soap:Body> indica el inicio del cuerpo del mensaje, en esta sección se incorpora toda la información necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una petición.
  • <soap:Fault> que se utiliza para que cualquier tipo de fallo que se produzca se notifique en esta sección y que, como se observa, está contenida dentro del cuerpo del mensaje.
  • </soap:Fault> cierra de la sección Fault.
  • </soap:Body> indica el final del cuerpo del mensaje.
  • </soap:Envelope> indica el final del mensaje SOAP.

WSDL (Web Services Description Language)

Es un protocolo basado en XML que describe los accesos al Web Service. Podriamos decir que es el manual de operación del web service, porque nos indica cuales son las interfaces que provee el servicio web y los tipos de datos necesarios para la utilización del mismo.

<?xml version="1.0">
<definitions>
    <types>
        // definición de los tipos de datos utilizados en el Web Service
    </types>
    <message>
        // definición de los métodos y parámetros para realizar la operación. Cada message puede consistir en una o
        // más partes (parámetros)
    </message>
    <portType>
        // definición de las operaciones que pueden ser realizadas, y los mensajes involucrados 
        // (por ejemplo el mensaje de petición y el de respuesta). Es la parte más importante.
    </portType>
    <binding>
        // definiciones de los formatos de los mensajes y detalles del protocolo para cada portType
    </binding>
</definitions>

Explicación del código anterior

  • <?xml version=”1.0″> es otro documento XML, es por esto que debe comenzar con el tag <?xml .. ?>
  • <definitions> indica el comienzo del documento, este tag agrupa a todos los demás.
  • <types> que es dónde se definen los tipos de datos utilizados en el Web Service.
  • </types> que indica el final de la definición de tipos.
  • <message> que es dónde se definen los métodos y parámetros para realizar la operación. Cada message puede consistir en una o más partes (parámetros).
  • </message> que indica el final de la definición de los parámetros.
  • <portType> dónde se definen las operaciones que pueden ser realizadas, y los mensajes involucrados (por ejemplo el mensaje de petición y el de respuesta). Es la parte más importante.
  • </portType> que es el final de la definición de las operaciones y mensajes.
  • <binding> dónde se define el formato del mensaje y detalles del protocolo para cada portType.
  • </binding> que finaliza la definición del formato del mensaje y detalles del protocolo para cada PortType.
  • </definition> que es para indicar el final del documento WSDL

Tenéis un buen ejemplo en el artículo Paso de Parámetros en SOAP con Estructuras complejas dónde se explica como realizar un Web Service con WSDL y tipos de datos simples.

UDDI (Universal Discovery Description An Integration)

Es un modelo de directorios para Web Services. Una especificación para mantener directorios estandarizados de información acerca de los Web Services, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente. UDDI utiliza WSDL para describir las interfaces de los Web Services.

Dicho de otra manera, es un lugar en el cual podemos buscar cuales son los Servicios web disponibles, una especie de directorio en el cual podemos encontrar los Web Services publicados y publicar los Web Services que desarrollemos.

Crear un Web Service con PHP y MySQL (Introducción)

15 agosto, 2013 Deja un comentario

Una API (Application Programming Interface o Interfaz de programación de aplicaciones) es un conjunto de funciones y métodos que ofrece una biblioteca que permite su utilización de forma remota como una capa de abstracción. Google, por ejemplo, tiene la Google SOAP Search API que permite a los desarrolladores consultar entre los millones de páginas web indexadas por Google directamente desde una aplicación cualquiera usando un Web Service, a través de los estándar SOAP y WDSL.

Un Web Service o Servicio Web, por su parte, es un sistema software diseñado para soportar la interoperabilidad de máquina a máquina en una red. En el contexto de aplicaciones Web, usualmente se refiere a un conjunto de APIs que se pueden acceder a través de Internet y ejecutar en un sistema remoto que aloja el servicio solicitado. Las máquinas interactúan con el Web service utilizando unos mensajes especiales llamodos SOAP que se han de establecer previamente.

Para conocer cómo se realiza el intercambio de mensajes en los Web Services debemos primero debemos entender los elementos fundamentales que lo componen. Estos son el XML, SOAP, WSDL, y UDDI.

XML (Extensible Markup Language)

Es un subconjunto simplificado del SGML (Standard Generalized Markup Language o Estándar de Lenguaje de Marcado Generalizado) que fue diseñado principalmente para documentos Web. Se caracteriza porque permite crear “etiquetas o tags propias (véase <libro>), habilitando la definición, transmisión, validación, y la interpretación de datos entre aplicaciones y entre organizaciones. Un punto que es importante aclarar es que el HTML y el XML tienen funciones diferentes. El HTML tiene por objeto mostrar información, mientras que el XML se ocupa de la información propiamente dicha (el contenido). Este concepto es importante tenerlo en cuenta, ya que muchas personas al escuchar sobre XML piensan que es el sucesor de HTML.

Ejemplo de un documento XML sobre información de autos:

<?xml version=“1.0” encoding=“UTF-8”?>
<vehiculos>
 
<coche>
     
<marca>Toyota</marca>
     
<modelo>Corolla</modelo>
     
<fechaCompra>2002</fechaCompra>
 
</coche>
 
<coche>
     
<marca>Honda</marca>
     
<modelo>Civic</modelo>
     
<fechaCompra>2003</fechaCompra>
 
</coche>
</vehiculos>

 

SOAP (Simple Object Access Protocol)

Es un protocolo que permite la comunicación entre aplicaciones a través de mensajes por medio de Internet. Es independiente de la plataforma, y del lenguaje. Está basado en XML y es la base principal de los Web Services. Los mensajes SOAP son documento XML propiamente dicho.

<?xml version=“1.0”?>
<soap:Envelope  xmlns:soap=http://www.w3.org/2001/12/soap-envelope&#8221;
       
soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding&#8221;>
   
<soap:Header>
        // Definición de la cabecera del mensaje. Incluye información específica del mensaje,
        // como puede ser la autenticación.
   
</soap:Header>
   
<soap:Body>
        // Definición o descripción del cuerpo del mensaje, en esta sección se incorpora toda la información
        // necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una
        // petición.
       
<soap:Fault>
            // Todos los fallos que se puedan producir se deben notificar aquí.
       
</soap:Fault>
   
</soap:Body>
</soap:Envelope>

 

Explicación del código anterior

  • <?xml version=”1.0″?> Como se puede apreciar, SOAP, es un documento XML, y como tal, debe comenzar con el tag <?xml….?> y la versión correspondiente.
  • <soap:Envelope indica que comienza el envelope (sobre) del mensaje.
  • xmlns:soap = “http://www.w3.org/2001/12/soap-envelope&#8221; que viene a decir que en un mensaje SOAP siempre se debe asociar el elemento envelope al namespace (espacio de nombres) http://www.w3.org/2001/12/soap-envelope.
  • soap:encodingStyle=”http://www.w3.org/2001/12/soap-encoding”&gt; indica dónde se encuentran definidos los tipos de datos utilizados en el documento.
  • <soap:Header> indica el comienzo del Header (encabezado). En esta sección se incluye información específica del mensaje, como puede ser la autenticación.
  • </soap:Header> indica el final del Header (encabezado).
  • <soap:Body> indica el inicio del cuerpo del mensaje, en esta sección se incorpora toda la información necesaria para el nodo final. Por ejemplo, los parámetros para la ejecución, o la respuesta a una petición.
  • <soap:Fault> que se utiliza para que cualquier tipo de fallo que se produzca se notifique en esta sección y que, como se observa, está contenida dentro del cuerpo del mensaje.
  • </soap:Fault> cierra de la sección Fault.
  • </soap:Body> indica el final del cuerpo del mensaje.
  • </soap:Envelope> indica el final del mensaje SOAP.

 

WSDL (Web Services Description Language)

Es un protocolo basado en XML que describe los accesos al Web Service. Podriamos decir que es el manual de operación del web service, porque nos indica cuales son las interfaces que provee el servicio web y los tipos de datos necesarios para la utilización del mismo.

<?xml version=“1.0”>
<definitions>
   
<types>
       
// definición de los tipos de datos utilizados en el Web Service
    <
/types>
    <message>
        /
/ definición de los métodos y parámetros para realizar la operación. Cada message puede consistir en una o
       
// más partes (parámetros)
    <
/message>
    <portType>
        /
/ definición de las operaciones que pueden ser realizadas, y los mensajes involucrados
       
// (por ejemplo el mensaje de petición y el de respuesta). Es la parte más importante.
    <
/portType>
    <binding>
        /
/ definiciones de los formatos de los mensajes y detalles del protocolo para cada portType
    <
/binding>
</
definitions>

 

Explicación del código anterior

  • <?xml version=”1.0″> es otro documento XML, es por esto que debe comenzar con el tag <?xml .. ?>
  • <definitions> indica el comienzo del documento, este tag agrupa a todos los demás.
  • <types> que es dónde se definen los tipos de datos utilizados en el Web Service.
  • </types> que indica el final de la definición de tipos.
  • <message> que es dónde se definen los métodos y parámetros para realizar la operación. Cada message puede consistir en una o más partes (parámetros).
  • </message> que indica el final de la definición de los parámetros.
  • <portType> dónde se definen las operaciones que pueden ser realizadas, y los mensajes involucrados (por ejemplo el mensaje de petición y el de respuesta). Es la parte más importante.
  • </portType> que es el final de la definición de las operaciones y mensajes.
  • <binding> dónde se define el formato del mensaje y detalles del protocolo para cada portType.
  • </binding> que finaliza la definición del formato del mensaje y detalles del protocolo para cada PortType.
  • </definition> que es para indicar el final del documento WSDL

 

UDDI (Universal Discovery Description An Integration)

Es un modelo de directorios para Web Services. Una especificación para mantener directorios estandarizados de información acerca de los Web Services, sus capacidades, ubicación, y requerimientos en un formato reconocido universalmente. UDDI utiliza WSDL para describir las interfaces de los Web Services.

Dicho de otra manera, es un lugar en el cual podemos buscar cuales son los Servicios web disponibles, una especie de directorio en el cual podemos encontrar los Web Services publicados y publicar los Web Services que desarrollemos.

Comunicación SOAP

15 agosto, 2013 Deja un comentario

Este artículo va para todos aquellos que se preguntan cómo puede hacer la comunicación SOAP con tipos de datos simples y complejos. Es decir, cómo enviar-recibir parámetros mediante SOAP.

Una de las cosas que todos vemos, o solemos ver, al principio cuando nos metemos en el mundo del los Servicios Web es el XML-RPC (un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP para la transmisión de mensajes) pero, si investigáis un poco, descubriréis que muchos lenguajes no se llevan muy bien que digamos con este protocolo.

Seguidamente, uno le echa valor y se decide, por ejemplo, a implementar un Web Service en PHP y, de repente, se encuentra con otro obstáculo. PHP 5.x no es que esté demasiado “maduro” en este tema y además, como se puede comprobar fácilmente, hay escasa documentación.

Después de pelearse y conseguir nuestro primer Servicio Web, Luego uno se también suele meterse en los archivos de descripción WSDL y, normalmente, ya muchos toman la decisión de dejarlo por imposible porque, aunque parecen sencillos, pero no lo son.

Bueno. No hay que ponerse catastrofistas. Una de las grandes aportaciones que nos hace SOAP y WSDL es que tanto el servidor como el cliente, de forma automática, comprueban muchos errores y lo hace todo de forma independiente al usuario. Es por esta razón que nos encontramos tantos problemas para realizar estructuras complejas como son los array asociativos.

Si lo que queremos es crear o gestionar datos simples como cadenas, enteros o fechas, esta tecnología puede ayudarnos mucho pero, si lo que se quiere es gestionar estructuras de elementos complejas como son los arrays asociativos los dolores de cabeza aumentarán considerablemente ya que no existe casi documentación sobre ello, y por si fuera poco, la que hay, o no lo explican bien, o no es del todo veraz.

Dicho esto, recordemos que los Servicios Web se componen de 3 partes básicamente. Definición del archivo WSDL, el archivo PHP del Cliente y el archivo PHP del Servidor. El WSDL es el más importante ya que sin este nunca funcionará.

Por si no habéis tocado mucho el SOAP, primero, haremos un ejemplo con paso de parámetros simples y, a continuación, realizaremos uno con estructuras complejas.

Ejemplo 1: Paso de Parámetros Simples en SOAP

La archivo WSDL (soap.wsdl)

Como se ve a continuación, NO DECLARAMOS NINGÚN TYPES porque al sólo tener que manejar un parámetro simple de tipo string ya lo hace sóla la aplicación.

<?xml version="1.0" encoding="utf-8"?> 
<!-- NOTAS IMPORTANTES --> 
<!-- ***************** --> 
<!-- SI SE CAMBIA EL SERVICIO WEB DE UBICACIÓN SE DEBE SUSTITUIR http://www.islavisual.com/ws POR LA URL QUE PROCEDA. --> 
<!-- SI ADEMÁS SE UTILIZA UN ARCHIVO schema.xsd TAMBIÉN HAY QUE CAMBIARLO DÓNDE APAREZCA. --> 
<definitions name="servicio"  
             targetNamespace='http://www.islavisual.com/ws/soap.wsdl' 
             xmlns          ='http://schemas.xmlsoap.org/wsdl/' 
             xmlns:http     ="http://schemas.xmlsoap.org/wsdl/http/" 
             xmlns:soap     ="http://schemas.xmlsoap.org/wsdl/soap/" 
             xmlns:SOAP-ENC ="http://schemas.xmlsoap.org/soap/encoding/"  
             xmlns:xsd      ='http://www.w3.org/2001/XMLSchema'> 
     
    <!--    AHORA DEBEMOS DEFINIR LO QUE EN SOAP SE DENOMINA MENSAJES. ESTOS MENSAJES SE CORRESPONDEN CON EL NOMBRE DE LA 
            FUNCIÓN Y SUS PARÁMETROS DE LA CLASE DEL SOAP-SERVER.  
            EL name DEL message ES EQUIVALENTE AL NOMBRE DE LA FUNCIÓN.  
            EL name DE CADA part SE CORRESPONDE CON CADA UNO DE LOS PARÁMETROS DE LA FUNCIÓN.  
            EN EL ELEMENTO part: 
                SI QUEREMOS DEFINIR PARÁMETROS DE ENTRADA LO HAREMOS CON EL ATRIBUTO type EN EL MENSAJE QUE TERMINA EN Request. 
                SI QUEREMOS DEFINIR PARÁMETROS DE ENTRADA LO HAREMOS CON EL ATRIBUTO type EN EL MENSAJE QUE TERMINA EN Response.--> 
     
    <!-- MESSAGE estaActivo --> 
    <message name='estaActivoRequest'> 
        <part name='message' type='xsd:string' /> 
    </message> 
    <message name='estaActivoResponse'> 
        <part name='result' type='xsd:string' /> 
    </message> 
    <!-- fin MESSAGE estaActivo --> 
     
    <!--    DEFINICIÓN DE LAS OPERACIONES PERMITIDAS Y MENSAJES INVOLUCRADOS (PETICIÓN Y RESPUESTA, ...). 
            NORMALMENTE TANTO input COMO output TENDRÁN CORRESPONDENCIAS CON LOS MENSAJES DEFINIDOS EN LA ZONA DE MENSAJES 
            ANTES DEFINIDA. --> 
             
    <portType name='servicioPortType'> 
        <!-- OPERACION estaActivo --> 
        <operation name='estaActivo'> 
            <input message='tns:estaActivoRequest' /> 
            <output message='tns:estaActivoResponse' /> 
        </operation> 
        <!-- fin OPERACION estaActivo --> 
    </portType> 
     
    <!--    AHORA ESPECIFICAMOS LOS PROTOCOLOS DE COMUNICACIÓN USADOS. DICHO DE OTRA MANERA ES LA DEFINICIÓN DEL FORMATO DE  
            CADA MENSAJE Y DETALLES DEL PROTOCOLO DE CADA PortType. 
            AQUÍ DECLARAMOS UNA OPERACIÓN, LE ASOCIAMOS LA FUNCIÓN DE LA CLASE Y, SU ENTRADA Y SALIDA --> 
             
    <binding name='servicioBinding' type='tns:servicioPortType'> 
        <soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/> 
        <!-- OPERACION estaActivo --> 
        <operation name='estaActivo'> 
            <soap:operation soapAction='http://www.islavisual.com/ws#estaActivo' /> 
            <input> 
                <soap:body use='literal' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' namespace='http://www.islavisual.com/ws' /> 
            </input> 
            <output> 
                <soap:body use='literal' encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' /> 
            </output> 
        </operation> 
        <!-- fin OPERACION estaActivo --> 
    </binding> 
     
    <!-- AHORA REALIZAMOS LA DEFINICIÓN DEL CONJUNTO DE PUERTOS Y DIRECCIÓN DE LOS MISMOS. --> 
    <service name='servicio'> 
        <port binding='tns:servicioBinding' name='servicioPort'> 
            <soap:address location='http://www.islavisual.com/ws/soapServer.php'/> 
        </port> 
    </service> 
</definitions>

 

La archivo client.php

Podemos declarar las opciones de la conexión estableciendo un array bastante simple:

$options = array( 
    // Opciones frecuentes 
    'trace' => true, 
    'exceptions' => true, 
    'wsdl_cache' => WSDL_CACHE_NONE, 
    'features' => SOAP_SINGLE_ELEMENT_ARRAYS, 
    'soap_version'   => SOAP_1_2, 
 
    // Credenciales de Autentificación para peticiones SOAP. 
    'login' => 'username', 
    'password' => 'password', 
     
    // Codificación de la conexión 
    'encoding'=>'UTF-8', 
     
    // URL del Proxy. No se debe poner aquí el http ó https ya que no funcionaría. 
    'proxy_host' => 'www.islavisual.com',  
    'proxy_port' => 44300, 
     
    // Credenciales de Autentificación para el Proxy. 
    'proxy_login' => NULL, 
    'proxy_password' => NULL);

 

Establecemos la conexión:

$client = new SoapClient("http://www.islavisual.com/ws/soap.wsdl", $options );

 

Hacemos la llamada a la función deseada. En este caso es una función muy simple que sólo nos devuelve el TimeStamp de Unix si recibe el valor ‘Hello’ y NULL si no coincide.

$client->isAlive( new SoapParam("Hello", "message"));

 

Y finalmente procedemos a establecer las cabeceras y la respuesta del Servidor:

header ("Content-Type:text/xml; charset=utf-8"); 
echo $client->__getLastResponse();

 

La archivo server.php

Primero podemos configurar algunas variables del Servidor aunque no es necesario:

ini_set("soap.wsdl_cache_enabled", "1"); 
ini_set("soap.soap.wsdl_cache_dir", "/tmp"); 
ini_set("soap.wsdl_cache_ttl", "86400");

 

Segundo declaramos la clase con las funciones a incorporar a nuestro Web Service:

class SOAPFunctions { 
    private $_SOAPSERVER = NULL; 
    private $_HEADERVARS = ""; 
    private $_params     = array(); 
    private $_USER       = ""; 
    private $_PASSWORD   = ""; 
 
    public function __construct($soapServer_resource){ 
        $this->_SOAPSERVER  = $soapServer_resource; 
        $this->_USER        = $_SERVER['PHP_AUTH_USER']; 
        $this->_PASSWORD    = $_SERVER['PHP_AUTH_PW']; 
    } 
 
    public function isAlive($message){ 
        if($message == "Hello") return time(); 
        else return NULL; 
    } 
}

 

Finalmente establecemos el Constructor de SoapServer y configuramos unas pocas propiedades:

$wsdl = "http://".$_SERVER['SERVER_NAME'].dirname($_SERVER['SCRIPT_NAME'])."/"; 
$soap_server  = new SoapServer($wsdl."soap.wsdl"); 
$soap_server->setClass("SOAPFunctions", $soap_server); 
$soap_server->handle();

 

  • Con setClass le indicamos cuál es la clase que tiene nuestros métodos.
  • Con handle le indicamos que procese la petición SOAP y nos devuelva una respuesta.

 

Ahora si lo queréis probar sólo tendréis que ejecutar o llamar al client.php

 

defrag

28 diciembre, 2010 Deja un comentario

%SystemRoot%\system32\dfrg.msc

C:\WINDOWS\system32

defrag.rar

Un pequeño tip para ilustrar como mapear una unidad desdeWindows mediante la consola CMD

9 diciembre, 2010 Deja un comentario

c:> net use ? \\172.16.1.2\c$

net use D: \\Descargas\notas hctarcs /persistent:no

Ejecutar como

4 noviembre, 2010 Deja un comentario

En ocasiones es necesario que un usuario ejecute una aplicación como administrador.

Esto se resuelve utilizando un acceso directo el cual ejecute un administrador local de la PC,

 

%windir%\System32\runas.exe /profile /savecred /user:XXX "c:\Program Files\XX\XXX.exe"

Multi – messenger Mediante el Regedit

24 abril, 2010 Deja un comentario

Aqui los pasos:

1.- Entramos a Ejecutar ya sea
a) menu inicio – Ejecutar
b) tecla de windows + R

2.- Digite regedit y presione enter

3.- Sigue la cadena del lado izquierdo:

HKEY_LOCAL_MACHINE despues SOFTWARE despues Microsoft y despues Windows Live

4.- Hacemos clic derecho sobre la carpeta que dice Messenger
le damos donde dice nuevo y despues donde dice valor DWORD le ponemos de nombre MultipleInstances

5.- Le damos clic derechoy en modificar y le ponemos 1 y dejamos selecionada la casilla Hexadecimal.

Aquí les muestro una imagen de como esta la cadena:


listo.