Que tan RESILIENTES pueden ser los sistemas hoy en día?

La resiliencia es la habilidad que tiene un sistema de regresar al equilibrio después de haber sufrido cualquier transformación. Al final, el sistema mantiene su misma función, estructura y por ende los mecanismos de retroalimentación.

Los descubrimientos más recientes han cuestionado el porqué algunos sistemas pueden llegar a adaptarse y otros no. Algunos si pueden adaptarse al cambio y continúan desarrollándose.

En la medida que la tecnología toma protagonismo en los negocios, el riesgo y costos por pérdidas de información es mayor.

Según el Estudio Global de IBM sobre el Impacto Económico de Riesgos de TI, una interrupción de 20 minutos puede costar a la organización más de 1 millón de dólares. Una interrupción importante, que dure en promedio siete horas, puede implicar costos por encima de los 105.000 dólares para una empresa que facture en promedio 2 millones de dólares al año.

La capacidad de resiliencia determina la competitividad de las organizaciones. Las políticas y tecnologías integradas para reducir los tiempos de inactividad en los sistemas empresariales constituyen un activo de resistencia a fallos y riesgos de integridad en los datos.

No es de extrañar que, por ello, las organizaciones estén dispuestas a invertir recursos para asegurar que los sistemas, datos y aplicaciones estén casi siempre disponibles para protegerlos de los riesgos, que van desde errores humanos a los fenómenos meteorológicos.

Estos esfuerzos, dentro de una estrategia de recuperación de desastres y continuidad del negocio (Disaster Recovery & Business Continuity), implica la recuperación de infraestructura y de los tiempos de inactividad en los sistemas. Conceptos que se les reconoce como objetivos de recuperación de puntos (Recovery Points Objectives, RPO) y objetivos de recuperación de tiempos (Recovery Time Objectives, RTO).

Con esto se asegura, a nivel de negocio, la continuidad de negocios para sus clientes externos e internos, asimismo frente a la competencia.

RESILENCIA CIBERNETICA - Vulnerabilidad de los Sistemas

La seguridad informática, o también conocida como resiliencia cibernética, es una de las mayores preocupaciones de la sociedad actual y es vulnerable. Esto es debido principalmente a la baja complejidad de las contraseñas que generamos, poniendo en riesgo la seguridad de los sistemas informáticos.

La razón al parecer, es debido a que las las contraseñas son demasiado simples y se usan de forma recurrente. Así pues, según el responsable de riesgos tecnológicos en Deloitte, Dean Kingsley, la mayor parte de las contraseñas son vulnerables en cinco horas. “Las empresas deben asumir que pueden sufrir un ataque en cualquier momento y prepararse convenientemente. Es el momento de pasar de la simple prevención a la detección y respuesta planificada”, asegura el experto. “El objetivo es crear una organización resistente que pueda responder rápidamente a los ataques”, insiste.

El estudio demuestra que, el 79% de los usuarios tienen las 500 contraseñas más utilizadas; el 40% las 100 más usadas y un 14% las 10 claves más utilizadas. Incluso, un 9,8% de usuarios escribe “password 123456 o 12345678” como contraseña; un 8,5% tiene por clave “password o 123456” y un 4,7% de los usuarios tiene por contraseña “password”

Dentro de las contraseñas mas utilizadas estan los nombres de la persona, miembros de la familia, fechas de nacimiento, etc. Información que, debido a las redes sociales es facild e adquirir

Franklin Noguera, Socio de la división de Gestión de Riesgo Empresarial Deloitte Centroamérica, comenta sobre la falta de sensibilización de los empleados y las organizaciones sobre el tema de la seguridad informática “la interrogante no es si usted va a ser atacado; la interrogante es cuándo y cómo va usted a responder. Una gestión efectiva de los riesgos de la seguridad informática exige una combinación fuerte de la prevención, detección temprana y respuesta rápida. Alcanzar la ciber-resiliencia es tan, o más importante que tener seguridad cibernética por sí sola”.

Hermes Romero, Gerente Gestión de Riesgo Esmpresarial Deloitte Honduras, llama la atención sobre la necesidad de generar una conciencia sobre la importancia de la gestión de la seguridad de la información y verla como una inversión para las organizaciones.

Esto significa que las organizaciones necesitan un proveedor de servicios que tenga la visión y la capacidad de orquestar solución de resiliencia adecuada a partir de esta combinación de tecnologías y servicios establecidos y emergentes.

LA ORGANIZACION MAS RECONOCIDA EN RESILENCIA

IBM Resiliency Services ha sido reconocido como líder en el Gartner Magic Quadrant de 2015 por Disaster Recovery como servicio. Para este informe, Gartner consideró cerca de 30 candidatos, seleccionó y evaluó a 14 proveedores de servicio, designando a IBM Resiliency como líder en DRcS con base en su amplitud de visión y capacidad de ejecución.

El universo digital se expande, y garantizar la continuidad del negocio se hace cada vez más complejo. Según Forrester, una de cada tres empresas declaró haber sufrido algún tipo de falla o desastre que afectó la continuidad de sus negocios. Hace tan sólo tres años, esto lo declaraban una de cada cinco.

Es necesario considerar todos los elementos para garantizar la continuidad del negocio y evitar pérdidas de información, déjanos saber tus dudas e inquietudes desde i cloud seven diseñamos la arquitectura que mejor se adapte a tu negocio, somos partners certificados de Amazon Web Services y Microsoft Azure, proveedores de Cloud Computing líderes del mercado, solicita una cita con uno de nuestros especialistas sin ningún costo.

Referencias:

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

https://blog.uchceu.es/informatica/resiliencia-cibernetica-quien-tiene-la-culpa-de-la-vulnerabilidad-de-los-sistemas-informaticos/

http://icloudseven.com/microsoft-azure/

http://icloudseven.com/amazon-web-services-aws/

http://icloudseven.com/resiliencia-empresarial-desde-la-nube/

Sistemas Distribuidos... en la NUBE (Cloud computing)

Los sistemas en la nube es un paradigma que permite ofrecer servicios de computación a través de Internet. En este tipo de computación todo lo que puede ofrecer un sistema informático se ofrece como servicio, de modo que los usuarios puedan acceder a los servicios disponibles en la nube mediante Internet sin conocimientos de la gestión de los recursos que se utilizan.

Según el IEEE Computer Society, es un paradigma en el que la información se almacena de manera permanente en servidores de Internet y se envía a cachés temporales de clientes. Esto se debe a que, pese a que las capacidades de las PCs han mejorado sustancialmente, gran parte de su potencia se desaprovecha, al ser máquinas de propósito general.

Cloud computing es un nuevo modelo de prestación de servicios de negocio y tecnología, que permite al usuario acceder a un catálogo de servicios estandarizados y responder a las necesidades de su negocio, de forma flexible y adaptativa pagando únicamente por el consumo efectuado. El cambio paradigmático que ofrece cloud computing es que permite aumentar el número de servicios basados en la red. Esto genera beneficios tanto para los proveedores que pueden ofrecer de forma más rápida y eficiente un mayor número de servicios, así como también proporciona beneficios para los usuarios que tienen la posibilidad de acceder a ellos aprovechando de la transparencia e inmediatez del sistema. 

Cloud computing consigue aportar las ventajas antes mencionadas basándose en una infraestructura tecnológica dinámica que se caracteriza por un alto grado de automatización, una rápida gestión de los recursos, una elevada capacidad de adaptación para responder a la demanda variable, así como virtualización avanzada y un precio flexible en función del consumo realizado evitando además el uso fraudulento del software y la piratería.

Este concepto que incorpora el software como servicio (SaaS) siendo una de las tendencias tecnológicas. El concepto de la cloud computing comenzó en proveedores de servicio de Internet a gran escala, como Google, Amazon WS y otros que construyeron su propia infraestructura. De entre todos ellos emergió una arquitectura: un sistema de recursos distribuidos horizontalmente, introducidos como servicios virtuales de TI escalados masivamente y manejados como recursos configurables. Este modelo de arquitectura fue inmortalizado por George Gilder en su artículo de diciembre de 2006 en la revista Wired titulado “Las fábricas de información”.

PRINCIPALES VENTAJAS

• Integración probada de servicios: por su naturaleza, la tecnología de Cloud Computing se puede integrar con mucha mayor facilidad y rapidez con otras aplicaciones desarrolladas.
• Prestación de servicios a nivel mundial: las infraestructuras de "Cloud Computing" proporcionan mayor capacidad de adaptación, recuperación de desastres y reducción al mínimo de los tiempos de inactividad debido a la infraestructura que posee.
• Una infraestructura 100% cloud computing no necesita instalar ningún tipo de hardware, es por eso, que se la considera una tecnología simple y que requiere mucha menor inversión para empezar a trabajar.
• La implementación de una aplicación en la nube es más rápida y con menos riesgos debido a que se obvian cuestiones como la compra de HW, instalación, mecanismos de contingencia, etc.
• Contribuye al uso eficiente de la energía para el funcionamiento de la infraestructura. En los datacenters tradicionales los servidores consumen mucha más energía de la requerida realmente. En cambio en la nube la energía consumida es sólo la necesaria, reduciendo notablemente el desperdicio.

DESVENTAJAS

• La centralización de las aplicaciones y el almacenamiento de los datos origina una interdependencia con los proveedores de servicios.
• La disponibilidad de las aplicaciones están ligadas a la disponibilidad de acceso a internet.
• Los datos “sensibles" de la aplicación no residen en las instalaciones del cliente por lo que podría generar un contexto de alta vulnerabilidad para la sustracción o robo de información.
• La confiabilidad de los servicios depende de la inversión en infraestructura tecnológica por parte de los proveedores de servicios en nube.
• La disponibilidad de servicios altamente especializados podría tardar meses o incluso años para que sean factibles de ser desplegados en la red.
• En relación a la seguridad, la información del cliente debe recorrer diferentes nodos para llegar a su destino, cada uno de ellos son foco de inseguridad. Si se utilizan protocolos seguros como HTTPS por ejemplo, la velocidad total disminuye debido a la sobrecarga que estos requieren.
• Escalabilidad a largo plazo: a medida que más usuarios empiecen a compartir la infraestructura de la nube la sobrecarga en los servidores de los proveedores aumentará y corre por cuenta del proveedor de la nube que posea un esquema de crecimiento óptimo de su infraestructura.

TIPOS DE NUBES

Nubes públicas, donde las aplicaciones de muchos clientes diferentes pueden estar compartiendo recursos de servidores, sistemas de almacenamiento y otras infraestructuras de la nube.

Nubes privadas, orientadas a clientes que necesitan alta protección de datos y estrictos SLA. Las nubes privadas están en una infraestructura administrada por un solo cliente que controla qué aplicaciones deben correr y dónde. El cliente es propietario del servidor, red, y disco y pueden decidir qué usuarios están autorizados a utilizar dicha infraestructura.

Nubes híbridas, combinan los modelos de nubes públicas y privadas donde el cliente es propietario de algunas partes y comparte otras, aunque de una manera controlada.

PARADIGMA MOVIL EN LA NUBE

Básicamente, se refiere a una infraestructura que tanto el almacenamiento de datos y el procesamiento de datos tienen lugar fuera del dispositivo móvil. En la actualidad, ya existen algunos buenos ejemplos de las aplicaciones móviles de cloud computing como Gmail para móviles, Google Maps, y algunas aplicaciones de navegación. Sin embargo, la mayoría de las aplicaciones de hoy todavía almacenan los datos en el dispositivo y el procesamiento también se lleva a cabo dentro del dispositivo móvil y no en la nube.

El Mobile Cloud Computing (MCC), integra la tecnología cloud computing en el entorno móvil y supera los obstáculos relacionados con el rendimiento (por ejemplo, duración de la batería, almacenamiento y ancho de banda), el ambiente (por ejemplo, la heterogeneidad, escalabilidad y disponibilidad), y la seguridad (por ejemplo, la fiabilidad y la privacidad) tan discutidos en la computación móvil. Los usuarios móviles acumulan una rica experiencia sobre distintos servicios ofrecidos por aplicaciones móviles (por ejemplo, aplicaciones de iPhone, aplicaciones de Android, etc), que se ejecutan en los dispositivos y/o en servidores remotos a través de redes inalámbricas.

VENTAJAS DE LA COMPUTACION MOVIL

Mejorar la capacidad de almacenamiento de datos y potencia de procesamiento:

La capacidad de almacenamiento es también uno de los obstáculos de los dispositivos móviles. MCC permite a los usuarios móviles almacenar y acceder a los datos de gran tamaño desde la nube a través de las redes inalámbricas.

El primer ejemplo es el servicio de Amazon Simple Storage (Amazon) que posee un servicio de almacenamiento de archivos. Facebook es la aplicación de redes sociales con más éxito hoy en día, y también es un típico ejemplo del uso de la nube en el intercambio de imágenes. Con la nube, los usuarios pueden ahorrar una gran cantidad de energía y espacio de almacenamiento en los dispositivos móviles ya que, por ejemplo, todas las imágenes son enviadas y procesadas en la nube.

Mejora de la fiabilidad: 

El almacenamiento de datos o la ejecución de aplicaciones en la nube es una forma efectiva para mejorar la fiabilidad ya que los datos y la aplicación se almacenan al mismo tiempo que se realizan backup en un cierto número de equipos. Esto reduce el intercambio de dato y la posibilidad de pérdida de aplicaciones en los dispositivos móviles. Además, MCC puede ser diseñado como un modelo de seguridad de datos completo tanto para los proveedores de servicios como para los usuarios.

Por ejemplo, la nube puede ser utilizada para proteger los derechos de autor de contenidos digitales (por ejemplo, de vídeo, música, etc.) de distribución no autorizada, uso indebido, etc. Además, la nube de forma remota puede proporcionar a los usuarios móviles con servicios de seguridad tales como escaneo de virus, detección de código malicioso y autenticación.

Referencias:

https://es.wikipedia.org/wiki/Computaci%C3%B3n_en_la_nube

http://computacionennube-milagritos.blogspot.pe/p/computacion-en-nube-y-computacion.html

http://www.pros.upv.es/es/eventos/proximoseventos/86-raiz-espanol-es-es/empresas/ofertatecnologica/123-diseno-y-desarrollo-de-sistemas-ubicuos-y-de-inteligencia-ambiental

https://gissic.files.wordpress.com/2011/07/computacion_en_nube_revista_paraguay_luis_joyanes.pdf

http://e-learningupiicsa.blogspot.pe/2013/04/ventajas-y-desventajas-del-computo-en.html

APIS... REST o SOAP??

Las APIs (Application Programming Interface) están cada vez más presentes en todo, y es muy común el debate SOAP vs REST en el diseño de este tipo de aplicaciones.

Esto comienza en la forma en como se debe ofrecer una API. Las iniciativas de la web 2.0 y la corriente avalancha de servicios online, parece que han optado por las APIs REST. Incluso, si lo que se quiere es ofrecer servicios, no es necesario habilitar una API, existen empresas como APIGee, 3Scale o Mashery que ya lo hacen por uno.

Resaltando que REST utiliza casi siempre HTTP como método de comunicación y XML o JSON para intercambiar datos. Cada URL representa un objeto sobre el que se pueden utilizar los métodos POST, GET, PUT y DELETE. Es decir, utiliza el idioma de la web.

En tanto que SOAP, es toda una infraestructura, generalmente basada en XML, cada objeto puede tener métodos definidos por el programador con los parámetros que sean necesarios.

Con esto, puede estar claro que REST es ligero, con poca configuración, se lee fácilmente (son URLs) y no hace falta nada especial para implementarlo. El SOAP, mucho más ambicioso, es fácil de consumir y tiene un tipificado fuerte (WSDL).

La diferencia se ve aún mejor en este ejemplo, ¿cómo añadimos dinero a nuestra cuenta?, ¿y cómo vemos lo que tenemos?

En SOAP:

bank = new SOAPProxy(“http://…..”)

bank.addMoneyToAccount(account 123456789, 50 euro)

bank = new SOAPProxy(“http://…..”)

bank.getAccountBalance(account 123456789)

En REST:

http://…/bank/addMoneyToAccount?account=123456789&money=50

http://…/bank/getAccountBalance?account=123456789

Al parecer en REST todo son URIs, las cosas están localizables y accesibles, en SOAP, las cosas son mucho más jerárquicas, pero quizá más controladas. ¿Más seguras?.

Lo bueno de que existan alternativas es que se están tomando cosas buenas de uno y otro lado, cada uno resalta las deficiencias del otro, y se buscan soluciones para que éstas se minimicen. Por ejemplo, los ya mencionados APIgee actúan como un tercero que controla accesos a tu API, en SOAP se ha mejorado la seguridad, el JSON se está convirtiendo en una lingua franca de intercambio de payloads, Google y Mozilla atacan con los Web Intents, etc.

REST API

REST (REpresentational State Transfer) nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP, por lo que es increíblemente más simple y convencional que otras alternativas que se han usado en los últimos diez años como SOAP y XML-RPC.

Podríamos considerar REST como un framework para construir aplicaciones web respetando HTTP.

Por lo tanto REST es el tipo de arquitectura más natural y estándar para crear APIs para servicios orientados a Internet.

Existen tres niveles de calidad a la hora de aplicar REST en el desarrollo de una aplicación web y más concretamente una API que se recogen en un modelo llamado Richardson Maturity Model en honor al tipo que lo estableció, Leonard Richardson padre de la arquitectura orientada a recursos. Estos niveles son:

1. Uso correcto de URIs
2. Uso correcto de HTTP.
3. Implementar Hypermedia.

Además de estas tres reglas, nunca se debe guardar estado en el servidor, toda la información que se requiere para mostrar la información que se solicita debe estar en la consulta por parte del cliente.

Al no guardar estado, REST nos da mucho juego, ya que podemos escalar mejor sin tener que preocuparnos de temas como el almacenamiento de variables de sesión e incluso, podemos jugar con distintas tecnologías para servir determinadas partes o recursos de una misma API.

Nivel 1: Uso correcto de URIs

Cuando desarrollamos una web o una aplicación web, las URLs nos permiten acceder a cada uno de las páginas, secciones o documentos del sitio web.

Cada página, información en una sección, archivo, cuando hablamos de REST, los nombramos como recursos.

El recurso por lo tanto es la información a la que queremos acceder o que queremos modificar o borrar, independientemente de su formato.

Las URL, Uniform Resource Locator , son un tipo de URI, Uniform Resource Identifier, que además de permitir identificar de forma única el recurso, nos permite localizarlo para poder acceder a él o compartir su ubicación.

Una URL se estructura de la siguiente forma:

Existen varias reglas básicas para ponerle nombre a la URI de un recurso:

• Los nombres de URI no deben implicar una acción, por lo tanto debe evitarse usar verbos en ellos.
• Deben ser únicas, no debemos tener más de una URI para identificar un mismo recurso.
• Deben ser independiente de formato.
• Deben mantener una jerarquía lógica.
• Los filtrados de información de un recurso no se hacen en la URI.

Las URIs no deben implicar acciones y deben ser únicas

Por ejemplo, la URI /facturas/234/editar sería incorrecta ya que tenemos el verbo editar en la misma.

Para el recurso factura con el identificador 234, la siguiente URI sería la correcta, independientemente de que vayamos a editarla, borrarla, consultarla o leer sólo uno de de sus conceptos: /facturas/234

Las URIs deben ser independientes de formato

Por ejemplo, la URI /facturas/234.pdf no sería una URI correcta, ya que estamos indicando la extensión pdf en la misma.

Para el recurso factura con el identificador 234, la siguiente URI sería la correcta, independientemente de que vayamos a consultarla en formato pdf, epub, txt, xml o json: /facturas/234

Las URIs deben mantener una jerarquía lógica

Por ejemplo, la URI /facturas/234/cliente/007 no sería una URI correcta, ya que no sigue una jerarquía lógica.

Para el recurso factura con el identificador 234 del cliente 007, la siguiente URI sería la correcta: /clientes/007/facturas/234

Filtrados y otras operaciones.

Para filtrar, ordenar, paginar o buscar información en un recurso, debemos hacer una consulta sobre la URI, utilizando parámetros HTTP en lugar de incluirlos en la misma.

Por ejemplo, la URI /facturas/orden/desc/fecha-desde/2007/pagina/2 sería incorrecta ya que el recurso de listado de facturas sería el mismo pero utilizaríamos una URI distinta para filtrarlo, ordenarlo o paginarlo.

La URI correcta en este caso sería:

/facturas?fecha-desde=2007&orden=DESC&pagina=2

Nivel 2: HTTP

Conocer bien HTTP no es opcional para un desarrollador web al que le importe su trabajo. Aunque el RFC es sencillo de leer, si estás interesado en aprender bien las bases de este protocolo es muy recomendable la guía de O’Reilly sobre el mismo.

Para desarrollar APIs REST los aspectos claves que hay que dominar y tener claros son:

• Métodos HTTP
• Códigos de estado
• Aceptación de tipos de contenido

Métodos.

Como hemos visto en el anterior nivel, a la hora de crear URIs no debemos poner verbos que impliquen acción, aunque queramos manipular el recurso.

Para manipular los recursos, HTTP nos dota de los siguientes métodos con los cuales debemos operar:

• GET: Para consultar y leer recursos
• POST: Para crear recursos
• PUT: Para editar recursos
• DELETE: Para eliminar recursos.
• PATCH: Para editar partes concretas de un recurso.

Por ejemplo para un recurso de facturas.

GET /facturas Nos permite acceder al listado de facturas

POST /facturas Nos permite crear una factura nueva

GET /facturas/123 Nos permite acceder al detalle de una factura

PUT /facturas/123 Nos permite editar la factura, sustituyendo la totalidad de la información anterior por la nueva.

DELETE /facturas/123 Nos permite eliminar la factura

PATCH /facturas/123 Nos permite modificar cierta información de la factura, como el número o la fecha de la misma.

Quizá debido al desconocimiento o el soporte de ciertos navegadores, los desarrolladores web han usado, durante los últimos años, únicamente los métodos GET Y POST para realizar todas estas acciones. Si trabajamos con REST, esto sería un error de base y puede darnos problemas incluso a la hora de nombrar nuestros recursos, obligándonos a poner verbos en las URLs.

Códigos de estado.

Uno de los errores más frecuentes a la hora de construir una API suele ser el reinventar la rueda creando nuestras propias herramientas en lugar de utilizar las que ya han sido creadas, pensadas y testadas. La rueda más reinventada en el desarrollo de APIs son los códigos de error y códigos de estado.

Cuando realizamos una operación, es vitar saber si dicha operación se ha realizado con éxito o en caso contrario, por qué ha fallado.

Un error común sería por ejemplo:

En este ejemplo se devuelve un código de estado 200, que significa que la petición se ha realizado correctamente, sin embargo, estamos devolviendo en el cuerpo de la respuesta un error y no el recurso solicitado en la URL.

Este es un error común que tiene varios inconvenientes:

• No es REST ni es estándar.
• El cliente que acceda a este API debe conocer el funcionamiento especial y cómo tratar los errores de la misma, por lo que requiere un esfuerzo adicional importante para trabajar con nosotros.
• Tenemos que preocuparnos por mantener nuestros propios códigos o mensajes de error, con todo lo que eso supone.

HTTP tiene un abanico muy amplio que cubre todas las posibles indicaciones que vamos a tener que añadir en nuestras respuestas cuando las operaciones han ido bien o mal.

Es imperativo conocerlos y saber cuándo utilizarlos, independientemente de que desarrolles siguiendo REST.

El siguiente ejemplo sería correcto de la siguiente forma:

Tipos y formatos de contenido.

Cuando hablamos sobre URLs, vimos también que no era correcto indicar el tipo de formato de un recurso al cual queremos acceder o manipular.

HTTP nos permite especificar en qué formato queremos recibir el recurso, pudiendo indicar varios en orden de preferencia, para ello utilizamos el header Accept.

Nuestra API devolverá el recurso en el primer formato disponible y, de no poder mostrar el recurso en ninguno de los formatos indicados por el cliente mediante el header Accept, devolverá el código de estado HTTP 406.

En la respuesta, se devolverá el header Content-Type, para que el cliente sepa qué formato se devuelve, por ejemplo:

En este caso, el cliente solicita la factura en epub comprimido con ZIP y de no tenerlo, en pdf o json por orden de preferencia. El servidor le devuelve finalmente la factura en pdf.

Nivel 3: Hypermedia.

A pesar de lo que nos pueda inducir a pensar el término retrofuturista Hypermedia, el concepto y la finalidad que busca describir es bastante sencillo: conectar mediante vínculos las aplicaciones clientes con las APIs, permitiendo a dichos clientes despreocuparse por conocer de antemano del cómo acceder a los recursos.

Con Hypermedia básicamente añadimos información extra al recurso sobre su conexión a otros recursos relacionados con él.

Aquí tenemos un ejemplo:

En este ejemplo vemos cómo indicar en un xml que representa un pedido, el enlace al recurso de la factura relacionada con el mismo.

Sin embargo, necesitamos que el cliente que accede a nuestra API entienda que esa información no es propia del recurso, sino que es información añadida que puede utilizar para enlazar el pedido con la factura.

Para ello conseguir esto, debemos utilizar las cabeceras Accept y Content-Type, para que tanto el cliente como la API, sepan que están hablando hypermedia.

Por ejemplo:

Como vemos, el cliente solicita el formato application/nuestra_api+xml de forma preferente al formato text/xml. De esta forma, le indica al servicio web, que entiende su formato hypermedia y puede aprovecharlo.

El servicio web por lo tanto, como implementa hypermedia, le devuelve la información de recurso y la información de hypermedia que puede utilizar el cliente.

Hypermedia es útil por ejemplo para que el cliente no tenga que conocer las URLs de los recursos, evitando tener que hacer mantenimientos en cada uno de los mismos si en un futuro dichas URLs cambian (cosa que no debería pasar). También es útil para automatizar procesos entre APIs sin que haya interacción humana.

Conclusión

Como hemos visto, los principios básicos para construir APIs REST se basan en conocer sobre todo HTTP, algo que ya no es opcional en el desarrollo web.

Referencias:

http://en.wikipedia.org/wiki/Resource-oriented_architecture

http://apigee.com/

http://www.3scale.net/

http://mashery.com/

http://movilforum.com/apis-seguimos-con-el-rest-vs-soap/

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

http://www.w3.org/Protocols/rfc2616/rfc2616.html

http://es.wikipedia.org/wiki/Anexo:C%C3%B3digos_de_estado_HTTP

http://www.w3.org/Provider/Style/URI.html

SCRUM en SOA

SCRUM es una metodología de desarrollo ágil que se caracteriza por adoptar una estrategia de forma incremental, tan es así, que deja de lado la planificación y ejecución del producto.

También basa la calidad del resultado en las conclusiones de los equipos de personas auto organizados que en la calidad de los procesos en sí.

Debido a que se basa en un desarrollo ágil, las organizaciones lo usan para obtener una adecuada arquitectura orientada a servicios (SOA), en sus modelos de negocio.

Principales características:

Modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto, donde los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que representa a los stakeholders(interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

También realiza una gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último equipo motivado. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.

Referencias:

https://es.wikipedia.org/wiki/Scrum
https://proyectosagiles.org/beneficios-de-scrum/
https://es.wikipedia.org/wiki/Desarrollo/Agildesoftware/