Follow this series as we discuss a Java EE architectural blueprint used at Symbiotics.
Authors: Deon Taljaard, Jaco Beukes, Zifa Mathebula, Poloko Mphahlele
Java EE architectural blueprint
As the series progresses, we aim to share some more project architectures and discuss the adaptation of the base architecture for a project’s specific requirements.
The aim of this blog post is to describe the base project structure Symbiotics employs and the merits of the approach. This discussion consists of two parts, namely a diagram, which illustrates the conceptual model of this architectural approach and a discussion of its main elements. This is followed by a breakdown of the pros and cons of employing the suggested approach.
Part 1: Architectural diagram and discussion
Each of the components in the diagram represents a separate architectural layer. A description of the main components in the diagram is given below.
A. UI
The UI represents the presentation layer and can be implemented using any web/presentation framework, such as Wicket, JSF, Struts, etc., or client-side Javascript framework such as AngularJS, Knockout, etc.
The UI is lightweight as it contains no business or orchestration logic. The orchestration of calls to back-end services, to construct a client view, is co-ordinated by the client service of which the UI layer is a consumer.
B. Client service
The client service is responsible for coordinating all back-end services required to construct the user interface model.
Although the client service is not generally featured in traditional architectural patterns, it enables a level of decoupling from a specific UI implementation, which merits segregation into its own layer.
The client service may be implemented as a Web Service, RESTful service or remote EJB. It exposes an interface which may be consumed by various types of clients, including web and mobile applications.
C. Engine/Business logic
The engine layer encapsulates business logic and is implemented as a Stateless Session Bean (SLSB). It exposes an API which is consumed by the client service layer and provides a Service Provider Interface (SPI) that defines a contract that must be implemented by the integration layer. It may call multiple providers that implement its SPI.
The engine layer implements a Façade design pattern – it provides a simplified interface into a complex API.
D. Integration
The integration layer forms a single integration point to all external services. It encapsulates all logic (such as client code), data structures and configuration artefacts required to interact with these services. It also performs a mapping function in the sense that it maps models used by external services to internal models used by the application.
Part 2: Pros and cons of this architectural approach
The merits of this approach will be highlighted in this section by contrasting the pros and cons of the suggested approach.
Pros
[list icon=”fa-thumbs-o-up” icon_color=”#c0c0c0″ border=”0″ font_size=”16″ animation_type=”” class=”” id=””]
[list_item]The layered approach creates clear delineation of responsibility within the project.[/list_item]
[list_item]The approach provides an infrastructure which should remain relatively static, even for fast-evolving projects – limited refactoring should be required.[/list_item]
[list_item]The client service layer can be consumed by multiple UI implementations (browser vs. mobile vs. desktop application) as well as external service consumers using different protocols (SOAP vs. REST vs. RMI/Remote EJB).[/list_item]
[list_item]The engine layer provides the usual benefits associated with using SLSBs, such as support for declarative transactions and security.[/list_item]
[list_item]Isolation of integration code in the integration layer prevents logic relating to an external system from bleeding into the core application code.[/list_item]
[/list]
Cons
[list icon=”fa-thumbs-o-down” icon_color=”#c0c0c0″ border=”0″ font_size=”16″ animation_type=”” class=”” id=””]
[list_item]The suggested approach might be overkill for a small project considering all the infrastructure code that needs to be put in place.[/list_item]
[list_item]The integration layer might become very large for complex projects if support needs to be added for multiple integration points.[/list_item]
[/list]
Conclusion
This blog entry described an approach to architecting applications using a multi-layered pattern designed to promote flexibility, segregation of responsibility, multi-protocol support and the minimisation of coupling between layers.
We looked at a conceptual model of the suggested architecture and provided pros and cons that need to be considered when implementing this architecture.
We hope you will join us in our next blog post in which we will be discussing Symbiotics’ approach to integrating Maven into the suggested architecture.
If you find this blog helpful and think others might too please share and like us on facebook.
