Architectured RAD: Tackling the Challenges of on Demand Business - The Process Partitions

(Page 3 of 3 )

Part 1 -- Business requirements with UML

Defining and analyzing business requirements should be done by an analyst who is comfortable with business-level UML modeling and with mapping these models to database persistence. Database analysts will require some UML training to perform this role.

· Estimate work effort using IBM Rational RequisitePro and IBM Rational Rapid Developer.

The analyst gathers requirements using IBM Rational RequisitePro -- consisting of use cases that describe the Web, wireless, and integration functions of the application.

Then, IBM Rational Rapid Developer provides a project estimator that can estimate the work effort required to develop the application, based on these use cases. This enables the project leader to accurately estimate the size of the project team, staff the project with the requisite skills, and plan out the project timeline.

· Model visually using IBM Rational Rose or IBM Rational XDE

The analyst can then use IBM Rational Rose or IBM Rational XDE for UML modeling. Depending on the application's complexity, the analyst may choose to use all or only some of the UML models. The most essential is the UML Class Model. Each class represents an entity (or a business object) in the application: customer, order, product, and so forth.

· Import class model from XDE into Rational Rapid Developer

The class model is imported from IBM Rational XDE into IBM Rational Rapid Developer (Figure 3). This model can be resynchronized at any time. In some projects that do not need full UML modeling, the Class Architect built into IBM Rational Rapid Developer may be used instead of IBM Rational XDE or IBM Rational Rose (see Figure 8).

· Import legacy database models

In our marketplace application, the product catalog data is resident on a legacy IMS database. IBM Rational Rapid Developer provides connectors to almost every legacy database, including IMS, VSAM, ADABAS, IDMS, and so on. To connect to the product catalog IMS database, an IBM Rational Rapid Developer import process runs on the mainframe that converts the IMS database schema (in COBOL copybooks) into an XML schema file. This XML schema file is then imported into IBM Rational Rapid Developer as a class model. We then link the class model imported from IBM Rational XDE with the IMS class model to complete our application class model.

· Establish database persistence

The product classes have already been made persistent in the IMS database. The remaining classes will be made persistent in a DB2 database. IBM Rational Rapid Developer can perform object-to-relational mapping and create database schema for all popular relational databases, including many versions of DB2, Sybase, Microsoft SQL Server, and Oracle. For the application in this scenario, we create a database schema in DB2 V7.

· Define business rules

We can now define business rules in IBM Rational Rapid Developer as validation, derivation, and initial value expressions on the attributes of entities. Rule examples are: inventory check, order item pricing, order pricing, customer credit check, and so forth. Rules are defined using a Java business rule editor.

· Define business processes

Optionally, the analyst can also define business processes in the application: for example, an order process for checking out a Web order. A business process is defined as a state chart/activity diagram. These process models are purely analytical and do not lead to any direct code construction.

So far, we have created the core infrastructure UML models of this marketplace application: class model, database persistence, business rules, and business processes. We are now ready for rapid user interface and integration development. Of course, even as we develop the application, we can still continue to refine the core UML models.

Part 2 -- Develop user interface(s) rapidly

In IBM Rational Rapid Developer, user interface development consists of the following activities:

• Define site flow models for each actor of the application -- performed by an analyst.
  
• Define the look and feel of the application with styles and themes -- performed by a graphic artist.
  
• Define the functional pages -- performed by a team of RAD developers.

· Create site models

This application has three types of human actors: buyers, sellers, and administrators. For each class of actor, a site model is designed that maps the flow of the users through the application. These site models should directly reflect the user interface use cases defined in Rational RequisitePro. This is the most important model for clearly communicating with business owners of the application, and it is crucial for projects in which joint application development with business users is important. In a typical Rational Rapid Developer project, the project room walls are full of large- size pictures of site models, and much of the design and discussion focuses on these models.

· Establish page styles and themes

In order to maintain a consistent look and feel for the application, and to be able to change it easily, a graphic designer creates: 1) visual style sheets for each type of control; 2) page templates for each type of actor; and 3) color themes, font themes, and image themes for the application -- all within IBM Rational Rapid Developer.

· Design Web pages

Most of the work in an application consists of page design. The application in our scenario consists of about eighty Web and five wireless pages to be implemented by five RAD developers. A developer with application development skills in almost any language or IDE -- Visual Basic, Power Builder, COBOL, RPG, and so on -- will find this a comfortable environment, and can be trained within days to be productive in IBM Rational Rapid Developer.

· Lay out pages visually

With IBM Rational Rapid Developer, page design is visual and rapid, and it is greatly facilitated with the Page Architect feature, as shown in Figure 9. Developers pick and place styled controls, attach them to attributes of entities, and specify their properties. IBM Rational Rapid Developer is a very rich user interface design environment for rapidly creating feature-rich Web applications. As a developer designs a page by laying out its controls, IBM Rational Rapid Developer automatically creates a page content model called ObjectSpace. Developers can refine the page content by adding selection, sort, grouping, and pagination specifications to ObjectSpace.

· Design page logic

In this application, thirty pages require business logic. For example, the OrderBasket page has a "submit" button that invokes the CheckOutOrder method to process the basket. This business logic is written in Java used as a 4GL language and is written with the assistance of Logic Architect, shown in Figure 10.

Business logic typically represents about five percent of the code in a running application. In order to make it easier to learn and write this logic, IBM Rational Rapid Developer provides nearly 100 code templates, which means that developers need only fill in parameters to write code. Development teams can also add their own templates.

After designing the page logic, a developer can quickly construct and test it. IBM Rational Rapid Developer automatically constructs, compiles, and deploys the application. This enables an iterative style of application development conducive to prototyping and joint application development with business owners.

· Internationalization of pages

After all pages are designed and tested, we internationalize the twenty buyer pages. We define the four locales, and for each locale we define the language, country, and code set. A developer then marks all the text and image controls on these pages that need to be localized.

A translation file is then created and exported in the developer's choice of translation formats -- TMX, XLIFF, CSV, or Excel. After translation, the returned translated file is imported back, and we can then view and test the translated pages in Page Architect. IBM Rational Rapid Developer automatically handles date, time, and currency formatting functions, but developers can optionally override them with their own logic.

· Additional application functionality

The marketplace application also leverages the following IBM Rational Rapid Developer capabilities:

• Advanced page design functions -- such as controlling page access through role-based security, defining client-side page logic, and overriding the generated HTML.
  
• Debugging via Websphere Application Developer -- code is constructed as a project in WSAD (and other IDEs), and it can be used to inspect and debug the code.
  
• Wireless page design -- IBM Rational Rapid Developer functionality helps us ensure adherence to the size of the wireless device screen by marking construction, using WML instead of HTML.

Part 3 -- Rapid integration development

The next step for the developers is integrating with a legacy IMS database (as defined in our requirements for this application). Describing all the steps involved in doing this would require another article, so for our present purposes, we will assume that this step is now complete. We are now ready to integrate with an internal order processing application, as well as B2B applications using XML messaging and Web services.

· Enterprise and B2B integration with XML

For integration with the JD Edwards order processing application, we first define that we are going to use IBM WebSphere MQ as our messaging facility and define two queues that will be used to communicate with this system.

We have defined 10 use cases (user interactions) for this system. Each interaction includes a request and a response; therefore, twenty XML messages will be exchanged over Websphere MQ. For each message, we read the XML DTD that defines the format of the message, and map it into an ObjectSpace (see Figure 11).

This is the same ObjectSpace that we encountered earlier in the Web and wireless development activity; the only difference here is that it is being mapped to XML, not HTML or WML. The mapping process is visual and rapid. For each request/response set, we also define the business logic that will handle the request and submit the response. This business logic is also the same logic that we encountered earlier during Web design. So, as you see, Web design and XML messaging are only superficially different.

Now we repeat this process for integrating with the buyer and seller systems.

· Integration with Web services

In this application, Web services are being used to invoke commonly available services from credit card and shipping vendors. We first use IBM Rational Rapid Developer to discover these Web services that have been published in a public UDDI repository.

Once these services have been discovered, it becomes very easy to invoke them from the correct place in our business logic. Most will be invoked from the order processing logic. In the IBM Rational Rapid Developer Logic Architect, all of the services are available from the services tab. The developer can click on a service, and a service call is inserted in the code, appearing as a Java method call. The developer then specifies the method call parameters, and then he is finished. IBM Rational Rapid Developer will automatically handle all the mechanics of invoking the service, using SOAP request/response mechanism for the target application server.

Part 4 -- N-tier architected deployment

At this point, we have completed our application development. The application is ready to be deployed by the team's technology architect, who deeply understands the target technologies and knows how an application can be optimally deployed with the desired degree of performance, scalability, security, and manageability. In contrast, the analyst and the developers active on the project so far have used their skills in modeling business functionality, but have not been required to delve into the underlying n-tier technologies.

In our scenario, the technology architect actually creates a number of staging deployment models. A key benefit of IBM Rational Rapid Developer is that an architect can deploy the same application in all of these varying environments, yet optimize it for each one. For each deployment model, the architect selects appropriate technologies, fine tunes the construction patterns, and partitions the application for optimum load handling on a server farm.

· Staging requirements

The staging deployment models defined by IBM Rational Rapid Developer Enterprise Application Architect feature (see Figure 12) are:

• One or more deployment models for developers. They use lightweight application servers (e.g. Tomcat or IBM WebSphere Express) and database technologies (IBM Personal DB2 or SQL Server) that can easily be installed on developers' laptops.
  
• A number of test deployment models for each stage of testing.
  
• A production model for the prototype phase, deployed on a single server using IBM WebSphere 4.0, IBM WebSphere MQ, and IBM DB2 7.0 UDB.
  
• A production model for the main production phase, targeted to deploy on a 100-server farm to support more than one million users. This will use WebSphere 4.0, WebSphere MQ, and DB2 on the mainframe. In this model, the architect fine tunes the construction patterns for the transactions that have the most volume. The Rational Rapid Developer Enterprise Application Architect feature also partitions the application on the 100-server farm by creating three main partitions for buyers, sellers, and administrators, and then further creating multiple n-tier partitions for each main partition.
  
• A production model for the next generation of technologies migrating to WebSphere 5.0 and DB2 8.0.

IBM Rational Rapid Developer will create a different and independently optimized code for each of these deployment models and package it for easy deployment.

IBM Rational TeamTest can now be used for functional and performance testing of the application. To aid in testing, IBM Rational Rapid Developer can automatically create sample data in the database.

Finally, the tested application is deployed, and the development team is ready for the next iteration.

---

Originally written by Arun Gupta
Copyright (c) 2000-2003 IBM Corporation. All rights reserved.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

Comments On: Architectured RAD: Tackling the Challenges of on Demand Business

>>> Be the FIRST to comment on this article!