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
Related
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
I have no development experience with Spring, since we're a Java EE shop. However, we are looking into a solution for our needs that runs on Spring and should integrate our existing Java EE solution.
After reading the Spring 3.0.5 documentation, I'm still uncertain how a transaction can be propagated from Spring to an EJB.
For instance, a Spring bean would create a transaction, save some stuff into one database and then hand over the transaction to one of our stateless session beans, which (using JPA) saves some other stuff into another database. And all of this must run under the same transaction, which is committed when the control is returned to the Spring bean.
Also, I'm not clear about the deployment: Would Spring run as a webapp in the EAR that contains the session beans?
if you configure Spring to use a JTATransactionManager and then call your SessionBean from within Spring the bean should actually pick up the Spring-created transaction. Have look here: http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/htmlsingle/spring-framework-reference.html#transaction-application-server-integration and the described <tx:jta-transaction-manager/>
I actually only did it the other way around (joining EJB Transaction in spring) so I'm not completely sure, but you can easily test it by setting
#TransactionAttribute(TransactionAttributeType.MANDATORY)
on your SessionBean and call it from spring... if there's not existing Transaction you will end up with a TransactionRequiredException
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.
I want to use an EJB3 from within my Tapestry Page class, I can do JNDI lookup for it, but it will me much convenient to use EJB injection or Tapestry IoC. Is that possible?
Of course! You can either contribute your EJBs via Tapestry's IOC container, so you would do the JNDI lookup in your build methods instead of all over your code (see the manual for information).
Or you could wire up your EJBs as Spring beans (see the Spring EJB documentation for details), and use Tapestry-Spring to allow injecting them into your components via #Inject.