In a micro service architecture, Is it good to have separate DAO services for all the Business services or should I have all the layers intact in the service. In my case, I am building a small Banking application where in I have below services
cbs-accountsummary
cbs-payments
cbs-accounts
cbs-loan
cbs-deposits
So should I really require below services as well
cbs-accountsummary-dao
cbs-payments-dao
cbs-accounts-dao
cbs-loan-dao
cbs-deposits-dao
Or is it fine to have DAO as part of business services. I am really wondering how it goes in real life applications.
In micro-services architecture you split your Domain to micro-services and each micro-service will have its own: api, business logic and data access.
Your example
In your case for example the micro-service "cbs-payments" will have its own API exposed, as well as a business layer(the domain logic of the payments domain) and data access layer. The micro-service will be responsible for the whole scope of the request from api to data persistence. This could include api's, business logic, cache, database and other things.
Lets say if you have a Create payment api call. You would call your micro-service REST api like POST api/payments which would process the request, apply some business rules(validation and others) and save it to the micro-service specific database. All that code would be in your micro-service.
The confusion
Maybe your where working with systems where the the architectural split was not done based on the domain but on some other criteria.
Usually micro-services are split based on some Domain boundaries like in your example. Each of these micro-services are isolated. Regardless of business logic, data access logic or any other logic it is still part of that micro-service.
Usually people use DDD(Domain Driven Design) with micro-services. It is also a common approach to use Repository and Unit Of Work design patterns. You could create Generic Repository/Unit of Work classes which help in database interaction. If you are using micro-service architecture you can extract these generic implementation to some library and use them in each micro-service(extend them if needed). Still you would use that code in your micro-service code.
As already said, I would not go for separate DAO-Services. A Microservice should control all aspects for the bounded context it is responsible for, this includes persistence.
Imagine, if there would be seperate DAO-Services, what would prevent a client from modifying, via said services, the data of the Microservice itself? The Microservice applies business logic onto its domain objects and persists them or not (in case of business rule violation). You never want this to be circumvented. See "cohesive behavior" of Sam Newmans book Building Microservices.
Related
I'm familiar with spring boot framework and I developed an Application which helps to handle online Assignments.I used few service classes to handle different tasks of the application and its structure can be seen here.
And I have seen several complex applications built as independent packages based on the task it do in the application.
(1)
My First question is can my Application be called as a MicroServices Application?? Because I have
used independent services for the application development.
(2)
And my second question is Can a application developed in MicroServices Architecture has MVC Architecture at the same time.But I have seen in several tutorials they are 2 different architectures.But a Moicroservices Application also has Models ,Views and Controllers at the same time.
So can those 2 be used at the same time??
Thank you!!
You should do some deeper research yourself about the concept and theory of microservices. Studying other applications without the basic knowledge can be misleading.
(1) Just because you are using multiple classes called services does not mean, you are building microservices application. Microservice application examples can be - student management rest api, question and answer management rest api, UI for administration, UI for public usage etc. All of them can be separate spring boot apps, or any other technology capable of handling the requirements (node.js, python, php, Asp.net ...) You should be able to deploy, test and use them as separate standalone apps.
(2)I think a microservice app does not need views, it can be a rest/soap app, log aggregation app, health check app, messaging service app etc. But different types can use different architecture, one of which can be MVC.
By definition of M. Fowler microservices are
..an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
As you see the definition is ambiguous. I think you are building a monolith application with a good separation of responsibilities into classes called XyServices - a possible candidates to migrate to microservices.
Microservices according to Chris Richardson
( recognized thought leader in microservices) is Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.
It is way of delivery and based on 12 factors
https://12factor.net/.
We use domain driven design as one of the way.
MVC is way of designing as service where we have model view and controller.
In Microservices architecture we can use MVC in one way where each component will be distributed .
Please go through the Microservice Patterns. It is very good book to understand the Microservices architecture
1.Answer to your question yes your application can be Microservices if it followed the 12 factors as mentioned in the website .
Yes Microservices can be on the pattern of mvc but they will be distributed and like we have Microservices for backend in similar fashion we have micro frontend for UI .
Assuming you follow DDD and you have your Domain, Application and Presentation (Controller) Layers, should the Application Layer be completely decoupled from knowing anything about HTTP requests and all the other things that go with it such as cookies, sessions, etc.
To illustrate, say our CommentingService in Application Layer needs a value from a cookie named guestId. Should this value be passed in as a parameter to our service or can we pass the whole Request (HttpContext) object and let our service extract it from there.
Commons sense tells me that if I would want to reuse this Application Layer somewhere else I would want it to be decoupled from web.
Services
Yes, you will want to decouple your application layer from any web concerns.
Application layer is responsible for managing your domain objects like aggregates, repositories etc (orchestration).
Mostly you will go with next layer providing Rest Api functionality.
If you decompose it like that, you could use your API with CLI, Rest, Soap or whatever your business want you to provide.
Cross-cutting concerns
You will want to implement cross-cutting concerns in your application layer, because you do not want to reinvent wheel for every outside layer.
For example: security, caching, transaction managing logging.
It doesn't provide you with business capabilities, so you do not implement them in domain layer, but you can implement it in your application layer.
After read the Gordon's article about Best Practices to build Enterprise Application using Spring Framework, I would like to share some ideas about the Service layer.
My architecture represents exactly what Gordon described in this image http://gordondickens.com/wordpress/wp-content/uploads/2012/07/Spring-App-Layers.png
The application is complex, has a heavy business rule and demands to use different resources like Database, SOAP, REST and file handle sometimes in the same use case.
For this scenery that I have described above, I have a Service class that needs to perform SOAP and REST requests and handle some database data. So, I have autowired in my Service class a SOAP and a REST component and the Repository to handle the database stuff.
I'm concerned about if this is the best approach do handle the integration between my Services and the resources like SOAP, REST, Database and etc.
Thanks
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds problematic even though it will work.
Think about the dependency between layers. Service layer will depend on Repository layer (Business logic layer will depend on data layer). Service integration layer (or service communication layer) for incoming requests will depend on the Service layer. But the data layer does not depend on the service layer. Nor the service layer depend on the inbound service invocation layer.
So, remove the SOAP and REST components from the Service class. To the SOAP and REST components, wire the Service instance (i.e. avoid SOAP and REST components wired into the Service, do it in the reverse direction).
This way, when you want to support another integration protocol (say JMS), you do all such work not by modifying your service.
Your data access seems to be fine. I hope your Service accesses the repository via DAOs.
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds fine. You are using dependency injection, this means they can be easily tested or altered.
How can we flow user session from one spring application context to another?
Basically I have one spring application representing Web Layer and another spring application representing REST layer. I want when Web Layer access the REST layer the session containing user info to be available from to Web at REST layer for authentication.
Please suggest.
Edit after receiving first ans:
At present we do have Web Layer in place along with security and all the other flows. What we are about to intended is to introduce REST layer. This REST layer is suppose to be called by present Web Layer and by other APIs. We do not want to make any changes for Web Layer, but at the same time need security to be placed at REST Layer that should work for Web Layer too when calling REST services.
Differentiate between SSO and session sharing. If you just want the authentication to carry between application (user only has to log in once), then you want some form of Single-Sign-On (SSO), CAS is one example, but there are numerous.
If, on the other hand, you need to have access to the full session (and everything the application has put in it) across different nodes (or applications), you could look into something like Memcached or Terracotta. Worth noting is that session replication is fairly I/O intensive and for larger sites it often requires a dedicated network interface for the replication.
I would put it to you, however, that if your applications are so tightly coupled that they need to share the same exact session state, then perhaps they should not be separated in the first place? This smells of faulty design and architecture assumptions.
We are planning to develop a big application in web, our current plan is to create a WCF service for each class in the Business layer. Is this effective? I want to know where can we use WCF in a big web application and main advantages of using it
we have these projects
1) MVC3 with Razor that handles UI
2) Class Library Project that communicate with Database
3) WCF Project
Method we using
1)Creates UI and Model in MVC
2)Makes dll that communicate with UI (eg:Save function/Update function) using ClassLibrary Project
3)The Class Library Created is Added (Added to Bin) in WCF Project
4) Builds the WCF and Host It in Server
5) The Hosted Service is Used in MVC Project for Communication with DB
Our Technical lead is saying it is light weight and more secure but i am wondering why he is saying to use WCF for whole appication
First ask this question, why do you need a service layer, when it could be achieved by a separate application. If you want to achieve this for just loose coupling, then it does not makes sense.
In my opinion, the service layer would be useful for exposing your data (dal-layer) and not Business Layer. For example take twitter. Twitter exposes it data over Web Services. What you do with the data is completely your interpretation. The data could be consumed by many application over HTTP. So your client could be remotely situated and need not to be on the same server as your application. The business layer could change based upon interpretation of data. The consumer, then need to worry about latest changes and including latest DLL. It will just consume the webservice. Also mocking your service would be pretty easy and you could write your NUnits tests very easy on your Business layer then. I would also recommend you to have a look at ASP.Net Web API, which provides restful way of exposing your services and data(with inbuilt capablity of exposing it as JSON). The RestFull service has many advantages over WCF, like you then need not to worry about WSDL and etc. The interface always remains same. Consuming a RestFul service is very easy.
As again with the twitter example. The clients consuming twitter api's are not situated on same server. So it makes sense to expose it over HTTP.
But if you do not have such a requirement(Client is not remotely situated), then exposing your data over web services does not make sense. Then a separate application will give you loose coupling and that should be good enough for you. Also exposing data on HTTP will have some performance impact too.
UPDATE 2
I understand the scenario you are trying to implement and I think its perfectly allright. By light weight he means, from your WCF service he would do interaction with Database and then send light weight DTO's for each action and controller as per requirement. So basically your WCF would do nothing but invoke methods from your class library, would fetch some Business Object and Convert it back to DTO(as required by your action to render UI) and send it to Controller.
Also make sure, you use Dependency Injection for your Services, so that you could write NUnit tests for your controller with mock data and hence no requirement of Database for running your NUnits
My preference is to have the service layer be a completely independent application that can be consumed by many applications. It makes projects, especially large ones, much easier to scale, than if you were to create your service layer inside a single web application.
Unfortunatly to tell you. Using WCF is less effective. The main purpose to use WCF it to let your data can be accessed with any client application. not just web application. you may also have a Silverlight or winform. WCF has nothing to do with "A BIG" web app.