S-CASE Blog | wapo.io in the Game of RESTful Application Development

In today’s blog Marina Stamatiadou talk about Lego. And S-CASE, of course, with the focus on how both Lego and Software Services need flexibility to produce the desired effect.

Everyone knows Lego! Lego bricks can be assembled and connected in many ways to construct several objects like vehicles, buildings, decorations, and even working robots. Anything constructed can be taken apart again and the pieces can be used to make other, completely different objects. The core idea of Lego is that “any piece can be combined with any other piece”[1].

Lego, Ice Cream and S-CASE: what’s not to like?

Lego, Ice Cream and S-CASE: what’s not to like?

In the software world things can be quite similar, as one can create multiple software components and execute them in such a way which produces the desirable result. However, this approach is very abstract while reality is far more complex. Software components are not always standalone and they might have more than one entry points. The most common example comes from the object-oriented software engineering. In this paradigm class methods can be called multiple times from one or more classes and execution order is not sequential neither follows one and only pattern.

On the other hand, there comes the REST approach which tries to overcome complexity in the field of web applications. REST defines a set of architectural principles by which you can design web services that focus on a system’s resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages.[2] REST services are simple, standalone and dedicated to satisfy a specific functionality.

But, can one combine the core object-oriented principles with the RESTful approach? How? And what will the result be? The wapo.io team will give the answer to this question by creating a software platform that will address both end-user’s and developer’s energy-related needs. The main idea came from the fact that, today, there is a big variety of energy management software applications that provide end users with useful energy-related analytics while there is also an increasing number of energy-management APIs that facilitate the job of developers who work in the respective domain. However, there is still a gap filling these two approaches. wapo.io will be the bridge to fill in this gap and to create the appropriate “Lego” infrastructure.

wapo.io consists of a number of simple, standalone REST services which can be considered as construction Lego bricks. Each one is dedicated to serve a specific need and has its well-defined I/Os to enable seamless communication with other Lego-like wapo.io REST services. The main idea is that REST services can be called one after the other, in a serial execution order, connecting different software Lego bricks together in order to achieve a more complicated functionality. For example, let’s assume that we have the set of REST services shown in Table 1 available:

  • Domain/Area Service Name Service Description
  • Validation OutOfLimitsValidation Checks if the processed data file contains meter values that are out of limits
  • Validation WrongDateFormatValidation Checks if the processed data file contains dates that have a wrong format
  • Validation UndefinedPointValidation Checks if the processed data file contains meter (point) that is not defined
  • Analytics CalculatePerAreaConsumption Calculates the per m2 consumption
  • Analytics ConsumptionThresholdExceededAlert Checks if a consumption threshold has been exceeded
  • Visualization TicketGeneration Generates a new notification (ticket)
  • Visualization ChartGeneration Generates a new chart

The services given in Table 1 can be executed in several ways, depending on the desirable functionality. As a result, one developer can exploit all the available options, creating software that validates incoming data files, runs a set of analytics algorithms and produces a chart that outlines the respective findings. Another developer can make use of less lego-like services and create software that just validates incoming data files. A third developer can only check incoming data for valid date formatting and then create a chart for data visualization.

The options are many and the advantage is obvious! What is hidden behind this idea is S-CASE which enables fast prototyping and development of our main constructive blocks, the RESTful Lego bricks, while also facilitating their orchestration. The service composition becomes an easy job for developers that do not have much experience, like the Lego construction is easy and fun for kids! Using S-CASE has made it quick and easy to create functional services that will enrich the wapo.io directory and offer more opportunities to wapo.io’s customers.

[1] http://jakob.engbloms.se/archives/1806

[2] http://www.ibm.com/developerworks/library/ws-restful/

Leave a Reply

Your email address will not be published.