IDCode - Rest

Experiencia del Proyecto

Durante el desarrollo de la implementacion del Proyecto, la mayoria de nosotros tratamos de implementar Rest, por su facil desarrollo.

Aunque eso depende más de cómo está hecha la parte del cliente, teóricamente el desarrollo hoy en dia  de sitios web basados en un API puede dar mejor desempeño que uno tradicional. Cuando haces una solicitud al servidor lo que tienes como respuesta son datos planos, que requieren tiempos de transferencia menores que si esos mismos datos los recibieras mezclados con el HTML/CSS de la presentación.

En nuestro proyecto no necesitas recargar la página, aunque esto no es una ventaja específica del desarrollo basado en REST, sino del uso de Ajax en general, con el que podemos conseguir aplicaciones web que se asemejan más a aplicaciones de escritorio.


REST requiere menos recursos del servidor 

Esto no es necesariamente cierto aunque en muchos casos sí se pueda deducir. Hay muchas opiniones al rededor de REST. Nosotros basamos esa afirmación en estos motivos:

No mantener el estado, no requiere memoria, se pueden atender más peticiones

No requiere escribir el HTML, por lo tanto tienes menos procesamiento en el servidor

IDCode - Lecciones Aprendidas

Conclusiones:

Anterior mentes había escuchado estos servicio tanto Soap como Rest, pero ahora que he visto este tema mas cerca, llevando el curso de Sistemas Distribuidos, ha sido una experiencia valiosa.

La mayoría de  clientes prefieren la interfaz REST.

Existen hoy en día muchas empresas que han invertido y apostado por SOAP, pero es evidente que los desarrolladores prefieren, en algunos casos, una forma mas sencilla de programación REST.

En nuestro caso, en el proyecto que realizamos se utilizo mas Rest que Soap por su facil implementacion.
   
Al parecer REST tendra mayor aceptación en el futuro, pero eso va a depender de lo cambiante de la tecnología y del tiempo que pida el usuario para la implementacion.

Foro 5: FILE TRANSFER

FILE TRANSFER

1. Sobre los estilos de integración, seleccione uno y comente una ventaja y una desventaja de su aplicación.

FILE TRANSFER COMO ESTILO DE INTEGRACIÓN


El proceso del File Transfer es facilitado por el protocolo FTP o SFTP. La estandarización de este protocolo garantiza la interoperabilidad y la disponibilidad de herramientas estándar para implementar la transferencia de archivos a través de lenguajes y plataformas de programación.


VENTAJA:


Interoperabilidad: Las aplicaciones generan archivos que contienen la información a compartir y dado que las aplicaciones receptoras o clientes tienen la responsabilidad de transformar los archivos en diferentes formatos de acuerdo a sus necesidades, esto proporciona una mayor interoperabilidad del sistema.Una decisión importante con los archivos es el formato a utilizar. Muy rara vez la salida de una aplicación ser exactamente lo que se necesita para otro. Los formatos de archivo estándar han crecido con el tiempo. Sistemas mainframe suelen utilizar fuentes de datos en base a los formatos del sistema de archivo de COBOL. Sistemas Unix utilizan archivos de texto basados en XML.

DESVENTAJA:


Escalabilidad: Una de las limitaciones de este estilo de integración es que es poco escalable dado que la aplicación debe generar un file para cada aplicación cliente, lo que vuelve ineficiente el proceso si la cantidad de receptores aumenta.

2. Identifique un patrón que ha visto en el curso o que ha aplicado en su proyecto. ¿Qué opina del patrón? 

Shared Database:


Al tener una base de datos única tenemos la ventaja de que la integridad de la misma está asegurada. Adicionalmente con este estilo la transaccionalidad no es un problema especialmente en el caso de actualizaciones simultáneas a un mismo grupo de datos desde diferentes fuentes.   Del mismo modo, con esta base de datos centralizada no es necesario preocuparse del formato de archivos pues todas usarán la indicada por la base.



Referencias:


https://dsd2014tips.wordpress.com/2014/10/11/enterprise-integration-patterns-estilos/http://www.enterpriseintegrationpatterns.com/patterns/messaging/toc.htmlhttp://www.internetya.co/que-es-el-servicio-ftp-file-transfer-protocol/http://www.ordenadores-y-portatiles.com/ftp.html

Foro 3 - Ws-Policy

Ws-Policy

1. Elabore un resumen de la especificación.

WS-Policy es una especificación que forma parte de la familia de especificaciones de tecnologías basadas en servicios web del W3C. Esta especificación permite a los programadores de servicios web anunciar sus políticas relativas a seguridad, calidad de servicio, etc. y a los clientes de servicios web especificar sus requisitos de calidad de servicio, seguridad, latencia, etc. WS-Policy es una recomendación del W3C desde septiembre de 2007.

La especificación WS-Policy está formada por un conjunto de especificaciones que describen las capacidades y restricciones asociadas a determinados servicios web.

 Define un framework y un modelo para expresar características y requerimientos de un servicio.  Delega a otras especificaciones la definición de políticas particulares a un dominio.

Modelo:

Policy Assertions
 - Requerimiento o característica que describe al servicio.
 - Poseen un tipo de acuerdo al dominio al que pertenecen.

Policy Alternatives
- Conjunto de assertions

Policy
- Conjunto de alternativas


Por qué utilizar WS-Policy

Los clientes que consumen servicios web deben estudiar la información de directivas para ver si pueden o no respetarlas. Por ende, no se puede escribir un cliente para que simplemente acceda a un servicio web que requiera que todos los mensajes sean cifrados o firmados de cierta manera. Un cliente tampoco accedería a un servicio web que tiene una directiva que requiere una marca de tiempo y enviar un mensaje que no la tenga. Y ese es el objetivo de WS-Policy: especificar información de directivas que deben respetar los consumidores del servicio web.

2. Describa con un ejemplo en que caso aplica el uso de la especificación.

<wsp:Policy

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

xmlns:sec="http://schemas.xmlsoap.org/ws/2002/12/secext" >



  <wsp:ExactlyOne>

    <wsp:All>

      <sec:SecurityToken>

        <sec:TokenType>sec:X509v3</sec:TokenType>



      </sec:SecurityToken>

    </wsp:All>

  </wsp:ExactlyOne>

</wsp:Policy>

3. Investigue con que tecnologías puede desarrollar una solución que cumpla con la especificación.

Tecnologia XML
Apache Axis2 versión 1.0
Java 2 Standard Edition versión 1.4.2

Foro 1 - Comparacion con Web Servis Rest

SOAP Y REST

Diferencias

Foro 1

Web Services Soap

Características Principales:

• SOAP generalmente,  es relativamente sencillo de utilizar.
• SOAP es un protocolo extraordinariamente complejo pensado para dar soluciones a casi cualquier necesidad en lo que a comunicaciones se refiere, incluyendo aspectos avanzados de seguridad, transaccionalidad, mensajería asegurada y demás
• Es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambios de datos XML, el punto identificativo de SOAP es que las operaciones son definidas como puertos WSDL (Web Services Description Language).
• Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el desarrollo).
• Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP, SMTP, TCP o JMS).
• Independencia (SOAP permite cualquier modelo de programación).

Ventajas:

• El Web Services Description Language (WSDL) contiene y describe el conjunto de normas comunes para definir los mensajes, los enlaces, las operaciones y la ubicación del servicio Web. WSDL es un tipo de contrato formal para definir la interfaz que ofrece el servicio Web.
• SOAP requiere menos código de plumbing code de servicios REST, (es decir, las transacciones, la seguridad, la coordinación, direccionamiento, la confianza, etc) La mayoría de las aplicaciones en el mundo real no son simples y apoyar las operaciones complejas, que requieren para mantener el estado de conversación y la información contextual. Con el enfoque de SOAP , los desarrolladores no tienen que preocuparse acerca de cómo escribir el código de plomería en la capa de aplicación a sí mismos.
• Es más seguro debido a que su implementación siempre o la mayoría de las veces se hace del lado del servidor.
• Soporta varios protocolos y tecnologías, incluyendo WSDL, XSD, SOAP y WS-Addressing.

Desventajas:

• Si se desea modificar algo en el servidor esto impacta de una forma negativa en los clientes ya que ellos realizar varias modificaciones al código
• Si no se cuenta con las herramientas correctas, la interpretación puede tornarse demasiado compleja y difícil.
• Las desventajas de la utilización de SOAP recaen en la dificultad para entender las especificaciones del protocolo, puesto que es un complejo esquema de codificación en el cual es necesario precisar que todos los mensajes se incluyan en un sobre, con el contenido del mensaje dentro de un elemento de cuerpo para que puedan ser entendidos por cada una de las aplicaciones Web que procesan el mensaje.
• SOAP convierte en opcionales elementos como encabezados y ofrece un amplio margen con respecto a lo que se puede incluir en el elemento de cuerpo y además cambia los nombres de métodos en etiquetas secundarias del cuerpo y los argumentos en etiquetas secundarias del nombre del método, lo que puede generar ciertos problemas de interoperabilidad.
• Las especificaciones SOAP indican que si recibe un encabezado SOAP con un atributo must Understand establecido como "1", deberá entenderlo o generar un error. Numerosas implementaciones no lo hicieron al principio lo que implicó problemas de interoperabilidad.