We all know how a typical web application is usually built up. The image at the side rougly displays the different layers that are to be found in an application. Typically, the user interface layer receives HTTP requests, calls one or more methods in the Business logic layer, and responds with an HTTP message containing HTML.
Nowadays, SOA has come along, and suddenly all enterprise architects want XML web services everywhere. For some reason, many think of SOA as a synonym for “everything must be a web service”. What SOA really is, is not the topic of this article. I want to discuss the position these web services get in the overall picture.
The “Business logic” layer could contain business services that are useful to other applications too. In that case, it might be an option to provide these business services to the “outside world” as XML Web Services. So, the user interface is separated from the rest of the application and replaced with a Web Services interface layer. The business logic is now available to all applications that need it. The user interface that had just been removed is now considered another application that uses the business logic layer through a web services layer.
On paper, it might not even look that ugly. There are, however several major downsides to this approach.
First of all, performance is decreased, as XML Web Service calls cost a lot of processing time. Not only marshalling the request and the response take a lot of time, but HTTP communication takes its toll too.
Something developers will notice, especially after the first release, is that this choice of architecture is difficult to maintain. Most changes that have been requested involve the user interface; a little more information here, something else there, etc. However, to get this information to the front-end, changes have to be made in the business logic, domain model and or the Web Service interface.
The third downside is that the “Business Logic” layer and the “User interface” layer are (often) functionally coupled. The main functions exposed in the view have almost a one-to-one mapping to business services. Splitting these two layers into different application would then sound inappropriate.
So why is this apparently homogeneous application split up into different components?
One thing I have heard is that this is the way SOA prescribes it should be done. I’ve read many documents and specifications, but I have never found a single one that says so. It might be obvious that I disagree.
Another excuse is “versioning”. For some reason, people think more of versioning as a problem than as an opportunity. When done right, versioning of a web service should be a big problem. But a more important question is: why should you version a service? Probably because the business rules in the business logic layer have changed. If that is the case, why keep the old version alive? It uses a deprecated business logic layer. Another reason to version is because the request/response model of the web service doesn’t provide all available information. That can be easily solved by adding either a new service, or an optional parameter to the existing request indicating an extended response is wanted. In my article about Web Service versioning in Java, I go more in-depth on ways services can be versioned (limiting to Java).
However, the most common excuse for the separation is reuse. “Maybe, in the future, more application might want to use this functionality too” is a sentence I have heard more than once too often. Will the business logic ever be used by another application? If that is the case, will the request/response model chosen sufficient for that application? Big chance that the answers are respectively “Most probably not” and “Very little chance”.
It is obvious that I am not fond of this solution. Not because I don’t think it really sounds right, but because I have dealt with this structure in my day to day work. Not somehting I would want to wish you.
I prefer to see the analogy between the User Interface (UI) layer and the Web Services (WS) layer. The UI presents an Business Logic interface to human users. HTML is usually the format of choice. A Web Service layer is exactly that, but then presents the same functionality in another format. For example as SOAP/XML messages. Or as JMS messages on a queue. And let’s not forget REST.
When you see the analogy between the UI and the WS interface, an architectural layout as the image on your right is a good option. In this picture, I have drawn a single “WS” box, but there could be more, depending on the types of services you would like to expose. I have, however, never seen more than one WS interface type in an application, and it usually is a SOAP based web service.
The application is still usable by other applications, accessible for other users and a lot easier to develop. There really aren’t any concessions to be made compared to the completely separated variant. Furthermore, the Web Service only has to be added at the point in time another application actualy needs it. This allows the request/response model to be designed in such a way that external application can take full advantage of the business logic.
I am conviced that the last option provides the most possibilities with the least concessions. And isn’t that exactly what we want? Or did I really miss something? In that case, please leave a comment and let me know.