Distributed application development is a feature of JBuilder Enterprise.
This chapter discusses creating a distributed application using JBuilder, VisiBroker, and the Common Object Request Broker Architecture (CORBA).
The Common Object Request Broker Architecture (CORBA) allows distributed applications to interoperate (application to application communication), regardless of what language they are written in or where these applications reside.
The CORBA specification was adopted by the Object Management Group to address the complexity and high cost of developing distributed object applications. CORBA uses an object-oriented approach for creating software components that can be reused and shared between applications. Each object encapsulates the details of its inner workings and presents a well defined interface, which reduces application complexity. The cost of developing applications is reduced, because once an object is implemented and tested, it can be used over and over again.
The Object Request Broker (ORB) (shown in Figure 1) connects a client application with the objects it wants to use. The client program does not need to know whether the object implementation it is in communication with resides on the same computer or is located on a remote computer somewhere on the network. The client program only needs to know the object's name and understand how to use the object's interface. The ORB takes care of the details of locating the object, routing the request, and returning the result.
VisiBroker for Java provides a complete CORBA 2.3 ORB runtime and supporting development environment for building, deploying, and managing distributed Java applications that are open, flexible, and inter-operable. Objects built with VisiBroker for Java are easily accessed by Web-based applications that communicate using OMG's Internet Inter-ORB Protocol (IIOP) standard for communication between distributed objects through the Internet or through local intranets. VisiBroker has a native implementation of IIOP to ensure high-performance and inter-operability.
JBuilder provides a set of wizards and other tools to make development of CORBA applications simple, well, as simple as a CORBA application can get anyway. The chapter "CORBA Tools" explains the various CORBA tools and wizards and how they can be used to create CORBA and other distributed applications.
This chapter includes a tutorial to help you become acquainted with some of the JBuilder and VisiBroker for Java development tools, and explores developing a distributed, object-based application using JBuilder and VisiBroker for Java. A sample application, "Tutorial: creating a CORBA application in JBuilder", is used to illustrate each step of the process.
When you develop distributed applications with JBuilder and VisiBroker, you must first identify the objects required by the application. You will then usually follow these steps:
IDL is the language that an implementer uses to specify the operations that an object will provide and how they should be invoked. In this example, we define, in IDL, the Account
interface with a balance()
method and the AccountManager
interface with an open()
method.
Using the idl2java
compiler, we'll produce client-side stubs (which provide the interface to the Account
and the AccountManager
objects' methods) and server-side classes (which provides classes for the implementation of the remote objects).
To complete the implementation of the client program, initialize the ORB, bind to the Account
and the AccountManager
objects, invoke the methods on these object, and print out the balance.
To complete the implementation of the server object code, we must derive from the AccountPOA
and AccountManagerPOA
classes, provide implementations of the interface
's method, and implement the server's main
routine.
To create the client program, compile the client program code with the client stub. To create the Account
server, compile the server object code with the server servants.
For more advanced information on using JBuilder and VisiBroker to create distributed applications, see the VisiBroker for Java Programmer's Guide, and the VisiBroker for Java Reference Guide, available from the doc
directory of your VisiBroker for Java installation.
For more information about Common Object Request Broker Architecture (CORBA), some useful links are:
In this tutorial, you will explore a sample client application that can query on the balance in a bank account. This tutorial provides the steps to create the basic files needed to run and deploy a simple, CORBA-based distributed application.
From this example, you will learn how to
Account
and AccountManager
.
AccountManager
object, obtain the balance, print the balance, and handle exceptions.
AccountManager
server, and run the client program.
This tutorial assumes that you are familiar with the JBuilder development environment. If you are new to JBuilder, refer to "The JBuilder environment" in Building Applications with JBuilder for an introduction.
.../jbproject/BankTutorial/BankTutorial.jpx
, to .../jbproject/Bank/BankTutorial.jpx
.
The BankTutorial project appears in the project pane. It currently includes one file, BankTutorial.html
, which displays the information entered in the Project wizard. Next, we will define the object interfaces by writing the account interface in IDL.
The first step to creating a CORBA application is to specify all of your objects and their interfaces using the OMG's Interface Definition Language (IDL). IDL has a syntax similar to C++ and can be used to define modules, interfaces, data structures, and more. The IDL can be mapped to a variety of programming languages. The IDL mapping for Java is summarized in the VisiBroker for Java Reference Guide.
This topic shows how to create the BankTutorial.idl
file for this example. The Account
interface provides a single method for obtaining the current balance. The AccountManager
interface creates an account for the user if one does not already exist.
To create the IDL file, and define the object interfaces,
BankTutorial.idl
in the File Name field. Click OK. A sample IDL file is created and added to the project.
module Bank { interface Account { float balance(); }; interface AccountManager { Account open(in string name); }; };
Next, you use the VisiBroker IDL compiler, named idl2java
, to generate stub routines and servant code from the IDL specification. The stub routines are used by your client program to invoke operations on an object. You use the servant code, along with code you write, to create a server that implements the object. The code for the client and object, once completed, is used as input to your Java compiler to produce a client Java applet or application and an object server.
The interface specification you create in IDL is used by the idl2java
compiler to generate Java classes for the client program, and skeleton code for the object implementation. The Java classes are used by the client program for all method invocations. You use the skeleton code, along with code you write, to create the server that implements the objects.
The code for the client program and server object, once completed, is used as input to your Java compiler to produce the client and server executables classes.
To generate the client stubs and server servants,
BankTutorial.idl
file in the project pane.
idl2java
compiler.
If the file had required special handling, you can set IDL properties by right-clicking the IDL file in the project pane, and selecting Properties. This dialog enables you to specify options for compiling remote interfaces defined in IDL.
Because Java allows only one public interface or class per file, compiling the IDL file will generate several .java
files. These files are stored in a generated sub-directory called Generated Source
, which is the module name specified in the IDL and is the package to which the generated files belong. You can view the generated files by clicking the expand glyph beside BankTutorial.idl
.
The following files are generated:
_AccountManagerStub.java
--Stub code for the AccountManager
object on the client side.
_AccountStub.java
--Stub code for the Account
object on the client side.
Account.java
--The Account
interface declaration.
AccountHelper.java
--Declares the AccountHelper
class, which defines helpful utility methods.
AccountHolder.java
--Declares the AccountHolder
class, which provides a holder for passing Account
objects.
AccountManager.java
--The AccountManager
interface declaration.
AccountManagerHelper.java
--Declares the AccountManagerHelper
class, which defines helpful utility methods.
AccountManagerHolder.java
--Declares the AccountManagerHolder
class, which provides a holder for passing AccountManager
objects.
AccountManagerOperation.java
--This interface provides declares the method signatures defined in the AccountManager
interface in the Bank.idl
file.
AccountManagerPOA.java
--POA servant code (implementation base code) for the AccountManager
object implementation on the server side.
AccountManagerPOATie.java
--Class used to implement the AccountManager
object on the server side using the tie mechanism. For more information about the tie mechanism, see the VisiBroker for Java Programmers Guide, Chapter 9, "Using the tie mechanism."
AccountOperations.java
--This interface provides declares the method signatures defined in the Account
interface in the Bank.idl
file
AccountPOA.java
--POA servant code (implementation base code) for the Account
object implementation on the server side.
AccountPOATie.java
--Class used to implement the Account
object on the server side using the tie mechanism. For more information about the tie mechanism, see the VisiBroker for Java Programmers Guide, Chapter 9, "Using the tie mechanism."
For more information about the Helper, Holder, and Operations classes, see the "Generated Classes" chapter in the VisiBroker for Java Reference Manual.
Many of the classes used in implementing the bank client are contained in the Bank
package generated by the idl2java
compiler as shown in the previous example. This next set of steps creates a Java client to further illustrate this example.
To create the client,
BankTutorial.idl
as the IDL file. The other fields are automatically generated.
Bank.AccountManager
from the Interface list.
myAccountManager
. Click Finish.
Bank.Account
as the Interface.
Frame1.java
in the Project pane. Select Make.
Files named AccountClientImpl1.java
and AccountManagerClientImpl1.java
display in the Project pane.
AccountManager
) to the Object Request Broker (ORB). To do this,
OrbConnect
object.
OrbConnect
object to the Frame.
myAccountManager
in the Structure pane.
orbConnect1
from the ORBConnect
property in the Inspector.
OrbConnect
object in the structure pane.
initialize
property to true using the Inspector.
To bind the wrapper class at runtime,
contentPane
object from the Structure pane.
layout
property to XYLayout
.
JButton
control from the Swing tab of the Component palette. Click in the Design pane to add a JButton to the application. This button will be used to create a new account and bind it to the AccountManager
reference.
text
property of the JButton
in the Inspector. Enter Create account in the text field.
JTextField
control from the Swing tab. Click in the Design pane to add a JTextField
control to the application. The field will be used to enter the name of the new account to be created.
JLabel
to the left of the JButton
(jLabel1
by default). Enter "Enter name" in its text
field using the Inspector.
JLabel
control from the Swing tab (jLabel2
by default). Click in the Design pane to add a JLabel
control to the application. This label will display the balance in the account.
JButton
control. Select the Events tab of the Inspector. Select the actionPerformed
event, then double-click its value box to create the event. The focus moves to the Source pane.
jButton1_actionPerformed
event:
myAccount.setCorbaInterface(myAccountManager.open(jTextField1.getText())); jLabel1.setText("The account balance is " + myAccount.balance());
When you've completed these steps, the Designer will look like this:
The generated client class does the following:
OrbConnect
properties.
AccountManager
object.
Before your client program can invoke the balance()
method, it must first use the bind()
method to establish a connection to the server that implements the AccountManager
object. The implementation of the bind()
method is generated automatically by the idl2java
compiler. The bind()
method requests the ORB to locate and establish a connection to the server. If the server is successfully located and a connection is established, a proxy object is created to represent the server's AccountManagerPOA
object. An object reference to the AccountManager
object is returned to your client program.
Next your client class needs to call the open()
method on the AccountManager
object to get an object reference to the Account
object for the specified customer name.
bind()
.
Once your client program has established a connection with an Account
object, the balance()
method can be used to obtain the balance. The balance()
method on the client side is actually a stub generated by the idl2java
compiler that gathers all the data required for the request and sends it to the server object.
The application now contains a user interface that will create Account
objects, each with a zero balance. To make the example more interesting, we could add a database of customers, account numbers, and balances that could be looked up and used to debit and credit the account with withdrawals and deposits. However, in this simple example, we will simply add an implementation to generate a balance for a given name based on the number of characters in the name.
To implement the CORBA interface,
banktutorial.Bank.server
object in the project pane to expose all files.
AccountImpl.java
to open it in the content pane.
balance()
method (you can use Ctrl+F). Replace return 0
with
return _name.length()*100;
Just as with the client, many of the files used in implementing the bank server are contained in the BankTutorial
package generated when the IDL file is compiled. However, you need to create the server implementation.
From the compiled IDL file, JBuilder can help create multi-tier CORBA applications. Your distributed application can be a Java CORBA server with a Java CORBA client or an HTML client.
The client class implements the client application that obtains the current balance of a bank account. The server class implements the server application that is a default implementation servant.
To create the server,
BankTutorial.idl
in the IDL File field.
The package banktutorial.Bank.server
and the file BankServerApp.java
are generated. The file BankAppGenFileList.html
, is also added to the project, and contains the list of generated files.
The server program, named BankServerApp.java
, does the following:
Refer to the VisiBroker for Java Programmer's Guide for a description of the generated files.
The Portable Object Adaptor, or POA, intercepts a client request and identifies the object that satisfies the client request. The object is then invoked and the response is returned to the client. The POA is a replacement for the Basic Object Adaptor (BOA) and was developed to offer portability on the server side.
The POA is designed to:
For more information on POA, go to the OMG Web site at http://cgi.omg.org/corba/beginners.html.
For information on migrating CORBA applications from BOA to POA, see the Object Management Group Web site at http://cgi.omg.org.
To make the project, select
Any errors will be noted in the message view. Correct any syntax errors before continuing to the next section. For more information on debugging distributed applications, see "Debugging distributed applications."
To run the sample java client application,
The Smart Agent, or OsAgent
, is the object location service. The client finds the server by using OsAgent and the server advertises services by using OsAgent - it's how they find each other. Ordinarily, you will want the Smart Agent to be running on at least one host in your local network. The Smart Agent is described in detail in "The Smart Agent," in the VisiBroker for Java Programmer's Guide.
To start the Smart Agent,
The Smart Agent is toggled on and off by selecting and unselecting it from the Tools menu.
If you're running Windows NT and you want to start the Smart Agent as an NT Service, you need to register the ORB Services as NT Services during installation. See the VisiBroker for Java Installation Guide for instructions on installing this product. If the Services were registered, you then are able to start the Smart Agent as an NT Service through the Services Control Panel, you do not have to start it from the menu.
Alternatively, you could run the Smart Agent from the command line by running osagent.exe
from the VisiBroker bin
directory.
To start the server implementation,
BankServerApp.java
in the project pane.
The Bank server window displays. Running BankServerApp.java
invokes the virtual machine and offers other special features. For command-line options and more information, see "Programmer Tools" in the VisiBroker for Java Reference Manual.
To run the Java client,
Application1.java
file in the project pane.
The running application appears, and looks like this:
The user interface for the application appears in a window. Enter a name (for example, Paul) in the text field, click the button, and the generated balance is displayed in the label, as shown below:
The account balance is computed based on the number of characters in the name * 100.
The server monitor prints out a message every time it creates a new Account
. You will see the following output on the server side:
VisiBroker is also used in the deployment phase. This phase occurs when a developer has created client programs or server applications that have been tested and are ready for production. At this point a system administrator is ready to deploy the client programs on end-users' desktops or server applications on server-class machines.
For deployment, the VisiBroker ORB supports client programs on the front end. You must install the ORB on each machine that runs the client program. Clients (that make use of the ORB) on the same host share the ORB. The VisiBroker ORB also supports server applications on the middle tier. You must install the full ORB on each machine that runs the server application. Server applications or objects (that make use of the ORB) on the same server machine share the ORB. Clients may be GUI front ends, applets, or client programs. Server implementations contain the business logic on the middle tier.
JBuilder includes a single DEVELOPMENT LICENSE
of VisiBroker for Java "Developer Version". This license
must be used in conjunction with JBuilder. Additional developers will require their own VisiBroker development licenses. Deployed programs require a separate VisiBroker deployment license for each server machine.
Some sample CORBA applications using are provided with VisiBroker, in the examples
directory of your VisiBroker installation. Each sample attempts to incorporate functionality described in the VisiBroker for Java Programmer's Guide.