Please ignore English grammar.
For Learning purpose I want to create a microservice project in Spring and I download some sample project and now I have some very basic
idea of microservices. But I am confused how I start my own project.
I want to implement the following simple use case.
In my database I have three table
Product,
ProductStock
and Order and I want to write microservice for each table.
Product microservice will have end point for crud operation.
ProductStock microservice will only have update stock and check stock end point.
Order microservice will only have posting order operation.
I create a multi module maven project and now I have following question.
1: Is creating multi module maven project is the only way to create microservices project.
2: I am using Hibernate so in which module(microservice) I create model classes. I need model classes in every module(microservice).
(Model classes are Product, ProductStock and Order).
3: Where I set hibernate confiuration.
Even if this question is way too broad, i'll try to answer your question as good as i can:
A multimodule project is not the only way (and i would even say, not a recommended way for different services). Usually you have completely separated Maven projects for each service.
Every service has to have its own data model and entity classes. Services should never share any entities, and should not access the same databases/schemas. They can use the same database server with different schemas.
In every service, which uses Hibernate.
The microservice architecture is not a trivial area so I would suggest to you that you start with some theory first. One of the books which is often referred here and there is Building Microservices By Sam Neuman. I highly recommend reading it or at least a part of it. This is the theoretical part.
Then for some hands on experiences you may want to clone/fork the PiggyMetrics project. This is an educational project but at the same time it contains quite a lot of patterns and advanced stuff.
After that you will be able to answer your own questions yourself, albeit there will be much more to ask ;-)
Good luck!
Related
I have two spring applications, the 1st app communicates with hibernate and the 2nd project communicates with elasticsearch, the data added by first project, then replicated from mysql to elasticsearch.
This data on elastic will be used in the 2nd spring application.
So, my question is the entities in first project for example have translation objects and it will be different objects each has details in one language, then we create a common project that contains these entities that will be used as maven dependency in both apps.
Does this way is correct or moving these entities into every project to do the differences since entities won't be exactly the same in both projects
If the classes are not exactly the same it doesn't make sense to share.
Sharing often results in a tight coupling between components and hinders the independent evolution of the components.
We are beginning the process of re-architecting the systems within our company.
One of the key components of the work is a new data model which better meets our requirements.
A major part of the initial phase of the work is to design and build a data migration tool.
This will take data from one or more existing systems and migrate it to the new model.
Some requirements:
Transformation of data to the new model
Enrichment of data, with default values or according to business rules
Integration with existing systems to pull data
Integration with Salesforce CRM which is being introduced into the company.
Logging and notification about failures
Within the Spring world, which is the best Spring project to use as the underlying framework for such a data migration tool?
My initial thoughts are to look at implementing the tool using Spring Integration.
This would:
Through the XML or DSL, allow for the high level data flow to be seen, understood, and edited (possibly using a visual tool such as a STS plugin). Being able to view the high level flow in such a way is a big advantage.
Connectors to work with different data sources.
Transformers components to be built to migrate data formats.
Routers to route the data in the new model to endpoints which connect with systems.
However, are there other Spring projects, such as Spring Data or Spring Batch, which are a better match for the requirements?
Very much appreciate feedback and ideas.
I would certainly start with spring-integration which exposes bare bones implementation for Enterprise Integration Patterns which are at the core of most/all of your requirements listed.
It is also an exceptionally great problem modelling tool which helps you better understand the problem and then envision its implementation in one cohesive integration flow
Later on, once you have a clear understanding of how things are working it would be extremely simple to take it to the next level by introducing the "other frameworks" you mentioned/tagged adding #spring-cloud-data-flow and #spring-cloud-stream.
Overall this question is rather broad, so consider following the above pointers and get started and raise more concrete questions.
as I mentioned I want to implement a backup/snapshot feature for my web app.
As for details, imagine each User has several Projects which has several Components which also has several Subcomponents. Those are the entities that I want to backup apart from User.
The goal that I want to achieve is that user may save the current state as a snapshot and later if he doesn't like the new configuration, can easily turn back to his save and there can be multiple snapshots. Those snapshots has to be read only.
I'm asking for a design architecture or style or any kind of idea to implement. That's why I didn't put my entities here.
Thanks, beforehand!
I have some similar versioning in a project where I manage that in a service by simply introduced another entity. In your case that would be a ProjectVersion and the Project has a list (OneToMany) of these versions and additionally a ManyToOne (or OneToOne) relation to one ProjectVersion called master. The Project itself has no more fields.
A few days ago I stumbled across #Version from java persistence API (not the spring one) and this annotation should help to automatically increase and manage a version value in the entity during updates. But I haven’t tested it myself.
Just a general question on any techniques used to seperate your web application for customer specific requirements. At the moment I have one web application but I need to add new functionality for one customer thats not needed by another. I know spring 3 comes with new support for profiles but I'm just curious if anyone has had a similar problem and how they went about solving it particularly using spring mvc and maven as a build management tool
The proper way to do this would be as follows:
Have a web assembly module. This module will build a war file containing the proper features extracted into separate modules simply defined as dependencies. My advice is to have a separate web assembly project per client. This way you will keep things neat for yourself, avoid mix-ups (such as releasing features to clients who haven't paid for them) and have an overall easier maintenance.
Furthermore decide whether to do your version separation at the level of the version tag or classifier:
The version tag you can use in order to separate things in branches.
The classifier tag you can also use to separate configurations specific to your clients.
We are writing a new set of services and have decided to make them share a common interface... calling it a BaseService. The idea is that whenever anyone wants to develop a new service in our organization, they should be just able to extend and use this BaseService.
We have written a few other classes which also form a part of this base jar, it does things like handle transactions and connect to database using hibernate etc.
Right now all the services that extend the BaseService are a part of the same project (Eclipse + Maven), and some of the services are dependent on each other, but because they are in the same project we don't have a problem with dependencies.However, we expect 40-50 services to be written which would extend base service and would also be interdependent.
I am worried that the size of the base project would be huge and that just because when someone has to use one service they might have to depend on my base jar which has 50 services.
Is there a way that we can make some projects dynamically dependent on others?
Lets say I have a service A which depends on service B, when I build/compile Service A,it should be able to realize that it has a dependency on service B and automatically use the Service B jar.
I have heard of OSGi, will it solve my problem or is there a way I can do it with Maven or is there a simpler solution ?
Sorry about the long post !
Thanks in advance for your suggestions
It doesn't make any sense to "dynamically" manage project dependencies, since build dependencies are by definition not dynamic.
Your question, at least for the moment, seems to be entirely about how to build your code rather than about how to run it. If you are interested in creating a runtime system in which new service implementations can be dynamically added then OSGi may be the solution to look at. An extra advantage here would be that you could enforce the separation of API from implementation, and prevent the implementing services from invalidly depending on parts of your core module that you do not want them to have visibility of.
You could also use OSGi to manage evolution of your core service API through versioning; for example how do you communicate the fact that a non-breaking change has been made to the API versus a breaking change etc.
I would say there are two options depending if i understand your question correct. First one. You have already defined an interface (java term) and now you have different implementations of that. The simple solution for Maven would be to a have a module which is called for example: service-api and than this will be released and can be used by others as dependencies. On their side they simply implement the interface. No problem with the dependencies. If you are more talking about OSGi than you should take a look to maven-tycho.