Familiar Bedfellows | The Automation engine, Model Driven Engineering and Victorian buildings (Part 2)

In this blog post, (you can read part one here), we will move back to S-CASE and the way MDE is utilised so as automated construction of RESTful Services is achieved.

In the S-CASE MDE engine, we encounter all the four discrete software construction stages that the 19th century civil engineer had to go through in order to build a Victorian house. These four phases of MDE have been already presented in part one. Only now, the S-CASE MDE engine does not build Victorian houses, but software of a particular architectural style.

The style that S-CASE follows for the web services it produces, is the REST architectural style (instead of the Victorian Style), enhanced with some design patterns and concepts. But what is REST anyway? It is a software architectural style for the web, which Roy Fielding introduced in 2000. In the same way the Victorian style has some characteristics like steep roofs, sash windows etc. that differentiate it from others, REST has some distinct properties as well (figure 1):

scasepic1

Figure 1: Image courtesy of http://martinfowler.com/

  1. Every RESTful web service (house) comprises only of resources (rooms)
  2. Each such resource has a unique URI (address) at which it is accessible.
  3. Every such URI is accessed with the common HTTP verbs. In contrast to other styles though, the HTTP verbs are used in the intended way. In any case, the POST HTTP verb is used to create a new resource, the GET verb is used to retrieve an existing resource, PUT is used to update an existing resource and DELETE to delete one.
  4. The resources are interconnected with hypermedia links.

The hypermedia links are probably the property that differentiates REST the most from other styles. But what are these links for? They are pretty much the same thing with the navigation arrows in an old-fashioned adventure video game similar to the one shown in figure 2. In this case, no matter wherever you are in the house (web service), you are always given the next possible actions. This means that you do not have to know them a priori, which in turn increases a lot the flexibility of the interaction between web services and clients. In this example, you may open any of the three doors, follow the corridor or go up the stairs. However, you absolutely have to take one of these specified actions! Thus, you may not stand in front of the painting on the wall to take a look! That is, should there exists a bedroom door upstairs, you may not open it from the position shown in figure 2. Instead, you first have to go up the stairs following the provided link and then open the door by using the link that you will be given once you go up the stairs.

Furthermore, the S-CASE’s MDE engine embeds to the REST style some more design patterns. One may think of them as additional decorations in every room other than those already introduced by the Victorian style. For example Model View Controller (MVC) is used in order to further apply the divide and conquer as well as the separation of concerns design principles. Additionally, the repository pattern is used to offer a uniform way to store stuff. This is like every Victorian house also had a storekeeper. That way, whenever anyone living in the house wants to store something in the warehouse, does not have to know where to store it (or from where to retrieve it). He simply gives it to the storekeeper instead.

scasepic2

Figure 2: Image courtesy of www.geffrye-museum.org.uk

So, how would a conversation be between a modern times customer, who wants to buy an e-shop service, and an MDE engine that knows how to build RESTful web services? The customer would probably say to the MDE engine what that service (house), which he wants to buy, should have. In particular, he could ask for some specific resources (rooms), like user accounts, user profiles, product inventory, the capability to pay with credit cards, search the products database or even have email notifications enabled. Additionally, he would probably ask for some properties to be added to those resources. For instance, he may ask that the user profile should contain some text placeholder where the user can write a description of himself. Moreover, the user accounts should have a username, a password and an email. Lastly, the product inventory should have a price and a textual description for each product. Once the customer specifies his needs to the MDE engine, the e-shop web service CIM is formulated.

One should recall at this point that like in the case of Victorian houses, nothing that has to do with software architecture, design patterns or even programming languages and web frameworks is discussed yet. At this initial stage of MDE that S-CASE goes through, only concepts of RESTful web services domain are examined, like resources, their relations and/or some properties of them, period!

From this point on, the MDE engine of S-CASE begins to apply the REST architectural style as well as the extra design patterns to every single concept that its customer included in CIM. For instance, the MDE engine would add to all the resources specified in CIM a controller entity that will handle all the incoming web requests with some type of protocol. Then, it would assign to each one of them a unique URI and input/output representation handlers of some type. Moreover, it would design an RDBMS database schema of some type that is sufficient to store the envisioned e-shop’s data, which is going to be accessed in a uniform way by means of a repository controller. Once the MDE engine transforms every single CIM concept by applying to it the described architectural style, the envisioned e-shop’s PIM is formulated. It must be stressed though, that likewise the Victorian house engineer did not specify the exact make of the materials, the MDE engine does not specify any specific technologies to be used at this point either. Instead, it used an abstract generic form of each of them (some type of protocol, some type of database schema etc.).

Similarly to the Victorian house case, the next step is to pick specific technologies (materials) with which the service will be constructed. In the S-CASE MDE engine for example, one possible combination of technologies could be the JAXB framework to handle the parsing and marshaling of incoming/outgoing representations, the JAX-RS one to handle incoming web requests of the HTTP 1.1 protocol, the Hibernate one to handle RDBMS database schema of (for example) POSTGRESQL and the Java language as the language to code the envisioned service. Once MDE engine applies a specified technology to every PIM component, the e-shop PSM is formulated. Of course, there could be many other combinations of technologies that could be used to form different PSMs. Other customers might choose another one from the available ones! Similarly to the Victorian house case and in any case, the relationship between PIM and PSM is always one PIM to many possible PSMs.

At this point, the appropriate, for the selected PSM, code generators (specialized builders of a Victorian house) write the actual software code. Once this is done, the process of building the e-shop RESTful service ends. Of course, like in the case of Victorian houses, some resources will end up to be fully implemented (fully built and decorated rooms), whilst some others will need some additions so as to be completed or there may be even some resources that are simple wrappers (empty rooms) interconnected with the other resources of the service. Such resources would require human developer intervention to get completed pretty much like the Victorian house garden would need a gardener to plant some flowers etc. to it.

Summing up, S-CASE utilizes MDE to automate the procedure of building RESTful web services. Once S-CASE parses the multi-modal requirements (UML diagrams, semi structured text etc.), it attempts to understand the needs of its “customer” in order to formulate the CIM. Later on, it applies the REST architectural style to transform the CIM to its according PIM. Then, according to user preferences, it transforms the PIM to one of the possible PSMs and finally, it initiates its code generator to produce the actual service code. The crucial point to stress one more time though, is that this process is an automated one. So the customer that “told his needs” to the MDE engine of S-CASE by providing his multi-modal input, would then get back the according RESTful service automatically and instantly.

This pretty much concludes the demonstration of the way the S-CASE’s MDE engine builds a RESTful service. At this point many possibilities arise. Which should be the acceptable concepts in CIM? What should be the enforced design of the PIM etc. Such issues will be discussed in the next entries related to meta-model engineering and automation trade-offs within the S-CASE MDE engine.

Read part one of this series.

Leave a Reply

Your email address will not be published.