Adding rest service to a struts application

Question

我正在尝试使用jersey为struts应用程序添加休息服务。为此我需要以这样的方式隔离java代码，以便struts和rest api可以共同访问它。这样做是为了使代码是在休息和支柱之间共享，任何变化都会反映在两种服务中。我想知道，这个想法有多少是可行的，而这就是人们通常设计休息服务的方式。

Answer 1

While our presentation layer isn't Struts based (usually it's either Spring Web MVC or JSF), we use Spring 3.0 + Java EE 6, specifically, EJB 3.0 and JPA 2.0 for such situations.

EJB 3.0 stateless session beans work great—they can have declarative (annotation-based) dependency injection and transaction demarcation, or they can manage their transactions, dependencies and resources themselves using whatever traditional mechanism. They seamless integrate with JPA 2.0 and are easy enough to unit test. The main advantage over pure Spring beans is that they can be deployed independently of the Web application (as an EJB JAR).

On the front-facing Web services, we also use Jersey/JAX-RS. Because Jersey/JAX-RS dependency injection is broken (it doesn't use Weld/CDI like the rest of Java EE), we've had to resort to Spring DI to 'wire' up the front-facing REST resource classes with the 'back-end' EJBs. The good thing is this works well enough to inject the EJBs into our MVC controllers and can also be used with JSF managed beans. Alternatively, you can write your REST-ful resources using Spring alone (either way has its own pros/cons, but in general both do the job well).

I know I glossed over the whole thing but I'd be glad to share more details upon request.

---

EDIT: Some more details, as per request.

You're first stop for learning Jersey/JAX-RS would have to be the Jersey User Guide . There are also several tutorials/examples you can easily find across the 'Net.

While you should be able to package Jersey/JAX-RS resources into the same WAR as your Struts pages, we went with the simpler alternative of deploying them separately.

Now, when deploying to Glassfish 3.1, we hit this bug, also documented here . The bottom line is that @EJB injection didn't work for us as expected.

So, instead, we fell back on to Spring using the jersey-spring contrib module, following this example .

Anyway, the rest of it is standard Java EE 6 / EJB 3.0. We identify and place all common functionality into a 'service' layer which are largely implemented as @Stateless EJBs.

Persistence is handled through JPA @Entity s accessed through a JPA inject EntityManager . Transactions are declaratively demarcated using @TransactionAttribute .

Here's a quick illustration of a typical EJB + JPA service bean:

@Stateless
public class WidgetServiceBean implements WidgetService {

    @PersistenceContext
    private EntityManager em;

    @Override
    public List<Widget> findWidgetByName(String name) {
        return em.createNamedQuery("Widget.findByName", Widget.class)
            .setParam("name", name).getResultList();
    }

    @Override
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void removeWidgetById(int id) {
        em.find(Widget.class, id).remove();
    }
}

(Obviously not production quality but just shows how 'lean' they can be.)

The service layer and entities are packaged as an EJB JAR which can be deployed separately, and made available to all other modules via global JNDI lookup. Or, they can be deployed within the Struts or JAX-RS WAR and as of Java EE 6 (Glassfish 3.x) they will be found, deployed as part of the module and made available to other components within the same WAR.

Some might argue that it's simpler to just use Spring beans if you're using the Spring container anyway. I would say, probably, but then you also have to use Spring's persistence framework, and Spring's transaction framework. (Spring also provides declarative transactions and persistence.) If you're already heavily invested into Spring then that might be an easier path.

OTOH, EJB 3.0, JPA 2.0 and JTA have also been radically simplified from their predecessors and are part of the Java EE standard so it's an architectural decision with a lot of dimensions.