significado serie practicos exams ejemplos definicion actuary soa

serie - ¿Qué es SOA "in plain english"?



soa serie (20)

¿Alguien puede explicar en inglés sencillo de qué se trata SOA ? Escucho SOA aquí, SOA allí, pero no puedo entender exactamente qué es y para qué se usa. ¿Fue un concepto simple y luego se convirtió en algo enorme o qué?

Todos los documentos, incluido el wiki, son un poco abstractos o tal vez soy un idiota y no lo entiendo. ¿Hay una guía de idiotas sobre esto?

¿Qué hay exactamente detrás de estas tres letras?

¡Depende de quién seas!

Si es propietario de una empresa, SOA es una solución para aumentar sus ingresos y agilidad empresarial. Si eres un arquitecto de empresas, SOA es una forma de dibujar un software agradable y limpio en un lienzo en blanco. Si eres arquitecto, SOA es la solución para diseñar servicios poco compactos sobre una plataforma de integración, simplemente para conectar servicios a puntos de venta. Si eres un desarrollador, SOA es un paradigma de programación en el que un servicio se encuentra en el centro del diseño y el código.

Deberías leer 100-SOA-Questions [pdf]

Aclamaciones

Al leer las respuestas anteriores, me parece que SOA es lo que los desarrolladores (al menos los buenos) han estado haciendo desde el primer día.

Bueno, ya ves ... SOA significa Arquitectura Orientada a Servicios ... En pocas palabras, escribes un código muy genérico, es decir, hace algo que se puede usar en muchas aplicaciones ... puede ser algo así como una libreta de direcciones o puede ser una calculadora. y usted lanza este código en el IIS. Entonces usted proporciona un servicio a través de su código. Entonces usted es un proveedor de servicios. Ahora alguien quiere usar un código similar y luego no tiene que escribir el código nuevamente. Simplemente usa tu código tal vez a través de un servicio web. Por lo tanto, se convierte en un consumidor de servicios. Por lo tanto, hacer un programa que use tales servicios se llama SOA. Y el acoplamiento flexible está allí ya que el proveedor del servicio y el consumidor pueden estar interactuando incluso si están utilizando lenguajes de programación diff. Espero que entiendas.

Escuche la edición de esta semana del podcast de Floss Weekly , que cubre SOA. Las descripciones son de muy alto nivel y no ahondan en demasiados detalles técnicos (aunque ejemplos más concretos y reconocibles de proyectos SOA habrían sido útiles.

La arquitectura orientada a servicios (SOA) es un estilo arquitectónico de software que crea aplicaciones como una colección de piezas conectables, cada una de las cuales puede ser reutilizada por otras aplicaciones.

Por lo que yo entiendo, el concepto básico es que creas pequeños "servicios" que proporcionan algo útil a otros sistemas y evitan la construcción de sistemas grandes que tienden a hacer todo dentro del sistema.

Entonces usted define un protocolo que usará para la interacción (digamos, puede ser servicios web SOAP) y le permite a su "sistema-que-funciona-algo-trabaja" interactuar con los servicios pequeños para lograr su "gran objetivo" .

Puede encontrar útil este artículo (¿Qué es SOA? - SOA y servicios web explicados) .

Un pequeño adelanto

  • SOA es un estilo de aplicaciones de arquitectura de tal manera que están compuestas por agentes discretos de software que tienen interfaces simples y bien definidas y que se organizan a través de un acoplamiento flexible para realizar una función requerida.

  • Hay dos roles en SOA: un proveedor de servicios y un consumidor de servicios. Un agente de software puede jugar ambos roles. SOA no es un concepto completamente nuevo, sin embargo, este artículo se centra principalmente en SOA tal como se implementa con los servicios web.

SOA es un estilo arquitectónico, pero también una visión de cómo la aplicación heterogénea debe ser desarrollada e integrada. El objetivo principal de SOA es alejarse de las aplicaciones monolíticas y tener en su lugar un conjunto de servicios reutilizables que se pueden componer para crear aplicaciones.

En mi humilde opinión, SOA tiene sentido solo a nivel de empresa, y no significa nada para una sola aplicación.

En muchas empresas, cada departamento tenía su propio conjunto de aplicaciones empresariales que implicaban

  1. Característica similar fue implementada varias veces

  2. Los datos (por ejemplo, datos de clientes o empleados) deben ser compartidos entre varias aplicaciones

  3. Las aplicaciones estaban centradas en el departamento.

Con SOA, la idea es que los servicios reutilizables estén disponibles en toda la empresa, de modo que la aplicación se pueda construir y componer a partir de ellos. La promesa de SOA es

  1. No es necesario volver a implementar funciones similares una y otra vez (por ejemplo, proporcionar un servicio al cliente o al empleado)

  2. Facilita la integración de aplicaciones en conjunto y el acceso a datos o características comunes

  3. Esfuerzo de desarrollo centrado en la empresa.

La visión SOA requiere un cambio tecnológico así como un cambio organizacional . Mientras que resuelve algunos problemas, también introduce otros, por ejemplo, la seguridad es mucho más difícil con SOA que con la aplicación monolítica. Por lo tanto, SOA está sujeto a discusión sobre si funciona o no.

Esta es la vista de 1000 pies de SOA. Sin embargo, no se detiene aquí. Existen otros conceptos que complementan a SOA como Business Process Orchestration (BPM), Enterprise Service Bus (ESB), procesamiento de eventos complejos (CEP), etc. Todos abordan el problema de alineación de TI / negocios , es decir, cómo tener la TI ser capaz de apoyar a la empresa de manera efectiva.

SOA es una nueva insignia para algunas ideas muy antiguas:

  • Divida su código en módulos reutilizables.

  • Encapsule en un módulo cualquier decisión de diseño que pueda cambiar.

  • Diseñe sus módulos de tal manera que se puedan combinar de diferentes maneras útiles (a veces denominadas "familia" o "línea de productos").

Todos estos son principios básicos de desarrollo de software, muchos de ellos primero articulados por David Parnas.

Lo nuevo en SOA es

  • Lo estás haciendo en una red.

  • Los módulos se están comunicando mediante el envío de mensajes entre sí a través de la red, en lugar de mediante mecanismos de lenguaje de programación más tradicionales, como las llamadas a procedimientos. En particular, en una arquitectura orientada a servicios, las partes generalmente no comparten el estado mutable (variables globales en un programa tradicional). O si comparten estado, ese estado está cuidadosamente encerrado en una base de datos que a su vez es un agente y que puede administrar fácilmente múltiples clientes concurrentes.

SOA es una palabra de moda que fue inventada por los proveedores de tecnología para ayudar a vender sus tecnologías relacionadas con Enterprise Service Bus. La idea es que haga que sus pequeñas aplicaciones isleñas en la empresa (por ejemplo: sistema contable, sistema de control de existencias, etc.) exponen todos los servicios, de modo que puedan organizarse de forma flexible en ''aplicaciones'' o, mejor dicho, convertirse en parte del negocio agregado de la empresa lógica.

Básicamente es una carga de viejas tonterías que casi nunca funciona, porque pasa por alto que las razones por las cuales la tecnología es como es en una organización se debe a la cultura, la evolución, la historia de la empresa, y el bloqueo es tan alto que cualquier intentar reestructurar la tecnología está destinado a fallar.

SOA o Service-Oriented Architecture es un patrón de arquitectura de software en el cual las aplicaciones o sistemas se construyen a partir de servicios de software subyacentes (y generalmente distribuidos) que se ajustan a un conjunto específico de características, a saber:

  1. Interfaz, política y contrato basado
  2. Transparencia de ubicación
  3. Autónomo
  4. Abstracto
  5. Reutilizable
  6. Composable
  7. Apátrida
  8. Detectable
  9. Extensible
  10. Débilmente acoplado

El objetivo principal de SOA es la agilidad en el desarrollo de sofware, es decir, la capacidad de responder a los cambios de manera fácil y económica, lo que permite a las empresas responder rápidamente a los mercados cambiantes.

Los servicios se implementan típicamente (pero de ninguna manera exclusivamente) como servicios web, es decir, operan sobre el omnipresente protocolo HTTP web, y se implementan utilizando SOAP basado en XML o el paradigma REST ligero (y más popular).

Supongamos que tienes cuatro cocineros. En SOA, usted supone que se odian entre sí, por lo que se esfuerza por dejar que tengan que hablar el uno al otro lo menos posible.

¿Cómo haces eso? Bueno, primero definirás los roles y la interfaz: cocinar 1 hará ensalada, cocinar 2 hará sopa, cocinar 3 hará la carne, etc. Luego colocarás los platos bien organizados sobre la mesa (entonces estos son los interfaces) y diga: "Todos, por favor, coloquen su creación en sus platos asignados. No se preocupen por nadie más".

De esta forma, los cuatro cocineros tienen que hablar lo menos posible, lo cual es muy bueno en el desarrollo de software, no necesariamente porque se odien entre sí, sino por otras razones como ubicación física, eficiencia en la toma de decisiones, etc.

También significa que puedes recombinar los platos (servicios) como quieras. Por ejemplo, puedes usar el postre para servir un café, o simplemente tomar la sopa y combinarla con un pan que compraste de otra compañía para ofrecer un menú más barato, o dejar que otros restaurantes usen tus ensaladas para combinarlas con sus platos, etc. .

Una de las implementaciones más exitosas de SOA fue en Amazon. Debido a su diseño, podrían volver a empaquetar toda su infraestructura y venderla como Amazon Web Service.

* Este es solo un aspecto de SOA.

También podría representar "Struct of Arrays" (en oposición a "Array of Structs"), que es un tema común en programación paralela (especialmente SIMD), pero supongo que eso no es lo que quieres decir aquí.

Una arquitectura de aplicación tradicional es:

  • Una interfaz de usuario
  • Elementos no definidos (implementación) que están encapsulados / ocultos detrás de la interfaz de usuario

Si desea acceder a los datos mediante programación, es posible que necesite recurrir a la eliminación de pantalla.

SOA me parece que es una arquitectura que se centra en exponer datos legibles por máquina y / o API, en lugar de exponer UI.

Veo muchas respuestas que explican una arquitectura orientada a servicios (SOA) utilizando palabras y términos técnicos aún más avanzados. Me gustaría dar una oportunidad de explicarlo para el profano, usando una analogía en inglés sencillo.

Pero primero una descripción de un SOA
SOA podría describirse en tres capas como se ve en la imagen siguiente. Por un lado, tenemos al Proveedor y, por el otro lado, tenemos al Consumidor , separado por un Puente, donde las dos partes se comunican.

El consumidor usa una cantidad de Aplicaciones necesarias para su negocio y el proveedor utiliza Componentes que brindan información a estas aplicaciones. Se comunican a través de un conjunto de Servicios que utilizan una arquitectura común.

La analogía
Imagine una casa en el campo, que de muchas maneras es parte de una comunidad más grande, como una ciudad o pueblo. La ciudad tiene sus propios sistemas complejos para proporcionar agua y electricidad, gestionar el saneamiento, proporcionar transporte y otras utilidades. La casa es el consumidor en este modelo, la ciudad (o comunidad) es el proveedor y las tuberías, alcantarillas, líneas eléctricas, fibras ópticas, etc. es la infraestructura en la que se comunican.

Este modelo podría compararse libremente con un SOA. La gente de la casa utiliza una serie de "aplicaciones" diferentes, como radiadores, computadoras, inodoros, lámparas, calefacción por suelo radiante, bañeras, etc. A estas aplicaciones no les importa cómo la ciudad genera el agua, genera electricidad o maneja los desechos durante tanto tiempo. como funciona Los componentes de la ciudad son generadores, bombas de agua y áreas de saneamiento. Brinda a la casa todas estas necesidades, pero depende de la casa usarla de la forma que considere conveniente.

Espero que esto le haya dado al menos a alguien una mejor imagen de una SOA.

de los blogs de ittoolbox.

A continuación, se describen las similitudes y diferencias con las técnicas de diseño anteriores:

• SOA versus programación estructurada o Semejanzas: lo más similar a las llamadas a subrutinas donde se pasan los parámetros y la operación de la función se abstrae de la persona que llama, por ejemplo, enlace CICS y ejecución y la palabra reservada COBOL CALL. Los cuadernos se usan para definir una estructura de datos que típicamente se define como un esquema XML para servicios. o Diferencias: SOA está débilmente acoplada, lo que implica que los cambios en un servicio tienen menos impacto para el consumidor (el programa "de llamada") y los servicios son interoperables en todos los idiomas y plataformas.

• SOA versus OOA / OOD o Similitudes: encapsulación, abstracción e interfaces definidas o Diferencias: SOA está vagamente emparejado con ninguna jerarquía de clases o herencia, abstracciones de bajo nivel: nivel de clase versus servicio comercial

• SOA versus Desarrollo basado en componentes heredado (CBD) - ej. CORBA, DCOM, EJB o Semejanzas: reutilización a través del ensamblaje de componentes, interfaces, llamadas remotas o Diferencias: adopción amplia de estándares, esquemas XML vs. objetos Marshaled, orquestación de servicios, diseño para reutilización es más fácil, los servicios se enfocan en el negocio versus los enfocados en TI, los servicios comerciales son del todo definidos (de amplio alcance)

• SOA (para integración) versus Enterprise Application Integration (EAI) o Similitudes: Mejores prácticas (interfaces bien definidas, esquemas estandarizados, arquitectura impulsada por eventos), interfaces reutilizables, esquemas comunes o Diferencias: estándares, adopción y herramientas mejoradas

lo que tiende a suceder en las grandes organizaciones es que con el tiempo todo es monolítico o sistemas dispares en todas partes o un poco de ambos. Alguien finalmente llega y dice que tenemos un desastre. Ahora, desea rediseñar (dinero para alguien) todo lo que se orienta en una especie de monolítica depende de a quién le pague el paradigma, pero al mismo tiempo, puede agregar piezas y partes independientemente del maestro / monolito.

Entonces compra Oracle SOA y Oracle se convierte en el jefe de todas sus partes. Todos los demás jugadores que entran tienen que trabajar con SOA a través de un servicio (servicio web o lo que sea). El monolito de Oracle se encarga de todo (el monolito no es despectivo). Oh sí, tienes ASP.NET MVC en el frente o algo más.

Lo principal es mover cosas dentro y fuera del sistema sin impacto y mantener al proveedor Oracle SOA, Microsoft WCF, como el cerebro de todo. todo es muy fluido, fluido, cosas que entran y salen con poco o ningún impacto, incluso servicios humanos, no solo computadoras.

Para mí, solo significa un grupo de servicios web (o como los llamemos en el futuro) con una buena interfaz. Y si posee la base de datos, solo acceda a la base de datos y deje de preocuparse por las palabras de moda. está bien.

SOA es el acrónimo de Service Oriented Architecture.

SOA está diseñando y escribiendo aplicaciones de software de tal manera que distintos módulos de software se pueden integrar sin problemas con un alto grado de reutilización.

La mayoría de las personas restringe SOA como escribir servicios cliente / servidor-web-services. Pero es un contexto demasiado pequeño de SOA. SOA es mucho más grande que eso y en los últimos años los servicios web han sido el medio principal de comunicación, que es probablemente la razón por la cual las personas piensan que SOA es un servicio web en general que restringe los límites y el significado de SOA.

Puede pensar en escribir un módulo de acceso a la base de datos que sea tan independiente que pueda funcionar por sí mismo sin dependencias. Este módulo puede exponer clases que pueden ser utilizadas por cualquier software host que necesite acceso a la base de datos. No hay configuración de inicio en la aplicación de host. Lo que sea necesario o requerido se comunica a través de las clases expone por el módulo de acceso a la base de datos. Podemos llamar a estas clases como servicios y considerar el módulo como habilitado para servicios.

Practicar SOA ofrece un alto grado de reutilización al aplicar DRY [No repetir tu auto], lo que da como resultado un software altamente sostenible. La capacidad de mantenimiento es lo primero que piensa cualquier arquitectura de software: SOA le ofrece eso.