Metodos Rest y también de SOAP

Quienes hayan usado SOAP para WebService, sabrán que es bien fácil de diseñar, pero algo
complicado de consumir: se necesita toda una API para construir los clientes utilizando el WSDL.
Por ejemplo, para PHP se necesita de la biblioteca NuSOAP. Entonces, para lograr el concepto de «lenguaje único XML» es un dolor de cabeza. Y más aún si el cliente es tan simple como JavaScript, manejar XML de SOAP provocaría suicidos masivos… o no usar WebServices.

Además, con SOAP se permite crear un solo servicio y ponerle varios métodos. Esto puede llevar a un mal diseño del servicio ya que podría tener un servicio que haga de todo: por ejemplo, un servicio de manejo de Clientes que permita también manejar Proveedores.

RESTful es una propuesta muy interesante de Roy Fielding que permite manejar los servicios web con métodos definidos, manteniendo la simpleza del protocolo como XML, pero que cada servicio sea identificado únicamente con un solo URI.

En este post veremos cómo crear un Servicio RESTful usando NetBeans, y haremos crecer de poco a poco nuestro ejemplo… desde hacer operaciones sencillas, hasta manejar estructuras complejas.

Cabe destacar que los servicios de las redes sociales como Flickr, Twitter, Facebook, etc son
basados en RESTful.

Para este ejemplo usaremos NetBeans 7.3, y GlassFish v3.0.1, ya que usaremos las características de Java EE6. Con GlassFish v.2 igual funciona, y NetBeans ayuda en ello,

Para comenzar, debemos entender que necesitamos de una clase para manejar un servicio. En esta clase solo pueden haber máximo cuatro métodos públicos que son ejecutados por los cuatro métodos HTTP disponibles para RESTful:

  1. GET
  2. POST
  3. DELETE
  4. PUT

Los métodos GET y POST son conocidos en los formularios (<form method=»post» />)
¿Tienen algo que ver? Sí, y lo veremos poco a poco. Cada uno de estos métodos determina
la acción que hará el REST sobre nuestra aplicación. No deben haber más de un GET o POST o DELETE o PUT, solo tiene que haber uno de cada método. Cada uno tiene una tarea especifica:

  1. GET: Para obtener un valor. Puede ser un listado de objetos
  2. POST: Para guardar un nuevo objeto (instancia de identidad) en la aplicación
  3. DELETE: Para eliminar un objeto (instancia de identidad)
  4. PUT: Para actualizar un objeto.

A continuación dejo un tutorial de rest para android interesante.

https://www.youtube.com/watch?v=XRURZVtphn8

Referencia:

https://msdn.microsoft.com/es-es/library/mt163658.aspx

https://powerbi.microsoft.com/es-es/documentation/powerbi-developer-rest-api-reference/

 

Descubriendo MSMQ

Una de las técnicas o patrones para integración empresarial es la de mensajería. En ese esquema, ademas de otras herramientas, tenemos a MSMQ de Microsoft, que es una herramienta que permite realizar el manejo de colas de mensajes. La finalidad de MSMQ es lograr una comunicación asíncrona (off line) entre procesos. A veces, muchas arquitecturas usan este patrón para implementar contingencias en la interacción de servicios.

Características
MSMQ es útil cuando tenemos algún proceso que requiere invocar una rutina que lleva mucho tiempo. Antes, El proceso que invocaba algún servicio quedaba esperando a que el proceso invocado termine para poder continuar. Con MSMQ actuando de forma asíncrona ofrece continuidad al proceso invocador y al proceso invocado.
Esta herramienta ofrece un alto grado de encriptación para los mensajes, así como la autenticación de los mismos. Asi mismo, permite el uso de transacciones externas, lo que facilita la implementación de contingencias o aplicaciones que requieran «regularizaciones off line»
MSMQ proporciona enrutamiento dinámico, lo que hace que los mensajes se muevan por diferentes rutas de red y puedan encontrar el nodo que solicito su funcionalidad.
Biztalk Server es el adapatadro para MSMQ que le permite funcionar con colas remotas y locales, publicas y privadas, transaccionales y no transaccionales.
Ofrece compatbilidad para mensajes mayores a 4MB y proporciona acceso a características de Message Queuing 4.0 como, por ejemplo, lecturas transaccionales remotas y lectura desde subcolas.
A continuación dejo dos links de ejemplos de MSMQ & WCF:
Referencias:

REST

REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP.

  1. ¿Los principios de REST?

El estilo de arquitectura subyacente a la Web es el modelo REST. Los objetivos de este estilo de arquitectura se listan a continuación:

  • Escalabilidad de la interacción con los componentes. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas industriales, dispositivos móviles.
  • Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial.
  • Puesta en funcionamiento independiente. Los clientes y servidores pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, a través de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido.
  • Compatibilidad con componentes intermedios. Los más populares intermediaros son varios tipos de proxys para Web. Otros permiten reforzar las políticas de seguridad: firewalls. Y por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
  1. Métodos más importantes del REST

Los métodos HTTP más importantes son PUT, GET, POST y DELETE. A continuación, mostramos las analogías que se realizan constantemente:

  1. Posible futuro de REST

Todos los negocios de cualquier lugar tendrán que estandarizar sus modelos de direccionamiento para exponer las interfaces en común a sus clientes. SOAP, actualmente no permite esto en si mismo. Para que los negocios interoperen sin programar manualmente de manera explícita enlaces a los clientes, se necesitará estandarizar un modelo de direccionamiento, más que invertir en sistemas propietarios. REST proporciona un alto grado de estandarizar la información a compartir. Por tanto, si los servicios Web basados en SOAP no consiguen implantar este mecanismo, no sobrevivirán por lo tanto y en conclusión se podría creer que se viene la era de los Servicios Web basados en REST.

  1. Recomendaciones:

·         RESTEasy es un JBOSS que prove varios frameworks para ayudar a construer WebServices RESTFUL junto con aplicaciones Java. Está totalmente certificado y es portable.

·         Recess es un framework Restful PHP libre muy interesante. Igualmente, contiene ejemplos, códigos, foros y posibilidad de descargar diferentes ejemplos como referencia.

Referencias:

https://msdn.microsoft.com/es-es/library/jj683097.aspx

Haz clic para acceder a RestVsWebServices.pdf

Conceptos sobre APIs REST

Funcionamiento de Web Service

Explicando un poco el funcionamiento de Web Service, el cliente establece un diálogo coherente con el Web Services Cliente(WSC), alojado en el servidor de aplicaciones, mediante el envío de una petición haciendo uso de un contrato llamado WSDL, para luego recibir la respuesta del Web Services Servidor(WSS), el cual es el encargado de jecutar los procesos y envíar respuestas al WSC. El WSDL es un archivo generado en una codificación XML el cual esta basado en el protocolo SOAP (Simple Objecte Access Protocol).
El Web service(WS) no es como cuando un usuario navega en las páginas web, sino que el WS al recibir peticiones a través de mensajes SOAP desde otras aplicaciones, éste realiza el proceso solicitado y devuelve un mensaje SOAP de respuesta el cual puede ser utilizado por la aplicacion cliente.
Es recomendable el uso del Web Services cuando hay necesidad de que un cliente autorizado acceda remotamente a la información y generar procesos, interactuando con el sistemas que una empresa haya compartido para que pueda ser accedido en todo momento desde el Internet.
También, es recomendable el Web Service cuando se requiere crear una red virtual entre empresas, que tengan la necesidad de intercambiar información a través de Internet en un entorno seguro y protegido.
No es recomendable el uso de Web Services en sistemas donde no es requerido un entorno distribuido, como puede ser el compartir información a todos los usuarios sin restricciones en el cual no se genera ningún tipo de proceso.
Conclusiones
  • Los sistemas distribuidos abarcan una cantidad de aspectos considerables, por lo cual su desarrollo implica mucha complejidad.
  • Existen ciertos aspectos que requieren extremo cuidado al desarrollarse e implantarse como el manejo de fallos, el control de la concurrencia, etc.
  • Se nota también que muchas tecnologías están en constante desarrollo y maduración, lo cual implica un minucioso estudio previo de muchos factores antes de apostar por alguna tecnología en especial.
  • En lo personal por trabajo he estado trabajando con servicios web a manera funcional sobre el tema de facturación electrónica con el web service de SUNAT lo cual es interesante ya que utilizan formato de texto XML para intercambiar información. Como herramienta para hacer pruebas estado utilizando el soapUI el me permitido hacer pruebas ingresando la URL del servicio web en este caso el de SUNAT.

Referencias:

https://es.wikipedia.org/wiki/Servicio_web

https://msdn.microsoft.com/es-es/library/bb972248.aspx

https://msaffirio.wordpress.com/2006/02/05/%C2%BFque-son-los-web-services/

 

Los principios de diseño SOA

Como primer  post, en este proceso de inmersión dentro del mundo de los sistemas distribuidos, considerando que es importante que conozcamos la Arquitectura Orientada a Servicios (SOA) la cual define y sirve como base para la creación y utilizaciónd e servicios para dar soporte a los requisitos del Negocio. Asimismo, nos permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.

Dentro de esta arquitectura se pueden mencionar un conjunto de  8 principios los cuales pasamos a detallar a continuación:

1.- Contrato de Servicios Estandarizados

Cuando un servicio se implementa como un servicio web, se debe adherir (proporcionar) un contrato de comunicaciones explícitamente declarado y definido colectivamente por uno o más descriptores del servicio, en el cual debe figurar especificaciones como:

• Nombre del Servicio.
• Forma de accesos.
• Funcionalidades que ofrece.
• Descripción de los datos de entrada de cada funcionalidad que ofrece.
• Descripción de los datos de salida de cada funcionalidad que ofrece.

De este modo, todo consumidor de los servicios accederá mediante el contrato, logrando la independencia entre el consumidor y la implementación del propio servicio. Con esto se evita el manejo incorrecto de los datos, se evita trabajo innecesario en la invocación entre estos servicios y también se pone de manifiesto que la existencia de un modelo de datos a nivel de servicio es una de las primeras necesidades que se debe tener en cuenta.

Service Contract

2.- Bajo Acoplamiento:

Este principio hace referencia a que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.

Service Loose Coupling

3.- Abstracción:

El principio de abstracción permite encapsular el servicio y reducir el acoplamiento. 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.

El uso de estándares permite definir interfaces uniformes que esconden la lógica del servicio respecto del entorno que le rodea (sistemas proveedores y consumidores)

Este nivel de abstracción permite centrarnos exclusivamente en la especificación del servicio, sin incluir información tecnológica ni de ninguna otra naturaleza, más allá de la propia especificación estándar del servicio desde el punto de vista del negocio al que sirve, que queda recogida en su contrato.

Service Abstraction

4.- Reusabilidad:

La reutilización es el principal principio de la arquitectura SOA, cada servicio debe ser analizado, diseñado y construido de manera que su uso pueda serexplotado al máximo, es decir, cada servicio debe ser de algún modo genéricocon el fin de que pueda usarse en diferentes contextos y satisfacer distintosobjetivos. De esta manera, los servicios podrán ser reusables dentro de lamisma aplicación, dentro del dominio de aplicaciones de la empresa o inclusodentro del dominio público para su uso masivo.

Por otro lado, estos servicios reutilizables deben estar diseñados de maneratal que su solución lógica sea independiente de cualquier proceso de negocio otecnología en particular.

Con este principio se busca reducir las posibilidades de duplicación de lógica.Si un servicio que ya existe en un contexto funcional se ajusta a la nuevalógica reutilizable, en lugar de crear un nuevo servicio, dicha lógica debeformar parte del servicio existente.

Service Reusability

5.- Autonomía:

Este principio nos dice que todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

Service Autonomy

6.- No estado:

Un servicio no debe guardar ningún tipo de información. 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 deben provenir directamente de los parámetros de entrada.

Service Statelessness

7.- Descubrimiento:

Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

Service Discoverability

8.- Composición:

Este principio nos dice que todo servicio debe estar construido de tal manera que pueda ser utilizado para construir servicios genéricos de mayor complejidad, el cual estará compuesto de servicios de menor nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación (WS-BPEL) y coreografía (WS-CDL).

El concepto de desarrollo de software a partir de componentes existentes independientemente fomenta el concepto de composición. Por ello el concepto de composición es heredado por la orientación a servicios, por lo que un proceso de negocio está automatizado mediante la combinación de múltiples servicios. Sin embargo, dentro de la orientación a servicios es mayor el enfoque en la creación de servicios que se pueden componer y recomponer dentro de múltiples soluciones para proporcionar la agilidad prometida por la SOA. Como resultado de este énfasis, algunas pautas son requeridas para el desarrollo de servicios que pueden ser efectivamente agregados en varias soluciones.

Service Composability

Estos son en resumen los principios del diseño SOA. A partir del próximo post empezaremos a armar una solución en .NET (C#) esperando aplicar todos los conceptos hasta aquí mencionados.

Conclusión

No es preciso definir cuál es la mejor opción para orquestar arquitecturas SOA. En ese proceso intervienen muchos factores como requerimientos funcionales y no funcionales, presupuesto, experiencia de desarrollo, etc. Lo importante es saber identificar cuando usar cual y como usarlos para poder crear una arquitectura escalable, de alta disponibilidad y que conserve siempre la estructura SOA. Ello garantizará el éxito de una integración empresarial.

Referencias:

http://www.soapatterns.org/patterns_principles.php

http://arquitecturaorientadaaservicios.blogspot.com/2006/06/principios-de-la-orientacin-servicios.html

http://info-soa.blogspot.com/2010/09/principios-de-una-arquitectura.html

http://www.ibm.com/developerworks/library/ws-soaintro.html

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration