ES2898050T3 - Método y dispositivo de disposición de servicios, y servidor - Google Patents

Método y dispositivo de disposición de servicios, y servidor Download PDF

Info

Publication number
ES2898050T3
ES2898050T3 ES16924165T ES16924165T ES2898050T3 ES 2898050 T3 ES2898050 T3 ES 2898050T3 ES 16924165 T ES16924165 T ES 16924165T ES 16924165 T ES16924165 T ES 16924165T ES 2898050 T3 ES2898050 T3 ES 2898050T3
Authority
ES
Spain
Prior art keywords
service
flow diagram
live network
operation model
service flow
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
Application number
ES16924165T
Other languages
English (en)
Inventor
Zhijiang Gao
Yi Lin
Xin Liu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2898050T3 publication Critical patent/ES2898050T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método de orquestación de servicios, en donde el método comprende: obtener (301) un diagrama de flujo de servicio, en donde el diagrama de flujo de servicio comprende una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio; obtener (302) un parámetro de planificación que corresponde a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y cuando la verificación tiene éxito, generar (303), en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio, en donde la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran de manera gráfica en una interfaz de operación de usuario; y la obtención de un diagrama de flujo de servicios comprende: determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y determinar el diagrama de flujo de servicio que consiste en la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.

Description

DESCRIPCIÓN
Método y dispositivo de disposición de servicios, y servidor
Campo técnico
Esta solicitud se refiere al campo de las tecnologías de la comunicación y, en particular, a un método y un aparato de orquestación de servicios, y a un servidor.
Antecedentes
Desde que nació una tecnología de redes definidas por software (Software-Defined Networking, SDN para abreviar) y se aplicó a una red de transporte, T-SDN evoluciona continuamente en la dirección de construir una red de transporte de "software" de próxima generación. SDN implementa virtualización de funciones de red, simplificación de la gestión de la red y automatización del despliegue de la red mediante el uso de una interfaz de programación abierta, para satisfacer una demanda urgente de diseño inteligente, apertura e innovación por parte de un operador. Con la introducción de un controlador T-SDN, hay una "inteligencia" para el control centralizado en la red de transporte, y un dispositivo físico se puede controlar directamente mediante el uso de una interfaz hacia el sur (“southbound”). En base al control centralizado, un enfoque SDN comienza a cambiar gradualmente desde la interfaz hacia el sur del controlador a una interfaz hacia el norte (“northbound”) del controlador en la industria. En virtud de un modelo de red de transporte estandarizado y de tecnologías tales como una API hacia el norte y un controlador de código abierto, se espera romper el cierre de una red de transporte convencional, y abrir la capacidad de una red de transporte mediante el uso de una interfaz hacia el norte estándar, de modo que realmente implemente la apertura de la red.
El documento US 2016/294643 A1 describe métodos y sistemas para orquestación de servicios, capaces de integrar recursos de red distribuidos en una red en la nube, para proporcionar un servicio requerido por un proveedor de servicios.
El documento WO 2015/196813 A1 describe técnicas para un método y un aparato de orquestación de servicios en SDN y un medio de almacenamiento.
Ante el crecimiento de varias aplicaciones de internet, un operador necesita expandir continuamente la capacidad y la escala de una red de transporte del operador, para garantizar que haya suficiente ancho de banda para cumplir con requisitos de tráfico en aumento explosivo. Frente a los dispositivos y servicios masivos que aumentan continuamente, el operador necesita realizar operaciones y mantenimiento diferenciados para diferentes escenarios de red y requisitos de servicio. Por lo tanto, un escenario de operación y mantenimiento es más complejo.
Debido a que un requisito de función relacionado con una interfaz hacia el norte y un requisito de función relacionado con la orquestación de servicios SDN no se han explorado por completo, la dificultad en la orquestación y programación de servicios en SDN sigue siendo grande, y un ingeniero de operación y mantenimiento no puede realizar la orquestación y programación de servicios en SDN en línea. Para cumplir con requisitos de servicio variables, un proveedor de equipos o un proveedor de software de terceros aún desarrolla un nuevo servicio o actualiza un servicio para el operador, en base a un sistema de soporte comercial original o a un sistema de soporte de operaciones.
Por ejemplo, si el operador tiene un nuevo requisito de operación y mantenimiento o requiere un nuevo servicio, el operador generalmente necesita describir el requisito del operador al proveedor del equipo, y el proveedor del equipo realiza el desarrollo de funciones personalizadas. Este proceso de desarrollo suele ser un proceso largo y complejo. En un ejemplo en el que se utiliza un modelo en cascada, después de que llega un requisito de desarrollo del operador, es necesario realizar actividades como análisis, diseño, codificación y prueba antes de la entrega final. Un período completo generalmente incluye varios meses. Si el requisito cambia durante el desarrollo, es necesario repetir todo el proceso de desarrollo. Todo el proceso lleva mucho tiempo. Después de completar el desarrollo, el proveedor del equipo necesita realizar operaciones complejas, como la actualización y configuración del software en una red de operador, para finalmente proporcionar un servicio requerido para el operador. Un ingeniero de operación y mantenimiento del operador opera manualmente un sistema de soporte comercial o un sistema de soporte de operaciones que tiene una nueva función de servicio, e implementa la operación y el mantenimiento en un dispositivo físico usando una interfaz hacia el sur.
En conclusión, frente a los requisitos de servicio actuales que son flexibles y variables, la dificultad en la orquestación y programación de servicios en SDN sigue siendo grande, y un ingeniero de operación y mantenimiento no puede realizar la orquestación y programación de servicios en SDN en línea.
Compendio
Las realizaciones de esta solicitud dan a conocer un método y un aparato de orquestación de servicios, y un servidor según se define en las reivindicaciones independientes, para resolver el problema técnico de la técnica anterior de que, frente a requisitos de servicio actuales que son flexibles y variables, todavía existe una gran dificultad en la orquestación y programación de servicios en SDN, y un ingeniero de operación y mantenimiento no puede realizar la orquestación y programación de servicios en SDN en línea.
Según un primer aspecto, una realización de esta solicitud da a conocer un método de orquestación de servicios, y el método incluye:
obtener un diagrama de flujo de servicio de un servicio a orquestar, donde el servicio a orquestar se usa para establecer una operación de gestión y control para una red de transporte, el diagrama de flujo de servicio incluye una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio;
obtener un parámetro de planificación que corresponda a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio.
En esta realización, se construye el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para el parámetro de planificación que se establece para una operación correspondiente a cada identificador de modelo de operación, cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para realizar la operación correspondiente, si hay permiso para obtener, o si existe el recurso de red en vivo que tiene que ser proporcionado para soportar la ejecución del diagrama de flujo de servicio orquestado, puede verificarse en línea interactuando con el plano de control. Cuando la verificación en línea tiene éxito, el diagrama de flujo de servicio orquestado se compila en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente. En base a esto, la orquestación y compilación en línea se pueden realizar en función de diferentes requisitos de servicio, de modo que se cumplen los requisitos de servicio actuales que son flexibles y variables.
Opcionalmente, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se visualizan en una interfaz de operación de usuario de manera gráfica; y
la obtención de un diagrama de flujo de servicio de un servicio a orquestar incluye:
determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y
determinar el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
Opcionalmente, en esta realización, cuando la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en la interfaz de operación de usuario de manera gráfica, se puede proporcionar un entorno gráfico de programación de servicios al usuario, de modo que el usuario puede responder rápidamente a un requisito de servicio personalizado, y se reduce la dificultad de orquestación de servicios.
Opcionalmente, después de obtener un parámetro de planificación que corresponda a cada identificador de modelo de operación, el método incluye además:
realizar una verificación lógica sobre la relación de conexión lógica, y realizar una verificación semántica sobre el parámetro de planificación.
Opcionalmente, en esta realización, la verificación lógica se realiza sobre la relación lógica del servicio, y la verificación semántica y de sintaxis se realiza sobre el parámetro de planificación, de modo que la viabilidad de la orquestación de servicios puede asegurarse preliminarmente.
Opcionalmente, obtener un estado de la red en vivo mediante el uso de un plano de control y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de red en vivo, incluye:
obtener el estado de la red en vivo a través de una interfaz de interacción creada previamente para la interacción con el plano de control;
consultar, en base al estado de la red en vivo, si el recurso de la red en vivo existe en el estado de la red en vivo; y/o determinar, en base al estado de la red en vivo, si hay permiso para solicitar el recurso de la red en vivo.
Los recursos de toda la red SDN se obtienen a través de la interfaz de interacción creada previamente para la interacción con el plano de control, y la viabilidad del diagrama de flujo de servicio orquestado preliminarmente se verifica en función de los recursos obtenidos. Por lo tanto, la viabilidad del servicio orquestado preliminarmente se puede verificar en línea. Además, se puede proporcionar a un operador una plataforma de innovación de orquestación de servicios conveniente, en modo de programación gráfica, para facilitar la innovación de servicios del operador. La plataforma de innovación integra un entorno de desarrollo de control de red, un entorno de desarrollo de prestación de servicios y un entorno de desarrollo de integración de servicios, puede proporcionar al operador una solución completa desde un diseño innovador hasta un desarrollo simple, despliegue rápido y mantenimiento automático, y puede implementar personalización rápida de servicios para el operador y afrontar perfectamente complejos requisitos de operación y mantenimiento. En comparación con la técnica anterior, se implementa realmente la apertura completa de un plano de aplicación en una arquitectura SDN, y se pueden cumplir los requisitos actuales de orquestación de servicios que son flexibles y variables.
Opcionalmente, la generación, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, del código ejecutable para ejecutar el diagrama de flujo de servicio, incluye:
generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y
crear una interfaz de interacción para la interacción con el plano de control, donde la interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable.
En esta realización, cada identificador de modelo de operación corresponde a un modelo de operación, cada modelo de operación es un componente básico o componente mejorado de código abierto, basado en una arquitectura de sistema SDN, y cuando se invoca, cada componente básico o componente mejorado de código abierto puede ser convertido en un archivo de secuencia de comandos (equivalente a un lenguaje de ejecución estándar de un proceso empresarial) que corresponde al modelo de operación. En consecuencia, la relación de conexión lógica entre los identificadores de modelo de operación es un componente lógico de código abierto, basado en la arquitectura de sistema SDN. Cuando se invoca cada componente lógico, se puede formar un archivo de secuencia de comandos que describe una relación lógica entre una pluralidad de modelos operativos. En base a esto, puede ser conveniente procesar el diagrama de flujo de servicio orquestado preliminarmente en el lenguaje de ejecución de procesos empresariales, y convertir el lenguaje de ejecución de procesos empresariales en el código ejecutable, reduciendo así la dificultad de compilación del servicio.
Además, después de generar el código ejecutable para ejecutar el diagrama de flujo de servicio, el método incluye además:
obtener, a través de la interfaz de interacción, el recurso de red en vivo obtenido mediante solicitud;
ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud; y
ayudar, a través de la interfaz de interacción creada y en base al recurso de red en vivo obtenido mediante solicitud, al plano de control a completar las tareas de administración de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
En esta realización, el recurso requerido para ejecutar el servicio orquestado se solicita a través de la interfaz de interacción utilizada para la interacción entre un servidor y el plano de control, por ejemplo, una NBI en una arquitectura SDN, de modo que se pueda extender una función de la NBI. El recurso necesario para ejecutar el servicio orquestado se solicita desde el plano de control de SDN a través de la interfaz de interacción, y el servicio orquestado se ejecuta en función del recurso obtenido mediante solicitud, de modo que la ejecución en línea del servicio orquestado se puede realmente implementar.
Según un segundo aspecto, una realización de esta solicitud da a conocer un aparato de orquestación de servicios, configurado para implementar cualquier método en el primer aspecto. El aparato de orquestación de servicios incluye módulos de función correspondientes, configurados por separado para implementar etapas del método anterior.
Según un tercer aspecto, una realización de esta solicitud da a conocer un servidor, que incluye un procesador, un transceptor y una memoria.
La memoria está configurada para almacenar una instrucción, el procesador está configurado para: ejecutar la instrucción almacenada en la memoria y controlar el transceptor para recibir una señal y enviar una señal, y cuando el procesador ejecuta la instrucción almacenada en la memoria, el procesador está configurado para realizar cualquier método en el primer aspecto.
Breve descripción de los dibujos
la figura 1 es un diagrama esquemático de una arquitectura de sistema SDN según una realización de esta solicitud; la figura 2 es un diagrama estructural esquemático de un servidor configurado para ejecutar un procedimiento de método de orquestación de servicios según una realización de esta solicitud;
la figura 3 es un diagrama de flujo esquemático de un método de orquestación de servicios según una realización de esta solicitud;
la figura 4 es un diagrama esquemático de representación gráfica de un identificador de modelo de operación y una relación de conexión lógica según una realización de esta solicitud;
la figura 5 es un diagrama esquemático del ejemplo 1 de un diagrama de flujo de servicios construido, según una realización de esta solicitud;
la figura 6 es un diagrama esquemático del ejemplo 2 de un diagrama de flujo de servicios construido, según una realización de esta solicitud;
la figura 7 es un diagrama esquemático del ejemplo 3 de un diagrama de flujo de servicios construido, según una realización de esta solicitud;
la figura 8 es un diagrama estructural esquemático de un aparato de orquestación de servicios según una realización de esta solicitud; y
la figura 9 es un diagrama esquemático de una arquitectura de sistema SDN en la que se despliega un aparato de orquestación de servicios, según una realización de esta solicitud.
Descripción de realizaciones
A continuación se describen las soluciones técnicas de esta solicitud haciendo referencia a los dibujos adjuntos. Un método de orquestación de servicios en las realizaciones de esta solicitud es aplicable a la orquestación de servicios SDN de redes definidas por software. La figura 1 es un diagrama de una arquitectura de sistema SDN según una realización de esta solicitud, y la arquitectura de sistema SDN incluye un plano de aplicación, un plano de control y un plano de datos. Un controlador está desplegado en el plano de control. El controlador integra un algoritmo centralizado y tiene funciones automáticas de control centralizado en toda la red, como planificación de la red, optimización de recursos y evaluación del rendimiento. Una NBI, es decir, una interfaz hacia el norte, está abierta entre el plano de aplicación y el plano de control, y una SBI, es decir, una interfaz hacia el sur, está abierta entre el plano de control y el plano de datos.
En la arquitectura de sistema SDN mostrada en la figura 1, los dispositivos físicos de toda la red están implementados en el plano de datos. Estos dispositivos físicos están ubicados en una parte hacia el sur de la arquitectura SDN. El controlador comunica e interactúa con estos dispositivos utilizando la SBI, para controlar directamente estos dispositivos. En comparación con una arquitectura SDN existente, se añade un aparato de orquestación de servicios al plano de aplicación en la arquitectura SDN aplicable a esta realización de esta solicitud. El aparato de orquestación de servicios está ubicado en una parte hacia el norte de la arquitectura SDN y comunica e interactúa con el controlador utilizando la NBI.
El aparato de orquestación de servicios sirve como puente entre el plano de aplicación SDN y el plano de control, y proporciona una capacidad abierta de gestión y desarrollo de plataformas para un usuario final, un desarrollador de aplicaciones y un administrador mediante el uso de NBI, para cumplir un requisito para el desarrollo, funcionamiento y mantenimiento de SDN.
En base a la arquitectura del sistema mostrada en la figura 1, la orquestación de servicios en esta realización de esta solicitud es la orquestación de servicios realizada en base a la arquitectura de sistema SDN. Un servicio a orquestar se determina primero en función de un requisito de servicio de un usuario. El servicio a orquestar se determina en función del requisito de servicio, y el procedimiento de ejecución se utiliza para establecer una operación de gestión y control, para una red de transporte. Un procedimiento de ejecución del servicio a orquestar se determina preliminarmente en base al servicio a orquestar determinado. La operación de gestión y control que se establece en este documento incluye una pluralidad de tipos de tareas de red, que pueden ser varias tareas de gestión y control para un dispositivo de red o un recurso de red en la arquitectura SDN. Un procedimiento de ejecución de un servicio incluye normalmente una pluralidad de etapas de operación y una secuencia de ejecución de la pluralidad de etapas de operación. Posteriormente, si se puede obtener un recurso de red correspondiente de la arquitectura de sistema SDN mediante solicitud para soportar una ejecución suave del servicio a orquestar, se determina en función del procedimiento de ejecución del servicio a orquestar. A continuación, cuando se determina que el recurso de red correspondiente se puede obtener de la arquitectura de sistema SDN mediante solicitud para soportar el servicio a orquestar, se compila el procedimiento de ejecución del servicio a orquestar, para formar código ejecutable. Finalmente, en base al código ejecutable compilado, se solicita un recurso de red correspondiente desde la arquitectura de sistema SDN para ejecutar el código ejecutable compilado, a fin de cumplir el requisito de servicio del usuario.
Por ejemplo, la figura 2 es un diagrama estructural esquemático de un servidor según una realización de esta solicitud. El servidor está configurado para ejecutar un procedimiento de método de orquestación de servicios en una realización de esta solicitud. Tal como se muestra en la figura 2, el servidor incluye un procesador 201 y un transceptor 205. Opcionalmente, el servidor incluye además una memoria 202 y una interfaz de comunicaciones 203. El procesador 201, la memoria 202, la interfaz de comunicaciones 203 y el transceptor 205 están conectados entre sí utilizando un bus 204. La memoria puede estar integrada en el procesador 201, o puede ser independiente del procesador 201.
El bus 204 puede ser un bus de interconexión de componentes periféricos (peripheral component interconnect, PCI para abreviar), un bus de arquitectura estándar industrial extendida (extended industry standard architecture, EISA para abreviar), o similar. El bus 204 puede clasificarse en un bus de direcciones, un bus de datos, un bus de control y similares. Para facilitar la representación, solo se usa una línea gruesa para representar el bus en la figura 2, pero esto no significa que haya un solo bus o solo un tipo de bus.
La memoria 202 puede incluir una memoria volátil (memoria volátil), tal como una memoria de acceso aleatorio (random-access memory, RAM para abreviar); o la memoria puede incluir una memoria no volátil (memoria no volátil), tal como una memoria flash (memoria flash), una unidad de disco duro (hard disk drive, HDD para abreviar) o una unidad de estado sólido (solid state drive, SSD para abreviar); o la memoria 202 puede incluir una combinación de los tipos de memorias anteriores.
La interfaz de comunicaciones 203 puede ser una interfaz de comunicaciones por cable, una interfaz de comunicaciones inalámbricas o una combinación de las mismas. Por ejemplo, la interfaz de comunicaciones por cable puede ser una interfaz Ethernet. La interfaz Ethernet puede ser una interfaz óptica, una interfaz eléctrica o una combinación de las mismas. La interfaz de comunicaciones inalámbricas puede ser una interfaz WLAN.
El procesador 201 puede ser una unidad central de procesamiento (central processing unit, CPU para abreviar), un procesador de red (network processor, NP para abreviar) o una combinación de una CPU y un NP.
El procesador 201 puede incluir además un chip de hardware. El chip de hardware puede ser un circuito integrado de aplicación específica (application-specific integrated circuit, ASIC para abreviar), un dispositivo lógico programable (programmable logic device, PLD para abreviar) o una combinación de los mismos. El PLD puede ser un dispositivo lógico programable complejo (complex programmable logical device, CPLD para abreviar), una matriz de puertas programables en campo (field-programmable gate array, FPGA para abreviar), lógica de matriz genérica (generic array logic, GAL para abreviar), o cualquier combinación de los mismos.
La memoria 202 en esta realización de esta solicitud está configurada para almacenar una instrucción, el procesador 201 está configurado para: ejecutar la instrucción almacenada en la memoria 202 y controlar el transceptor 205 para recibir una señal y enviar una señal, y cuando el procesador 201 ejecuta la instrucción almacenada en la memoria 202, el procesador 201 está configurado para:
obtener un diagrama de flujo de servicio de un servicio a orquestar, donde el servicio a orquestar se usa para establecer una operación de gestión y control para una red de transporte, el diagrama de flujo de servicio incluye una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio;
obtener un parámetro de planificación que corresponda a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio.
En esta realización de esta solicitud, el procesador 201 construye el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para un parámetro de planificación que se establece para una operación correspondiente a cada identificador de modelo de operación, cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para realizar la operación correspondiente, el procesador 201 puede verificar, en línea interactuando con el plano de control , si existe permiso para obtener, o si existe el recurso de red en vivo que tiene que ser proporcionado para soportar la ejecución del diagrama de flujo de servicio orquestado. Cuando la verificación en línea tiene éxito, el procesador 201 compila el diagrama de flujo de servicio orquestado en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente. En base a esto, la orquestación y compilación en línea se pueden realizar en función de diferentes requisitos de servicio, de modo que se cumplen los requisitos de servicio actuales que son flexibles y variables.
Opcionalmente, en esta realización de esta solicitud, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se visualizan en una interfaz de operación de usuario de manera gráfica. El procesador 201 está configurado para: determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario, y determinar el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
Cuando la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en la interfaz de operación de usuario de manera gráfica, se puede proporcionar al usuario un entorno gráfico de programación de servicios, de modo que el usuario puede responder rápidamente a un requisito de servicio personalizado, y se reduce la dificultad de la orquestación de servicios.
Opcionalmente, después de obtener el parámetro de planificación que corresponde a cada identificador de modelo de operación, el procesador 201 está configurado además para: realizar una verificación lógica sobre la relación de conexión lógica, y realizar una verificación semántica sobre el parámetro de planificación.
La verificación lógica se realiza sobre la relación lógica del servicio, y la verificación semántica y sintáctica se realiza sobre el parámetro de planificación, de modo que la viabilidad de la orquestación de servicios se puede asegurar preliminarmente.
Opcionalmente, el procesador 201 está configurado para: obtener el estado de la red en vivo a través de una interfaz de interacción creada previamente para la interacción con el plano de control; consultar, en base al estado de la red en vivo, si el recurso de la red en vivo existe en el estado de la red en vivo; y/o determinar, según el estado de la red en vivo, si hay permiso para solicitar el recurso de la red en vivo.
Opcionalmente, el procesador 201 puede interactuar con un controlador central en el plano de control, el procesador 201 puede interactuar con un orquestador en el plano de control, o el procesador 201 puede interactuar con un sistema de gestión de red en el plano de control.
Opcionalmente, la interfaz de interacción entre el procesador 201 y el plano de control es una NBI en una arquitectura SDN. De este modo, una función de la NBI se puede ampliar más.
Opcionalmente, la interfaz de interacción para interactuar con el plano de control puede ser una interfaz estándar TAPI especificada por la organización Open Networking Foundation (ONF para abreviar).
Opcionalmente, la interfaz de interacción para interactuar con el plano de control puede ser una interfaz estándar IETF (Grupo de trabajo de ingeniería de internet, Internet Engineering Task Force, IETF para abreviar).
Los recursos de toda la red SDN se obtienen a través de la interfaz de interacción creada previamente para la interacción con el plano de control, y la viabilidad del diagrama de flujo de servicio orquestado preliminarmente se verifica en función de los recursos obtenidos. Por lo tanto, la viabilidad del servicio orquestado preliminarmente se puede verificar en línea. Además, se puede proporcionar a un operador una plataforma de innovación de orquestación de servicios conveniente, en modo de programación gráfica, para facilitar la innovación de servicios del operador. La plataforma de innovación integra un entorno de desarrollo de control de red, un entorno de desarrollo de prestación de servicios y un entorno de desarrollo de integración de servicios, puede proporcionar al operador una solución completa desde un diseño innovador hasta un desarrollo simple, despliegue rápido y mantenimiento automático, y puede implementar una personalización de servicios rápida para el operador y afrontar perfectamente complejos requisitos de operación y mantenimiento. En comparación con la técnica anterior, se implementa realmente la apertura completa de un plano de aplicación en una arquitectura SDN, y se pueden cumplir los requisitos actuales de orquestación de servicios que son flexibles y variables.
Opcionalmente, el procesador 201 está configurado para: generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y crear una interfaz de interacción para la interacción con el plano de control, donde la interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable. Para reducir la dificultad de compilación del servicio, en esta realización de esta solicitud, cada identificador de modelo de operación corresponde a un modelo de operación, cada modelo de operación es un componente básico o un componente mejorado de código abierto, basado en una arquitectura de sistema SDN, y cuando se invoca, cada componente básico o componente mejorado de código abierto se puede convertir en un archivo de secuencia de comandos (equivalente a un lenguaje de ejecución estándar de un proceso empresarial) que corresponda al modelo de operación. En consecuencia, la relación de conexión lógica entre los identificadores de modelo de operación es un componente lógico de código abierto, basado en la arquitectura de sistema SDN. Cuando se invoca cada componente lógico, se puede formar un archivo de secuencia de comandos que describe una relación lógica entre una pluralidad de modelos operativos. En base a esto, puede ser conveniente procesar el diagrama de flujo de servicio orquestado preliminarmente en el lenguaje de ejecución de procesos empresariales y convertir el lenguaje de ejecución de procesos empresariales en el código ejecutable, reduciendo así la dificultad de compilación del servicio. Para una relación de mapeo entre un componente básico o un componente mejorado y un identificador de modelo de operación en el diagrama de flujo de servicio, y una relación de mapeo entre un componente lógico y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, se hace referencia a un procedimiento de método.
Opcionalmente, después de generar el código ejecutable para ejecutar el diagrama de flujo de servicio, el procesador 201 está configurado además para: obtener, a través de la interfaz de interacción, el recurso de red en vivo obtenido mediante solicitud; ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud; y ayudar, a través de la interfaz de interacción creada y en función del recurso de red en vivo obtenido mediante solicitud, al plano de control a completar tareas de gestión de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
El recurso necesario para ejecutar el servicio orquestado se solicita a través de la interfaz de interacción utilizada para la interacción entre el servidor y el plano de control, por ejemplo, una NBI en una arquitectura SDN, de modo que se pueda ampliar una función de la NBI. El recurso necesario para ejecutar el servicio orquestado se solicita desde el plano de control de SDN a través de la interfaz de interacción, y el servicio orquestado se ejecuta en función del recurso obtenido mediante solicitud, de modo que la ejecución en línea del servicio orquestado se pueda realmente implementar.
Basado en un mismo concepto inventivo, un método de orquestación de servicios en una realización de esta solicitud es la orquestación y compilación realizada en base a un procedimiento de ejecución de un servicio a orquestar. Por ejemplo, la figura 3 es un diagrama de flujo esquemático de un método según una realización de esta solicitud, y un procesador desplegado en un servidor ejecuta un procedimiento del método para realizar la orquestación de servicios. Tal como se muestra en la figura 3, el método incluye las siguientes etapas:
Etapa 301: obtener un diagrama de flujo de servicio de un servicio a orquestar, donde el servicio a orquestar se usa para establecer una operación de gestión y control para una red de transporte, el diagrama de flujo de servicio incluye una pluralidad de identificadores de modelo de operación y un la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio.
Etapa 302: obtener un parámetro de planificación que corresponde a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, según el estado de la red en vivo obtenido, si se puede obtener el recurso de red en vivo que tiene que ser proporcionado.
Etapa 303: cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio.
Debido a que un procedimiento de ejecución del servicio a orquestar incluye una pluralidad de operaciones y una secuencia de ejecución de la pluralidad de operaciones, para simplificar la orquestación y compilación del servicio a orquestar, un procedimiento de ejecución de la pluralidad de operaciones en el servicio a orquestar se construye de manera que se construye el diagrama de flujo de servicio en esta realización de esta solicitud. El diagrama de flujo de servicios construido incluye la pluralidad de identificadores de modelo de operación preestablecidos y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación. La pluralidad de identificadores de modelo de operación representan etapas de ejecución de la pluralidad de operaciones en el servicio a orquestar. La relación de conexión lógica entre la pluralidad de identificadores de modelo de operación representa la secuencia de ejecución en el diagrama de flujo de servicio construido, y representa una secuencia de ejecución de la pluralidad de operaciones en el servicio a orquestar.
Opcionalmente, para reducir la dificultad en la orquestación y compilación del servicio a orquestar, esta realización de esta solicitud da a conocer un entorno gráfico de programación de servicios, de modo que un usuario puede responder rápidamente a un requisito de servicio personalizado. Específicamente, el entorno gráfico de programación de servicios proporcionado es específicamente el siguiente: la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en una interfaz de operación de usuario de manera gráfica, y la interfaz de operación de usuario en este documento es el entorno gráfico de programación de servicios. Al diseñar el entorno gráfico de programación de servicios, se puede proporcionar una plataforma de innovación conveniente para un operador, para facilitar la innovación de servicios del operador. La plataforma de innovación integra un entorno de desarrollo de control de red, un entorno de desarrollo de prestación de servicios y un entorno de desarrollo de integración de servicios, puede proporcionar al operador una solución completa desde un diseño innovador hasta un desarrollo simple, despliegue rápido y mantenimiento automático, y puede implementar una personalización rápida de servicios para el operador y afrontar perfectamente complejos requisitos de operación y mantenimiento.
Para describir más claramente la pluralidad de identificadores gráficos de modelo de operación y la relación gráfica de conexión lógica en esta realización de esta solicitud, esta solicitud da a conocer el siguiente ejemplo.
Primero, en esta realización de esta solicitud, en base a una característica de un servicio de transporte SDN, algunos componentes se generan a través de código abierto para representar modelos de operación de una pluralidad de operaciones en el servicio de red de transporte, y representan un modelo lógico de secuencia de ejecución entre la pluralidad de modelos de operación. Tanto los modelos operativos de código abierto como el modelo lógico se denominan componentes de la red de transporte, y los componentes de la red de transporte suelen incluir un componente básico, un componente mejorado y un componente lógico.
El componente básico está configurado para realizar una operación básica de gestión y control en un dispositivo de red o en un servicio de red en la red de transporte. La operación básica de gestión y control incluye la gestión y el control de la conexión, la gestión y el control de los elementos de la red, la gestión y el control del modelo de servicio, la gestión y el control de OAM, y similares. El componente básico es un modelo de operación de red de transporte SDN generado después de que se lleve a cabo encapsulado o desarrollo secundario en base a una interfaz estándar NBI, TAPI o IETF en el plano de control SDN abierto, por ejemplo, un componente básico "Crear servicio" que representa una operación de creación, un componente básico "Consultar servicio" que representa una operación de consulta, un componente básico "Actualizar servicio" que representa una operación de actualización, un componente básico "Eliminar servicio" que representa una operación de eliminación y un componente básico "Consultar topología" que representa una consulta de la topología de la red.
El componente mejorado proporciona un modelo de política general, un modelo de algoritmo y un modelo de servicio estándar para la operación básica de gestión y control. El modelo de política proporciona una política encapsulada para un usuario. Por ejemplo, un componente de política de tiempo "Temporizado^1 puede proporcionar políticas de tiempo comunes, tales como temporización y ciclos. El modelo de algoritmo puede proporcionar funciones de algoritmo tales como cálculo básico de rutas, optimización de red y análisis de servicios.
El componente lógico proporciona varios tipos de lógica de servicio para la operación básica de gestión y control. El componente lógico se forma haciendo referencia a un principio de diseño de programa y la característica del servicio de transporte, incluye mecanismos como "Lógica secuencial", "Lógica de pasarelas paralelas", "Ciclos" y "Activación de eventos", y está configurado para implementar Varias relaciones de combinación lógica entre componentes básicos o componentes mejorados. Por ejemplo, el componente lógico puede ser "Inicio (Inicio)", "Fin (Fin)", "Lógica secuencial (Lógica secuencial)" o "Lógica de pasarelas paralelas (Lógica de pasarelas paralelas)".
Ciertamente, los componentes de la red de transporte en esta realización de esta solicitud no se limitan a los tres componentes anteriores, y también deberán incluir componentes independientes que estén especialmente diseñados e implementados por un tercero en el futuro. Estos componentes independientes pueden tener una función de transporte especial. En esta realización de esta solicitud, estos componentes independientes se denominan colectivamente componentes de terceros. Ciertamente, los componentes de terceros también incluyen componentes que tienen la misma función que el componente básico, el componente mejorado y el componente lógico anteriores.
Además, el identificador del modo de operación en esta realización de esta solicitud es un identificador del componente básico o el componente mejorado en esta realización de esta solicitud. La relación de conexión lógica entre la pluralidad de identificadores de modelo de operación en esta realización de esta solicitud es un identificador del componente lógico, que representa la relación de combinación lógica entre componentes básicos o componentes mejorados en esta realización de esta solicitud.
Por ejemplo, el identificador del componente básico es "Crear servicio", "Consultar servicio", "Actualizar servicio", "Eliminar servicio" o "Consultar topología". Por ejemplo, el identificador del componente mejorado es "Temporizador", y el identificador del componente lógico es "Inicio", "Fin", "Lógica secuencial", "Lógica de pasarelas paralelas", o similar.
A continuación, la representación gráfica de la pluralidad de identificadores de modelo de operación y la relación de conexión lógica es la representación gráfica de los identificadores de los componentes de la red de transporte (incluido el componente básico, el componente mejorado, el componente lógico y el componente de terceros).
Se ilustran los identificadores gráficos de modelo de operación y la relación de conexión lógica. Opcionalmente, tal como se muestra en la figura 4, identificadores tales como "Crear servicio (Crear servicio)", "Consultar servicio (Consultar servicio)", "Actualizar servicio (Actualizar servicio)", "Temporizador (Temporizador)", "Inicio (Inicio)", "Fin (Fin )", "Lógica secuencial (Lógica secuencial)" y "Lógica de pasarelas paralelas (Lógica de pasarelas paralelas)" se muestran en la interfaz de operación de usuario en forma de bloques gráficos. El usuario puede seleccionar estos bloques gráficos para una interfaz de programación de servicios en varias formas de selección, tales como copiar, pegar, insertar, arrastrar e importar.
En esta realización de esta solicitud, una forma de representación gráfica de los identificadores de modelo de operación y la relación de conexión lógica no se limita a mostrar los identificadores de los componentes de la red de transporte en los bloques gráficos, y cualesquiera otras formas de representación gráfica de los identificadores de modelo de operación y la relación de conexión lógica deben caer dentro del alcance de protección de esta realización de esta solicitud.
Basándose en los identificadores gráficos de modelo de operación y la relación gráfica de conexión lógica, cuando se está construyendo un diagrama de flujo de servicio de un servicio a orquestar, para el usuario, se puede construir el diagrama de flujo de servicio del servicio a orquestar siempre que una pluralidad de identificadores de modelo de operación y una relación de conexión lógica se seleccionen de la interfaz de operación de usuario. Para un procesador que realiza orquestación de servicios, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación que son seleccionadas por el usuario pueden determinarse basándose únicamente en una instrucción de operación correspondiente en la interfaz de operación de usuario, de modo que se puede determinar el diagrama de flujo de servicio del servicio a orquestar.
Opcionalmente, la obtención de un diagrama de flujo de servicio en la etapa 301 incluye: determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y determinar el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
Opcionalmente, el usuario puede almacenar el diagrama de flujo de servicio construido como una plantilla de servicio, y buscar o seleccionar la plantilla de servicio almacenada cuando un servicio similar necesita ser orquestado posteriormente, para obtener un diagrama de flujo de servicio del servicio a orquestar. Por lo tanto, el diagrama de flujo de servicio obtenido puede ser un diagrama de flujo de servicio seleccionado directamente de las plantillas de servicio almacenadas previamente.
La pluralidad de operaciones en el servicio a orquestar necesariamente necesita estar soportada por algunos elementos. Estos elementos se denominan parámetros de planificación. Sin embargo, cada identificador de modelo de operación en el diagrama de flujo de servicio del servicio a orquestar es solo un identificador de un componente básico o un componente mejorado. Por lo tanto, es necesario establecer un parámetro de planificación para cada identificador de modelo de operación en el diagrama de flujo de servicio construido. Por ejemplo, una de las operaciones en el servicio a orquestar es "consultar el ancho de banda ODU2 entre un nodo de origen A y un nodo receptor E". Un identificador de modelo de operación de esta operación puede ser sólo "Consultar servicio", y los elementos de consulta que soportan esta operación de consulta son "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2". Por lo tanto, durante la orquestación de servicios, estos elementos de consulta "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" tienen además que orquestarse en el diagrama de flujo de servicio como parámetros de planificación. Para el procesador que realiza orquestación de servicios, es necesario obtener el parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio.
En esta realización de esta solicitud, para un programador, el parámetro de planificación que corresponde a cada identificador gráfico de modelo de operación en el diagrama de flujo de servicio puede establecerse utilizando la interfaz de operación de usuario.
Opcionalmente, para evitar aumentar la carga de diseño del programador, se mapea a cada modelo de operación una pluralidad de opciones de parámetros que se pueden seleccionar. Para una opción de parámetro seleccionada, se puede establecer un parámetro de planificación requerido por cada operación en el servicio a orquestar. En consecuencia, para el procesador que realiza orquestación de servicios, se tiene que almacenar previamente una opción de parámetro que corresponda a cada identificador de modelo de operación. Para una operación de establecimiento de parámetros realizada por el usuario en la interfaz de operación de usuario, se almacena un parámetro de planificación que corresponde a cada opción de parámetro.
Opcionalmente, la obtención de un parámetro de planificación que corresponda a cada identificador de modelo de operación en la etapa 302 incluye:
determinar, en base a la instrucción de operación del usuario en la interfaz de operación de usuario, el parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio. Específicamente, el parámetro de planificación que corresponde a cada identificador de modelo de operación se determina en base a una opción de parámetro que es seleccionada por el usuario y que corresponde a cada identificador de modelo de operación, y un valor de parámetro introducido por el usuario para la opción de parámetro seleccionada.
Para implementar compilación en línea, antes de la compilación, es necesario verificar si el parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio orquestado preliminarmente es válido, y es necesario verificar si la lógica de servicio del diagrama de flujo de servicio es válida, y cuándo el parámetro de planificación es un recurso que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio (por ejemplo, un recurso requerido para crear ancho de banda ODU3 entre el nodo de origen A y el nodo receptor E), es necesario verificar si el recurso que tiene que ser proporcionado puede obtenerse de un recurso inactivo SDN mediante solicitud, o cuando el parámetro de planificación es un recurso que es necesario solicitar para ejecutar el diagrama de flujo de servicio (por ejemplo, un recurso que es necesario solicitar para consultar el ancho de banda ODU2 entre el nodo de origen A y el nodo receptor E), es necesario verificar si el recurso que tiene que consultarse existe en los recursos de toda la red SDN.
En base a esto, opcionalmente, para el procesador que realiza orquestación de servicios, después de obtener un parámetro de planificación que corresponda a cada identificador de modelo de operación, el método incluye además las siguientes etapas:
(1) Realizar una verificación lógica de la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación en el diagrama de flujo de servicio.
La verificación lógica es principalmente para verificar si la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación en el diagrama de flujo de servicio es ilógica.
(2) Realizar una verificación semántica sobre los parámetros de planificación que corresponden respectivamente a la pluralidad de identificadores de modelo de operación en el diagrama de flujo de servicio.
La verificación semántica de los parámetros de planificación es principalmente para verificar si los parámetros de planificación son válidos.
(3) Cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, verificar si se puede obtener el recurso de red en vivo que tiene que ser proporcionado.
Cabe señalar que, cuando el identificador de modelo de operación en el diagrama de flujo de servicio es un identificador de un componente mejorado, el parámetro de planificación que corresponde al identificador de modelo de operación suele ser un parámetro de tiempo especificado o un parámetro de algoritmo y, por lo general, no es necesario proporcionar ningún recurso de red en vivo. Por lo tanto, por lo general, no se realiza ninguna verificación obteniendo un estado de la red en vivo mediante el uso del plano de control, y solo es necesario realizar una verificación semántica. Sin embargo, no se excluye un caso especial.
Cuando el identificador de modelo de operación en el diagrama de flujo de servicio es un identificador de un componente básico, además de que se realiza la verificación semántica sobre el parámetro de planificación que corresponde al identificador de modelo de operación, generalmente es necesario proporcionar un recurso de red en vivo. Por lo tanto, es necesario obtener un estado de la red en vivo utilizando el plano de control para realizar la verificación.
Según la arquitectura de sistema SDN proporcionada en la realización de esta solicitud, el recurso de red en vivo que tiene que ser proporcionado en este caso es un recurso que tiene que planificarse desde un plano de datos SDN cuando se verifica un parámetro de planificación que corresponde a cualquier identificador de modelo de operación en el diagrama de flujo de servicio, y el estado de la red en vivo obtenido mediante el uso del plano de control en este caso es una vista de recursos de toda la red contenida en el plano de datos SDN en base a la arquitectura de sistema SDN. Se puede consultar un estado de recurso y un estado de servicio de cualquier dispositivo de nodo en función de la vista de recursos de toda la red.
Opcionalmente, cuando el parámetro de planificación es el recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, el estado de la red en vivo se obtiene utilizando el plano de control, y el que se pueda obtener el recurso de red en vivo que tiene que ser proporcionado se verifica en base al estado de la red en vivo obtenido.
Opcionalmente, obtener el estado de la red en vivo mediante el uso del plano de control incluye: obtener, mediante el procesador que realiza orquestación de servicios, el estado de la red en vivo a través de una interfaz de interacción creada previamente, para la interacción con el plano de control.
Opcionalmente, el procesador que realiza orquestación de servicios interactúa con un controlador central en el plano de control, el procesador que realiza orquestación de servicios puede interactuar con un orquestador en el plano de control, o el procesador que realiza orquestación de servicios puede interactuar con un sistema de gestión de red en el plano de control.
Opcionalmente, cuando el estado de la red en vivo se obtiene utilizando el plano de control para verificar el parámetro de planificación, la interfaz de interacción invocada es una NBI en el plano de control en la arquitectura de sistema SDN proporcionada en la realización de esta solicitud. Opcionalmente, la interfaz de interacción para interactuar con el plano de control puede ser una interfaz estándar TAPI especificada por la organización ONF. Opcionalmente, la interfaz de interacción para interactuar con el plano de control puede ser alternativamente una interfaz estándar IETF.
Específicamente, cuando el parámetro de planificación es el recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, verificar si se puede obtener el recurso de red en vivo que tiene que ser proporcionado, incluye:
(a) cuando el parámetro de planificación incluye un recurso que tiene que usarse para ejecutar el diagrama de flujo de servicio, verificar si hay permiso para solicitar el recurso que tiene que usarse desde un recurso inactivo SDN; y
(b) cuando el parámetro de planificación incluye un recurso que es necesario solicitar para ejecutar el diagrama de flujo de servicio, verificar si el recurso que es necesario solicitar existe en los recursos de toda la red SDN Cuando todos los elementos de verificación anteriores tienen éxito, se realiza la etapa 303, que incluye específicamente:
generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y crear una interfaz de interacción para la interacción con el plano de control, donde la interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable.
La realización anterior ha descrito en detalle que un modelo de operación correspondiente a cada identificador de modelo de operación es un componente básico o componente mejorado de código abierto, basado en la arquitectura de sistema SDN. En esta realización de esta solicitud, cuando se invoca cada componente básico o componente mejorado de código abierto, se puede formar un lenguaje de descripción de código abierto de una operación correspondiente en base a un parámetro de planificación que se establece para el componente básico o componente mejorado de código abierto. Basándose en la técnica anterior, el lenguaje de descripción de la operación se puede convertir en un archivo de secuencia de comandos correspondiente a la operación. En consecuencia, la relación de conexión lógica entre los identificadores de modelo de operación es un componente lógico de código abierto, basado en la arquitectura de sistema SDN. Cuando se invoca cada componente lógico, se puede formar un lenguaje de descripción de código abierto que describe una relación lógica entre una pluralidad de operaciones correspondientes a la pluralidad de identificadores de modelo de operación.
Por ejemplo, una secuencia de comandos XML de la operación que corresponde a cada identificador de modelo de operación se puede generar en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, y a un lenguaje de descripción de código abierto de un componente básico o un componente mejorado que corresponde a cada identificador de modelo de operación. Un archivo de secuencia de comandos XML para realizar todas las operaciones en el diagrama de flujo de servicio construido, se puede generar en base a la secuencia de comandos XML generada de la operación que corresponde a cada identificador de modelo de operación, y a una secuencia de comandos XML de la relación lógica entre la pluralidad de operaciones correspondientes a la pluralidad de identificadores de modelo de operación. A continuación, el archivo de secuencia de comandos XML para realizar todas las operaciones en el diagrama de flujo de servicios construido se puede convertir en el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicios construido. Opcionalmente, se puede utilizar un modelo de procesamiento de transacciones BPMN (business process modeling notation, notación de modelado de procesos empresariales) para convertir el diagrama de flujo de servicios que tiene éxito en la verificación en un lenguaje de ejecución de procesos empresariales y a continuación convertir el lenguaje de ejecución de procesos empresariales en un programa ejecutable. Una especificación BPMN, por ejemplo, un estándar de lenguaje de ejecución de procesos empresariales BPEL (estándar de lenguaje de ejecución de procesos empresariales), puede soportar el mapeo del diagrama de flujo de servicios creado al lenguaje de ejecución de procesos empresariales.
Para ejecutar en línea el código ejecutable compilado, al generar el código ejecutable anterior, el procesador que realiza orquestación de servicios necesita además crear la interfaz de interacción utilizada para la interacción entre el procesador que realiza orquestación de servicios y el plano de control. La interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable orquestado. El recurso de red en vivo que tiene que ser proporcionado es en este caso un recurso que tiene que planificarse, durante la ejecución del código ejecutable del diagrama de flujo de servicio orquestado, desde el plano de datos SDN para un parámetro de planificación que se establece para una operación correspondiente a cualquier identificador de modelo de operación. El recurso que tiene que planificarse desde el plano de datos SDN incluye un recurso que tiene que solicitarse y/o un recurso que tiene que consultarse.
Cabe señalar que, en un proceso de verificación, un objetivo de planificación del recurso desde el plano de datos SDN al interactuar con el plano de control es verificar si existe el recurso que es necesario solicitar y si hay permiso para solicitar el recurso que tiene que solicitarse. Cuando se ejecuta el código ejecutable, un objetivo de planificación del recurso desde el plano de datos SDN interactuando con el plano de control es solicitar el recurso que es necesario solicitar y el recurso que es necesario utilizar.
Opcionalmente, en base a la arquitectura de sistema SDN dada a conocer en la realización de esta solicitud, la interfaz de interacción creada en la etapa 303 para la interacción entre el procesador que realiza orquestación de servicios y el plano de control es la NBI en el plano de control en la arquitectura de sistema SDN.
Opcionalmente, la interfaz de interacción entre el procesador que realiza orquestación de servicios y el plano de control puede ser alternativamente una interfaz estándar TAPI especificada por la organización ONF.
Opcionalmente, la interfaz de interacción entre el procesador que realiza orquestación de servicios y el plano de control puede ser alternativamente la interfaz estándar IETF.
En base a la interfaz de interacción creada entre el procesador que realiza orquestación de servicios y el plano de control, después de la etapa 303, el procesador que realiza orquestación de servicios realiza además las siguientes etapas: obtener, a través de la interfaz de interacción creada, el recurso de red en vivo obtenido mediante solicitud; y ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud. Según la arquitectura de sistema SDN proporcionada en la realización de esta solicitud, el recurso de red en vivo obtenido mediante solicitud incluye un recurso SDN que tiene que consultarse para ejecutar el código ejecutable y un recurso SDN que tiene que usarse para ejecutar el código ejecutable.
En esta realización de esta solicitud, el procesador que realiza orquestación de servicios puede ejecutar y administrar el servicio diseñado. El programa ejecutable diseñado con éxito puede denominarse una tarea. El procesador que realiza orquestación de servicios puede completar varios tipos de administración de una máquina de estado de tareas, por ejemplo, operaciones de administración de tareas, tales como ejecutar una tarea, suspender una tarea, modificar una tarea y almacenar una tarea como plantilla. Especialmente, en un proceso completo de administración de tareas, el procesador que realiza orquestación de servicios necesita realizar una operación de verificación durante una pluralidad de veces, y realizar la verificación del estado de ejecución sobre la lógica de la tarea en línea interactuando con el plano de control en tiempo real, para garantizar que la tarea se puede ejecutar normalmente en una red en vivo.
Además, en un proceso de ejecución del código ejecutable, el procesador que realiza orquestación de servicios puede además instruir, a través de la interfaz de interacción creada, al plano de control para actualizar el estado de la red en vivo en función del recurso de red en vivo obtenido mediante solicitud. Por ejemplo, el procesador que realiza orquestación de servicios interactúa en línea con el plano de control a través de la interfaz de interacción, para ayudar al plano de control a completar, según el recurso de red en vivo obtenido mediante solicitud, las tareas de administración de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
Cabe señalar que esta solicitud es principalmente aplicable a una red OTN (red de transporte óptico) o a WDM (multiplexación por división de longitud de onda). Un concepto innovador de orquestación gráfica de servicios y compilación en línea en esta solicitud también es aplicable a otro entorno de red, tal como IP.
En esta realización de esta solicitud, se construye el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para el parámetro de planificación que se establece para la operación correspondiente a cada identificador de modelo de operación, cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para realizar la operación correspondiente, el que haya permiso para obtener, o exista el recurso de red en vivo que tiene que ser proporcionado para soportar la ejecución del diagrama de flujo de servicio orquestado, puede verificarse en línea interactuando con el plano de control. Cuando la verificación en línea tiene éxito, el diagrama de flujo de servicio orquestado se compila en el código ejecutable, de modo que se implementa compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente. En base a esto, la orquestación y compilación en línea se pueden realizar en función de diferentes requisitos de servicio, de modo que se cumplen los requisitos de servicio actuales que son flexibles y variables.
Ejemplo 1
En base al procedimiento de método anterior, una realización de esta solicitud da a conocer un procedimiento de método de orquestación de servicios para crear automáticamente un servicio en un momento específico. Específicamente, se crea un servicio S1 en un tiempo t1 y el servicio S1 es un servicio ODU. Específicamente, se crea ODU2 desde un nodo A a un nodo E. El procedimiento de método incluye las siguientes etapas.
Etapa 401: determinar, en base a "Crear servicio" gráfico, a 'Temporizador" gráfico y a "Inicio", "Fin" y "Lógica secuencial" gráficos, que son seleccionados por un usuario, los identificadores de modelo de operación "Crear servicio" y "Temporizador ", y una relación de conexión lógica que incluye "Inicio" , "Fin" y "Lógica secuencial ". Etapa 402: obtener un diagrama de flujo de servicio que incluye los identificadores de modelo de operación "Crear servicio" y "Temporizador", y la relación de conexión lógica que incluye "Inicio", "Fin" y "Lógica secuencial".
Haciendo referencia a la figura 5, se obtiene el diagrama de flujo de servicio formado conectando por orden "Inicio (Inicio)", "Temporizador (Temporizador)", "Crear servicio (Crear servicio)" y "Fin (Fin)".
Etapa 403: determinar, en base a la entrada del usuario, un parámetro de planificación que corresponde a cada uno de los identificadores de modelo de operación "Crear servicio" y "Temporizador".
Específicamente, los parámetros de planificación que corresponden a "Crear servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" en función de tres elementos de parámetro: "nodo de origen", "nodo receptor" y "ancho de banda" que corresponden a "Crear servicio" seleccionado por el usuario, y a los parámetros: "nodo A", "nodo E" y "ODU2" que son introducidos respectivamente por el usuario en los tres elementos de parámetro.
El parámetro de planificación que corresponde a "Temporizador" se determina como t1 en base a t1 introducido en un elemento de parámetro que corresponde a "Temporizador" seleccionado por el usuario.
Etapa 404: realizar una verificación lógica sobre la lógica de servicio del diagrama de flujo de servicio, y verificar los parámetros de planificación que corresponden a "Crear servicio" y el parámetro de planificación que corresponde a "Temporizador".
Opcionalmente, un proceso de verificación incluye los siguientes elementos de verificación.
1. Verificar si la semántica de la lógica de servicio es válida, por ejemplo, si la lógica de servicio entra en conflicto con otra lógica.
2. Verificar si la semántica del parámetro de planificación t1 que corresponde a "Temporizador" es válida, donde t1 puede ser solo un tiempo futuro y no puede ser un tiempo pasado.
3. Verificar si los formatos de datos y los tipos de datos de los parámetros de planificación "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" que corresponden a "Crear servicio" son válidos y correctos. 4. Al verificar que los parámetros de planificación que corresponden a "Crear servicio" incluyen un recurso que es necesario solicitar, verificar si el recurso que es necesario solicitar existe en los recursos de toda la red SDN. Antes de la verificación, la información de la topología de la red, la información del dispositivo de red en tiempo real y la información sobre un puerto disponible entre el "nodo de origen A" y el "nodo receptor E" tienen que obtenerse utilizando un plano de control. A continuación, en base a la información obtenida, se verifica si hay un "nodo de origen A" normal y un "nodo receptor E" normal, y se verifica si hay un puerto disponible configurado para ODU2. Si existe el "nodo de origen A" normal y el "nodo receptor E" normal, y existe el puerto disponible configurado para ODU2, el resultado de verificación de esta verificación es que la verificación tiene éxito.
5. Al verificar que los parámetros de planificación que corresponden a "Crear servicio" incluyen un recurso que tiene que usarse, verificar si hay permiso para obtener el recurso que tiene que usarse a partir de un recurso inactivo SDN mediante solicitud.
Antes de esta verificación, es necesario obtener información de autenticación de la operación de red relacionada, información OAM, información de recursos inactivos y similares utilizando el plano de control. A continuación, en base a la información obtenida, se verifica si existe permiso para realizar una operación (por ejemplo, solicitar un recurso de SDN y crear el servicio S1 utilizando el recurso obtenido mediante solicitud) en una red en el tiempo t1, y se verifica si hay suficientes recursos para soportar la creación del servicio ODU2 desde el nodo A al nodo E.
Si hay permiso para realizar una operación en la red en el tiempo t1, y hay suficientes recursos para crear el servicio ODU2 desde el nodo A al nodo E, esta verificación tiene éxito.
Si la verificación en cualquiera de los elementos de verificación anteriores falla, se solicita finalizar esta tarea de orquestación de servicios, de modo que un programador restablezca un parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio.
Si la verificación de todos los elementos de verificación anteriores tiene éxito, el resultado de la verificación es que la verificación tiene éxito. En este caso, se puede realizar la siguiente etapa.
Etapa 405: procesar el diagrama de flujo de servicio orquestado, para generar un programa ejecutable, tal como código Java o código de lenguaje C, con relación a un modelo de procesamiento de transacciones BPMN y en base al diagrama de flujo de servicio orquestado, y el parámetro de planificación t1 que corresponde a "Temporizado^1 y los parámetros de planificación que corresponden a "Crear servicio" en el diagrama de flujo de servicio.
Cuando se genera código ejecutable, se crea además una interfaz de interacción a través de la cual se tiene que realizar la interacción con el plano de control para planificar un recurso durante la ejecución del código ejecutable. Por ejemplo, una interfaz de creación de servicios (un tipo de interfaz de la interfaz de creación de servicios puede ser una interfaz estándar NBI, TAPI o IETF).
Etapa 406: ejecutar el programa ejecutable orquestado, en un modo de ejecución de prueba a través de la interfaz de interacción creada, para interactuar con el plano de control.
En base a la interfaz de interacción creada, un proceso de ejecución del programa ejecutable es el siguiente: cuando t1 llega, se invoca la interfaz de creación de servicio para obtener un recurso requerido para crear el servicio ODU2 desde el nodo A al nodo E, y el servicio ODU2 del nodo A al nodo E se crea en base al recurso obtenido.
En el proceso de ejecución del programa ejecutable, la interacción en línea se puede realizar además con el plano de control, para ayudar al plano de control a completar tareas como consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
En el ejemplo específico anterior, se construye el diagrama de flujo de servicio que incluye "Crear servicio", "Temporizado^1, "Inicio", "Fin" y "Lógica secuencial", de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para los parámetros de planificación que se establecen para las operaciones correspondientes a "Crear servicio" y "Temporizado^1, cuando los parámetros de planificación son recursos de red en vivo que tienen que ser proporcionados para realizar las operaciones correspondientes, si hay, y si hay permiso para obtener los recursos de red en vivo que tienen que ser proporcionados para soportar la ejecución del diagrama de flujo de servicio orquestado, se puede verificarse en línea interactuando con el plano de control. Cuando la verificación en línea tiene éxito, el diagrama de flujo de servicio orquestado se compila en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente.
Ejemplo 2
Basándose en el procedimiento de método anterior, una realización de esta solicitud da a conocer un procedimiento de método de orquestación de servicios para actualizar automáticamente un servicio de temporización. Por ejemplo, un servicio S1 se actualiza a un servicio S2 en un tiempo t2, para ser específico, un servicio ODU2 desde un nodo de origen A a un nodo receptor E se cambia a un servicio ODU3 desde el nodo de origen A al nodo receptor E. El procedimiento de método incluye las siguientes etapas.
Etapa 501: determinar, en base a "Consultar servicio" (identificador de modelo de operación de consulta) y "Actualizar servicio" (identificador de modelo de operación de actualización) gráficos, "Temporizado^1 gráfico e "Inicio", "Fin" y "Lógica secuencial" gráficos, que son seleccionados por un usuario, identificadores de modelo de operación "Crear servicio", "Actualizar servicio" y "Temporizador", y una relación de conexión lógica que incluye "Inicio", "Fin" y "Lógica secuencial".
Etapa 502: obtener un diagrama de flujo de servicio que incluye los identificadores de modelo de operación "Consultar servicio", "Actualizar servicio" y "Temporizador", y la relación de conexión lógica que incluye "Inicio", "Fin" y "Lógica secuencial".
Haciendo referencia a la figura 6, se obtiene el diagrama de flujo de servicio formado conectando por orden "Inicio (Inicio)", "Consultar servicio (Consultar servicio)", "Temporizador (Temporizador)", "Actualizar servicio (Actualizar servicio)" y "Fin (Fin)".
Etapa 503: determinar, en base a la entrada del usuario, un parámetro de planificación que corresponda a cada uno de los identificadores de modelo de operación "Consultar servicio", "Actualizar servicio" y "Temporizador".
Específicamente, los parámetros de planificación que corresponden a "Consultar servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" en función de tres elementos de parámetro: "nodo de origen", "nodo receptor" y "ancho de banda" que corresponden a "Consultar servicio" seleccionado por el usuario, y a los parámetros:"nodo A" , "nodo E" y "ODU2" que son respectivamente introducidos por el usuario en los tres elementos de parámetro.
Los parámetros de planificación que corresponden a "Actualizar servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU3" en función de tres elementos de parámetro: "nodo de origen", "nodo receptor" y "ancho de banda" que corresponden a "Actualizar servicio" seleccionado por el usuario, y a los parámetros: "nodo A", "nodo E" y "ODU3" que son introducidos respectivamente por el usuario en los tres elementos de parámetro.
El parámetro de planificación que corresponde a "Temporizador" se determina como t2, en base a t2 introducido en un elemento de parámetro que corresponde a "Temporizador" seleccionado por el usuario.
Etapa 504: realizar una verificación lógica sobre la lógica de servicio del diagrama de flujo de servicio, y verificar los parámetros de planificación que corresponden respectivamente a "Consultar servicio", "Actualizar servicio" y "Temporizador".
Opcionalmente, un proceso de verificación incluye los siguientes elementos de verificación.
1. Se verifica si la semántica de la lógica de servicio es válida, por ejemplo, se verifica si la lógica de servicio entra en conflicto con otra lógica.
2. Se verifica si la semántica del parámetro de planificación t2 que corresponde a "Temporizador" es válida, donde t2 solo puede ser un tiempo futuro y no puede ser un tiempo pasado.
3. Se verifica si los formatos de datos y los tipos de datos de los parámetros de planificación "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" que corresponden a "Consultar servicio" son válidos y correctos, y se verifica si los formatos de datos y los tipos de datos de los parámetros de planificación "nodo de origen A", "nodo receptor E" y "ancho de banda ODU3" que corresponden a "Actualizar servicio" son válidos y correctos.
4. Se verifica si un recurso que es necesario solicitar para verificar los parámetros de planificación que corresponden a "Consultar servicio" y a "Actualizar servicio" existe en los recursos de toda la red SDN.
Dado que los parámetros de planificación que corresponden a "Consultar servicio" y "Actualizar servicio" incluyen el recurso que tiene que consultarse, antes de la verificación, es necesario obtener información de topología de red, información de dispositivos de red en tiempo real e información sobre un puerto disponible entre el "nodo de origen A" y el "nodo receptor E", utilizando un plano de control. A continuación, en base a la información obtenida, se verifica si hay un "nodo de origen A" normal y un "nodo receptor E" normal, se verifica si el nodo de origen A y el nodo receptor E soportan un cambio de ancho de banda, se verifica si hay un puerto para el servicio ODU2 desde el nodo de origen A hasta el nodo receptor E, y se verifica si hay un puerto disponible configurado para ODU3. Si existe el "nodo de origen A" normal y el "nodo receptor E" normal, existe el puerto para el servicio ODU2 desde el nodo de origen A al nodo receptor E, existe el puerto disponible configurado para ODU3 y el nodo de origen A y el nodo receptor E soportan el cambio de ancho de banda, el resultado de verificación de esta verificación es que la verificación tiene éxito.
5. Se verifica si existe permiso para obtener un recurso que es necesario utilizar, a partir de un recurso inactivo SDN mediante solicitud.
Debido a que los parámetros de planificación que corresponden a "Actualizar servicio" incluyen el recurso que tiene que usarse, antes de esta verificación, es necesario obtener información de autenticación de la operación de red relacionada, información de OAM, información de recursos inactivos y similares, utilizando el plano de control. A continuación, en base a la información obtenida, se verifica si existe permiso para realizar una operación en una red en el tiempo t2 (por ejemplo, solicitar un recurso de SDN y crear el servicio S2 utilizando el recurso obtenido mediante solicitud), y se verifica si hay suficientes recursos para soportar la creación del servicio ODU3 desde el nodo de origen A hasta el nodo receptor E.
Si hay permiso para realizar una operación en la red en el tiempo t2, y hay suficientes recursos para crear el servicio ODU3 desde el nodo de origen A hasta el nodo receptor E, esta verificación tiene éxito.
Si la verificación en cualquiera de los elementos de verificación anteriores falla, se solicita finalizar esta tarea de orquestación de servicios, de modo que un programador restablece un parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio.
Si la verificación de todos los elementos de verificación anteriores tiene éxito, el resultado de la verificación es que la verificación tiene éxito. En este caso, se puede realizar la siguiente etapa.
Etapa 505: procesar el diagrama de flujo de servicio orquestado, para generar un programa ejecutable, tal como código Java o código de lenguaje de programación C, haciendo referencia a un modelo de procesamiento de transacciones BPMN y en base al diagrama de flujo de servicio orquestado, y el parámetro de planificación t2 que corresponde a "Temporizadô ' y a parámetros de planificación que corresponden a "Consultar servicio" y "Actualizar servicio" en el diagrama de flujo de servicio.
Cuando se genera código ejecutable, se crea además una interfaz de interacción a través de la cual se tiene que realizar la interacción con el plano de control para planificar un recurso durante la ejecución del código ejecutable, por ejemplo, una interfaz de consulta de servicio y una interfaz de actualización de servicio (los tipos de interfaz de la interfaz de consulta de servicio y la interfaz de actualización de servicio pueden ser una interfaz estándar NBI, TAPI o IETF).
Etapa 506: ejecutar el programa ejecutable orquestado, en un modo de ejecución de prueba a través de la interfaz de interacción creada, para interactuar con el plano de control.
Según la interfaz de interacción creada, un proceso de ejecución del programa ejecutable es el siguiente: la interfaz de consulta de servicio se invoca para consultar información relacionada con el servicio ODU2 desde el nodo de origen A al nodo receptor E, cuando llega t2, se invoca la interfaz de actualización del servicio, para obtener un recurso requerido para actualizar el servicio ODU2 desde el nodo de origen A al nodo receptor E, y el servicio ODU2 desde el nodo de origen A al nodo receptor E se cambia al servicio ODU3 desde el nodo de origen A al nodo receptor E en base al recurso obtenido.
En el proceso de ejecución del programa ejecutable, la interacción en línea se puede realizar además con el plano de control, para ayudar al plano de control a completar tareas como consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
Algunas otras características opcionales en esta realización de esta solicitud son las mismas que las de la realización del método anterior. Para más detalles, se hace referencia a la descripción en la realización del método anterior, y los detalles no se describen en este caso nuevamente.
En el ejemplo específico anterior, se construye el diagrama de flujo de servicio formado conectando por orden "Inicio", "Consultar servicio", "Temporizado^1, "Actualizar servicio" y "Fin", de modo que la orquestación preliminar del servicio a orquestar se simplifica. Para los parámetros de planificación que se establecen para operaciones correspondientes a "Consultar servicio", "Temporizado^1 y "Actualizar servicio", cuando los parámetros de planificación son recursos de red en vivo que tienen que ser proporcionados para realizar las operaciones correspondientes, si existen, y si existe permiso para obtener los recursos de red en vivo que tienen que ser proporcionados para soportar la ejecución del diagrama de flujo de servicio orquestado, se puede verificar en línea interactuando con el plano de control. Cuando la verificación en línea tiene éxito, el diagrama de flujo de servicio orquestado se compila en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente.
Ejemplo 3
Basándose en el procedimiento de método anterior, una realización de esta solicitud da a conocer un procedimiento de método de orquestación de servicios para actualizar el ancho de banda de temporización. Se asume que un servicio ODU1 desde un nodo de origen A a un nodo receptor E se denomina servicio S3 para abreviar, un servicio ODU0 desde el nodo de origen A al nodo receptor E se denomina servicio S4 para abreviar, y un servicio ODU2 desde el nodo de origen A al nodo receptor E se denomina servicio S5 para abreviar. Si un servicio que es necesario orquestar es el siguiente: el servicio S3 se crea primero, el servicio S3 se cambia al servicio S4 en un período de tiempo T3 a T4 cada día, y el servicio S4 se cambia al servicio S5 en un período de tiempo T5 a T6 cada día, el procedimiento de método incluye las siguientes etapas.
Etapa 601: determinar, en base a "Crear servicio" (crear el identificador de modelo de operación) y "Actualizar servicio" (actualizar identificador de modelo de operación) gráficos, a "Temporizador" gráfico y a "Inicio", "Fin" y "Lógica secuencial" gráficos, que son seleccionados por un usuario, identificadores de modelo de operación "Crear servicio", "Actualizar servicio" y "Temporizador", y una relación de conexión lógica que incluye "Inicio", "Fin", "Lógica secuencial (lógica secuencial)" y "Lógica paralela (Lógica paralela)", donde hay dos bloques de "Actualizar servicio" y dos bloques de "Temporizador".
Etapa 602: obtener un diagrama de flujo de servicios que incluye los identificadores de modelo de operación "Crear servicio", "Actualizar servicio" y "Temporizador", y la relación de conexión lógica que incluye "Inicio", "Fin" y "Lógica secuencial".
Haciendo referencia a la figura 7, el diagrama de flujo de servicio en el que "Inicio (Inicio)", "Crear servicio (Crear servicio)" y "Lógica paralela (Lógica paralela)" están conectados por orden, se forman dos ramas después de "Lógica paralela (Lógica paralela)" , cada rama se forma conectando por el orden "Temporizador (Temporizador)" y "Actualizar servicio (Actualizar servicio)", y cada bloque de "Actualizar servicio (Actualizar servicio)" se conecta a "Fin (Fin)" en el orden en que se obtiene.
Etapa 603: determinar, en base a la entrada del usuario, un parámetro de planificación que corresponda a cada uno de los identificadores de modelo de operación "Crear servicio", "Actualizar servicio" y "Temporizador" que se encuentran en cada rama.
Específicamente, los parámetros de planificación que corresponden a "Crear servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU1" en base a "nodo A", "nodo E" y "ODU1" que son introducido por el usuario en elementos de parámetro que corresponden a "Crear servicio".
Los parámetros de planificación que corresponden a "Actualizar servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU0" según los parámetros "nodo A", "nodo E" y "ODU0" que se introducen en elementos de parámetro que corresponden a "Actualizar servicio" que es seleccionado por el usuario en una primera rama.
El parámetro de planificación que corresponde a "Temporizador" en la primera rama se determina como "período de tiempo T3 a T4" en base al "período de tiempo T3 a T4" introducido en un elemento de parámetro que corresponde a "Temporizador" que es seleccionado por el usuario y que está en la primera rama.
Los parámetros de planificación que corresponden a "Actualizar servicio" se determinan como "nodo de origen A", "nodo receptor E" y "ancho de banda ODU2" según los parámetros "nodo A", "nodo E" y "ODU2" que son respectivamente introducidos en elementos de parámetro que corresponden a "Actualizar servicio" que es seleccionado por el usuario en una segunda rama.
El parámetro de planificación que corresponde a "Temporizador" en la segunda rama se determina como "período de tiempo T5 a T6" en base al "período de tiempo T5 a T6" introducido en un elemento de parámetro que corresponde a "Temporizador" que es seleccionado por el usuario y que está en la segunda rama.
Etapa 604: realizar una verificación lógica sobre la lógica de servicio del diagrama de flujo de servicio, y verificar los parámetros de planificación que corresponden respectivamente a "Crear servicio", "Actualizar servicio" y "Temporizador".
Opcionalmente, un proceso de verificación incluye los siguientes elementos de verificación.
1. Se verifica si la semántica de la lógica de servicio es válida, por ejemplo, si la lógica de servicio entra en conflicto con otra lógica.
2. Se verifica si la semántica de los parámetros de planificación "período de tiempo T3 a T4" y "período de tiempo T5 a T6" que corresponden a "Temporizador" es válida, y si el período de tiempo T3 a T4 se solapa con el período de tiempo T5 a T6.
3. Se verifica si los formatos de datos y los tipos de datos de los parámetros de planificación "nodo de origen A", "nodo receptor E" y "ancho de banda ODU1" que corresponden a "Crear servicio" son válidos y correctos, y se verifica si los formatos de datos y los tipos de datos del los parámetros de planificación "nodo de origen A", "nodo receptor E", "ancho de banda ODU0" y "ancho de banda ODU2" que corresponden a "Actualizar servicio" son válidos y correctos.
4. Se verifica si un recurso que es necesario solicitar para verificar los parámetros de planificación que corresponden a "Crear servicio" y "Actualizar servicio" existe en los recursos de toda la red SDN.
Dado que los parámetros de planificación que corresponden a "Crear servicio" y "Actualizar servicio" incluyen el recurso que tiene que consultarse, antes de la verificación, es necesario obtener información de topología de red, información de dispositivos de red en tiempo real e información sobre un puerto disponible entre el "nodo de origen A" y el "nodo receptor E", utilizando un plano de control. A continuación, en base a la información obtenida, se verifica si existe un "nodo de origen A" normal y un "nodo receptor E" normal, se verifica si el "nodo de origen A" y el "nodo receptor E" admiten un cambio de ancho de banda, y se verifica si hay puertos disponibles configurados respectivamente para ODU1, ODU0 y ODU2.
Si existe el "nodo de origen A" normal y el "nodo receptor E" normal, existen los puertos disponibles configurados respectivamente para ODU1, ODU0 y ODU2, y el nodo de origen A y el nodo receptor E admiten el cambio de ancho de banda, a el resultado de la verificación de esta verificación es que la verificación tiene éxito.
5. Se verifica si existe permiso para obtener un recurso que es necesario utilizar, a partir de un recurso inactivo SDN mediante solicitud.
Debido a que los parámetros de planificación que corresponden a "Actualizar servicio" incluyen el recurso que tiene que usarse, antes de esta verificación, es necesario obtener información de autenticación de la operación de red relacionada, información de OAM, información de recursos inactivos y similares, utilizando el plano de control. A continuación, en base a la información obtenida, se verifica si hay permiso para realizar una operación en una red en el período de tiempo T3 a T4 y el período de tiempo T5 a T6, se verifica si hay recursos suficientes para crear el servicio ODU1 (es decir, el servicio S3) desde el nodo de origen A al nodo receptor E, se verifica si hay suficientes recursos para cambiar del servicio S3 al servicio S4, y se verifica si hay suficientes recursos para cambiar del servicio S4 al servicio S5.
Si hay permiso para realizar una operación en la red en el período de tiempo T3 a T4 y el período de tiempo T5 a T6, y hay recursos suficientes para crear el servicio de origen S3, cambiar del servicio S3 al servicio S4 y cambiar del servicio S4 al servicio S5, esta verificación tiene éxito.
Si la verificación en cualquiera de los elementos de verificación anteriores falla, se solicita finalizar esta tarea de orquestación de servicios, de modo que un programador restablece un parámetro de planificación que corresponde a cada identificador de modelo de operación en el diagrama de flujo de servicio.
Si la verificación de todos los elementos de verificación anteriores tiene éxito, el resultado de la verificación es que la verificación tiene éxito. En este caso, se puede realizar la siguiente etapa.
Etapa 605: procesar el diagrama de flujo de servicio orquestado, para generar un programa ejecutable, tal como código Java o código de lenguaje de programación C, haciendo referencia a un modelo de procesamiento de transacciones BPMN y en base al diagrama de flujo de servicio orquestado, y el parámetro de planificación que corresponde a "Temporizador" y los parámetros de planificación que corresponden a "Crear servicio" y "Actualizar servicio" en el diagrama de flujo de servicio.
Cuando se genera código ejecutable, se crea además una interfaz de interacción a través de la cual se tiene que realizar la interacción con el plano de control para planificar un recurso durante la ejecución del código ejecutable, por ejemplo, una interfaz de creación de servicios y una interfaz de actualización de servicios.
Etapa 606: ejecutar el programa ejecutable orquestado, en un modo de ejecución de prueba a través de la interfaz de interacción creada, para interactuar con el plano de control.
En base a la interfaz de interacción creada, un proceso de ejecución del programa ejecutable es el siguiente: la interfaz de creación de servicio se invoca para obtener un recurso requerido para crear el servicio S3, y el servicio ODU1 desde el nodo de origen A hasta el nodo receptor E se crea en base al recurso obtenido; cuando llega T3, se invoca la interfaz de actualización del servicio para obtener un recurso necesario para cambiar del servicio S3 al servicio S4, el servicio ODU1 del nodo de origen A al nodo receptor E se cambia al servicio ODU0 desde el nodo de origen A al nodo receptor E en base al recurso obtenido, y el servicio S4 se mantiene en el período de tiempo T3 a T4; y cuando llega T5, se invoca la interfaz de actualización del servicio para obtener un recurso requerido para cambiar del servicio S4 al servicio S5, el servicio ODU0 del nodo de origen A al nodo receptor E se cambia al servicio ODU2 desde el nodo de origen A al nodo receptor E en función del recurso obtenido, y el servicio 5 se mantiene en el período de tiempo de T5 a T6.
En el proceso de ejecución del programa ejecutable, la interacción en línea se puede realizar además con el plano de control, para ayudar al plano de control a completar tareas como consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
En el ejemplo específico anterior, se construye el diagrama de flujo de servicio en el que "Inicio", "Crear servicio" y "Lógica paralela" están conectados por orden, las dos ramas están formadas después de "Lógica paralela", cada rama está formada conectando por el orden "Temporizador" y "Actualizar servicio", y cada bloque de "Actualizar servicio" está conectado a "Fin" por orden, de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para los parámetros de planificación que se establecen para las operaciones correspondientes a "Crear servicio", cada bloque de "Temporizador" y cada bloque de "Actualizar servicio", cuando los parámetros de planificación son recursos de red en vivo que tienen que ser proporcionados para realizar las operaciones correspondientes, si hay, y si hay permiso para obtener los recursos de red en vivo que tienen que ser proporcionados para soportar la ejecución del diagrama de flujo de servicio orquestado, se puede verificar en línea interactuando con el plano de control. Cuando la verificación en línea tiene éxito, el diagrama de flujo de servicio orquestado se compila en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el plano de control, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente.
En base a un mismo concepto inventivo, tal como se muestra en la figura 8, una realización de esta solicitud da a conocer además un aparato 800 de orquestación de servicios. Tal como se muestra en la figura 9, el aparato 800 de orquestación de servicios está ubicado en un plano de aplicación en una arquitectura de sistema SDN, un controlador 900 está implementado en un plano de control en la arquitectura de sistema SDN, y una pluralidad de dispositivos de nodo que acceden a la SDN están implementados en un plano de datos en la arquitectura de sistema SDN, por ejemplo, un nodo A, un nodo B, un nodo C, un nodo E y un nodo F mostrados en la figura 9. Para un diagrama de topología de estos dispositivos de nodo, se hace referencia a la figura 9. El controlador 900 puede obtener un diagrama de topología del plano de datos y, además, puede realizar gestión de recursos y mantenimiento del servicio en cada dispositivo de nodo en el plano de datos. En esta arquitectura de sistema, el aparato de orquestación de servicios 800 incluye:
una unidad de orquestación 820, configurada para obtener un diagrama de flujo de servicio de un servicio a orquestar, donde el servicio a orquestar se usa para establecer una operación de gestión y control para una red de transporte, el diagrama de flujo de servicio incluye una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio; dónde
la unidad de orquestación 820 está configurada además para obtener un parámetro de planificación que corresponde a cada identificador de modelo de operación;
una unidad de verificación 840, configurada para: cuando el parámetro de planificación obtenido por la unidad de orquestación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
una unidad de compilación 860, configurada para: cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que es obtenido por la unidad de orquestación y que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio.
Opcionalmente, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en una interfaz de operación de usuario de manera gráfica, y la unidad de orquestación 820 está configurada para: determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y
determinar el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
Opcionalmente, después de que la unidad de orquestación 820 obtenga el parámetro de planificación que corresponde a cada identificador de modelo de operación, la unidad de verificación 840 está configurada además para:
realizar una verificación lógica sobre la relación de conexión lógica, y realizar una verificación semántica sobre el parámetro de planificación.
Opcionalmente, la unidad de verificación 840 está configurada para:
obtener el estado de la red en vivo a través de una interfaz de interacción creada previamente para la interacción con el controlador 900 en el plano de control, donde para la interfaz de interacción entre el controlador 900 en el plano de control y la unidad de verificación 840, se hace referencia a la figura 9;
consultar, en base al estado de la red en vivo, si el recurso de la red en vivo existe en el estado de la red en vivo; y/o determinar, según el estado de la red en vivo, si hay permiso para solicitar el recurso de red en vivo.
Opcionalmente, la unidad de compilación 860 está configurada para:
generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y
crear una interfaz de interacción utilizada para la interacción entre el controlador 900 en el plano de control y una unidad de ejecución 880, donde la interfaz de interacción está configurada para solicitar al controlador 900 en el plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable.
Opcionalmente, el aparato de orquestación de servicios 800 incluye además la unidad de ejecución 880, y para la interfaz de interacción entre el controlador 900 en el plano de control y la unidad de ejecución 880, se hace referencia a la figura 9.
Después de que la unidad de compilación 860 genera el código ejecutable para ejecutar el diagrama de flujo de servicio, la unidad de ejecución 880 está configurada para: obtener, a través de la interfaz de interacción, el recurso de red en vivo obtenido mediante solicitud;
ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud; y
ayudar, a través de la interfaz de interacción y en base al recurso de red en vivo obtenido mediante solicitud, al plano de control a completar las tareas de administración de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
En esta realización de esta solicitud, el aparato de orquestación de servicios construye el diagrama de flujo de servicio que incluye la pluralidad de identificadores de modelo de operación y la relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, de modo que se simplifica la orquestación preliminar del servicio a orquestar. Para el parámetro de planificación que se establece para una operación correspondiente a cada identificador de modelo de operación, cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para realizar la operación correspondiente, el aparato de orquestación de servicios puede verificar, en línea interactuando con el plano de control, si hay permiso para obtener, o si existe el recurso de red en vivo que tiene que ser proporcionado para soportar la ejecución del diagrama de flujo de servicio orquestado. Cuando la verificación en línea tiene éxito, el aparato de orquestación de servicios compila el diagrama de flujo de servicio orquestado en el código ejecutable, de modo que se implementa la compilación del servicio en línea. En comparación con la técnica anterior, en un procedimiento de ejecución en el que el servicio a orquestar se orquesta preliminarmente orquestando el diagrama de flujo de servicio, se puede reducir la dificultad en la orquestación y compilación del servicio. La verificación de viabilidad en el servicio orquestado se realiza en línea mediante interacción con el controlador, y se compila además un servicio orquestado que tiene éxito en la verificación de viabilidad, de modo que la orquestación y compilación en línea del servicio personalizado se puede completar de manera eficiente. En base a esto, la orquestación y compilación en línea se pueden realizar en función de diferentes requisitos de servicio, de modo que se cumplen los requisitos de servicio actuales que son flexibles y variables. Algunas otras características opcionales en esta realización de esta solicitud son las mismas que las de la realización del método anterior. Para más detalles, se hace referencia a la descripción en la realización del método anterior, y los detalles no se describen en este caso nuevamente.
Los expertos en la técnica deben comprender que las realizaciones de esta solicitud pueden proporcionarse como un método, o un producto de programa informático. Por lo tanto, esta solicitud puede usar una forma de realizaciones de solo hardware, realizaciones de solo software o realizaciones con una combinación de software y hardware. Además, esta solicitud puede utilizar una forma de producto de programa informático que se implementa en uno o más medios de almacenamiento utilizables por ordenador (que incluyen, entre otros, una memoria de disco, un CD-ROM, una memoria óptica y similares) que incluyen código de programa utilizable por ordenador. Esta solicitud se describe haciendo referencia a los diagramas de flujo y/o diagramas de bloques del método, el dispositivo (sistema) y el producto de programa informático según las realizaciones de esta solicitud. Debe entenderse que se pueden utilizar instrucciones de programa informático para implementar cada proceso y/o cada bloque en los diagramas de flujo y/o los diagramas de bloques, y una combinación de un proceso y/o un bloque en los diagramas de flujo y/o los diagramas de bloques. Estas instrucciones de programa de ordenador pueden proporcionarse para un ordenador de propósito general, un ordenador dedicado, un procesador integrado o un procesador de otro dispositivo programable de procesamiento de datos, para generar una máquina, de modo que las instrucciones ejecutadas por un ordenador o un procesador de otro dispositivo programable de procesamiento de datos generan un aparato para implementar una función específica en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques.
Estas instrucciones de programa de ordenador pueden almacenarse en una memoria legible por ordenador que puede instruir al ordenador u otro dispositivo programable de procesamiento de datos, para que funcione de una manera específica, de modo que las instrucciones almacenadas en la memoria legible por ordenador generen un artefacto que incluye un aparato de instrucción. El aparato de instrucción implementa una función específica en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques.
Estas instrucciones de programa informático pueden cargarse en un ordenador u otro dispositivo programable de procesamiento de datos, de modo que se realicen una serie de operaciones y etapas en el ordenador o en el otro dispositivo programable, generando así un proceso implementado por ordenador. Por tanto, las instrucciones ejecutadas en el ordenador o en el otro dispositivo programable proporcionan etapas para implementar una función específica en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques. Aunque se han descrito algunas realizaciones opcionales de esta solicitud, los expertos en la técnica pueden realizar cambios y modificaciones a estas realizaciones una vez que aprendan el concepto inventivo básico. Por lo tanto, se pretende que las reivindicaciones adjuntas cubran las realizaciones y todos los cambios y modificaciones que caen dentro del alcance de esta solicitud.
Obviamente, los expertos en la técnica pueden realizar diversas modificaciones y variaciones a esta solicitud sin apartarse del alcance de esta solicitud. Esta solicitud está destinada a cubrir estas modificaciones y variaciones de esta solicitud siempre que estén dentro del alcance de protección definido por las siguientes reivindicaciones y sus tecnologías equivalentes.

Claims (12)

REIVINDICACIONES
1. Un método de orquestación de servicios, en donde el método comprende:
obtener (301) un diagrama de flujo de servicio, en donde el diagrama de flujo de servicio comprende una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio;
obtener (302) un parámetro de planificación que corresponde a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
cuando la verificación tiene éxito, generar (303), en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio, en donde la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran de manera gráfica en una interfaz de operación de usuario; y
la obtención de un diagrama de flujo de servicios comprende:
determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y
determinar el diagrama de flujo de servicio que consiste en la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
2. El método según la reivindicación 1, en donde después de obtener un parámetro de planificación que corresponde a cada identificador de modelo de operación, el método comprende además:
realizar una verificación lógica de la relación de conexión lógica; y
realizar una verificación semántica sobre el parámetro de planificación.
3. El método según la reivindicación 2, en donde obtener un estado de la red en vivo utilizando un plano de control, y verificar, en base al estado de la red en vivo obtenido, si se puede obtener el recurso de red en vivo, comprende: obtener el estado de la red en vivo a través de una interfaz de interacción creada previamente para la interacción con el plano de control;
consultar, en base al estado de la red en vivo, si el recurso de la red en vivo existe en el estado de la red en vivo; y/o determinar, según el estado de la red en vivo, si hay permiso para solicitar el recurso de red en vivo.
4. El método según una cualquiera de las reivindicaciones 1 a 3, en donde la generación, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio, comprende:
generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y
crear una interfaz de interacción para la interacción con el plano de control, donde la interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable.
5. El método según la reivindicación 4, después de generar el código ejecutable para ejecutar el diagrama de flujo de servicio, que comprende además:
obtener, a través de la interfaz de interacción, el recurso de red en vivo obtenido mediante solicitud;
ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud; y
ayudar, a través de la interfaz de interacción creada y en base al recurso de red en vivo obtenido mediante solicitud, al plano de control a completar las tareas de administración de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
6. Un aparato de orquestación de servicios, que comprende:
una unidad de orquestación, configurada para obtener un diagrama de flujo de servicio, donde el diagrama de flujo de servicio comprende una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio; en donde
la unidad de orquestación está configurada además para obtener un parámetro de planificación que corresponde a cada identificador de modelo de operación;
una unidad de verificación, configurada para: cuando el parámetro de planificación obtenido por la unidad de orquestación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en función del estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
una unidad de compilación, configurada para: cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que obtiene la unidad de orquestación y que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio, en donde la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en una interfaz de operación de usuario de manera gráfica, y la unidad de orquestación está configurada para:
determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y
determinar el diagrama de flujo de servicio que consiste en la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
7. El aparato según la reivindicación 6, en donde después de que la unidad de orquestación obtenga el parámetro de planificación que corresponde a cada identificador de modelo de operación, la unidad de verificación está configurada además para:
realizar una verificación lógica sobre la relación de conexión lógica, y realizar una verificación semántica sobre el parámetro de planificación.
8. El aparato según la reivindicación 7, en donde la unidad de verificación está configurada para:
obtener el estado de la red en vivo a través de una interfaz de interacción creada previamente para la interacción con el plano de control;
consultar, en base al estado de la red en vivo, si el recurso de la red en vivo existe en el estado de la red en vivo; y/o determinar, en base al estado de la red en vivo, si hay permiso para solicitar el recurso de red en vivo.
9. Aparato según una cualquiera de las reivindicaciones 6 a 8, en donde la unidad de compilación está configurada para:
generar, en base al parámetro de planificación que corresponde a cada identificador de modelo de operación, un archivo de secuencia de comandos de una operación que corresponde a cada identificador de modelo de operación; generar, en base a la relación de conexión lógica y al archivo de secuencia de comandos de la operación que corresponde a cada identificador de modelo de operación, el código ejecutable para realizar todas las operaciones en el diagrama de flujo de servicio; y
crear una interfaz de interacción para la interacción con el plano de control, donde la interfaz de interacción está configurada para solicitar al plano de control el recurso de red en vivo que tiene que ser proporcionado para ejecutar el código ejecutable.
10. El aparato según la reivindicación 9, que comprende además una unidad de ejecución, en donde
después de que la unidad de compilación genera el código ejecutable para ejecutar el diagrama de flujo de servicio, la unidad de ejecución está configurada para: obtener, a través de la interfaz de interacción, el recurso de red en vivo obtenido mediante solicitud;
ejecutar el código ejecutable en base al recurso de red en vivo obtenido mediante solicitud; y
ayudar, a través de la interfaz de interacción y en base al recurso de red en vivo obtenido mediante solicitud, al plano de control a completar las tareas de administración de recursos para consultar un recurso de capa inferior, reservar un recurso de capa inferior y notificar un cambio de recurso de capa inferior.
11. Un servidor, que comprende un procesador, un transceptor y una memoria, en donde
la memoria está configurada para almacenar una instrucción, el procesador está configurado para: ejecutar la instrucción almacenada en la memoria y controlar el transceptor para recibir una señal y enviar una señal, y cuando el procesador ejecuta la instrucción almacenada en la memoria, el procesador está configurado para:
obtener un diagrama de flujo de servicio, en donde el diagrama de flujo de servicio comprende una pluralidad de identificadores de modelo de operación y una relación de conexión lógica entre la pluralidad de identificadores de modelo de operación, y la relación de conexión lógica es una secuencia de ejecución en el diagrama de flujo de servicio;
obtener un parámetro de planificación que corresponda a cada identificador de modelo de operación, y cuando el parámetro de planificación es un recurso de red en vivo que tiene que ser proporcionado para ejecutar el diagrama de flujo de servicio, obtener un estado de la red en vivo mediante el uso de un plano de control, y verificar, en base al estado de la red en vivo obtenido, si se puede obtener el recurso de la red en vivo; y
cuando la verificación tiene éxito, generar, en base a la relación de conexión lógica y al parámetro de planificación que corresponde a cada identificador de modelo de operación, código ejecutable para ejecutar el diagrama de flujo de servicio, en donde la pluralidad de identificadores de modelo de operación y la relación de conexión lógica se muestran en una interfaz de operación de usuario de manera gráfica, y el procesador está configurado para: determinar, en base a una instrucción de operación de un usuario en la interfaz de operación de usuario, la pluralidad de identificadores de modelo de operación y la relación de conexión lógica que son seleccionadas por el usuario; y
determinar el diagrama de flujo de servicio que consiste en la pluralidad de identificadores de modelo de operación y la relación de conexión lógica.
12. El servidor según la reivindicación 11, en donde después de obtener el parámetro de planificación que corresponde a cada identificador de modelo de operación, el procesador está configurado además para: realizar una verificación lógica sobre la relación de conexión lógica, y realizar una verificación semántica sobre el parámetro de planificación.
ES16924165T 2016-12-15 2016-12-15 Método y dispositivo de disposición de servicios, y servidor Active ES2898050T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2016/110158 WO2018107442A1 (zh) 2016-12-15 2016-12-15 一种业务编排方法、装置及服务器

Publications (1)

Publication Number Publication Date
ES2898050T3 true ES2898050T3 (es) 2022-03-03

Family

ID=62557894

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16924165T Active ES2898050T3 (es) 2016-12-15 2016-12-15 Método y dispositivo de disposición de servicios, y servidor

Country Status (5)

Country Link
US (1) US11178233B2 (es)
EP (1) EP3544260B1 (es)
CN (1) CN108432208B (es)
ES (1) ES2898050T3 (es)
WO (1) WO2018107442A1 (es)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109104297B (zh) * 2018-07-09 2022-01-21 中国银行股份有限公司 一种业务流程的处理方法及装置
CN109408112B (zh) * 2018-09-25 2024-01-16 平安科技（深圳）有限公司 在线开发文档生成方法、装置、终端及可读存储介质
CN111061723B (zh) * 2018-10-16 2023-05-09 中国移动通信有限公司研究院 工作流实现方法及装置
US20200153679A1 (en) * 2018-11-08 2020-05-14 Huawei Technologies Co., Ltd. Method for enhancing status communications in a sdn-based communication system
CN109933315A (zh) * 2019-02-26 2019-06-25 广州衡昊数据科技有限公司 一种图形化的业务处理系统和方法
CN111083722B (zh) * 2019-04-15 2024-06-07 中兴通讯股份有限公司 模型的推送、模型的请求方法及装置、存储介质
CN112084827B (zh) * 2019-06-14 2024-02-23 杭州海康威视数字技术股份有限公司 数据处理方法及装置
CN110413267B (zh) * 2019-08-08 2023-05-26 四川爱创科技有限公司 基于业务规则的自适应业务流程建模方法
CN113094167A (zh) * 2020-01-08 2021-07-09 顺丰科技有限公司 一种云计算资源处理方法、装置、设备及存储介质
CN111404738B (zh) * 2020-03-10 2023-05-30 中国电信集团工会上海市委员会 一种网络控制器的流表和配置的热修改方法
CN111429127A (zh) * 2020-03-20 2020-07-17 中国建设银行股份有限公司 一种应用于缴费的业务管理方法和装置
CN111949338A (zh) * 2020-08-10 2020-11-17 上海熙菱信息技术有限公司 一种基于微服务的服务编排方法
CN111966334B (zh) * 2020-08-17 2023-06-27 支付宝(杭州)信息技术有限公司 一种业务处理方法、装置及设备
CN112099848B (zh) * 2020-09-11 2024-03-05 杭州海康威视数字技术股份有限公司 一种业务处理方法、装置及设备
CN112379884B (zh) * 2020-11-13 2024-01-12 李斌 基于Spark和并行内存计算的流程引擎实现方法及系统
CN114527962A (zh) * 2020-11-23 2022-05-24 中国移动通信集团重庆有限公司 流程自动化处理装置、方法及计算设备
CN113469647A (zh) * 2021-06-23 2021-10-01 广州鲁邦通智能科技有限公司 一种企业信息集成系统和业务处理方法
CN113435846A (zh) * 2021-06-30 2021-09-24 深圳平安智汇企业信息管理有限公司 业务流程编排方法、装置、计算机设备及存储介质
CN113553159A (zh) * 2021-07-29 2021-10-26 共达地创新技术(深圳)有限公司 基于可视化的模型调度方法、设备和存储介质
CN113934416B (zh) * 2021-10-26 2022-08-19 山东同圆数字科技有限公司 基于图形化语义策略编程的运维管理方法及系统
CN114679495B (zh) * 2022-02-08 2024-01-05 阿里云计算有限公司 一种资源服务操作请求的调度编排方法和调度执行方法
CN114691233A (zh) * 2022-03-16 2022-07-01 中国电子科技集团公司第五十四研究所 一种基于工作流引擎的遥感数据处理插件分布式调度方法
WO2024065191A1 (en) * 2022-09-27 2024-04-04 Siemens Aktiengesellschaft Method, apparatus, electronic device, and readable storage medium for orchestrating microservices
CN115564322B (zh) * 2022-12-06 2023-09-19 连连（杭州）信息技术有限公司 一种业务处理方法、装置、电子设备及存储介质
CN116132513B (zh) * 2023-02-24 2024-04-19 重庆长安汽车股份有限公司 服务编排的参数更新方法、装置、设备及存储介质
CN115955409B (zh) * 2023-03-09 2023-05-30 花瓣云科技有限公司 一种变更编排方法及相关装置
CN117611094B (zh) * 2023-12-06 2024-06-07 阿帕数字科技有限公司 基于业务流程编排实现供应链体系设计方法及系统
CN117472552B (zh) * 2023-12-28 2024-05-28 中电数据产业有限公司 服务场景智能编排及动态调度方法、装置、设备及介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6263358B1 (en) * 1997-07-25 2001-07-17 British Telecommunications Public Limited Company Scheduler for a software system having means for allocating tasks
US7117500B2 (en) * 2001-12-20 2006-10-03 Cadence Design Systems, Inc. Mechanism for managing execution of interdependent aggregated processes
US7596416B1 (en) * 2004-08-25 2009-09-29 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Project management tool
GB0427133D0 (en) * 2004-12-10 2005-01-12 British Telecomm Workflow scheduler
CN101729588A (zh) * 2008-10-17 2010-06-09 华为技术有限公司 一种业务编排的方法及装置
US8887163B2 (en) * 2010-06-25 2014-11-11 Ebay Inc. Task scheduling based on dependencies and resources
WO2012126105A1 (en) * 2011-03-21 2012-09-27 Hegazi Tarek Mohamed Mohamed System and method for schedule optimization
CN103513976B (zh) 2012-06-29 2018-06-12 中兴通讯股份有限公司 业务流程建模方法及装置
US8812752B1 (en) * 2012-12-18 2014-08-19 Amazon Technologies, Inc. Connector interface for data pipeline
CN104811326A (zh) 2014-01-24 2015-07-29 中兴通讯股份有限公司 一种管理业务链的方法、系统及装置
US9798596B2 (en) * 2014-02-27 2017-10-24 Commvault Systems, Inc. Automatic alert escalation for an information management system
CN104978172A (zh) 2014-04-04 2015-10-14 中兴通讯股份有限公司 Sdn应用集成管理和控制的方法、系统及设备
CN105207798B (zh) * 2014-06-26 2020-03-13 中兴通讯股份有限公司 软件定义网络中的业务编排方法及装置
CN104360842B (zh) 2014-10-23 2017-09-26 桂林电子科技大学 一种基于jbpm的服务动态流程编排方法
US10403399B2 (en) * 2014-11-20 2019-09-03 Netspective Communications Llc Tasks scheduling based on triggering event and work lists management
KR102364712B1 (ko) * 2015-04-03 2022-02-18 한국전자통신연구원 분산 클라우드 환경에서 서비스 오케스트레이션 시스템 및 방법
US9886311B2 (en) * 2015-04-24 2018-02-06 International Business Machines Corporation Job scheduling management
US9916177B2 (en) * 2015-08-19 2018-03-13 International Business Machines Corporation Predictive workload scheduling with integrated analytics
CN106209875A (zh) * 2016-07-19 2016-12-07 青岛海信传媒网络技术有限公司 基于多业务服务器的业务处理方法及业务服务器

Also Published As

Publication number Publication date
US11178233B2 (en) 2021-11-16
CN108432208A (zh) 2018-08-21
WO2018107442A1 (zh) 2018-06-21
EP3544260B1 (en) 2021-09-22
CN108432208B (zh) 2020-02-21
EP3544260A1 (en) 2019-09-25
EP3544260A4 (en) 2019-11-06
US20190306256A1 (en) 2019-10-03

Similar Documents

Publication Publication Date Title
ES2898050T3 (es) Método y dispositivo de disposición de servicios, y servidor
US11698780B2 (en) Deployment and configuration of an edge site based on declarative intents indicative of a use case
US11611487B2 (en) Model driven process for automated deployment of domain 2.0 virtualized services and applications on cloud infrastructure
Brogi et al. QoS-aware deployment of IoT applications through the fog
WO2018213991A1 (zh) 网络切片创建的方法、装置以及通信系统
US9634900B2 (en) Declarative approach to virtual network creation and operation
US9537717B2 (en) Policy enforcement point provisioning
Zhao et al. A software workbench for interactive, time critical and highly self-adaptive cloud applications (SWITCH)
Rusti et al. Smart city as a 5G ready application
Thanh et al. Embedding security and privacy into the development and operation of cloud applications and services
Khan et al. Generic intent-based networking platform for E2E network slice orchestration & lifecycle management
Casola et al. MUSA deployer: Deployment of multi-cloud applications
Casellas et al. Metro-haul: SDN control and orchestration of disaggregated optical networks with model-driven development
Štefanič et al. Non-functional requirements optimisation for multi-tier cloud applications: An early warning system case study
Mechtri et al. Agile service manager for 5g
Képes et al. Integrating IoT Devices Based on Automatically Generated Scale-Out Plans
Solayman et al. Portable Modeling for ICU IoT-based Application using TOSCA on the Edge and Cloud
Zimmermann et al. Deployment enforcement rules for TOSCA-based applications
JP2017220240A (ja) ネットワーク制御システムのためのグラフィカルポリシインタフェース
Garrich et al. Network optimization as a service with Net2Plan
Willocx et al. QoS-by-Design in reconfigurable IoT ecosystems
Wenger et al. Model-driven engineering of networked industrial automation systems
Kridalukmana et al. Iot microservice architecture for iotaas device users
Akue et al. Integrating an online configuration checker with existing management systems: Application to CIM/WBEM environments
Filiposka et al. Transforming silos to next-generation services