Author: Tea Kolevska

Rating, charging and billing for the clouds – Cyclops demo

In the past few months, the ICCLab has been developing a generic rating-charging-billing engine that would offer cloud service providers a modular framework that enables dynamic pricing activities and distributed design. The model closely follows the general accounting process, in the same time providing a lot of flexibility due to the loosely-coupled design. The platform is currently being developed in Python on top of OpenStack using its Ceilometer component for collection and extraction of the metered data. To enable this facility, we have created a custom Ceilometer client that uses REST APIs to get the needed data records. The key architectural components are:

  • Mediation module: The data coming from the monitoring devices needs to be combined in a single user session and transformed in a common format.
  • Charging module: The rating engine collects the usage records and applies the appropriate pricing strategy.
  • Billing module: The basic billed amount in a billing cycle is generated by aggregating the charge records and readjusts it by applying discounts, penalties, taxation etc.
  • User/Management interface: The service can be accessed by a web-based user-interface that allows configuration of every aspect of the RCB process.

In the video below, a demo of the first Cyclops prototype is being shown. In the scenario, we take a look at the basic admin features: listing all the tenants and their respective users, checking the user status, calculating the accumulated cost per user, as well as starting a periodic counter for the specific user. The facility for defining the pricing function for a particular user, allows the admin to choose some of the available meters and apply standard arithmetics to get the desired formula.

This is the first prototype for our RCB solution. In future, the platform would offer more advanced rating and charging models with the support for discounts, taxation, penalties etc, as well as support for other cloud platforms.


Introduction to MuleSoft

Being part of the Service Prototyping lab, the ICCLab teaches the Service Engineering course at ZHAW. As part of that course was a lecture on MuleSoft, a tool that facilitates the data exchange between applications following the service-oriented architecture (SOA) methodology. It was developed to take the donkey-work out of the integration process, allowing developers to connect anything, anywhere. Because it “carries the heavy development load” of connecting systems, it is also sometimes referenced as a Swiss army knife. Mule differs from the typical web application servers by specializing in integration between different applications, databases and cloud services, as opposed to integration with just the end users. Mule applications are also stateless and event-driven.

MuleSoft is an integration platform that consists of CloudHub and Mule ESB. CloudHub is an integration platform as a service (iPaaS) that connects SaaS and on-premise application. It allows cloud to cloud integration as well as cloud to enterprise integration. MuleESB on the other hand, is Java-based enterprise service bus for building and running integration applications and web services. It offers service meditation by separating business logic from protocols and message formats, message routing and data transformation. Most importantly, it provides service creation and service orchestration. It allows the functionalities in any endpoint to be exposed as a service and existing services to be hosted as a lightweight service containers.

To facilitate the access to MuleESB’s functionalities, there is Mule Studio, an Eclipse-based integration development environment that can be used as either a visual, drag-and-drop editor or just a simple XML editor. Because Mule is also based on the concept of event-driven architecture, you can use MuleStudio to create an application that processes messages by forming a flow. The Mule flow is actually a sequence of message-processing events constructed by combining several building blocks which are pre-packed units of business logic. Each building block in the flow evaluates or process the message until it has passed through all the building blocks in the flow. Mule receives the message through a request-response inbound endpoint, transforms the content into a new format and process the business logic before returning a response via the message source.

The Mule flow typically consists of a message source, message processors and some global elements. The message source accepts a message from an external source, thus triggering the execution of the flow itself. The message processors transform, filter and enrich the message, while the global elements are reusable pieces of code that can be invoked by multiple elements in any flow within the application. The Mule message is the data that passes through the application via one or more flows. It consists of a message header that is the meta data about the message, and message payload, the actual data content that is being transported through the Mule application. Mule uses the Mule Expression language (MEL) to facilitate the transport of the Mule message. In the final stages, a response is returned to the original sender or the results of the processing are logged to a database or send to a third party.

For example, lets say that a company has a shipping and a billing service which now need to connect to an inventory system. Writing the code manually may work for the time being, but suppose we want to make a few changes in the future. Or connect to a third party SaaS app. We will then have to update every connection. Instead, Mule can transform the different data formats and act as a translator between them.

To sum up, what Mule basically does is enabling the integration between the SaaS and on-premise applications, eliminating point-to-point connections and taking out the need to worry about the different data formats.

Tea Kolevska

Tea KolevskaTea Kolevska is doing a six month traineeship in the cloud computing lab as part of the IAESTE program for exchange of students for technical experience. She is a bachelor student at the Faculty of Electrical Engineering and Information Technologies in Skopje, Macedonia, majoring in Informatics and Computer Engineering. During her stay, she is working on the Rating, Charging and Billing project for the clouds, developing the ICCLab’s Cyclops solution.