Servicio de facturación en la nube

Un módulo de servicio de facturación habilitado por SOA para el entorno en la nube

La facturación en la nube es un proceso que consiste en generar facturas desde datos de uso de recursos mediante un conjunto de políticas de facturación predefinidas. El autor define un módulo de servicio de facturación en la nube habilitado para una arquitectura orientada en el servicio que cubre tanto los requisitos funcionales — un servicio de cotización, funciones de conversión y políticas, esquemas de pago y la identificación del usuario — y los requisitos no funcionales, pero esenciales, como la seguridad, la escalabilidad, los estándares y la tolerancia a fallas.

Hans-Dieter Wehle, Especialista TI distinguido, IBM

Hans-Dieter WehleHans-Dieter Wehle es un especialista en TI distinguido para cómputo en la nube de IBM. Es asociado de IBM R&D Design Center en Boeblingen, Alemania, y tiene más de 20 años de experiencia en la industria de la informática, desde soporte de campo hasta desarrollo de software y consultoría. Wehle forma parte de IBM R&D desde 1999. A partir del 2006, se focalizó en TI ecológica y en soluciones de informática en la nube, y participó en varios proyectos de desarrollo de IBM.



17-12-2012

Desarrolle habilidades de este tema

Este contenido es parte de knowledge paths progresivo para avanzar en sus habilidades. Vea:

El propósito de tener un componente de facturación optimizado para la nube es capaz de brindar una interfaz para generar facturas de uso. La facturación en la nube es un proceso que consiste en generar facturas desde datos de uso de recursos mediante un conjunto de políticas de facturación predefinidas. La factura puede ser para dinero real o puede referirse a una noción más abstracta de intercambio, según sus propias políticas generales de computación en la nube — no importa porque el servicio de facturación no especifica el uso de un modelo económico específico.

Este artículo proporciona una guía rápida de cómo definir un módulo de servicio de facturación en la nube designado para un entorno de arquitectura orientado al servicio. Abarca requisitos funcionales como servicios de cotización, funciones y políticas de conversión, métodos de pago y cuestiones de identificación de los usuarios. También cubre los requisitos no funcionales esenciales como la seguridad, la escalabilidad, los estándares y la tolerancia a fallas.

Partes de un módulo de servicio de facturación en la nube

Primero, voy a aclarar la arquitectura de este módulo de facturación para la nube. Luego, explicaré el pensamiento que sustenta esta política de facturación y el idioma y la sintaxis que se utilizan. También cubriré el motor de reglas/inferencia y el rol que cumplen. Finalmente, concluiremos esta sección con una rápida discusión sobre el flujo de trabajo y la resolución de conflictos.

El módulo de trabajo: La forma sigue a la función.

El módulo general del servicio de facturación en la nube debería brindar tipos de puertos para dar soporte a todos sus requisitos funcionales (descritos en la sección siguiente):

  • El servicio de facturación genera facturas según las políticas que obtiene del Repositorio de Políticas de Facturación.
  • Estas facturas se almacenan en el Repositorio de Facturación para que el gestor pueda utilizarlas más tarde.

La Ilustración 1 muestra la arquitectura general de los servicios contables y de facturación.

Ilustración 1 La arquitectura del módulo
The architecture of the module

El proceso de generación de facturas no es automático y necesita que lo inicie el gestor. Todas las funcionalidades del servicio se implementan en un servicio web.

La ilustración 2 muestra el módulo desde un punto de vista tecnológico e ilustra varios componentes secundarios y la interacción entre estas diferentes tecnologías.

Ilustración 2 El módulo desde el punto de vista tecnológico
the module from the technology point of view

El servicio de facturación establece la conexión entre el servidor web a través de la interfaz PHP y obtiene el documento de registro desde el Repositorio de Registro de Uso (UR).

Políticas de facturación, sintaxis de facturación, idioma

Un ejemplo simple de una política de facturación es similar a las aclaraciones siguientes:

  • 1 CPU/h (horas de uso) es equivalente a 1 token
  • Descuento del 20 por ciento para CPU/h superior a 20 h

Sin embargo, más allá de que sus políticas de facturación sean simples o complejas, habrá un momento en el que el gestor de recursos querrá modificarlas. Capturar cada caso es casi imposible y cambiar el código de origen cada vez que añada nuevas políticas, por supuesto, no es factible.

Es importante hacer una distinción clara entre la lógica informática que computa la factura final y las políticas de facturación que establecen los lineamientos sobre cómo generar una factura. Las políticas de facturación no son parte del servicio; constituyen un elemento externo que utiliza el servicio de facturación. Las redacta el gestor de recursos y se almacenan en un repositorio. El servicio de facturación utiliza este repositorio para extraer los lineamientos necesarios para generar la factura final.

Suponga que quiere formalizar las dos políticas que mencioné como ejemplos. Es posible crear algo como lo siguiente: (cpu_h(x) sería los números x de las horas de CPU y token(x) sería los números x de los token, entonces

(1)# bill = token(cpu_h(x));
(2)# if 
         cpu_h(x) > 20
     entonces
         bill = bill*.8;

Esta notación capta ambas políticas. Sin embargo tiene dos problemas principales:

  • No es un lenguaje natural.
  • No puede capturar todos los casos.

Recuerde, la persona que establece las políticas de facturación necesariamente no debe ser un programador y que escribir dicha notación puede ser un dolor de cabeza. Es mucho más fácil y natural expresar las políticas de facturación en un lenguaje más natural que esta notación.

El segundo problema es que es muy difícil expresar un amplio intervalo de políticas complejas al utilizar esta notación. Las normas comerciales pueden cambiar bastante rápido y las normas de facturación necesitan adaptarse a ellas. La anticipación de un requisito de una política futura puede solo realizarse mediante el uso de una sintaxis robusta de normas.

También hay diferentes tipos de lenguajes utilizados para describir las políticas; cada uno tiene sus propios beneficios y desventajas.

Un lenguaje natural permite la expresión de normas en inglés sencillo:
Cuando el evento es una Asignación VM y el tipo de cliente es Platino, el costo por segundo es de 0,0002 euros.

El lenguaje natural es fácil de utilizar y tiene una curva de aprendizaje llana. Este es más atractivo para los usuarios de computadoras no avanzadas.

La misma descripción de la política en un lenguaje específico de dominio (que utiliza la misma sintaxis y semántica utilizada en el documento de especificación) se ve de la siguiente manera:
EVENT = "VM Assignment", CLIENT_TYPE = "Platinum", RESOURCE_TYPE = "BLADE Type 4", RESOURCE_AGE > 240 * 60 * 60 (seconds), SERVICE_LEVEL = "Platinum", COST_PER_SECOND = 0.0002 (Euros, Pounds, etc.)

El lenguaje específico del dominio es más estructurado y más fácil de realizar ediciones rápidas y cambios que el lenguaje natural.

Más sobre el encadenamiento hacia adelante

El encadenamiento hacia adelante o la interfaz basada en datos (basado en la regla de inferencia modus ponens: Si P, entonces Q; P es real, entonces Q es real) es uno de los métodos principales de razonamiento cuando se utilizan las normas de inferencia, las normas sintácticas o funciones que toman premisas y retornan una conclusión. El encadenamiento hacia adelante comienza con los datos disponibles, proyecta los intentos futuros para extraer más datos (nuevos) hasta que alcanza el objetivo. (El otro método es el encadenamiento hacia atrás donde usted inicia el objetivo y el trabajo retrocede para ver si los datos más en detalle son compatibles con el objetivo; ambos se basan en la regla modus ponens, pero BC se considera una inferencia basada en el objetivo.

Una ventaja del encadenamiento hacia adelante en comparación con el encadenamiento hacia atrás es que la recepción de los nuevos datos puede desencadenar nuevas inferencias; esto hace que el motor esté más preparado para las situaciones cuyas condiciones podrían cambiar.

El motor de reglas/inferencia y su rol

El motor de reglas/inferencia es parte del sistema que evalúa las normas basadas en el estado del sistema o entrada de datos del usuario. Tener una sintaxis de la política no es suficiente: Usted también necesita un mecanismo para hacer valer la política y para evaluarla. Este es el objetivo para el cual se diseño el motor de reglas.

El motor que estoy describiendo es un motor de reglas de encadenamiento hacia adelante al utilizar una implementación avanzada del algoritmo Rete. En esta etapa en el desarrollo, mis colegas y yo nos encontramos en el proceso de evaluar varios motores de regla y dos llamaron nuestra atención:

  • ACEL desde IBM (Lenguaje Autónomo de Expresión Informática) se desarrolló inicialmente como una parte del Lenguaje de la Política Informática Automática para describir las condiciones cuando una política debería aplicarse al sistema gestionado.
  • Para utilizar los estándares de la industria, tiene que utilizar la API del Motor de Regla (JSR94) de Java™ como interfaz de programación.

Las Reglas de Facturación se ingresan y modifican mediante un extremo frontal web simple. Observe la estructura del motor de reglas/inferencia.

Ilustración 3 Motor de reglas/inferencia
The rules/inference engine

Más sobre el algoritmo Rete y la coincidencia de patrones

El algoritmo Rete (que se pronuncia REY-tii o Rii-tii) es un algoritmo de coincidencia de patrones para el desarrollo de sistemas de reglas de producción que ha evolucionado para muchos shells de sistemas expertos populares. Rete proviene del latín red.

El algoritmo Rete sacrifica el uso de la memoria para aumentar la velocidad; pulsa una implementación más lenta de verificación de datos a reglas (verifica si los datos coinciden con las reglas > si no coinciden, lanza la regla y, si coinciden, mantiene la regla > regla siguiente > bucle de retorno para el inicio de las reglas) al desarrollar una red (la parte "Rete") de nodos en los cuales cada uno corresponde a un patrón en la parte condicional "si" de una regla. Lo que hace el Rete es almacenar información de "datos a hechos" en la memoria en funcionamiento. A su vez, esto permite a los sistemas compartir datos en los nodos para eliminar algunos tipos de redundancias; almacenar coincidencias parciales cuando se unen a diferentes tipos de hechos (lo que evita que el sistema tenga que volver a evaluar todos los hechos cuando se realizan cambios; deshacerse de elementos de la memoria de forma eficiente cuando los hechos se eliminan de la memoria en funcionamiento.

El proceso que consiste en hacer coincidir los hechos nuevos o existentes frente a las reglas de producción se denomina coincidencia de patrones. Existe una cantidad determinada de algoritmos que se utilizan para la coincidencia de patrones mediante los motores de reglas. Las reglas se almacenan en la memoria de producción y en los hechos que el motor de inferencia hace coincidir con la memoria en funcionamiento.

Los hechos se insertan en la memoria en funcionamiento donde se los modifica o se los retrae. Un sistema con una gran cantidad de reglas y hechos podría producir que muchas normas sean reales para la activación del mismo hecho; se considera que estas normas entran en conflicto. La agenda administra el pedido de ejecución de estas reglas en conflicto al utilizar una estrategia de resolución de conflictos.

El flujo de trabajo y la estrategia de resolución de conflictos

Flujo de trabajo se refiere al orden precedente de las reglas cuando se las evalúa (¿Qué regla debería evaluarse en primer lugar?). La resolución de conflictos hace referencia a qué regla eliminar si más de una prueba ser real. Esos dos puntos son importantes y tienen que estar presentes en un módulo de servicio de facturación exitoso.

A continuación, pasemos a una discusión concisa sobre los requisitos funcionales.


Requisitos funcionales de un módulo de facturación

Ahora, voy a detallar de forma sucinta los requisitos funcionales a tener en cuenta en un módulo de facturación en la nube.

Servicio de cotización

La instancia de intermediación en la nube debería soportar un servicio de cotización para permitir a los usuarios solicitar cotizaciones antes de utilizar un recurso. Por ejemplo, "¿Qué me cuesta ejecutar tal y tal en un sitio informático?" La cotización no debería ser obligatoria y debería tener validez solo por un breve periodo de tiempo.

Función de conversión y políticas

La instancia de intermediación en la nube debe implementar una función de conversión que convertiría de un registro de uso a una moneda mediante un esquema básico de conversión — como costo de 1CPU/h = 1 token, por ejemplo — y negociar el valor monetario del token según el modelo económico y la demanda. La instancia de intermediación en la nube debería permitir al propietario del recursos brindarla con modelos de conversión personalizarlos para satisfacer mejor sus intereses.

Proceso de identificación del cliente (entidad)

La instancia de intermediación en la nube debe permitir la identificación de la entidad a la que se cobrará por el uso del recurso. Un usuario puede pertenecer a una organización virtual diferente y ejecutar varios trabajos. En este caso, es importante identificar a quien pagaría por cada trabajo. También puede pasar que un trabajo se pague desde distintos presupuestos según el dinero disponible, por ejemplo.

Funciones y políticas de los esquemas de pago

La instancia de intermediación en la nube debe soportar, al menos, un esquema de pago. Algunos ejemplos permiten un pago posterior, un pago por adelantado (en el momento de la reserva, por ejemplo) o un esquema de pagos continuos.

El servicio en la nube debería ser flexible en términos del establecimiento de precios del tema (que puede cambiar con el tiempo) o debería tener tarifas diferentes como una tarifa de uso, una tarifa fija, tarifas extra ordinarias o bonificaciones. Por ejemplo, una política puede verse de la siguiente manera:

EVENT = "VM Assignment", 
CLIENT_TYPE = "Platinum", 
RESOURCE_TYPE = "BLADE Type 4", 
RESOURCE_AGE < 240 * 60 * 60 (seconds), 
SERVICE_LEVEL = "Platinum", 
COST_PER_SECOND = 0.0002 (Euros)  

EVENT = "ONE_OFF SERVICE 1", 
RESOURCE_TYPE = "BLADE Type 4", 
ONE_OFF_COST = 1

Requisitos esenciales, pero no funcionales

Para abordar los requisitos esenciales no funcionales para el módulo de facturación en la nube, el módulo debería procesar, al menos:

  • La capacidad de hacer sus transacciones seguras.
  • La autenticación basada en roles.
  • Rastreos de auditoría para permitir el análisis de la actividad.

En concreto, debe llevar a cabo los pasos para evitar que clientes sin autorización o impostores envíen eventos o generen un proceso de facturación sin la autenticación o el permiso adecuado.


En conclusión

Al detallar la anatomía de un módulo de facturación en el entorno de la nube, pudo apreciar algunas de las consideraciones a tener en cuenta cuando planifique desarrollar su propio módulo. Expuse una visión de cómo el módulo encaja con los servicios de contabilidad y facturación, y cómo encaja en la infraestructura total en la nube. Pudo apreciar ejemplos de políticas de facturación, sintaxis y lenguaje, y pudo conocer con más detalles cómo funciona el motor de reglas/inferencia. También expuse una lista de verificación de los tipos de requisitos funcionales par un módulo de facturación y los requisitos esenciales no funcionales que también necesita tener en cuenta.

Recursos

Aprender

Obtener los productos y tecnologías

  • Vea las imágenes de productos disponibles en IBM Smart Business Development and Test en la nube de IBM Cloud.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing, SOA y servicios web
ArticleID=852011
ArticleTitle=Servicio de facturación en la nube
publish-date=12172012