I would like to ask for some advice regarding the system design for the application I am currently working at. We have a story feature similar to instagram and as a back-end language we are using Java Spring and I have just implemented a Redis cache.
The current layers are like this:
Controller -> Service -> Repository ( Jpa Interface) -> Domain
We will be implementing some caching for a lot of data ( like the user stories of users ).
From a Java architectural point of view does it make sense to add a DAO layer between the service and repository layers where the data source ( aka cache or actual database ) will be chosen. Also does it make sense to actually create a "cache domain" that is a data structure that represents the domain object but is specifically created to be stored in the cache ( a bit like a dto, but for example for a user story I could have a field that shows earliest story element remove time so I know when I can remove certain entries).
The recommended approach is to have caching defined in front of service layer (admittedly, technically there's no restriction in using cache in b/w Service and Repository either), this way your data flow will look like following
Controller -> ServiceCache -> Service -> Repository ( Jpa Interface) -> Domain
The ServiceCache layer (the "cache domain") contract must confirm to Service layer interface. In fact, both ServiceImpl and ServiceCache will implement same (Service) layer interfaces. All methods in ServiceCache should be simple delegate to ServiceImpl layer. This way you can transparently replace Service beans injected in Controllers with that of ServiceCache (say by using spring #Qualifier). You do not have to have to have all ServiceCache built this way, go incrementally as you add caching capabilities to your beans.
The ServiceCache should enable spring cache abstraction, this is more or less de-facto standard for spring applications. This way all caching work is managed by spring itself and you don't have to deal with low level caching constructs by yourself. You should add appropriate hooks in you application to ensure proper eviction and re-population of cache as per your business/technical rules (say using create/update events in service/persistence layer). This can be accomplished using #CachePut, #CacheEvict annotated methods in ServiceCache layer which shall be invoked appropriately by your application specific hooks responsible for updating/deleting cache objects.
Spring cache further abstracts actual cache technology and give you freedom to switch them as may be appropriate without any change in your caching code/logic (e.g. use in memory caffine cache for unit tests and redis OR ehhcache for production). I'll strongly recommend to understand all options available from spring cache and use them effectively for cachce management. Following articles are good start -
A Guide To Caching in Spring
Spring Cache Abstraction
Hope it helps!!
Related
In hexagonal architecture, domain layer has no dépendency with framework.
Is it possible to use Spring cache in domain layer ?
Caching is application concept, not a business concept: you could write another application for the same business that would not have cache involved. In an hexagonal architecture, caching should go in the adapter layer, not in the domain layer.
Hexagonal architecture isolates the domain logic from the Infrastructure, such as the database, search engine, message queue, mail delivery, and the cache system. The domain is free of any infrastructure and framework boilerplat. Only Infrastructure Layer must contain the implementation details of Spring Cache. It is achieved via Dependency Inversion Principle by making the class depend on abstractions (interfaces or abstract classes) instead of concrete classes. This means that the depending class has no knowledge about the concrete class that it is going to use, it has no reference to the fully qualified class name of the classes that it depends on. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
Let's review several implementations where cache makes sense.
Cache at the Repository Level
You can define repository contract in Domain Layer and the implementation must be done in Infrastructure Layer where you define persistence and Spring Cache details. Domain will not know details about the cache system but will use it thru repository implementation. Every client of your repository will use the cache.
Cache at the Application layer
Application Service is about use cases. Implementation cache on this level gives you more control of where and when you want to use a cache. You can define Cahce Manager contract at Application layer and perform implementation details in Infrastructure Layer. Also it can be done like proxy or decorator for your services where you will apply Spring Cache annotations.
we have a platform composed of few applications.
We have to develop an API which must factorize all interaction to a database.
In this API, we will too have a version of the database in XML format.
The XML format will be used just by one application.
Our application are developped in a classic architectural : dao - service layer - presentation layer.
The DAO layer will be moved into API. No problem on that point.
In many application, the service layer is just a gateway between presentation & dao layer without specific business code.
So my questions are :
should we create the API with a Service layer for each dao ?
if yes, so keep a service layer in application which call service layer from API ?
should we create a service layer in API which manage the factory (database/XML), but that mean each application has to give an information to choose the dao to select (when just one application has this need) ?
or just create all dao in different packages for database & xml in API, keep factory in the application which has the need, and call dao (database) in all others ?
Need help ! :p
I'm lost...
FYI, we are in Java 1.6 with Spring 3.1.1. JDBC Template in DAO for moment.
We are looking informations about spring data jdbc to replace JDBC Template.
Any suggestion about that can be appreciated ^^
[ No Hibernate - JPA solution ]
Thank you.
[edit 1]
In other word, keep a service layer in application & in the API is a way for me to have an abstraction layer. If we have to modify the database structure, maybe we don't have to edit all applications if we can make some changes directly in the service layer of API too.
Imagine 3 possibilities :
service layer in API with factory to choose which dao to use (xml/database)
just dao in API
service layer in API for database & specific layer in API for XML
What solution do you choose ?
[edit 2]
Is it interesting to create an unique class to call the API ? like in a Facade design Pattern.
Use the Service Layer for what is meant to do: provide real world services, by using one ore more DAOs per service offered (and other stuff like managing transactions, sanitizing Strings and other things like that).
If you (together with a more experienced coworker) think you don't need this service layer, then do not put it into your architecture. But make sure to create a proof of concept of your architecture (this may contain the implementation of a somewhat complex functionality of the system or part of it) so you can evaluate it later to demonstrate if you really don't need such layer (or if you do).
My understanding is that you need to decouple and reuse the business layer from the presentation layer, having multiple client applications using the same business implementation.
In this case you need to implement the service layer in the API. Some advantages:
You don't need to repeat the service implementation for any client application handling the presentation.
You can easily decouple the database model design from the business. Design patterns (DTO, Facade) and cross cutting concerns may be easily introduced.
A well designed service layer will require a minimum amount of modifications, compared to DAOs holding DB implementation details.
In this API, we will too have a version of the database in XML format. The XML format will be used just by one application.
By providing this implementation via the API more client applications will be able to use it in the future, if needed.
Spring remoting is offering excellent tools for such a design (RMI, HTTP invoker etc)
I don't see any added value in proving an API for DAOs.
I have an existing Java EE 6 application (deployed in Glassfish v 3.1) and want to support multiple tenants. Technologies/APIs I'm currently using in my app are
EJB (including the EJB timer service)
JPA 2.0 (EclipseLink)
JSF 2.0
JMS
JAX-RS
I plan to use CDI as well
As far as I know, adding multi-tenancy support affects only the persistence layer. My question: Has anybody done this before? What are the steps to convert the application? Will this affect other layers other than persistence?
There will be a high number of tenants, therefore, all data will reside in the same DB schema.
Persistence Layer
Start with the persistence layer. Roll upwards through your architecture once you have that done.
The Schema that you are proposing would have an ID that identifies the tenant (eg. TenantId). Each table would have this ID. In all of your queries you would have to ensure that the TenantId matches the logged in User's TenantId.
The difficulty with this is that it is a very manual process.
If you go with Hibernate as your JPA provider then there are some tools that will help with this; namely Hibernate Filters.
These are commonly used to restrict access on multi-tenant Schemas (see here and here for some more)
I haven't used EclipseLink but it does look like it has good support for Multi-Tenancy as well. The DiscriminatorColumn looks like a very similar concept to Hibernate Filters.
Service Layer
I assume that you're using JAX-RS and JMS for a Service Layer. If so then you will also need to think about how you are going to pass the tenantId around and authenticate your Tenants. How are you going to prevent one tenant from accessing the REST service of another? Same thing for JMS.
UI Layer
You are going to have to hook up your login in your UI to a Bean (Hibernate or Eclipselink) that sets the TenantId for the Filter/Discriminator.
Tell us about the number and the degree of separation and customization necessary for different tenants.
If you have a small number of tenants, I would propose to create a customizable "white-label" product. This gives you the opportunity to create some specific things for one tenant without overcomplexing matters. Plus, separating the applications per tenant helps you in maintenance. We did this for a product with a handful of different tenants.
If you have many tenants, this is of course no longer practical. We did a generic version of the same product. All we did then was distinguish tenants by id after login, thus separating the data from others. But still, there was nothing to do in terms of changing the application or a layer within, the id was all what was needed to separate the data and the workflow is automatically separated by having different instances of beans or other managed objects.
There's several ways you can go with this, depending on the level of separation you want to achieve and how many concurrent tenants you want to support. At one extreme, you can create a new schema for each tenant and therefore ensure database-level isolation of data. For most practical purposes it's usually sufficient to have a logical partitioning of your data by assigning a tenant_id to every entity in your domain model and maintaining foreign-key constraints. Of course this means you'll probably want to always pass in your current session's tenant_id to every query / finder method so that it can restrict the data set based on that. You'll want to make sure that users cannot access another tenant's data by entering a tenant id (or a entity id) that does not belong to them in url.
Go message oriented.
If you choose messaging as the strategic approach and refactor (if necessary) business logic around JMS, then other options remain viable and locally applicable.
With this approach, you pay a specific fixed cost (refactor) in your existing (single tenant) system. You then can apply approaches of various degrees of complexity, ranging from simple sharding (#Geziefer's id based association) to a full blown shared-core-schema + extended-tenant-specific-schemas approach, without impacting system architecture and additional refactoring.
You will further have orthogonal control over your system data flows via the messaging layer (applying routers, filters, special processing paths, etc.)
[edit per request]
There is nothing per se in M.T. that explicitly suggests message orientation. But as a general problem, we are looking at widening interfaces, and enriched data flows. Per an API based approach, you would need to carefully inject the appropriate the tenant discriminant in all required interfaces (e.g. methods). A message based (or alternatively a context based API approach) allows for a normative (stable) interface (e.g. message.send()) and at the same allows for explicit specialized data flows. If switching to a message based backbone is not on the table, you are strongly suggested to consider injecting a uniform context (e.g. "RequestContext") param in your APIs. This single extension should cover all your future specialization needs.
I'm looking at this java web application that is using hibernate, jsp's, and spring framework. (from what I can tell!)
the file layout is like this:
classes/com/example/project1
inside project1
/dao
_entity_Dao.java
/dao/hibernate/
_entity_DaoHibernate.java
/factory
DaoFactory.java
DaoFactoryImpl.java
/managers
_entity_Manager.java
/managers/impl
_entity_ManagerImpl.java
/model
_entity_.java
/service
_xxxx_Service.java
/service/impl/
_xxxx_ServiceImpl.java
Have you guys read about this sort of layout somewhere? Is it considered best-practice?
What is the difference between a Factory and a Manager and a Service? (high level)
For typical layout of an application built with Spring I'd look at the example web applications that ship with it (meaning Spring).
Using things like DaoFactory is definitely not be a best-practice, the Daos should get injected instead. In general you should not need factories with Spring except for some unusual cases. Injecting is done when the web application starts up, spring reads the configuration information and constructs all the objects and plugs them in according to configuration xml and/or annotations (this is assuming singleton-scope for your objects, which is usual for stateless things like daos and services, things scoped as prototypes get new copies created as the application asks for them).
In Spring applications a service is similar to a Stateless Session Bean, it is a transactional layer encompassing application logic for a use case. So if your user takes an action that has the effect of causing several different tables to get updated you can inject the daos into that service, have a method on that service do the updates on the daos, and configure Spring to wrap that service in a proxy that makes that method transactional.
I've seen manager used as another name for what I described as service. Here I don't know what they're doing with it.
I don't like the idea of combining your interfaces and impls in one project. Just because you want to consume the interface doesn't mean you want to consume the impl and it's cumbersome transitive dependencies. The main reason is because there will be more than one impl (hypothetically, i.e. JPA/JDBC/Hibernate, or Axis2/CXF, etc.). The interfaces should not be bound to the implementation, otherwise the point is lost. This also allows for easy dependency injection as the impls simply reside on the classpath, then something like a Proxy or Spring (e.g.) can inject the implementations.
In all likelihood, all you need is a:
Interface Project
dao
EntityDao
types
Entity
HibernateImpl Project
dao
EntityHibernateDao
src/main/resources/
EntityMapping.cfg.xml
I started experimenting with Spring Roo just recently. It does a very nice job helping one build a domain model with integrated persistence rather quickly. As it adds persistence functionality in aspects, I started think about the following question:
Roo adds finders (load an instance of a class from the database which meets variable criteria) in an aspect to the actual class/entity. In DDD this is IMHO the responsibility of repositories. Repositories are explicit classes which show up in the design. Of course as an aspect the repository functionality is hidden in an entity and is pretty much invisible.
So here is the question: Is an aspect a real substitute for a explicit repository class? Are there any downsides to the Roo AOP approach?
Adding finders to your domain classes feels more natural from a user's point of view but it mingles your layers. Grails uses the same approach by adding static finder*() save(), ... methods.
Apart from the aestetics it might have practical drawbacks when not used in web application setting:
Your domain classes are now tied to your database. If you transfer these objects to rich clients via RMI or HttpInvoker the client cannot and often may not use the find* methods because there is no session / database connection available on the client.
I generally prefer allowing domain classes to reference service layer interfaces to prevent an anemic domain model (http://martinfowler.com/bliki/AnemicDomainModel.html). This has its own set of drawbacks but at least provides a clear boundary. On the client the concrete implementation behind a service interface can then just proxy all method calls to the server (or just use a synamic proxy with spring remoting or sth similar).
So to answer your question: It might be a substitute but you should be aware of the possible negative consequences which make your domain classes (i.e. your core business logic) less portable between systems.
This depends on how complicated your applications persistence layer is and how much control you have over it. If your application is simple enough to be implemented via JPA, then it all could be handled via Roo aspects. However if you are mapping legacy tables or need advanced DB stuff, then you may find yourself in a situation where Spring-JDBC is the only way out and in these cases a repository/dao model may still be useful.
I consider it logical inconsistent (and a break of layer responsibility) to be mixing two persistence models and so as most of my applications requires such advanced DB constructs I stick strictly with a repository model.
I think adding repository methods to domain objects is bad design. The right place would be static methods in the domain class. But domain objects and their management are two different things that should be separated. I would prefer domain objects and repositories.
I guess the motivation was to achieve something Rails/Grails like with Java.