Android con SOAP & REST

La constante aparición  de dispositivos moviles va de la mano con una demanda alta de APP para diferentes sistemas y Androoid en busca de alcanzar a AppStore no es la excepcion.

En la web de codigo abierto permite a muchos desarrolladores codificar y desarrollar (valga la rebundancia ) Estos APP, y para ello utilizan las diferentes tecnoclogia. En este post quiero comentarle de una de ellas

Soap y Rest se adecuan muy bien a la implementacion de APPs

Estas pueden ser consumidas por un mismo Web service recuerden que la mayoría de los sitios webs grandes (Google, Bancos, Facebook, Microsoft, etc.) usan aplicaciones que utilizan servicios webs (web services).  Un web service  es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Así que distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet, esto significa que los ws aportan interoperabilidad.

La interoperabildiad se consigue mediante la adopción de estándares abiertos. El servicio web que nosotros utilizaremos esta basado en un estandar abierto llamado SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call).

De manera mas clara, un ws es un conjunto de métodos que se pueden invocar por alguna aplicación para realizar una tarea compleja, como lo muestra la siguiente imagen

 

En las siguiente link encontraran unos manuales muy detallados para empreder nuestro dearrollo de nuestros primeros APPs para Android

http://www.sgoliver.net/blog/?p=2571
http://www.sgoliver.net/blog/?p=2594

JSON simplifica la vida

El codificar un servicios muchas veces nos pueden arrojar muchos errores. Durante el desarrollo de mi proyecto me encontre con un problema. Logre capturar en una linea el codigo de un vaor INT para luego ser llamado por JSON

Espero les sea util

Fuentes

http://stackoverflow.com/questions/16992841/unable-to-post-json-to-rest-service

http://www.slideshare.net/rmaclean/json-and-rest

http://www.youtube.com/watch?v=5WXYw4J4QOU

IOS en REst

Durante el desarrollo de mi proyecto me interese en investigar sobre los APP en los dispositvos moviles smartphone, tables, etc. sobre el uso y funcionamiento en REST.

Como la existencia de librerias robustas como la ASIHTTPRequest que permite convocar los recursos de forma asincrona, tema que llevamos durante el ciclo. La sincronizacion es muy importante para el funcionamiento de los APPs.

Explicacion muy bien detalla de la de la configuracion en la conectividad  App a Rest API

Fuentes
http://www.slideshare.net/gillygize/connecting-to-a-rest-api-in-ios

Un blogger que ya implemento el servicio
http://www.juanpelaez.com/geek-stuff/ios/consumiendo-servicios-rest-desde-ios-5-parte-1-preparando-el-proyecto/

Pagina donde pueden iniciar una aventura sobre IOS.
https://developer.apple.com/devcenter/ios/index.action

Rest siempre Rest

Rest siempre Rest

Muchas veces creemos que el codificar es complicado, tedioso, aburrido y por que no inutil, bueno eso me paso a mi cuando empece a desarrollar en mi curso de Desarrollo de Sistemas Distribuidos, pero me di cuenta que no tiene porque ser asi. Durante el desarrollo de mi curso en la universidad aplicamos REST.

Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfacesXMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST.

Les dejo un codigo que encontre en la WEB para implementar Rest en aplicativos para Android

Insertando data via Rest

public static HttpResponse doPost(String url, JSONObject c) throws ClientProtocolException, IOException 
    {
        HttpClient httpclient = new DefaultHttpClient();
        HttpPost request = new HttpPost(url);
        StringEntity s = new StringEntity(c.toString());

        s.setContentEncoding("UTF-8");
        s.setContentType("application/json");

        request.setEntity(s);
        request.addHeader("accept", "application/json");

        return httpclient.execute(request);
}

Actualizando data via Rest

public static HttpResponse doPut(String url, JSONObject c) throws ClientProtocolException, IOException
{
        HttpClient httpclient = new DefaultHttpClient();
        HttpPut request = new HttpPut(url);
        StringEntity s = new StringEntity(c.toString());
        s.setContentEncoding("UTF-8");
        s.setContentType("application/json");

        request.setEntity(s);
        request.addHeader("accept", "application/json");

        return httpclient.execute(request);
}

Eliminando data via Rest

public static void doDelete(String url) throws  ClientProtocolException, IOException{
     HttpClient httpclient = new DefaultHttpClient();
     HttpDelete delete = new HttpDelete(url);
     delete.addHeader("accept", "application/json");
     httpclient.execute(delete);
}

Fuentes

http://www.ibm.com/developerworks/ssa/library/wa-aj-multitier2/

http://msdn.microsoft.com/es-es/magazine/dd942839.aspx

http://www.majidkhosravi.com/android-rest/

http://blogs.burnsidedigital.com/2012/08/how-to-create-restful-http-for-android-in-4-easy-steps-using-spring/

XML vs JSON

XML vs JSON

Enfrentarse con alguien nunca fue tan complicado y dudoso (es que sabemos que si son dignos rivales entre si).  Primero presentaremos a los contrincantes

XML, 

siglas en inglés de eXtensible Markup Language ('lenguaje de marcas extensible'), es un lenguaje de marcas desarrollado por el World Wide Web Consortium (W3C). Deriva del lenguaje SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML) para estructurar documentos grandes. A diferencia de otros lenguajes, XML da soporte a bases de datos, siendo útil cuando varias aplicaciones se deben comunicar entre sí o integrar información. (Bases de datos Silberschatz).

XML no ha nacido sólo para su aplicación para Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.

XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil.

JSON, 

acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. JSON es un subconjunto de la notación literal de objetos de JavaScript que no requiere el uso de XML.

La simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente como alternativa a XML en AJAX. Una de las supuestas ventajas de JSON sobre XML como formato de intercambio de datos en este contexto es que es mucho más sencillo escribir un analizador sintáctico (parser) de JSON. En JavaScript, un texto JSON se puede analizar fácilmente usando la función eval(), lo cual ha sido fundamental para que JSON haya sido aceptado por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad de JavaScript en casi cualquier navegador web.

En la práctica, los argumentos a favor de la facilidad de desarrollo de analizadores o del rendimiento de los mismos son poco relevantes, debido a las cuestiones de seguridad que plantea el uso de eval() y el auge del procesamiento nativo de XML incorporado en los navegadores modernos. Por esa razón, JSON se emplea habitualmente en entornos donde el tamaño del flujo de datos entre cliente y servidor es de vital importancia (de aquí su uso por Yahoo, Google, etc, que atienden a millones de usuarios) cuando la fuente de datos es explícitamente de fiar y donde no es importante el no disponer de procesamiento XSLT para manipular los datos en el cliente.

Si bien es frecuente ver JSON posicionado contra XML, también es frecuente el uso de JSON y XML en la misma aplicación. Por ejemplo, una aplicación de cliente que integra datos de Google Maps con datos meteorológicos en SOAP hacen necesario soportar ambos formatos.

Cada vez hay más soporte de JSON mediante el uso de paquetes escritos por terceras partes. La lista de lenguajes soportados incluye ActionScript, C, C++, C#, ColdFusion, Common Lisp, Delphi, E, Eiffel, Java, JavaScript, ML, Objective-C,Objective CAML, Perl, PHP, Python, Rebol, Ruby, Lua y Visual FoxPro.

En diciembre de 2005 Yahoo! comenzó a dar soporte opcional de JSON en algunos de sus servicios web.

El término JSON está altamente difundido en los medios de programación, sin embargo, es un término mal descrito ya que en realidad es solo una parte de la definición del estándar ECMA-262 en que está basado Javascript. De ahí que ni Yahoo, ni Google emplean JSON, sino LJS. Una de las cualidades intrínsecas de Javascript denominada LJS (Literal Javascript) facilita el flujo de datos e incluso de funciones, para la cual no requiere la función eval() si son datos los que se transfieren como en el caso de XML. Todo lo referente a transferencia de datos en todos sus tipos, incluyendo arrays, booleans, integers, etc. no requieren de la función eval(), y es precisamente en eso en donde supera por mucho JavaScript al XML, si se utiliza el LJS y no la incorrecta definición de JSON.

El desarrollo de nuestro proyecto nos permitió identificar y entender mejor la teoría y como cunclusion podemos decir los siguiente:

•  Si mi fuente datos es un webservice, pues lo mejor es usar xml, si mi fuente de datos es una matriz de php, json.
• XML es un lenguaje de representación de datos y para eso debe emplearse, pero cuando se trabaja con AJAX la agilidad es la regla, y sin duda alguna parsear en php una estructura JSON es MUCHO más rápido que una estructura XML (más aún con las funciones json_encode y json_decode incluidas en el core de PHP desde la versión 5.2.0), y ni hablar del manejo de estructuras JSON en Javascript.... mi recomendación personal:
• JSON cuando estas entablando comunicación con AJAX, y XML si necesitas implementar un servicio web, hacer feeds, o cualquiera de la demás aplicaciones comunes de XML.
• JSON su facil interpretación, la transferencia de información (en Kb) es mucho mas pequeña que recibir XML.
• XML goza de mayor soporte y ofrece muchas más herramientas de desarrollo. Hay muchos analizadores JSON en el lado del servidor, existiendo al menos un analizador para la mayoría de los entornos..
• XML, es un lenguaje de intercambio de información estructurada desarrollado por la W3C, con la proposición de ser un estandard entre diferentes plataformas, desde bases de datos, editores de texto,…Es una tecnología sencilla y fácil de entender, además se aplica un razonamiento lógico a su estructura.

Fuentes

http://es.wikipedia.org/wiki/Extensible_Markup_Language

http://es.wikipedia.org/wiki/JSON

SOA vs REST

SOA vs REST

Siempre en todo ámbito encontramos enfrentamiento y en la tecnología  no existe excepción en este post quiero hablarles de dos en especial REST es un patrón de arquitectura construido bajo verbos simples que se adaptan bastante fácil con HTTP. A diferencia, SOAP es un protocolo de mensajería basado en XML (mensajes SOAP con una estructura XML) que puede utilizarse por una variedad de protocolos de transporte, incluso el mismo HTTP.

Ambos fueron tocados durante mis clases en la universidad ambos sirvieron para alimentar mi proyecto y convivieron de manera eficiente.

Una clara comparativa de ambas tecnologias las revisamos a continuacion.

REST

1.- La arquitectura encaja de manera natural con HTTP.

2.- Necesario para clientes donde la capacidad es muy limitada (Escenarios JavaScript)

3.- No hay necesidad de Proxys (como en SOAP) para las conversiones y demás.

4.- Trata con acceso a recursos

REST – SOAP

5.- Operaciones remotas (una de las finalidades de los servicios web)

6.- Acceso a recursos remotos (más de lo anterior)

7.- Interoperable (otra de las finalidades de los servicios web)

SOAP

8.- El cifrado es a nivel de mensaje

9.- Dispone de ruteadores o intermediarios

10.- Reeegularmente (no creo que siempre) el envío de mensajes es confiable.

11.- Políticas de control (Diferentes perfiles)

12.- Basado en acciones

Como pequeño resumen podemos indicar lo siguiente:

Ventajas de REST

• Está totalmente bajo especificaciones del protocolo HTTP, en donde todo actúa como un recurso, ni siquiera los servicios se escapan, se trata el mensaje igual como si fuera alguna imagen, uno o varios elementos HTML, etc. 
• No es tan estricto como SOAP, los datos pueden mantenerse estrictamente o de forma desacoplada, mediante la URI.
• Los recursos pueden consumirse fácilmente desde JavaScript (La mayoría de las aplicaciones que utilizan OpenId o el protocolo OAuth utilizan JavaScript para realizar llamadas con REST, por ejemplo twitter)
• Los mensajes son bastante ligeros, el rendimiento y la escalabilidad no deberían ser problema y cuando uno está acostumbrado a trabajar en “Internet”, esto es de vida o muerte.
• REST no se queja, puede utilizar XML o JSON para el formato de los datos.

Desventajas de REST

• Si se trata de trabajar con objetos fuertemente tipados, tipo =P, en el código de servidor, es algo tedioso incluso difícil, pero esto también depende de otras situaciones.
• No creo (no lo sé) que funcione bien con aplicaciones de alto rendimiento y basadas en tiempo real. Por ejemplo, algún sistema para ingeniería industrial que arroje constantemente datos y mas datos para generar estadísticas.

Ventajas de SOAP

• Trabaja bien con datos, los mensajes y las comunicaciones están bien estructurados.
• Dispone de proxys fuertemente tipados.
• Funciona sobre diferentes protocolos, no solamente HTTP (como en REST) si no también sobre TCP, NamedPipes, MSMQ, etc. aunque el uso de estos no es tan bueno si se trata de estandarizar en Internet.

Desventajas de SOAP

• Los mensajes generados por SOAP no se pueden cachear (¿o si?)
• En JavaScript.. olvídate de SOAP.

Como conclusión no podemos decir que una es mejor que otra ya que ambos se aplican según la necesidad

fuente
http://thanksnetwork.com/2012/10/16/rest-vs-soap/

Tecnologías de programación distribuida

Tecnologías de programación distribuida

Muchas veces el querer visualizar la tecnologia como tal; desde un punto de vista unico y encasillado hace perder en enfoque de otros entornos y muchas veces pierde vision y alcance las Tecnologias de Programacion Distribuida esta enfocado en desarrollar sistemas distribuidos abiertos, escalables, transparentes y tolerantes a fallos. Este paradigma es el resultado natural del uso de las computadoras y las redes.

Hoy quiero comentarles de dos llevados en mi curso de Desarrollo de Sistemas Distribuidos

WEBSocket

La especificación HTML5 WebSockets define una API que permite que las páginas web para utilizar el protocolo WebSockets para la comunicación de dos vías con un host remoto. Se presenta la interfaz WebSocket y define un canal de comunicación full-duplex que opera a través de una toma única en la Web. WebSockets HTML5 proporcionan una enorme reducción en el tráfico innecesario en la red y la latencia en comparación con el sondeo no escalable y soluciones a largo votación que se utilizaron para simular una conexión full-duplex por mantener dos conexiones. Algunos navegadores que utilizan esta tecnologia son:

• Chrome 4
• Safari 5 (includes iOS 4.2)
• Mozilla Firefox 8
• Microsoft ha incluido soporte para WebSocket en Internet Explorer 10, que aún está bajo desarrollo.

Como ventaja pódemos decir que WebSocket es que actúa como un complemento más natural para los sistemas de mensajería de usuario final, dúplex completo, basados en TCP como RMI, JMS o XMPP, empleados en los servicios de chat. Al conectar HTTP a estos protocolos se produce “una no-correspondencia que muchas compañías han invertido mucho tiempo tratando de resolver”, contó Fallows.

Una desventaja aun es todavía no son verdaderamente métodos de comunicación bidireccional - la información sigue viajando sólo en una dirección en un momento dado.

Los WebSockets son diferentes, porque utilizan TCP que permite la verdadera comunicación bidireccional entre el cliente (su computadora) y un servidor. Esto significa que usted nunca tiene que hacer una petición de nuevos datos desde el servidor, ya que la información es, literalmente, transmitida a su computadora en tiempo real a medida que llega nueva información. Es un concepto complicado, pero muy poderoso, una vez que llegue a familiarizarse con él.

A pesar de que todas estas tecnologías no son parte de HTML5, todas ellas resuelven un propósito específico y que debe ser aceptado y usado junto con HTML5 siempre que sea posible. Por ejemplo, mediante la combinación de WebSockets y canvas de HTML5 se pueden crear en tiempo real increíbles juegos para varios jugadores en línea (redundante pero cierto). Ahora sí, es una combinación fresca de dos tecnologías diferentes, que juntas dan un sabor al desarrollo inigualable.

WCF 

Windows Communication Foundation o WCF (también conocido como Indigo), es la plataforma de mensajería que forma parte de la API de la Plataforma .NET 3.0 (antes conocida como WinFX, y que no son más que extensiones para la versión 2.0). Se encuentra basada en la Plataforma .NET 2.0 y de forma predeterminada se incluye en el Sistema Operativo Microsoft Windows Vista.

Fue creada con el fin de permitir una programación rápida de sistemas distribuidos y el desarrollo de aplicaciones basadas en arquitecturas orientadas a servicios (también conocido como SOA), con una API simple; y que puede ejecutarse en una máquina local, una LAN, o sobre Internet en una forma segura.es comparable con webservices. Entre sus ventajas tenemos:

• WCF soporta SOAP
• Permite encriptar y asegurar la información a través de internet.
• Puede hostear un servicio sin que este en el IIS o en el administrador de Windows
• Soportar patrones de intercambio de mensajes como half duplex y full dúplex.
• Soporta http, HTTPS y FTP
• Permite el manejo de excepciones.

En la web pude encontrar un link para los que al igual que Yo nos iniciamos en estos temas.

http://es.scribd.com/doc/128416270/78507290-Manual-WCF-pdf
http://gvasquezf12.blogspot.com/2013/02/servicio-web-wcf-rest-y-soap.html

Los principios de diseño de la Arquitectura Orientada a Servicios:

Los principios de diseño de la Arquitectura Orientada a Servicios:

Si la teoria no se aplica correctamente durante el analisis de un proyecto en muchos casos se presentan retrabajos y problemas en los sistemas algo muy claro y necesario es entender de SOA y para esto cito a Mary E. Shacklett, creo que define el concepto de forma clara y amigable en buen crcistiano.

"SOA es una técnica que ha surgido del desarrollo de software orientado a objetos que fue evolucionando hacia la creación de servicios web que encapsulan piezas de software de negocio usadas en la web para coordinar procesos de negocio de empresa."

Estos principios o al menos los mas relevantes vistos en clase son:

1. Contratos de servicio estandarizados: forma parte de la esencia misma de un servicio. Para que se considere un servicio,  su interfaz de entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos  que forman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de los estándares como WSDL y XSD, el contrato del servicio está autodescrito.
   Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a su vez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicio web, a pesar de que parece que son los que más abundan.
2. Servicios con bajo acoplamiento: hace referencia al nivel de dependencia entre servicios, entre el proveedor y el consumidor. Cuanto menos acoplamiento se logra una mayor independencia para el diseño del servicio y su posterior evolución
3. Abstracción: este principio pone el enfásis en ocultar los detalles internos del servicio, tanto como sea posible. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo
4. Reusabilidad: como es conocido, la arquitectura SOA no busca la sustitución de las lógicas de negocio actuales sino que proporciona una forma de reaprovechar todos estos activos encapsulandolos en servicios para que a su vez puedan ser reutilizados por otros servicios.
5. Autonomia: Este principio indica que el servicio tiene un alto grado de control sobre su entorno de ejecución y sobre la lógica que encapsula
6. Sin estado: el tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar provienen de los parámetros de entrada.
7. Capacidad de descubrimiento: al servicio se le dota de meta datos, gracias a los cuales puede ser descubierto de manera efectiva. Estos meta datos pueden ser interpretados de manera automática pudiendo ser reutilizados. Para ello es necesario disponer de un mecanismo de descubrimiento (llamado registro de servicios) como por ejemplo el UDDI.
8. Composición: define la capacidad de un servicio para formar parte de un servicio más complejo. A medida de que la arquitectura SOA se consolide, los nuevos servicios (de más alto nivel) podrán implementarse a partir de los servicios de más bajo nivel ya existentes. La implementación de nuevos servicios se reducirá al mínimo y que los nuevos se crearán a partir de otros ya pre existentes.
9. Interoperabilidad: este principio no formaba parte de los 8 principios originales ya que en realidad es una propiedad que forma parte de todos ellos.  Cada uno de los anteriores contribuye a la interoperabilidad de alguna manera. En las arquitecturas SOA, el problema de la falta de esta cualidad es uno de los más importantes. Hay que tener en cuenta que muchos de los servicios que intervienen se implementan con una tecnología diferente, incluso con un sistema operativo distinto.
   Por ejemplo, se puede tener un servicio realizado en Java ejecutándose sobre Linux que invoca a otro implementado en .net corriendo en una máquina con Windows. Históricamente las especificaciones que dan forma a los servicios web (como WSDL, SOAP, etc.) eran tan ambiguos que las dos partes estaban prácticamente condenadas a no entenderse. Iniciativas como el Basic Profile 1.0 han contribuido a eliminar estas ambiguedades, simplificando estos estándares, logrando que el consumidor y el proveedor del servicio puedan comunicarse entre sí.
   
   
   Durante nuestro proyecto aplicamos Autonomía y Abstracción.