Existe-t-il une méthode préférée pour mettre à jour les applications qui utilisent un EJB?

Question

J'ai une application Java qui fonctionne avec un EJB, mais si:

1. L'EJB est mis à jour, l'application est endommagée.
2. Le serveur d'application est mis à jour, l'application est endommagée.

Sans implication humaine, existe-t-il une méthode préférée pour mettre à jour les fichiers jar du client pour le serveur d'applications et le bean?

Si la méthode préférée dépend du serveur d'applications, supposons que jboss.

Answer 1

C’est l’une des raisons pour lesquelles les gens migrent vers les services Web :) Ou aussi avec JMS.

Vraiment, si votre serveur d'applications est mis à niveau ou si votre fournisseur est modifié, vos anciens stubs étrangers / étrangers ne fonctionneront certainement pas avec le nouveau code côté serveur. : - (

Vous souvenez-vous que EJB a déclaré qu'il devrait exister un rôle de déployeur d'applications? C’est à lui de préparer client.jar pour les applications clientes et de le distribuer (ou bien il s’agit bien de l’emballeur d’applications d’application? L’important est que ce n’est pas une opération automatique ).

Certaines astuces peuvent être possibles (par exemple, il est très difficile de placer client.jar à un emplacement spécifique sur le serveur, puis de le télécharger par client, puis d'utiliser le chargeur de classes), mais il s'agit de plus de piratages que de pratiques établies.

En ce qui concerne les spécificités de JBoss, je n’ai aucune information.

Answer 2

Votre problème fondamental est que si le contrat d'interface entre un composant change, il rompt l'autre. Ce problème n’est pas limité aux applications et aux EJB, il n’est pas sûr pour le compilateur.

La seule approche automatisée que je connaisse consiste à configurer vos projets de manière à rendre le projet d'application dépendant du projet EJB (au sein de l'EDI et des fichiers de construction), ce qui vous permet de vérifier le compilateur. Et en les déployant ensemble comme une EAR.

Si ce n'est pas une option et si elles doivent être déployées séparément, votre développeur EJB doit être en mesure de garder intactes les interfaces rétrocompatibles.