Hello code lovers:
Recently, I was involved in a project that consisted of legacy application modernization and migration (e.g. Delphi, Fortran, C# desktop-based applications) to java web-based applications. We began with the idea of creating java web applications using Spring and in the backend using a persistence framework or JDBC (Java Database Connectivity) that only returns data. These two tools would produce two different WAR (Web Application ARchive) files, one for the UI and one for the backend, that “talk” to each other via JSON.
In summary, we have N web applications running into an application container; Liferay in our case. (I will not cover Lifefray in this post). If we follow SOA (service-oriented) architecture in the application-to-UI interaction; why not use SOA architecture in the application-to-backend interaction? Here is where WSO2 SOA middleware comes in handy.
To understand the usefulness of WSO2 SOA middleware, let’s look at a possible scenario of how to use the Data Services Server. We start with N web applications that do a pre-load process that fill-up a drop-down list in the user interface. The application has on its DAO layer the required implementation to obtain the data from the database. The application N+1 will do the same, N+2 as well and so on. They all follow the same pattern, but they have their own implementation replicated on each web application. If they all follow this order, why not expose that data as a web service? Then, all applications that need to fill up the same drop-down list don’t need to worry about implementing any DAO object to access the data. All they need to do is call a web service; it’s as simple as that! The Data Services Server will return the data in JSON format. How cool is that? Just imagine all your queries and stored procedures exposed as a web service.
Think about all the possibilities SOA architecture across the application flow provides; more flexibility, reduction of redundant code, more grouping of functionality and everything is exchanged in the JSON format. All these components lead me to believe there will only be positive results.
Let’s go ahead and take a look at the different components that interact on my own implementation (there are many other components of the suite, but I’m just covering a few here. You can take a look at the other components here)
Data Services Server: This manages the data sources creation (Oracle, MSSQL, XML, JSON, XLS), the resources creation (queries declaration, stored procedure declaration) and it also exposes them as web services.
API Manager: This handles the interaction between the frontend-backend-Data Services Server. At the end, everything gets published here, including the backend REST operations and the DSS operations. As a result, the UI only needs to “talk” to the API manager because all operations are exposed as one huge API. This results in a beautiful REST-based API.
I hope this post will motivate you to take a look at this alternative process to develop enterprise applications. Perhaps you will find it as interesting as I did when I begin using it. Not to mention, everything is 100% open source. So, what are you waiting for?
See you in the next post!