Auteur : Zhu Xianzhong Source du compilateur : Tianji.com
Résumé Cet article explique comment réaliser l'interaction entre votre application ASP.NET et le serveur d'applications J2EE et comment rendre l'appel d'EJB aussi simple que l'appel d'un service Web XML.
Introduction
Aujourd'hui, de nombreuses grandes organisations disposent et utilisent des équipes de développement et des serveurs de publication qui sont un mélange de technologies .NET et J2EE. Afin d'équilibrer la qualité d'entreprise envoyée via le serveur d'applications J2EE, la logique métier d'une entreprise est souvent publiée sur le serveur d'applications J2EE sous la forme d'entreprise JavaBeans (EJB). D'autre part, afin de répondre aux exigences en constante évolution du développement commercial, la plupart des développeurs préfèrent implémenter une logique de description dans l'environnement de développement Visual Studio.NET avec des performances de production élevées. Le défi se pose lorsque vous devez connecter la couche de présentation .NET à la couche de logique métier J2EE.
Voyons comment Visual MainWin pour J2EE peut vous aider à faire face et à surmonter - à partir de Visual Studio.NET, utilisez C# ou Visual Basic.NET pour implémenter la couche de description ASP.NET, puis appelez la couche de logique métier implémentée sous la forme de EJB - c'est difficile à développer. Rassurez-vous, vous n'aurez pas besoin de vous embêter avec le codage de l'API EJB pour ce faire. Avec Visual MainWin pour J2EE, les deux couches - le frontal ASP.NET et le back-end EJB - peuvent s'exécuter comme une application J2EE pure sur votre serveur d'applications J2EE, avec une optimisation des performances et une sécurité cohérente basée sur J2EE.
Pour appeler des EJB depuis Visual Studio .NET, vous devez installer la version entreprise de Visual MainWin pour J2EE. Bien entendu, vous pouvez télécharger sa version d'évaluation depuis le site Web mainsoft.com pour une analyse expérimentale.
Exemple d'analyse
L'exemple StocksPortfolio de cet article, qui vous montre comment créer une application à l'aide d'une couche Web ASP.NET et d'une couche métier J2EE, est installé et documenté dans Visual MainWin pour J2EE. Cet exemple implémente une simple page Web ASP.NET (utilisée par les utilisateurs pour gérer leurs investissements en actions) et un service Web ASP.NET (utilisé pour fournir des cotations boursières fictives). Cet exemple utilise également un EJB de session - utilisé par votre serveur d'applications J2EE pour implémenter la logique d'achat et de vente d'actions.
Figure 1. Application StocksPortfolio exécutée sur le serveur d'applications JBoss
Ajoutez des EJB à votre environnement .NET
Appeler un EJB à partir de Visual Studio.NET est aussi simple que d'appeler un service Web. Dans votre Explorateur de solutions, cliquez avec le bouton droit sur « Références » et sélectionnez « Ajouter une référence EJB ». Un nouveau type de référence apparaîtra et ne peut être utilisé que dans Visual MainWin pour les projets J2EE, qui est très similaire à la référence Web standard de Visual Studio sous. NETIDE (voir Figure 2).
Figure 2. Ajout d'une référence EJB
Pour ajouter une référence EJB à votre projet Visual MainWin pour J2EE, vous n'avez besoin que d'un fichier d'archive Java (JAR) - un fichier qui implémente l'EJB ou contient ses interfaces locales et distantes. Visual MainWin peut interroger le serveur d'applications pour obtenir des informations sur tous les EJB qui y sont publiés et afficher les EJB correspondant à votre définition JAR dans une boîte de dialogue. Il vous suffit de sélectionner l'EJB spécifique (éventuellement plusieurs) que vous souhaitez utiliser (voir Figure 3).
Figure 3. Boîte de dialogue Ajouter une référence EJB
Vous pouvez également utiliser l'EJB sur un serveur d'applications distant, à condition qu'il soit du même type que le serveur d'applications local associé à votre projet. Il peut s'agir d'un serveur Windows, Linux, Unix, Mainframe ou de tout autre serveur compatible J2EE. Pour consommer un EJB publié sur un serveur distant, cliquez sur "Avancé" pour développer la boîte de dialogue (voir Figure 4).
Figure 4. Boîte de dialogue Ajouter une référence EJB en mode avancé
Saisissez l'URL JNDI du serveur d'applications J2EE distant et cliquez sur « Extraire du serveur ». Visual MainWin listera tous les EJB publiés sur le serveur distant et les EJB qui correspondent à votre fichier JAR. Cette opération est cohérente avec les EJB locaux.
Sélectionnez l'EJB que vous souhaitez consommer (il peut y en avoir plusieurs) et cliquez sur OK. Un nouveau dossier de référence EJB est créé dans votre navigateur Explorateur de solutions, comme le montre la figure 5. Ce dossier contient une référence basée sur le serveur pour chaque référence EJB nouvellement ajoutée, similaire à un nœud de référence Web. De plus, une classe wrapper est générée pour simplifier le codage de vos appels EJB. Nous discuterons de cette classe wrapper dans une section ultérieure.
Figure 5. Dossier de l'Explorateur de solutions affichant la référence EJB
Appel de méthodes EJB à partir de .NET
Lorsque vous ajoutez une référence EJB à votre projet, le système génère automatiquement une classe .NET (C# ou VB.NET). Elle décrit une interface simple avec l'EJB. . Cette classe inclut le codage J2EE requis pour créer l'EJB et appeler ses méthodes. Cette classe .NET expose les méthodes de l'interface distante EJB via ses propres méthodes publiques. Pour appeler les méthodes métier de votre EJB, il vous suffit de créer une instance de la classe wrapper et d'appeler la méthode de classe wrapper appropriée.
Voici un exemple de code pour appeler une méthode EJB à partir de votre projet .NET :
//Créez une instance de l'EJB StockTrader.
localhost.StockTraderEJB trader = new localhost.StockTraderEJB();
//Acheter le titre défini par l'utilisateur dans la zone de texte du nom du titre,
//Le nombre d'actions achetées correspond au nombre indiqué dans la zone de texte Nombre d'actions
trader.buy(tbStockName.Text, Int32.Parse(tbNumOfShares.Text));
L'analyse approfondie
exécute l'appel J2EE demandé dans le constructeur statique de la classe wrapper générée ci-dessus pour créer l'objet home de l'EJB. Ensuite, dans un constructeur par défaut, il utilise l'objet home pour créer l'objet EJB. L'objet EJB est stocké en tant que membre de classe wrapper via lequel les méthodes EJB métier sont appelées.
Ce qui suit fait partie du code permettant de créer la classe wrapper de l'EJB StockTrader :
private static trading.StockTraderHome home ;
trading privé.StockTraderEJB ejbObj;
statique StockTraderEJB() {
// Créer un contexte Java Naming (JNDI)
Contexte contextuel ;
contexte = vmw.j2ee.J2EEUtils.CreateContext(null, null);
objet homeObj;
//Récupère l'objet home du serveur JNDI
homeObj = context.lookup("ejb/StockTrader");
home = ((trading.StockTraderHome)(homeObj));
}
//Constructeur par défaut : Créer une nouvelle instance d'EJB
public StockTraderEJB() {
this.ejbObj = home.create();
}
Cette classe wrapper expose les méthodes de l'interface distante EJB via ses méthodes publiques. Chacune de ces méthodes appelle ensuite la méthode métier correspondante de votre EJB via l'objet EJB. Le code suivant vous montre la méthode du trader en actions dans le wrapper EJB :
public virtual void buy(string arg_0, int arg_1) {
this.ejbObj.buy(arg_0, arg_1);
}
vente publique virtuelle vide (string arg_0, int arg_1) {
this.ejbObj.sell(arg_0, arg_1);
}
Visual MainWin est également responsable du mappage des types de données entre Java et .NET. Par exemple, si l'une des méthodes de votre EJB reçoit un objet java.lang.calendar en tant que paramètre, vous appellerez cette méthode avec un paramètre d'objet .NET System.DateTime et la mapperez à un java.lang sur l'objet calendrier. Par la suite, si votre méthode EJB renvoie un java.lang.class, vous recevrez un objet System.Type à la place.
Problèmes de débogage
Même si Visual MainWin simplifie le développement, vous devrez peut-être déboguer vos applications ASP.NET/EJB mixtes à plusieurs niveaux. Le débogueur Visual MainWin vous permet de déboguer vos applications hybrides à partir de l'IDE Visual Studio .NET. Vous pouvez définir des interruptions dans votre code C# ou VB.NET, accéder au code Java EJB et déboguer l'intégralité de votre application au-delà des frontières linguistiques. Et comme le débogage doit être présent partout où le problème survient, le débogueur Visual MainWin peut être attaché à votre serveur d'applications J2EE, qu'il s'exécute sous Linux, Unix ou d'autres frameworks, à condition qu'il puisse s'exécuter sur le débogueur. le motif.
Figure 6. Utilisation du débogueur Visual MainWin pour déboguer le code source d'EJB
L'application créée par Visual MainWin pour vous est une application de servlet J2EE standard. Elle peut être publiée et gérée via la console du gestionnaire de serveur d'applications J2EE, comme n'importe quel autre J2EE. Identique au servlet. application. Par conséquent, votre couche de présentation ASP.NET et votre couche de logique métier EJB peuvent s'appuyer sur la même infrastructure de sécurité J2EE. Vos applications hybrides ASP.NET/EJB peuvent s'appuyer sur un modèle de sécurité cohérent grâce à l'utilisation de l'authentification de servlet J2EE, et les définitions d'utilisateur et de rôle de votre serveur d'applications peuvent garantir la sécurité en équilibrant les mécanismes d'autorisation basés sur les rôles.
Résumé
1. Cet article traite des objets et des interfaces distants. La consommation locale d'objets via Visual MainWin est également possible. Afin de distribuer une application qui utilise des objets natifs, vous devez créer un fichier d'archive d'entreprise (EAR) qui contient à la fois le fichier WAR de votre application et le fichier JAR de l'EJB local.
2. Bien que Visual MainWin puisse mapper la plupart des types .NET aux types Java, il ne peut pas mapper les types de collection, car ce mappage peut entraîner une dégradation des performances. Par conséquent, vous pouvez choisir de gérer les types de collections Java à partir de votre code .NET ou d'effectuer ces conversions vous-même.
3. Visual MainWin vous permet de consommer des beans session et des beans entité non transactionnels. Les beans d'entité transactionnelle ne peuvent pas être consommés de manière transparente, vous devez donc coder manuellement les appels de transaction J2EE. Cependant, dans la plupart des cas, les beans d'entité transactionnelle sont accessibles via les beans de session, il est donc peu probable que vous ayez besoin de le faire.
