Author: Zhu Xianzhong Compiler source: Tianji.com
Abstract This article will introduce how to realize the interaction between your ASP.NET application and J2EE application server and how to make calling EJB as easy as calling XML Web service.
Introduction
Today, many large organizations find themselves having and using development teams and publishing servers that are a mix of .NET and J2EE technologies. In order to balance the enterprise quality sent through the J2EE application server, a company's business logic is often published on the J2EE application server in the form of enterprise JavaBeans (EJB). On the other hand, in order to meet the ever-changing requirements of business development, most developers prefer to implement description logic in the Visual Studio.NET development environment with high production performance. The challenge arises when you need to connect the .NET presentation layer to the J2EE business logic layer.
Let's take a look at how Visual MainWin for J2EE can help you face and overcome - from Visual Studio.NET, use C# or Visual Basic.NET to implement the ASP.NET description layer and then call the business logic layer implemented in the form of EJB - this Challenging to develop. Rest assured, you won't need to mess with EJB API coding to do this. With Visual MainWin for J2EE, both layers - the ASP.NET front-end and the EJB back-end - can run as a pure J2EE application on your J2EE application server, with performance optimization and consistent J2EE-based security.
In order to call EJBs from Visual Studio .NET, you must install the enterprise version of Visual MainWin for J2EE. Of course, you can download its evaluation version from the mainsoft.com website for experimental analysis.
Example Analysis
This article's StocksPortfolio example - which shows you how to create an application using an ASP.NET Web layer and a J2EE business layer - is installed and documented in Visual MainWin for J2EE. This example implements a simple ASP.NET web page - used by users to manage their stock investments - and an ASP.NET Web service - used to provide fictional stock quotes. This example also uses a session EJB - used by your J2EE application server to implement the logic for buying and selling stocks.
Figure 1. StocksPortfolio application running on JBoss application server
Add EJBs to your .NET environment
Calling an EJB from Visual Studio.NET is as easy as calling a Web service. In your Solution Explorer, right-click "References" and select "Add EJB Reference". A new reference type will appear that can only be used in Visual MainWin for J2EE projects, which is very similar to the standard Visual Studio. Web reference under NETIDE (see Figure 2).
Figure 2. Adding an EJB reference
To add an EJB reference to your Visual MainWin for J2EE project, you only need a Java archive (JAR) file - one that implements the EJB or contains its local and remote interfaces. Visual MainWin can query the application server for information about all EJBs published on it and display the EJBs corresponding to your JAR definition in a dialog box. You just need to select the specific EJB (possibly multiple) you want to use (see Figure 3).
Figure 3. Add EJB Reference dialog box
You can also consume the EJB on a remote application server, as long as it is the same type as the local application server associated with your project. This could be a Windows, Linux, Unix, Mainframe or any other J2EE enabled server. To consume an EJB published on a remote server, click "Advanced" to expand the dialog box (see Figure 4).
Figure 4. Advanced mode Add EJB Reference dialog box
Enter the JNDI URL to the remote J2EE application server and click "Fetch From Server". Visual MainWin will list all EJBs published on the remote server and the EJBs that correspond to your JAR file. This operation is consistent with local EJB.
Select the EJB you want to consume (there may be multiple) and click OK. A new EJB reference folder is created in your Solution Explorer browser, as shown in Figure 5. This folder contains a server-based reference for each newly added EJB reference, similar to a Web reference node. In addition, a wrapper class is generated to simplify your EJB call coding. We will discuss this wrapper class in a later section.
Figure 5. Solution Explorer folder showing EJB reference
Calling EJB methods from .NET
When you add an EJB reference to your project, the system will automatically generate a .NET (C# or VB.NET) class. It describes a simple interface to the EJB. This class includes the J2EE coding required to create the EJB and invoke its methods. This .NET class exposes the methods of the EJB remote interface through its own public methods. To call your EJB's business methods, you simply create an instance of the wrapper class and call the appropriate wrapper class method.
Here is a code example for calling an EJB method from your .NET project:
//Create an instance of the StockTrader EJB.
localhost.StockTraderEJB trader = new localhost.StockTraderEJB();
//Buy the stock defined by the user in the stock name text box,
//The number of shares purchased corresponds to the number in the number of shares text box
trader.buy(tbStockName.Text, Int32.Parse(tbNumOfShares.Text));
In-depth analysis
executes the requested J2EE call in the static constructor of the wrapper class generated above to create the home object of the EJB. Then, in a default constructor, it uses the home object to create the EJB object. The EJB object is stored as a wrapper class member through which business EJB methods are called.
The following is part of the code to create the wrapper class of the StockTrader EJB:
private static trading.StockTraderHome home;
private trading.StockTraderEJB ejbObj;
static StockTraderEJB() {
// Create a Java Naming (JNDI) context
Context context;
context = vmw.j2ee.J2EEUtils.CreateContext(null, null);
object homeObj;
//Get the home object from the JNDI server
homeObj = context.lookup("ejb/StockTrader");
home = ((trading.StockTraderHome)(homeObj));
}
//Default constructor: Create a new EJB instance
public StockTraderEJB() {
this.ejbObj = home.create();
}
This wrapper class exposes the methods of the EJB remote interface through its public methods. Each of these methods then calls the corresponding business method of your EJB through the EJB object. The following code shows you the stock trader method in the EJB wrapper:
public virtual void buy(string arg_0, int arg_1) {
this.ejbObj.buy(arg_0, arg_1);
}
public virtual void sell(string arg_0, int arg_1) {
this.ejbObj.sell(arg_0, arg_1);
}
Visual MainWin is also responsible for mapping data types between Java and .NET. For example, if one of your EJB's methods receives a java.lang.calendar object as a parameter, then you would call that method with a .NET System.DateTime object parameter and map it to a java.lang. on the calendar object. Subsequently, if your EJB method returns a java.lang.class, you will receive a System.Type object instead.
Debugging Issues
Even though Visual MainWin simplifies development, you may still need to debug your multi-level, mixed ASP.NET/EJB applications. The Visual MainWin debugger allows you to debug your hybrid applications from within the Visual Studio .NET IDE. You can set interrupts in your C# or VB.NET code, step into EJB Java code, and debug your entire application across language boundaries. And, because debugging needs to be present wherever the problem occurs, the Visual MainWin debugger can be attached to your J2EE application server, regardless of whether it is running on Linux, Unix or other frameworks, as long as it can run on the debugger Just the pattern.
Figure 6. Using the Visual MainWin debugger to debug EJB source code
The application that Visual MainWin creates for you is a standard J2EE servlet application - it can be published and managed through the J2EE Application Server Manager Console, just like any other J2EE Same as servlet application. Therefore, your ASP.NET presentation layer and your EJB business logic layer can rely on the same J2EE security infrastructure. Your hybrid ASP.NET/EJB applications can rely on a consistent security model through the use of J2EE servlet authentication, and your application server user and role definitions can ensure security by balancing role-based authorization mechanisms.
Summary
1. This article discussed remote objects and interfaces. Local object consumption via Visual MainWin is also possible. In order to distribute an application that uses native objects, you must create an enterprise archive (EAR) file - which contains both your application's WAR file and the local EJB's JAR file.
2. Although Visual MainWin can map most .NET types to Java types, it cannot map collection types - because this mapping may cause a performance penalty. Therefore, you can choose to handle Java collection types from your .NET code or perform such conversions yourself.
3. Visual MainWin allows you to consume session beans and non-transactional entity beans. Transactional entity beans cannot be consumed transparently, so you must manually code J2EE transaction calls. However, in most cases transactional entity beans can be accessed through session beans, so you are unlikely to need to do this.
