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.
5 thoughts on “Why are web services so different from an HTML user interface?”
Thanks for the article – great points.
I agree with the first Ben, this seems so similar to EJBs, where all these extra layers of complexity (in the form of “Core J2EE Patterns” – Session Facade, Service Locator, Business Delegate, etc.) were necessary in the name of “separation of concerns” – back then: business logic from infrastructure.
Basically, people traded the farm (performance, scalability, maintainability) for just this one non-functional concern…and it seems to be happening again with SOA. They advocate fundamentally changing everything for the hope of “business agility” and not worrying about all the other things: performance, maintainability, etc.
Anyway, I think in most cases, your proposed approach makes most sense – keep the UI local and create the web services interface as needed.
Two thoughts strike me at reading this article.
The first is the (perhaps somewhat worrying) parallel between what you sketch and the development of EJBs back in the days of yore. The situation that you’re sketching (dividing a monolithic application into separate ones that are coupled and as a net result just paying a performance penalty for the same functionality) is exactly what prompted the creation of local EJBs (i.e. EJBs accessed through their LocalHome interface). This is perhaps not surprising; people never learn.
The second is that you might be able to strike a simple compromise between architects’ desires to split up the application “for future flexibility” and software engineers’ needs in the way of performance and not making things more complicated than necessary. You can insert an abstraction layer between the User Interface layer and the supporting layers. This would then allow you to transparently relink the User Interface layer, switching its connections from either directly to the Business Logic layer to a WS Client layer and back. Especially in an application that uses dependency injection this can be a compromise that maintains both flexibility and performance as needed.
Sounds like a very familiar story. Some people talk about SOA like it’s a no-brainer. You simply read the theory books and your done. That’s definitely not the case. There is a lot to learn and you will make a lot of mistakes as you go along. Interesting stuff though…
One reason to physically separate your UI from the business services (in separate EAR’s) might be that they will get their own life-cycle. Functionality can be added to the business services and deployed separately from the UI and vice versa. You have to make a trade-off when thinking about packaging your business services into EAR’s. Too many and you will have a deployment nightmare. Too few and you loose flexibility.
It is very important to think in terms of coarse grained business services. Each coarse grained service will be a separate web-service. This coarse grained web-service uses SOAP messages for invocation. Many fine-grained business services are living within that coarse grained web-service. These fine-grained services are using POJO interfaces and a shared busines domain. An application should only have a few coarse grained web services, but can have many fine-grained services.
Some architects have a tendency to think in terms of ‘web-services all the way’. They want web-service interfaces between all fine-grained business services. Doing that, will kill productivity and performance. You will find yourself coding mappings (from SOAP to domain model and vice versa) all day long. Each small modification in the domain model will cost you a lot of re-factoring etc. You will also find your application server in state of stress, due to the huge amount of marshalling and unmarshalling taking place. My advice: use coarse grained web-services and many smaller POJO based business services.
There is a major difference between trying to predict re-use and not standing in the way of re-use. Some architects think that they can predict the future and know exactly how and when a service will be re-used. They try to anticipate future use and add functionality that might be used in the future by other applications. My advice: do n’t do that. In most situation, you will get it wrong and have a lot of re-work on you hands. The only thing you have to keep in mind is that you do n’t stand in the way of re-use. When designing, always ask yourself the question: what will happen if this has to change in the future? Do n’t try to predict what that change will be!
thank you for your comment, and I have to say I agree with you for the greater part.
Most part of this article is about the monolithic application you were talking about. That is when the user interface is functionally tied to the business layer. So, that part we probably have the same vision.
When it comes to a new application that uses existing services, there are two scenarios. The question really is, is the user interface to be built functionally tied to the business logic in that specific existing service. If the answer is yes, you might as well consider putting that new UI inside the existing service component. If the answer is no, the UI probably has a different business case (and probably another owner too) and is probably not a good candidate to put together with the existing service.
You remark about the several types of presentation layers is also interesting. I didn’t think about that at the time of writing the article. But isn’t that the same again as multiples types of web services? Shouldn’t we see the analogy here too? In other words, you could decide to add multiple UI components for each of the type of presentation layer. Don’t forget that Web Service calls are expensive, so if there is a nice way to avoid them, let’s do!
Anyway, thanks for your view on the matter. Your 2 cents have been put in the piggy bank 😉
If I would have read your article half a year ago I would have agreed with you all the way.
However while working with SOA, I’ve come to the following more subtle opinion.
As you already stated, there are roughly 2 choices in architecture when dealing with a user interface within a SOA environment. And both choices revolve around the following question:
– should the user interface communicate through webservice calls to the business layer or should it be linked to the business layer through API calls which were packaged alongside the web layer?
My answer would be: it depends.
If the business logic and web layer are developed as a monolithic application, its unnecessary to split the web layer from the business layer. It adds complexity without any clear advantages. And distributed environments are so last week ;-). If clients want to bypass the user interface, the just plug some webservices on the business layer, and let the client have its fun.
However when there are already services available within the runtime environment, why not use these to “mesh up” the user interface? The service environment is just another information layer used to retrieve domain objects. This has some major advantages:
– you’re free to choose one or more types of presentation layers (HTML, flash, mobile devices, etc.)
– business logic can continue on new service implementation without affecting the current user interface development
– a highly scalable and flexible architecture (I know, it sounds like a blast from the past) in which business logic and presentation are developed separately
It does however require a very efficient development environment when coping with several components with different versions. That is however more related to SOA than to the question above.
My 2 cents.
Comments are closed.