Modèles d'architecture de services Web JAX-RS

Question

Quelles sont les pratiques courantes pour le développement de services Web JAX-RS?

Je pense que mon architecture a en quelque sorte d'une odeur à elle:

Le webservice agit en tant que mandataire, la collecte d'informations provenant de différentes sources. Il y a des fils RSS, des services SOAP et une base de données. Je voudrais faire abstraction de la source de données dans ma logique métier. C'est pourquoi je suis venu avec quelque chose comme ceci:

couche persistance:

| RSS Connector Parser   SOAP Interface(s)    Entities  | 
|  SomeRssDataDAO  SomeSoapDao AnotherSoapDap UserDao ...Dao  | 

Service Layer

| SomeRssDataService   SoapDataService  UserFavoritesService | 

"ressources" couche

|  JerseyResources that map HTTP to service methods      | 

La couche de service, ainsi que la couche de persistance serait des EJB.

Le problème auquel je fais face est que j'aurais des transactions dans la couche de persistance. Que se passe-t-il si un service doit utiliser plusieurs étapes pour faire son travail, ce qui ne serait pas correct à ce moment-là.

Mais l'utilisation de transactions/entitymanager dans ma couche de service ne semble pas correcte.

Quel est le chemin à parcourir?

De même, des conseils généraux d'architecture d'application d'entreprise seraient appréciés.

Answer 1

Je ne vois rien de mal à ce que les transactions soient gérées par la couche de service. C'est là que le contexte pour décider ce qui devrait être atomique est et devrait être.

Votre couche de service n'a pas besoin d'être un EJB sauf si vous envisagez de les distribuer. Vous pouvez utiliser des transactions JDO ou JPA pour gérer les opérations de persistance.

Votre "couche de persistance" n'a pas vraiment besoin d'être EJB, sauf si vous prévoyez de les distribuer.