Last updated: 26 Jan, 2021
When people hear for the first time that Xsemble enables building applications from smaller building blocks, they wonder if these blocks are microservices. Well, Xsemble components are much tinier than microservices, and can in turn be used for creating microservices. Further, the powerful capabilities built into Xsemble make it a great choice for creating microservices. This is a 2 part blog article to show how. We shall be referring to a demo application that is supplied with Xsemble version 2.5.2, namely “Demo8.Microservices”.
Microservices and Xsemble Components
Microservices
As we know, microservices is a way to achieve what is known as Z-axis scaling, a way to decompose a larger application based on business functions. These microservices are separate deployables which collaborate with one another using standard mechanisms like HTTP. The number of microservices that constitute one application is typically small, because of the added complexity and performance overheads (reference1, reference2). Indeed, it becomes newsworthy when this number is high, as is the case with the Netflix architecture.
This separation of deployables allows separation of the development teams. The development teams agree on the interfaces exposed by the various microservices using which they will be able to collaborate, and then get into developing the microservices independently. This helps them break the inter-dependencies which would have happened if they were one single team developing a single monolithic application having all the functionalities.
Xsemble Components
As said before, Xsemble components are a much tinier decomposition of applications. To understand how tiny they are, imagine the usual functionality of login which is common across web applications. User has a login page, and the login id and password entered are validated on the server. In this example, the login page and the login validation functionality are represented by different Xsemble components. This is a very fine granular decomposition at the tiniest level — we call it a molecular level decomposition.
At this granularity, an application can easily have hundreds or thousands of Xsemble components. The communication between the components is lightweight — mostly with in-process calls, thereby alleviating parsing and communication overheads. The complexity part is taken care of by the visualization provided by the Xsemble flow diagrams. If a flow diagram starts growing in complexity, one can use logical grouping of components into separate repositories and the top-down decomposition of functionality into projects and subprojects. Xsemble flow diagrams for some complex business processes developed by college students can be seen here, here and here.
The advantages of separation of concern during the development and maintenance are stretched much further, with the development happening at component level. The decomposition of teams gets further granular to the level of individual programmer. Each programmer can operate independently, delivering the components assigned to them. Xsemble makes this easy by generating template code from the definition of a component. This template can be shared with a programmer for coding in the business logic of a component. Towards this point, consider the below example.
Example of a Code Template
The figure below shows the “Template & Implementation” dialog for the “Remove Item From Cart” component in the “Demo8.Microservices” repository (included within Xsemble), where the generated template for a component is seen on the left side and the implementation code on the right. The marked areas show how a programmer has added the implementation code within the template.
As one can see, the generated template code contains comments to guide a programmer.
Why Implement Microservices with Xsemble
Having seen that the decomposition into Xsemble components is at the tiniest molecular level, it follows logically that a microservice may be composed out of assembling Xsemble components.
Indeed it can be, and there are some good reasons for doing so:
- Ease of Refactoring: During the development of a microservices-based application, one comes across situations where some functionality included in one microservice is found better suited in another microservice, or qualifies to be a separate microservice. In a Xsemble implementation, this refactoring is achieved much easily at the component level with visualization, as opposed to doing it at code level as is usually done.
- Scalability of Development: As mentioned above, you can achieve a parallelism in development of components. Individual programmers being able to churn out component implementations in isolation goes well with #RemoteWorking. Further, if your project is falling behind in schedule, you have the option to utilize bench resources or freelancers to implement some components.
- Code Reuse: Xsemble makes it easy to create reusable components. Its reference guide (that comes with the product) has a full chapter devoted to reusability. With reusable components, you have less to code and less to test. This further means lower risk and faster time to market.
End-to-End Application Flow
Life becomes even more interesting when all the microservices that compose an application are created with Xsemble as a single flow diagram. (This single flow diagram could be contained in a single Xsemble project, or logically grouped into projects/subprojects to manage complexity.) The end-to-end flow — across these microservices — now becomes available for visual inspection. Isn’t that wonderful? The orchestration of the working of different microservices is conventionally seen as a headache (and a bottleneck in using number of microservices). This ability of end-to-end visualization eliminates it completely.
To see this in action, let’s look at an example.
Example
Let’s look at the Demo8.Microservices project with the Layerwise node coloring scheme. The project is a mini version of an e-commerce site where you see a list of mobiles and add some to the shopping cart. (We shall see it in more details in part 2.) It is implemented as two microservices: one for ordering and the other for shopping cart. Without any background information, do you notice the two layers distinctly in the following figure? One has to be really blind not to.
Mind you – although it is so much expressive, it is not just a pretty picture. It is the accurate representation of a working application.
Let’s understand this a little further.
Every Xsemble project has architectural layers, or simply layers, defined within it. A layer in turn corresponds to a supported platform. A simple web application has two layers: the web layer (supported by a web browser) and the other is the server layer (supported by a web server). Microservices are basically distinct server layers. Our Demo8.Microservices application has the following three layers:
- Web Layer: On the web browser. Characteristic color chosen as cyan.
- Ordering Layer: A server layer corresponding to the ordering functionality. Characteristic color chosen as light yellow.
- ShoppingCart Layer: A server layer corresponding to the shopping cart functionality. Characteristic color chosen as light purple.
Notes:
- The diagram shows some nodes with a specific page-like shape with a gradient background color. The shape indeed indicates Page nodes, and the color gradient shows that they get formed in one of the server layers and then transition to a web layer.
- The diagram also shows some circles with a gray background. Circles represent data nodes. The ones with the gray background are transient, in the sense that they represent inter-layer data and hence do not belong to any particular layer.
To give a reader a better feel of how a layer is defined, the “Edit Layer” dialog for the ShoppingCart layer is shown below:
In an Xsemble flow diagram, gray arrows represent the execution flow and dashed blue arrows represent the data flow. The Demo8.Microservices flow diagram presented above can be used to trace the execution flow of the application as it starts with the Ordering layer nodes (light yellow background) and then gets to the ShoppingCart layer nodes (light purple background). With a little more knowledge of what those various node shapes correspond to, one can get complete details into the internal working of the complete application –within each microservice and across– from the flow diagram.
Summary
Xsemble components offer a very granular (molecular) decomposition of a software application. The benefits of using microservices are therefore amplified multi-fold in an Xsemble based application.
It is possible to use Xsemble to implement one or more Microservices that constitute an application. This gives you extra benefits such as ease of refactoring, scalability of development and code reuse. Further, if microservices interacting with one another are implemented with Xsemble, you can get a great visibility into the functioning across microservices.
In part 2, we shall take a detailed look at the interaction points. We shall see how the reusability mechanisms inbuilt into Xsemble make your microservices application robust even in the face of API changes.
