f?:@'.$&2& %g&1'210*%a'*5% h&$02'$$%!5&102$%!,ij ·...
TRANSCRIPT
Avenida de Castilla,1 - Edificio Best Point - Oficina 21B28830 San Fernando de Henares (Madrid)
tel./fax: +34 91 675 33 [email protected] - www.autentia.com
Somos su empresa de Soporte a Desarrollo Informático.Ese apoyo que siempre quiso tener...
1. Desarrollo de componentes y proyectos a medida
TecnologíaDesarrolloSistemas
Gran Empresa
Producción
autentia
Certificacióno Pruebas
Verificación previa
RFP Concurso
Consultora 1
Consultora 2
Consultora 3
Equipo propio desarrolloPiloto
3a
3b
1. Definición de frameworks corporativos.2. Transferencia de conocimiento de nuevas arquitecturas.3. Soporte al arranque de proyectos.4. Auditoría preventiva periódica de calidad.5. Revisión previa a la certificación de proyectos.6. Extensión de capacidad de equipos de calidad.7. Identificación de problemas en producción.
3. Arranque de proyectos basados en nuevas tecnologías
¿Qué ofrece Autentia Real Business Solutions S.L?
Para más información visítenos en: www.autentia.com
Compartimos nuestro conociemiento en: www.adictosaltrabajo.com
Gestor portales (Liferay)Gestor de contenidos (Alfresco)Aplicaciones híbridas
Tareas programadas (Quartz)Gestor documental (Alfresco)Inversión de control (Spring)
BPM (jBPM o Bonita)Generación de informes (JasperReport)ESB (Open ESB)
Control de autenticación y acceso (Spring Security)UDDIWeb ServicesRest ServicesSocial SSOSSO (Cas)
Spring MVC, JSF-PrimeFaces /RichFaces, HTML5, CSS3, JavaScript-jQuery
JPA-Hibernate, MyBatisMotor de búsqueda empresarial (Solr)ETL (Talend)
Dirección de Proyectos Informáticos.Metodologías ágilesPatrones de diseñoTDD
2. Auditoría de código y recomendaciones de mejora
4. Cursos de formación (impartidos por desarrolladores en activo)
1/10/14 SOA vs. SOAP y REST
www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=SOAvsSOAPREST 1/4
Entra en Adictos a través de
Entrar
E-mail
Contraseña
Deseo registrarmeOlvidé mi contraseña
Inicio Quiénes somos Formación Comparador de salarios Nuestros libros Más
» Estás en: Inicio Tutoriales SOA vs. SOAP y REST
Síguenos a través de:
Catálogo de servicios
Autentia
Últimas Noticias
» IX Autentia Cycling Day(ACTUALIZADO)
» Autentia en la carrera delas empresas
» Spring 4.0 ¿qué hay denuevo amigo?
» Torneo de pádel solidarioAMEB
» Próxima charla: Gradlecomo alternativa a Mavenpara la construcción deproyectos en Java
Histórico de noticias
Últimos Tutoriales
» Mi primera vista en ZKcomo desarrollador JSF (I).
» Transicionespersonalizadas en iOS7
» Spring BeanPostProcessor
» Cómo montar un raid1 enuna máquina corriendodebian.
» Notificaciones locales eniOS.
Ver todos los tutoriales del autor
Miguel Arlandy Rodríguez
Consultor tecnológico de desarrollo de proyectos informáticos.
Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo,factoría y formación
Somos expertos en Java/JEE
Fecha de publicación del tutorial: 2014-01-10 Tutorial visitado 1 veces Descargar en PDF
SOA vs. SOAP y REST.
0. Índice de contenidos.
1. Introducción.2. Entorno.3. ¿Por qué servicios web basados en SOAP o REST?.4. ¿Por qué SOA?.5. La relación entre SOA y los servicios web basados en SOAP o REST.6. Referencias.7. Conclusiones.
1. Introducción
SOA y SOAP suelen ser términos que, a menudo, suelen generar bastante confusión (supongo que por la semejanza desus siglas). Parece que muchas veces no tenemos del todo claro dónde empieza y acaba cada cosa aunque, en elfondo, sabemos que existe relación entre ambos términos. Incluso es común encontrar por ahí algunos artículos dondese refieren a SOA cuando realmente quieren decir SOAP.
Con el desarrollo de servicios web basados en REST también puede ocurrir algo parecido.
En este tutorial intentaremos explicar qué diferencias existen entre una arquitectura SOA y el desarrollo de servicios webbasados en SOAP o REST, cómo se relacionan y los beneficios esperados de cada uno.
2. Entorno.
El tutorial está escrito usando el siguiente entorno:
Hardware: Portátil MacBook Pro 15' (2.2 Ghz Intel Core I7, 8GB DDR3).Sistema Operativo: Mac OS X Mavericks 10.9
3. ¿Por qué servicios web basados en SOAP o REST?.
Nótese que este punto no pretende ser una comparativa entre SOAP y REST, lo que intentaremos es destacar losobjetivos y características comunes del desarrollo de servicios web basados en SOAP o REST.
SOAP y REST son siglas asociadas a estándares para el diseño y desarrollo de web services o servicios RESTful. El usomás común que se suele dar a estos servicios es el de integrar diferentes sistemas o componentes de una o variasplataformas. Mediante el uso de estándares conseguimos que esa integración se convierta en interoperabilidad. Lainteracción se consigue mediante el intercambio de mensajes entre sistemas.
Es muy común ver cómo se emplean tanto SOAP como REST para exponer parte de la funcionalidad (o recursos) dediferentes aplicativos. Tenemos ejemplos muy claros de esto en dos excelentes herramientas como son Sonar y Jenkins.En este caso exponen recursos a través de un API REST (imagino que por sencillez y porque los requisitos lo permiten)para que otros sistemas puedan interoperar con ellos. Lógicamente, esta misma filosofía es aplicable dentro de unaplataforma empresarial.
1/10/14 SOA vs. SOAP y REST
www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=SOAvsSOAPREST 2/4
Últimos Tutoriales del
Autor
» REST, el principioHATEOAS y SpringHATEOAS
» SOA y los tipos de servicios
» Introducción a Spring Batch
» Iconos increíbles paranuestra web con FontAwesome Icons
» WebSockets con Stomp yActiveMQ: ¿chateamos?
Últimas ofertas de
empleo
2011-09-08Comercial - Ventas -MADRID.
2011-09-03Comercial - Ventas -VALENCIA.
2011-08-19Comercial - Compras -ALICANTE.
2011-07-12Otras Sin catalogar -MADRID.
2011-07-06Otras Sin catalogar -LUGO.
También puede ser bastante común crear un web service cuya lógica funcionalidad sea requerida por distintosaplicativos o componentes dentro de una plataforma (el típico servicio de utilidad). Este enfoque ya se va acercando aSOA, pero eso será en el siguiente punto. Además, podríamos tener un servicio de más alto nivel para ser consumidodesde diferentes frontales: ej. una aplicación web y una aplicación móvil.
Y un ejemplo clásico en el uso de servicios web es el de integrar diferentes sistemas o plataformas como puede ser elcaso de diferentes departamentos dentro de una organización o diferentes organizaciones.
Además de la interoperabilidad, otra gran ventaja que ofrecen estas alternativas es la flexibilidad a la hora de elegir latecnología con la que queremos implementar la lógica de negocio que queremos exponer. De esta forma, podemoscomunicar diferentes sistemas o componentes independientemente de la tecnología con la que están implementados.
Pero, ¿qué tiene que ver todo esto con SOA?. Lo vemos a continuación...
4. ¿Por qué SOA?.
SOA es un modelo de arquitectura tecnológica que surge de la aplicación del paradigma de orientación a servicios.Dicho paradigma no es una idea revolucionaria, sino que surge de la influencia de diferentes modelos como puedenser: la orientación a objetos, BPM, orientación a aspectos, web services...
La idea subyacente consiste en descomponer la lógica de negocio de una organización (o partes de ella) en pequeñasunidades de funcionalidad. Estas pequeñas unidades son los servicios. Con esto conseguimos romper con el conceptode aplicaciones "silo", donde se creaba una aplicación para resolver una necesidad de negocio concreta, otra pararesolver otra, etc... Lo que tendremos será una plataforma transversal formada por un inventario de servicios (ovarios) de forma que no solventaremos las necesidades cambiantes del negocio creando nuevas aplicaciones sinocombinando diferentes servicios (y creando nuevos servicios cuando corresponda). De esta forma conseguimos quelos departamentos de IT y negocio estén alineados de forma que el primero pueda responder de manera ágil a lasexigencias del segundo.
Dicho esto, alguien puede pensar: "Entonces para tener una SOA lo que tengo que hacer es crear web services a lobestia". Pues no, ójala fuese tan fácil :).
Es cierto que para poder tener una arquitectura SOA necesitamos tener una buena base de servicios. Pero no vale concrearlos de cualquier manera. Estas son algunas consideraciones que debemos tener en cuenta:
Debemos contar con una buena base de servicios reutilizables o muli-propósito. Servicios no diseñados pararesolver una necesidad de negocio específica. Los servicios de utilidad y entidad son perfectos en este sentido. Deesta forma podremos crear múltiples composiones basadas en ellos conforme las necesidades de negocio vancambiando.Nuestros servicios deben contar con un contrato estandarizado (ya sea WSDL, un documento o ambos) con unmodelo de datos normalizado dentro de todo nuestro inventario. De esta manera facilitamos la interacción entreservicios. Sustituimos el concepto de integración por interoperabilidad intrínseca.Debemos categorizar y registrar todos nuestros servicios (recursos de plataforma) de forma que, en cualquiermomento, podamos consultar con qué recursos contamos, qué funcionalidades encapsulan y cómo interacturarcon ellos.Debemos evitar el solapamiento de funcionalidades entre servicios como parte de la labor de gobierno SOA quedebemos ejercer sobre nuestra plataforma.Debemos evitar "casarnos" con una tecnología en concreto (Java, .Net, etc...) a la hora de crear nuestros
1/10/14 SOA vs. SOAP y REST
www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=SOAvsSOAPREST 3/4
Anímate y coméntanos lo que pienses sobre este TUTORIAL:
servicios. Los servicios deben poder implementarse con la tecnología que consideremos necesaria en cadamomento sin que esto afecte al resto de la plataforma.
Como vemos, no resulta tan fácil diseñar una arquitectura orientada a servicios. Sin embargo, los servicios web bastadostanto en SOAP como REST son excelentes opciones a la hora de crear los servicios que conformarán nuestraplataforma ya que, sin lugar a dudas, reunen las condiciones ideales para poder diseñar servicios que cumplan con losprincipios de diseño alineados con SOA.
5. La relación entre SOA y los servicios web basados en SOAP o REST.
Como comentamos anteriormente, SOA gira en torno a los servicios o recursos de plataforma. Dichos servicios debencumplir con una serie de principios de diseño como pueden ser: una alta capacidad de reutilización, abstracción, bajoacoplamiento, autonomía, capacidad de composición, contar con un contrato estandarizado (WSDL en caso de SOAP,convenciones en caso de REST y posiblidad de complementarlos con documentación en ambos casos)...
Tanto SOAP como REST pueden cumplir a la perfección con cualquiera de estos principios. Sin embargo, sonespecificaciones totalmente independientes a SOA. De la correcta aplicación del paradigma de orientación a servicios y,sobre todo, del cumplimiento de los principios de diseño de servicios surgirá el éxito o el fracaso de esta relación.
Lógicamente, no vale únicamente con tener servicios web para tener una SOA. Como vimos en el punto anterior,los servicios que exponen Jenkins y Sonar son servicios de muy alto nivel (servicios de tarea). Si todo nuestro inventariose basase en este tipo de servicios, no podríamos realizar composiciones complejas ni, por tanto, modelar de forma ágildiferentes procesos cuando el negocio así lo requiriese.
Un fallo conceptual muy común en algunos equipos de IT es el de asegurar que tienen una fabulosa arquitectura SOAcuando realmente lo que tienen son unos cuantos servicios de alto nivel orquestados por un bus. Pero eso no es SOA,en todo caso es integración.
6. Referencias.
SOA: Principles of Service Design
7. Conclusiones.
Construir una arquitectura SOA es un trabajo relativamente complejo, laborioso y siempre a medio/largo plazo. No todaslas plataformas u organizaciones son las mejores candidatas para ello. Es muy importante conocer bien el paradigma deorientación a servicios antes de barajar esta posibilidad. Debemos conocer antes sus ventajas, inconvenientes, objetivos,beneficios, cambios a nivel organizativo, etc...
Podemos diseñar excelentes arquitecturas basadas en REST de una manera bastante más sencilla. Incluso podemosbasarnos en aplicaciones silo, que tienen sus inconvenientes pero también sus ventajas, para la integración entre ellas(si fuese necesaria) ya tenemos muchas alternativas como los servicios web. No todo debe pasar por SOA. SOAsimplemente es un medio para obtener una serie de beneficios, nunca debe ser un fin en sí mismo. Todo depende deltamaño de la organización, presupuesto, lo cambiante del negocio y, sobre todo, del sentido común :-).
Espero que este tutorial os haya sido de ayuda. Un saludo.
Miguel Arlandy
Twitter: @m_arlandy
A continuación puedes evaluarlo:
Regístrate para evaluarlo
Por favor, vota +1 o compártelo si te pareció interesante
Share |
1/10/14 SOA vs. SOAP y REST
www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=SOAvsSOAPREST 4/4
Esta obra está licenciada bajo licencia Creative Commons de Reconocimiento-No comercial-Sin obras derivadas 2.5
PUSH THIS Page Pushers Community Help?
----no clicks + + + + + + + +
0 people brought clicks to this page
powered by karmacracy
» Registrate y accede a esta y otras ventajas «
Copyright 2003-2014 © All Rights Reserved | Texto legal y condiciones de uso | Banners | Powered by Autentia | Contacto