Using Forte for Java to Develop and Deploy Web Services

Print-friendly Version

This article describes the Forte for Java, Enterprise Edition, version 3.0 product (FFJEE 3.0) and demo application from a high-level view. FFJEE, with iPlanet's set of servers and containers, offers developers an environment in which they can build end-to-end Java applications with a suite of products all supplied by Sun Microsystems. In this article, we focus on using FFJEE to develop a Web service. Future articles will show other features of FFJEE, including developing enterprise beans and traditional Java clients.

Today, computing is a service-based model in which Web services are rapidly replacing monolithic, fat-client hosted and maintained software applications. Sun, in combination with iPlanet, is providing the means to develop smart Web services that provide greater value and a richer user experience. Smart Web services will provide a high level of customization and personalization, well beyond the generic Web services of today. This will be achieved through the addition of context awareness, multi-net capabilities, quality of service (meeting user needs with the least amount of effort invested by the user), and fully open interfaces.

Forte for Java is a key part of the Sun Open Net Environment (Sun ONE), which is an open framework providing tools that support Web services. Sun ONE enables organizations to create, assemble, and deploy Web services. The Sun ONE framework includes tools and technologies, such as Forte for Java and Forte ESP, to create, assemble, integrate and distribute these Web services to end users. Forte for Java is based on an open architecture that is designed for easy integration with other tools, such as Web design tools like Macromedia's Dreamweaver and Adobe's GoLive, and software, including application servers developed by ISVs.

FFJEE:

• Works with the iPlanet Application Server, version 6.0, SP2.
• Provides full support for server-side, Java 2 platform, Enterprise Edition (J2EE), and Enterprise JavaBeans 1.x (EJB) application development.
• Works with the current release (1.2) of the J2EE Reference Implementation.
• Includes all of the development features offered by the Forte for Java (FFJ) Internet and Community editions: support for the Java programming language, including Swing components, support for Java Server Pages (JSPs) and servlets, and support for JDBC and Transparent Persistence.

Developers can use FFJEE for server-side Java development to build J2EE-compliant applications, and build and deploy enterprise bean (EJB) and Web components like Java Server Pages (JSPs), and create Web services. The environment enables developers to create and package EJB and Web components so that they are available to clients as Web services. The wizards within the Forte tool do much of the detailed work for the developer.

Making an application available as a Web service provides clients with XML access to the application. XML access removes the need to expose the methods of the application's enterprise bean components and to require that a client write Java API code to use the application. With XML access, non-programmers can quickly and easily develop clients that can use these Web services.

Building a Web Service

We use a winery demo application to illustrate how you can use FFJEE to develop, deploy, and publish a Web service to application clients. The demo application illustrates a multitier J2EE application, where part of the application is provided to clients as a Web service. The demo illustrates the use of the FFJEE wizards to do such things as:

• Create and package EJB components
• Create an XML message to use as a client interface to a component
• Package the component as a Web service
• Publish the Web service to a service registry so that it is available to clients

Demo Background

The demo application consists of two independent wineries who wish to make their product catalog and some of their data accessible to clients, such as independent sales representatives, distributors, resellers, and merchants. The wineries want to make this information available as Web services, and they use FFJEE to build a J2EE application to accomplish this.

The demo application, which we refer to as a winery application, is divided into four tiers. The first tier is the client tier--the resellers, distributors, and merchants--who access the application via the Web through a browser or mobile device.

The second tier is the Web layer--the Web services, including the service registry, and the Web container. These all reside on the Web server, and they utilize JSPs and servlets. The third tier contains the EJB servers and EJB containers for the two respective wineries. Note that the wineries are completely independent from each other. The enterprise bean components are held within the respective EJB containers, and these enterprise beans contain the business logic for each winery.

Lastly, the fourth tier, or EIS tier, is where the enterprise data resides. In addition, the Winery Business-to-Business (B2B) portal sits between all the clients and the wineries. The Winery B2B company develops the portal through which clients access the wineries. It also integrates all the services from the wineries into a common page on its own Web site, which it promotes as a Web site for wine representatives, merchants, and so forth. See Figure 1.

Figure 1, Winery Application Architecture

The winery application is an end-to-end J2EE application, developed entirely with and on Sun products. Winery B implements the following functionality. It develops an entity bean and a session bean that find and extract product data from its EIS, that is, its database or databases. The extracted data, such as bottle price, name of the wine, description, and so forth, meet the needs of its clients, the resellers, distributors, and merchants. The winery wants to make this information and data access functionality available as Web services, so that the client-side developers need not be sophisticated J2EE programmers to access the information, but can be Web developers working on HTML pages. Thus, Winery B intends to publish its Web service to a Web service registry. The data will be in XML format, and clients can access the data via a browser through a Web page. The data, because it is XML based, can be formatted differently depending on the display needs of the different clients, whether that is HTML or wireless format, or even some other format. The Web developer at Winery B2B portal develops the Web pages that access Winery B's data. In the next sections, we'll show you how a developer at the winery uses FFJEE to build the Web service. Then, we'll show you how a Web developer at the portal company uses FFJEE to build the Web pages using HTML that provide access to the winery's Web service.

Developing the Winery Application

So how would a developer at the winery build such an application? Using the FFJEE tool, the development process is straightforward and uncomplicated. The developer must go through the following steps, all the while being aided by the FFJEE wizards:

1. Create the enterprise beans.
2. Assemble the enterprise beans to an EJB module within a J2EE module.
3. Create a Web service that maps to the EJB module. As part of this step, you bind an XML interface to the enterprise beans and their methods. A client component then can use the XML interface to invoke the bean methods, and, from the client's point of view, the invocation is done solely with XML messages rather than API function calls.
4. Deploy the Web service as a J2EE application to an application server, such as iPlanet's Application Server or the J2EE Reference Implementation.
5. Publish the Web service.

Creating Enterprise Beans

To begin, the developer uses the FFJEE EJB template to create the necessary session and entity beans. These beans hold the winery's business logic and include the methods to access the winery's EIS or databases. In this example, the developer creates an entity bean, WineEJB, to retrieve fields from the database, and a stateless session bean, MerchantEJB, that communicates to the entity bean.

The developer can use Forte's source editor to enter the business logic code for the different beans. FFJEE automatically generates the corresponding home and remote interfaces for the different beans, and makes sure the persistence parameters are properly set. The developer uses property sheets to set up the references between the two enterprise beans. As the developer refines the beans and the beans' relationships and references, FFJEE keeps all such references up-to-date and automatically updates the deployment descriptor. FFJEE also generates the deployment descriptor entries required by the developer's particular J2EE application server.

In addition to providing a representation of each class or interface of a bean, FFJEE also provides a logical representation of the bean. The bean's logical representation encompasses all of the interfaces and classes of that bean. Because an enterprise bean consists of several classes or interfaces: it is easier for developers to use the bean's logical representation when working with enterprise beans.

Assembling the Beans into an EJB Module

Once the enterprise beans are developed, they must be assembled into an EJB module within a J2EE module, which represents the application itself. Assembling the beans is the first step in the application assembly process.

With FFJEE, assembling a bean into an EJB module is simply a matter of selecting the logical representation of an enterprise bean and adding it to an EJB module. By selecting the logical representation, FFJEE automatically adds all the classes and interfaces of the bean, plus any helper or dependent object classes used by the bean, to the EJB module. As before, FFJEE automatically updates the deployment descriptor to include all beans added to the module.

Creating a Web Service

Next the developer uses the Web Service template to set up the application's components as Web services. In this phase, you define XML operations and then aggregate a set of XML operations into a Web service.

The Web Service template lets you map enterprise bean methods to XML operations. Mapping a method to an XML operation enables you to ultimately expose that method to clients. For example, the winery application's entity bean WineEJB has a find method that is an SQL query. You can map the bean's find method to an XML operation, and thus create an XML interface to that find method. Later, a client can send an XML message or document and be able to invoke the mapped enterprise bean method.

It's possible to map multiple bean methods, including methods from different enterprise beans, to one XML operation. Mapping or binding a bean method to an XML operation results in an XML message with fields that reference the data returned by the enterprise bean method. By aggregating multiple beans and multiple methods into one XML operation, you have an XML operation that presents the information as one logical piece. In our application, the developer maps the session bean's listAllWines method, which invokes an entity bean find method to retrieve a collection of wine data, to a getInventoryOP operation. (A collection represents one or more rows of wine data that is of type WineInfo class.) The bean then uses methods on a dependent object class (WineInfo) to list each field of the data. This mapping produces an XML input message and an XML output message. Because listAllWines takes no parameters, the input message merely shows that all wine data is selected. However, the XML output message shows each field of the returned data, and each field is tagged with the name of the field, such as price, wine name, and so forth. See Mapping Methods to Operations.

Figure 2, Mapping Methods to Operations

The developer can choose to edit the XML operation. For example, you might want to rename the labels for the fields to make them more meaningful for your clients. Thus, you might change wine name to varietal. You can also selectively remove fields from the XML output message so that they are not exposed to clients. You might, for example, remove the price field from the XML operation and thus prevent clients from accessing this piece of data.

XML operations are reusable components. They can be accessed, sent, and formatted just like any other XML message. In addition, an XML operation can be used simultaneously by different Web services.

Once the developer has defined the winery's XML operations, he then defines a Web service to hold all XML operations that pertain to the application. In our example, the developer creates an InventoryService Web service and adds the appropriate XML operations to the service.

A Web Service can be created to act as an umbrella for other services and operations. (See Figure 3.) You create the Web Service (using the Web Service template), and add XML operations and other Web services to the Web service. A Web service can have multiple XML operations. Each XML operation can represent multiple bean methods. It's easy to see how one Web service can represent a complicated set of actions. When you create a Web service, you also create an .xmc file that contains the metadata for each XML operation and an .xms file that contains the metadata for the entire XML service. Keep in mind that both the .xmc and .xms metadata files are created in XML format.

Figure 3, Web Service Umbrella

FFJEE generates compiled Java class files from the .xmc files. FFJEE also parses the .xms file and produces a special session bean. This session bean acts as a router for the service. In our example, it exists on the winery's application server, and, when it receives XML-based requests for winery data from clients, it is responsible for calling the entity or session bean methods that access the data from the EIS. It then returns whatever data was found by the beans as XML data.

Deploy the Service as a J2EE Application

Use the FFJEE Deploy tools to package and assemble the modules into a J2EE application .ear file. Then deploy the J2EE application to the default application server. You may select the default application server. FFJEE handles deployment tasks required by the particular application server integrated with FFJEE.

Publishing the Web Service

Once all the services are defined, the developer uses FFJEE's J2EE template to package the application components. This step produces the .ear file, which is the file distributed for deployment. The .ear file includes the Web service, plus all the Java class files and EJB modules. (For deployment, the deployer uses the property sheets associated with the application to do any deployment customization.)

The Publish template allows the developer to enter the components into the UDDI registry so that it is available to Web clients. Methods may be enabled or disabled during the publishing process. Disabling a method keeps the method hidden from clients.

At this point, the Java development is finished. Clients can now access these published services through their browser.

Developing the Client

A Web page designer, using a tool such as Macromedia Dreamweaver or Adobe GoLive, can design a page and include the service published by the winery. It is not necessary to be a programmer or to write Java code to do this. By using FFJEE's Enterprise Services Presentation (ESP) toolkit from within his web page design tool, the designer can include the service by displaying and selecting the appropriate service field.

ESP is a data-centric service for visualizing and presenting data, and it extends such tools as Macromedia's Dreamweaver and Adobe's GoLive. It separates a document's logic from its content. ESP takes a plain HTML Web page that a Web developer is working on in some tool such as Dreamweaver, and adds XSLT rules, JSP tags, and custom JSP actions to that page, effectively converting the HTML page to a JSP. The page can thus utilize services published to a Web services registry such as UDDI (Universal Description Discovery and Integration registry). The Web designer can not only select from the published services, the designer can also select fields from within a published service. ESP inserts the appropriate JSP display tags and actions into the HTML page for both the selected service (or services) and its selected fields. ESP itself is a servlet with its own custom tag library, and it processes the published services (which are XML-based data) according to XSLT rules. ESP can thus transform XML data to different client formats, such as HTML, wireless format, and so forth.

For example, a Web designer who wants to access the winery service might use Dreamweaver to create a simple HTML page (which must be named with a .jsp extension) to list the wines carried by winery. The Web designer creates a table, with column headings for each data item in the display. The developer also might put some graphics on the page, set different colors, and so forth, to produce an attractive, easy-to-read page. An extremely simple HTML page might look as follows:

Wines In Stock Stock# Type Name Description Stock# Type Name Description

Then, the Web designer uses ESP to browse the UDDI registry, from which he can select any published Web service. In our case, the designer selects the InventoryService for the winery. Then, the designer selects data fields from within the service to display in the Web page. See Designing the Web Page.

Figure 4, Designing the Web Page

ESP inserts the JSP tags, XSLT rules, tag library directives, and custom JSP actions, including the URL to the InventoryService and JSP tags referencing specific data fields. During the page development phase, the Web developer merely chooses data fields that are available from the service and indicates where in the page to display them, while ESP inserts the necessary HTML variables. ESP also has a runtime phase that uses the tag library and XSLT processor, rather than the ESP servlet, to process requests that convert XML to HTML.

For example, ESP might generate the following JSP page from the simple HTML page shown above:

<html xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
 charset=iso-8859-1" />

</head>

<body bgcolor=
"#FFFFFF" text="#000000">
<%@ taglib uri="esp-taglib" prefix="forte" %>
<p><font size="6"><b>Wines In Stock</b></font> </p>
<forte:esp name="MyWineList" inline="true" sourceURL=
"local::wineOperation:" resultSet=
"wineOperation/Vector-WineInfo/WineInfo:Bottleprice,
Bottlesavail,WineId,Winedesc,Winename,Winetype,Wineyear"> 

<table width="75%" border="1">
<tr> 
<td>Stock#</td>
<td>Type</td>
<td>Name</td>
<td>Description</td>
</tr>
<xsl:for-each select="wineOperation/Vector-WineInfo/WineInfo">
<tr> 
<td><forte:expand value="{WineId}">Stock#</forte:expand></td>
<td><forte:expand value="{Winetype}">Type</forte:expand></td>
<td><forte:expand value="{Winename}">Name</forte:expand></td>
<td><forte:expand value="{Winedesc}">Description</forte:expand></td>
</tr>
</xsl:for-each> 
</table>
</forte:esp> 
<p>&nbsp; </p>
</body>
</html>

The final Web page might look as follows in figure 5

Conclusion

We've seen in this article how FFJEE greatly simplifies the process of developing Web pages and Web services. By using the Forte tools in conjunction with tools for Web page development, it's possible to develop and publish a Web service, and develop the Web pages to access a service, writing little if any code. You do almost all the design and development using these graphical-based tools, and, beneath the covers, Forte generates virtually all of the required code.

This article focused on developing the Web side of an application. Future articles will address using the same FFJEE product to develop enterprise bean components and traditional Java applications.

For More Information

Forte for Java, Enterprise Edition, version 3.0 product (FFJEE 3.0) is available for download here.

About the Author

Beth Stearns is the principal partner of ComputerEase Publishing, a computer consulting firm she founded in 1982. Her client list includes Sun Microsystems, Inc., Silicon Graphics, Inc., Oracle Corporation, and Xerox Corporation. Among her publications are the "Java Native Interface" chapter in "The Java Tutorial Continued" book in the Addison Wesley Java series, "The EJB Programming Guide" for Inprise Corporation, and "Understanding EDT", a guide to Digital Equipment Corporation's text editor. Most recently, she co-authored with Vlada Matena of the Addison Wesley Java series book, "Applying Enterprise JavaBeans: Component-Based Development for the J2EE Platform."

Have a question about programming? Use Java Online Support.