I'm developing a new application based on Spring MVC and Hibernate for data access.
I want the data access layer to be running on a separate application server, preferably JBOSS.
I want the data access layer to be running behind a firewall.
How can I achieve this?
Right now I'm concerned about hibernate lazy initialization in this scenario. Would there really be any problems with Hibernate lazy initialization?
There could be some performance penalties to this approach - the IO will be a bottleneck. However, Spring Remoting allows you to easily achieve this.
Create an interface for you DAO.
Implement the concrete implementation.
Use spring remoting to export the interface.
Inject the interface - from your apps point of view its just something that implements the interface. It doesn't care the the calls are being fired off to the remote server.
The mechanism for achieving this is called DynamicProxies - a Java SE feature. DynamicProxies allow you to provide a class that responds to the method calls on an interface at runtime. In this case the method calls are dispatched across to the corresponding methods on the remote server.
Both the service layer and DAO layer servers should be behind the firewall on the same domain.
From the UI, use REST web services to fetch the data from application server (hosting the DAO's and Transactional services). Annotate the entity classes with #Proxy(lazy=false) to avoid lazy loads of entities. For the server to validate the clients (web application querying the business layer behind firewall), use client identity certificates, you can use Bouncy Castle CMS APIs to validate the identity, trust and message integrity. If you have SSL offloaders in network, use detached signatures in http(s) headers.
Related
I am fairly new in microservices architecture. I've been trying to build a microservices stack using Spring Boot, Spring Cloud and Netflix OSS libraries.
I want to know what is the correct way and place to store session.
Here is an overview of the infrastructure that I created:
OAuth2 backed Authorization/Authentication Server
UI Service (Spring Boot, Front end service)
Backend Service-1
Backend Service-2
Redis Server to store session and other cachable data
Discovery Server (eureka)
Currently, I'm trying to store session in Redis by configuring UI service to perform it. It seems to be working fine, although I haven't had the chance to try it for multiple service instances. However, I'm already having serialization/deserialization issues while developing.
By the way, trying to store the session on front end app is the correct place to do or it should be done in Authorization/Authentication service as authentication is processed in that service?
Here is my Session config in UI service (front end service)
#Configuration
#EnableRedisHttpSession
public class SessionConfig extends
AbstractHttpSessionApplicationInitializer {
public SessionConfig() {
super(RedisConfig.class);
}
}
To sum up, I'm expecting to achieve and use best practices on this project. Your kind assistance would be appreciated.
The idea of a general server side user session and a microservices style architecture don't go together well. The reason being that you are likely to break the separation of concern that you use separate the domain boundaries of your services.
Remember, every service is supposed to service a specific domain problem autonomously - including all required data persistence. So for example if there is anything to remember for a users connected devices you would do that in the one service that is responsible for those device connections and nowhere else. The service would be responsible for processing those request and persisting any status that the devices require. Similarly when there is anything to remember about he users authorization you would do that in the authorization service.
And regarding the question to use Redis or not - In a microservices architecture the choice of storage system would be up to the service architect. Maybe one service stores its data in a relational database, maybe another uses a key-value-store and yet another may use an event queue system or a time series database.
So in summary you have to ask yourself what your session really is used for and make the corresponding services responsible to persist that information in a domain specific way. (If you give some more details in your question about this, I can give you my opinion).
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.
I am about to start creating a new application and wanted to get some feedback on the approach I plan on using. We will be using spring and spring data jpa.
Can controllers call domain services and repositories or should the controller only make calls to application and infrastructure services?
If its "ok" to call domain services and repositories from a controller and a domain service operation needs a transaction, can/should I just put the #Transactional annotation on the domain service method? Or should I have an application service that wraps the call (not sure I like this approach because you would end up with a bunch of pass through methods)?
If its not "ok" to call domain services and repositories from a controller do I need to create application services to wrap all possible domain service calls(like I said in 2 that could be a lot of pass through methods)?
The best solution I can come up with is something like the following:
Repositories will have the #Transactional annotation with propagation REQUIRED when writing to the database and propagation set to readOnly=true and propagation set to SUPPORTS when reading from the database.
Application and Domain Services will add the #Transactional annotation as needed
If the controller ever needs to make make a direct call to a repository a domain service or an application service it can. No pass throughs.
I am not clear for your question. What is the Domain Services doing? I knew Application Services and Domain Repositories very well.
In spring , there are two layers service and data access layer.
Service layer can used #Service (In your design it will be application Services) but not used #Transactional Tag.
Data access layer used #Repository Tag and also #Transactional Tag, Because This layer is directly connected and make operation with the Database. So, I like to know what 's function of the Domain Service. I am not clear for that.
Thanks buddy.
I personally would only access your domain and application services from your controllers. That way you only have to put #Transactional annotations at one "level". You get transactionality out of the box at your repository layer if you're extending the regular Spring Data repository interfaces. I would leave that layer as simple as possible. Put your readOnly and other configuration at the service layer.
Creating "pass through" methods allows you more flexibility down the road too if you ever decide to change your DAO implementation.
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.
I have following architecture in my application.
Client (GWT) <--calls--> Servlet <--calls--> Service <--calls--> Dao
I want to make this architecture easier for changes.
For example: when I want return the inserted id of an object from the Dao layer, because I need it in the client, I have to update the service and the servlet layer as well. So for this little change I have to update all 3 layers (3 classes and 3 interfaces) makes a change on 6 places.
I see why I need the Dao Layer.
I also get why I need the service layer.
What I don't get is why the service layer can't also be a servlet. At the moment all my servlets do is forwarding the request to the service layer.
The Wikipedia Article about Java Servlets says:
Servlets are most often used to
1 process or store data that was submitted from an HTML form
2 provide dynamic content such as the results of a database query
3 manage state information that does not exist in the stateless HTTP protocol
1 and 2 are just database calls, which I make in my dao layer and the service layer makes extra business logic already possible.
3 I am currently not working with sessions. I don't have a login so far and I am just playing around with my architecture, but I think the service layer could handle this as well.
I want to know the cos and pros for this architecture change:
pros:
One layer less to update if a change happens.
cons
Service Layer gets complexer.
Thx for your answers.
You need the servlet layer because that is what allows access to the session.
Also, you don't want your service layer to need to know anything about HTTP since you want to be able to re-use the service and DAO layers in other applications (e.g. if you write a desktop application re-using those layers) and needing to include the servlet API would not make sense there.
If needed you could call the DAO layer directly from a servlet for simple cases in order to not duplicate methods in the service and DAO layers.
The servlet API has filters which are a good place to implement security in your web application.
You can use Spring Security if you are already using the Spring framework for your web application.