ES2970491T3 - Tecnologías de creación y distribución de conectores de integración en un sistema de intermediación de servicios en la nube - Google Patents
Tecnologías de creación y distribución de conectores de integración en un sistema de intermediación de servicios en la nube Download PDFInfo
- Publication number
- ES2970491T3 ES2970491T3 ES18785215T ES18785215T ES2970491T3 ES 2970491 T3 ES2970491 T3 ES 2970491T3 ES 18785215 T ES18785215 T ES 18785215T ES 18785215 T ES18785215 T ES 18785215T ES 2970491 T3 ES2970491 T3 ES 2970491T3
- Authority
- ES
- Spain
- Prior art keywords
- connector
- computing device
- developer
- api
- portal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0641—Electronic shopping [e-shopping] utilising user interfaces specially adapted for shopping
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5015—Service provider selection
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Mathematical Physics (AREA)
- Stored Programmes (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Las tecnologías para crear y distribuir conectores de integración en sistemas de intermediación de servicios en la nube incluyen un dispositivo informático de portal de desarrollador acoplado comunicativamente a un centro de conectores de un mercado informático. El dispositivo informático del portal de desarrollador está configurado para recibir información de un desarrollador a través de un portal de interfaz de usuario de desarrollador de un dispositivo informático del portal de desarrollador. Dicha información incluye información de descriptor de conector para un conector asociado con un servicio en la nube y uno o más tipos de recursos del conector. El dispositivo informático del portal de desarrollador está configurado además para construir, a través de un generador de conectores del dispositivo informático del portal de desarrollador, el conector como una función de la información del descriptor del conector y uno o más tipos de recursos, generar un paquete de conector para el conector construido, y transmitir el paquete de conector generado a un concentrador de conector de un dispositivo informático de mercado de servicios en la nube, en el que el paquete de conector se puede utilizar para crear una o más instancias del conector. En el presente documento se describen realizaciones adicionales. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Tecnologías de creación y distribución de conectores de integración en un sistema de intermediación de servicios en la nube
Referencia cruzada a la solicitud relacionada
La presente solicitud reivindica prioridad a la Solicitud Provisional de los Estados Unidos número 62/485,665, presentada el 14 de abril de 2017.
Campo técnico de las realizaciones divulgadas
Las realizaciones actualmente divulgadas se refieren en general a la intermediación de servicios en la nube, y más particularmente,con tecnologías para crear y distribuir conectores de integración en sistemas de intermediación de servicios en la nube.
Antecedentes de las realizaciones divulgadas
Los proveedores (ISVs)de software independientes desarrollan y venden aplicaciones de software las cuales están típicamente diseñadas para funcionar en una o más plataformas de hardware o de sistema operativo. Tales aplicaciones de software están en un intervalo desde la utilidad básica o la aplicación para mejorar la productividad hasta la aplicación de procedimientos de negocio para empresas (por ejemplo, gestión de la relación con el cliente (CRM), planificación de recursos empresariales (ERP), herramientas de automatización, etc.). A medida que la informática en la nube se ha vuelto más generalizada, uno de tales procedimientos de entrega de software ha sido a través de la nube mediante el uso de un software como modelo basado en servicios (SaaS). Mediante el uso de este procedimiento de entrega, los ISVs pueden vender sus aplicaciones de software, o suscripciones a sus aplicaciones de software, a través de una nube pública o un mercado en la nube.
A la vez que el mercado en la nube proporciona una tienda en línea para el acceso del cliente a los servicios y aplicaciones de software basados en la nube, se puede utilizar un intermediario de servicios en la nube para facilitar la transacción entre el ISV y un usuario final, revendedor, minorista, etc., tal como mediante el uso de un plug-in o conector de API para cada servicio en la nube. En las implementaciones tradicionales de intermediarios de servicios en la nube, cada intermediario de servicios en la nube tiene típicamente un contrato con cada ISV para cada servicio en la nube el cual proporciona al intermediario de servicios en la nube acceso a la plataforma y/o infraestructura, a la cual se puede acceder (por ejemplo, a través de un portal) para crear y gestionar conectores API, permitiendo así que sus servicios se compren, aprovisionen, y ejecuten en la nube.
Típicamente, tales conectores API se lanzan desde el lado del intermediario de servicios en la nube, ya sea en las instalaciones (es decir, del lado del proveedor) o en la nube (por ejemplo, bajo la cuenta del intermediario de servicios en la nube). Como tal, cada instancia de plataforma de intermediario de servicios en la nube tiene su propio conector de API para cada servicio que la plataforma de intermediario de servicios en la nube está adaptada para proporcionar. Sin embargo, tales implementaciones manuales requieren en general una multitud de procedimientos API y pocos puntos de integración de interfaz de usuario, lo cual puede dar lugar a tiempos de liberación más largos para que los ISVs integren sus servicios en la respectiva plataforma de intermediario de servicios en la nube. Por tanto, es necesario crear y distribuir conectores de integración en los sistemas de intermediación de servicios en nube.
El documento US 2007/239858 A1 describe un marco de software para proporcionar un software de integración Negocio a Negocio (B2B) como servicio (SaaS). El marco sigue un modelo de concentrador y radio en el que el concentrador y el radio se comunican a través de servicios web. A la vez que el concentrador y los radios actúan como pasarelas de integración con los sistemas de empresa, el concentrador también actúa como un centro remoto centralizado de mando, control y configuración para toda la instalación. El software de concentrador permite generar y desplegar remotamente los entornos de radio y gestionarlos de manera remota. El entorno de radio generado puede descargarse, instalarse y configurarse para conectarse a los sistemas locales y actuar como mediador para la integración B2B entre el concentrador y los sistemas locales. Una vez instalados, los entornos se gestionan de manera remota a través de la consola de gestión proporcionada por el software de concentrador.
Sumario de las realizaciones divulgadas
En un aspecto, se divulga un procedimiento para crear y distribuir conectores de integración de servicios en la nube en un sistema de intermediación de servicios en la nube. El procedimiento incluye recibir, a partir de un desarrollador a través de un portal de UI de desarrollador de un dispositivo informático de portal de desarrollador, información de descriptor de conector para un conector asociado con un servicio en la nube; recibir, a partir del desarrollador a través del portal de UI de desarrollador, uno o más tipos de recursos del conector; construir, a través de un constructor de conector del dispositivo informático de portal de desarrollador, el conector como una función de la información de descriptor de conector y el uno o más tipos de recursos; generar, mediante el constructor de conector, un paquete de conector para el conector construido; y transmitir, mediante el constructor de conector, el paquete de conector generado a un concentrador de conector de un dispositivo informático de mercado de servicios en la nube, en el que el paquete de conector se puede utilizar para crear una o más instancias del conector.
En algunas realizaciones, el procedimiento incluye además analizar, mediante un sistema experto del dispositivo informático de portal de desarrollador, si se ha publicado una versión anterior del conector asociado con el servicio en la nube; determinar, mediante el sistema experto y después de determinar que se ha publicado la versión anterior del conector, un nivel de coincidencia entre el conector y la versión anterior del conector; comparar, mediante el sistema experto, el nivel de coincidencia contra un umbral de nivel de coincidencia; y relacionar, mediante el sistema experto, el conector con la versión anterior del conector como una nueva versión de la versión anterior del conector.
En algunas realizaciones, el procedimiento incluye adicionalmente analizar, a través del sistema experto del dispositivo informático de portal de desarrollador, si otro servicio debería estar relacionado con el conector; identificar, mediante el sistema experto, si uno o más de los otros servicios podrían estar relacionados con el conector; y relacionar, mediante el sistema experto y después de haber identificado que el uno o más de los otros servicios podrían estar relacionados con el conector, el uno o más de los otros servicios.
En algunas realizaciones, el procedimiento incluye además recibir, a partir del desarrollador a través del portal de UI de desarrollador, un identificador asociado con un esqueleto de conector a partir de una base de datos de esqueleto de conector del dispositivo informático de portal de desarrollador, en el que el esqueleto de conector se puede utilizar para generar un marco para crear el conector, y en el que recibir el uno o más tipos de recursos del conector comprende recibir el uno o más tipos de recursos del conector en base al esqueleto de conector.
En algunas realizaciones, recibir la información de descriptor de conector incluye recibir un título del servicio, un tipo del servicio, un icono asociado con el servicio, y una o más instrucciones de proveedor de servicio. De manera adicional o alternativamente, en algunas realizaciones, el procedimiento incluye además determinar, mediante el constructor de conector, una o más diferencias entre el conector y la versión anterior del conector; y generar, mediante el constructor del conector, una o más instrucciones de actualización en función de la una o más diferencias determinadas, en el que generar el paquete de conector comprende generar el paquete de conector en función de la una o más instrucciones de actualización.
Breve descripción de los dibujos
Las realizaciones y otras características, ventajas y divulgaciones contenidas en la presente memoria, así como la forma de obtenerlas, se harán evidentes y la presente divulgación se entenderá mejor por referencia a la siguiente descripción de diversas realizaciones ejemplares de la presente divulgación tomadas en conjunto con los dibujos adjuntos, en los que:
La Figura 1 es un diagrama de bloques de una realización ilustrativa de un sistema de mercadoe intermediación de servicios en la nube para crear y distribuir conectores de integración en sistemas de intermediación de servicios en la nube, que incluye un dispositivo informático de intermediario, un dispositivo informático de proveedor de servicios, y un dispositivo informático de portal de desarrollador, cada uno de los cuales está acoplado de manera comunicativa a un dispositivo informático de mercado;
La Figura 2 es un diagrama de bloques de una realización ilustrativa de uno de los dispositivos informáticos del mercado de intermediario de servicios en la nube del dispositivo informático de mercado de la Figura 1;
La Figura 3 es un diagrama de bloques de un entorno ilustrativo del dispositivo informático de i portal de desarrollador de la Figura 1;
Las Figuras 4A - 4D son un diagrama de flujo esquemático de un procedimiento ilustrativo para crear y distribuir conectores en sistemas de intermediación de servicios en la nube que se pueden realizar mediante el dispositivo informático de portal de desarrollador de la Figura 1;
La Figura 5 es un diagrama de flujo esquemático de un procedimiento ilustrativo para realizar un análisis de versión en los objetos conectores que se puede realizar mediante el dispositivo informático de portal de desarrollador de la Figura 1; y
La Figura 6 es un diagrama de flujo esquemático de otro procedimiento ilustrativo para realizar un análisis de emparejamiento en objetos conectores que se puede realizar mediante el dispositivo informático de portal de desarrollador de la Figura 1.
Descripción detallada de las realizaciones divulgadas
Con el propósito de promover la comprensión de los principios de la presente divulgación, se hará referencia ahora a las realizaciones ilustradas en los dibujos, y se utilizará un lenguaje específico para describirlas. Sin embargo, se entenderá que no se pretende limitar el ámbito de la presente divulgación.
La Figura 1 ilustra un sistema 100 de mercado e intermediación de servicios en la nubepara crear y distribuir conectores de integración. El sistema 100 de mercado e intermediación de servicios en la nube incluye un dispositivo 116 informático de portal de desarrollador, un dispositivo 122 informático de proveedor de servicios, y un dispositivo 130 informático de intermediario, cada uno de los cuales está acoplado de manera comunicativa a un dispositivo 102 informático de mercado (por ejemplo, a través de una red 128). En uso, un desarrollador/programador de aplicaciones de servicios en la nube asociado con un proveedor de servicios en la nube desarrolla una interfaz de programación de aplicaciones (API) (véase, por ejemplo, la API 126 de la Figura 1) y un conector de API para uno o más de los servicios en la nube.
Para desarrollar el conector de API, el desarrollador utiliza un portal de desarrollador (por ejemplo, el portal 118 de interfaz de usuario (UI) de desarrollador 118 del dispositivo 116 informático de portal de desarrollador) para un servicio particular que se ofrece a la venta en un mercado de servicios en la nube (por ejemplo, a través del mercado 104 de intermediario de servicios en la nube del dispositivo 102 informático de mercado). Se debe apreciar que el desarrollador puede acceder al portal 118 de UI de desarrollador a través de un dispositivo informático de punto final (no se muestra) acoplado de manera comunicativa (por ejemplo, a través de la red 128) al dispositivo 116 informático de portal de desarrollador.
El conector de API puede tener la forma de código fuente utilizable para crear una instancia replicada de ese conector de API (véase, por ejemplo, una instancia 114 de conector de API de la fábrica 112 de conector de la Figura 1), la cual se puede utilizar para comunicarse con su respectiva API 126. En consecuencia, cada API 126 está configurada para recibir comandos a partir del servicio en la nube (por ejemplo, a través de la interfaz 124 de proveedor de servicios en la nube del dispositivo 122 informático de proveedor de servicios) y transmitir los comandos recibidos a la correspondiente instancia 114 de conector de API a la cual está conectada la API 126, y viceversa.
El portal de desarrollador está configurado para recibir información del desarrollador que se puede utilizar para definir los componentes principales del paquete de conector, tal como un modelo (por ejemplo, una explicación del modelo de negocio para objetos de aplicación), una(s) interfaz o interfaces de usuario que soporte las interacciones del usuario, y un back end (por ejemplo, un servicio de transferencia de estado representacional (REST) para el aprovisionamiento de procedimientos, la gestión, la monitorización de solicitudes, etc.) para el conector. Se debe apreciar que el portal de desarrollador puede estar configurado para recibir información adicional asociada con el conector, tal como la dirección del servicio en la nube, la configuración predeterminada, la información de precios, las plantillas de ventas, un identificador del servicio en la nube, etc.
El portal de desarrollador está configurado adicionalmente para, como se describirá con más detalle más adelante, producir un paquete de conector, probar el paquete de conector producido, y publicar el paquete de conector probado en un catálogo de conectores (por ejemplo, la base 110 de datos de servicios disponiblesdel concentrador 106 de conector del dispositivo 102 informático de mercado). Posterior a la fase de desarrollo, el paquete de conector puede proceder entonces a la fase de producción, en la cual el conector puede desplegarse en un intermediario de servicios en la nube (por ejemplo, a través del mercado 104 de intermediario de servicios en la nube a través de la interfaz 132 de intermediario de servicios en la nube del dispositivo 130 informático de intermediario).
El dispositivo 102 informático de mercado está configurado para gestionar licencias para diversos servicios en la nube entre proveedores de servicios en la nube e intermediarios de servicios en la nube. En un ejemplo ilustrativo, un proveedor de servicios en la nube (por ejemplo, un proveedor de software independiente (ISV)) contrata con una entidad controladora del mercado 102 de servicios en la nube para facilitar la venta de una licencia a un usuario final. La licencia puede entonces permitir a ese usuario final, o a otro(s) usuario(s) final(es) asociado(s) a él, determinado acceso a los servicios en la nube del proveedor de servicios en la nube (por ejemplo, aplicación(es) de software como servicio (SaaS) basadas en la nube).
Para ello, el dispositivo 102 informático de mercado ilustrativo incluye un concentrador 106 de conector que está configurado para almacenar conectores empaquetados generados a través del portal 118 de UI de desarrollador (por ejemplo, en la base 110 de datos de servicios disponibles) y para establecer canales de aprovisionamiento para conectores 114 de una fábrica 112 de conector entre una interfaz 124 de proveedor de servicios en la nube del dispositivo 122 informático de proveedor de servicios y una interfaz 132 de intermediario de servicios en la nube del dispositivo 130 informático de intermediario. En consecuencia, un intermediario de servicios en la nube puede entonces vender licencias de servicios en la nube asociados con los conectores empaquetados a usuarios finales (por ejemplo, un cliente, un intermediario, un revendedor, etc.) a través de su respectiva interfaz 132 de intermediario de servicios en la nube.
El concentrador 106 de conector está configurado adicionalmente para generar credenciales de canal de aprovisionamiento para cada conector 114 (por ejemplo, credenciales de intermediario y/o credenciales de proveedor de servicios en la nube, tales como las que pueden almacenarse en la base 108 de datos de credenciales). Se debe apreciar que las credenciales de canal de aprovisionamiento pueden ser cualquier tipo de información (por ejemplo, claves criptográficas u otros datos arbitrarios) que sea utilizable para autenticar un canal de comunicación seguro entre dos entidades que utilicen las credenciales de canal de aprovisionamiento.
Como se muestra en el sistema 100 ilustrativo de mercado e intermediación de servicios en la nube, cada uno del dispositivo 102 informático de mercado, el dispositivo 116 informático de portal de desarrollador, el dispositivo 122 informático de proveedor de servicios, y el dispositivo 130 informático de intermediario están incorporados comodispositivos 134 informáticos. En consecuencia, se debe apreciar que cada uno de los respectivos dispositivos 134 informáticos se puede incorporar como cualquier tipo de dispositivo informático y/o almacenamiento capaz de realizar las funciones descritas en la presente memoria. Adicionalmente, se debe apreciar que cada uno de los respectivos dispositivos 134 informáticos puede estar comprendido por más de un dispositivo 134 informático. Se debe apreciar que uno o más de los dispositivos 134 informáticos pueden estar incorporados como uno o más servidores (por ejemplo, independientes, montados en bastidor, etc.) y/o una combinación de cuchillas de informática y dispositivos de almacenamiento de datos (por ejemplo, de una red de área de almacenamiento (SAN)) en una red con arquitectura de nube o centro de datos, a la vez que uno o más de los dispositivos informáticos pueden estar incorporados como uno o más ordenador de mesa, dispositivos informáticos móviles (por ejemplo, teléfono inteligente, dispositivos portables, tabletas, portátiles, ordenadores portátiles, etc.), o cualquier otro tipo de dispositivos “inteligente” o de otro modo conectado a Internet.
Con referencia ahora a la Figura 2, se muestra una realización ilustrativa de un dispositivo 134 informático representativo de uno o más del dispositivo 102 informáticos de mercado, el dispositivo 116 informático de portal de desarrollador, el dispositivo 122 informático de proveedor de servicios, y el dispositivo 130 informático de intermediario. El dispositivo 134 informático ilustrativo incluye una unidad 200 central de procesamiento (CPU), un controlador 202 de entrada/salida (E/S), una memoria 204, un circuito 206 de comunicación de red, y un dispositivo 210 de almacenamiento de datos, así como, en algunas realizaciones, uno o más periféricos 208 de E/S. En algunas realizaciones, uno o más de los componentes ilustrativos pueden combinarse en un único sistema en un chip (SoC) en un único circuito integrado (IC). Se debe apreciar que las realizaciones alternativas pueden incluir componentes adicionales, menores, y/o alternativos a los del dispositivo 134 informático ilustrativo, tal como una unidad de procesamiento gráfico (GPU), una fuente de alimentación, etc., los cuales no se muestran para preservar la claridad de la descripción. Además, se debe apreciar que el tipo de componentes de almacenamiento/informático del respectivo dispositivo 134 informático puede basarse en el tipo y el uso previsto del respectivo dispositivo 134 informático.
La CPU 200, o procesador, puede ser incorporado como cualquier tipo de hardware o combinación de circuitos capaces de procesar datos. En consecuencia, la CPU 200 puede incluir un núcleo de procesamiento (no se muestra) en una arquitectura de procesador de un solo núcleo, o múltiples núcleos de procesamiento en una arquitectura de procesador de múltiples núcleos. Independientemente del número de núcleos de procesamiento, la CPU 200 es capaz de leer y ejecutar instrucciones de programa. En algunas realizaciones, la CPU 200 puede incluir una memoria caché (no se muestra) que puede estar integrada de manera directa con la CPU 200 o colocada en un chip separado con una interconexión separada a la CPU 200. Se debe apreciar que, en algunas realizaciones, la lógica de canalización se puede usar para realizar operaciones de software y/o hardware (por ejemplo, operaciones de procesamiento de tráfico de red), en lugar de comandos emitidos a/a partir de la CPU 200.
El controlador 202 de E/S, o la interfaz de E/S, puede ser incorporado como cualquier tipo de hardware informático o combinación de circuitos capaces de interconectar entre los dispositivos de entrada/salida y el dispositivo 134 informático. De manera ilustrativa, el controlador 202 de E/S está configurado para recibir solicitudes de entrada/salida a partir de la CPU 200, y enviar señales de control a los respectivos dispositivos de entrada/salida, por lo que gestiona el flujo de datos a/a partir del dispositivo134informático.
La memoria 204 puede ser incorporada como cualquier tipo de hardware informático o combinación de circuitos capaces de contener datos e instrucciones para su procesamiento. Tal memoria 204 se puede denominar memoria principal o primaria. Se debe apreciar que, en algunas realizaciones, uno o más componentes del dispositivo 134 informático pueden tener acceso directo a la memoria, de tal manera que determinados datos se puedan almacenar a través de un acceso directo a la memoria (DMA) independientemente de la CPU 200.
El circuito 206 de comunicación de red puede ser incorporado como cualquier tipo de hardware informático o combinación de circuitos capaces de gestionar comunicaciones de interfaz de red (por ejemplo, mensajes, datagramas, paquetes, etc.) a través de modos de comunicación inalámbricos y/o cableados. En consecuencia, en algunas realizaciones, el circuito 206 de comunicación de red puede incluir un controlador de interfaz de red (NIC) capaz de ser configurado para conectar el dispositivo 134 informático a una red informática (por ejemplo, la red 128), así como otros dispositivos informáticos del sistema 100 de mercado e intermediación de servicios en la nube.
El uno o másperiféricos 208 de E/S pueden ser incorporados como cualquier dispositivo auxiliar configurado para conectarse a y comunicarse con el dispositivo 134 informático. Por ejemplo, losperiféricos 208 de E/S pueden incluir, pero no limitarse a, un ratón, un teclado, un monitor, una pantalla táctil, una impresora, un escáner, un micrófono, un altavoz, etc. En consecuencia, se debe apreciar que algunos dispositivos de E/S son capaces de una función (es decir, de entrada, o de salida), o de ambas funciones (es decir, de entrada y de salida).
En algunas realizaciones, losperiféricos 208 de E/S pueden estar conectados al dispositivo 134 informático a través de un cable (por ejemplo, un cable de cinta, un cable, un cable de bus serie universal (USB), un cable de interfaz multimedia de alta definición (HDMI), etc.) del dispositivo 134 informático. En tales realizaciones, el cable se conecta a un puerto correspondiente (no se muestra) del dispositivo 134 informático para el cual las comunicaciones realizadas entre ellos pueden ser gestionadas por el controlador 202 de E/S. En realizaciones alternativas, losperiféricos 208 de E/S pueden estar conectados al dispositivo 134 informático a través de un modo de comunicación inalámbrico (por ejemplo, Bluetooth®, Wi-Fi®, etc.) el cual puede ser gestionado por el circuito 206 de comunicación de red.
El dispositivo 210 de almacenamiento de datos puede ser incorporado como cualquier tipo de hardware informático capaz de almacenar datos de manera no volátil (por ejemplo, medios de almacenamiento semiconductores, medios de almacenamiento magnéticos, medios de almacenamiento ópticos, etc.). Tales dispositivos 210 de almacenamiento de datos se denominan comúnmente almacenamiento auxiliar o secundario, y se usan típicamente para almacenar una gran cantidad de datos relacionados con la memoria 204 descrita anteriormente.
De nuevo con referencia a la Figura 1, el sistema 100 ilustrativo de mercado de servicios en la nube incluye una red 128 que se puede utilizar por los otros dispositivos 134 informáticos (es decir, el dispositivo 116 informático de portal de desarrollador, el dispositivo 122 informático de proveedor de servicios, y el dispositivo130informático de intermediario) para comunicarse con el dispositivo 102 informático de mercado. La red 128 se puede implementar como cualquier tipo de red cableada y/o inalámbrica, que incluye una red de área local (LAN), una red de área amplia (WAN), una red de área metropolitana (MAN), una red global (Internet), etc., mediante el uso de cualquier tecnología de comunicación cableada y/o inalámbrica y protocolos de transmisión de comunicación de red. En consecuencia, la red 128 puede incluir uno o más dispositivos informáticos de red acoplados de manera comunicativa (no se muestran) para facilitar el flujo y/o procesamiento del tráfico de comunicación de red a través de una serie de interconexiones cableadas y/o inalámbricas. Tales dispositivos informáticos de red pueden incluir, pero no limitarse a, uno o más puntos de acceso, enrutadores, conmutadores, servidores, dispositivos informáticos, dispositivos de almacenamiento, etc.
Por ejemplo, uno o más de tales dispositivos informáticos de red pueden estar configurados para acoplar uno o más del dispositivo 102 informático de mercadeo, el dispositivo 116 informático de portal de desarrollador, el dispositivo 122 informático de proveedor de servicio, y/o el dispositivo 130 informático de intermediario a la red 128 en una configuración LAN utilizando tecnologías de comunicación por cable (por ejemplo, Ethernet, token ring, etc.) y/o una configuración WLAN utilizando tecnologías de comunicación inalámbricas (por ejemplo, Bluetooth®, Wi-Fi®, banda ancha inalámbrica, ZigBee®, etc.) y protocolos asociados. En cumplimiento del ejemplo, una configuración LAN puede estar acoplada (por ejemplo, a través de coaxial, telefonía móvil, fibra, etc.) a una o más redes de área mayor (por ejemplo, WANs, redes de área metropolitana (MANs), Internet, etc.) a través de dispositivos informáticos de red adicionales de la red 128. Se debe apreciar que uno o más de los dispositivos informáticos de red y/o configuraciones de red pueden ser virtualizados (por ejemplo, un conmutador virtual, una LAN virtual, etc.).
Como se ha descrito anteriormente, el dispositivo 116 informático de portal de desarrollador incluye un portal de UI de desarrollador, el dispositivo 122 informático de proveedor de servicios incluye una interfaz 124 de proveedor de servicios en la nube, y el dispositivo 130 ilustrativo informáticode intermediario incluye una interfaz 132 de intermediario de servicios en la nube. Cada uno del portal 118 de UI de desarrollador, la interfaz 124 de proveedor de servicios en la nube, y la interfaz 132 de intermediario de servicios en la nube puede incorporarse como cualquier combinación de software, hardware, firmware, y circuitos capaces de realizar las funciones descritas en la presente memoria. En algunas realizaciones, uno o más del portal 118 de UI de desarrollador, la interfaz 124 de proveedor de servicios en la nube, y la interfaz 132 de intermediario de servicios en la nube pueden configurarse para presentar información (por ejemplo, a través de una UI gráfica, una interfaz de línea de comandos, etc.) a una pantalla de su respectivo dispositivo 134 informático. En tales realizaciones, el portal 118 UI de desarrollador, la interfaz 124 de proveedor de servicios en la nube, y/o la interfaz 132 de intermediario de servicios en la nube pueden configurarse para transmitir entradas recibidas a partir de un usuario para iniciar sesión, configurar la interfaz respectiva, o manipular información (por ejemplo, ajustes) asociados con el mismo.
Con referencia ahora a la Figura 3, se muestra un entorno 300 ilustrativo del dispositivo 116 informático de portal de desarrollador. El entorno 300 ilustrativo incluye un constructor 304 de conector, un reproductor 314 de conector, un sistema 316 de prueba, y un sistema 318 experto, así como el portal 118 de UI de desarrollador de la Figura 1. En algunas realizaciones, uno o más del portal 118 de UI de desarrollador 118, el constructor 304 de conector, el reproductor 314 de conector, el sistema 316 de prueba, y el sistema 318 experto pueden incluir uno o más medios legibles por ordenador (por ejemplo, la memoria 204, el dispositivo 210 de almacenamiento de datos, y/o cualquier otro dispositivo de almacenamiento de medios) que tiene instrucciones almacenadas en el mismo y uno o más procesadores (por ejemplo, la CPU 200) acoplados con el uno o más medios legibles por ordenador y configurados para ejecutar instrucciones para realizar las funciones descritas en la presente memoria. Además, el entorno 300 ilustrativo incluye una base 302 de datos de modelos y un gestor 306 de biblioteca, cada uno de los cuales se describirá con más detalle más adelante.
Como se describió anteriormente, el portal 118 de UI de desarrollador puede incorporarse como cualquier tipo de firmware, hardware, software, circuito, o combinación de los mismos capaz de realizar las funciones descritas en la presente memoria. Además, cada uno del constructor 304 de conector, el reproductor 314 de conector, el sistema 316 de prueba, y el sistema 318 experto también pueden ser incorporados como cualquier tipo de firmware, hardware, software, circuito, o combinación de los mismos capaces de realizar las respectivas funciones descritas en la presente memoria.
Como también se ha descrito anteriormente, el portal 118 de UI de desarrollador está configurado para proporcionar una interfaz a un desarrollador para generar un conector de API empaquetado para un servicio en la nube. Para ello, el portal 118 de UI de desarrollador está configurado para comunicarse con un desarrollador (por ejemplo, a través de solicitudes/respuestas de protocolo de transferencia de hipertexto [HTTP]) e interactuar con los diversos componentes y medios de almacenamiento del entorno 300.
Por ejemplo, el portal 118 de UI de desarrollador está configurado para comunicarse con el desarrollador para recibir información (es decir, información de descripción de conector) utilizable para empaquetar un conector de API desarrollado por el desarrollador. Como se ha descrito anteriormente, el conector de API se puede utilizar para generar instancias del conector las cuales permiten la interfaz entre el intermediario de servicios en la nube y el proveedor de servicios en la nube. Como tal, la información de descripción de conector puede incluir cualquier información relacionada con el conector de API que pueda utilizarse para crear una instancia del conector de API. Por ejemplo, la información de descripción de conector puede incluir, pero no se limita a, información de UI (por ejemplo, un título del servicio, uno o más iconos, etc.), información de modelo de recursos (por ejemplo, servicio(s) proporcionado(s), tales como espacio en disco, buzones de correo, dominios, etc.), credenciales para establecer el canal de aprovisionamiento, información del plan de servicio (por ejemplo, reglas de facturación para el intermediario/proveedor), información de recursos. La información de descripción de conector puede almacenarse en la base 302 de datos de modelos.
Se debe apreciar que el desarrollador puede modificar cualquier porción de la información de descripción de conector (por ejemplo, tal y como puede almacenarse en la base 302 de datos de modelos) a través del portal 118 de UI de desarrollador. Para ello, el portal 118 de UI de desarrollador está configurado para proporcionar una o más interfaces visuales utilizables por el desarrollador para generar un modelo para el conector y/o publicar el conector (por ejemplo, a través del constructor 304 de conector), ejecutar una o más pruebas en un sistema de prueba contra el conector desarrollado (por ejemplo, a través del reproductor 314 de conector y el sistema 316 de prueba), y verificar el conector contra una o más reglas de compatibilidad (por ejemplo, a través del sistema 318 experto) para garantizar la compatibilidad retrospectiva para actualizaciones/cambios realizados en un conector.
La base 302 de datos de modelos está configurada para almacenar un modelo para cada conector. El modelo puede incluir cualquier información utilizable para definir o de otro modo empaquetar el conector, tal como etiquetas de UI (por ejemplo, nombre, descripción, etc.), materiales visuales (por ejemplo, iconos, capturas de pantalla, estilos, etc.), extensiones de UI (por ejemplo, descripciones de cómo conectar elementos de UI en aplicaciones existentes), definiciones de objetos de negocio soportados por el conector (por ejemplo, usuario, buzón, regla de filtrado de correo basura, etc.). Se debe apreciar que, en algunas realizaciones, al menos una porción de las extensiones de UI puede definirse como páginas HTML, e incluir JavaScript, CSS, imágenes, etc. relevantes, así como una descripción para conectar los elementos de UI en la estructura de UI para cada página aplicable. Adicionalmente, la información de modelo puede incluir, para cada objeto soportado por el conector, una o más propiedades (por ejemplo, tipo, descripción, etiqueta, valor por defecto, etc.), una o más relaciones (es decir, cómo el objeto(s) está(n) conectado(s) con otro(s) objeto(s) del modelo de dominio de servicio y la cardinalidad de la(s) relación(es)), y/o mapeo de uso/límite (por ejemplo, cómo el uso/límites están mapeados a recursos y planes vendibles). Se debe apreciar que, en algunas realizaciones, la base de datos de modelos puede mantener múltiples versiones del mismo conector y/o múltiples conectores. En consecuencia, se debe apreciar aún más que, en tales realizaciones en las cuales se mantienen múltiples versiones, la diferencia entre las versiones (es decir, los cambios) puede determinarse automáticamente (por ejemplo, a través de una comparación de determinada información de modelo).
El constructor 304 de conector está configurado para generar un archivo de esquema para todos los objetos de negocio asociados con un conector. Para ello, el constructor 304 de conector está configurado para analizar metadatos (por ejemplo, información de descripción de conector) del conector para identificar los objetos de negocio y generar el archivo de esquema. Adicionalmente, el constructor 304 de conector está configurado para generar un conjunto de instrucciones de actualización en tales realizaciones en las cuales el conector no es la primera versión del conector (es decir, el conector que se está empaquetando es una actualización o de otro modo incluye cambios en un conector previamente empaquetado para el mismo servicio). Las instrucciones de actualización pueden incluir cualquier cambio de modelo que pueda rastrearse y aplicarse a una versión actualizada del conector, tal como cambios en los metadatos del conector, adición de nuevas propiedades en el ámbito del tipo o asignación de un valor predeterminado, eliminación de propiedades, cambio de nombres/tipos de propiedades, adición de servicios (por ejemplo, un nuevo objeto en el modelo de dominio de aplicación), adición de nuevas relaciones a/entre objetos de otro conector o del modelo de dominio de aplicación, renombrarlas relaciones, cambiar la cardinalidad u opciones de las relaciones, cambiar el tipo requerido por la relación, cambiar las reglas de acceso a propiedades, cambiar las reglas de acceso y/o asignación de relaciones, dividir las relaciones en más de una relación de acuerdo con las reglas, etc.
El constructor 304 de conector está configurado además para ensamblar el esquema generado anteriormente y las instrucciones de actualización, si se aplica, junto con el código fuente del conector, y las plantillas frontales en un paquete de conector. Además, el constructor 304 de conector está configurado para cargar el paquete de conector ensamblado en la base 110 de datos de servicios disponibles del dispositivo 102 informático de mercado que incluye un catálogo de conectores (es decir, servicios disponibles).
El gestor 306 de biblioteca está configurado para gestionar el flujo de datos entre las bases de datos ilustrativas, las cuales incluyen ilustrativamente una base 308 de datos de reglas de compatibilidad, una base 310 de datos de esqueleto de conector, y una base 312 de datos de plantillas frontales. Para ello, el gestor 306 de biblioteca está configurado para realizar operaciones de lectura y escritura en cada una de las bases de datos, así como cualquier otra operación que pueda ser necesario realizar en los datos (por ejemplo, estandarizar los datos, normalizar los datos, mejorar los datos, etc.).
La base 308 de datos de reglas de compatibilidad está configurada para almacenar reglas para la gestión de versiones (es decir, reglas de compatibilidad). En otras palabras, las reglas de compatibilidad garantizan la compatibilidad retrospectiva entre versiones. Por ejemplo, las reglas de compatibilidad no permiten realizar cambios al tipo de recursos que se venden, ya que se rompería la compatibilidad retrospectiva; sin embargo, las reglas de compatibilidad permiten ampliar la configuración de ese tipo de recursos o vender tipos de recursos adicionales. Como tal, las reglas de compatibilidad proporcionan la capacidad de permitir que se realicen actualizaciones automáticas, ya que la actualización propuesta puede ser probada contra las reglas de compatibilidad (por ejemplo, por el constructor 304 de conector). Se debe tener en cuenta que pueden existir varios conjuntos de tales reglas. Por ejemplo, una actualización menor puede mantener una compatibilidad retrospectiva total, a la vez que una actualización mayor puede mantener una compatibilidad retrospectiva limitada.
La base 310 de datos de esqueleto de conector está configurada para almacenar código preparado de acuerdo con el modelo y las mejores prácticas para el desarrollo de conector. Como tal, el código almacenado puede utilizarse como marco de partida para el desarrollo del back end de un conector. Se debe apreciar que el código puede personalizarse dependiendo del modelo definido por el desarrollador.
La base 312 de datos de plantillas frontales está configurada para almacenar interfaces de usuario para escenarios conocidos (por ejemplo, creación de un nuevo cliente/cuenta, compra de una suscripción para un cliente, desactivación de una suscripción, finalización de una suscripción, etc.). En consecuencia, cuando un desarrollador habilita un escenario conocido, el código de UI relevante para ese escenario se puede adicionar a un componente de UI del conector a partir de la base 312 de datos de plantillas frontales.
Se debe apreciar además que, en algunas realizaciones, los datos almacenados en las respectivas bases de datos como se describe en la presente memoria pueden no ser mutuamente excluyentes. En otras palabras, determinados datos descritos en la presente memoria como almacenados en una base de datos se pueden almacenar de manera adicional o alternativamente en otra base de datos descrita en la presente memoria, o en otra base de datos. Se debe apreciar aún más que, en algunas realizaciones, los datos se pueden almacenar en una única base de datos, o en una base de datos distribuida, o disposición de base de datos alternativa.
El reproductor 314 de conector está configurado para ejecutar escenarios de prueba del conector contra un sistema de prueba (por ejemplo, el sistema 316 de prueba). Tales escenarios pueden incluir el despliegue del conector, la creación de instancias de conector, la configuración de plantillas y planes de servicio, la prueba de la creación de suscripciones/usuarios, la solicitud de uso de recursos de contador, etc. En consecuencia, el sistema 316 de prueba está configurado para proporcionar recursos utilizables para probar diversos escenarios de un conector. Se debe apreciar que los recursos pueden ser físicos y/o virtuales.
El sistema 318 experto está configurado para analizar los posibles servicios de emparejamiento y sugerir uno o más servicios identificados como candidatos para ser emparejados con el servicio asociado con el conector. Para ello, el sistema 318 experto está configurado para identificar información asociada con el conector (por ejemplo, un tipo de servicio, una descripción, etc.) y comparar la información identificada con la información correspondiente de otros servicios que están típicamente emparejados. En un ejemplo ilustrativo, el sistema 318 experto puede sugerir emparejar un servicio contra correos basura en base a los resultados del análisis realizado en un conector para un servicio de correo electrónico. Se debe apreciar que cualquier relación puede cambiar el modelo de conector asociado.
Como se ha descrito anteriormente, el dispositivo 116 informático de portal de desarrollador puede estar comprendido por más de un dispositivo 134 informático. En consecuencia, a la vez que el portal 118 de UI de desarrollador, la base 302 de datos de modelos, el gestor 306 de biblioteca, el constructor 304 de conector, el reproductor 314 de conector, el sistema 316 de prueba, y el sistema 318 experto se muestran ilustrativamente como residentes en un único dispositivo 134 informático (es decir, el dispositivo 116 informático de portal de desarrollador), se debe apreciar que, en algunas realizaciones, uno o más componentes pueden estar ubicados en diferentes dispositivos 134 informáticos, comprendiendo juntos el dispositivo 116 informático de portal de desarrollador.
Con referencia ahora a las Figuras 4A-4D, se proporciona un procedimiento 400 ilustrativo para crear y distribuir conectores de integración en sistemas de intermediación de servicios en la nube que puede ser realizado por el dispositivo 116 informático de portal de desarrollador, o más particularmente por uno o más de los componentes del dispositivo 116 informático de portal de desarrollador (por ejemplo, el portal 118 de UI de desarrollador, el constructor 304 de conector, etc.). El procedimiento 400 comienza en el bloque 402, en el cual el dispositivo 116 informático de portal de desarrollador determina si crear un objeto conector. Si es así, el procedimiento 400 avanza al bloque 404 en el cual el dispositivo 116 informático de portal de desarrollador selecciona un esqueleto de conector relevante (por ejemplo, a partir de la base 310 de datos de esqueleto de conector de la Figura 3). Como se ha descrito anteriormente, el esqueleto de conector puede estar en forma de código utilizable como marco de partida para el desarrollo del back end de un conector.
En el bloque 406, el dispositivo 116 informático de portal de desarrollador genera un identificador único de modelo de conector. En el bloque 408, el dispositivo 116 informático de portal de desarrollador solicita (por ejemplo, a través del portal 118 de UI de desarrollador) información de descripción de conector para un modelo de conector a partir de un desarrollador de conector. En un ejemplo ilustrativo, en el bloque 410, el dispositivo 116 informático de portal de desarrollador solicita información de UI (por ejemplo, un título de servicio, un tipo de servicio, un icono, etc.) y una o más instrucciones de proveedor. Como se ha descrito anteriormente, la información de descripción de conector puede incluir cualquier información relacionada con el conector de API que pueda utilizarse para instanciar una instancia del conector de API, tal como información de modelo de recursos (por ejemplo, servicio(s) proporcionado(s), como espacio en disco, buzones de correo, dominios, etc.), credenciales para establecer el canal de aprovisionamiento, información del plan de servicio (por ejemplo, reglas de facturación para el intermediario/proveedor), información de recursos.
En el bloque 412, el dispositivo 116 informático de portal de desarrollador determina si se ha recibido la información solicitada (por ejemplo, a través del portal 118 de UI de desarrollador). Si es así, el procedimiento 400 avanza al bloque 414, en el cual el dispositivo 116 informático de portal de desarrollador almacena la información recibida (por ejemplo, en la base 302 de datos de modelos de la Figura 3). En el bloque 416, el dispositivo 116 informático de portal de desarrollador notifica a un sistema experto (por ejemplo, el sistema 318 experto de la Figura 3) realizar un análisis de la versión (véase, por ejemplo, el procedimiento 500 de la Figura 5). En otras palabras, el dispositivo 116 informático de portal de desarrollador notifica al sistema experto que analice los conectores existentes (por ejemplo, en la base 110 de datos de servicios disponiblesdel concentrador 106 de conector de la Figura 1) para posibles conectores los cuales sean versiones anteriores del objeto conector. En el bloque 418, el dispositivo 116 informático de portal de desarrollador determina si se ha completado el análisis de la versión, como puede determinarse al recibir una indicación a partir del sistema experto encargado de realizar el análisis de la versión.
Si el dispositivo 116 informático de portal de desarrollador determina que se ha completado el análisis de la versión, el procedimiento 400 avanza al bloque 420, que se muestra en la Figura 4B. En el bloque 420, el dispositivo 116 informático de portal de desarrollador solicita recibir tipos de recursos del objeto conector del desarrollador del conector (por ejemplo, a través del portal 118 de UI de desarrollador) en base al esqueleto de conector asociado seleccionado por el desarrollador de conector en el bloque 404.En el bloque 422, el dispositivo 116 informático de portal de desarrollador determina si se han recibido los tipos de recursos solicitados. Si es así, el procedimiento 400 avanza al bloque 424, en el cual el dispositivo 116 informático de portal de desarrollador almacena los tipos de recursos recibidos en la base de datos de modelos (por ejemplo, en la base 302 de datos de modelos de la Figura 3).
En el bloque 426, el dispositivo 116 informático de portal de desarrollador notifica al sistema experto (por ejemplo, el sistema 318 experto) que realice un análisis de relación (véase, por ejemplo, el procedimiento 600 de la Figura 6). En otras palabras, el dispositivo 116 informático de portal de desarrollador notifica al sistema experto que analice el objeto conector que se está creando para posibles servicios relacionados con el servicio del objeto conector. En el bloque 428, el dispositivo 116 informático de portal de desarrollador determina si se ha completado el análisis de la relación. Si es así, el procedimiento 400 pasa al bloque 430, en el cual el dispositivo 116 informático de portal de desarrollador determina, en base a la información recibida a partir del sistema 318 experto en el bloque 418, si el objeto conector tiene una o más versión(es) correspondiente(s) del objeto conector que se ha(n) publicado anteriormente. Si es así, el procedimiento 400 pasa al bloque 450, el cual se muestra en la Figura 4D y se describe más adelante; de otro modo, el procedimiento 400 pasa al bloque 432, el cual se muestra en la Figura 4C.
En el bloque 432, el dispositivo 116 informático de portal de desarrollador construye un conector en función del modelo de servicio. Para ello, en el bloque 434, el dispositivo 116 informático de portal de desarrollador recupera el identificador de modelo de conector asociado generado en el bloque 406. Adicionalmente, en el bloque 436, el dispositivo 116 informático de portal de desarrollador recupera los recursos de modelo asociados. Además, en el bloque 438, el dispositivo 116 informático de portal de desarrollador recupera una plantilla front end (por ejemplo, interfaces de usuario para escenarios conocidos). Más aún, en el bloque 440, el dispositivo 116 informático de portal de desarrollador diseña un manifiesto en base a los recursos de modelo asociado recuperados y la plantilla de front end.
En el bloque 442, el dispositivo 116 informático de portal de desarrollador determina si el conector se ha construido con éxito. En caso negativo, el procedimiento 400 regresa al bloque 408 para solicitar información de descripción de conector adicional y/o alternativa; de otro modo, el procedimiento 400 avanza al bloque 444. En el bloque 444, el dispositivo 116 informático de portal de desarrollador genera un paquete de conector en base al modelo. En el bloque 446, el dispositivo 116 informático de portal de desarrollador almacena el paquete de conector (por ejemplo, en la base 110 de datos de servicios disponiblesdel concentrador 106 de conector de la Figura 1). En el bloque 448, el dispositivo 116 informático de portal de desarrollador transmite una indicación al desarrollador del conector indicando que el paquete de conector fue almacenado.
Como se describió anteriormente, en el bloque 430 (se muestra en la Figura 4B), si el dispositivo 116 informático de portal de desarrollador determina que el objeto conector tiene alguna versión publicada previamente, el procedimiento 400 pasa al bloque 450, el cual se muestra en la Figura 4D. En el bloque 450, el dispositivo 116 informático de portal de desarrollador construye un conector en función del modelo de servicio. Para ello, en el bloque 452, el dispositivo 116 informático de portal de desarrollador recupera el identificador de modelo de conector asociado generado en el bloque 406. Adicionalmente, en el bloque 454, el dispositivo 116 informático de portal de desarrollador recupera los recursos de modelo asociados. Además, en el bloque 456, el dispositivo 116 informático de portal de desarrollador comprueba los recursos contra cualquier regla de compatibilidad aplicable para garantizar la compatibilidad retrospectiva de las actualizaciones/cambios realizados en un conector. Como se describió anteriormente, las reglas de compatibilidad proporcionan la capacidad de permitir que se realicen actualizaciones automáticas, ya que la actualización propuesta puede probarse contra las reglas de compatibilidad (por ejemplo, como puede almacenarse en la base 308 de datos de reglas de compatibilidad). Aún más, en el bloque 458, el dispositivo 116 informático de portal de desarrollador recupera una plantilla de front end (por ejemplo, interfaces de usuario para escenarios conocidos). Todavía aún más, en el bloque 460, el dispositivo 116 informático de portal de desarrollador diseña un manifiesto en base a los recursos de modelo asociados recuperados y la plantilla de front end.
En el bloque 462, el dispositivo 116 informático de portal de desarrollador determina si el conector se construyó con éxito (por ejemplo, si los recursos violan alguna regla de compatibilidad). De lo contrario, el procedimiento 400 regresa al bloque 408 para solicitar información de descripción de conector adicional y/o alternativa; de otro modo, el procedimiento 400 avanza al bloque 464. En el bloque 464, el dispositivo 116 informático de portal de desarrollador determina cualquier diferencia entre los modelos de la versión anterior del conector y la versión actual del conector. En el bloque 466, el dispositivo 116 informático de portal de desarrollador genera una o más instrucciones de actualización en base a las diferencias determinadas en el bloque 464. Como se ha descrito anteriormente, las instrucciones de actualización pueden incluir cualquier cambio de modelo que se pueda rastrear y aplicar a una versión actualizada del conector
En el bloque 468, el dispositivo 116 informático de portal de desarrollador genera un paquete de conector en base al modelo y las instrucciones de actualización. En el bloque 470, el dispositivo 116 informático de portal de desarrollador almacena el paquete de conector (por ejemplo, en la base 110 de datos de servicios disponibles del concentrador 106 de conector de la Figura 1). En el bloque 472, el dispositivo 116 informático de portal de desarrollador transmite una indicación al desarrollador del conector indicando que el paquete de conector fue almacenado.
Con referencia ahora a la Figura 5, se proporciona un procedimiento 500 ilustrativo para realizar un análisis de versión en objetos conectores que puede ser realizado por el dispositivo 116 informático de portal de desarrollador, o más particularmente por el sistema 318 experto del dispositivo 116 informático de portal de desarrollador. El procedimiento 500 comienza en el bloque 502, en el cual el sistema 318 experto determina si se ha recibido una notificación de análisis de versión (por ejemplo, a partir de un desarrollador a través del portal 118 de UI de desarrollador de las Figuras 1 y 3.
En el bloque 504, el sistema 318 experto compara la información de descripción de conector del objeto conector actual que se está creando contra la información correspondiente del paquete(s)de conector(es) almacenado(s) actualmente en la base 110 de datos de servicios disponiblesdel concentrador 106 de conector de la Figura 1, como puede determinarse a partir del modelo asociado (por ejemplo, la información de modelo de recursos almacenada en la base 302 de datos de modelos de la Figura 3). Como se ha descrito anteriormente, la información de descripción de conector puede incluir cualquier información relacionada con el conector de API que pueda utilizarse para instanciar una instancia del conector de API. En un ejemplo ilustrativo, en el bloque 506, el sistema 318 experto compara un tipo de servicio, un nombre de servicio, y un icono de servicio de cada objeto conector.
En el bloque 508, el sistema 318 experto determina un nivel de coincidencia entre los objetos conectores en función de un resultado de la comparación realizada en el bloque 504. En el bloque 510, el sistema 318 experto determina si el nivel de coincidencia determinado en el bloque 508 es mayor que o igual a un umbral de nivel de coincidencia. El nivel de coincidencia puede ser cualquier valor numérico (por ejemplo, cantidad, número, valor de contador, porcentaje, etc.) utilizable para transmitir un nivel de coincidencia entre la información (por ejemplo, el tipo de servicio, el nombre del servicio, el icono del servicio, etc.) de cada objeto conector. En consecuencia, el umbral de nivel de coincidencia puede definirse como cualquier cantidad correspondiente utilizable para comparar contra el nivel de coincidencia para determinar si el nivel de coincidencia es lo suficientemente alto tal como para que pueda determinarse razonablemente que los objetos conectores están asociados (es decir, uno es una versión anterior del otro).
Si el sistema 318 experto determina que el nivel de coincidencia es mayor que o igual al umbral de nivel de coincidencia, el procedimiento 500 se pasa al bloque 512 antes de avanzar al bloque 514. En el bloque 512, el sistema 318 experto relaciona el objeto conector actual con el conector publicado anteriormente como una nueva versión de ese objeto conector. Si el sistema 318 experto determina que el nivel de coincidencia es menor que el umbral de nivel de coincidencia, el procedimiento 500 se pasa al bloque 514, en el cual el sistema 318 experto transmite una indicación al constructor de conector (por ejemplo, el constructor 304 de conector de la Figura 3) que indica que el sistema experto ha completado el análisis de la versión. En el bloque 516, el sistema 318 experto transmite un identificador de la versión anterior del objeto conector, según sea aplicable (es decir, si la relación se produjo en el bloque 512).
Con referencia ahora a la Figura 6, se proporciona un procedimiento 600 ilustrativo para realizar un análisis de emparejamiento en objetos conectores que puede ser realizado por el dispositivo 116 informático de portal de desarrollador, o más particularmente por el sistema 318 experto del dispositivo 116 informático de portal de desarrollador. El procedimiento 600 comienza en el bloque 602, en el cual el sistema 318 experto determina si se ha recibido una notificación de análisis de relación (por ejemplo, a partir de un desarrollador a través del portal 118 de UI de desarrollador de las Figuras 1 y 3. En el bloque 604, el sistema 318 experto identifica cualquier otro servicio
P03394-EP-00 (036768.01091) que podría estar relacionado con el objeto conector actual. Para ello, en el bloque 606, el sistema 318 experto puede identificar los otros servicios en base a la información de sus paquetes de conector almacenada en la base 110 de datos de servicios disponibles del concentrador 106 de conector, tal como sus respectivos tipos de recursos de conector.
En el bloque 608, el sistema 318 experto solicita al desarrollador del conector que acepte la(s) relación(es) identificada(s) con cualquier servicio existente y/o identificado que se vaya a vincular al conector. En el bloque 610, el sistema 318 experto determina si la(s) relación(es) ha(n) sido aceptada(s). Se debe apreciar que, en algunas realizaciones, pueden aceptarse algunas, todas, o ninguna de la(s) relación(es) identificada(s). Se debe apreciar que, en algunas realizaciones, es posible que no se solicite al desarrollador que acepte las relaciones. En otras palabras, en tales realizaciones, las relaciones pueden identificarse y asociarse automáticamente, de tal manera que el procedimiento 600 avanza directamente del bloque 604 al bloque 612. Si alguna de las relaciones identificadas fue aceptada en el bloque 610, el procedimiento 600 avanza al bloque 612 antes de proceder al bloque 614. En el bloque 612, el sistema 318 experto transmite una indicación a cada uno de los propietarios de conectores asociados con el servicio(s)aceptado(s) para confirmar la relación. De otro modo, si alguna de las relaciones identificadas no fue aceptada en el bloque 610, el procedimiento 600 avanza al bloque 614, en el cual el sistema 318 experto transmite una indicación al constructor de conector (por ejemplo, el constructor 304 de conector de la Figura 3) que indica que el sistema experto ha completado el análisis de la relación.
Aunque la presente divulgación se ha ilustrado y descrito en detalle en los dibujos y en la descripción anterior, la misma se debe considerar como ilustrativa y no de carácter restrictivo, entendiéndose que sólo se han mostrado y descrito determinadas realizaciones, y que se desea proteger todas los cambios y modificaciones que entran dentro del ámbito de la presente divulgación.
Claims (6)
1. Un procedimiento para crear y distribuir conectores de Interfaz de Programación de Aplicaciones, API, en un sistema (100) de intermediación de servicios en la nube, comprendiendo el procedimiento:
recibir, a partir de un desarrollador a través de un portal (118) de UI de desarrollador de un dispositivo (116) informático de portal de desarrollador, información de descriptor de conector para un conector de API asociado con un servicio en la nube;
recibir, a partir del desarrollador a través del portal (118) de UI de desarrollador, uno o más tipos de recursos de un modelo del conector de API;
construir, a través de un constructor (304)de conector del dispositivo (116) informático de portal de desarrollador, el conector de API en función de la información de descriptor de conector y deluno o más tipos de recursos, en el que el dispositivo (116) informático de portal de desarrollador recupera un identificador de modelo de conector asociado y recupera los recursos de modelo asociados, en el que el dispositivo (116) informático de portal de desarrollador recupera una plantilla front end;
generar, mediante el constructor (304) de conector, un paquete de conector para el constructor de conector; y
transmitir, mediante el constructor (304) de conector, el paquete de conector generado a un concentrador (106) de conectorde un dispositivo informático de mercado de servicios en la nube, en el que el paquete de conector se puede utilizar para crear una o más instancias del conector de API.
2. El procedimiento de la reivindicación 1, que además comprende:
analizar, mediante un sistema experto del dispositivo (116) informático de portal de desarrollador, si se ha publicado una versión anterior del conector de API asociado con el servicio en la nube;
determinar, mediante el sistema experto y con posterioridad a la determinación de que se ha publicado la versión anterior del conector de API, un nivel de coincidencia entre el conector de API y la versión anterior del conector de API;
comparar, mediante el sistema experto, el nivel de coincidencia contra un umbral de nivel de coincidencia; y relacionar, mediante el sistema experto, el conector de API con la versión anterior del conector de API como una nueva versión de la versión anterior del conector de API.
3. El procedimiento de la reivindicación 1, que además comprende:
analizar, a través del sistema experto del dispositivo (116) informático de portal de desarrollador, si otro servicio debe estar relacionado con el conector de API;
identificar, mediante el sistema experto, si uno o más servicios podrían estar relacionados con el conector de API; y
relacionar, mediante el sistema experto y después de haber identificado que el uno o más servicios podrían estar relacionados con el conector de API, el uno o más de otros servicios.
4. El procedimiento de la reivindicación 1, que comprende además recibir, a partir del desarrollador a través del portal (118) de UI de desarrollador, un identificador asociado con un esqueleto de conector a partir de una base (310) de datos de esqueleto de conectordel dispositivo (116) informático de portal de desarrollador, en el que el esqueleto de conector es utilizable para generar un marco para crear el conector de API, y en el que recibir el uno o más tipos de recursos del conector de API comprende recibir el uno o más tipos de recursos del conector de API en base al esqueleto de conector.
5. El procedimiento de la reivindicación 1, en el que recibir la información de descriptor de conector de API incluye recibir un título del servicio, un tipo de servicio, un icono asociado con el servicio, y una o más instrucciones del proveedor de servicios.
6. El procedimiento de la reivindicación 1, que además comprende:
determinar, mediante el constructor (304) de conector, una o más diferencias entre el conector de API y la versión anterior del conector de API; y
generar, mediante el constructor (304) de conector, una o más instrucciones de actualización en función de la una o más diferencias determinadas,
en el que la generación del paquete de conector comprende la generación del paquete de conector en función de la una o más instrucciones de actualización.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201762485665P | 2017-04-14 | 2017-04-14 | |
| PCT/US2018/027596 WO2018191680A1 (en) | 2017-04-14 | 2018-04-13 | Technologies for creating and distributing integration connectors in a cloud service brokerage system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2970491T3 true ES2970491T3 (es) | 2024-05-29 |
Family
ID=63790654
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18785215T Active ES2970491T3 (es) | 2017-04-14 | 2018-04-13 | Tecnologías de creación y distribución de conectores de integración en un sistema de intermediación de servicios en la nube |
Country Status (19)
| Country | Link |
|---|---|
| US (2) | US20180300115A1 (es) |
| EP (1) | EP3610369B1 (es) |
| JP (1) | JP7073394B2 (es) |
| CN (1) | CN110506257B (es) |
| AU (1) | AU2018252007B2 (es) |
| CA (1) | CA3059798A1 (es) |
| DK (1) | DK3610369T3 (es) |
| ES (1) | ES2970491T3 (es) |
| FI (1) | FI3610369T3 (es) |
| HR (1) | HRP20240139T1 (es) |
| HU (1) | HUE065659T2 (es) |
| LT (1) | LT3610369T (es) |
| MX (1) | MX2019012212A (es) |
| PL (1) | PL3610369T3 (es) |
| PT (1) | PT3610369T (es) |
| RS (1) | RS65115B1 (es) |
| SI (1) | SI3610369T1 (es) |
| SM (1) | SMT202400040T1 (es) |
| WO (1) | WO2018191680A1 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113841371B (zh) * | 2020-02-25 | 2024-01-09 | 华为云计算技术有限公司 | 用于将后端即服务与在线服务集成的方法、系统和计算机可读介质 |
| US20220244936A1 (en) * | 2021-01-29 | 2022-08-04 | Salesforce.Com, Inc. | Dynamically evolving and updating connector modules in an integration platform |
| CN113626007B (zh) * | 2021-10-13 | 2021-12-31 | 树根互联股份有限公司 | 连接器模型的应用方法、装置及服务器 |
| CN116821172A (zh) * | 2023-06-28 | 2023-09-29 | 北京柏睿数据技术股份有限公司 | 一种基于异构数据源数据查询系统 |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7062506B2 (en) * | 2003-01-24 | 2006-06-13 | The Cobalt Group, Inc. | Staged publication and management of dynamic webpages |
| US7735077B2 (en) * | 2004-05-05 | 2010-06-08 | Bea Systems, Inc. | System and method for inventory services |
| JP2006092167A (ja) | 2004-09-22 | 2006-04-06 | Ricoh Co Ltd | サービス提供装置、意味関係サービス提供装置、サービス提供プログラム、意味関係サービス提供プログラム、記録媒体、サービス提供方法及び意味関係サービス提供方法 |
| US8046441B2 (en) * | 2006-02-13 | 2011-10-25 | Infosys Limited | Business to business integration software as a service |
| JP4367424B2 (ja) * | 2006-02-21 | 2009-11-18 | 沖電気工業株式会社 | 個人識別装置，個人識別方法 |
| US20070300237A1 (en) * | 2006-06-22 | 2007-12-27 | Tim Neil | Facilitating access to application data at an application server by a wireless communication device |
| US8782637B2 (en) * | 2007-11-03 | 2014-07-15 | ATM Shafiqul Khalid | Mini-cloud system for enabling user subscription to cloud service in residential environment |
| US8843997B1 (en) * | 2009-01-02 | 2014-09-23 | Resilient Network Systems, Inc. | Resilient trust network services |
| US8699499B2 (en) * | 2010-12-08 | 2014-04-15 | At&T Intellectual Property I, L.P. | Methods and apparatus to provision cloud computing network elements |
| US20140006482A1 (en) * | 2012-07-02 | 2014-01-02 | Vmware, Inc. | Method and system for providing inter-cloud services |
| US20130282565A1 (en) * | 2012-04-18 | 2013-10-24 | Mastercard International Incorporated | Systems and methods for managing transactions for a merchant |
| US9348652B2 (en) * | 2012-07-02 | 2016-05-24 | Vmware, Inc. | Multi-tenant-cloud-aggregation and application-support system |
| US9979797B2 (en) * | 2012-07-27 | 2018-05-22 | Nokia Technologies Oy | Methods and apparatuses for facilitating utilization of cloud services |
| EP2893685B1 (en) * | 2012-09-07 | 2017-07-26 | Oracle International Corporation | Infrastructure for providing cloud services |
| JP6181185B2 (ja) * | 2012-09-07 | 2017-08-16 | オラクル・インターナショナル・コーポレイション | Ｌｄａｐベースのマルチカスタマ・インクラウド・アイデンティティ管理システム |
| US9824390B2 (en) * | 2013-03-15 | 2017-11-21 | International Business Machines Corporation | Cloud service brokerage service store |
| US20140365350A1 (en) * | 2013-06-10 | 2014-12-11 | Rawllin International Inc. | Financial platform that facilitates management of financial services |
| EP2824891A1 (en) * | 2013-07-12 | 2015-01-14 | Twinlife SAS | Distributed programmable connection method to establish peer-to-peer multimedia interactions |
| US20150067171A1 (en) * | 2013-08-30 | 2015-03-05 | Verizon Patent And Licensing Inc. | Cloud service brokering systems and methods |
| US10129078B2 (en) * | 2014-10-30 | 2018-11-13 | Equinix, Inc. | Orchestration engine for real-time configuration and management of interconnections within a cloud-based services exchange |
| US20160198016A1 (en) * | 2015-01-05 | 2016-07-07 | Onavo Mobile Ltd. | Techniques for network resource caching using partial updates |
| US9974415B2 (en) * | 2015-01-19 | 2018-05-22 | Kohler Co. | Shower door assemblies and methods for installing same |
| US20160260157A1 (en) * | 2015-03-05 | 2016-09-08 | International Business Machines Corporation | Rapid service orchestration and management |
| US11714685B2 (en) | 2015-07-31 | 2023-08-01 | The Conundrum Ip Llc | Discovering and publishing API information |
| EP3329449B1 (en) | 2015-07-31 | 2025-05-28 | Ent. Services Development Corporation LP | Federated marketplace portal |
-
2018
- 2018-04-13 JP JP2019553085A patent/JP7073394B2/ja active Active
- 2018-04-13 US US15/953,104 patent/US20180300115A1/en not_active Abandoned
- 2018-04-13 CA CA3059798A patent/CA3059798A1/en active Pending
- 2018-04-13 SM SM20240040T patent/SMT202400040T1/it unknown
- 2018-04-13 CN CN201880024966.5A patent/CN110506257B/zh active Active
- 2018-04-13 HR HRP20240139TT patent/HRP20240139T1/hr unknown
- 2018-04-13 PL PL18785215.7T patent/PL3610369T3/pl unknown
- 2018-04-13 EP EP18785215.7A patent/EP3610369B1/en active Active
- 2018-04-13 ES ES18785215T patent/ES2970491T3/es active Active
- 2018-04-13 FI FIEP18785215.7T patent/FI3610369T3/fi active
- 2018-04-13 PT PT187852157T patent/PT3610369T/pt unknown
- 2018-04-13 RS RS20240109A patent/RS65115B1/sr unknown
- 2018-04-13 SI SI201831057T patent/SI3610369T1/sl unknown
- 2018-04-13 LT LTEPPCT/US2018/027596T patent/LT3610369T/lt unknown
- 2018-04-13 DK DK18785215.7T patent/DK3610369T3/da active
- 2018-04-13 WO PCT/US2018/027596 patent/WO2018191680A1/en not_active Ceased
- 2018-04-13 AU AU2018252007A patent/AU2018252007B2/en active Active
- 2018-04-13 MX MX2019012212A patent/MX2019012212A/es unknown
- 2018-04-13 HU HUE18785215A patent/HUE065659T2/hu unknown
-
2020
- 2020-06-01 US US16/889,451 patent/US11748079B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| RS65115B1 (sr) | 2024-02-29 |
| AU2018252007B2 (en) | 2022-11-24 |
| US20180300115A1 (en) | 2018-10-18 |
| FI3610369T3 (fi) | 2024-01-30 |
| DK3610369T3 (da) | 2024-01-29 |
| WO2018191680A1 (en) | 2018-10-18 |
| HRP20240139T1 (hr) | 2024-04-12 |
| AU2018252007A1 (en) | 2019-10-03 |
| EP3610369B1 (en) | 2023-11-01 |
| EP3610369A4 (en) | 2021-01-13 |
| JP2020516989A (ja) | 2020-06-11 |
| PL3610369T3 (pl) | 2024-03-25 |
| US20210034345A1 (en) | 2021-02-04 |
| MX2019012212A (es) | 2019-11-28 |
| CN110506257A (zh) | 2019-11-26 |
| SI3610369T1 (sl) | 2024-03-29 |
| CA3059798A1 (en) | 2018-10-18 |
| PT3610369T (pt) | 2024-02-05 |
| JP7073394B2 (ja) | 2022-05-23 |
| SMT202400040T1 (it) | 2024-03-13 |
| HUE065659T2 (hu) | 2024-06-28 |
| US11748079B2 (en) | 2023-09-05 |
| CN110506257B (zh) | 2023-11-03 |
| LT3610369T (lt) | 2024-02-12 |
| EP3610369A1 (en) | 2020-02-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2960508T3 (es) | Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado | |
| ES2905794T3 (es) | Tecnologías para extender de manera segura la APIs de servicios en la nube en un mercado de servicios en la nube | |
| US9558020B2 (en) | Method of processing javascript (JS) API requests | |
| ES2970491T3 (es) | Tecnologías de creación y distribución de conectores de integración en un sistema de intermediación de servicios en la nube | |
| CN112335214A (zh) | 智能合约解释器 | |
| JP7105298B2 (ja) | クラウドサービスブローカーシステムにおいてオファーの機能を自動的に検証する技術 | |
| CN109656538A (zh) | 应用程序的生成方法、装置、系统、设备和介质 | |
| Dalle Vacche | Mastering Zabbix | |
| US12050690B2 (en) | Run-time communications protocol parameter adjustment in containerized applications | |
| CN115668152A (zh) | 应用拓扑发现 | |
| US20250004757A1 (en) | Version management and releases of a software application | |
| Dissanayake | REST API Service Middleware | |
| Granlund et al. | RFC: A user-friendly system for managing and automating network changes in a secure zone model | |
| Bakke et al. | Authentication in the Internet of Things | |
| Rallabandi | LINCHPIN: A YAML Template Based Cross Cloud Resource Provisioning Tool | |
| Diamantis | Resource management of virtual machines in cloud environments |