Author: Alexander Tretyakevich
Architectural Goals
The application architecture should address the following goals:
- Provide for sufficient level of the performance for a specific subsystem/business feature
- Be scalable to meet the needs for different lifecycles of the application (small at the start/growing as the popularity of the system will grow)
- Be effective (scaling of a specific feature shouldn’t require scaling of the entire system/global change of the application deployment environment)
- Be maintainable
Top-level Architecture Definition
The application architecture will be based on a service-oriented architecture concept, with both vertical and horizontal partitioning of services (depending on the nature of each specific service). All services will have two ways of communication:
- Synchronous (direct/dispatched communications using the synchronous ESB bus)
- Asynchronous (emitting events and catching them, using high-performance message-based transport)
The system will use the main application database to store the application data, yet separate services could have their own databases for reducing the load to the main database and increase responsiveness/reliability.
The application architecture allows application owners to place separate services on the same physical/virtual hosts, on different hosts, in cluster configurations. In order to provide a greater level of flexibility and maintainability, the system uses the service registry and dispatcher (as a part of the ESB bus), as well as centralized management/tracking facility (being the part of the administrative application).
The application architecture allows the system to continue working in case of failures of secondary services (with temporary unavailability of some system functions).
The implementation will be based on the Java technology stack with extensive use of ready solutions (preferably open source/free).
Architecture Components
The top-level view of the application architecture is presented on the following scheme:
The detailed description of the architecture elements/modules is provided further in the document.
Please note that some services have not been mentioned explicitly and are a part of functionality for one of core service sets.
Synchronous ESB Bus
The application will use the ESB-like approach for intercommunication between the distinguished business services, which together form the application. All services publish their public business interfaces (via the Service Registry) and use the system synchronous transport bus to perform point-to-point communications between different services. The synchronous communication is used to request data/perform priority processes on demand.
The architecture will provide the ability for services to use different mediums (with adaptation) for communicating, including:
- Web Services (e.g. Java Axis)
- XML-RPC based calls
- RPC (Corba, etc) calls
- Proprietary protocols
Yet the most straightforward way will be sticking to a single transport to reduce the overheads, e.g. Web Services.
The ESB solution could be based on the proprietary developed lightweight framework, or ready solutions like Mule Java open source ESB.
Service Registry
The service registry will be responsible for tracking and providing information (for entire system) about registered services, their addresses, current state and capability, including:
- Information about hosts which contains current services (or entry points for service clusters)
- Status of the current service (available/unavailable)
- Version of the service (for easy tracking of the deployed application state)
- Resolve requests from business services and translate them to addressed requests
The service registry could use both the main database for storing the information/embedded database for increased reliability.
Asynchronous Event Bus
The application will use the Asynchronous Event bus to exchange asynchronous events between components of the application (both remote and local). Processing of events is started as the services receives the event (yet it’s up to the service to decide when to process the incoming event) and could result in raising new events/or be performed as a quiet process.
The event bus will provide the following modes of work:
- Broadcasting of events for all consumers
- Addressed sending of event to specific consumers
- Peer-to-peer exchange between two services
Async Transport
The asynchronous transport will be used to provide high-performance communication medium for the Asynchronous Event Bus. The following set of suitable solutions could be used:
- JMS (Server + brokers, e.g. Apache MQ) – being the industry standard at the moment.
- AMQP (e.g. RabbitMQ) – rapidly evolving alternative
- Any proprietary lightweight message exchange protocol/queues (less probable to additional expenses for the development)
Application Database
The application database (possibly MySQL-based, at least at the start) will be used as the main storage for the application data. The majority of business services will rely on the main database (yet some of autonomous/semiautonomous services could have their own databases for increased workload capabilities).
In order to provide the increased levels of performance/reliability, the database could be configured to use:
- Clustering (improving performance/reliability)
- Replication (improving reliability/improving performance of asynchronous processes)
Also the system will include the scheduled backup/restoration solution to provide better level of the reliability.
Client Application
The client application provides users with the UI front end to all major business features of the system, as well as the set of core functionality (which isn�t included as a separate service).
The application uses standard layered architecture, including:
- DAO layer (possibly Hibernate-based)
- Business layer (together with the DAO layer forming the domain model), possibly Spring IoC will be used to ease the development
- Presentation layer (Web-UI, with AJAXed components, the exact solution/framework will be selected after receiving the updated design specification)
The client application will be ready for setup in the load balanced environment from the very start (Apache Balancer + several Web Servers)
Administrative Application
The administrative application provides users with the UI front end to all major management features of the system, as well as the set of core functionality (which isn’t included as a separate service).
The application uses standard layered architecture, including:
- DAO layer (possibly Hibernate-based)
- Business layer (together with the DAO layer forming the domain model), possibly Spring IoC will be used to ease the development
- Presentation layer (Web-UI, with AJAXed components, the exact solution/framework will be selected after receiving the updated design specification)
Access Control Service
The system will include the centralized access control service, which will provide other services with access control capabilities. Due to clustered nature of the system, the access control system could use the following techniques to improve performance/lower the complexity of the system:
- Single sign-on performed on the service itself (all user contexts are stored on the service itself, client services/applications receive/operate user security tokens only)
- Each service (via the integration with universal access control hub on the service’s side) could use the permission cache to reduce the network overhead. The further architectural improvement could be usage the distributed cache/memory pool (e.g. Terracota) to further improve the performance and reduce the complexity of the cache synchronization procedure
Mass Notification Service
The mass notification service provides the system with the ability to send email notifications (in case of necessity, the service could be made as more medium-neutral, to support different notification mediums, like internal notifications/SMS/etc). The mass notification service solves following standard issues:
- Balancing of the system load in case of numerous emails to be sent
- Usage of multiple SMTP hosts to surpass email sending limits (spam filters, etc) and improve the overall throughput of the system
- Queued processing of notification tasks (completely asynchronous behavior for the client)
Statistics Service
The statistics service is responsible for processing raw application data and produce calculated/prepared statistics data (usually in large scale systems it’s very ineffective to process the statistics on-the-fly for each statistical request).
The statistical data could be stored in the main application DB or in the separate statistics database to improve the performance/ease data backups. The service is completely in charge of tracking of the data integrity for the statistics database.
Since the statistics service is asynchronous, it’s possible to user separate read-only replicas of the main database as the source for collecting the statistical data (some latency in the replica data isn’t the problem here).
Payment Service
The payment service provides the necessary abstraction layer for working with different online payment portals (as well as provides business interfaces for offline payment modes). The payment service core provides a standard set of payment/billing capabilities, including:
- Combined payments (cart, etc)
- Refunds/Net 30
- Periodical payments
- Reporting
Advertisement Service
Advertisement service provides capabilities for running advertisement banner-based campaigns of different types (PPC/PPI) and provide banner tracking/input for the statistical service.
Search Service
The system includes two modes of the search:
- Full-text search (based on internal data indexing/external site indexes/tags)
- Business search (set of business-specific searches, with advanced capabilities)
The full-text search could be based on the Lucene search engine (e.g. in the form of Compass/Hibernate Search integration).
The business search implementation will depend on the concrete search.
Indexing Service/Web Crawler
The Web Crawler is intended for indexing internal pages of the application (for free-form text search) as well as indexing of third-party sites. The service allows controllable crawling for specific destinations (to define security credentials for protected sites, etc).
Do you like the article and want us to develop your project? Feel free to contact us here!
This entry was posted on Monday, October 27th, 2008 at 7:29 am and is filed under Architecture.
