Introduction
Recently I implemented for a customer a service which counts user interactions on their company website. The purpose was to count how many times a page has been called.
First, I want to give you an architectural overview of this service.
The image above shows the architectural overview. It contains of the following parts:
- Application: This is the application that uses the service.
- Facade: The facade implements an interface which represents the access point to the functionality of the service. The facade also has the advantage that the service itself is hidden to rest of the application. Imagine you want to replace the service: All you have to do is to modify the service methods, but not the application itself. Remember: Always program against interfaces!
- Service: The service component itself. This is where the actions takes place. Usually you have here a DAO – Layer.
- Communication: The communication between application and the service is realised by using the Burlap Hessian protocol. The Hessian binary web service protocol makes web services usable without requiring a large framework and without learning yet another alphabet soup of protocols.
The idea of the service has many advantages; namely faster development, testability, reuseability.
- Faster Development: When you develop a service you concentrate only on the development of the service itself and not be bothered in the first place how it fits into your application. Also imagine you would build your application with e.g. Maven…it can be quite time consuming to build the whole application instead of only compiling the service. Another considerable point is that you do not necessarily need to know the application itself, all you need is to provide an interface for other programmers. You can work independently and parallel to other teams or team members. So you don’t need to wait until they are finished with their implementations.
- Testability: Your service itself is an independent component and because of this attribute the component can be test individually. Consider it like a unit test. What you also can do is to test the performance of you service. Your test result won’t have the overhead of the application that uses the service.
- Reusability: The service itself can be injected not only into one application but can be used by other applications as well. Just imagine using Dependency Injection: Add your service to other applications so that they easily benefit from the service. All you have to use the service’ interface methods…thats it! The rest is already done.
In the second part I will show an example, explain the classes and show you how to test the service. Stay tuned!