Esta es una buena pregunta: diría que hay algunos paralelos muy fuertes (y similitudes, pero también algunas diferencias clave).
- En ambos casos, está administrando el acceso, los derechos, las interacciones con los componentes del servicio y, a menudo, entre distintos grupos de personas.
- En ambos casos, se aplican patrones de mejores prácticas, reglas y orientación a los desarrolladores para tratar de mantener el sistema manejable y eficiente.
- En ambos casos, se aplica un paradigma arquitectónico de orientación al servicio.
Así que hay fuertes similitudes, pero también hay diferencias:
- En la gobernanza de SOA en la mayoría de los escenarios, los diversos grupos que usan el sistema se consideran “confiables” hasta cierto punto y “dentro” de la empresa (algunos sistemas se extienden a través de diferentes organizaciones, pero normalmente están muy estrictamente controlados). En API Management, la suposición inicial es que muchos de los grupos involucrados * no * serán de facto confiables y * no * serán parte de la organización. Esto significa que desde el día la seguridad, el aprovisionamiento, el monitoreo, etc. se convierte en una propuesta diferente.
- En segundo lugar, un efecto secundario es que, mientras que con SOA las identidades de los usuarios / servicios, etc., generalmente se gestionan a través de uno o más sistemas de identidad internos, con API Management se involucran nuevas identidades que son externas a la organización y se necesita un medio para ser encontrado para administrar esas entidades y las relaciones que lo acompañan. (Esto resultó ser una parte mucho más importante de nuestras herramientas en http://www.3scale.net de lo que se esperaba).
- En tercer lugar, los sistemas internos de SOA tienden a estar estrechamente acoplados e incluso acoplados previamente, con tecnologías como SOAP que proporcionan enlaces precisos y, a menudo, las implementaciones se concretan una por una para cada nuevo usuario de un servicio. Las API externas en particular tienden a rechazar este enfoque y se acoplan mucho más libremente, esperando muchas conexiones y usos diversos (gran parte de ellos potencialmente desconocidos en el momento del diseño de la API) que usan exactamente la misma interfaz. Esto devuelve la responsabilidad a API Management para garantizar que el control general, el uso y la supervisión del servicio sean sólidos, para hacer frente a la diversidad en el uso, así como a los cambios radicales en la carga de tráfico.
En última instancia, creemos que los dos están muy relacionados y es justo decir que “la administración de API es algo así como SOA en Internet público y para interactuar con personas que a priori no conoce”. En cuanto a qué conjunto de tecnología puede ser influyente, también espero que haya un poco de préstamo de ambos mundos.
- ¿Hay proyectos de código abierto en computación en la nube?
- Tengo grandes datos para almacenar. ¿Qué debería preferir: servicios en la nube o debería comprar mis propios servidores?
- ¿Existe una definición estandarizada para la nube híbrida?
- ¿Qué deben saber los desarrolladores sobre el nuevo servicio de procesamiento de datos administrado que Google lanzó en Google I / O?
- ¿Los consumidores confiarán más fácilmente en Greplin con sus datos privados que otras compañías más establecidas (como Google)?
Tenemos varios clientes que nos usan en un modo interno de tipo de gobierno API SOA, por lo que la transición definitivamente está sucediendo.
