J'espère que cette question n'est pas trop abstraite. Ceci concerne l'architecture Java EE ou la conception de services. J'ai deux logiques d'affaires (simplifié ici pour faciliter la lecture):Dépendances du service Java EE
@Stateless
@LocalBean
public class EmailService {
@EJB
private SomeBean someBean;
// ... some other EJBs to acces the DB layer (and using JPA)
public void sendEmail(String recipient /* some parameters */) {
// ... some email sending logic here
}
}
@Stateless
@LocalBean
public class ExecutePaymentService {
@EJB
private UserBean userBean;
// ... some other EJBs to acces the DB layer (and using JPA)
public void executePayment(int amount, int userId) {
// ... some payment logic here
// NEED TO SEND EMAIL HERE
}
}
La conception que j'ai est que les haricots JSF Managed appellent les services ci-dessus. Mon problème est que les haricots gérés contiennent une certaine logique:
- exécuter le paiement
- En cas de paiement email réussie d'envoi
- IF ne pas faire quelque chose d'autre
Je veux avoir cette logique dans les EJB de services pour la Les beans gérés collectent uniquement les entrées et les résultats.
Les autres options sont que ExecutePaymentService étend EmailService puis appelez le sendEmail stuff. Cela peut conduire à un arbre d'héritage énorme pour pouvoir fournir n'importe quel service à partir de n'importe quel service, plus difficile à maintenir sur le long terme et grande application .... Puisque la plupart des services doivent avoir injecté EJB pour accéder à la base de données je ne peux pas utiliser services non-EJB ....
Quelle serait une meilleure façon de permettre un service to call another service?
Si vous avez la possibilité d'utiliser un ESB, cette logique de choix peut être implémentée à l'aide d'un outil tel que Drools. La logique métier présentée est en quelque sorte liée à la structure Factory, si elle est définie comme une énumération de type de service. Vous pouvez déclarer une interface avec des méthodes communes et utiliser une classe avec @WebService (endpointInterface = "package.MyPaymentInterface"). –
Merci pour votre suggestion. Je ne pense pas que nous puissions mettre en œuvre ESB à ce stade, mais je vais le garder comme une option lorsque nous avons besoin d'une nouvelle plate-forme. – JScoobyCed
Une petite suggestion: vous n'avez pas besoin de '@ LocalBean'. Il est très tentant d'en mettre un là-bas, mais s'il ne fait absolument rien dans votre situation; un bean sans état sans interface métier expose déjà automatiquement une vue sans interface, ce qui est exactement le but de '@ LocalBean'. –