I am trying to learn Spring Framework, before that I used to create application with EJBs
[Web services]->[Business Layer]->[DAO Layer] | [Database]
in following way
WebServices: Restful API using Jersey with url mappings, that support both JSON and XML format( news/list.json, news/list.xml). Once a request is received by an endpoint(url-mapped-method) it is forwarded to a relevant EJB through lookup(remote, local). EJB process every thing, apply business rules and return result as DTO(Data transfer object),Service then transform the result into required format (JSON, XML)
Business Layer: Business Layer (Facade) implemented in EJB with remote and local interfaces, these EJBs can call other EJBs. WebService layer(and/or Timer service and MDBs) can also call any of the EJBs). For timer service related functionality I used EJB Timer Service and for Messages used Message Drive Bean and interceptor for logging and auditing.
DAO Layer: All the Database related functions(add,edit, delete, search) JPA/Hibernate using EntityManager are written here (Entity beans and HQL).
Seamless Transaction support, each EJB's method (lookup-based) call is treated as a separate transaction and calling methods of DAO layer are part of same transaction(provided that no extra configuration is provided). multiple operations are carried out in a single transaction If one db operation fails all others are roll backed automatically. Each Table is mapped as an entity class with relations etc.
I have worked on Spring MVC but could not map/understand correctly for above architecture
I know bit about AOP and that I think is a perfect replacement for Interceptors (or at least it work for me)
Now my question is how all these could be replaced in Spring framework?
Jersey (RestAPi) alternative in Spring>
EJB alternative in Spring (as EJB supports remoting, each lookup call to a method is treated as a transaction, calls to EJB's method could be intercepted and it comes with state-full and stateless flavors)?
Timer Service alternative in Spring?
Message Drive Bean alternative in Spring?
Interceptor alternative is AOP in Spring (As per my experience and that serve my purpose)
JPA(entity manager) alternative in spring?
Jersey (RestAPi) alternative in Spring?
Spring MVC does this perfectly fine, in my opinion. Just annotate your methods in your controller as the REST apis you want to use.
EJB alternative in Spring (as EJB supports remoting, each lookup call to a method is treated as a transaction, calls to EJB's method could be intercepted and it comes with state-full and stateless flavors)?
There is no full alternative. There are several techniques that implement this in parts: Spring remoting for remote calls, Spring transactions as transactions, Spring AOP interceptors for intercepting calls. However, for example XA transactions on remote calls are something you don't get as such in Spring. Spring however works fine with EJBs, so if you prefer them, you can still have them and use Spring in other parts of your software.
Timer Service alternative in Spring?
Spring task scheduling
Message Drive Bean alternative in Spring?
Message Listener Containers
Interceptor alternative is AOP in Spring (As per my experience and that serve my purpose)
There are several levels of interceptors in spring. There are handler interceptors in mvc, there are bean call interceptors like the SpringAutowiringInterceptor, and there are AOP-based interceptors that can be used in multiple layers.
JPA(entity manager) alternative in spring?
Spring has multiple of these as well. It's actually quite straightforward to just use JPA with Spring-Data, it's designed to integrate to JPA. There are Spring JDBC and other data layer alternatives though if Spring Data is not what you want.
Jersey (RestAPi) alternative in Spring ⇨ it's rest api (in spring with #Path annotation) or spring mvc if you want to use controllers (#Controller annotation)!
EJB alternative in Spring ⇨ Spring doesn't give statefull bean out of a box but you can use #Service annotation (or #Repository for DAO) but you have to handle transactions manually (with annotations for example)
Message Drive Bean alternative ⇨ There is no equivalent out of the box in Spring, you could use injection and librairies of Spring to get it working (package org.springframework.jms should contains what you need)!
JPA(entity manager) alternative is not ejb ⇨ so it can be used in Spring.
Spring is a lighweight library so you can do all you do with EJB but it's more configurable so you will have more work to do the same that EJB do. But this configuration brings you some advantages: you have the hand on it!
This explains Spring and Java EE (which is what you would have used EJBs in) side by side: http://www.slideshare.net/reza_rahman/java-ee-and-spring-sidebyside-34320697
Jersey offers Spring solutions too - see their website
Spring does support remote calls through, e.g., RMI; It also supports transactions; AFAIK, no explicit stateful/stateless Spring Components - it depends on how you use it
AFAIK nothing as awesome as TimerService, however, you could use Quartz
Spring offers MDPs (Message-Driven POJOs)
Spring does support JPA - see first link.
Another cool comparison slideshare: http://www.slideshare.net/kelapure/java-e-evsspringshootout
Related
ive been tasked with a total refactor of legacy code. It's a simple webservice, just an http request, then business logic with possibly a few database calls and a few other microservice calls, then a json response. I am being pushed not to use spring boot because no one else around me has used it before, and I was told jersey does everything spring boot does. I've never used jersey so im trying to find out how to do things that spring boot makes simple (ie repository layer with spring-data, caching, spring-consul, spring-zuul, spring-actuator, spring-circuit-breaker) It looks like jersey does do an analog of spring-security, bean validation, and easy insertion of servlet filters, but not everything spring-boot does. Is there an easy way to wire in a JPA type repository in jersey? I cant find it in the docs at https://jersey.java.net/documentation/latest/index.html.
I think about it this way. There are different layers in your application. You have a service layer, and you have a "REST layer". You access the Spring repositories with the service layer. Then you have the REST layer. With Spring, you have Spring MVC which is its web layer implementation, that you can also use as REST services. There is also Jersey, which is completely independent of Spring, which is a another REST layer options.
That be said, when using Spring MVC as the REST layer, adding the service layer with Spring data is seamless. But Jersey also has integration with Spring, that allows us to use Spring at the service layer inside our Jersey REST services. You check out this post which has some links to example of how this can be done (no hacking, this is supported out of the box). Using this approach, you can just injector your Spring data repositories into your Jersey resource class
interface PetsRepository extends JpaRepository<Pets, Long> {}
#Path("/pets")
class PetsResource {
#Autowired
private PetsRepository repo;
}
Now lets talk about Spring Boot. Spring Boot is just a bootstrapping framework. What it does is allow you to easily bootstrap an application without all the boilerplate configuration you would need without it. When your using Spring Boot for your REST services, you're not actually using Spring Boot itself as the REST service engine. You are only using it to bootstrap Spring MVC and maybe your Spring Data. But Spring MVC is the actual REST service engine.
Now like I said before, Jersey has support for integrating Spring into into it (for the service layer). Because of this support, Spring Boot has also provided a bootstrap configuration to integrate this support seamlessly. So instead of using the manual configuration that you would see in one of the examples linked to above, Spring Boot handles this configuration for us. So we can use Jersey as the REST layer, and Spring beans as the service layer. Check out the links below
See also:
Spring Boot docs for Jersey support
I am attempting to read method annotations in my web layer that are defined on classes in my EJB3 layer.
The object I am working with is a JPA defined entity on my EJB layer that is being fetched with a local ejb lookup to my client layer. When I attempt to read the annotations on the methods they are missing. It appears that all of the annotations are being stripped off of the objects that are being passed from the EJB layer to the Client layer.
The annotation I would like to read is not one of the EJB or JPA annotations but something to drive the processing of the class on the web tier.
If this is typical behavior of the servers then I can write the process differently, annotating the class was the simplest solution.
Thanks
-Scott
OK, the ease of EJB 3 tripped me up here.
In the client of an EJB app I am not looking at an instance of the Class from the EJB tier but a generated instance based on a generated interface from the EJB layer. Therefore the annotations defined on the EJB layer class are not present in the client layer of the application.
I know that the general consensus is to use one or the other, but we have a specific task where we would like to use our spring services from within a stateless ejb timer.
Is there a standard way of getting a spring service from outside the normal flow of my web app? (Note I'm using the stripes framework and it has built in spring support and I'm using this built in support to access my spring services normally)
According to the Spring manual you can configure an EJB 3 injection interceptor that will take care of injecting #Autowired springbeans into your EJB Session Beans.
Can or should a Service layer be a Spring bean?
If so, how should it be got from a calling application, a consumer of a service?
Because the consumer must be aware that such a bean exists, so it in any case must use Spring
to make use of Service methods.
Of course. The service layer is the part of your application that is visible to other users (e.g. a Web layer) so it needs to be configured and setup somewhere. Imho a Spring configuration is the best place to put this configuration in. The Service Layer user then has to take care of instantiating that context and getting the Service Objects he needs.
An alternative - if it needs to run standalone - would be for your service class(es) implementing the Service Layer interface(s) to instantiate the Spring application context themselves.
By making your consumers also spring beans, and inject the service bean with dependency injection.
Yes, It is always nice to configure service beans as spring beans. In the web layer you need to take care of instantiating the needed service objects. Another option is to make the web layer classes also as spring beans and inject the necessary service layer spring beans. From the testing point of view also, this type of design is very helpful when we use Spring testing framework.
What role is Spring taking in Struts + Spring + Hibernate?
Spring provides many different "modules" and different programmers will use different parts of Spring.
However, commonly in this sort of stack, you will see Spring being used as a provider of
An inversion of control container for dependency injection
An abstraction to Hibernate called "HibernateTemplate"
Framework classes for simplifying Aspect Oriented Programming
Transaction support, often "declaratively" via the IoC container and AOP.
Well, Hibernate handles the persistence part, JSP handles your GUI, Struts controls the flow between pages/actions/etc, and Spring can manage all your beans which contain the main business logic, instead of using EJB. Plus it can simplify the coding of your Hibernate DAO's and transaction managing.
Instead of having to code your Locator to obtain some EJB through JNDI and all that stuff, you can just get the Spring ApplicationContext and ask for the bean you need. All the beans defined in Spring can be interconnected. If you have to connect one of your beans to an external EJB through JNDI you can even do so without any code (Spring offers a JNDI proxy object which obtains the reference you give it and returns it as an object with the interface you specify). This can help you simplify unit testing of all those beans and change the config without recoding anything; you can use one of Spring's PlatformTransactionManagers to manage a DataSource or point it to a J2EE container's JTA manager; define your own pooled DataSource or use your container's DataSource published through JNDI, etc.
Well to add;
(Views and Controllers) Struts for its extensive JSP features with Struts tags and web request handling features
(Service and application management) Spring to handle the ORM and service layers with its excellent dependency injections,etc.
(ORM with db independence) Hibernate for well proven ORM