appbuilder 2.1.0 product concepts guidedocshare02.docshare.tips/files/18431/184314649.pdf · the...

BluePhoenix AppBuilder 2.1.0.

Product Concepts Guide

http://www.bluephoenixsolutions.com

BluePhoenix AppBuilder 2.1.0.Product Concepts GuideApril, 2003

Corporate HeadquartersBluePhoenix SolutionsVlierwerf 7B4704 SB RoosendaalThe Netherlands+31 (0) 165 399 401+31 (0) 165 396 308 fax

USA HeadquartersBluePhoenix Solutions USA, Inc.8000 Regency ParkwayCary, NC 27511United States+1 919.380.5100+1 919.380.5111 fax

www.bluephoenixsolutions.com

© 1992-2003 BluePhoenix Solutions

All rights reserved.

BluePhoenix is a trademark of BluePhoenix Solutions. All other product and company names mentioned herein are for identification purposes only and are the property of, and may be trademarks of, their respective owners.

Portions of this product may be covered by U.S. Patent Numbers 5,495,222 and 5,495,610 and various other non-U.S. patents.

The software supplied with this document is the property of BluePhoenix Solutions, and is furnished under a license agreement. Neither the software nor this document may be copied or transferred by any means, electronic or mechanical, except as provided in the licensing agreement.

BluePhoenix Solutions has made every effort to ensure that the information contained in this document is accurate; however, there are no representations or warranties regarding this information, including warranties of merchantability or fitness for a particular purpose. BluePhoenix Solutions assumes no responsibility for errors or omissions that may occur in this document. The information in this document is subject to change without prior notice and does not represent a commitment by BluePhoenix Solutions or its representatives.

http://www.bluephoenixsolutions.com

TABLE OF CONTENTS

AppBuilder 2.1.0 Product Concepts Guide

1 AppBuilder - The Complete Development Solution . . . . . . . . . . . . . . . . . 1-1

System Requirements for AppBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Platforms and Operating Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Environment Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Programming Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Network Protocols Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

AppBuilder 2.1.0 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Enterprise-Scale Internet Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Challenges in Internet Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Java Development Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4AppBuilder Java Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Extended Connectivity Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6MQSeries Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7XML SOAP Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7NetEssential Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Development Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Support for Multilingual User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Workgroup Repository Rebuild Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Host Remote Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9Rules Language Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10OpenCOBOL Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

2 Repository Development Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13

Understanding Repository-Based Development. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13Repository Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14

Types of Repositories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Personal Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Workgroup Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Enterprise Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

Workgroup Repository Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16Using the Workgroup Server Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Using the Freeway Explorer Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Workgroup Repository Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

Repository Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Using the Object-Based Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Setting Project Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

AppBuilder 2.1.0 Product Concepts Guide i

Setting Workgroup Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19Analyzing Impact and Rebuilding the Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Repository Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Migration Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Import and Export Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

3 Application Design Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Open Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23Integrated Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23Application Specification Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25User Interface Design Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Scripting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-27

4 Multiple Platform Development Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

Web Application Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29Supported Platforms and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29

AppBuilder Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31Hierarchy, Configuration, and Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31Preparation and Rebuild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32Debugging and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32Java Client Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33

Generation for Traditional Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34Run-time Host Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35

OpenCOBOL Generation Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35

5 J2EE Technology Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37

Java Features in AppBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37

HTML Thin-Client Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38

Full Java Client Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39

Enterprise Java Bean Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40Application Server Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41

J2EE Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42EJB Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42Component Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43

Java Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43Java Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43CLEAR_WINDOW_CHANGES Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-43C User Components in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44Thread-Safe Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44

Java Development Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

ii AppBuilder 2.1.0 Product Concepts Guide

CHAPTER

1 APPBUILDER - THE COMPLETE DEVELOPMENT SOLUTION


AppBuilder contains everything a development environment needs to create any type of simple or complex business application with platform-independent functionality, including:

• An easy-to-use and manage user interface, object toolset, and repository infrastructure

• System administration security controls for scope and permissions

• Migration, testing, and deployment functions

AppBuilder supplies a comprehensive development environment for your applications, including the following:

• Object modules

• Rules Language

• Java language support

• Standard COBOL code generation

• OpenCOBOL generation

• Packaging

• Debugging

• Deployment functionality

The following topics are discussed in this section:

• System Requirements for AppBuilder

• Enterprise-Scale Internet Development

• Extended Connectivity Options

• Development Enhancements

• OpenCOBOL Generation

System Requirements for AppBuilderAppBuilder provides a heterogeneous application development environment. The following are system requirements organized under the following sections:

1-1

System Requirements for AppBuilder

• Platforms and Operating Systems

• Environment Support

• Programming Language Support

• Network Protocols Support

• Support for Multilingual User Interface

• Workgroup Repository Rebuild Facility

Platforms and Operating SystemsFor information on the supported platforms and operating systems, refer to “Meeting System Requirements” in the Installation Guide for Windows.

Environment Support• Java 2 Platform, Standard and Enterprise Editions

• IBM WebSphere 4.0 application server

• BEA WebLogic 6.0 (with SP6) application server

• Apache with Tomcat Web Server

• Any HTML editor and Microsoft Internet Explorer (IE) 6.0 browser

• PCs operating Windows 2000

• Servers operating AIX, HP-UX, or OS/400

• Mainframe systems running CICS

Programming Language Support• C for Windows

• Java (using J2EE)

• COBOL

Network Protocols SupportAppBuilder operates over Local Area Networks(LAN) or Wide Area Networks(WAN) using the following network protocols:

• TCP/IP

• Named Pipes

• LU6.2

• LU2

1-2 AppBuilder - The Complete Development Solution

AppBuilder 2.1.0 Features

Table 1-1 lists the network protocols supported by AppBuilder for different operating systems:

AppBuilder 2.1.0 FeaturesAppBuilder 2.1.0 adds improved workbench tools, Java enhancements, multiple language development, rebuild enhancements, and dynamic set support.

AppBuilder 2.1.0 features include:

• Architecture-independent development

• An integrated toolset for designing, developing, and deploying applications

• Object-based components managed from host, server, or client repositories

• Support for C, standard COBOL, and Java programming languages

• Ready-to-use business logic and libraries

• Centralized administration with permission and scope controls

• Preparation, testing, and debugging functionality

• A remote prepare facility for mainframe development

• Support for IBM MQSeries middleware

• NetEssential installation and configuration enhancements for WindowsNT/2000

• Open connectivity using HTTP Simple Object Access Protocol (SOAP) XML Web Services

• DBCS Support

• Ability to develop multilingual user interface objects and build an application for a specific language.

• Enhanced repository rebuild functions

Table 1-1 Supported Network Communication Protocols

Operating System Protocol Product

AIX

LU6.2 IBM Communications Server for AIX

TCP/IP IBM (bundled with OS)

TCP/IP IBM TCP/IPIBM Lan Server

Windows 2000

LU2Attachmate Extra! Personal Client IBM PCOMMWall Data Rumba for Mainframe

LU6.2 Microsoft SNA ServerIBM Communications Server

Named Pipes Microsoft (bundled with OS)

TCP/IP Microsoft (bundled with OS)

AppBuilder 2.1.0 Product Concepts Guide 1-3

Enterprise-Scale Internet Development

Enterprise-Scale Internet DevelopmentLarge enterprises using legacy business models and systems are incorporating Internet technology to expand their business opportunities. An integration solution that provides flexible, robust performance, and a scalable development environment capable of integrating old and new business infrastructures is essential. AppBuilder provides the complete business Internet development solution.

Challenges in Internet DevelopmentThe challenges of enterprise-wide Internet development include:

• Development for mixed-technology environments

While no single solution fits all development requirements, Java language development is a flexible option many organizations are choosing to create portal entries into enterprise systems. To incorpo-rate existing databases and infrastructure, organizations need mechanisms that communicate reli-ably within mixed systems, such as Java combined with C or COBOL.

• Providing a solution that integrates new technology with existing systems

Many organizations are introducing systems into their organization that do not integrate well with previous systems or each other. These organizations need a complete integration solution for their-systems.

• Maximizing performance across platforms

Organizations need to deploy large-scale, enterprise-wide applications to a wide array of operating systems, servers, and clients while maintaining high-speed, dependable performance requirements.

• Developing applications in a “future-proof” fashion

Producing high-quality applications is costly, whether developing new applications or upgrading existing systems. The desire to develop platform-independent or, more precisely, architecture-inde-pendent applications drives organizations to look at options that impact their future direction, such as thin-client HTML vs. thick-client Java, web versus application servers, or Java language code development versus C.

• Managing and maintaining large, scalable applications

Enterprises that create and maintain large-scale applications for the Internet need to control and track the interaction between a large team of developers and manage deployments to a wide variety of environments.

AppBuilder offers an application development environment that maintains complete data and user control. It supports manageable and secure, yet easily accessible, business objects for enterprise-scale development across a wide range of platforms and architectures. Through the use of repository technology, AppBuilder supplies the tools and technology you need to design, implement, and maintain high-quality, multi-platform, distributed applications.

Java Development SupportIBM WebSphere and BEA WebLogic are among the popular application servers supported by AppBuilder. AppBuilder supports Java Standard Edition 1.3.1 (with J2EE Reference Implementation), any HTML editor, and the IE browser.


Enterprise-Scale Internet Development

AppBuilder Java development features provide:

• Integrated Toolset

• Central Repository

• Code Generation

Integrated Toolset

The Construction Workbench toolset provides an easy-to-use interface and object management windows. The toolset allows developers to concentrate on the business aspects of an application rather than on the technical infrastructure used to implement the business components. With this versatile set of tools, developers can create and configure applications and maintain them over generations of execution technology. The open architecture of AppBuilder Java development frees you from hardware platform, operating system, client/server distribution or Internet distribution concerns.

Central Repository

In order to manage a team of developers working simultaneously on large-scale development projects, AppBuilder uses repository technology as a central store of information. The repository controls and organizes not only the structure of components but also how the components interact and the duplication of objects and functions. Using this information, functions necessary to maintain enterprise-scale environments, such as impact analysis and broadcast messages, become seamless operations.

Code Generation

AppBuilder provides generation technology that converts Business Object and Business Process definitions into high-performing applications. These generators convert the AppBuilder specifications into open code, specifically tuned for the selected deployment platform, distribution architecture, and Internet architecture. Using AppBuilder’s fourth-generation language (4GL) that generates native code, you are not limited to development for a specific execution platform.

AppBuilder Java Development ProcessAppBuilder leverages the strengths of legacy AppBuilder functionality with the requirements of web commerce. Existing application deployment processes are enhanced with thin web-based clients and Enterprise Java Bean servers.

To complete the suite of Java-enabled capabilities, AppBuilder also packages the newly-generated applications, making them easily deployable on any J2EE-compliant application server. Figure 1-1 illustrates the development process from initial application specification to deployment across multiple platforms.


Extended Connectivity Options

Figure 1-1 AppBuilder Java Development Process

Extended Connectivity OptionsThe remote procedure call from Java to the OS/390 platform is implemented using IBM MQSeries. This eliminates the requirement for NetEssential host connectivity and allows three-tier applications to be deployed using only standard connectivity, Enterprise Java Beans and IBM MQSeries.

It allows connectivity to SOAP XML Web Services, a technology rapidly becoming the Remote Procedure Call (RPC) protocol of choice, allowing you to leverage existing applications by making them available across an enterprise using industry-standard connectivity technologies.

Note For NetEssential users, we continue to provide an efficient way to configure and manage communications.


Extended Connectivity Options

AppBuilder 2.1.0.1 provides additional support for industry-standard connectivity in new ways. The following topics are discussed in this section:

• MQSeries Remote Procedure Call

• XML SOAP Web Services

• NetEssential Improvements

MQSeries Remote Procedure CallFor organizations that have selected MQSeries as their middleware to create MQSeries infrastructures consisting of both logically synchronous and asynchronous applications, AppBuilder offers another configurable connectivity choice for Java development, along with NetEssential, Enterprise Java Beans and XML-SOAP. A configuration change on the client is all that is required to invoke a host rule over MQSeries.

AppBuilder dynamically determines where and how this service is to be accessed when a remote rule is invoked. If the rule is invoked over MQSeries, AppBuilder marshals the Java data classes and writes the message to an MQSeries queue using Java Message Service’s (JMS) API. This message is sent to an input queue managed by the CICS Queue-Manager. The incoming message triggers the invocation of the AppBuilder rule and the results are written back to the output queue where the calling program is waiting. Figure 1-2 shows the MQSeries connectivity process.

Figure 1-2 Java Connectivity to Mainframe Using MQSeries

XML SOAP Web ServicesAppBuilder offers support for Web Services based on Simple Object Access Protocol (SOAP) that require open connectivity across an enterprise. The connectivity contract for these systems is defined externally by SOAP Schemas and Web Service Definition Language (WSDL). This external definition, and the use of HTTP as its common transport, make these SOAP Services an attractive standardization and integration technology choice. Applications developed in Java are deployable as SOAP XML Web Services, and the SOAP Schema defining these services is published, allowing these services to be accessed by other applications across the enterprise.

The AppBuilder Partition can deploy its Web Services on an application server or as a Java servlet on a web server. The actual Java rules can be deployed locally or accessed remotely. A new Partition Type, ‘Gateway’, is used to specify that the Partition should function as a gateway and forward all its requests to


Development Enhancements

another server. Using a Web Service gateway, clients can create an SOAP-XML interface for their existing AppBuilder COBOL applications. Figure 1-3 gives an example of the SOAP XML web service gateway configuration.

Using AppBuilder Java rules, Web Services are configured and accessed like any other remote rule. AppBuilder Web Services provide one standard interface usable by AppBuilder and third-party applications.

Figure 1-3 Application Server Connectivity Using SOAP XML

NetEssential ImprovementsInstallation and configuration enhancements are available for WindowsNT and Windows2000 that make setting up and managing NetEssential communications middleware easier:

• Remote File Configuration and Management

• Remote Start/Stop Functionality for Services

• Automated Installation and Configuration

Development EnhancementsSeveral features are now available in AppBuilder to support more flexibility in the development environment:

• Support for Multilingual User Interface

• Workgroup Repository Rebuild Facility

• Host Remote Preparation

• Rules Language Features

• OpenCOBOL Generation



Support for Multilingual User InterfaceAppBuilder now provides support for development of multilingual user interfaces and the creation of an application targeted for a specific language. AppBuilder currently supports only a single family of languages (languages within one code page) for each application. You can then define the window forms and sets of your application for the languages that you have defined.

The language definitions are accessed through Construction Workbench using the Language Administration Tool. Window Painter and Set Builder can be used to create and maintain language dependent variants for Windows and Sets. TurboCycler and TurboScripter can be used for accessing language dependent artifacts in AppBuilder.

The resulting applications, including language-modified user interface objects, can be prepared just as any AppBuilder application, and deployed in Java, C Client, and thin-client.

Workgroup Repository Rebuild FacilityThe Workgroup Repository Rebuild facility is usable on every AppBuilder platform. It allows you to perform a rebuild of your application from a remote preparation client, in conjunction with an Application Configuration or Partition. Using this facility, the rebuild selectively updates and rebuilds only those objects impacted by a particular change. The rebuild facility creates a record each time an object is prepared for a particular Application Configuration or Partition. For more detailed information, refer to the Deploying Applications Guide.

Host Remote PreparationThe remote prepare facility for the mainframe platform streamlines the development of host applications. In the past, a developer was required to migrate source code to the enterprise repository for extraction, COBOL generation, and source code compile and link processing.

Using remote preparation, a developer can build, prepare, and test the code on their workstation using a personal or workgroup repository and then move the object to the enterprise repository when it is complete. Once the source code is located remotely in the personal or workgroup repository, it is compiled and linked without accessing the host repository. This allows the object’s source to remain on the Personal or Workgroup repository until you are ready to upload it to the host.

Figure 1-4 illustrates the process for remote preparation on the host.



Figure 1-4 Host Remote Preparation

The remote prepare facility is configured and functions similarly to other platforms. The Machine object specifies the name and operating system of its Partition. When an object is prepared for a Host Partition, the job scheduler asynchronously sends the AppBuilder source to the preparation server on the host where COBOL is generated, compiled, and linked. Upon completion, the preparation server asynchronously sends the results to the client.

Rules Language FeaturesAppBuilder Rules Language and COBOL provide flexibility and maintainable standards in mainframe development. AppBuilder includes Rules Language functionality, such as object and event support, and alternatives to the MAP and SET Statement and View Specification that improve ease-of-use for developers using Visual Basic and COBOL.

The OpenCOBOL Generation facility offers an additional programming option for developing code that can be called without an intermediary runtime using standard COBOL processes.

The Enterprise Administration Guide provides detailed information about the OpenCOBOL generation facility. For information about specific COBOL development , refer to the Rules Language Reference Guide.

MAP and SET Statement

Currently, the following MAP statement is used to assign the value of one variable to another:

MAP SOURCE_FIELD to DESTINATION_FIELD

While this statement is still supported, a new statement that may be more familiar to developers is also available. The new SET statement syntax assigning value to a variable is shown in the following example:

SET DESTINATION_FIELD := SOURCE_FIELD

The specification of the destination field first is standard in most programming environments, such as in the programming language Visual Basic (VB).

Note The current MAP statements and View specification statements are not effected and are still supported.



View Specification

An application developed in AppBuilder typically has deeply nested data structures. To improve the specification of data structure members and align them with standards typical of many programming environments, AppBuilder now provides an additional format to specify a member of a View using the dot notation (‘.’) and listing the views from highest to lowest level.

The current field specification statement looks like this:

Field1 of View3 of View2 of View1

The View specification allows the omission of intermediate View levels. While the previous statement is still supported, a new statement using dot notation is also available, as shown in the following example:

View1.View2.View3.Field1

Fully qualifying views is necessary to avoid ambiguous references. This feature is supported in the new form but must be specified explicitly using the dot (‘.’) as shown in the following example:

View1..Field1

OpenCOBOL GenerationMigration of entire applications to standard COBOL is now possible using the COBOL generation facility for mainframe development. It generates COBOL source code that is easy to read and maintain and conforms to industry-standard COBOL functions and data types. Following these industry standards, AppBuilder generates the open code required for use outside the AppBuilder runtime environment and creates a more efficient development effort overall.

The generated COBOL does not require the use of a separate runtime because external libraries required by the generated COBOL are provided in the source, as well as the compiled code. The generated standard COBOL programs can be called externally or from AppBuilder applications, allowing greater openness in application design.

The OpenCOBOL generation facility is available for CICS, IMS, and BATCH environments.

The OpenCOBOL generation facility does not replace the existing AppBuilder COBOL generation facility; both options are supported.


CHAPTER

2 REPOSITORY DEVELOPMENT ENVIRONMENTS


AppBuilder uses repository technology to manage large-scale development projects. The repository is a type of relational database containing all the application components in the development environment: objects, business logic, configuration settings, relationships, and metadata. AppBuilder provides both the repository technology for management of project objects and a powerful graphical interface for access to those objects. The following repository topics are covered in this section:

• Understanding Repository-Based Development

• Types of Repositories

• Workgroup Repository Administration

• Repository Administration

Understanding Repository-Based DevelopmentUsing a common repository, a large team of developers has access to an unlimited number of objects in an AppBuilder development environment. The resulting workspace allows developers to create application code simultaneously, see and utilize objects that others have developed, coordinate application design, and deploy applications across the enterprise.

The individual members of a development team can design an application using AppBuilder-supplied graphical tools and a design specification, and generate native code for multiple environments from a single workstation. AppBuilder repositories manage the various artifacts created during the development of these large systems: such as the drawings, source code, data structures, and configurations. The centralized management of these resources enables object sharing and code reuse.

Figure 2-1 illustrates two possible ways to set up your repository. In example A, the development team client workstations maintain personal repositories that can access a mainframe system containing a host repository.

In example B, the separate client workstations have personal repositories with access to a server containing a workgroup repository; the server in turn, has access to a host repository for the final application migration, compiling and linking, or database services. In all cases, scope and user permissions for the repository can be administered to control access and actions, and to track and analyze the repository contents.


Understanding Repository-Based Development

Figure 2-1 Repository Options

Repository FeaturesThe features of repository-based development include:

• Flexible, scalable architecture

• An object-based information model

• Data migration between repositories

• Conference-based notification

• Platform-, protocol-, and database-independent configurations of workgroup installations

• Industry-standard APIs

• National Language Support (NLS) and Double-Byte Character Support (DBCS)

• Impact analysis for migration imports

• Integrated rebuild facility with reports

2-14 Repository Development Environments

Types of Repositories

The benefits of working with objects in a repository include:

• Architecture-independent deployment using application specifications

• Object sharing across platforms, tools, and lifecycle phases

• Repository security

• Reduction of administrative and maintenance costs

• Simplified migrations to and from the mainframe

Types of RepositoriesAppBuilder supplies these three types of repositories:

• Personal Repository

Created on the client workstation for local development

• Workgroup Repository

Created on a server for workgroup access for developers working on workstations and sharing objects and projects.

• Enterprise Repository

Created on a mainframe to manage enterprise-wide application components and projects, and prepare, test, and deploy applications

Personal RepositoryA personal (local) repository is a repository that is created on the client workstation and uses a database that resides on the same computer. It supports one user on the local machine. Multiple personal repositories can be created on a single machine and each one may have the same or different users permitted access to each repository.

The personal repository offers repository functionality on the client workstation, typically a Windows NT or 2000 platform, allowing objects to be uploaded to and merged with a larger development effort, whether it be on a server in a workgroup repository or on a mainframe repository.

A personal repository is local, therefore it does not require a constant network connection. Only when you upload, download, or query remote objects do you need a network connection to a remote consolidation server.

See the Personal Repository Administration Guide for more information.

Workgroup RepositoryThe Workgroup (Freeway) repository offers a controlled, secure client/server environment by maintaining the repository on an AIX or Windows NT network server accessible to all developers from

Note Workgroup and Freeway are interchangeable terms, referring to a networked AppBuilder repository.


Workgroup Repository Administration

remote nodes using Freeway Explorer or the Construction Workbench. Workgroup repositories provide active updates that broadcast changes during real-time operation. Workgroup repositories also include sophisticated locking mechanisms that define permissions restricting access to and modification of objects and projects. Impact analysis of migration imports manages and tracks changes and implementation results and generates result logs.

Using AppBuilder, you can set up different Workgroup repositories representing different phases of development, for example:

• Application development

• System and integration testing

• Developer training

• User acceptance

See the Workgroup Repository Administration Guide for more information about workgroup repository administration and configuration.

Enterprise RepositoryThe Enterprise repository is a secure, mainframe repository used for building applications using AppBuilder. The mainframe is designated as the central archive and active site for the development team to manage application objects and configuration. Additional enterprise features help manage the process of getting applications from initial development into production.

The repository tables are stored and managed on the mainframe. Developers then download objects from the enterprise repository to personal repositories installed on client workstations. New and modified objects are later uploaded to the mainframe repository. This setup is ideal for organizations separated by large distances, where LAN speeds make the workgroup repository impractical.


The AppBuilder repository provides a LAN-based tool to administer and manage a software design and development environment from a centrally-located database residing on a server. The objects within the repository are viewed and accessed for modification or configuration. AppBuilder repository software enables a system administrator to implement security restrictions that control access to objects in the repository. Security restricts connection and modification to those objects based on permissions set by the system administrator. The following topics are discussed in this section:

• Using the Workgroup Server Browser

• Using the Freeway Explorer Tool

• Workgroup Repository Actions

• Repository Installation and Configuration

• Migration Facility

• Import and Export Utility



Using the Workgroup Server BrowserThe Workgroup Server Browser uses the Microsoft Windows Network browser to show all the domains, workgroups, and Workgroup server machines connected to the LAN. The administrator can start and stop the Workgroup service on a remote machine from one central location, given the appropriate level of Windows NT and SQL Server security.

Using the Freeway Explorer ToolUse AppBuilder’s Freeway Explorer to access the objects in Workgroup repositories, and to perform the functions and data manipulation required to manage the repository.

The Freeway Explorer is a suite of tools used to:

• Connect to workgroup repositories

• Set security levels and repository permissions

• Locate and load objects for migration

• View and edit object properties

• View object entities and relationships in a hierarchy browser

• Remove objects from a repository

• Search for objects using a query or keyword

• Create migration objects using the Migration and the Application Folder Tool

• Perform impact analysis on migration imports and exports

• Broadcast repository messages to other usersl

The Freeway Explorer tool is accessed through an icon in the AppBuilder program start menu.

Figure 2-2 Freeway Explorer Start Menu

Note To use Freeway Explorer, you must establish a connection alias from the LAN to the Workgroup server. Request the parameter information from your Workgroup repository administrator to create the connection alias prior to using a Workgroup repository.


Repository Administration

Workgroup Repository ActionsThe following actions are available in a Workgroup repository.

After creating a connection alias, provide the following security information to connect to a Workgroup repository:

• Login ID - the user ID for the Workgroup repository

• Password - the password as determined by native security

Repository AdministrationRepository administration consists of configuring the repositories by:

• Using the Object-Based Information Model

• Setting Project Security

• Setting Workgroup Security

• Analyzing Impact and Rebuilding the Application

Using the Object-Based Information ModelThe AppBuilder Information Model is the set of entity types you use to define the building blocks in applications. Relationships, or the associations between the entities, are also defined using AppBuilder. The entities and relationships, when defined together constitute the objects that are stored in an

Table 2-1 Repository Actions and Descriptions

Actions Description Parameters Required

New Creates a new association to a Workgroup repository

Connection alias - the name assigned by the developer to differentiate between different Workgroup repositories. This is typically the Server name.

Connect via - the protocol used during development to access the Workgroup repository from the client.

Server name - the network name of the server on which the Workgroup repository resides. This must be consistent with the communications protocol.

Service name - the name of the service request used to connect to the Workgroup repository using NetEssential. If you are not using NetEssential, the field is “default”.

ConnectUsed to login to a Workgroup repository after a connection alias is created

none required

Disconnect Closes a connection to the Workgroup server none required

Commit session Saves all changes to the repository none required

Rollback session Reverses the unit of work to it’s previous state before the last commit none required

Delete Removes the connection alias none required



enterprise, personal, or workgroup repository. You use the objects as the fundamental building blocks for your application development.

Refer to the Information Model Reference Guide for detailed information on using the Information Model.

Setting Project SecurityRepository security is implemented using a security model of:

• Users

• Groups

• Projects

• Permissions and Scope of objects

A repository administrator determines the security parameters for objects and for the actions a user can perform on objects. For example, an administrator can specify that you can add but not delete an entity or a relationship within a particular group you are assigned to. An administrator can further specify the authorized scope of a changes you can make to a particular method. For example, you may be authorized to add an entity in rules, but not to create views.

Using AppBuilder, the system administrator can keep strict control on software versions, modifications, releases, databases, and libraries. The development environment remains stable and secure, and programmers are assured that the objects and relationships they create today will be unchanged tomorrow. Objects can be shared among the group members but the source object is only modifiable by the assigned owner, unless and until that security option is changed by the administrator. The repository administrator also assigns locking attributes for objects in the repository using AppBuilder’s reliable, automatic locking function.

Setting Workgroup SecurityWorkgroup security is implemented using the Workgroup security model stored within the repository. The Workgroup repository security model makes use of the GROUP object as an intermediary between the PROJECT and USER objects.

Table 2-2 Object Security Models

PROJECT The area to which development objects are defined.

The Workgroup repository can store multiple projects. When a user logs on to a Workgroup repository, the user selects and works within the context of a project. A user can work within any project to which they are assigned, and objects created are assigned to the user’s active project.

GROUP The group of users associated with common security permissions and scope.

Multiple groups can be defined to a project, thereby allowing for different levels of authorizations and scope. Additionally, a group can be defined to multiple projects, with the permissions in separate projects being different. Children subgroups may also be defined in the security model for the purpose of organization.



When a GROUP is included in a project hierarchy, the type of access group members have to the objects in the project is defined using the attributes:

• Scope - defines the set of objects that developers have access to

• Permissions - defines the actions permitted to users, selected from the options:

• Create

• Relate

• Update

• Delete

The system administrator assigns user IDs and passwords with specific permissions assigned to each client. The user is then defined to be associated with one or more user groups. Each group can be associated with another user group, or with one or more projects, and so on. The scalability and flexibility of the repository allows a large, small, or expanding number of users to have limited or full access to groups and projects, read-only access, the capability to create, relate to, update, or delete objects, or a combination of all these parameters.

For more detailed information about Workgroup security settings, refer to the Workgroup Repository Administration Guide.

Analyzing Impact and Rebuilding the ApplicationRebuild functionality and impact analysis are powerful tools in project management.

The Rebuild process generates executable files by preparing all the objects that have changed in the enterprise repository. Rebuild automatically analyzes which objects in the package, if any, need to be prepared and the environment in which they need to be prepared, eliminating excessive and unnecessary processing of unchanged objects.

The Impact Analysis tool reports changes that have been made to objects or projects. It can be a useful tool for communicating to the team about modifications that have been made to repository entities and relationships. It also enables users to predict the impact that modifications will have on the larger application effort.

For detailed information about the impact analysis process, refer to the Developing Applications Guide and the Development Tools Reference Guide.

For detailed information on the Rebuild process, refer to the AppBuilder Deploying Applications Guide, nformation Model Guide, and the Enterprise Rebuild Guide .

Repository Installation and ConfigurationAppBuilder software can be installed from a network operating on WindowsNT or Windows2000. To install AppBuilder software, copy the installation software to a network location and install AppBuilder on individual machines. Install AppBuilder on individual machines by running the installation script or setup program directly from the file system. AppBuilder software can also be installed from the AppBuilder disk (CD-ROM).

Note Refer to the Installation Guide for Windows for detailed installation instructions.



Workgroup repository software can be installed and configured to run on numerous platforms using different network configurations and protocols. While there are many possible configurations, the two most commonly used are:

• Single Repository with Multiple Clients

The basic configuration in a distributed environment includes at least one client machine (where the Development Tools reside) communicating with at least one server machine (where the Workgroup repository resides).

• Multiple Repositories with Multiple Clients

Development projects occurring simultaneously (for example, Development, Training, and Integration projects) can be stored in separate repositories on separate servers. Clients with access to each server have access to the respective repositories.

For detailed information about repository configuration and management, refer to the Workgroup Repository Administration Guide . For mainframe repository administration details, refer to the Enterprise Administration Guide.

Migration FacilityThe AppBuilder Migration facility in Freeway Explorer provides a method for moving objects between workgroup repositories and the mainframe repository. You can migrate individual objects or entire object hierarchies using the export and import functions.

• In the export phase, you migrate object information from a workgroup repository into migration files.

• In the import phase, you use the information in the migration files to migrate the exported data into another workgroup or a mainframe repository. Both the export and import phases of migration are performed from a client workstation.

The migration tool produces log files that track and report the results of migrations for project management. It assesses differences between data in the source and target repositories and documents modifications that are made to objects (create, update, delete, or compare) when an import is performed.

Import and Export UtilityThe Import and Export utility allows repository administrators to import and export data to or from a Workgroup repository. The import and export utility extracts the contents of the Workgroup tables into an independent format that can be transferred between platforms.

For detailed information about managing workgroup repositories, refer to the Workgroup Repository Administration Guide.

Note The Application Folder CDIF Import tool does not perform impact analysis. In an Application Folder Import, objects are merged into the existing repository overwriting existing data, if necessary.


CHAPTER

3 APPLICATION DESIGN TOOLS


AppBuilder provides an easy-to-use environment for the specification of application configurations at every level of development. The tools available in Workbench and the repository interface allow you to design the application model, create and modify the objects and relationships, and create your application user interface, functionality, and deployment options.

Open Architecture DesignApplications designed with an open architecture are deployable unrestricted by distribution, platform, and Internet architecture limitations. AppBuilder application specifications are defined by business rules and related forms that are not dependent on a specific platform.

The following topics describe AppBuilder’s application design capabilities:

• Integrated Development Environment

• Application Specification Tools

• User Interface Design Tools

• Scripting Tools

Integrated Development EnvironmentIn AppBuilder, the tools for designing and developing eBusiness or standard applications are integrated into one toolset called the Construction Workbench. This is an integrated development approach that provides a workspace for all your development tasks, from application design and object creation to testing and deployment.

Construction Workbench Toolset

The Construction Workbench tools allow you to create and edit rules that are saved as entities in the repository and encapsulate the business logic at a functional level. From the Rules Language source code, application code can be generated and configured and user interfaces created.


Open Architecture Design

Construction Workbench tools on the workstation include:

• Rules Editor

• Window Painter

• Report Painter

• Configuration Designer

Figure 3-1 The AppBuilder Construction Workbench Interface

The Workbench also offers access from within the interface to these related AppBuilder tools:

• Integrated Deployment Engine

• TurboScripter Scripting Tool

• Rules Debugger

• Workgroup Repository

3-24 Application Design Tools


Application Specification ToolsAppBuilder application specification tools create and modify models that reflect the state of objects in the repository. These tools create the objects and relationships in the repository. Use these specification tools to define your application’s logical design and its user interface and interactive functions:

• Entity Relationship Diagrammer

• State Transition Diagrammer

• Database Diagrammer

• Process Dependency Diagrammer

• Window Flow Diagrammer

• Matrix Builder

Using the repository, the AppBuilder toolset provides traditional information engineering specification tools in a graphical interface. With the business logic rules language, this set of specification tools allows your development team to focus on application development solutions, rather than on platform-specific implementation details.

Entity Relationship Diagrammer

Use the Entity Relationship Diagrammer to specify the logical structure of the data in an organization. An entity relationship diagram defines a cohesive data architecture for systems development and helps ensure that you have defined all enterprise data. Its forward engineering feature generates relational objects from the entities, relationships, identifiers, and attributes represented in the logical model.

State Transition Diagrammer

Use the State Transition Diagrammer to identify the states data go through and the internal and external events to which an application must respond. Transitions between states help outline the business rules an application needs.

Database Diagrammer

Use the Database Diagrammer to specify a relational database and create an application hierarchy (structural model) from the logical database hierarchy (relational model) that the forward engineering process generates.

Process Dependency Diagrammer

Use the Process Dependency Diagrammer to specify the logical structure of the processes in an organization. Process dependency diagrams show the set of actions or processes initiated by a given event.



Window Flow Diagrammer

Use the Window Flow Diagrammer to specify the window flow, the user interaction, and event handling. Window Flow Diagramming allows for prototyping the user interface of an application without having to code the associated user interface event handlers and business logic for the application.

Matrix Builder

Use Matrix Builder to build matrices that show associations between objects to organize your data and maximize object and process reuse. With Matrix Builder, you can coordinate multiple processes that share an entity or attribute ensuring that the data associated with the entity is sufficient. Matrix Builder displays entities as matrix elements in rows and columns and relationships as intersection data.

User Interface Design ToolsAppBuilder Workbench provides tools to create high-functioning, user-friendly interfaces for your applications and web forms. AppBuilder allows you to configure the logic that your data follows, from beginning to end through application deployment and execution. The following tools are discussed in this section:

• Window Painter

• Configuration Designer

• Windows Report Painter

Window Painter

Use the Window Painter tool to define, prototype, and build sophisticated graphical user interfaces (GUIs) and 3270-based forms. The components of a user interface can all be created here, including the:

• fields

• list boxes

• push buttons

• radio buttons

• interactive elements of web pages and forms

You define the properties, placement, and function of window objects using either an AppBuilder-supplied template or the forms wizard that guides you through custom forms design. The window objects allow your end-user to view and input data. The functionality you define to these objects then implements and processes the data that controls the execution of your application.

Configuration Designer

After the business logic and windows are created and saved in a repository, define the configuration using the Configuration Designer. Configuration involves defining partitions, the assignment of parts of the application to various clients and servers on various machines in the network. With the integration of this functionality in Construction Workbench, you can easily see which rules are deployed on which



machines and toggle between views of the configuration and the business logic by clicking a tab in the interface.

Figure 3-2 The Configuration Designer Interface

Windows Report Painter

The Windows Report Painter allows you to create and modify report definitions in the repository. These definitions generate COBOL reports for execution on the mainframe or Java reports for execution from a JVM. This tool offers the same functionality as the Seer*HPS 5.3 Report Painter and is fully compatible with reports generated using that tool.

Scripting ToolsTurboScripter and TurboCycler are powerful scripting tools that provide access to repository objects and can use the high-level specifications created by the drawing tools to produce robust applications.



Figure 3-3 TurboCycler Template Setup Dialogr

TurboScripter

TurboScripter is a COM-based Visual Basic (VB) scripting language that can be used to automate certain portions of application development. It uses VB scripting, providing ease-of-use and access to third-party COM objects or proprietary objects to automate development tasks.

TurboCycler

TurboCycler is a tool available in the workstation Construction Workbench that can be used to generate or maintain objects from existing repository objects using automated tasks that you define. Used with the TurboCycler Development Kit, it provides pre-defined templates to automate repetitive tasks.

For more information about AppBuilder scripting tools, refer to the Scripting Tools Reference Guide.


CHAPTER

4 MULTIPLE PLATFORM DEVELOPMENT CONCEPTS


Business applications that require new, Internet-based technology can be updated using the AppBuilder code generator. Using AppBuilder, you can create applications that are executable on a variety of platforms, allowing you to integrate new technology and maximize your application’s functionality with minimal effort.

Web Application DevelopmentThe AppBuilder Java development environment allows objects defined in the repository to be compiled into fully-operational applications on different platforms and in different architectures, including web browsers, Java application servers, C-based servers, and COBOL-based servers on OS/390 using CICS.

The generated code used in web applications is now subject to industry standards intended to regulate quality and reusability. AppBuilder follows industry standards by generating code for all supported platforms. The generated code is well-structured, readable, and maintainable. The reusability and order of structured code permit the creation of platform-independent, non-proprietary applications.

As part of the AppBuilder code generation process, multiple options can be specified that cover all the deployment options, from monolithic (all layers on the same platform and interaction through local calls) to totally distributed (each layer on a different platform from the web browser to the host).

The following section discusses Supported Platforms and Protocols for AppBuilder.

Supported Platforms and ProtocolsFigure 4-1 illustrates the platforms and communication protocols supported in AppBuilder:


Web Application Development

Figure 4-1 Supported Platforms and Protocols

4-30 Multiple Platform Development Concepts

AppBuilder Development Process


AppBuilder provides a toolset to create objects and routines to create applications. The toolset offers methods to capture business problems, assess design solutions, and program the rules required in the application to manage business logic.

The preparation and test steps supplied in the methodology include the generation of actual code that can be migrated into the application, using the same language, user interface, and business logic that was used in the development environment.

The AppBuilder environment allows for a high degree of reuse in the data specification and database design phases of software development. The application specification is designed to maximize efficiency, control, and application stability.

A typical AppBuilder development process consists of the following steps:

1. Analyze - Model the data and processes of a system

2. Design - Design the database

3. Prototype - Model the window flow of the application and construct a functioning prototype

4. Construct - Develop the application hierarchy, windows, views, and business logic

5. Test and Prototype - Generate and test the rules

6. Partition and Deploy - Prepare the application for the target environment and deploy

AppBuilder client/server application development is accomplished using the AppBuilder Construction Workbench. The icons, menus, windows, and reports that constitute the application’s user interface are built using the tools in the Construction Workbench. The application logic code is created using the AppBuilder Rules Language.

When development is complete, the AppBuilder Construction Workbench prepares the client and server sides of the application for local or remote execution.

The following topics describe the AppBuilder application development process and options for code generation and deployment using AppBuilder:

• Hierarchy, Configuration, and Partitions

• Preparation and Rebuild

• Debugging and Testing

• Java Client Deployment

• Server Deployment

• Generation for Traditional Technologies

• OpenCOBOL Generation Facility

Hierarchy, Configuration, and PartitionsAppBuilder provides a user interface that allows you to view, organize, and modify your application using a hierarchical structure.

The project represents the highest level in an application hierarchy. It contains the business function and associated configuration of the application.



The function represents the highest-level business process or primary purpose of the application. Functions contain groups of processes that sub-divide the application into components based on the tasks they perform and their relationships to each other.

A configuration describes how the application is to be deployed on actual machines. The settings for a project define whether the application is standalone or distributed. If distributed, the configuration settings determine which configuration or set of configurations apply.

Before deploying the application, you define the configuration of the application and the partitions (assignments of parts of the application to various clients and servers on various machines in the network). Use the partitions to specify how the parts of the project are prepared.

Preparation and RebuildDepending on the deployment and execution environment, application preparation or rebuild may include these steps:

• Create database tables, if database access is required

• Prepare any external files used by a rule

• Prepare windows when you submit a window (for C client) or when you submit a rule for preparation (for Java client)

• Transform rules and groupings of rules into an executable program

• Compile source code for any external code components used by a rule

• Prepare any sets that the application uses

• Make available to the run-time environment the menus, shortcuts, windows, and workstation reports that comprise the application end-user interface

• Prepare mainframe rules for test execution on the workstation or check the syntax of those rules

Debugging and TestingRule source code debuggers are available for both C and Java development. The C or Java Debugger is launched from Construction Workbench using the same process that launches the run-time (execution) client from within the workbench. See the Deploying Applications Guide for detailed information.

Java Client DeploymentAppBuilder generates Java code that is consistent with three different application architectures, including:

• HTML (Thin-client) with Java Servlet

• Java Client (Thick-client) with EJB Server

• Windows NT, XP, and 2000 Clients



HTML (Thin-client) with Java Servlet

Thin-client HTML technology allows client machines to call application, database, and administrative files that reside on a server for data processing. HTML client and Java servlet generation can be used to develop web applications.

Java Client (Thick-client) with EJB Server

In addition to HTML, AppBuilder can generate full Java clients. The presentation generation produces a full Java Graphical User Interface (GUI). Complete Java class files are generated with each AppBuilder rule becoming a Java Enterprise Java Bean (EJB). When the objects are prepared, the class files are generated in a Java run-time folder.

Chapter 5, “J2EE Technology Concepts” describes the Java development process and Java functionality using AppBuilder in greater detail.

Windows NT, XP, and 2000 Clients

Conventional run-time implementations can be generated, including thick C Language Windows run-time clients.

Server DeploymentAppBuilder supports web and application server deployment for Java applications. Using Sun Microsystem Java Version 2 Enterprise Edition (J2EE) standards for application server environments, AppBuilder Java development provides a secure, reliable gateway to back-end systems. Business logic can be applied through web application interfaces and databases.

AppBuilder also generates code using C on AIX, HP-UX, IBM iSeries and AS/400, that is deployable on Windows NT, XP, and 2000 environments, or using COBOL for CICS or IMS mainframe systems.

COBOL can be generated using the existing AppBuilder COBOL or an open COBOL generation facility. The OpenCOBOL generation facility creates a one-to-one relationship between AppBuilder rules and COBOL programs and generates standard COBOL source code. OpenCOBOL can execute in three environments: CICS, IMS, BATCH, and both.

The following sections discuss the server configurations supported for AppBuilder development in C language:

• Supported Workstation Server Types

• Supported Host Server Types

Supported Workstation Server Types

You configure each AppBuilder workstation node by defining the node either as:

• A client and agent

or

• An application server and agent


Generation for Traditional Technologies

After installation, you can configure the node as a gateway or batch server.

Supported Host Server Types

For each host type, the corresponding directory structure contains the following:

• an initialization file (INI)

• an error log or trace file

• run-time tables

• a server executable.

The host server types supported in the AppBuilder environment are:

• Client

• Application Server

Client

In a distributed application, client programs request services from a host server. A service, or AppBuilder server rule, is code that performs some task—database access, for example—for the client.

Application Server

An application server invokes user-supplied services at runtime. A distributed application might use these services to retrieve information from a database using these processing steps:

1. Read a requested service from a client

2. Wait for a response

3. Continue processing after receiving a response

An application server responds to Remote Procedure Calls (RPC) from the client.

Generation for Traditional TechnologiesAppBuilder can deploy applications to a number of platforms and architectures. In situations where the performance that C language development offers is important, AppBuilder is deployable to native C or COBOL from the same repository source and the same application specification.

You may want to deploy some of your applications on traditional platforms for the following reasons:

• As a backup for a development project in Java

• To reduce risk and liability when testing new technology

• To run faster in C or to increase performance on a given architecture

From the Construction Workbench, you can deploy the same rules to different platforms in different languages.

Refer to the Third-Party Support Matrix at the customer service website for details about all the current platforms and languages supported.


OpenCOBOL Generation Facility

Run-time Host TypesThere are five host types available for use during application runtime:

OpenCOBOL Generation FacilityAppBuilder offers improved run-time flexibility with an optional OpenCOBOL generation facility. This facility supplies readable, maintainable source code that conforms to industry-standard COBOL functions and data formats. External libraries required by the generated COBOL are provided in the source and compiled (binary) form, eliminating the need for a separate runtime. The generated COBOL is callable externally and from within AppBuilder applications, providing the maximum open source capability.

Features of OpenCOBOL:

• Does not require the use of a separate runtime

• Conforms to standard COBOL functions and data formats

• User choice of AppBuilder COBOL or OpenCOBOL generation

• COBOL performance is improved

• One externally-callable COBOL program is generated from each AppBuilder rule

• Options are provided for the following configuration settings:

- VIEW and SET preparation

- BIND FILE REGEN

• Creates a separate copybook library for OpenCOBOL programs

• Uses dynamic COBOL calls

The OpenCOBOL generation facility does not replace the existing AppBuilder COBOL generation facility; both options are supported.

For detailed information about OpenCOBOL generation, refer to the Rules Language Reference Guide and the Enterprise Application Guide.

Table 4-1 AppBuilder Host Types

Host Type Description

client Requests services from a server

application server Invokes user-supplied run-time services

agent Manages remote prep and event distribution

gateway Re-routes client requests through different protocols

batch server Invokes a single-service DLL at run-time

forwarding servera

a. this serves as an application server but is configured after installation.

Application server that is configured after installation


OpenCOBOL Generation Facility


CHAPTER

5 J2EE TECHNOLOGY CONCEPTS


The AppBuilder toolset and repository technology includes powerful application development for the Java Version 2 Enterprise Edition (J2EE) environment with full Java client and servlet-based HTML clients and Enterprise Java Bean (EJB) support. The following topics describe how AppBuilder Java is implemented:

• Java Features in AppBuilder

• HTML Thin-Client Generation

• Full Java Client Generation

• Enterprise Java Bean Generation

• J2EE Integration

In addition, this chapter discusses the following topics:

• Java Enhancements

• Java Development Limitations

Java Features in AppBuilderAppBuilder 2.1 delivers the following Java features:

• Server components deployable as Enterprise Java Beans

• Embedded SQL support for AppBuilder database access rules

• Java database connectivity

• Generation of thin HTML-based web clients using Java servlets

• A portable application development process

• Support for C user components

• Java Report Writer capability

• Product packaging and deployment enhancements

• Debugger for all Java platforms

Figure 5-1 shows an example of an AppBuilder Java implementation scenario.


HTML Thin-Client Generation

Figure 5-1 Java Implementation

HTML Thin-Client GenerationHTML thin-client technology offers flexibility in application development by allowing application, database, and administrative files to reside on a server and be called by client machines only when needed for processing data. AppBuilder offers HTML client and Java servlet generation, a truly thin-client architecture, that does not require a Java Virtual Machine on the client.

Using thin-client generation, AppBuilder allows you to create two separate components within the traditional client portion of an application:

• A thin HTML presentation component that runs in a browser

• Java servlets that run on a web or application server

The HTML component operates directly in the web interface on the client machine. The servlet provides “active” content for a browser-based form that can be shared with other Enterprise Java Bean (EJB) and Java components created with AppBuilder, or with other third-party tools.

AppBuilder also provides Java open source libraries that maintain the state of a multi-display presentation, something web browsers cannot do independently. The fact that browsers are inherently non-conversational need not limit the range of possibilities; the servlet side of the application manages any desired conversational aspects automatically. This feature makes it possible to generate thin HTML forms from the same specifications used to generate thicker Java clients. Figure 5-2 illustrates the thin-client deployment scenario using AppBuilder.

5-38 J2EE Technology Concepts

Full Java Client Generation

Figure 5-2 Thin-Client Deployment

Fundamentally, Java servlet technology is the Java version of CGI/NSAPI/ISAPI. It dynamically generates HTML from client requests. To maintain application data, state, or call stacks between servlet requests, AppBuilder allows the generation of thin HTML-based web clients based on Java servlet technology. These servlet applications are developed using a typical client application development process. They operate with a smaller footprint, requiring less data to be downloaded to the browser client. This savings in data migration minimizes time and efficiency considerations that are especially important in web application functionality.

Full Java Client GenerationIn addition to HTML, AppBuilder can generate full Java clients. In full Java clients, the presentation generation produces a full Java GUI. Complete Java class files are generated when the objects are prepared because, using AppBuilder Java generation, each rule becomes a Java Bean. The class files are generated in a Java run-time folder for easy management and reuse. Additionally, any existing or third-party Java Bean can be readily integrated into AppBuilder rules.

Figure 5-3 shows how full Java client servlets can be deployed in the AppBuilder environment.


Enterprise Java Bean Generation

Figure 5-3 Servlet Deployment

The Java client can be deployed in several different ways:

• Applications can be downloaded from a web server either by calling every rule when needed or by downloading the JAR file. No AppBuilder software needs to be installed on the client

• Traditional distribution of class or JAR files to the individual client machine or a file server

At runtime, the Java application can be invoked in several different ways:

• Directly from the command line

• From a supplied execution client Java application

• From a supplied execution client applet; for example, one that is contained in an HTML page

• From any other Java program

Enterprise Java Bean GenerationJava applications, downloaded from the web or executed from the desktop, communicate with middle-tier AppBuilder services deployed as EJBs. Thin HTML-based web client applications using Java servlets communicate with both AppBuilder EJB services and C Language AppBuilder services.

AppBuilder supports the generation of EJBs on the server. These modules are accessible from AppBuilder Java clients, as well as other third-party Java clients. At a minimum, two interfaces, a class and an XML document, must be created and maintained for every EJB. A change to one of these files necessitates changes to all the other files.

Using AppBuilder, EJBs are as easy to support as any component on another platform. The developer specifies that a particular partition be deployed as EJBs and AppBuilder generates all the objects necessary, including the remote interface, home interface, and deployment descriptor XML.

Generated EJBs can execute in the context of any application server that supports EJBs and they require no other runtime. Figure 5-4 shows the EJB deployment scenario from the repository to the application server.


Enterprise Java Bean Generation

Figure 5-4 EJB Deployment Model

Application Server SupportAppBuilder supports Java RMI as a communication mechanism between the browser-based client and the web or application server. By providing application server support, AppBuilder provides an environment for the construction of robust, Java-based applications able to execute in the context of third-party browsers and application servers.

An application developed using AppBuilder executes using any configuration of browser-to-web server or browser-to-application server, thus allowing flexibility in your choice of eCommerce architecture. This flexibility allows you to update the architecture without impacting the functionality of the applications built using AppBuilder.

Communication Layer

The AppBuilder communication layer enables server components to be deployed on multiple platforms and protocols. This affords applications the flexibility to scale from small client/server implementations to large mainframe-based applications across an entire enterprise.

The user interface is an HTML page in a servlet-based client application. The Window Painter tool in the AppBuilder Construction Workbench generates a text representation of the HTML page during development. The generated HTML window is edited using a third-party HTML editor and stored in the repository, along with the AppBuilder window definition.

The Microsoft Internet Explorer (IE) web browser displays the application’s HTML user interface and forwards input requests to AppBuilder. The AppBuilder servlet rules then communicate with other AppBuilder services on other platforms or access databases via SQLJ-JDBC.

Note AppBuilder is supported on IBM WebSphere, BEA WebLogic and Apache Tomcat servers.


J2EE Integration

J2EE Integration

AppBuilder leverages the strengths of standard AppBuilder functionality with the requirements of web commerce. Using J2EE application server standards, AppBuilder provides seamless integration and a secure, reliable gateway for Java applications communicating with back-end systems and databases. AppBuilder packages newly-generated applications in formats that are easily deployable on any J2EE-compliant application server. Existing application deployment procedures are streamlined with thin web-based clients and EJB servers. Thin HTML-based web client applications using Java servlets communicate with both AppBuilder EJB services and C-language AppBuilder services.

Communication configurations using NetEssential-TCP/IP with all AppBuilder services is supported. Java applications can be downloaded via HTTP and executed from within a browser. Figure 5-5 illustrates the communications protocols supported in AppBuilder and the data migration process for web application development.

Figure 5-5 J2EE Application Server Development

EJB ContainerThe EJB Container runs and manages components generated by AppBuilder. It handles communication from the client application to the EJBs by defining the implementation settings for the interfaces that define the EJB.

The EJB Container:

• Listens for client requests

• Manages the state of the EJBs within the container

• Handles security


Java Enhancements

Component PackagingSun Microsystems’s J2EE standard for packaging components enables portable deployment to any compliant application server. AppBuilder uses this standard to generate J2EE packages for Enterprise Java Bean (EJB) and servlet components, allowing these components to be deployed to a wide variety of application server vendors.

An EJB, or servlet module, is generated from an AppBuilder Partition object. All the objects that make up a particular Partition, along with the modules deployment descriptor XML, are packaged together in an archive file (JAR for EJBs and WAR for servlets).

After the AppBuilder components are packaged into modules, the modules are deployed as stand-alone units, or assembled with other J2EE modules and deployed. The process involves preparing and packaging data in the repository to be defined as EJB modules that deploy to application servers.

For detailed information about generating EJB modules, refer to the Developing Applications and Deploying Applications Guides.

Java EnhancementsSeveral new features have been added to AppBuilder to improve the usability of AppBuilder for Java development:

• Java Report Writer

• CLEAR_WINDOW_CHANGES Component

• C User Components in Java

• Thread-Safe Components

• Running a java application in a browser within an internal frame

Java Report WriterTo complement AppBuilder Java technology, a report generation facility for Java, similar to the existing report writer, is now available that generates Java classes (and COBOL) from the repository’s report definitions. These classes can then be invoked from any Java platform by either AppBuilder or third-party applications to produce the report. This facility is compatible with existing report definitions, allowing clients to publish existing reports in Java.

CLEAR_WINDOW_CHANGES ComponentSupport for the CLEAR_WINDOW_CHANGES system component is included in this release for both Java and HTML clients, in addition to currently supported 3270 and Windows clients.

This component resets the status of window objects to the status of the window when it was originally created. As with all Java system components, this component is not deferred, but executed immediately on the currently active window.


Java Development Limitations

C User Components in JavaAppBuilder allows C user components to be called from Java. For an existing C user component to be called from Java, you must re-prepare it for a Java Partition. During this process, the Java Native Interface (JNI) entry function is generated and compiled into the user component. For this reason, user components compiled for Java are not compatible with those compiled to be called from C.

Thread-Safe ComponentsAppBuilder C user components are architecturally not thread-safe. References to the view structures are implemented as static global variables. Previously, this was not an issue because both AppBuilder client and server applications were not multi-threaded. However, Java applications developed in AppBuilder are multi-threaded, especially the servlet and EJB applications where many clients may be executing simultaneously. To be used in Java, user components must be defined as re-entrant, so the components can be used simultaneously.

AppBuilder user components compiled for Java can be made thread-safe with a small modification to the user component source. This modification, while it does not affect the component when compiled for C, creates the references to the view structures locally, giving each caller its own reference. Since there is no restriction to the functionality contained within a user component, it may still not be thread-safe (that is, users may have created other global structures). With these modifications, calling the component and creating the view structure can be used in a multi-thread environment.

Java Development LimitationsAppBuilder application development using Java requires special consideration of the following limitations:

• C Runtime Unavailable

C components that are compiled for Windows are linked with AppBuilder C runtime, giving them access to all the run-time functions available to generated C rules. When these C components are compiled for Java, they are run-time independent making all run-time functions unavailable.

• Seer*HPS 5.3 C Component Format Required

Seer*HPS 5.3 introduced an additional format for writing C user components that enabled these components to be compiled for both client and server platforms. This format specified that C functions should be defined as int system_ID (DCLRULEPARAM). The use of this format is also required for the C components to be compiled for Java.

• Global Views Not Supported

The implementation of this feature in C relies on the component and the runtime sharing the same view object in the same memory space. The differences between C and Java programming make any possible implementation semantically different than the original C version; for that reason, sharing of global views between AppBuilder Java applications and C components is not supported.


Index

INDEX


Aapplication server

description 4-34application specification

configurations 3-23

BBEA WebLogic

Java support 1-4

CCOBOL

creating SOAP-XML interfaces 1-8open generation facility 4-35remote prepare facility for 1-10server deployment 4-33

componentscalling C from Java 5-44Clear_Window_Changes 5-43

CONFIGURATIONdefinition 4-32

Configuration Designer 3-26connectivity

extended 1-6Construction Workbench

toolset 3-23

DDatabase Diagrammer (DBD) 3-25debugging applications 4-32deployment

distributed 4-29monolithic 4-29

development processsteps 4-31toolset description 4-31

EEJB

generation 5-40Enterprise Java Bean generation 5-40Entity Relationship Diagrammer (ERD) 3-25execution environment

in application preparation 4-32export and import functions 2-21extended connectivity 1-6

Ffeatures

repository-based development 2-14Freeway Explorer

opening 2-17tools 2-17

FUNCTIONdefinition 4-32

GGROUP

objects 2-19

Hhost

remote preparation 1-9run-time 4-35server types 4-34

HTML thin-client generation 5-38HTTP

SOAP common transport 1-7

IIBM WebSphere

Java support 1-4impact analysis 2-20import and export

in Workgroup repositories 2-21

AppBuilder 2.1.0 Product Concepts Guide i

Information Modelusing to set entity types 2-18

Internet developmentchallenges in 1-4enterprise-wide 1-4

JJ2EE

development using AppBuilder 5-37J2EE integration 5-42Java

application invocation methods 5-40application packaging 1-5client deployment 4-32debugger 4-32development process 1-5development support 1-4enhanced features 5-43server deployment 4-33thick client EJB 4-33thin client servlet 4-33

Java clientdeployment options 5-40

Java client generation 5-39Java GUI 5-39Java Native Interface (JNI) 5-44Java RMI 5-41Java Version 2 Enterprise Edition (J2EE) 5-37

MMAP

statement options 1-10Matrix Builder (MXB) 3-26migration

using Freeway Explorer 2-21

NNetEssential

remote configuration and management 1-8remote start/stop 1-8silent NetE install and configuration 1-8

network protocolssupported 1-3

OOpen COBOL Generation 1-10

Ppartitions

definition 4-32

Permissionsdefinition 2-20

platformssupported 4-29

preparationsteps 4-32

Process Dependency Diagrammer (PDD) 3-25programming languages

supported 1-2PROJECT

definition 4-31objects 2-19

protocolsnetwork 1-3supported 4-29supported network 1-2

Rrebuild

process in repository 2-20steps 4-32

Rebuild facilityoverview 1-9

Report WriterJava report generation 5-43

repositoryadministration tasks 2-18development process 2-13Enterprise or mainframe 2-16installation and configuration 2-20migrating objects 2-21multiple with multiple clients 2-21personal or local 2-15single with multiple clients 2-21types 2-15Workgroup administration 2-16Workgroup or Freeway 2-15

Rules Languageenhancements 1-10MAP statement options 1-10SET statement options 1-10

run-time host types 4-35

SScope

definition 2-20scripting tools

TurboScripter 3-27security

setting in repository 2-19service

definition 4-34

ii AppBuilder 2.1.0 Product Concepts Guide

servicesuser-supplied in application servers 4-34

SETstatement options 1-10

Simple Object Access Protocol (SOAP) 1-7State Transition Diagrammer (STD) 3-25support

environment 1-2HTML 1-4J2EE 1-4Java development 1-4network protocols 1-2platforms 4-29programming language 1-2protocols 4-29

system requirements 1-1

Ttest execution

preparing mainframe rules 4-32testing applications 4-32thin-client generation 5-38tools

application specification 3-25preparation and rebuild 4-32

TurboCycler 3-28TurboScripter 3-28types of repositories 2-15

UUSER

objects 2-19user interface

design tools 3-26Hierarchy, Configuration, and Partitions 4-31

Wweb development

using AppBuilder 4-29Web Service Definition Language (WSDL) 1-7Web Services

AppBuilder deployment 1-7Window Flow Diagrammer (WFD) 3-26Window Painter 3-26Windows

run-time implementations 4-33Windows Report Painter 3-27

Workgrouprepository actions 2-18required repository security information 2-18security 2-19server browser 2-17

workstationserver types 4-33

XXML SOAP Web Services 1-7

Index iii

appbuilder 2.1.0 product concepts guidedocshare02.docshare.tips/files/18431/184314649.pdf · the...

Documents