JavaTechnologyArchitecturePlanning andDesign€¦ · Sun acknowledges the pioneering efforts of...

Sun Microsystems, Inc.MS BRM01-209500 Eldorado BoulevardBroomfield, Colorado 80021U.S.A.

®

JavaTechnologyArchitecturePlanningandDesign

Part Number 805-4478-01

Revision A.1, July 1999

SL-410

StudentGuide

Please

Recycle

Copyright © 1999 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303, U.S.A. All rights reserved.

This product or document is protected by copyright and distributed under licenses restricting its use, copying,

distribution, and decompilation. No part of this product or document may be reproduced in any form by any means

without prior written authorization of Sun and its licensors, if any.

Third-party software, including font technology, is copyrighted and licensed from Sun suppliers.

Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a

registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd.

Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaSoft, JavaBeans, Enterprise JavaBeans, JDBC, SunTea, 100% Pure

Java, JavaHelp, SunLink, JDK, JavaStation, JavaStar, JavaScope, JavaSpec, JavaScript, Java HotSpot, Java Workshop,

JavaOS, Java Naming and Directory Interface, Solstice SunScreen, and NFS are trademarks or registered trademarks of

Sun Microsystems, Inc. in the U.S. and other countries.

All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc.

in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun

Microsystems, Inc. Netscape Navigator is a trademark of Netscape Communications Corporation.

The OPEN LOOK and Sun Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees.

Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user

interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface,

which license also covers Sun licensees who implement OPEN LOOK GUIs and otherwise comply with Sun written

license agreements.

RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-

14(g) (2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015 (b)(6/95) and DFAR 227.7202-3(a).

DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS,

AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A

PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH

DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.

iiiCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

ContentsAbout This Course .................................................................................... xiii

Course Map........................................................................................ xivModule-by-Module Overview ......................................................... xvCourse Objectives........................................................................... xviiiSkills Gained by Module.................................................................. xixGuidelines for Module Pacing ......................................................... xxTopics Not Covered.......................................................................... xxiHow Prepared Are You?................................................................. xxiiIntroductions .................................................................................. xxivHow to Use Course Materials ........................................................ xxvCourse Icons and Typographical Conventions ........................ xxvii

Icons ........................................................................................ xxviiTypographical Conventions ............................................... xxviii

Introduction to the Java Technology Architecture Process................1-1Relevance............................................................................................ 1-2Objectives ........................................................................................... 1-3What Does an Architect Do? ........................................................... 1-4

Tasks ...........................................................................................1-5Optional Tasks...........................................................................1-7Java Technology Architecture Goals......................................1-8Constraining Factors.................................................................1-9

System Architecture in Perspective.............................................. 1-10Overview..................................................................................1-10An Example Process ...............................................................1-11Process Steps............................................................................1-12

Why Is an Architecture Needed?.................................................. 1-15Architecture Notation..................................................................... 1-18Basic Three-Tier Architecture........................................................ 1-19Tier-to-Tier Communication ......................................................... 1-21

Protocols ...................................................................................1-21API Constraints .......................................................................1-21Sockets ......................................................................................1-22Remote Procedure Calls .........................................................1-23

iv Java Technology Architecture Planning and DesignCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Messaging ................................................................................1-23Distributed Object Communication ............................................. 1-24Advantages of Distributed Object Architectures ....................... 1-26Distributed Object Frameworks.................................................... 1-27Object Languages ............................................................................ 1-28Basic Three-Tier Java Technology Architecture ......................... 1-30

Overview..................................................................................1-30Applets, Applications, and Servlets .....................................1-33

Advantages of Three-Tier Architectures ..................................... 1-34Comparison of Three-Tier Communication Mechanisms ........ 1-36Overall Java Technology Architecture......................................... 1-40Java Technology Architecture Issues ........................................... 1-42Check Your Progress ...................................................................... 1-43Think Beyond .................................................................................. 1-44

Designing a Java Technology Architecture ..........................................2-1Relevance............................................................................................ 2-2Objectives ........................................................................................... 2-3Customer Application ...................................................................... 2-4

Application Description...........................................................2-4Customer Requirements ..........................................................2-6

Architecture Analysis ....................................................................... 2-8Customer Appraisal..................................................................2-8Java Technology Architecture Assessment .........................2-10Conversion to a Three-Tier Architecture.............................2-12Assessment So Far...................................................................2-14Applicability of Java Technology .........................................2-15Readiness of Customer...........................................................2-17

Advantages of Three-Tier Java Technology Architecture......... 2-19Application Architecture Design.................................................. 2-21

Tier One Tasks .........................................................................2-21Tier One Choices .....................................................................2-23Tier One Design.......................................................................2-24ECARS Client Summary ........................................................2-26Decisions to Make ...................................................................2-27Tier Two Functionality...........................................................2-32Tier Two Design Options.......................................................2-34Applications, Servlets, and CGI Scripts...............................2-36

Tier Two Architecture .................................................................... 2-40Servlet Architecture ................................................................2-40Web Server ...............................................................................2-41

Communication Protocols in a Three-Tier Architecture ........... 2-42Applet to Servlet APIs............................................................2-46Servlet-to-Tier Three Communication APIs .......................2-48

ECARS Summary for Communications ...................................... 2-50RMI Architecture Overview.......................................................... 2-52

vCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

RMI Features............................................................................2-54Object Naming and Locating ................................................2-56

Summary of the ECARS Solution ................................................. 2-57Tier One ....................................................................................2-58Tier Two ...................................................................................2-59Tier Three .................................................................................2-60Three-Tier Advantages...........................................................2-60Architecture Considerations Applied..................................2-61

ECARS Benefits ............................................................................... 2-62Exercise: Designing a High-Level, Three-Tier Architecture..... 2-63

Preparation...............................................................................2-63Exercise Summary...................................................................2-64

Check Your Progress ...................................................................... 2-65Think Beyond .................................................................................. 2-66

Java Technology Architecture Details ..................................................3-1Relevance............................................................................................ 3-2Objectives ........................................................................................... 3-3The Customer .................................................................................... 3-4

MedBroker Inc. ..........................................................................3-4Current Application Description............................................3-4The Problem...............................................................................3-5

Proposed Customer Architecture ................................................... 3-6Current Proposal .......................................................................3-6Application Requirements.......................................................3-7

Architecture Analysis ....................................................................... 3-9Architecture Framework Assessment.......................................... 3-11CORBA Architecture Overview.................................................... 3-12

Operations................................................................................3-13Services .....................................................................................3-15

DCOM Architecture ....................................................................... 3-16Operations................................................................................3-17Services .....................................................................................3-18

Comparison of Object Frameworks.............................................. 3-19Assessing CORBA for the Architecture ....................................... 3-21

CORBA Advantages ...............................................................3-21Performance and Reliability ..................................................3-21CORBA Implementation Choices .........................................3-22

CORBA Applicability ..................................................................... 3-24CORBA Architecture Implementation Considerations............. 3-25

Recommendation to Customer .............................................3-25Problem Assumptions ............................................................3-25

CORBA Implementation Stages.................................................... 3-27Applet Design Critical Issues ........................................................ 3-29Applet Design Details .................................................................... 3-32

Building the GUI .....................................................................3-32

vi Java Technology Architecture Planning and DesignCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Data Flow Through The Applet............................................3-33Class Downloading.................................................................3-34

Applet Design Elements ................................................................ 3-35Applet Rules .................................................................................... 3-37Tier Two Design Choices ............................................................... 3-39MedBroker Tier Two Design Summary....................................... 3-42

Trade-offs .................................................................................3-42Services to Build into the Application .................................3-44

Java IDL Architecture Overview .................................................. 3-46Tier Three Design............................................................................ 3-47The Final MedBroker Architecture............................................... 3-49Exercise: Design a Heterogeneous Object Architecture ............ 3-51



Integration With Existing Applications and Databases .....................4-1Relevance............................................................................................ 4-2Objectives ........................................................................................... 4-3Tier Three of the Architecture ......................................................... 4-4

Interfacing With Tier Three .....................................................4-4Constraints .................................................................................4-5Common Integration Techniques for Tier Three..................4-6

Existing Network Considerations .................................................. 4-8Dynaclaim Architecture ................................................................. 4-10Standard Tier Three Access Mechanisms.................................... 4-13

Comparing Access Mechanisms ...........................................4-13Relational Databases...............................................................4-14IMS Hierarchical Databases...................................................4-14CICS Transactions...................................................................4-15

The JDBC API .................................................................................. 4-16JDBC Connection Structure ...................................................4-16JDBC Architectural Details ....................................................4-17

JDBC Object Overview................................................................... 4-19JDBC and SQL ................................................................................. 4-20JDBC Driver Types.......................................................................... 4-22Two- and Three-Tier JDBC Designs ............................................. 4-27Other Database Architectural Considerations............................ 4-28

Database Performance Considerations................................4-28Connection Pool ......................................................................4-29Connection Pool Processing ..................................................4-30Database Abstraction..............................................................4-31

Alternative Data Access Mechanisms.......................................... 4-33Access Using a Native Program.................................................... 4-34Java and Native Methods............................................................... 4-36

viiCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Screen Scraping ............................................................................... 4-37Assessing Screen Scrapers ............................................................. 4-39

Advantages and Disadvantages ...........................................4-39Performance Issues .................................................................4-40

Assessing Screen Scrapers ............................................................. 4-42Evaluating Alternate Architectures for QuickQuote ................. 4-44

Review of Current Architecture............................................4-44Alternate QuickQuote Database Architectures ..................4-45Using Messaging for QuickQuote Persistence ...................4-46Using an ODBMS for QuickQuote Persistence...................4-48

Summary of Alternatives............................................................... 4-50Exercise: Designing a High-Level Three-Tier Architecture...... 4-51



Creating New Application Architectures ..............................................5-1Relevance............................................................................................ 5-2Objectives ........................................................................................... 5-3Qualifying the Application for Java Technology ......................... 5-4

Qualifying Attitude and Infrastructure .................................5-5Qualifying the Third Party Product .......................................5-6Qualifying the Existing Application ......................................5-7Java Technology Applicability................................................5-8

Migration Considerations ................................................................ 5-9Overview....................................................................................5-9Migration Trade-Offs..............................................................5-11

Gathering Information for the Architecture................................ 5-14Customer Preparation ............................................................5-16Customer Constraints.............................................................5-18

Evaluating Protocols and Products .............................................. 5-20Common Protocols and Products.........................................5-20Prototyping ..............................................................................5-21

Preparing for Reuse ........................................................................ 5-22Conventional Three-Tier Architecture.................................5-24Objects and Tiers .....................................................................5-26

Object Reuse..................................................................................... 5-28Architectural Variations................................................................. 5-29Enterprise JavaBeans Architecture ............................................... 5-30

JavaBeans..................................................................................5-30Enterprise JavaBeans Comparison .......................................5-30Containers ................................................................................5-31Enterprise JavaBeans Server..................................................5-33Enterprise JavaBeans Components ......................................5-36Bean Packaging and Deployment.........................................5-38

viii Java Technology Architecture Planning and DesignCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Enterprise JavaBean Types ....................................................5-39Locating Enterprise JavaBeans...................................................... 5-40Summary of Enterprise JavaBeans ............................................... 5-41

Architecture Implications ......................................................5-41Programmer Implications......................................................5-42

The Publish/Subscribe Architecture............................................ 5-43Events........................................................................................5-43Publishers and Subscribers....................................................5-44Benefits of Publish and Subscribe.........................................5-45

Publish/Subscribe and Three-Tier Architectures ...................... 5-47Implementing Publish and Subscribe ..................................5-47Publish/Subscribe Examples ................................................5-48

Assessing Publish/Subscribe Feasibility..................................... 5-50Assessing Alternate Architectures for PlasticDeSign, Inc......... 5-51

PlasticDeSign, Inc. Case Study..............................................5-51Enterprise JavaBeans Alternative .........................................5-52Publish/Subscribe Alternative..............................................5-54


Designing a Secure Java Technology Architecture .............................6-1Relevance............................................................................................ 6-2Objectives ........................................................................................... 6-3The Three-Tier Architecture and Security..................................... 6-4

Security In the Default Three-Tier Architecture...................6-4Applets and Security Manager ...............................................6-4Disadvantages ...........................................................................6-7

Basic Security Architecture............................................................ 6-10Typical Security Structure With Firewalls ..........................6-10DMZ..........................................................................................6-12Firewalls and Scalability ........................................................6-13Assess the Security Infrastructure ........................................6-14

Security Appraisal........................................................................... 6-15Security and Application Architecture ........................................ 6-16Addressing Security Requirements With Java Technology...... 6-17Security Techniques and Layering ............................................... 6-19Security Architecture Details......................................................... 6-23

Authentication Options..........................................................6-24Access Control Options..........................................................6-25Encryption Options.................................................................6-25

Signed Classes ................................................................................. 6-27JDK 1.2 Security.......................................................................6-27Protection Domains ................................................................6-27Signed Servlets ........................................................................6-28Digital Signatures....................................................................6-29Digital Certificates ..................................................................6-31

ixCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Message Digests ......................................................................6-32Security Versus Usability............................................................... 6-33Security Architecture...................................................................... 6-35Security Comparison: JDK 1.1 Versus JDK 1.2 ........................... 6-37Exercise: Evaluation of Security Architecture............................. 6-39



Designing an Architecture for Performance .........................................7-1Relevance............................................................................................ 7-2Objectives ........................................................................................... 7-3The Customer Application .............................................................. 7-4

Overview....................................................................................7-5Types of Users ...........................................................................7-6User Authentication..................................................................7-7Access Control ...........................................................................7-7Application Flow.......................................................................7-8

Analysis of Customer Architecture ................................................ 7-9Performance Analysis..................................................................... 7-10

Design Performance Factors..................................................7-10Architecture Performance Goals...........................................7-11Customer Application Performance Goals .........................7-12Perception and Reality ...........................................................7-12Prototyping ..............................................................................7-13

Architecture Performance Bottlenecks......................................... 7-14Java Technology Issues ..........................................................7-15Java Applet Environment Issues ..........................................7-18

Tier One Performance Issues......................................................... 7-19Applet Download Time .........................................................7-19Options to Improve Download Time...................................7-20Applet Execution Time...........................................................7-22Improving Applet Execution.................................................7-23Network Bandwidth Considerations ...................................7-25

Tier One Performance Rules.......................................................... 7-28Applet Performance................................................................7-28Internal Users...........................................................................7-29External Users..........................................................................7-31Mobile Employees...................................................................7-33

Tier Two Performance Issues ........................................................ 7-35Server Platform Performance ................................................7-36Server Load Balancing............................................................7-39Database Performance............................................................7-40Network....................................................................................7-41

Java Benchmarks ............................................................................. 7-42

x Java Technology Architecture Planning and DesignCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Java Application Performance Rules ........................................... 7-43Architecture Performance Rules................................................... 7-45

Designing .................................................................................7-45Tuning.......................................................................................7-47

Redesign of Customer Application for Performance................. 7-48Check Your Progress ...................................................................... 7-49Think Beyond .................................................................................. 7-50

The Java Technology Architecture in Production ...............................8-1Relevance............................................................................................ 8-2Objectives ........................................................................................... 8-3Application Development Architecture ........................................ 8-4Application Test Architecture ......................................................... 8-5

Testing All User Configurations .............................................8-5Test Configuration ....................................................................8-6Additional Testing ....................................................................8-7

Deployment Architecture Analysis................................................ 8-8Application Deployment Considerations...................................... 8-9

Production Services ................................................................8-12Mobile Users ............................................................................8-14

Network Computers....................................................................... 8-15Deployment Considerations for Enterprises .............................. 8-17

Applet and Application Distribution...................................8-17Rules for Applet Distribution................................................8-19Large Applications..................................................................8-20

Operational Issues........................................................................... 8-22Startup ......................................................................................8-22Troubleshooting ......................................................................8-23

Keeping Pace With Change ........................................................... 8-24Versioning ................................................................................8-24Reuse.........................................................................................8-25Maintenance.............................................................................8-26

Summary of Architecture Project Tasks ...................................... 8-27Architecture Checklist .................................................................... 8-29Check Your Progress ...................................................................... 8-30Think Beyond .................................................................................. 8-31

Case Studies ...............................................................................................A-1Module 2 Case Study....................................................................... A-2

Sample Questions to Ask The Customer..............................A-3DirectContact, Inc. ...................................................................A-4Constraints ................................................................................A-6

xiCopyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Module 3 Case Study....................................................................... A-8Instructions ...............................................................................A-8Dynaclaim, Inc..........................................................................A-9

Module 4 Case Study..................................................................... A-15Instructions .............................................................................A-15Plastic DeSign, Inc..................................................................A-17Requirements..........................................................................A-18Plastic DeSign, Inc. User Requirements..............................A-19

Module 6 Case Study..................................................................... A-21Instructions .............................................................................A-21UV Management Group........................................................A-22Application Requirements....................................................A-23Security Issues ........................................................................A-24

References................................................................................................... B-1Evolution of Java Technology ........................................................ B-2

JDK 1.0 ....................................................................................... B-2JDK 1.1 ....................................................................................... B-2JDK 1.2 ....................................................................................... B-3

Benefits of Java Technology............................................................ B-4Java Technology Packages.............................................................. B-5Summary of Java Technology APIs............................................... B-6Module 1 References........................................................................ B-7Module 2 References........................................................................ B-8Module 3 References........................................................................ B-9Module 4 References...................................................................... B-10Module 5 References...................................................................... B-12Module 6 References...................................................................... B-13Module 7 References...................................................................... B-14Module 8 References...................................................................... B-15

Glossary ......................................................................................... Glossary-1

xiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

AboutThisCourse

Course Goal

Java Technology Architecture Planning and Design provides you with the

knowledge base to create Java™ technology enterprise applications.

As the architect, you take the object model and define the

communication techniques that will be used between distributed

objects and between objects and nonobject-oriented applications and

data sources.

When you design an architecture, make sure the application is built for

scalability, flexibility, security and performance, and promotes and

takes advantage of object reuse.

Upon completion of this course, you should be able to advise

customers on the benefits of using Java technology and object-oriented

technologies, evaluate the suitability of a proposed Java application,

and build distributed object architectures to meet customer

requirements.

xiv Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Course Map

Each module begins with a course map that enables you to see what

you have accomplished and where you are going in reference to the

course goal. A complete map of this course is shown below.

Basic Principles

Java TechnologyArchitecture Details

Designing a JavaTechnology Architecture

Foundation

Introduction to the JavaTechnology Architecture Process

Advanced Principles

Creating New Application Architectures

Integration With ExistingApplications and Databases

Security and Performance Principles

Designing an Architecturefor Performance

Designing a Secure JavaTechnology Architecture

Deployment

The Java Technology Architecture in Production

About This Course xvCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Module-by-Module Overview

● Module 1 – Introduction to the Java Technology Architecture

Process

This module explains the role of a person who creates Java

technology architectures with respect to the application

development process. This role is compared to the roles of people

who write Java technology programs or develop Java applications.

● Module 2 – Designing a Java Technology Architecture

This module uses a case study to introduce the basic concepts of

Java technology architecture.

● Module 3 – Java Technology Architecture Details

This module delves into the Java technology three-tier

architecture, and looks at the decisions and trade-offs that need to

be made for each of the tiers. Case studies are used to explain the

various architectural details.

xvi Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1


● Module 4 – Integration With Existing Applications and Databases

This module focuses on the third tier of the Java technology

architecture, and how a Java application can be seamlessly

integrated into this tier.

● Module 5 – Creating New Application Architectures

This module looks at the options for building new Java application

architectures.

● Module 6 – Designing a Secure Java Technology Architecture

Many Java technology solutions incorporate a public network such

as the Internet. This module looks at how security is incorporated

into the Java application architecture.

● Module 7 – Designing an Architecture for Performance

This module discusses the performance implications of a Java

technology architecture.

About This Course xviiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1


● Module 8 – The Java Technology Architecture in Production

This module looks at architectural design decisions that might

affect the implementation of a Java technology solution.

● Appendix A – References

This appendix contains reference information and Web site

information that is not directly relevant to the course material but

may be useful to students.

● Appendix B – Case Studies

This appendix contains case study exercises and detailed

instructions for students to work on those case studies.

xviii Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Course Objectives

Upon completion of this course, you should be able to:

● Describe the role of an architect of Java technology

● State the advantages of a distributed object architecture

● Advise on how to use Java technology to maximize business

benefits

● State the major architectural issues and trade-offs faced when

designing enterprise Java technology solutions

● Evaluate the advantages and disadvantages of using Java

technology for enterprise applications (including cost, reusability,

performance, and manageability)

● Design a multi-tier Java technology architecture that meets

customer requirements

● Compare a Java technology object-oriented architecture with

common object request broker architecture (CORBA) and

distributed component object model (DCOM) alternatives and

discuss the pros and cons of each architecture for a set of customer

requirements

● Design a Java technology architecture that integrates with existing

systems

● Design a Java technology architecture for a new, enterprise-wide

application

● Evaluate the performance and security of a proposed Java

technology architecture

● Integrate security constraints into a Java application architecture

● Recommend techniques for effectively deploying and distributing

Java technology solutions in production

● Given a Java technology prototype or pilot application, advise on

how it can be effectively moved to production status

About This Course xixCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Skills Gained by Module

The skills for Java Technology Architecture Planning and Design are

shown in the first column of the matrix below. The black boxes

indicate the main coverage for a topic; the gray boxes indicate the

topic is briefly discussed.

Module

Skills Gained 1 2 3 4 5 6 7 8

Describe the role of an architect of Java technology

State the advantages of a distributed object architecture

Advise on how to use Java technology to maximize business benefits

State the major architectural issues and trade-offs faced whendesigning enterprise Java technology solutions

Evaluate the advantages and disadvantages of using Java technologyfor enterprise applications (including cost, reusability, performance,and manageability)

Design a multi-tier Java technology architecture that meets customerrequirements

Compare a Java technology object-oriented architecture withCORBA and DCOM alternatives and discuss the pros and cons ofeach architecture for a set of customer requirements

Design a Java technology architecture that integrates with existingsystems

Design a Java technology architecture for a new, enterpriseapplication

Evaluate the performance and security of a proposed Java technologyarchitecture

Integrate security constraints into a Java application architecture

Recommend techniques for effectively deploying and distributingJava technology solutions in production

Given a Java technology prototype or pilot application, advise onhow it can be effectively moved to production status

xx Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Guidelines for Module Pacing

The table below provides a rough estimate of pacing for this course.

Module Day 1 Day 2 Day 3 Day 4

About This Course A.M.

Module 1 – Introduction to the JavaTechnology Architecture Process

A.M.

Module 2 – Designing a Java TechnologyArchitecture

P.M.

Module 3 – Java Technology ArchitectureDetails

A.M./P.M.

Module 4 – Integration With ExistingApplications and Databases

P.M. A.M.

Module 5 – Creating New ApplicationArchitectures

A.M/P. M.

Module 6 – Designing a Secure JavaTechnology Architecture

P.M. A.M.

Module 7 – Designing an Architecture forPerformance

A.M.

Module 8 – The Java TechnologyArchitecture in Production

P.M.

About This Course xxiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Topics Not Covered

This course does not cover the topics shown on the above overhead.

Many of the topics listed on the overhead are covered in other courses

offered by Sun Educational Services:

● Object-oriented analysis and design – Covered in OO-225: Object-Oriented Design and Analysis with OMT/UML and OO-226: JavaAnalysis and Design Using UML.

● Java technology programming – Covered in SL-275: JavaProgramming

● Java technology distributed programming concepts and

application programming interfaces (APIs) – Covered in SL-301:

Distributed Programming with Java

Refer to the Sun Educational Services catalog for specific information

and registration.

xxii Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

How Prepared Are You?

To be sure you are prepared to take this course, can you answer yes to

the following?

● Explain basic object-oriented terms and concepts

● Describe the client-server architecture

● Explain the unique features of the Java programming language

and environment

● Compare the Java programming language to other programming

languages

● Describe the runtime environment for Java technology

● Explain what an API is

About This Course xxiiiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

How Prepared Are You?

● List the common Java technology APIs and briefly describe the

purpose of each

● Describe the difference between an applet and an application

● Explain the basic Java technology security model

xxiv Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Introductions

Now that you have been introduced to the course, introduce yourself

to each other and the instructor, addressing the items shown on the

above overhead.

About This Course xxvCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

How to Use Course Materials

To enable you to succeed in this course, these course materials employ

a learning model that is composed of the following components:

● Course map – Each module starts with an overview of the content

so you can see how the module fits into your overall course goal.

● Relevance – The relevance section at the start of each module

provides scenarios or questions that introduce you to the

information contained in the module and provoke you to think

about Java technology architectural issues.

● Lecture – The instructor will present information specific to the

topic of the module. This information will help you learn the

knowledge and skills necessary to complete the case studies.

● Case studies– Case study exercises will give you the opportunity

to apply the concepts presented in the lecture.

● Overhead image – Reduced overhead images for the course are

included in the course materials to help you easily follow where

the instructor is at any point in time. Overheads do not appear on

every page.

xxvi Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

How to Use Course Materials

● Check your progress – Module objectives are restated, sometimes

in question format, so that before moving on to the next module

you are sure that you can accomplish the objectives of the current

module.

● Think beyond – Thought-provoking questions are posed to help

you apply the content of the module or predict the content in the

next module.

About This Course xxviiCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Course Icons and Typographical Conventions

The following icons and typographical conventions are used in this

course to represent various training elements and alternative learning

resources.

Icons

Additional resources – Indicates additional reference materials are

available.

Discussion – Indicates a small-group or class discussion on the current

topic is recommended at this time.

Note – Additional important, reinforcing, interesting or special

information.

xxviii Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Course Icons and Typographical Conventions

Typographical Conventions

Courier is used for the names of command, files, and directories, as

well as on-screen computer output. For example:

Use ls -al to list all files.

system% You have mail.

Courier bold is used for characters and numbers that you type. For

example:

system% suPassword:

Courier italic is used for variables and command-line

placeholders that are replaced with a real name or value. For example:

To delete a file, type rm filename .

Palatino italics is used for book titles, new words or terms, or words

that are emphasized. For example:

Read Chapter 6 in User’s Guide.

These are called class options.

You must be root to do this.

1-1Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Introduction to the JavaTechnologyArchitectureProcess 1

Course Map

This module explains the architecture process with respect to the

application development process and compares it to the roles of those

who write Java technology programs and develop Java applications.

Basic Principles



Foundation


Advanced Principles






Deployment


1

1-2 Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Relevance

Discussion – As an architect of Java applications, you must have a

wide range of skills and experience beyond Java programming

language skills. Consider the following questions:

● How can I use Java technology with my current environment?

● Where do these Java technologies fit in with my current

environment?

● Why should I use Java technology on my server?

● Why should I use remote method invocation (RMI) instead of

CORBA? Isn’t CORBA an open standard?

● Can I use Active X clients with Java technology?

● If I use Java technology, will there be issues between the various

Java Development Kit (JDK™) versions?

● What is an object request broker (ORB) and where does it reside?

● How will an ORB work with my customer information control

system (CICS) system?

● Can I use CORBA clients with Java technology?

● Should I sign my own Java technology applets or go through a

Certification Authority?

● What tools are there for managing Java technology applets and

server applications?

● Will Java technology overload my network?

● Should my company convert from Smalltalk to Java technology?

● How can I find out how much memory a Java application or

applet requires at runtime?

1

Introduction to the Java Technology Architecture Process 1-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives

Upon completion of this module, you should be able to:

● Describe the duties performed by an architect of Java technology

● State how a Java technology architectural design fits into an

application development life cycle

● State the advantages of using a distributed object architecture

implementation

● Explain the advantages of using the Java programming language

instead of an alternative language such as C++

● Explain how an object-oriented architecture can solve business

problems

References

Additional resources – The following references can provide

additional details on the topics discussed in this module:

● Bass, Clements, and Kazman. 1998. Software Architecture. Addison-

Wesley.

● Rumbaugh, James et al. 1991. Object-Oriented Modeling and Design.Prentice Hall.

● Frank Buschmann et al. 1996. Pattern Oriented Software Architecture:A System of Patterns. Wiley.

● Blaha, Michael. Object-Oriented Modeling and Design for DatabaseApplications. Prentice Hall.

● Fowler, Martin. 1997. UML Distilled Addison-Wesley.

● Harmon and Watson. 1998. Understanding UML: the DevelopersGuide (With a Web-based Application in Java). Morgan.

● Appendix B, ‘‘References.”

1


What Does an Architect Do?

An architect of Java applications is involved at some level in all stages

of the Java application design and development process (Figure 1-1).

The architect is primarily responsible for defining the ways that

distributed Java software components will interact with each other

and with components and modules that do not support Java

technology.

The architect may be called on to advise customer management (at a

high level), or to work on-site at a customer location (at a technical

level). Decisions made by the architect can have a far-reaching effect

and impact customer organizations.

Figure 1-1 Various Architectures

Overall system architecture

Networkarchitecture

Javatechnologyarchitecture

Dataarchitecture

Securityarchitecture

1



Tasks

The architect needs to have business knowledge as well as computer

architecture experience and Java technology industry knowledge, to:

● Advise management on the use of Java technology for maximizing

business benefits

● Demonstrate Java technology expertise to the customer

● Develop a detailed set of application requirements from a high-

level list, and obtain customer agreement upon success criteria.

● Evaluate Java technology applicability for a given customer

against other object languages, or the hypertext markup language

(HTML) and common gateway interface (CGI) scripts

● Evaluate the advantages and disadvantages of using Java

technology for an enterprise application (including cost, security,

reusability, performance, and manageability considerations)

1



Tasks (Continued)

● Recommend third-party Java and object-oriented technologies and

products that can meet the customer’s requirements

● Develop project plans and design documents for customers

● Train and mentor customers on Java technology architecture, and

Java technology design principles and interfaces

● Analyze customer-proposed application designs and architectures

● For a given set of business requirements, design a distributed

object architecture using Java technology

● Act as part of a team, which may include the customer, that

designs, develops, and implements enterprise-wide Java

technology solutions

● Defend the integrity of the architecture over the project’s lifecycle

1



Optional Tasks

The following are not part of the core architect tasks, but may be

requested by the customer:

● Determine if this is a programming or a business problem

● Drive the analysis and design phases of application development

● Develop pilot applications for proof of concept

● Discuss and suggest improvements to the customer’s processes

1



Java Technology Architecture Goals

An architect of Java technology applications should additionally seek

an appropriate balance between these features of the architecture:

● Application performance and throughput

● Use of component design

● Adherence to company security policy

● Compatibility with the existing systems, network, and data

architectures

● Object reuse

1



Constraining Factors

The architecture may be constrained and influenced by many factors,

including

● Resources, including budget, time, and customer expertise

● Existing systems, data, infrastructure, interfaces, and build/buy

choices

● Network bandwidth and performance

● Human/machine Interface

● Standards

● Security needs

1


System Architecture in Perspective

Overview

“The software architecture of a program or computing system is the

structure or structures of the system, which comprise software

components, the externally visible properties of those components,

and the relationships among them.” (Bass, Len; Clements, Paul; and

Kazman, Rick. 1998. Software Architecture in Practice. Addison-Wesley.)

Figure 1-2 shows the flow of an object-oriented development project.

Note that this is an iterative process, which may take several iterations

to achieve. If the application is large and complex, it may be broken

into viable chunks which can be prototyped in isolation.

The architecture phase of an application usually follows the business

analysis, and precedes the actual programming phase. With the case of

Java technology, which does not require any particular design process,

the analysis and design may be done using an object-oriented notation

such as object modeling technique (OMT), which defines processes, or

its successor unified modeling language (UML), which does not define

processes, only a notation.

1



An Example Process

Figure 1-2 Object-Oriented Deployment Project

Deploymentenvironments

Process Constraints

Deploy

Businessconstraints

Problem domainuse case diagrams

Unknown businessrequirements

Classdiagrams

Environmentaland technology

constraints

Reusabilitybuild or buy

State, Process,Interaction, and

Sequence diagrams

Build or buy toolsLanguage choice

Object classesReuse library

UML package designOMT subsystem designDeployment diagrams

Business processreengineering

Deploymentenvironments

Documentation

Productionqualitycode

Testingenvironmentsimulation

Business operations,costs, and

competitiveness

New workflowopportunities

Architecturedesign

Object-orientedanalysis

Object-orienteddesign

Generate Javasoftware classes

Test

Requirementsanalysis

Outputs

1



Process Steps

Java applications development, like all object-oriented development,

benefits most from an iterative development process.

Note – Companies do not have to follow these steps rigidly (some

companies may go directly from the requirements step to the

architecture step). However, the maximum benefits from object

technology are obtained when a methodology is used throughout the

entire application development life-cycle.

The steps taken in the architecture process are

1. Create a business requirements/problem statement. The

architect’s involvement varies at this stage (it may be minimal if

the customer has a formal business process, or may be heavy if

the architect is also the designer).

1


The Architecture Process in Perspective

Process Steps (Continued)

2. Conduct an object-oriented analysis. The architect should be

involved at this stage (however, the customer may actually do

the analysis). The architect should ensure the class diagram

correctly models the business requirements.

3. Reuse analysis. Ideally, the architect will have reuse in mind at all

times during the design process, but this is particularly relevant

during the main analysis phase.

4. Develop an architecture. The architecture is the blueprint for

building the application and defines the distribution of the object

classes on different computers, and the protocols and

middleware for connecting and integrating with existing or non-

object systems. The architecture may be affected by the locations

of the end users, and the pre-existing architectures of legacy

systems.

1


The Architecture Process in Perspective

Process Steps (Continued)

5. Create an object-oriented design. The architect should be

involved at this stage, as an advisor (though this is customer

dependent). The architect may advise customer designers on

object reuse, inheritance decisions, and “buy versus build”

decisions about object classes.

6. Code, test, and implement the application. The architect is

typically not involved here, except as a project coordinator or

advisor.

7. Deploy the application or the prototype. The architect is typically

not involved here, except as a project coordinator or advisor.

Note that the deployment architecture may differ from the design

architecture.

Note – Architectural design patterns are useful architectural models

for common application requirements, such as user interface design,

and component architectures. The architect can develop new patterns,

reference common patterns, or use industry-specific patterns.

1


Why Is an Architecture Needed?

Attempting to go from business requirements directly to the coding

stage will produce an unworkable and unmaintainable system. This is

why architecture is so important. A well-planned architecture can

anticipate potential application troublespots and ensure the success of

the application in production.

The application should provide

● Robustness, against incorrect input, and against new requirements

● Scalability

● Portability

● Good performance

1


Why Is an Architecture Needed?

● Integration with existing systems and data

● Appropriate use of new technology

● Appropriate use of protocols, middleware, and standards

Successfully architected applications can be distributed and sold to

customers, partners, and others in different environments.

The importance of good architecture cannot be overstressed—the

architecture affects the scalability, flexibility, robustness, performance,

security, and cost of the application in production.

Note – The architect’s success is measured by these factors.

The architectural documentation should assist in use and extension of

the classes. It should also provide some insight into class internals.

1


Architecture Diagrams

There is no standard notation for drawing an architecture. The

architect may wish to use UML notation as follows:

● Class diagrams are used when talking to customer analysts.

● UML package diagrams are used to describe the architecture to the

customer. Packages are advantageous for designing architectures,

since they allow for the isolation of parts of the application which

can then be developed independently. This also promotes

flexibility, since a package can be exchanged for a different

package if necessary.

● Dependency diagrams are used to show the dependencies

between packages.

● UML deployment diagrams are used to show how the architecture

is divided into tiers.

1


Architecture Notation

Other UML diagrams, such as sequence diagrams and collaboration

diagrams, can also be used (Figure 1-3). These include

Figure 1-3 UML Notations Used in Architecture Drawings

● Packages that represent logical software modules (groups of

classes). Links between packages are indicated with arrows.

Packages can be stacked within other packages.

● Components that show classes and how they interact. Class

diagrams can show subclasses, instances, and associations.

Instances are prefixed with a colon (:) and underlined. Active

objects are shown within the instance. Dependencies are indicated

with lines.

● Nodes that indicate deployment tiers, such as clients, servers, and

so forth. Packages can be shown within nodes.

Package

Component

Node

:Instance:Instance

1


Basic Three-Tier Architecture

This course focuses on the impact of Java technology on application

architectures. However, you should understand the basic architectural

concepts of layering and tiering.

The three-tier (or greater) architecture breaks an application into

discreet functions (presentation, business logic, and data access logic).

These functions are known as tiers.

Tiers are logical, and may be implemented on physically separate

servers. Provided the tiers have been well thought out and created, the

tiers can be moved to different physical servers, or an extra tier can be

inserted without requiring any changes to the application code.

Business rules can be changed without affecting the other tiers.

Figure 1-4 Three-Tier Architecture

Application architecture

Tier 1 Tier 2 Tier 3

Presentation tier

API

TCP layer

IP layer

Network

Business logic tier

API

TCP layer

IP layer

Network

Data access tier

API

TCP layer

IP layer

Network

TCP = Transmission Control ProtocolIP = Internet Protocol

1


Basic Three-Tier Architecture

The prime architectural focus is the mapping of a business function or

system service to a tier. Tiers allow the application to be separated out

onto different hardware platforms.

Though each tier can be run on separate physical hardware, the

architecture is independent, allowing for different distribution models of

the architecture. For instance, multiple tiers may be implemented to run

on the same hardware platform or on separate platforms, and

additional tiers can be inserted for scalability and flexibility.

1


Tier-to-Tier Communication

Protocols

Application tiers communicate across a network and relay data to one

another using communication protocols such as:

● Sockets

● Remote procedure calls (RPCs)

● Messaging

API Constraints

Applications use APIs to access these communication protocols. In a

two-tier client-server architecture, structured query language (SQL)

calls to a database are passed from client to server using one of the

listed mechanisms. In many cases, the API and protocol libraries are

provided by the database vendor or fourth generation language (4GL)

tool vendor, so the choice is dictated by the vendor.

1


Tier-to-Tier Communication

Sockets

Sockets are used for sending and receiving streams of data bi-

directionally between two applications.

Figure 1-5 Tier-to-Tier Communication Using Sockets

Serversocket

Linkedlibraries

Dataaccesslogic

ApplicationGUIlogic

Database tierServer tierClient tier

Transportlayer

Serversocket

Applicationbusiness logic

Clientsocket

Serversocket

Transportlayer

Clientsocket

Transportlayer

GUI = graphical user interface

1


Tier-to-Tier Communication Protocols

Remote Procedure Calls

Remote procedure calls (RPCs) are used for calling a remote application.

Messaging

Messaging protocols are used for sending data as messages between

two applications. Data is placed on a queue by the sending tier and

retrieved from the queue by the recipient tier.

Note – Other communication protocols, such as IBM APPC, and

middleware, such as transaction monitors, will be discussed in later

modules.

1


Distributed Object Communication

Socket calls and RPCs are not object-oriented by design (Figure 1-6):

Figure 1-6 Distributed Object Architectures, Sockets, and RPCs

Socket calls are the most basic form of communication, and require

both sides to agree on the format of data to be exchanged. The

programmer is responsible for encoding and decoding the data

between the different machine architectures.

RPCs provide more abstraction than sockets. The programmer uses

standard procedural programming calls to call a remote program.The

programmer does not have to encode the data (the RPC does the

encoding using some form of external data representation). However,

RPCs may be proprietary to a vendor system and are not guaranteed

to fully interoperate with another vendor RPC.

Remote MethodInvocation (RMI)

Object may receivearguments ofpreviously unknowntypes; classes maybe loaded as needed.

Object call to methodon another object.Parameters andreturn values areobjects.

Internet Inter-ORBprotocol (IIOP)

Object must receivearguments of knowntypes. Methods mustbe preinstalled onserver.

Object call to methodon another object.Parameters andreturn values arestructures.

RPC

Data and executionrequests transferredbetween client andserver. Procedurespreloaded on server.

Procedure call toanother program.Parameters andreturn values arestructures.

Socket

Only data istransferred betweenclient and server.Interpretationmustbeexplicitly coded.

Socket call transfersbyte stream databetween twoprograms.

1


Distributed Object Communication

Object-to-object communication is the highest level of abstraction,

allowing for applications to be designed, developed and distributed in

a way that parallels business operations.

● An object can invoke methods on a remote object in the same way

that it invokes methods on local objects.

● With a distributed object-oriented application, the objects that

make up the application can be split up and run on multiple tiers

throughout a network on computers that best fit the task of each

object without having to change the rest of the application using

these objects. For example, an object that performs intense

computations, such as three-dimensional renderings, might be

placed on a more powerful computer, rather than on an average

desktop computer.

● Neither programmers nor users should be concerned about where

a specific object resides. The architect determines the deployment

location. Objects can be easily moved about, as the needs of the

business dictate. Objects can also be migrated to new platforms

without program changes.

1


Advantages of Distributed Object Architectures

Discussion – What is the advantage of having objects at each tier?

1


Distributed Object Frameworks

Distributed object frameworks allow distributed objects to

communicate across networks. The framework supplies the

infrastructure (APIs and network protocols), allowing the programmer

to focus on the business logic. Examples of such frameworks are:

● JavaSoft™’s Remote Method Invocation (RMI)

● The Object Management Group’s Common Object Request Broker

Architecture (CORBA)

● Microsoft’s Distributed interNet Application Architecture (DNA)

which contains the Component Object model (COM) and the

Distributed Component Object model (DCOM)

Note – RMI, CORBA, and DNA are usually implemented on top of APIs

such as RPCs or sockets.

1


Object Languages

Some popular object-oriented (OO) programming languages are Java,

C++, and Smalltalk. Table 1-1 gives a comparison of these languages.

Table 1-1 Comparison of Object Languages

Java C++ Smalltalk

Objected-Oriented Pure OO Not pure OO Pure OO

Maturity Young Mature Mature

Popularity Growing rapidly in use Widely in use Slow growth rate

StandardImplementation

Implementations mayvary by vendor(standard is maintainedby Java technologylicensing)

Implementationsvary across vendors

Implementationsmay vary acrossvendors

Reusable Yes Hard to obtain reuse Yes

Web Support Yes None None

1


PlatformDependence

Cross-platform virtualmachine (manyimplementations)

Platform dependent Cross-platformvirtual machine(fewimplementations)

Security Provides security forInternet (sandbox)

No built-in securityfor Internet

No built-insecurity forInternet

API Use Java technology API setenhances usability ofJava technology

Lack of enterpriseAPIs

Lack of enterpriseAPIs

Cost Sun’s JDK is free. Somedevelopment systemsare chargeable

GNU is Not UNIX(GNU) compilersare free, otherwisethere may be a smallcost for the compiler

Cost issue forSmalltalkenvironment

Features Safe language (nopointer manipulation)and garbage collection

Pointers andmemory leaks

Garbagecollection

Table 1-1 Comparison of Object Languages (Continued)

Java C++ Smalltalk

1


Basic Three-Tier Java Technology Architecture

Overview

The typical three-tier architecture for a Java application is shown in

Figure 1-7.

Figure 1-7 Basic Three-Tier Java Technology Architecture

Tier one Tier threeTier two

• User interface

• Input validation

• Data input

• Localcalculations

• Business logic

• Business rules

• Client sessionmanagement

• Database connection

• Remote objectaccess

• Legacyapplicationand dataaccess logic

• Databaseserver logic

• Web browser withoptional Javaapplet

• Java application

• Web (HTTP) server

• Java application or servlet

• Non-Java application

• Middleware such astransaction monitors

• Protocol converters

• Terminal emulators

• Databaseproducts

• Legacy productsand applications

• Transactionprocessingsystems

Logical application view

HTTP = Hypertext transfer protocol

1



Overview (Continued)

As shown in Figure 1-7, tier one (the client tier) provides the graphical

user interface (GUI), forms for data entry, and local validation of data.

Computations can be performed at this stage (for example,

summarizing or totaling a list of items entered on an order, sorting

data). The client tier can be implemented as a Java applet that is

downloaded to the client and runs within a Web browser, or as a Web

browser form. The client tier does not connect directly to a database

back end.

Tier two consists of an “application server.” The application server

handles connections from client applications, performs most of the

business logic, and interfaces to databases and applications at tier

three. The application server can be written in the Java programming

language or in a traditional language such as C or C++. This tier can

additionally provide the following services to the client tier:

● Remote object access (CORBA, Java technology RMI)

● Database connectivity, access, and update

● Processing of transactions

● Load balancing

● Protocol conversions (for example, IBM 3270 to HTML)

● Terminal emulation (for example, IBM TN3270)

● Security services (proxy servers and access control)

● Email services

● File services

● Print services

1




The Web server, though not strictly part of the application architecture,

is used to download applets to the client platform, as well as respond

to Web uniform resource locator (URL) requests from tier one.

Tier three consists of the database server and physical database store,

or legacy applications and legacy data stores. Application logic can be

embedded here as triggers and stored procedures in the database. Tier

three can be physically implemented on the same server as tier two, or

can be implemented on one or more back-end servers.

Note – The architecture can have more than three tiers. This will be

discussed later.

The architect defines the logical application tiers and how they

communicate, and how they can be implemented on physical

platforms:

● Tier two provides the opportunity for scalability in a Java


● The architect should design tier two for scalability, so that it can be

scaled up as the number of tier one clients increases. For example,

a second application server can be added without affecting either

tier one or tier three.

1



Applets, Applications, and Servlets

Java applets are invoked by the HTML <applet> tag and downloaded

to the client from a Web hypertext transfer protocol (HTTP) server.

Applets have to conform to certain security restrictions if they are not

signed.

Java applications are not subject to the security restrictions of applets.

Applications do not need a Web browser, and must be pre-loaded onto

the client or server platform (they are not automatically downloaded).

Servlets reside on the Web server and perform the same functionality

as applications, except that they are invoked by the Web server.

1


Advantages of Three-Tier Architectures

Discussion – What are some of the advantages of a three-tier

architecture over a two-tier architecture?

1


Notes

1


Comparison of Three-Tier Communication Mechanisms

Application tiers communicate using a wide range of protocols. As

shown in Table 1-2, these include asynchronous message queuing,

RPCs, and sockets (the most common).

Object-oriented applications use object-oriented interfaces layered on

top of these protocols. The architect needs to select the appropriate

type of underlying protocol to best serve the application requirements.

Table 1-2 compares the various protocols using the following

definitions:

● Asynchronous communication enables the calling object to

continue processing.

● Synchronous communication blocks the calling object from

processing until the called object completes.

● Conversational communication gives the calling object the option

to continue processing or wait for a response. Conversational

communication is sometimes referred to as peer-to-peer.

1


Comparison of Three-Tier Communication Mechanisms

Table 1-2 Three-Tier Communication Mechanisms

Asynchronous SynchronousConversational/Peer-to-Peer

ApplicationCharacteristics

Loosely coupledapplication design.No wait time.

Tightly coupledapplication design.Wait time forremote procedureto execute.

Tightly coupledapplicationdesign.No wait time.

NetworkCharacteristics

Can work indisconnect mode.Network does nothave to beavailable.

Network must beavailable.

Network must beavailable.

ApplicationLatency

Performance notaffected bynetwork speed.

Performs best onhigh-speed localarea network(LAN).

Performance notaffected bynetwork speed.

ApplicationModel

Suitspublish/subscribemodel.Better for high-performancemainframe access.

Suits transactionprocessing.

Suits datatransfer.

Example Message queuingIBM MQSeries.

Remote procedurecall.

Socket callIBM LU6.2.

1


Synchronous and Asynchronous Architectures

A well designed Java technology architecture should be independent

of the actual communication mechanism. However, the architect

should still decide early on which parts of the application must be

synchronous, and which parts can take advantage of messaging.

● Synchronous applications make more demands on the application

development, and on the eventual deployment. The architecture

must be robust and fail-safe, and cope with error situations such as

the network or remote server being unavailable. The deployment

configuration must provide for the level of reliability with

redundant network and server components.

● Asynchronous applications can use the features provided by

messaging products for reliability, so there are fewer demands on

the development.

1


Notes

1


Overall Java Technology Architecture

Defining a Java technology architecture is no different than designing

a multi-tiered client-server application; however, there are

considerations due to the use of object technology, the Internet, the

Web, and the use of the Java programming language (Figure 1-8).

Figure 1-8 Overall Java Technology Architecture

The simplest Java technology architecture adds the following

components and services to the application architecture:

● Tier one

▼ Java Virtual Machine (JVM) or Web browser that supports Java

technology

▼ HTML pages or Java technology applets that are downloaded

from the tier two Web server

▼ Network interface to tier two transmission control

protocol/Internet protocol (TCP/IP) or TCP/IP over point-to-

point protocol (PPP)

▼ Communication protocols to tier two

Client

Service network

Machine

RDBMS

MainframeCICSIMS

MachineMachineMachine

ClientClient Client

JVM+Java application

Web browser+Java applet

Web browser+HTML

EmbeddedJVM

RDBMS = Relational database management systemIMS = Information management system

1


Overall Java Technology Architecture

● Tier two

▼ Web server for downloading applets and HTML pages

▼ Application server (purchased or developed business logic)

▼ Security services (authentication, for example)

▼ General services (print, email, file, directory, and so forth)

▼ Middleware to tier three (ORBs, transaction monitors, and so

forth)

▼ Communications protocols to tier three

1


Java Technology Architecture Issues

Discussion – Take a few minutes to discuss some typical issues and

considerations that an architect must deal with. For example:

● Java technology environmental and infrastructure issues

● Object reusability

● Designing the various application tiers and splitting logic among

the tiers

● Placement and mapping of the tiers onto physical servers

● Specifying the protocols between the tiers (object or non-object)

● Performance implications for the architecture

● Network implications for the architecture (LAN, wide area

network [WAN], Internet, private network)

● Designing an architecture for scalability and flexibility (so that

objects can be moved easily in deployment)

● Designing an architecture for security

● Designing an architecture for portability

1


Check Your Progress

Before continuing on to the next module, check that you are able to

accomplish or answer the following:

❑ Describe the duties performed by an architect of Java technology

❑ State how a Java technology architectural design fits into an

application development life cycle

❑ State the advantages of using a distributed object architecture

implementation

❑ Explain the advantages of using the Java programming language

instead of an alternative language such as C++

❑ Explain how an object-oriented architecture can solve business

problems

1


Think Beyond

How do you approach designing an architecture based on Java

technology?


Designinga JavaTechnologyArchitecture 2

Course Map

This module uses a case study to introduce the basic concepts of Java


Basic Principles



Foundation


Advanced Principles






Deployment


2


Relevance

Discussion – You have been presented with a set of requirements

from a customer for a business application. The customer is interested

in hearing if the Java technology model is applicable and how Java

technology can be used to increase the business benefits of the

application. The customer is not currently using Java technology.

You are scheduled for a one-hour, informal meeting with the

customer’s project manager, technical architect and lead programmer.

At this meeting you should be prepared to draft a high-level

architecture for this application using Java technology, and explain

how it can benefit their business.

● Do you have enough information from the customer? What

additional questions might you ask the customer? What additional

information might you need from the customer (for instance, data

models or entity-relationship diagrams)?

● What do you need to know about the customer’s business and his

or her information technology (IT) environment?

● How can you assess how Java technology will benefit the

customer?

● How do you create a Java application?

2

Designing a Java Technology Architecture 2-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Evaluate the applicability of a Java technology solution for a given

customer application requirement

● Design a basic three-tier architecture for a set of customer

requirements

● Explain the advantages of using Java technology RMI for a given

customer architecture

● State the major architectural issues and trade-offs faced when

designing a distributed Java technology solution

● Discuss the advantages of servlets rather than common gateway

interface (CGI) scripts

● List common communication protocols used in a three-tier Java


References



● Berg, Daniel J. and Fritzinger, Steven. Advanced Techniques for JavaDevelopers. Wiley. 1998.


2


Customer ApplicationApplication Description

Expense Collection and Reimbursement System (ECARS) is an existing

application for employee submission of business expenses requests

and reports on-line. It is a two-tier client-server application—the

workflow is illustrated in Figure 2-1.

Figure 2-1 ECARS Application Workflow

Expenserequest

Expense report

Requestapproval

Approval code

Email

Database

Email

Email

Audit checksExpensepayment

Expenseapproval

Employee

Manager

2


Customer Application

Application Description (Continued)

● Tier one consists of a client application written in 4GL (which

generates C code) that provides a form for employees to fill out

(the on-line form is a direct copy of the paper form that was

previously used to fill out expenses). Employees fill out this form,

the application does some local checking (such as computing

totals), and formats the form into a database update request.

Managers use the same interface for approving or denying

requests or reports. Employees use a mix of Windows 95,

Windows NT, and Macintosh computers over a TCP/IP LAN.

● Tier two consists of a Windows NT server application which

handles the requests from the clients, saves the expense

information in a Sybase relational database, and submits email

notification to the expense approvers. When an expense request is

approved, the employee receives an emailed expense

authorization code. This code is required to enter an expense

report.

2



Customer Requirements

This system has been very successful in saving the costs associated

with processing business expenses. There is no longer any need to give

cash advances to employees since expenses can be turned around

within two days of submission. The company saves approximately $25

in paper costs and filing costs for each expense request.

There are currently 200 users on the system, in one campus location.

Now the company wants to expand the system worldwide, so that

they can obtain more savings.

● The company is aware that the current two-tier system will not

scale to support the 20,000 worldwide users.

● The application maintenance overhead will worsen as more clients

are brought onto the system.

● Each country needs to have native language support.

2



Customer Requirements

● There are also some local expense handling practices in Japan and

Germany that must be added to the system. These cover the way

employees are reimbursed (in some countries they are paid by

check and in other countries the checks are directly deposited in

the employee’s bank account).

● Managers cannot use the current system to approve expenses for

employees who work in different regions or in other countries.

Managers who themselves are remote cannot use the system to

approve expenses of campus-based employees.

● There are different expense policies that apply in different

countries. For instance, the daily rate for a hotel in London and

Tokyo is higher than the daily rate for other places. Employees fall

under the local expense policy, regardless of where they normally

work.

2


Architecture Analysis

Customer Appraisal

When preparing the appraisal, determine:

● What the prime issue is for this customer

● If you have enough information from the customer

● What additional questions you should ask the customer

● How you create a Java application

2



Customer Appraisal (Continued)

● What additional documentation might you need from the

customer (for instance, data models and entity-relationship

diagrams). The entity-relationship model of the database can help

you design your application object-oriented model. Database

entities correlate very strongly to object entities.

● What the customer’s business and IT environment are.

● How Java technology can meet the customer’s requirements For

this customer, is there an advantage from “software on demand,”

simplified client maintenance, and the ability to deploy anywhere.

2



Java Technology Architecture Assessment

What advantages will the three-tier Java technology architectureprovide this customer?

● Scalability. The current two-tier architecture requires that the

database server in the second tier manage direct connections to

each running client. This approach cannot scale up to enterprise-

wide use because of inherent limits on the number of server

connections. A three-tiered architecture increases scalability

because the second tier can multiplex multiple first-tier clients

through a single database connection to the third tier.

● Flexibility. Tier-two processing can be distributed onto multiple

platforms for workload balancing. These platforms can be placed

in regional or country locations.

2



Java Technology Architecture Assessment (Continued)

● Database independence. The Sybase database can be changed or

upgraded without affecting other objects.

● Performance. Adding a second server distributes the tier two

processing load across multiple physical servers.

● Reliability. The middle tier can be replicated for reliability (hot

standby). The Java programming language tends to produce more

reliable systems than those written in languages like C and C++.

● Reduced client administration. If other client applications need to

access multiple databases, there might have to be multiple

networking database drivers (for example, Open Database

Connectivity [ODBC] database drivers) installed on the client

platform. In a three-tier environment, this middleware can be

concentrated on the middle tier.

● Internet support. The three-tier model is better suited to the Internet

since the amount of data sent to the client over the network can be

reduced to a manageable amount by the middle-tier.

Right now, the use of the Internet is not a requirement for this

application. But do not discount the Internet. This is a worldwide

company with users who travel and dial in to the company’s

WAN. The company could probably achieve significant savings in

telephone leased line costs if they shifted their remote access to the

Internet.

Note – The customer will need to purchase a platform for running the

additional tier (running tiers two and three on the same server would

offer no benefits in terms of performance or scalability).

2



Conversion to a Three-Tier Architecture

When you are planning a conversion from a two-tier architecture to a

three-tier one, ask yourself the following questions:

● What are the drawbacks of a three-tier architecture for this

application?

● Can the application be easily converted to a three-tier architecture?

How much effort is involved to separate the presentation logic

from the business logic?

Some issues to consider in scoping the work effort include:

▼ Does the application need to be modified for other reasons (for

example, new requirements or for Year 2000)?

2



Conversion to Three Tier Architecture (Continued)

▼ Does the user interface need updating or changing? For

example, do you want to provide a GUI instead of a terminal

interface? This is a good opportunity to convert to a Web-based

user interface.

▼ How difficult is it to partition the client application? Can parts

of the application be salvaged, or does the application need to

be rewritten for a three-tier architecture?

▼ Does the application need to use local client files and print

services? Is there a need to store or process information locally

on the client platform (for example, a local configuration file,

email, or print requests)? Applet security restrictions can be

problematic here.

● Does the existing Sybase database support a three-tier

architecture?

● Does the design of the database need to change? The entity-

relationship diagram can help you design your object class

diagrams. Database entities correlate strongly to objects. Many-to-

many entity relationships can be shown using UML notation.

2



Assessment So Far

At this stage it would appear that the client-side application would

have to be rewritten, since the database access logic is heavily

embedded in the C code. This is typical of 4GL applications.

However, you can make use of the existing data design and screen

layouts.

2



Applicability of Java Technology

Another question to ask yourself is: Is Java technology applicable for

all or parts of this application? There might be both business and

technology factors which would make Java technology suitable. You

can determine if there are such factors by asking yourself the following

questions:

● Does the customer intend to offer this application over the Internet

at some future time? Do the application’s end users already use a

Web browser (to access the Internet or company intranet)?

● Will the customer benefit from Java technology’s platform

independence? What are the customer’s plans for mergers and

acquisitions?

● Is the application volatile? Java technology can offer better

manageability for on-going application maintenance.

2



Applicability of Java Technology (Continued)

● Does the customer have standard 4GL development tools? How

will Java technology integrate or conflict with them? Will the

customer have to throw out their tools?

● Does the customer have object-oriented expertise in languages

other than the Java programming language? If nearly all of the

developers know Smalltalk or C++, but not the Java programming

language, which would be better to recommend

▼ An object-oriented architecture based on the languages that

they know?

▼ Training them in the Java programming language, justified by

the fact that the learning curve will be easy?

● Does the customer use groupware (for example, Lotus Notes)?

How will Java technology integrate, or conflict, with them?

● Are the security advantages of Java applets such as bytecode

verification, and the Java technology sandbox, an advantage for

this customer?

2



Readiness of Customer

How ready is the customer to proceed with Java technology?

● Does the customer already use Java technology?

● Does the customer have Web and Internet experience?

● Does the customer have object-oriented experience? If not, there

needs to be training in place before the customer embarks on

developing enterprise Java applications. If the customer has only a

team of COBOL developers, the training curve will be longer. Can

the customer wait for programmers to get trained?

● Are the customer’s client platforms capable of running Java

technology? Can they run a Web browser capable of handling Java

technology? Terminals such as IBM 3270s will have to be replaced.

Is the customer ready for this?

2



Readiness of Customer (Continued)

● Is the customer’s network capable of supporting Java technology?

Is there a TCP/IP network in place? Can the client platforms use

TCP services?

2


Advantages of Three-Tier Java Technology Architecture

Discussion – What are the advantages of a three-tier Java technology

architecture for the ECARS system? Does Java technology address the

company’s issues and provide for their new requirements?

Can Java technology

● Scale to support the 20,000 worldwide users?

● Keep the application maintenance overhead under control as more

clients are brought onto the system?

● Provide native language support for each country? The applet user

interface must display forms and GUI labels in local languages.

▼ Java technology supports internationalization with support for

the Unicode international character set encoding. (Unicode can

represent all the characters of all the world’s languages.)

▼ JDK 1.1 also supports the concept of locales using resource

bundles.

● A locale describes a preference for a language and ageographic region (for example, English/USA,French/Canada, or German/Switzerland).

● End users, or their system administrators, can specify theirpreferred locale in terms of ISO standard language andcountry codes. The locale definition can then be obtained bythe Java application which can interpret it and display textin the correct language and format (for example dateformats and currencies).

● The resource bundle can be part of the applet that is initiallydownloaded, or can be downloaded on demand.

● Resource bundles for different countries can be subclasses ofa base (default) class.

What other implications are there for native language support?

2


Advantages of Three-Tier Java Technology Architecture

● Handle local expense practices in Japan and Germany? Local

expense-handling practices in Japan and Germany can be

implemented by creating an abstract class to handle basic

expenses. Subclasses can then be derived for local practices in the

United States, Germany, Japan, and so forth. These classes can be

downloaded to the client platform.

● Enable managers to approve expenses for employees who work in

different regions or in other countries?

● Provide local expense policies for travelling employees? Java

technology can support this with resource bundles, and download

policy classes to the client platform.

2


Application Architecture Design

Tier One Tasks

What tasks does tier one perform?

● Data entry.

● Data validation.

● Computation and summarization of totals, such as expense line

items.

● Currency conversions. An example might be a Japanese yen to

United States dollar currency conversion routine. Until the applet

has started, there is no way of knowing which currencies are

required for the expense report. This conversion routine must be

downloaded to the client on demand.

● Detailed expense requests.

● Approval of expense requests (by manager).

2



Tier One Tasks (Continued)

● Local language display. Resource bundles can be created with

translations into different languages. The ECARS applet can then

load the appropriate class depending on locale, and thus display

messages in the correct language.

● Local expense policy use. An example might be employees who

need to use the local expense policy for the country they have just

returned from. This must be handled, even though the employees

might be in a different locale.

2



Tier One Choices

Figure 2-2 illustrates the options for tier one. Tier one is broadly a

choice between a Java applet and dynamic Web pages (dynamic

HTML or HTML with JavaScript).

● HTML forms pass data to a non-Java software script or program

using the Common Gateway Interface (CGI) protocol. Netscape

server API (NSAPI) and Microsoft internet information server API

(IISAPI) are alternate interfaces, proprietary to their respective

servers.

● Java applets pass data to a Java application or servlet.

Figure 2-2 Java Technology Architectural Choices

Web server

•CGI

•NetscapeNSAPI

•MicrosoftIISAPI

Web server

Javaapplication

Web page with form

HTTP

HTTP

Applet

Javaprotocol

SybaseRDBMS

JDBC

ODBC

Tier 1 Tier 3Tier 2

Non-Javacode

Servlet

2



Tier One Design

Table 2-1 compares the viability of HTML pages and Java applets.

Web forms can suffice if the user interface is simple, non-interactive,

and does not contain fields which have interdependencies. There is no

grid control in HTML—if this is needed, a Java applet should be used.

● For a simple tier one, HTML may load faster than a Java applet.

HTML is evolving with functionality, such as extensible markup

language (XML).

● Currently, HTML is supported on more types of clients than Java

applets.

Table 2-1 Tier One Design

HTML Java Applet

Web browsersupport

Any Web browser(extensions such asJavaScript are not supportedon all browsers)

Web browsers capable of using Javatechnology

Download speed Fast download Long to download (more complexlogic)

Interactivity Suitable for simple userinterfaces

Better for complex user interfaces(grids, trees, inter-dependent fields,cross-checking between fields, andso on)

Tier three access Uses CGI to access tier three Uses Java technology to access tierthree

State Stateless Statefull

2



Tier One Design (Continued)

A Java applet is preferable if the user interface is volatile, complex, or

has inter-dependent fields (for example, field X should not be filled out

if field Y has a certain value).

● The Java applet can perform data validation locally, saving on

trips to the network for validation purposes.

● The Java applet can also perform calculations, summaries, and

currency conversions.

2



ECARS Client Summary

For the ECARS application, use an applet since there is significant

computational and validation processing that can be done on the

client. Java technology makes it much easier to support the

internationalization and localization that is required. Figure 2-3

illustrates the logic flow in the client.

Figure 2-3 Client Logic Flow

Expenserequest

form

Validationcomputations

Call tier twoobject

Submitrequest form

EverythingOK?

EverythingOK?

Viewpendingrequest

Make changesto request

Approverequest

Client logic flow

NN

Requestors Approvers

YY

2



Decisions to Make

Now, you need to make further decisions on the use of Java

technology. Some of these are:

● How much business logic should go on the client (for example,

validation of expense request fields, currency conversions, or

totaling of expense line items)?

● Which level of the JDK will be used for development? Many

desirable features have been added in the JDK 1.1 and 1.2 versions

(for example, the enhanced GUI development classes in JDK 1.2

and the event mechanism in JDK 1.1).

2



Decisions to Make (Continued)

● How will the GUI be designed? You can use

▼ Java Foundation Classes (JFC)

▼ Purchased GUI classes

▼ Pre-written JavaBeans components

● Can any of the existing components be reused?

● Are you creating a Web browser dependency? Not all Web

browsers support JDK 1.1 and 1.2. Which Web browsers does the

customer use today? Is there a company standard for Web

browsers? Do these Web browsers support the level of the JDK

that you will use for developing the applet? You must be aware of

the implications of using these versions of the JDK.

▼ For an intranet implementation, the customer can specify and

control Web browser use.

2




▼ For an extranet, the customer may be able to specify and

control Web browser use.

▼ For the Internet, the customer has no control over the Web

browsers in use.

Note – The bottom line is that the client design should not restrict the

customer to a specific Web browser type, version, or product.

The architect should advise the customer on all issues related

to JDK and Web browser compatibility, so the customer fully

understands the trade-offs. The architect should also ensure

that part of the customer’s test plan includes testing the applet

on all Web browsers (and versions of those Web browsers) that

are in use.

2




● Have you considered using a Java plug-in application?

If there is a wide variety of Web browsers, suggest that the

customer standardize on one or two browsers, or opt to use the

JavaSoft Java Plug-in as a runtime environment for the applets.

The Java Plug-in is a downloadable runtime environment that is

used by the applet instead of the Web browser’s runtime.

● Should you use browser-independent code?

2




If the applet is to be used by external customers who may use a

variety of Web browsers, you must make the Java Plug-in

available when the applet is distributed, or not use any Java

technology features that might not be widely supported.

There are ways to ensure browser independent code, but they

may impose restrictions on the way the code is developed.

2



Tier Two Functionality

What services does this tier provide?

The ECARS application architecture must perform the following

functions at tier two (Figure 2-4):

Figure 2-4 Tier Two Flow

Note – The assumption that tier three will not change is being made at

this stage. The database design will remain and will move to tier three.

Clientrequesthandler

Data dispatcher

Expense requester

AddApprove

Check accessPrint

SQL constructorInsert

UpdateSelect

JDBC

Login

Check passwordSet access level

Print requester

Email

To tierone

To tierthree

2



Tier Two Functionality (Continued)

As Figure 2-4 illustrates, tier two

● Efficiently handles incoming Java applet requests.

● Runs business logic In this case, this involves taking the client

data, notifying approving managers using email, approving

expenses, and notifying the accounts payable system so the

employee can get paid.

● Assembles database access requests (read and write) and passes

them to the Sybase back-end database server.

● Conducts security checking (checking the login ID and password

of a user, authorizing user access to files and data). For instance,

managers can only see the expense reports of their direct

employees.

● Invokes print services

● Invokes email services

2



Tier Two Design Options

Figure 2-5 illustrates some of the tier two design possibilities. Other

possibilities, including other combinations of the parts shown here, are

viable too.

Figure 2-5 Tier Two Design Options

Javaapplication

Javaapplication RDBMS

AppletWeb server

CGI script

Web server

Servlet RDBMS

RDBMS

Applet

JDBC

JDBC

ODBC

RMI (JRMI)CORBA (IIOP)Socket

HTTP

HTTP

RMI (JRMI)CORBA (IIOP)

Socket

JDBC = Java database connectivity

2



Tier Two Design (Continued)

Tier two can be architected as one of the following:

● An application written in the Java, C++, or Smalltalk programming

language. This would allow for seamless object communication

from the client applet. The Java programming language is

recommended over C++ and Smalltalk since it allows for seamless,

object-oriented communication with the client Java applets.

● Web server plus CGI script. The traditional Web application uses the

HTTP protocol to the client tier, CGI at tier two, and database

access connectivity such as Microsoft’s Open Database

Connectivity (ODBC) to tier three. This is not an object-oriented

approach.

● Web server plus servlet. Servlets are easy to develop, especially for

programmers of the Java programming language familiar with

CGI scripting. Like CGI scripts, servlets are invoked by the Web

server.

Note – At a minimum, tier two must provide a Web server (for

downloading Java applets and HTML to the client tier), and a tier-two

application, script, or servlet to perform business logic and database

requests from the client tier.

2



Applications, Servlets, and CGI Scripts

Table 2-2 compares the options for designing business logic at tier two.

Table 2-2 Comparison of Java Applications, Servlets and CGI Scripts

Java Application Servlet CGI Program or Script

Javatechnologyexperience

Needed Needed Not needed; CGI scriptsare prevalent

Webconnections

Loosely integratedwith Web server (runsas separatemultithreadedprocess)Can run standalone(without Web server)

Closely integratedwith Web server(runs as Web serverthread)Invoked by Webserver

Loosely integrated withWeb server (runs asseparate process)Invoked by Web server

Threads Threaded forperformance

Threaded forperformance

Performance andscalability degradationthrough use of processes

JDK version Any JDK level JDK 1.1 and later;supported by mostWeb servers

N/A

Platformindependence

Platform independent(with JVM)

Platformindependent (withJVM)

Platform dependent

Output Produces HTML andother forms of output

Produces HTML andother forms ofoutput

Produces HTML output

Requests Persistent; can reusedatabase connections

Persistent; can reusedatabaseconnections

Loaded for each request;opens new databaseconnection each time

Protocols Supports protocolsother than HTTP

Supports protocolsother than HTTP

Uses HTTP

2


Client requests Application mustmanage clientconnection requesthandling andmultithreading

Web server managesclient connectionrequest handlingand multithreading

Web server managesclient processes

Distribution Not downloadable Downloadable overnetwork (like applet)for load balancing atmultiple locations

Not downloadable

Table 2-2 Comparison of Java Applications, Servlets and CGI Scripts (Continued)

Java Application Servlet CGI Program or Script

2



Applications, Servlets and CGI Scripts

Discussion – What are the advantages and disadvantages of designing

the second tier as a Java application, a servlet, or a CGI script?

2


Notes

2


Tier Two Architecture

Servlet Architecture

For the ECARS application, use a servlet (Figure 2-6).

The client applet calls the servlet using a URL request containing data

from the expense request. The Web server invokes the servlet as a

thread. When a client request arrives, the Web server passes the

expense request, as an argument, to the servlet. This servlet can handle

multiple client requests simultaneously. Servlet methods can be

designed for connecting to the database, sending email, printing,

checking security, and so forth.

Figure 2-6 ECARS Application Server Architecture Solution

The servlet design and code can be reused by the customer for other

business applications that require access to a three-tier database.

Note – Servlets can also process HTML form data passed to them by

the Web server.

Alternately, you could have opted for a Java application which would

run in its own process. The application would create a pool of reusable

threads to support each incoming employee request. An application

would be preferable for high workloads where the application could

be moved to a different platform from the Web server.

Applet Webserver

Servlet

Pool ofservletthreads

SybaseRDBMS

JDBC

URL

RMICORBA

2


Tier Two Architecture

Web Server

In general, the architecture design should not be tied to a specific Web

server product. In this case, it is preferable if the Web server supports

servlets, although you can start servlets from a lightweight container

program called the servletrunner. The choice of Web server may be

dictated by the customer’s current standard, or you may be asked to

recommend a Web server. Evaluation of Web servers is not covered in

this course.

Note – The Web server that runs the servlet does not have to be the

same Web server that the company uses for general HTML. A separate

Web server should be recommended if the existing Web server is

heavily loaded.

2


Communication Protocols in a Three-Tier Architecture

One of the key decisions that the architect must make is how the

application tiers communicate. The choices largely depend on the type

of client and server design and language, and the running

environment (Figure 2-7).

Figure 2-7 Three-Tier Application Communication Protocols

Some of the choices are:

● HTTP

● TCP sockets

● CORBA Internet inter-ORB Protocol (IIOP) using JavaIDL

● Java RMI

● Java native interface (JNI) to native protocol

● Vendor-supplied proprietary protocol

Web server

Javaservlet

HTTPApplet

Non-object-orientedapplications

Java RMITCP socketJava IDL

CORBA

Tier two Tier three

Sybasedatabaseserver

JDBC

Object-orientedapplications

TCPsocket

Nativecode

JNI

2


Three-Tier Application Communication Protocols

Table 2-3 compares the following four major communication protocol

choices for three-tier applications:

● HTTP

● Java RMI

● Java sockets

● Java IDL (CORBA)

2


Three-Tier Application Communication Protocols

Table 2-3 Comparison of Application Communication Protocols

HTTP Java RMI Sockets Java IDL (CORBA)

Use N/A Javatechnology toJavatechnology.

Java technologyto any.

Java technology toany.

Object-orientation

No. Yes. No; however,objects can beserialized oversockets.

Yes (also supportsnon-objectlanguages).

Objectdistribution

N/A Can transferobjects andobjectreferences.

N/A Can transfer objectreferences. Objectscan be transferred inCORBA Version 3products.

Language Supports Javatechnology.

Javaprogramminglanguageonly.

Multiplelanguages.

Multiple languages.

Learningcurve

Noprogrammingneeded.

Programmersdo not have tolearn CORBAdetails.

Programmers ateach end have toknow the formatand type of thedata.

Programmers have tolearn CORBA and theJava programminglanguage.

Package N/A Standard partof Javatechnology,nothing tobuy.

Standard part ofJava technology,nothing to buy.

CORBA products arepurchased fromvendors.

Services N/A Limitedservices.

No services. CORBA services(naming, security, andso on).

Scope Connect toany objectknown by aURL.

Connect toany Javaobject knownto RMI.

Connect to anyapplication thatsupports thesocket format youhave designed.

Connect to anyCORBA object knownto CORBA system orto any linked CORBAsystem.

2


Networksupport

Multiplenetworks.

TCP/IP only. Multiplenetworks.

Multiple networks.

Security Encryptionprovided byWeb browser(SecureSockets Layer[SSL]).

No nativeencryption(use JDK 1.2security).

Can useencryption(secure sockets).

Security may beimplemented byCORBA vendor.

Firewalls Can gothroughfirewalls.

May berestricted byfirewalls.

May be restrictedby firewalls.

May be restricted byfirewalls.

Table 2-3 Comparison of Application Communication Protocols (Continued)

HTTP Java RMI Sockets Java IDL (CORBA)

2


Three-Tier Application Communication Summary

Applet to Servlet APIs

Since you have decided to configure tier one as a Java applet, your

choices for communicating with tier two include:

● Using RMI to communicate with a Java application server or

servlet (once the initial request is established). If the customer is

committed to an all-Java technology design, this is the most

natural way to connect Java applets and applications.

● Using TCP sockets to communicate with a Java application server

or servlet, or to a non-Java application server. If the customer’s

developers know TCP sockets, they are easy to use, but they are

low-level and not object-oriented. The prime advantage of sockets

is that they are supported on most platforms, and back-end code

can be left undisturbed (if it uses sockets).

2


Three-Tier Application Communication Summary

Applet to Servlet APIs (Continued)

● Using Java IDL (CORBA) to communicate with non-Java

technology objects and legacy applications that can be accessed

using CORBA. This is the optimal middleware for connecting Java

applets to heterogeneous applications written in multiple

programming languages (C or C++ legacy code can be accessed

using CORBA object semantics).

2


Three-Tier Application Communication Choices

Servlet-to-Tier Three Communication APIs

There are similar choices here, with some additional choices. You can

use

● Java RMI if tier three contains Java technology.

● TCP sockets if tier three has socket interface.

● Java IDL if tier three supports the CORBA interface. CORBA

middleware can be used to encapsulate the legacy program in an

object-oriented layer.

● Java Database Connectivity (JDBC) if tier three is a database with

network support. This is the case for the ECARS application.

● Vendor-specific APIs (for example, SAP APIs). These are

determined by the nature of the application.

2


Three-Tier Application Communication Choices

Servlet-to-Tier Three Communication APIs (Continued)

● Application middleware APIs for communicating with

middleware such as transaction-processing monitors. Transaction

processing middleware is required if tier three processing involves

updating multiple databases using the two-phase commit, or if a

transaction monitor can provide needed performance and load

balancing to tier three.

● Bridging APIs to communicate with mechanisms such as CORBA

to DCOM and DCOM to Java technology

2


ECARS Summary for Communications

For this course, use the Java RMI API for applet-to-servlet

communication. One of the key advantages is that entire objects (code

and data) can be transferred using RMI. Using RMI, the ECARS client

applet can upload new implementations of currency conversion

routines and changed expense policy rules, as objects (methods as well

as data). The objects are updated on the server, but execute locally on

the client. This enables modifications to be made to the policies

without having to halt the clients—the client automatically gets the

new version of the object when they next log on or download an

applet.

2


ECARS Summary for Communications

JDBC will be used to access tier three. To keep things simple at this

stage, assume that you have moved the Sybase database to a tier three

server, and that you are keeping the existing Sybase database server

and database schema. Use JDBC to replace the ODBC calls that were

used by the old client applications.

2


RMI Architecture Overview

RMI is a layered architecture (Figure 2-8).

Figure 2-8 RMI Architecture Overview

Figure 2-8 illustrates two layers:

● RMI stub and skeleton layer – The stub provides a proxy service

for the client to call a remote object, and the skeleton dispatches

the call to the actual object method. This layer serializes the

object’s arguments (makes it into a stream of bytes) and any data

that is returned after the object executes. This data can be an

object.

Java applet

RMI stub

Transport layer(TCP)

Javaapplication

RMI skeleton


RMI native protocolJRMP

RMI registry

Client tier Tier two

RMI registryserver

RMI connection

JRMP = Java Remote Method Protocol

2



● Transport layer – This is used by RMI for connection setup and

management. (RMI currently uses TCP/IP sockets, though this

could be changed without affecting the higher layers.)

2



RMI Features

Features of RMI include the following:

● A lighter framework than CORBA.

● Distributed garbage collector. When there are no more outstanding

references to a remote object, the object is discarded.

● Uses Java technology security. Basic applets can access only objects

on the Web server platform (standard applet restriction). However,

applications and signed applets can access any host. Security will

be discussed in more depth in Module 6, ‘‘Designing a Secure Java

Technology Architecture.”

● Uses object serialization for passing objects.

● Passes remote objects by reference and other objects by value.

● Can tunnel through HTTP if the RMI protocol is rejected by a

firewall. This is an automatic fallback at the client.

2


Notes

2



Object Naming and Locating

The RMI registry is commonly used to locate RMI objects. The registry

loosely correlates to a CORBA object request broker (ORB). New

objects are serialized and sent to the Java registry with a locator URL.

Clients access the registry to locate objects and then invoke the remote

object using the remote stub proxy returned by the registry.

Note – JavaSoft is moving towards the use of industry standard

naming and directory services for locating RMI objects. This will be

achieved by using Java Naming and Directory Interface™ (JNDI)

services for RMI. Since JNDI encapsulates most naming service

implementations, RMI will be able to use them too.

2


Summary of the ECARS Solution

Figure 2-9 provides a high-level overview of the ECARS application

solution.

Figure 2-9 ECARS Solution Summary

Corporate intranet

Web serverSybaseRDBMSserverwith servlet

Emailserver

Employees

Managers

Regionallocation

Mainframeaccountspayablesystem

RMI

Tier 3Tier 2Tier 1

Mainframeterminalsfor legacyreportingand similarfunctions

2



Tier One

Figure 2-9 illustrates the following features of tier one:

● On the client platform, employees can use any JDK 1.1 compliant

Web browser (or the Java Plug-in). This restriction is due to the

need to support the RMI API.

● The ECARS applet is accessed by the employee entering its URL.

The Web server downloads the initial applet classes using HTTP.

The applet ascertains the locale (country) of the employee or

approving manager and downloads the relevant resource bundle

of classes that contains the native language text and labels for the

applet display.

2



Tier One (Continued)

Note – RMI uses the Java technology object serialization mechanism of

JDK 1.1 to send objects over the network. This means that Web

browsers used for the ECARS application must support JDK 1.1

directly or through the Java Plug-in.

● The ECARS applet subsequently accesses the tier two servlet using

Java RMI which is sent directly to the server port using TCP/IP (it

does not go via the Web server).

● Currently, ECARS does not support direct printing from the client

applet. This will be implemented as an add-on feature and will be

discussed in Module 3, ‘‘Java Technology Architecture Details.”

Tier Two

As shown in Figure 2-9, tier two has the following features:

● The servlet generates email to the list of approvers, and writes the

expense report to the Sybase database.

● If the company’s expense policy changes (for example, the upper

limit on hotel amounts is raised to $200 per night), the

programmer writes a new implementation of the policy interface

and installs it on the Web server. When the client applet invokes

the server’s getPolicy method using RMI, the new version of the

policy will be downloaded by RMI. When employees log in they

always get the latest policy, and any violations of the policy can be

detected up-front, when the employees enter the expense report,

instead of not being detected until much later in the process (for

example, by one of the approving managers).

● The Web server invokes the servlet.

● As ECARS is implemented worldwide, tier two can be replicated

in Europe and Asia.

2



Tier Three

Tier three is shown (in Figure 2-9) with the following features:

● The Sybase database server runs on a separate platform. Calls to

the database are made from tier two JDBC. JDBC will be discussed

in detail later in this course.

● There must be a transaction generated to the accounts payable

system, which resides on a separate mainframe. There are multiple

ways to accomplish this, including

▼ A database trigger

▼ Native code to existing mainframe application interfaces

These techniques will be discussed later in this course.

Three-Tier Advantages

Some advantages of using a three-tier architecture are

● Employees and managers can track expense claims from anywhere

in the world by using a Web browser.

● There is only one version of the client application to maintain.

● New expense policies can be easily implemented on the server and

downloaded as classes to the client platform.

● The system caters to international users.

● The error rate for expense processing is significantly decreased

since all employees are aware of the latest policy and since the

local Java applet does all computations instead of leaving it up to

a human.

● There is no human involvement in the process.

2



Architecture Considerations Applied

Some basic architecture standards that must be considered are

● Java technology versus HTML.

● JDK levels and browser dependency.

● Internationalization and localization.

● Java application and servlet assessment for tier two (Enterprise

JavaBeans will be added to these choices).

● Redesign of existing application. Existing 4GL client-server

applications may be too hard to convert. The architect may opt to

redesign the entire structure or incorporate part of the

architecture—for example, into tier three—leaving the intertwined

presentation and business logic undisturbed.

● Communication protocol assessment and selection.

2


ECARS Benefits

Discussion – What has the architect achieved with the ECARS

architecture?

2


Exercise: Designing a High-Level, Three-Tier Architecture

Exercise objective – Respond to a set of customer requirements and

map them to a three-tier architecture. List what information is missing

and should be gathered at the next meeting with the customer.

Discuss your proposed architecture with the customer (in this case the

other students). This activity is intended to get you used to the idea of

communicating with customers in an informal manner; for example,

using a whiteboard to propose a basic three-tier Java technology

architecture solution.

Preparation

To prepare for this exercise, do the following:

1. Read the customer’s requirements and constraints that are

detailed in Appendix A, “Case Studies,” in the “Module 2 Case

Study” section. Detailed instructions for completing the exercise

can also be found there.

2. Read and familiarize yourself with the Module 2 case study

before you go into your small groups. If you have any questions,

please ask the instructor for clarification.

2


Exercise: Designing a High-Level, Three-Tier Architecture

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues,

or discoveries you had during the case study.

● Experiences

● Interpretations

● Conclusions

● Applications

2


Check Your Progress



❑ Evaluate the applicability of a Java technology solution for a given

customer application requirement

❑ Design a basic three-tier architecture for a set of customer

requirements

❑ Explain the advantages of using Java RMI for a given customer

architecture

❑ State the major architectural issues and trade-offs faced when

designing a distributed Java technology solution

❑ Discuss the advantages of servlets rather than CGI scripts

❑ List common communication protocols used in a three-tier Java


2


Think Beyond

Imagine that at your customer presentation, you were asked the

following questions. How would you respond?

● RMI can only access Java objects not CORBA. When will RMI be

able to access CORBA objects?

● I need to design a new client interface for an existing database

application. How do I decide which is best: Java applet, HTML,

C++, or an object-oriented application builder such as Powersoft

PowerBuilder or Visual Basic?

● If I build my client application using Java technology, will it

coexist with my current environment?

● Java technology seems to be very volatile. Could new features and

changes to Java APIs affect my code?


JavaTechnologyArchitectureDetails 3

Course Map

This module delves further into the Java technology three-tier

architecture, and the decisions and trade-offs that need to be made for

each of the tiers. Case studies will be used to explain the architecture.

Basic Principles



Foundation


Advanced Principles






Deployment


3


Relevance

Discussion – At a previous meeting with the customer, you presented

a high-level three-tier architecture design. The customer is interested

in the object-oriented architecture and has asked for a proof of concept

with a more detailed design for the application components (client

tier, application server tier, and communication interfaces). The

customer has also asked for a comparison of Java RMI, CORBA, and

DNA (DCOM) alternatives for implementing this object architecture.

What are the advantages and disadvantages of each of the following

distributed object architectures?

● RMI based on Java technology

● The Object Management Group’s (OMG) CORBA

● Microsoft’s DNA (DCOM)

Which one is most applicable for this customer?

Note – JavaSoft’s Enterprise JavaBeans™ (EJB) is also a distributed

application architecture and will be discussed later in this course.

3

Java Technology Architecture Details 3-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Given set of business requirements, design a multi-tier, object-

oriented application architecture

● Design a detailed architecture that includes Java applet and

application server designs

● Compare a distributed Java technology architecture with the OMG

CORBA and Microsoft alternatives

● Discuss the benefits and disadvantages of these distributed

architectures for a set of customer requirements

References



● Meta Group. March 1998. CORBA versus DCOM: Solutions for theEnterprise. [Whitepaper].

● Mowbray, Thomas J. and Ruh, William A. 1997. Inside CORBA:Distributed Object Standards and Applications. Addison Wesley.

● Vogel, Andres and Duddy, Keith. 1998. Java Programming withCORBA. Wiley.

● Orfali, Robert and Harkey, Dan. 1998. Client/Server Programmingwith Java and CORBA. Wiley.


3


The Customer

MedBroker Inc.

MedBroker Inc. is a company that facilitates prescription payment

checking between pharmacies and health insurance companies. Their

business came about because of the diversity in the information

technology (IT) systems in the health insurance business.

Current Application Description

Basically, MedBroker acts as a universal translator, receiving

prescription claims from pharmacies in a variety of formats over a

variety of communications protocols (running over X.25 and leased

lines). The MedBroker application formats the claim data into a format

that can be accepted by the relevant payer (usually a health insurance

company).

3


The Customer

Current Application Description (Continued)

The MedBroker application currently runs on proprietary hardware

and accepts requests over dial-up or leased lines or over an X.25

packet switched network.

MedBroker checks the customer ID, determines the location and

format of the insurance company, and routes the request on to the

relevant company where it is authorized or denied, and sent back to

the pharmacy via MedBroker.

The Problem

MedBroker is a very aggressive company and wants to sign up more

pharmacies and health insurance companies. The current hardware

platform is the top end of its range, runs a proprietary operating

system and cannot be upgraded to provide for this growth. MedBroker

is keen to avoid any future proprietary lock-ins.

3


Proposed Customer Architecture

Current Proposal

Figure 3-1 shows the object class diagram that you presented to

MedBroker Inc. at your last meeting.

Figure 3-1 MedBroker Inc. Proposed Object Class Diagram

Claim form

Claim view

Claim router

Verify,translate

format, route

MedBroker premises Insurance companyPharmacy premises

Request


Request

To othersystems

Response

InsurancecompanyLocationformat

PharmacyLocationformat

Response

Claimauthorizer

Authorize orreject

ConsultsConsults

Sends

3



Application Requirements

Some of the requirements of MedBroker are

● The performance of the MedBroker application is paramount. The

system should impose no noticeable delay for the pharmacy (the

transaction must be translated, routed, and returned within a 10

seconds).

● MedBroker must not be seen as a delay in the entire transaction in

any significant way. The request is received in real time and must

be processed by MedBroker within a one-second (MedBroker’s

own goal). This does not include the processing at the pharmacy

or the insurance company.

● The application must be able to process 600 transactions per

second.

3



Application Requirements (Continued)

● Existing client platforms must not be affected.

▼ Pharmacies use a mixture of disk operating system (DOS) and

Windows personal computers (PCs), and turnkey hardwired

terminals that read customer insurance card data, and access

MedBroker.

▼ MedBroker has no control over the front-end PC or terminal

market. Thus, they cannot stipulate that their customers use

specific hardware or software.

▼ MedBroker anticipates that the health care industry will

eventually standardize on a set of formats, but that is unlikely

to happen in the near future. However, this should be kept in

mind when designing an architecture.

▼ Notwithstanding, MedBroker would like to expand the range

of connectivity to include Web-based transactions.

● Client data must be fully secured and recoverable in case of a

system error.

● Heterogeneous front and back ends are supported.

3



Because of the heterogeneous nature of the clients and back-end

insurance company platforms, MedBroker likes the object-oriented

approach. They particularly like the ability to derive new types of

transactions from the existing objects.

3



Based on the high-level object diagram that you presented, the

customer now wants to understand how this object architecture can be

implemented.

The customer has indicated they would like to standardize on a

common programming language for all software systems. Currently,

developers use a mixture of Visual Basic and C, and they have limited

object-oriented expertise.

What are the advantages and disadvantages of each of the following

distributed object architectures?

● Java RMI

● The OMG’s CORBA

● Microsoft’s DNA (DCOM)

Which is the most applicable for this customer?

How can you implement this architecture?

3


Architecture Framework Assessment

An object-oriented framework such as CORBA, DNA (DCOM) or Java

RMI allows object-to-object communication (Figure 3-2). These

architectures must now be assessed with respect to MedBroker’s

requirements.

Figure 3-2 Architecture Framework Assessment

X.25network

X.25front-end

Applicationserver

CORBADNARMI

Claimcheckapplication

Back-endapplication

FirewallInternet

Future

Webserver

CORBADNARMI

Future

Current

3


CORBA Architecture Overview

CORBA is a multi-tier layered architecture (Figure 3-3). The CORBA

specification defines the stub and skeleton layers, but does not define

which transport layer should be used. In most cases, TCP is used as

the transport by CORBA vendors. The shaded boxes show how a

vendor would implement the CORBA standard.

Figure 3-3 CORBA Architecture Overview

Client application

CORBAclient IDL stub(proxy)

ORB library


Server object

ORB library

CORBAstatic serverskeleton


Other vendorORBs

Object adapter

Method calls using IDL

RPC or IIOP

RPC or IIOP

CORBAdynamicinvocation

CORBAdynamicinvocation

Interfacerepository

RPC = Remoteprocedure call

3



The object request broker (ORB) is part of the implementation of the

CORBA specification. The ORB is like an object bus between CORBA

objects. The ORB consists of client and server library code that enables

objects to call other objects without regard to object location. ORBs

from different vendors can communicate with each other using

Internet Inter-Orb Protocol (IIOP), which is defined in the CORBA

standard.

Operations

There are two ways for a client to invoke a server object using CORBA:

● Static – The methods of the server object are pre-described using

an interface definition language (IDL). Both the client application

and the server object are compiled with the IDL. The server

registers itself with the ORB and its details are stored in the

interface repository. The client stub must be pre-loaded.

3



Operations (Continued)

● Dynamic – The request for the server object is built at runtime

using information from the interface repository. No pre-loading of

stubs is required. This offers more flexibility, especially if objects

are volatile and are moved around. However, there is a slight

performance impact at runtime.

The client application calls the ORB through the client stub or dynamic

interface to locate and start the remote object. The object adapter on

the server starts a server process for the server object (if it is not

already running). The object adapter

● Instantiates new objects or activates objects from persistent store

● Manages object references

● Handles incoming client calls

● Invokes the requested methods

● Deactivates objects

The client application calls a method in the server object. The call is

made directly using the object reference, not via the interface

repository. The parameters are marshalled into a standard format and

passed to the transport layer.

The server skeleton unpacks the message and calls the requested

method on the server object. It is up to the server object to handle

multiple client requests; for example, by creating threads.

3



Services

The CORBA specification provides a mature set of services for

managing objects in a distributed environment:

● Persistent object service – CORBA provides a persistent record of

instantiated objects. If the server fails, these objects can be

recovered.

● Centralized naming service – CORBA provides a centralized

naming service for locating and tracking objects by name. Names

are stored in a directory. If multiple ORBs are used, a naming

pattern that will work across multiple vendor ORBs must be

devised.

● Messaging service – This provides asynchronous messaging

support for CORBA objects.

● Events service –This is an event notification service for CORBA

objects. It allows events to be passed between objects that have no

direct awareness of each other. This service manages one-to-many

event notification.

● Transaction service – This provides a CORBA interface to

transaction monitors, such that multiple objects can be modified

with full transaction support (using the two-phase commit

protocol). Objects provide an interface for prepare, commit, and

rollback operations.

● Security service – This service allows the integration of vendor

security products into CORBA.

3


DCOM Architecture

DCOM is an evolution from Microsoft’s Component Object Model

(COM) which is a compound document framework (Figure 3-4).

Figure 3-4 Microsoft DCOM Architecture

The DCOM architecture is very similar to CORBA in that it provides

an “object bus,” client and server stubs, and a repository. Clients can

instantiate remote objects. DCOM clients can be written in C++, the

Java programming language, Visual Basic, and many 4GLs.

On Windows platforms, DCOM is highly integrated with operating

system services such as threads and memory management.

Clientapplication

RPC ormessaging

Transport layer

Servercomponent

MicrosoftTransactionServer

Transport layer

COMruntime

RPC ormessaging

IDL

IDL

Client proxy

Serverstub

COMruntime

Registry

3


DCOM Architecture

DCOM is layered on top of the Distributed Computing Environment

(DCE) RPC service. DCOM uses TCP as the transport layer. DCOM

can be tunnelled through HTTP for access through firewalls.

Operations

The steps taken are as follows:

1. The client application specifies the server interfaces using an IDL.

Microsoft’s Interface Definition Language (IDL) is used to

describe interfaces. This is not the same as the CORBA IDL.

2. The client proxy and server stub are generated and registered.

Both static and dynamic interfaces to DCOM are supported. The

registry returns the remote object location to the client.

3. The client makes a call to the server using an interface pointer.

The Service Control Manager tracks running objects on the

server. Unlike CORBA, clients cannot connect to an existing

object instance.

3


DCOM Architecture

Services

DCOM provides a range of services such as transaction processing,

messaging, and object management. Some services are provided by

Microsoft Windows NT.

Other aspects of DCOM are:

● Events are provided through ActiveX controls.

● There is no centralized naming service.

● A persistence service is supported.

3


Comparison of Object Frameworks

Table 3-1 gives a comparison of the object frameworks discussed in

this module.

Table 3-1 Comparison of Object Frameworks

CORBA RMI DCOM

Languages Multiple language(supports both objectand non-objectlanguages).

Java programminglanguage only.

Multiple languagesupport (Microsoftlanguages).

Platforms Cross-platform.Implemented bymultiple vendors onmultiple platforms.

Cross platform (withJVM support).

Microsoft platforms.Ported to non-Microsoft UNIX®platforms bySoftware AG.

Additionalpackages

Need to purchasevendor products.

Standard part of theJava technology. Noextra products needed.

Need to purchasevendor products.

Standards OMG standard. JavaSoft standard (ISOstandard in the future).

Microsofttechnology.

Naming service Centralized namingservice.

No current centralizednaming service.

No currentcentralized namingservice.

Scalability Proven scalability. Scalability not proven. Scalability notproven.

Integration Integrates withlegacy applicationsusing objectwrappers.

Does not integrate withlegacy applications thatdo not support Javatechnology.

Does not integratewith legacyapplications.

Framework Complex framework.Have to learn newlanguage (IDL).

Lightweightframework.Easy to use if you knowthe Java programminglanguage.

Complex framework,but masked by high-level products.

3


With RMI and CORBA, the option to pass entire objects (code and

data) can generate large amounts of network traffic. The architect

should use this option with care, especially over slower network links.

IntegratedDevelopmentEnvironments(IDE)

Limited variety ofIDEs; may have touse 3GL.

Limited variety of IDEs;may have to use 3GL.

Wide variety of high-level IDEs.

Services Provides robustrange of services(transaction, naming,security, persistence,event, and so on).

RMI services areevolving.

Provides transactionand messagingservices.

Garbagecollection

No distributedgarbage collection.

Distributed garbagecollection.

No distributedgarbage collection.

Interoperability Java technologyinterface to CORBA.

Future support forCORBA using InternetInter-Orb protocol(IIOP).

Java technologyinterface to DCOM.

Objectdistribution

Objects can be sentover the network(CORBA 3).

Objects can be sent overthe network, allowingfor object distribution.

Objects cannot besent over thenetwork, only objectreferences.

Communicationprotocol

IIOP. Java Remote MethodProtocol (JRMP). FutureIIOP support.

IIOP support usingthird party products.

Table 3-1 Comparison of Object Frameworks (Continued)

CORBA RMI DCOM

3


Assessing CORBA for the Architecture

CORBA Advantages

Of the three architectures, CORBA is the most “open” and mature, and

provides the most heterogeneity and proven scalability, which is a

prime requirement for the MedBroker application.

Other advantages are the centralized naming service, persistence of

running objects, and the automatic starting of called objects.

Performance and Reliability

Since this application has critical response time requirements, you

must ascertain the performance levels though prototyping. You can

develop a skeletal application to test and validate the performance of

your architecture. Performance will be discussed in detail in Module 7,

‘‘Designing an Architecture for Performance.”

3


Assessing CORBA for the Architecture

CORBA Implementation Choices

While the CORBA standard is open, there may be some proprietary

implementations of the standard by vendors (for instance,

communication protocols, platforms, and so on). Thus, for a customer.

the choice of CORBA vendor and standardization on that vendor may

be important. Naming and object references can cause issues between

different vendor implementations.

CORBA vendors provide mappings from a wide variety of object and

non-object languages to the IDL (for example, C, C++, COBOL, the

Java programming language, and Ada). However, C++ and the Java

programming language are the most common. Using CORBA to

implement the overall architecture gives you a number of choices for

implementation of the client tier.

Table 3-2 CORBA Implementation Choices

Option Implementation Choices Comment

1 Since the inbound network (X.25and leased lines) is not currentlyconstrained, leave the inboundnetwork intact, and provide a“bridge” at tier two to CORBA.

• This does not provide MedBroker withobject technology throughout theentire application. The company willlose flexibility in implementing futuresystems and reusing existing objects.

2 Rewrite the pharmacyapplication in an object languageand use CORBA so that it is partof the overall CORBAarchitecture.

• This would force the pharmacies to usea PC capable of supporting theseCORBA applications. The DOSplatforms and the terminals are unableto support CORBA applications.MedBroker is not in any position todictate client platforms. Thus, this isnot an option here.

• Note that the company would have tochoose a CORBA vendor that supportsits existing network or convert thenetwork to TCP/IP.

3


3 Rewrite the pharmacyapplication as a Java applet anduse the Java application toCORBA interface to tier two.

• This solution is not applicable heresince the Java application to CORBAinterface runs only on Solaris,Microsoft Windows 95, and WindowsNT systems. This is too narrow a rangeof clients for the pharmacies. TheWindows 3.1 and DOS platforms andterminals would have to be upgraded.A more general solution is needed.

4 Convert the pharmacyapplication to HTML withJavaScript or Microsoft ActiveXplug-in to provide computationsand interactivity.

• While this approach is simple, it maynot provide the degree of interactivityand sophistication at the user interface.It would also make the client platformsdependent on certain types of Webbrowsers, and contribute to the “fatclient” syndrome.

• Microsoft ActiveX plug-in binariesmust be downloaded to each client andcompiled for the platform.

5 Convert the pharmacyapplication to a Java applicationand use TCP sockets tocommunicate with a Javaapplication server, then useCORBA to communicate with tierthree. Sockets will run over theexisting network using Point-to-Point Protocol (PPP) until it isconverted to IP.

• This is the optimum solution for newcustomers.

• TCP will need to be installed on eachclient platform.

6 Provide a Java applet as anaddition to the current methods ofaccessing the MedBrokerapplication.

• The vendors that supply thepharmacies with turnkey systemswould have to add Web browser andTCP network support. However,existing terminals and networks arestill supported and can be upgraded atany time to take advantage of the newapplication.

• This would give MedBroker a bigadvantage over its competitors andwiden the customer market.

Table 3-2 CORBA Implementation Choices (Continued)

Option Implementation Choices Comment

3


CORBA Applicability

Discussion – Since the pharmacies use DOS and Microsoft Windows

platforms, isn’t Microsoft’s DNA (DCOM) architecture a better

alternative for distributed object communication?

3


CORBA Architecture Implementation Considerations

Recommendation to Customer

You have advised the customer to offer pharmacies the option to access

the application using the Internet. There is no need for pharmacies to

use this approach, but they would gain significantly from it. The

system will be modeled from an overall object approach, even though

objects will not be fully implemented at tier one.

Problem Assumptions

Some problems you should consider are

● Pharmacies with older DOS PCs and Windows 3.1 will continue to

use the existing systems and networks.

3


CORBA Architecture Implementation Considerations

Problem Assumptions (Continued)

● Pharmacies using Windows 95 PCs will use a Java application that

uses TCP socket communication to the tier two Java application.

There is no need for a Web browser because the client will use an

application rather than an applet. All platforms are capable of

supporting TCP (even if they do not have it installed currently).

They will need TCP for eventual Internet access.

▼ The reason for choosing sockets is primarily performance

compared to the use of CORBA or RMI. Also, the data format

used in the socket can be matched to the format used by the

older applications coming in over leased lines and the X.25

network.

▼ The use of sockets eliminates any potential delay in

downloading RMI or CORBA classes when the browser does

not provide those facilities.

● CORBA will be used from tier two to three. The customer will

have to develop object wrappers for the back-end applications.

The insurance companies will have to run a CORBA ORB.

3


CORBA Implementation Stages

The architecture can be implemented in stages (Figure 3-5):

Figure 3-5 Stages for Implementing an Architecture

Javaapplication

Javaapplet

OldMedBrokerapplication

CallJNI

Javaapplication

Webserver

Objectwrapper

Back-endapplication

HTTP

1

2

3

CORBA,RMI orSocket

X.25 orleased

line

CORBA

RMI

Servlet

Turnkeyclient

3


CORBA Implementation Stages

As Figure 3-5 illustrates, you must

● Maintain a dual system. The existing DOS turnkey terminals and

PCs can still access old MedBroker application (ported to a faster

platform). All new clients and new insurance companies can use

the object-oriented architecture.

● Rewrite the business logic part of the MedBroker universal

translator in the Java programming language. Convert the back-

end network to TCP/IP and implement CORBA to connect the

MedBroker application to the various heterogeneous back-ends.

The old MedBroker application can be interfaced with the Java

application through a bridge such as the Java Native Interface

(JNI). JNI allows native applications to call Java applications.

● Eventually add the ability to input pharmacy claims over the

Internet, perhaps by rewriting the client application as a Java

applet. This will introduce security constraints into the

architecture. A servlet running on the Web server can act as a pass-

through to the new MedBroker Java application.

3


Applet Design Critical Issues

With this in mind, the crucial issues for MedBroker are:

● Applet download time. Initially the pharmacies will use an

application over the existing network, so this will not be an issue.

However, the pharmacies will eventually access the applet over

the Internet. Class loading is slow because it uses the HTTP

protocol. Options to improve the speed include using

▼ HTTP 1.1 if it is supported by the Web browser JVM (class

loader).

3



▼ Compressed Java archive (JAR) files download multiple applet

classes at one time. JARs are always loaded “whole” but in JDK

1.2 there is a mechanism (Java Extensions Framework) that

allows multiple JARs to be specified so that each is loaded only

when needed. Many designers opt to download just the classes

required by the initial screen, and then use a separate thread to

download the remaining applet classes in the background.

Carefully designed, this can make applets appear to start very

quickly without noticeable runtime performance degradation.

▼ Alternative forms of applet distribution instead of doing it over

the network (for example, compact disc read-only memory

(CD-ROM), or push technology). Using Java technology does

not force you to use network loading.

▼ Careful applet design. A common cause of performance

degradation is the repetitive instantiation of single-use objects.

How can you get round this? The Java application does reclaim

memory resources when the object is no longer required, but it

is more efficient to reuse components.

● Transaction response time. This is the elapsed time measured from

when the pharmacist enters the request to the time when the claim

verification is received. To increase performance, the design

should keep the amount of data passed to the client small (using

tier two to reduce the amount if necessary).

The use of sockets enables you to have more control over the

amount of data. Note that this must be weighed against the extra

work involved in the use of sockets compared to RMI or CORBA.

3



● Applet “footprint” size. Applet footprint size is a combination of the

bytecode size, memory size and CPU size required for applet

execution. The architect should estimate the applet footprint and

hence loadtime. The size of JAR file (100 Kbytes, for example) is

divided by network throughput speed (1000 bytes per second for a

WAN, for example). Using this calculation, it would take 100

seconds (a little under two minutes) to download the JAR file.

Note – This happens only once, when the applet is started, and may be

acceptable to many customers.

CORBA runtime libraries add to the applet size and can make it

unmanageable on smaller PCs.

3


Applet Design Details

Building the GUI

The architect (or the designer) should decide between the Abstract

Windowing Toolkit (AWT), the JDK 1.1 Java Foundation Classes (JFC),

or purchased GUI classes for building the user interface. The

differences among these are

● AWT is small and efficient, but not very sophisticated.

● JFC produces a more sophisticated GUI, but will increase the

applet size. This will also restrict the Web browsers to those that

support the JDK 1.1 event model.

Is this a viable option for the pharmacies? Can a suitable browser be

offered for download? Can the Java Plug-in be offered? (The JFC is

distributed with the Java Plug-in.)

3



Data Flow Through The Applet

The applet will need to:

● Convert the GUI object data into TCP socket data.

● Convert incoming socket data into objects.

● Pass objects to a higher layer. Depending on the application server

platform, this layer may have to perform data conversions and

byte reordering.

● Receive incoming socket requests and pass data to a higher layer.

Figure 3-6 shows the design details for the applet.

Figure 3-6 Applet Design Details

Web browser

Applet window<applet code="myapplet"archive=JARfileWidth="x"Height="y">

HTML

Dialog box

Applet frame

3



Class Downloading

Initially, only the classes required for the first screen (the login screen)

will be downloaded. The main loop will process the login and

password, and create a separate background thread to download

remaining applet classes for the next screen layout. The applet should

subsequently create multiple threads to perform time consuming tasks

such as

● Writing to the network using TCP sockets (using the java.netpackage)

● Accessing and displaying on-line help

● Complex graphics and animation

● GUI events (such as mouse and button clicks)

3


Applet Design Elements

Table 3-3 shows the design elements that must be considered when

designing an applet.

Table 3-3 Applet Design Elements

Design Element Considerations

User interface classes Are the Java software classes sufficient, or is there a need topurchase classes (or write one’s own)? The application designershould decide if the components (widgets) of the JDK 1.1 AWT(Swing) are sufficient, or if there is a need to purchase userinterface classes; for example, use a tree panel or a tab panel,similar to those in Microsoft Windows.

Use of components The more customers standardize on a set user interface designusing standardized components such as JavaBeans, the morethey can reuse these parts of the applets. A consistent userinterface also speeds up the learning curve for new users.

Browser or frame Should the applet run inside the browser, or should it bedisplayed in a separate frame? A frame is a Java applet windowthat is external to the Web browser and is managed by the clientplatform’s window manager.

User navigation Is the applet responsible for navigation backwards andforwards (using showDocument() perhaps with frames). Mightthe applet and the browser interfere with each other? Forexample, the user may press the “back” button accidentally.

Applet viewing size What should the height and width of the applet frame be? Dothe users mind scrolling sideways and lengthways if the appletis larger than the screen width? Should the applet be sized to fitthe entire screen? If users run laptops, their screen size will besmaller (this may be a consideration for using a frame that is asbig as the available laptop screen size).

Help Is on-line help needed? Help is usually a requirement forcomplex user interfaces, or for situations where there is no localsupport for the users, as is the case with the pharmacies.JavaSoft JavaHelp™ is an example of an authoring system forproviding help. Other ways are to provide an HTML link to aWeb page.

Internationalizationand localization

These were discussed in Module 2, ‘‘Designing a JavaTechnology Architecture.”

3


Note – Other design features, such as ergonomics, use of pull-down

menus, scroll and tab lists, tree lists, and tool bars are beyond the

scope of this course.

Persistent state Does the applet need to store persistent state? This can be donewith a signed applet writing to the host disk, or morecommonly is done on the server, perhaps using cookies to allowthe applet to reload the correct state information when itrestarts.

Session state Does a group of related applets need to maintain a session stateshared between them, perhaps over multiple Web browseraccesses? There is no explicit support in the applet API forsession state on the client side. However, applets can maintainstate on the server side, for example by using the sessionsupport of the servlet API.

Applet printing Prior to JDK 1.1, printing had to be done from the Web browser.JDK 1.1 introduced applet printing to a network printer. Basic,untrusted applets can send print jobs only to the Web serverhost. If local printing is needed, options include:

• Using third-party products to do local printing.

• Formatting the print as an email attachment (using the“mailto” uniform resource locator (URL) or the mail clientAPI) and sending the email to the user. The user can then savethe report on a local system using email commands. Theadvantage of this method is that it does not involve the Webbrowser.

• Using the printer support in JDK 1.2. If local printing is key tothe applet, this might be an incentive to use JDK 1.2. Such adecision would introduce Web browser dependencies forsupporting JDK 1.2.

Table 3-3 Applet Design Elements (Continued)

Design Element Considerations

3


Applet Rules

Some rules you should adhere to when creating applets are:

● JAR files should be used to download applets. This will minimize

the applet download time.

● Applets should support four-digit years, even on user interfaces.

● Applets that are likely to be used internationally should support

international date formats and currency formats. Printing should

support multiple paper formats.

● Do not use new JDK features unless you are sure of the client

browser support. This might restrict you to JDK 1.0.

● Make sure there are no incompatibilities between the Java JDK 1.1

level that the applet is based on, and the Web browsers that are

being deployed at the client. Test on all possible browser

permutations that might be used (or mandate a browser standard

or the Java Plug-in).

● Size the applet display appropriately in HTML.

3


Applet Rules

● Understand the interaction between the applet and the Web

browser (especially the use of applet-supplied navigation keys

versus Web browser navigation keys).

● Make provisions for dealing with versioning issues with reusable

classes and implement regression testing. If the customer is

considering purchasing user interface classes, this should be done

at a global level, and the classes should be placed in a reusable

repository. The customer should be aware of versioning and

support issues with purchased classes. New versions should be

tested very carefully before being put into production.

Note – Client applets written in the Java programming language can

easily be implemented using multiple threads, so that only the thread

is blocked, not the entire applet. This can help overall throughput in

many situations.

3


Tier Two Design Choices

Table 3-4 shows the design choices to be considered for the new

MedBroker application.

Table 3-4 Design Choices

Tier Two Choices

Design Java application (write your own)Purchased (off-the-shelf) application serverPurchased CORBA server (ORB)Web server with pass-through servlet (later, inphase 2)

Function Check customer detailsDetermine back-end locationTranslate into back-end formatRoute to back-end (using CORBA)Send authorization or rejection to client

Language Java, C++, and other programming languages

Middleware(to tier three)

CORBA

3



If you use CORBA to implement the back-end architecture, you can

implement tier two in a number of ways:

● Develop the application in the Java or C++ programming language.

Since there is no HTTP input to the MedBroker application, there

is no need for a Web server at tier two. Later, when the ability to

access the application over the Internet is added, there will be a

need for a Web server to accept the initial HTTP requests and

download the Java applet to the pharmacies.

▼ The new application must provide client thread support, load

balancing and transaction support.

▼ A just-in-time (JIT) compiler can be used for performance.

3



▼ This application will be mainly input/output (I/O) bound,

receiving requests from the clients, and passing requests to the

insurance companies. The amount of processing performed is

minimal.

▼ Java software would be a more suitable choice since it enables

the eventual use of the Internet.

● Use a purchased application server. Some examples are Sybase’s

Jaguar CTS, Netscape Application Server, Novera, Weblogic

Tengah, or NetDynamics (see Appendix B, ‘‘References,” for a full

list of vendors).

▼ Application servers can connect clients to tier three databases.

▼ Most provide client thread support, client authentication, load

balancing, and transaction support. This removes the need for

the customer to code this functionality.

▼ Many development tools support these application servers and

are able to generate the necessary communications protocols to

tier two. There are many CORBA development tools on the

market, which additionally support Java technology.

▼ Business logic can be implemented as Enterprise JavaBeans

components that plug in to the application server.

● Purchase a CORBA server (ORB). This would offer a pass-through

server only, and only support CORBA services, not the sockets

that are being passed from the MedBroker client.

3


MedBroker Tier Two Design Summary

Trade-offs

The build or buy choice here is often influenced by the customer’s

knowledge base and experience.

● Purchased applications servers can be expensive, but they offer

many services to inexperienced customers. They may include

functions that are not needed for this application. You may have

no control over the performance of such servers.

● A CORBA-only server will not support the TCP socket requests

from the pharmacies.

● A newly created Java application can be tuned to offer the level of

performance required. It can listen on the TCP port number for

incoming client socket transmissions.

3



Trade-offs (Continued)

Based on the availability of Java software support for CORBA,

MedBroker opts to use Java technology at tier two. Configure tier two

as a Java application that uses Java software support for CORBA (Java

IDL).

3



Services to Build into the Application

The following services must be built into the application:

● Client support – It will create a thread to process each request.

● Administration – This enables the application to be started and

shut down. It could also respond to queries about the application’s

status. There are no API provisions in Java technology to do this.

● Logging – Logging is required to persist the request details during

the transaction. (The log can be held in storage and written out to

disk at intervals.)

● Route determination – This will require some kind of persistent

store, such as a file or object database. If it is small enough, the

routing table can be kept in memory.

● Invoking the “object” at tier three via the ORB.

The application server will use Java IDL to access objects residing at

tier three. You must use the JDK 1.2 to develop the application server,

since this contains the Java IDL classes.

3



Note – Since performance of this application is crucial, it can be

compiled using a JIT compiler instead of being interpreted.

3


Java IDL Architecture Overview

Java IDL is an extension to Java technology that allows CORBA IDL to

be mapped to Java applications, and thus allows Java software objects

to communicate with the CORBA objects running at tier three

(Figure 3-7):

Figure 3-7 Java IDL Architecture Overview

Java IDL is part of core JDK 1.2. and is based on CORBA.

● IDL interfaces are mapped to Java software interfaces.

● IDL operations are mapped to Java software methods.

Java IDL provides the ORB runtime for Java technology. Java IDL will

work with any CORBA-compliant ORB. ORB runtimes and object

adapters for the back-end systems must be purchased and installed by

the individual insurance companies. They will also have to register

their objects with the CORBA naming service.

The Java IDL ORB runtime communicates with a counterpart ORB

runtime implemented on each of the back-end servers.

IDL file describesthe services

provided by thelegacy application

Tier two

ORBruntime

Applicationserverthread

Legacy server

ORBruntime

LegacyCOBOL

application

C++wrapper

3


Tier Three Design

Tier three in this case consists of calls to legacy COBOL application

“objects” using CORBA. These legacy applications are not real objects;

they have been “front-ended” with wrapper code written in C++.

Who is responsible for writing the object wrappers?

● MedBroker. This will ensure consistency, however, MedBroker

may have to write (and support) several versions of the wrapper

to run on each of the different platforms.

● The back-end companies. MedBroker could specify the interfaces,

and let the companies build their own wrappers.

While the back-end insurance companies are free to choose an ORB

product, their choices may depend on the language that their legacy

applications are written in.

3


Tier Three Design

There are many ORB products that support C and C++, but fewer

products that support COBOLWhere possible, the same ORB should

be used by MedBroker and the insurance companies, to avoid any

vendor implementation differences regarding naming and other

services.

3


The Final MedBroker Architecture

Figure 3-8 gives an overview of the considerations to be made when

wrapping legacy code with CORBA.

Figure 3-8 Wrapping Legacy Code With CORBA

The architect (or the customer) must work with the insurance

companies to ensure that:

● The “services” offered by the legacy application are abstracted and

defined using the Interface Definition Language (IDL).

● The IDL is compiled on the legacy server and linked with the

legacy code. This can happen by calling legacy libraries, or, in

some cases, compiling the legacy code directly into the skeletons

created by the IDL compiler.

DOS andturnkey

platforms withexisting

application

Applet orpre-loadedapplication

Web browserwith applet

OldMedBrokerapplication

Javaapplication

(JIT)

Web server

ORB

Back-endapplicationand objectwrapper

X.25

TCPsocket

TCPsocket

Call

Networkinfrastructure



RMI

ORB

ORB

ORB

IIOP

Servlet

3


The Final MedBroker Architecture

● On the client side, the same IDL is compiled to the desired

language, such as the Java programming language, and the client

application can make calls to the methods that represent the legacy

services.

● The ORB runs as a batch job or started task on the mainframe.

Some ORBs provide adapters that connect to IBM CICS or IMS

programs directly.

Note – Each ORB needs to be tested with the MedBroker application.

3


Exercise: Design a Heterogeneous Object Architecture

Exercise objective – Recommend a high-level distributed architecture

for a customer situation. Discuss your proposed architecture with the

customer (in this case, the other students).

Preparation

In order to complete this exercise, you must

1. Read the customer’s requirements and constraints detailed in

‘‘Module 3 Case Study’’ on page A-8 in Appendix A, ‘‘Case

Studies.” Detailed instructions for completing the exercise can

also be found here.

2. Read and familiarize yourself with the case study before you go

into your small groups. If you have any questions, please ask the

instructor for clarification.

3


Exercise: Design a Heterogeneous Object Architecture

Exercise Summary



● Experiences

● Interpretations

● Conclusions

● Applications

3


Check Your Progress



❑ Given set of business requirements, design a multi-tier, object-

oriented application architecture

❑ Design a detailed architecture that includes Java applet and

application server designs

❑ Compare a distributed Java technology architecture with the OMG

CORBA and Microsoft alternatives

❑ Discuss the benefits and disadvantages of these distributed

architectures for a set of customer requirements

3


Think Beyond

At your customer presentation, you were asked the following

questions. How would you respond?

● Can I use Java technology with SAP and Peoplesoft?

● Does the Java IDL implementation in JDK 1.2 allow Java software

classes on a client to communicate with Java software classes on a

server without the use of a third-party ORB?

● Are there any CORBA ORBs that support HTTP tunneling without

other components being present at the client side?


IntegrationWithExistingApplicationsandDatabases 4

Course Map

This module focuses on the third tier of the Java application

architecture, and how a Java application can be seamlessly integrated

into this tier.

Basic Principles



Foundation


Advanced Principles






Deployment


4


Relevance

Discussion – With most of a company’s useful data residing in legacy

databases and files, many Java software architectures will need to

incorporate legacy systems as the back tier. In fact, providing a Web

“face-lift” to access legacy data is a common need. Some questions you

might be asked include:

● How can I use Java technology without removing my current

environment?

● Why should I move to Java technology on the server side?

● How can I access my IBM CICS on-line system by using the Web?

● How can I access my IBM Information Management System (IMS)

databases by using the web?

● How can I access legacy files by using the Web?

● What is the difference between JDBC and ODBC?

● How scalable is a solution with JDBC?

● Can a solution with JDBC provide native performance?

● How do you select a JDBC product?

4

Integration With Existing Applications and Databases 4-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Design a multi-tier Java application architecture where the third

tier is an existing application, file, or database

● Design a detailed architecture for integrating Java technology with

existing databases and applications

● State the advantages and disadvantages of using screen scrapers to

access applications at tier three

● State the advantages and disadvantages of using object mapping

for legacy system access

References



● Hamilton, Graham, Cattell, R. G. G., and Fisher, Maydene. 1997.

JDBC Database Access with Java: A Tutorial and Annotated Reference.

Addison-Wesley.

● Reese, George. 1997. Database Programming with JDBC and Java.O’Reilly.

● Schneider, Jeff and Arora, Rajeev. 1997. Using Enterprise Java. Que

Corporation.


4


Tier Three of the Architecture

Interfacing With Tier Three

The third tier of the architecture may consist of databases, files, and

applications that are typically not object oriented. The architect must

define the architecture such that it incorporates these elements. The

architect should work closely with the customer’s data, network, and

security architects to define architectures that provide access to

existing systems (Figure 4-1).

Figure 4-1 Tier Three of the Java Software Architecture

The architect must be aware of the existing interfaces to these

databases, files, and applications—some of these interfaces may be

proprietary or undocumented.

Back-end systems

RDBMS

Mainframeapplications

File

Mainframedatabases

Javaapplication orservlet

Java appletorWeb page

Proprietaryinterface

Proprietaryinterface

Undocumentedinterface

SQL

4



Constraints

The architect must consider any constraints that exist in the existing

legacy system application architectures; for example:

● Finely tuned transaction processing systems, such as reservations

systems, could be adversely affected by the additional workload

from the new Web-based application. Is there an alternative

approach, such as to convert the data to a separate RDBMS which

can be used by the new application?

● Maintenance schedules for legacy applications might conflict with

the new Web-based architecture. Examples might be modifications

for Year 2000 and the European currency that are on a different

timeline than the new application.

4



Common Integration Techniques for Tier Three

Databases, files, and applications at tier three can be accessed in a

variety of ways using:

● JDBC. JDBC is used to access relational databases at tier three.

Non-relational data can be converted (or extracted) to a new

relational database, or accessed through database middleware

gateways which map to and from the relational model.

Note – JDBC will be discussed further in this module.

4



Common Integration Techniques (Continued)

● Object wrappers. Object wrappers allow access to non-object-

oriented applications using CORBA IDL. This is the most seamless

approach from an architectural and a programming perspective.

However, this involves placing new code (the wrapper code) on

the existing production system.

Note – Object wrappers were discussed in Module 3.

● Published or standard programming interfaces. Another way of

accessing non-object-oriented applications is to use well-defined

interfaces that are supported by the application; for example, TCP

sockets or IBM’s APPC (LU6.2). Java applets, applications, and

servlets support TCP sockets directly. The use of IBM’s LU6.2 may

involve the use of native code in the Java software application

architecture.

● Screen scrapers. Screen scrapers are third-party products that

convert the screens of data that the legacy application produces as

output into a GUI format which can be displayed in a Java applet

or Web browser.

4


Existing Network Considerations

The existing applications, databases and files may or may not be

accessible using TCP/IP, even if there is TCP/IP support on the

platform.

The architect may need to specify gateway software and hardware to

convert between TCP/IP and the existing communications protocols.

● Application-level gateways convert at the transport layer. For

example, IBM’s AnyNet software enables IBM LU6.2 applications

to run over IP instead of SNA. Sun’s SunLink™ software supports

LU6.2 over IP.

● Network level gateways convert lower level network protocols

such as Token Ring to Ethernet. For example, Sun’s SunLink

gateway provides Ethernet to Token Ring or IBM SDLC

conversions.

4


Existing Network Considerations

Figure 4-2 shows the use of gateways to convert to the protocols used

by legacy systems.

Figure 4-2 Tier Three Network Considerations

Back-end systems

RDBMS

Mainframeapplicationsanddatabases

File


Java appletorWeb page

TCP/IP

SNA

NetBIOSGateway

SNA = Systems network architectureNetBIOS = Network basic input/output system

4


Dynaclaim Architecture

Figure 4-3 shows the Java application architecture proposed for

Dynaclaim in the Module 3 case study exercise.

Figure 4-3 Proposed Java Application Architecture for Dynaclaim


AgentSmalltalkclient

:CORBAgateway

:Domain(Java)

:Dataaccessor(Java)

:QuickQuote(Smalltalk) :Email

server

:Web Server

GUI

:Formatter(Java)

SMTP

:Servlet

IIOP

:Application Server

JDBC

Customerclient(applet)

GUI

HTTP

JRMP

Smalltalk toJava

:Faxserver

IMSactuarialdata

Extract

Quotequeue

4



Tier three consists of three data sources:

● The QuickQuote temporary queue. This has been architected as a

new relational database, accessed from a Java application using

JDBC. In this case, a relational database was chosen to store the

QuickQuote queue because they are common and readily

available, the customer’s experience with relational data (DB2),

and the ease of access from both to a Java application and

Smalltalk.

● The customer information stored in an IBM DB2 relational

database. This can be accessed using JDBC.

4



● The insurance data stored in an IBM IMS hierarchical database.

Since there is no direct Java API to the IMS database, the architect,

together with the customer’s data architects, must decide on an

optimal access strategy:

▼ Extract relevant data to a new RDBMS. This is the option

chosen for this case study.

▼ Use Java native calls (JNI) to a mainframe C or C++ program

that accesses the IMS database.

▼ Provide an object wrapper to the mainframe program and use

CORBA (Java IDL).

Note – The tier two platform must support the required networking to

access tier three—in this case, IBM’s SNA—or use a gateway that

converts to SNA. If the tier two server is a Solaris platform, the Sun

SunLink hardware and SunLink Peer-to-Peer runtime software

provides this connectivity. Alternately, some multi-protocol routers

(Cisco, Bay Networks, or 3Com) provide SNA to TCP/IP conversion

in the network.

4


Standard Tier Three Access Mechanisms

Comparing Access Mechanisms

Table 4-1 compares the access to various tier three sources that are

commonly found in Java application architectures: relational databases

such as IBM DB2, the IBM transaction monitor (CICS,) and the IMS

hierarchical database.

Table 4-1 Common Tier Three Access Mechanisms

RelationalDatabase IBM IMS DB IBM CICS

Access mechanism SQL Proprietaryread/write

Proprietaryread/write

Published API X/Open CallLevel Interface(CLI)

IBM DL/I calls IBM ECIIBM EPI

Java applicationaccess mechanism

JDBC No (only JNI) IBM CICS Gatewayfor Java technology(uses external callinterface [ECI] andexternal presentationinterface [EPI] to tierthree)

Object interface Object-relationalmappingproducts

IMS ObjectConnector (CORBA)

IBM ComponentBroker Connectorproduct (CORBAORB)

4



Relational Databases

JDBC is the preferred mechanism for Java applications and servlets to

access relational databases. JDBC will be discussed next in this

module.

IMS Hierarchical Databases

IMS Object Connector is a product from IBM that allows C++

programs access to IMS data. IMS Object Connector translates Data

Manipulation Language 1 (DL/I) segments (records) into C++ classes.

CORBA is used to communicate with the IMS system. There is no Java

software support for this product.

4



CICS Transactions

IBM CBConnector is CORBA ORB from IBM that allows CORBA

objects to access CICS transactions.

IBM CICS Java Gateway is written in the Java programming language

and allows a Java application to access CICS transactions without

CORBA. There are two high-level APIs to CICS transactions:

● External Call Interface (ECI) allows an external application to call

a CICS transaction.

● External Presentation Interface (EPI) allows an external application

to start a CICS transaction and receive IBM 3270 terminal data (as

though it were a real 3270 terminal).

4


The JDBC API

JDBC Connection Structure

JDBC is the recommended API for relational database access from Java

applications. JDBC is patterned on the X/Open Group’s CLI which

allows applications to access relational data using SQL statements

(Figure 4-4).

Figure 4-4 JDBC API

The JDBC API provides a database-neutral interface for Java

applications. The API calls the Driver Manager class, passing it a URL

string which identifies the required database. The JDBC Driver

Manager calls the driver for the required database.

Note – A database driver compliant with JDBC is needed for each

database product.


Applet

JDBCDrivers andDriverManagerprovidesConnection

DB2driver

Oracledriver

Sybasedriver

JDBC


JDBCConnection

4


The JDBC API

JDBC Architectural Details

JDBC is a client-server implementation. The client is usually a Java

application or servlet running at tier two. JDBC requires the following

to be installed on the client platform:

● JDBC driver manager. The driver manager is part of JDBC and is

used to set up the connection to the driver. The driver manager

allows for multiple drivers to connect to different vendor

databases. The customer can effectively “swap” database vendors

without changing any code in the Java application. Once the

connection is established, the driver manager is not involved in

the ongoing communications.

● One or more JDBC drivers. A JDBC driver is obtained from a

database vendor or software solution vendor. The driver is written

to the published JDBC specified interface.

4


The JDBC API

JDBC Architectural Details (Continued)

Note – There is a trend towards using the Java programming language

as the language of stored procedures. This will improve the current

situation with stored procedures which is that they are highly database

specific. Since stored procedures can be very fast (they are close to the

data, and can use many optimizations), this will be very valuable.

4


JDBC Object Overview

Each call to the JDBC API uses three objects (Figure 4-5).

Figure 4-5 JDBC Object Overview

These objects are

● A database connection object (for the JDBC driver).

● A statement object. The SQL query is pre-defined in this object but

can be dynamically altered when the statement object is executed.

When a statement is executed, a result set object is returned.

● A result set object. The result set is a vector object (array) that has

a cursor or pointer to the current row of data in the result set.

Note – To retrieve data from the result set object, you must be familiar

with the database schema (that is, the columns and their data types).

JDBC provides facilities for accessing the database schema (metadata).

DriverManager

DriverDriver

ConnectionConnection

Statement

ResultSet

Connection

StatementStatementStatement

ResultSetResultSet

JDBC API

4


JDBC and SQL

The statement object contains the SQL syntax that is passed to the

database. JDBC provides full support for SQL. SQL can be dynamic,

prepared, or callable.

● Dynamic SQL is not precompiled. The SQL is created at runtime.

Dynamic SQL is typically used for ad-hoc queries, where the SQL

content is not known in advance.

● Prepared SQL is precompiled. Usually, the skeleton of the syntax is

hard coded and precompiled, with any dynamic information

inserted at runtime. Precompilation cuts down the SQL syntax

error rate at runtime, and is faster to execute. If the same SQL

statements are going to be executed multiple times, it is more

efficient to use precompiled SQL instead of totally dynamic SQL.

4


JDBC and SQL

● Callable SQL invokes a call to a stored procedure on the database.

A stored procedure is a piece of code that is stored in the database,

and executes on the database server. Stored procedures are usually

written in a language proprietary to the database vendor.

The result set object has a pointer (cursor) to a series of rows and

columns that are returned from the database. The rows are received in

order. The Java application advances the cursor to the current row of

data by calling the next() method.

Note – JDBC 2.0 (part of JDK 1.2) adds additional functionality to

JDBC, such as improved database cursor support (scrollback).

4


JDBC Driver Types

JDBC drivers fall into one of the four categories outlined in Table 4-2.

Table 4-2 JDBC Driver Types

Type Suppliedby Features

1.JDBC-ODBCbridge(customermust acquireODBC driver)

• JavaSoft(usedwithvendorsuppliedODBCdriver)

• Bridge is database independent. Can access any databasethat has ODBC support (including non-relationaldatabases).

• Least efficient—has to go through both JDBC and ODBC.

• Requires JDBC manager, JDBC-ODBC bridge, ODBCmanager, and ODBC driver on the client side.

• Requires a different ODBC driver for each database.

2.Native APIdriver(partly Javasoftware)

• Populardatabasevendors

• Weblogic

• Driver is database specific.

• Driver converts JDBC to native proprietary databasecalls (for example, Oracle CLI or Sybase Open Client).

• Good performance.

• Requires JDBC manager, JDBC driver, and nativedatabase libraries on client.

• Requires different native driver for each database.

3.JDBC Net-protocol driver(Java software)

• Populardatabasevendors

• Weblogic

• Driver is written in the Java programming language.

• Driver is database independent—all drivers use thesame protocol from client to server.

• JDBC manager, JDBC driver, and native databaselibraries on tier two.

• Scalable—optimal driver for three-tier architectures.

• Driver converts JDBC to native proprietary databasecalls (for example, Oracle CLI or Sybase Open Client).

• Access to multiple back-end databases using databasegateway products.

4


4.Nativeprotocol driver(Java software)

Populardatabasevendors

• Driver is written in the Java programming language.

• Driver is database specific.

• Driver converts JDBC to native proprietary databasecalls.

• Good performance.

• Requires JDBC manager, driver and native databaselibraries on the client side.

Table 4-2 JDBC Driver Types (Continued)

Type Suppliedby Features

4


JDBC Driver Selection

The differences among drivers are more apparent when the client

issues the JDBC call directly. For a three-tier architecture, the JDBC call

can be issued from tier two (Figure 4-6).

Figure 4-6 JDBC Driver Selection

Clientapplet orapplication

RDBMS

Javaapplication,servlet, orEnterpriseJavaBean

Type 1 – JDBC and ODBC drivers and database libraries on clientType 2 – JDBC and database libraries on clientType 3 – JDBC on client, database libraries on tier twoType 4 – JDBC and database libraries on client

Type 1, 2, and 4 Type 3

4



As illustrated in Figure 4-6, you should

● Evaluate and assess the database, unless the customer has a

standard DBMS in-house.

● Determine if the DBMS vendor supplies a JDBC driver.

▼ If so, what type is it? Type 3 is best for three-tier architectures

that are implemented with only Java technology on tiers one

and two. Type 4 is best for companies that have standardized

on a DBMS vendor (it offers native performance).

▼ If not, evaluate third-party drivers.

4



● Examine the drivers. If there are no vendor-supplied or third-party

drivers, you can

▼ Purchase a database gateway product that has a JDBC driver

and mappings for the target database. Database gateways

perform mapping of non-relational databases and files to

relational data. These products also enable concurrent access to

multiple files and databases, with the resulting “joined data”

image returned as a temporary relational table.

▼ Use a JDBC-ODBC bridge.

▼ Evaluate alternate ways to interface to the data source (object

wrappers, native code, or published APIs such as sockets and

IBM LU6.2).

▼ Evaluate alternate ways to store the data (object database

management systems [ODBMSs]).

For scalability and performance, type 2, 3, and 4 JDBC drivers are

better. For maximum portability, type 3 and 4 are better (since they are

written in the Java programming language).

4


Two- and Three-Tier JDBC Designs

Discussion – JDBC drivers can be built on the client tier or on tier two.

Tier-one clients can use downloadable JDBC drivers that do not

require any client-side configuration.

What are the advantages of a three-tier JDBC architecture where the

drivers reside on tier two?

4


Other Database Architectural Considerations

Database Performance Considerations

Each client request to the database first requires a connection be

established to the database system. An RDBMS can support only a

finite number of concurrent open connections, so, as the number of

clients increases, there may be performance delays in waiting for

connections to become free (Figure 4-7).

Figure 4-7 Database Performance Considerations

Since the establishment of a new connection is quite an overhead in

terms of processing, it makes sense to try to keep the connection

permanently open. For this to work, there must be a scheme to sharethis database connection among multiple clients. This can be done

using only a three-tier JDBC architecture (tier two does not have the

transient nature of an applet so it is able to open a database connection

and keep it open across requests).

Applicationserver

Appletclients

JDBC RDBMS

Connectionpool

Continuous open connection

Multiple connections areopened and closed

Client requeststo database

4



Connection Pool

A connection pool multiplexes client requests to an already opened

database connection, thus reducing the total number of open

connections.

● Connection pooling is usually provided by purchased application

servers, and should be one of the criteria for product selection.

● Connection pool classes are available for purchase by customers

who write their own applications.

● Connection pools are implemented with some JDBC drivers.

● Connection pooling is provided for Enterprise JavaBeans.

4



Connection Pool Processing

The connection pool opens a fixed number of database connections at

start up. When the server is processing a client request to retrieve or

store data, it asks the pool for a free connection. Once the database

transaction is complete, the server should release the connection back

to the pool so that it can be re-used by another thread or server.

Note – Client requests that are multiplexed to the same connection

must share common characteristics such as data access authorizations.

4



Database Abstraction

JDBC requires that the programmer who is developing the application

or servlet understand SQL and the database schema. (The programmer

must write code to translate the object into SQL statements.)

Database abstraction techniques hide the relational nature of the data

and provide an object view of the data. These techniques provide

mapping between object and relational formats (Figure 4-8).

Figure 4-8 Database Abstraction

Note – Pure object databases also abstract the access to data and are

easier to administer than an RDBMS. However, object databases are

not as flexible as RDBMSs for storing purely alphanumeric data.

Java applet

Javaapplication

server

Abstractionlayer

JDBC driver

Object

RDBMS

SQL

Object/relationalmappings

Javadeveloper

system

Runtime

Development

RMI

4



Database Abstraction (Continued)

In Figure 4-8, the Java applet requests an object from the application

server. The application server does not use JDBC directly; it simply

passes the request to the abstraction layer that sits on top of JDBC and

does the mapping from object class to relational table and from

relational table back to object class.

With Java technology, objects can also be persisted in a relational

database and retrieved by programmers using pure object access.

Some considerations for database abstraction are

● In Java technology, classes must be mapped to relational database

tables. The complexity of this mapping depends on the nature of

the application.

● Complex database queries are often easier to understand using

SQL.

● If the relational database schema changes, the mappings must be

re-created.

Consult Appendix B, ‘‘References,” for a list of products that

implement database abstraction.

4


Alternative Data Access Mechanisms

If there is no JDBC driver available for the data source, architects must

investigate other alternatives, such as

● Accessing the data using Java JNI calls to a native program; for

example, a mainframe COBOL program that issues IBM DL/I calls

to an IMS database

● Using a screen scraper

● Converting the data to a format that supports Java technology

4


Access Using a Native Program

Java Native Interface (JNI), part of JDK 1.1, provides a standard Java

software interface for calling procedures or functions (code) that are

written in languages such as C and C++. JNI provides mapping

between the Java programming language character types and native C

and C++ types.

JNI is used to access tier three data from existing applications that

employ proprietary APIs not supported by Java technology. JNI can

also be used to access vendor product libraries that provide their own

interfaces to data. In Figure 4-9, two uses of JNI are shown.

Figure 4-9 How JNI Can Be Used

The top example in Figure 4-9 shows how using native code can be

used to access a mainframe COBOL application using peer-to-peer

IBM LU6.2 communication.

Javaapplet

Javaapplicationor servlet

IBM COBOLapplication

CICSgateway forJava

CICSclient

IBM CICSserver

IBMIMS database

IMSobjectconnector

JNI

Code notwritten in theJavaprogramminglanguage

LU6.2 orsocket

JavaRMI

Code notwritten in theJavaprogramminglanguage


4


Access Using a Native Program

The middle example shows how native code can be used to access a

mainframe IMS database using IBM-supplied object connector which

has a C++ interface but no Java software interface.

The bottom example shows Java application access to an IBM

Customer Information and Control System (CICS) transaction. In this

case, IBM has supplied Java application access (the CICS gateway for

Java technology). There is no need to use native code.

4


Java and Native Methods

Discussion – A native method is a Java software method (either an

instance method or a class method) whose implementation is written

as a function in another programming language. The native method

resides in a different source file that must be accessible to the Java

software code. How would you answer the following questions?

1. Why should JNI not be used by applets?

2. What advantages does JNI offer?

3. Why would there ever be a need to call Java software from a

native C or C++ program?

4


Screen Scraping

Screen scraping is a seamless way to provide a GUI for a legacy

application. When the legacy application has only a terminal interface,

this may be the only way to integrate the application with Java

technology and the Web.

In a three-tier design, the client does not access the legacy application

directly. It connects to a tier two application which in turn provides the

screen scraping functionality to the tier three application. Screen

scraping can be used to access Windows NT and UNIX applications as

well as mainframe applications (Figure 4-10).

Figure 4-10 Screen Scraping

Web client

Webserver

Applicationorservlet

Mainframeapplications

Windows NTapplications

Digital VMSapplications

UNIXapplications

Screenscraper

SNAor TCP/IP

SMB,TCP/IP orSPX/IPX

TCP/IP

DECNetorTCP/IP

HTTP

RMI or ownprotocol


IPX = Internetworked packet exchangeSPX = Sequenced packet exchangeSMB = Server message block

CGI

4


Screen Scraping

Note – The screen scraper uses the protocols of the target application.

The tier two platform must provide the underlying network

connectivity for these protocols.

The screen scraper connects to the target application, which runs as

normal. The returned data is intercepted and forwarded to a Java

applet or to a Web browser. The advantage is that the target

application is not affected; however, mapping of screen output to Java

AWT objects must be pre-established for each target application.

If a GUI is presented by a screen scraper, then part of the screen

scraper product resides on the client.

Refer to Appendix B, ‘‘References,” for a list of screen scraper vendors.

4


Assessing Screen Scrapers

Advantages and Disadvantages

The major benefit of screen scraping is in providing a graphical user

interface to an existing application with no disruption to the

application. Screen scrapers eliminate the need to split the application

presentation and business logic, which may be too difficult for legacy

applications.

The downside is that there is no enhancement of application

functionality. Table 4-3 lists the advantages and disadvantages of

screen scraping.

Table 4-3 Advantages and Disadvantages of Screen Scrapers

Advantages Disadvantages

Provide instant GUI for legacyapplications

Terminal upgrade needed (mayinvolve rewiring)

Provide extra functionality toterminal users (Web, Internetaccess)

No enhancement to basicapplication functionality

Can reformat original screen to newGUI layout

Involves work to map terminalfields to GUI elements

Users can access multiple legacyapplications from one clientplatform instead of having to usemultiple terminals

No enhancement to any applicationfunctionality

Imposes no administrationoverhead on client platform

Need to maintain mappings iforiginal screen layout ever changes.

Can implement with no disruptionto legacy applications

Processing overhead of conversionat tier two

No direct connectivity tomainframe needed on client

Requires connectivity to mainframeat tier two

Minimal user training since thescreen is scraped; may needtraining to use simulated keys

No re-engineering of the originalapplication is possible

Error handling can be difficult

4



Performance Issues

The biggest issue for screen scrapers is how they perform.

Performance issues include:

● Network usage. Much more network traffic will be generated (due

to the GUI).

● User response time. Users of terminal-based applications become

very proficient with time. Changing their user interface may

reduce productivity (at least temporarily). The screen scraper

product should provide Web-based users with the ability to use

menu shortcuts, type-ahead support, and mouseless operation in

order to increase their productivity.

4



Performance Issues (Continued)

Note – The performance of an application architecture that uses screen

scraping must be understood well in advance, perhaps through the

use of a prototype and a stress testing tool. What is the implication of

having a middle tier between the client and the target application?

What is the performance implication of introducing a GUI? For highly

interactive applications that need sub-second response times, screen

scraping may not be viable.

From an architectural perspective, screen scrapers should be used as

an interim step to eventually redesigning and rewriting the

application. Screen scrapers should not be recommended where sub-

second response times are needed (the extra tier cannot meet that).

4



You may be asked to assist the customer in selection of a screen

scraper product. Selection criteria includes:

● Does the product allow for a new GUI to be designed in Java

technology instead of just displaying the screen data in its original

“look-and-feel” within a window? Can it merge screen outputs? A

Java applet can maintain a session with the emulator (this might

consist of several screen interactions making up a single

transaction on the mainframe).

● What performance and monitoring tools are provided (or

available) for the product?

● How many client sessions are supported?

4



Selecting a Screen Scraper Product (Continued)

● Does the product support the full range of terminal keys (for

example, all 24 IBM program function keys [PFKeys])? How is this

emulation done—if the user must type in a sequence of characters

to simulate the key, this could affect that user’s typing rate and

thus lower productivity in high-response applications.

● Does the product support both key and mouse entry forms? If it

allows only mouse entry, the productivity of some users might be

affected whenever they have to reach away from the keyboard to

use the mouse.

● How does the product implement X-hosting for UNIX

applications? The X protocol produces a lot of network traffic as

data is passed to the X-server (normally located on the display

device, but in the case of an emulator located on tier two). Does

the emulator use the X.11 or the lightweight Intelligent Console

Architecture (ICA) protocol? (ICA uses less bandwidth.)

● Will the product provide the required response time for the

anticipated number of users with the customer’s network

configuration?

● Does the product provide any added value to users?

4


Evaluating Alternate Architectures for QuickQuote

Review of Current Architecture

The database architecture that was designed for the Module 3 case

study solution is depicted in Figure 4-11.

Figure 4-11 Completed Three-Tier Architecture for QuickQuote


AgentSmalltalkclient

:CORBAgateway

:Domain(Javatechnology)

:Dataaccessor(Javatechnology)

:QuickQuote(Smalltalk) :Email

server

:Web Server

GUI

:Formatter(JavaTechnology)

SMTP

:Servlet

IIOP

:Application Server

JDBC

Customerclient(applet)

GUI

HTTP

JRMP

ConnectSmalltalk toJavatechnology

:Faxserver

IMSactuarialdata

Extract

Quotequeue

4



Alternate QuickQuote Database Architectures

As with many applications, the requirements can be solved with

multiple architectures involving different types of objects interfaces

and protocols (refer to Table 4-4).

Alternatives to an RDBMS for the QuickQuote queue are:

● Message queuing middleware. This would provide the disk queues

and integrity for temporarily storing data.

● Object database. Object database management systems (ODBMSs)

store objects in their original format (encapsulated data and

methods). This is also true for the object model—the data can be

viewed as part of the application.

Table 4-4 Different Architectures, Object Interfaces, and Protocols

PersistenceMechanism Message Queue RDBMS ODBMS File

Accessmechanism

Proprietary API(vendor)

SQL (InternationalOrganization forStandardization[ISO] standard)

Objectquerylanguage(OQL)

Programread/write

Published API Vendor X/Open call-levelinterface (CLI)

No No

Javaapplicationaccess

Java applicationmessaging API orJava technologysupport bymessaging vendor

JDBC RMI,CORBA,OQL

Javaapplicationfile input/output(I/O)

Ad hoc query No Yes Yes (OQL) No

4



Using Messaging for QuickQuote Persistence

By implementing the QuickQuote queue as a messaging queue, you

gain some advantages over a relational database:

● The queue will be managed by the messaging product. A database

administrator (DBA) is not required.

● You do not have to define a database schema. However, you do

have to define the message content structure.

● Messaging guarantees that the message arrives at its destination.

● Some messaging products provide priority messaging. If the

customer needed an urgent quote in five minutes, for example, the

request could be expedited.

● Some messaging products provide a tracking and alerting

mechanisms. If a message that is put onto the queue is not

retrieved within the deadline for quote turnaround, an alert can be

sent to the agent’s manager.

4



Using Messaging for QuickQuote Persistence (Continued)

● Some messaging products provide an automatic filtering

mechanism so that agents see only the quote requests that they are

qualified to process. This filtering can be done when the request is

initially created.

● Messaging can be used by disconnected clients. Agents can log in

to the system, pick off their pending requests, and store them on

their machine. They could then log out and process the requests in

disconnect mode. In this case, they still need access to other data

from tier three.

● Messaging can be used to integrate mainframe systems that do not

require real-time access. For instance, the access to the DB2

customer database could return the data as a message queue,

which could be picked up by the agent in near real-time.

See Appendix B, ‘‘References,” for a list of messaging vendors.

The Java Messaging Service API will provide a generic Java software

interface to messaging products.

4



Using an ODBMS for QuickQuote Persistence

ODBMSs are more natural in an object-oriented application

environment. An ODBMS will be faster for storing pure objects,

compared to mapping those objects into relational form.

A trend in the market is for application servers to have built-in

ODBMSs.

RDBMS can store objects a binary large objects (BLOB) fields. The

BLOB is stored separately in the RDBMS with a pointer to the BLOB

stored in the table column. The application has to interpret the

contents of the BLOB.

With an ODBMS, the application references the object using types.

The considerations that should be evaluated when deciding among an

RDBMS, an ODBMS, and object/relational mapping are shown in

Table 4-5 on page 4-49.

4



Using an ODBMS for QuickQuote Persistence (Continued)

Table 4-5 Use of RDBMS, ODBMS, and Object/Relational Mappings

Use RDBMS if Use ODBMS ifUse object/relationalmapping if

• Data is already stored aslegacy data

• Data is primarilyalphanumeric andaccessed that way

• Large volumes of dataare needed

• Rapid scalability isanticipated (RDBMSshave proven scalability)

• Data is accessed andupdated as transactions

• Ad hoc query is needed(there are RDBMS toolsfor ad hoc queries)

• Customer wants to staymainstream(conservative)

• Data needs to be accessedby non-object-orientedapplications

• You need to store Javaapplication and other objects

• You purchased applications areintegrated with an ODBMS

• Customer is willing toexperiment

• No ad hoc query is needed (OQLis emerging as a query standardfor ODBMSs, but there are fewtools)

• Complex objects need to bestored and retrieved quickly (forexample, non-alphanumericdata, graphics, and so on)

• Java software access is providedby the ODBMS vendor

• Data is accessed only by object-oriented applications

• Versioning of objects is required

• Programmers needto access relationaldata in an object-oriented way

• Programmers donot know SQL

• Data access doesnot involve joinsfrom separatetables

4


Summary of Alternatives

Thus, your alternative solutions for the customer are as follows:

● ODBMS. ODBMS may be inappropriate for the QuickQuote

queue, since the data is alphanumeric, and there is a need to

provide ad hoc query support. However, if Dynaclaim wanted to

store photographs of cars and houses to attach to the customer’s

policy details, an ODBMS would be more appropriate.

● Message queue. The issue for messaging is lack of ad hoc,

synchronized query support (such as SQL). If there is an eventual

need to allow customers to check out the status of their requests,

this would be difficult to accomplish as a query.

● RDBMS. RDBMSs have a standard access mechanism (SQL) and

also support ad hoc queries, as well as being supported by many

reporting and query tools.

4


Exercise: Designing a High-Level Three-Tier Architecture

Exercise objective – Respond to a set of customer requirements and

determine the best way to migrate the application to Java technology.

Discuss your proposed architecture with the customer (in this case the

other students). This activity is intended to get you used to the idea of

communicating with customers in an informal manner; for instance,

using a whiteboard to propose a basic three-tier Java technology

solution.

Preparation

To complete this exercise successfully, you must accomplish the

following tasks:

1. Read the customer’s requirements and constraints detailed in

‘‘Module 4 Case Study’’ on page A-15 in Appendix A, ‘‘Case

Studies.” Detailed instructions for completing the exercise can

also be found here.


into your small groups. If you have any questions, please ask the


4


Exercise: Designing a High-Level Three-Tier Architecture

Exercise Summary



● Experiences

● Interpretations

● Conclusions

● Applications

4


Check Your Progress



❑ Design a multi-tier Java application architecture where the third

tier is an existing application, file, or database

❑ Design a detailed architecture for integrating Java technology with

existing databases and applications

❑ State the advantages and disadvantages of using screen scrapers to

access applications at tier three

❑ State the advantages and disadvantages of using object mapping

for legacy system access

4


Think Beyond

So far you have looked at Java software architectures that have been

constrained by the need to fit into existing application and data

environments.

Imagine a customer that has a set of requirements for a brand-new

application with no such dependencies:

● How would the architecture differ from the architectures that you

have looked at?

● What are the rules for creating a new application?


CreatingNewApplicationArchitectures 5

Course Map

This module looks at the options for creating new Java application

architectures.

Basic Principles



Foundation


Advanced Principles






Deployment


5


Relevance

Discussion – As a Java technology architect, you may be asked to:

● Evaluate the suitability of Java technology for a set of new

customer requirements

● Assess existing customer applications for the purpose of migration

to Java applications

While most requirements and applications will be suitable candidates,

some should not be architected for Java. What rules are used to help

determine application eligibility?

Given the freedom to create an application from the beginning, where

do you start?

5

Creating New Application Architectures 5-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Recommend a migration strategy for an existing application

● Design a multi-tier architecture using Enterprise JavaBeans

● Describe how Java technology can be used for transaction

processing

● Discuss alternative Java technology architectures, such as publish

and subscribe

● State the advantages and disadvantages of partial migration using

Java applets and applications

References



● Orfali, R., Hashley, D., and Edwards, J. The Essential DistributedObject Survival Guide. Wiley. 1996.

● Thomas, Anne. Enterprise JavaBeans Server Component Model forJava.Patricia Seybold Group. December 1997. [Whitepaper].


5


Qualifying the Application for Java Technology

The application you are about to design may be brand new, or may be

being migrated. Before you start, you should pre-qualify the customer

and the application for Java technology readiness.

There are many ways to decide if the project is an appropriate

candidate for Java technology, but one approach may be viewed in

three aspects. These will be described as being sequential, but you

need not treat this as inviolate. The aspects are

● Attitude and infrastructure

● Qualify the third-party product

● Qualify the existing application

● Java technology applicability

Attitude and infrastructure are about determining if the client is

willing to use Java technology, and if they have, or it is appropriate for

the client to buy the necessary infrastructure (such as TCP/IP

networking).

Qualify the existing application is applicable only if this project

involves extending, modifying, or updating in some way, an existing

system. You will need to ensure that there are no constraints in that

system that effectively prevent the use of Java technology. If you do

find such constraints, you might be able to aim for a compromise

solution, using Java technology for some aspects of the system, but not

for others.

Java technology applicability is a final check to ensure that the project

itself does not have technical requirements that make Java technology

unsuitable. Such situations are extremely rare, and usually arise only

in high speed real-time control, and when writing device drivers.

Because such situations are relatively rare, this category is left to last.

However, if you recognize situations of this sort at a first meeting, you

might well not proceed with the first stages, or proceed with a

modified plan.

Figure 5-1, Figure 5-2, Figure 5-3, and Figure 5-4 on the following

pages show flowcharts that describe the main questions you should be

asking yourself when checking each of these aspects.

5



Qualifying Attitude and Infrastructure

Figure 5-1 Qualifying Attitude and Infrastructure

Does thecustomer

already haveJava

technology?

Does the customerhave political

objections, evenafter persuasion

Does thecustomer have

the requiredinfrastructure?

Note: If going ahead, recommendtraining and/or consultancy

Note: If goingahead,

recommendappropriate

infrastructure

Can the customerjustify cost of the

requiredinfrastructure?

Yes

No

Yes

Yes

Yes

No

No

No

Do notrecommend

Javatechnology

Go to:“Qualifying the Third

Party Product”or

“Qualifying theExisting Application”

or”Java Technology

Applicability”

5



Qualifying the Third Party Product

Figure 5-2 Qualifying the Third Party Product

Does theproduct

support a Webfront end?

Do not recommendJava technology

Is a Javatechnology

version of theproduct

available?

Note: Plan touse the new

productversion

Go to “Qualifying theExisting Application”

Note: Plan touse the Web

front end

Is an alternativeproduct

available,suitable, andacceptable tothe customer?

Note: Planto use the

newproduct

Yes

Yes

Yes

No

No

No

5



Qualifying the Existing Application

Figure 5-3 Qualifying the Existing Application

Does theproject justifyand permit a

completerewrite?

Do not recommendJava technology

Can the businesslogic and

presentationcode be

separated?

Note: Plan toseparate

business logicand GUI

Go to “Java TechnologyApplicability”

Note: Plan torewrite

Can a screenscraper be

used?Note: Plan touse screen

scraping

Yes

Yes

Yes

No

No

No

5



Java Technology Applicability

Figure 5-4 Qualifying Java Technology Applicability

Does the systemrequire ultimate

real-timeresponse?

Recommend Javatechnology

Is the system a lowlevel device driver,

or require largeparts of the code toperform memory or

I/O accesses?

Consider a partialsolution, perhaps using

Java technology forGUI, control, or

monitoring and useC/C++ or assembler

code for critical systemfunctions. Otherwise,do not recommend

Java technology

Yes

Yes

No

No

5


Migration Considerations

Overview

The Java technology architect may be called on to advise a customer

on the merits of migrating to a new architecture. Considerations

include:

● Migration. Migration is recommended for:

▼ Applications with performance issues which a three-tier

architecture can address

▼ Applications that have hard-to-maintain and/or lost source

code

▼ Significant new requirements

▼ Applications whose code is volatile

▼ Applications whose functionality cannot be replaced by a

purchased application server, Enterprise JavaBeans component,

or packaged product

5




● Screen scraping. Screen scraping is recommended for:

▼ Applications with a short life expectancy

▼ Applications where the user interface, business logic, and data

access logic are intermixed and therefore too hard to separate

▼ Third-party applications that do not support Java technology

▼ Legacy applications that cannot be changed

5



Migration Trade-Offs

Some applications must be evaluated on a case-by-case basis. These

include:

● Cost assessment. What is the total cost of a migration versus

providing a Web front end to the application?

5



Migration Trade-Offs (Continued)

● Value assessment. What value does a new Java application add

that a patched existing application does not? For example, can you

sell the applications to partners or customers? Does it give you the

opportunity to re-engineer the business process?

● Infrastructure costs. The cost of the Java software infrastructure

must be factored in.

Table 5-1 Cost Assessments

Web Front-end Costs New Application Costs

Minimal learning curve (with aWeb browser)

Java application training andlearning curve (or consultingcosts)

Java technology infrastructure(Web servers, browsers, and soon)

Java technology infrastructure(Web servers, browsers, and soon)

Cost of purchasing screenscraper product

Cost of purchasing newapplication server or packagedproduct

Cost of gateway and interfacetools

Possible cost of convertinglegacy networks to TCP/IP

Cost of maintaining the oldsystem

Cost of writing new system

5



Migration Trade-Offs (Continued)

● Training costs. The cost of training must be factored in (for

example, from COBOL to the object-oriented Java programming

language, from SNA to TCP/IP, user support staff training, and so

on). The three-tier architecture may require an investment in new

tools for Java technology and component development.

● Mission-critical, high-profile applications. These are a double-

edged sword. There will obviously be a learning curve for the

customer on the first Java application project. Should this learning

curve be expended on a mission-critical application which might

have significant payback or risk, or on a less critical application

that can be completed in a shorter time?

A middle path here might be to use consultants to create the first

application.

● Redesign and migration costs. Can just a part of the application be

redesigned and migrated to make it more manageable?

● Maintenance costs of the legacy system. A very old system might

cost a great deal to maintain or improve.

5


Gathering Information for the Architecture

Producing an architecture can involve separate customer departments

or teams. The Java technology architect must work with each of these

departments to ensure the architecture conforms (Figure 5-5).

Figure 5-5 Gathering Information for the Architecture

Be sure to include the following groups:

● Data design group

● Application design group

● Security group

● User interface group

Standardscompliance

Userinterfacecompliance

Architecturecompliance

Securitycompliance

Networkcompliance

Datacompliance

Securitypolicy

n-tier Javatechnologyarchitecture

Databasedesign

Dataarchitecture

Networkdesign

Systemarchitecture

Securityarchitecture

Components

Userinterface

Testingstandards

5



Include the following documents in your information gathering

process:

● Business case. This provides the architect with background

information.

● Organizational structure. The architect should understand the

customer’s organization and relationships between those

organizations. Does the customer have ties to a particular vendor?

● Policies and standards. These include, security policy and network

access policy.

5



Customer Preparation

Does the customer

● Have an application design process; for example, waterfall or

iterative? Will Java technology work with it?

● Use any analysis and design tools? Is the customer happy with

these tools? Do they generate code? Can they generate Java

software code?

● Use a notation for application design and development? Can this

notation be used or adapted to object technology?

● Use application development languages, tools, and methodologies

that generate Java software code? Do they support object-oriented

standards?

● Have a system for handling new releases and versions of software

distribution? How do they distribute new software?

5



Customer Preparation (Continued)

● Have a specialist testing and quality assurance (QA) group? What

tools do they use? Can these tools be used with Web browsers and

Java applets? Can they simulate testing over a WAN?

● Need training in object-oriented analysis and design?

● Have standards for user interface designs?

● Have an overall system architecture plan?

● Have networking standards?

● Have an overall data architecture or a data model for the

application?

● Have a security policy? Does this policy cover the Web and

Internet?

5



Customer Constraints

You must understand the following customer constraints:

● Infrastructure – Terminals, desktops, servers

● Network – TCP/IP network and network-ready desktops

A scenario might be that the customer’s PCs are connected on

coax-based Token Ring LANs. The terminals connect to the

mainframe using locally attached IBM 3274 controllers. Thus it is a

big upgrade to support TCP/IP.

5



Customer Constraints (Continued)

● Experience and training in object technology – Exposure to object

technology

A scenario might be that some of the programmers have

experience with GUI objects using PowerSoft PowerBuilder tools

and two-tier client-server applications with the Microsoft ODBC

standard to access relational databases. This is a start, but there

needs to be customer awareness and training on three-tier

architectures, and server-based objects.

● Web, Internet, and Java technology expertise – Internet and intranet

experience

A scenario might be that the customer has no Java technology

expertise, but other departments in the company do have Web

servers for disseminating information to employees. Can this

expertise be utilized?

5


Evaluating Protocols and Products

Common Protocols and Products

Figure 5-6 summarizes the major protocols, products and middleware

commonly used in Java technology architectures. The architect will

eventually need to select the appropriate communication protocols.

This may involve the selection of third-party products. The architect

may also be called on to evaluate and recommend such products.

Figure 5-6 Java Technology Architecture Protocols and Products

Objectdistribution

Communi-cation

protocols

ReuseObjectpersistence

• ORBs

• JDBC drivers

• ODBMSs

• Components

• EnterpriseJavaBeans

• TransactionProcessing(TP) monitors

• Applicationservers

• Gateways

Middleware

• RMI

• CORBA

• JDBC

• Messaging

• JNI

• Other

Product andcomponentevaluation

5


Evaluating Protocols and Products

Prototyping

Developing a prototype application is a good way to validate the

architecture and demonstrate the applicability of Java technology to

the customer. Be aware that, in many cases, prototypes turn into

production applications (through the iterative development process).

Thus, the object-oriented analysis and design for a prototype should

be thorough.

Note – If the architecture is not done properly for a prototype that

becomes production, the customer may run into problems in the future

when the application needs to be scaled or moved to a new client

device or database.

5


Preparing for Reuse

Early on in the customer migration to Java technology, the architect

should help the customer prepare for eventual component

development and reuse.

● The earlier a company addresses reuse, the sooner the benefits are

realized.

● The concept of reuse may need to be “sold” to the customer

management first. It can take extra time and money to develop

reusable components and to set up an environment that

encourages reuse.

5


Preparing for Reuse

● Reuse takes a long time to produce a payback. Effort must be

spent on designing a general purpose, reusable framework

(general classes that can be subclassed and overridden to provide

new functionality). These objects should be independent of any

specific application. Components developed for a specific

application may end up being too application specific to be reused.

● A reusable library of components must be established, published,

documented, and maintained.

● Using Enterprise JavaBeans puts more focus on the benefits of

reuse.

5


Common Architecture Features

Conventional Three-Tier Architecture

The basic Java technology three-tier architecture (Figure 5-7) can be

used for many applications.

Figure 5-7 Generic Java Technology Three-Tier Architecture

This generic architecture can be used as a template. It includes

● Client presentation

● Client processing

● Client protocol (to tier two)

● Application server or servlet

● Client services (such as printing, and email)

Corporate intranet

Web server

RDBMSserver

RMI,RMI/IIOP,CORBA,HTTP, orSocket

Web browser

JavaappletorJavaBean

JDBC

RMI/IIOPJava IDL

CORBAapplication

JNIOtherapplication

servlet

5



● Application administration (such as application startup and

shutdown)

● Security services (login and access to data)

● Protocol to tier three

● Middleware to tier three (optional)

● Tier three application(s)

● Tier three data

5



Objects and Tiers

The architect separates the objects into presentation, business, and data

layers, and adds intermediary objects for communication.

You should strive to keep the logic and presentation tiers separate

(even if they will run on the same tier). It is tempting to move parts of

the business logic to the user interface to distribute processing onto the

desktop. What happens if the customer decides to replace the desktop

platform with a network computer or another “thin” client device? If

the logic is not well distributed, the new platform may not work. As

long as the logic is well distributed into tiers the logic can be moved

off the desktop if a network computer is implemented.

5



Objects and Tiers (Continued)

The skill of the Java technology architect is in determining if an object

is independent or if it has dependencies on other objects at a different

tier. If the architecture is done properly, there should be minimal

dependencies. You should

● Use UML package notation to reduce dependencies

● Apply architecture and design patterns to eliminate dependencies

The architect also determines reusability. If the same code appears in

several places it is a candidate for a reusable component and should be

placed on the logic tier.

5


Object Reuse

Discussion – Name some common objects that could be reused in

other applications.

5


Architectural Variations

The focus will now be on two variations of the basic communications

structure for Java technology three-tiered architectures (Figure 5-7):

● Enterprise JavaBeans component model

● Publish and subscribe model

Note – The Enterprise JavaBeans component model and publish and

subscribe can be used together in an architecture.

5


Enterprise JavaBeans Architecture

Enterprise JavaBeans is a standard for server-side components.

Enterprise JavaBeans are specialized business components that run on

a server.

JavaBeans

The JavaBeans standard defines a way for client-side components to

collaborate. Entire client applications can be built by combining

JavaBeans components.

Enterprise JavaBeans Comparison

Enterprise JavaBeans similarly defines a way for server-side

components to collaborate. Figure 5-8 shows the relationship between

Enterprise JavaBeans and the Java technology architecture.

Figure 5-8 Enterprise JavaBeans and the Java TechnologyArchitecture

Note – Enterprise JavaBeans requires JDK 1.1.

RDBMSserver

RMI/HTTP

Web browser


JDBC

RMI/IIOPJavaIDL

CORBAapplication

JNI

Otherapplication

Javaapplication Enterprise

JavaBeansserver

RMIRMI/IIOPJava IDL

Non-Javaapplication

CORBAIIOP

RMI

servlet

Web server

EnterpriseJavaBean

5



Containers

All JavaBeans components execute within a container. The server

essentially takes care of threading and concurrency whereas the

container essentially acts as an abstraction layer to interceed between

the server and the business logic. The container demarcates the calls to

the transaction management, manages the persistence layer, and

manages security for the Enterprise Bean’s business logic.

● For client-side JavaBeans, a container might be a Web page, a

form, or a compound document.

● For server-side Enterprise Beans, a container is a transparent

mechanism for servicing the business logic and allowing

portability between different vendors’ server software.

5



Containers (Continued)

Specifically, the Enterprise JavaBeans (EJB) model defines the

interfaces between a server-side component and a container as well as

the client view of the component. The interfaces between a container

and a server is not defined by the specification to allow the server

vendors more flexibility in how they implement the container. Just as

a servlet needs a Web server to run in, an Enterprise Bean needs an

EJB compliant application server and a container to run in. The

container is provided by the application server and manages the life

cycle of the Enterprise Bean. As seen in Figure 5-8, client-side requests

can be satisfied in three ways:

● By the Web server and servlet combination at tier two. They take

care of the network and Web side of the application.

● By the Enterprise JavaBeans server and Enterprise JavaBeans

combination at tier two. The EJB server must take care of the client

request handling and network specifics.

● By routing the requests from the servlet to the EJB server. The

servlet uses Java RMI to access the EJB.

Enterprise JavaBeans allows for middleware independence. Any

container that adheres to the EJB specification can be used. Containers

are used to port the Enterprise Bean from one server environment to

another.

5



Enterprise JavaBeans Server

The Enterprise JavaBeans server is the execution environment for the

container (and thus the Enterprise JavaBean):

● The server provides access to a distributed transaction mechanism

and runs one or more containers.

● The container provides life cycle (creation, destruction, and

persistence) and transaction control for one or more Enterprise

JavaBeans.

● The container and the server might be provided by the same

vendor middleware.

Figure 5-9 shows the relationship between containers and servers.

Figure 5-9 EJB Servers and Containers

EJBAppletorapplication

Container

Server

EJB

EJBEJB

Container

EJB

EJB

5



Enterprise JavaBeans Server (Continued)

The Enterprise JavaBeans server must be purchased from a third-party

vendor. The server is typically supplied by:

● Database management system vendors (for example, Sybase

Jaguar CTS)

● Transaction processing system vendors (for example, IONA

Technologies)

● Web application server vendors (for example, BEA Weblogic)

● CORBA ORB vendors

The Enterprise JavaBeans server provides services such as threading

and state management on behalf of the Enterprise JavaBean.

5



Container Features

Support for transaction processing:

● Transaction procedssing support (transaction start, end, commit,

and rollback)

● Distributed transaction support (two-phase commit)

● Resource sharing

Support for stage management:

● JDBC connection pools (multiplexed database connections)

Support for security management:

● Modifications can be made at deployment time to closely match

the business logic to the operational environment.

5



Enterprise JavaBeans Components

The Enterprise Bean is a reusable, portable, business component

written in the Java programming language. It is portable because the

environment information (the metadata) is stripped out and placed in

a file called a deployment descriptor. The deployment descriptor is

used when porting a Bean to a new server environment to tell the new

environment what the business logic requires to be operational. Some

of these requirements might include transactional management,

security management, and state management.

5



Enterprise JavaBeans Components (Continued)

Enterprise JavaBeans objects have two interfaces:

● Home interface. This allows for the creation (using factory

methods) and removal of the Bean instances, and for locating

existing Beans.

● Remote interface. The container exposes the methods of the

remote interface. These are the methods that perform the business

logic.

5



Bean Packaging and Deployment

The developer writes the Bean and packages the home and remote

interfaces with it. The Bean itself should not use threads, since this is

handled by the server.

The person deploying the Bean implements the interfaces using tools

provided with the container. Not all the Bean’s methods need to be

exposed.

5



Enterprise JavaBean Types

There are two types of Enterprise JavaBean components:

● Session – Session Beans are temporary; they only last for the

duration of the client request. They will be lost if the server

crashes. Session Beans can be:

▼ Stateless – The Bean does not change its state while it is

executing.

▼ Stateful – Execution causes a change in the state of the Bean.

For example, it might store parameters within itself.

● Entity – Entity Beans can persist indefinitely. The container can

create a pool of instances to serve multiple client requests.

5


Locating Enterprise JavaBeans

Clients locate Enterprise JavaBeans within a container by using the

Java Naming and Directory Interface (JNDI) API. JNDI is a high-level

API that can be used to interface Java applications to disparate naming

services such as CORBA Common Object Services (COS), Novell

Directory Services (NDS), RMI Registry, Lightweight Directory Access

Protocol (LDAP), and others. Basically, the naming services plug in

and map JNDI to their own formats (Figure 5-10).

Figure 5-10 Enterprise JavaBeans and JNDI

Note – The integration of naming services with JNDI is done by third-

party vendors. JNDI is a specification like JDBC.

The container creates a new instance of the Bean and locates existing

instances.

An Enterprise Bean can communicate with remote Enterprise Beans

using RMI, or with other objects using RMI/IIOP or Java IDL.

Javatechnologyclient

Container

CreateDestroyLocate

Homeinterface

JNDI

EnterpriseJavaBeanmetadata

Namingservice

Enterprise JavaBeansserver

EnterpriseJavaBeansinstance

Remoteinterface

RMI

5


Summary of Enterprise JavaBeans

Architecture Implications

The container and the Enterprise JavaBean are isolated through

defined interfaces.

State diagrams can be used to model Enterprise Javabeans

components; only the consistent states should be modeled, not

transitional states.

Collaboration diagrams can be used to describe the EJB architecture.

The Enterprise JavaBeans architecture lends itself to description with

UML packages.

5


Summary of Enterprise JavaBeans

Programmer Implications

The Enterprise JavaBeans standard allows programmers to easily

develop multi-use, scalable transactions.

The Bean developer writes the Bean as though only one client will use

it.

The Bean developer does not have to be aware of transaction

boundaries or use low-level transaction APIs. The container takes care

of this. However, advanced Bean developers do have the flexibility of

managing their own transactions if the need arises.

The Bean developer does not have to consider the network.

5


The Publish/Subscribe Architecture

The publish/subscribe model (Figure 5-8) is an alternative to the

synchronous RMI and CORBA architectures. Publish/subscribe is

based on events.

Events

An event is the notification of a business event (for example, the

creation of a purchase order). The event is usually a text message. The

publish/subscribe model is asynchronous and is usually implemented

on top of message queuing middleware.

Figure 5-11 The Publish/Subscribe Architecture

RDBMSserver

Web browser

CORBAapplication

Otherapplication

Javaapplication

Applicationthat cannothandle Javatechnology

Publish/subscribeservice

Publish

Subscribe


5



Publishers and Subscribers

Client and server components are classified into two groups:

● Publishers register the event with the publish/subscribe service.

For example, when a purchase order is created, the tier two object

that creates it can send notification to the requester of the purchase

order, the vendor, and to the accounts payable system. Events can

be as dynamic as a live stock feed, changes to inventory, or

materials movements. Events can contain data, such as the

purchase order details.

● Subscribers register their interest in specific events with the

publish/subscribe service. For instance, the client object that

originates the purchase request can subscribe to notification when

the purchase order is created.

5



Benefits of Publish and Subscribe

Applications running on both clients and servers can publish events,

and other clients and servers can subscribe to those events. When an

event occurs, a message is sent to the subscribers of that event. The

publish/subscribe model has many benefits:

● Loosely coupled architecture. If the subscriber’s system is down or

not connected to the network, the event is queued until the system

is back on-line. This guarantees availability.

● Scalable architecture. The only significant factor that might limit

scalability is network bandwidth. Message queues can be

distributed and replicated.

● Messaging benefits. Messaging systems guarantee message

delivery.

● Performance. Each message traverses the network only once, even

though it might be subscribed to by multiple recipients.

5



Benefits of Publish and Subscribe (Continued)

● Mainframes and programs that do not support Java technology

can play a role in the publish/subscribe model since they support

messaging.

Note – The publish/subscribe model requires management and

security, as well as data dictionaries to contain the details of the

publishers and subscribers, and message queues.

5


Publish/Subscribe and Three-Tier Architectures

Implementing Publish and Subscribe

The publish/subscribe model can be used with three-tier Java

technology architectures (Figure 5-12). Java applets, applications and

servlets can access the model using:

● The Java Messaging Service (JMS). This provides a high-level,

generic Java software interface to messaging products that support

the API.

● An API provided by the vendor of the publish/subscribe service.

It is expected that these vendors will also offer the JMS API as well

as their own APIs.

Figure 5-12 Publish/Subscribe and Three-Tier Architectures

Web browser


Servlet

Web server

Publish/subscribeservice

Tier threeapplication

RMI

5



Publish/Subscribe Examples

The publish/subscribe model is useful for workflow systems, like the

purchase requisition system describe previously. It is also suitable for

any application that requires near-time notification when events

happen:

● Inventory management real-time changes and levels can be

propagated to different applications or to suppliers and resellers.

● Real-time decision support. Decision makers can be notified of

events such as product levels, retail item fluctuations, and so on.

● Data monitoring applications (for example, finance applications

that monitor stock market prices).

● System monitoring and management applications. A system

administrator can be notified of events such as a system error.

● Bulletin board applications (one-to-many discussion groups,

multicast notification).

5



Publish/Subscribe Examples (Continued)

● Data warehousing applications. As a new update is made to the

source of the data warehouse, an event can be generated to reflect

the update in the data warehouse.

● Near-time systems.

● Intermittent connection applications (mobile users).

Note – Publish/subscribe is not suitable for real-time transaction

processing applications or database query systems.

5


Assessing Publish/Subscribe Feasibility

Table 5-2 compares the reasons for choosing publish/subscribe or

email.

Table 5-2 Comparison of Email and Publish/Subscribe

Email Publish/Subscribe

Workflow needed within hours Workflow needed withinminutes

All messages have samepriority

Messages need to be prioritized

Messages (and data) do nothave to be recoverable

Messages (and data) must berecoverable

Message delivery does notneed tracking

Message delivery must betracked

If the message is lost, thebusiness is not impacted

Message delivery is crucial tothe business process—if themessage is lost, the business isimpacted

5


Assessing Alternate Architectures for PlasticDeSign, Inc.

PlasticDeSign, Inc. Case Study

The Enterprise JavaBeans and the publish/subscribe model will now

be evaluated using the case study that you completed in Module 4,

‘‘Integration With Existing Applications and Databases (Figure 5-13).

Figure 5-13 Assessing Alternate Architectures for the PlasticDeSign,Inc. Company

:Client

Approverapplet

Buyerapplet

Order :Order

:RDBMSgateway

:Converter

:CICSgateway

WorkflowrouterRoutingengine

:Application Server

RMI:

JDBC

LU6.2

Requestorapplet

:PO finalizer

Formatter Accountspayablesystem

:Mail server

Vendorapplet

:Vendorinfo

Vendorinfo

:Java MailSMTP

Daemon

:PR / POstorage

:Web ServerHTTP

5



Enterprise JavaBeans Alternative

The following services can be provided by the Enterprise JavaBeans

server and container:

● Life cycle management of server-side components (create, destroy,

and so on)

● Client session management

● Database connection multiplexing to the RDBMS (connection

pools)

● Database update coordination for updating multiple tier-three

databases (the stored purchase orders and the mainframe accounts

payable system)

● Transaction management for creating purchase orders

● Security services for controlling access by vendors

5



Enterprise JavaBeans Alternative (Continued)

The following can be designed as server-side components:

● Standard services that are common to multiple applications, such

as file, print, naming/directory, and so on.

● Interfaces to existing systems, such as mainframe-based

applications and databases

● Object/relational mapping components

● Monitoring and management components

● Anything that can be reused as server-side

● Specific business processes, such as Purchase Order Creation

Note – When recommending Enterprise JavaBeans, the architect must

assess the features provided by the EJB server and container.

5



Publish/Subscribe Alternative

The following services are provided by publish/subscribe provide for

the PlasticDeSign, Inc. application:

● Elimination of the email server from the application.

● Reliability (compared to email).

● Improved workflow. With messaging, the approvers can get

notified much earlier, since messaging is more responsive than

email. The notification is sent to all approvers simultaneously.

● Urgent purchase orders can be pushed through the system using

messaging priority services.

● Integration with the mainframe. The new Java software system

can be synchronized with the existing mainframe system until all

users have been converted.

5


Check Your Progress



❑ Recommend a migration strategy for an existing application

❑ Design a multi-tier architecture using Enterprise JavaBeans

❑ Describe how Java technology can be used for transaction

processing

❑ Discuss alternative Java technology architectures, such as publish

and subscribe

❑ State the advantages and disadvantages of partial migration using

Java applets and applications

5


Think Beyond

Access controls are needed for external vendors who access the

PlasticDeSign, Inc. application.

● How do access controls affect the architecture?

● Which tier is security applied at?

● What security mechanisms does Java technology provide?


DesigningaSecure JavaTechnologyArchitecture 6

Course Map

Java technology architectures frequently incorporate a public network

such as the Internet. The architect must plan and design security into

such architectures. This module looks at security mechanisms for the

Java application architecture.

Basic Principles



Foundation


Advanced Principles






Deployment


6


Relevance

Discussion – There are many compelling reasons for using the

Internet or an extranet to deliver Java applets and applications to

customers, partners, and remote employees.

● It provides an inexpensive network solution.

● The infrastructure is already there, so customers do not have to

build one.

● Extranet applications can be distributed easily to customers.

● Partners and employees can access applications from anywhere

through a local Internet service provider (ISP), (saving the

company integrated services digital network [ISDN] leased line

and dial-up costs).

How can customers safely take advantage of the Internet?

6

Designing a Secure Java Technology Architecture 6-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● State the security constraints and trade-offs that affect Java

application architecture

● Design a multi-tier Java technology architecture for use over an

unsecured public network such as the Internet

● Evaluate a proposed (or existing) Java software solution

architecture and make recommendations to provide or increase

security

● Design a multi-tier architecture for an extranet application

References



● Gong, Li; Mueller, Marianne; Prafullchandra, Hemma; and

Schemers, Roland. Going Beyond the Sandbox: An Overview of theNew Security Architecture in the Java Development Kit 1.2. [White

paper]. Developed for USENIX, [Online] Available:

http://java.sun.com/people/gong/papers/pubs97.html.


6


The Three-Tier Architecture and Security

Security In the Default Three-Tier Architecture

The default JDK 1.1 three-tier architecture using Java technology is

inherently secure (Figure 6-1):.

Figure 6-1 Three-Tier Architecture and JDK 1.1 Security

Applets and Security Manager

Client applets run under the protection of a Security Manager (often

referred to as the sandbox). The Security Manager is a class which is

provided by the Web browser (JVM). The sandbox was designed to

protect client platforms from hostile applets that might be downloaded

over the Internet from unknown hosts.

Tier twoproxy

Database

Applethost

Database

Security Manager

Applet

Web browser

6



Applets and Security Manager (Continued)

Applets are prevented from:

● Accessing local client files

● Obtaining information about the client platform

● Connecting to hosts other than the applet host (the HTTP server

that downloaded the applet).

● Loading client libraries or DLLs

● Executing programs or scripts on the client platform

6



Applets and Security Manager (Continued)

Java applications (including client-side applications) do not normally

run under a Security Manager.

Servlets can run under a Security Manager that is provided by the Web

server.

Tier two acts as a proxy between the client and the data at tier three.

The client never accesses the data directly. Tier two allows controlled

access to tier three and enables centralized password control to be

implemented. All clients must access the back-end systems using tier

two.

Client applets can access other hosts in the system through the tier two

proxy.

6



Disadvantages

The sandbox in the Java programming language is sufficiently secure

for many architectures. However, it places a restriction that all accesses

from the applet must go through the Web server host (even if the host

is just a pass-through mechanism).

This restriction contradicts the idea of logical application tiers that can

be moved around the architecture. The tier two proxy must reside on

the applet host, and cannot be moved.

There might be a legitimate requirement for the applet to access local

client files and other devices; for example, a credit card reader

attached to the client platform.

6


Aspects of Security

Security is a multi-faceted requirement that must satisfy all parties.

Consider the PlasticDeSign case study from Module 4, ‘‘Integration

With Existing Applications and Databases.” PlasticDeSign now wants

to allow their suppliers to view status information about their own

purchase orders. They will be accessing the system over the Internet.

This calls for many different levels of security (Figure 6-2):

Figure 6-2 Security Requirements for PlasticDeSign

Web server with servlet

Mail server

RDBMS server

Tiers two and three

Other intranet servers

Suppliers

Internet

AppletPurchaseorderdata for allsuppliers

Mainframeaccountingsystems

6


Aspects of Security

As illustrated in Figure 6-2, the customer’s requirements are:

● The customer (PlasticDeSign) must be sure that the supplier is

valid.

● The supplier must be sure that the customer’s applet is safe and

that it does no harm to the supplier’s system.

● The supplier should be allowed to see only their own purchase

order data. This requires implementation of access controls.

● PlasticDeSign employees should be allowed to see only the

purchase orders that they originated. However, the buyer should

be able to view all purchase orders.

● No company confidential information should be exposed over the

Internet.

● The passwords used by the suppliers to log in to the system

should not be exposed over the Internet.

Will the basic three-tier architecture provide these levels of security?

6


Basic Security Architecture

Typical Security Structure With Firewalls

The basic security architecture for opening up an application to the

Internet is illustrated in Figure 6-3:

Figure 6-3 Basic Security Architecture for an ApplicationConnected to the Internet

Internet

FirewallFirewall

Demilitarized zone Corporate intranet

Web

Mail

FTP

Commerce

Customers

suppliersPartners

Remote

Packet andport filtering

employees

Applicationfiltering

Internal Web server

(DMZ)

6



Typical Security Structure With Firewalls (Continued)

In Figure 6-3, two firewalls are installed. The first one filters requests

from the Internet. The second firewall server protects the company’s

intranet. The only way to get through this second firewall is with a

trusted application.

6



DMZ

The area between the two firewalls is known as the demilitarized zone(DMZ). Because this is a semi-secure area, do not install any sensitive

data here.

The Web server and servlet run here. However, the servlet simply acts

as a proxy between the applet and business logic processing located

behind the second firewall. The servlet passes client requests to the

application business logic tier and to the back-end information

systems. Thus, neither the user nor the servlet has direct contact to tier

three data or applications. In essence, an extra tier has been added to

the Java technology architecture.

Other services such as file transfer protocol (FTP) and email run in the

DMZ. The DMZ can be a staging area for mail and FTP files that are

transferred between the Internet and the company intranet.

For electronic-commerce applications, the commerce server catalog

and shopping cart can run in the DMZ. However, no proprietary

company business processes should run here.

Catalog data that the users browse can be placed here; however, order

information must be passed through the second firewall to be

processed.

6



Firewalls and Scalability

Obviously, firewalls can become a bottleneck, since everything is

funneled through them. Firewalls are very efficient at scanning ports

and filtering packets; however, overhead might be incurred if the

firewall has to scan the contents of a packet (for example, looking for

the <applet> tag within HTML).

The architect must anticipate the affect of the firewall on the overall

architecture performance. Questions to ask are

● How robust is the firewall?

● How scalable is it?

● How many packets per second can it process?

The two firewalls serve different purposes; thus, they should be from

different vendors. If someone manages to break into the first firewall,

they might easily be able to break into a second firewall if it was from

the same vendor.

6



Assess the Security Infrastructure

Use the following questions in your assessment.

● Security policy – Does the company have an existing security

policy? Does this cover the Internet and access to systems by

outsiders?

● Remote access procedures – Are there procedures and rules in

place to govern remote access by employees, partners, and

suppliers? Many companies use dial-back modems for remote

access.

6


Security Appraisal

Discussion – What security exposures have not been addressed by the

dual firewall architecture?

6


Security and Application Architecture

Can the same application architecture suffice for both intranet and

extranet use? The basic security requirements for the PlasicDeSign

application, or for an extranet application, are:

● Authentication of external users – Is the current user validation

mechanism sufficient? Though this might appear to be sufficient,

the users are responsible for changing passwords frequently and

to choose passwords that cannot be easily guessed. Does there

need to be password access for the employees?

● Access control – There must be multi-level access control for

employees, buyers, and vendors. In its current form, the business

logic will allow any vendor to query any other vendor’s purchase

order data just by entering a valid purchase order number.

● Privacy – The Internet is an unsafe network. Passwords and other

sensitive data must be encrypted when they are sent over the

Internet.

6


Addressing Security Requirements With Java Technology

Table 6-1 shows some solutions to various security requirements.

Table 6-1 Addressing Security Requirements

Requirement Solution(s) Comment on Java TechnologySupport

Authentication • Passwords

• Signed applets

• Digital signatures

Signed applets and digitalsignatures require the Security APIin JDK 1.1

Access control (multi-level)

• Access control lists(ACLs)

Access control lists are oftenimplemented by Web server

Privacy of data • Encryption, such asSSL

• Virtual privatenetwork (VPN)

Web browser and Web serversupport for SSL encryption ofHTML

Java Cryptography Extension (JCE)for encrypting application datastreams requires JCE addition toJDK 1.1

Prevention of Internetspoofing

• Firewall scanning

• Digital signatures

Digital signatures require JDK 1.1

Virus protection • Firewall scanning The sandbox prevents virustransmission by applets

Prevention of dataalteration

• Message digests andsignatures

• Signed JAR files

Message digests and signed JARfiles require JDK 1.1

Prevention of Internetattacks

• Web proxy server

• Firewalls

6


Addressing Security Requirements With Java Technology

The Java virtual machine instructions provide the fundamental basis

for security. The Sandbox is implemented on that foundation. There

are variations on this security which can be used in Java technology

architectures to provide additional levels of security for applications.

Some of the more advanced forms of security will now be examined.

6


Security Techniques and Layering

Security can be applied to an application at different layers

(Figure 6-4).

Figure 6-4 Security Techniques and Layering

Application

Transport

Network

HTTP

SSL (https)

TCP

IP

IPSEC, SKIP

IP

SET, S/MIME, PGPJCE, S-HTTP

HTTP

SSL (https)

TCP

IP

IPSEC, SKIP

IP

SET, S/MIME, PGPJCE, S-HTTP

VPN

SET = Secure electronic transactionS/MIME = Secure/ multipurpose internet mail extensionPGP = Pretty good privacy

S-HTTP = Secure hypertext transfer protocolIPSEC = Internet project support environmentSKIP = Simple key-management for Internet protocols

6



Three layers are shown in Figure 6-4:

● Application layer. The data is encrypted at the application layer

before it gets to the transport layer. The applications must use

encryption keys or encryption algorithms directly (these must be

licensed from security vendors such as RSA Data Security, Inc.).

▼ Secure Electronic Transactions (SET) is a standard promoted by

credit card companies for making secure payments over the

Internet. The Java Electronic Commerce Framework (JECF)

incorporates the SET standard.

▼ Mail applications use secure multipurpose internet mail

extension (S/MIME) and pretty good privacy (PGP) to encrypt

data.

▼ The Java Cryptography Extension (JCE) is an API for

encrypting data between Java applications at the application

level.

▼ Secure HTTP (S-HTTP) is a secure form of the HTTP protocol

that can be used between Web browsers and Web servers.

6



● Transport layer. Transport layer security encrypts data below the

application layer, and is the most common form of security over

the Internet.

▼ SSL is the most common transport security mechanism. It

encrypts all data that passes over a secure socket, but not the

TCP/IP header information.

▼ SSL uses public key cryptography from RSA Data Security. The

Web site administrator generates a public/private key pair

when the SSL Web server is being configured. The Web

browser does not need any special configuration.

● Network layer. Network layer security encrypts date through the

network and is used by virtual private networks (VPNs). VPNS

are a secure “tunnel” or path through an unsecure network such

as the Internet (see Figure 6-5). VPNs can be used to provide

secure access by partners and suppliers (extranet).

VPNs are usually implemented by hardware at each end.

Application data is exposed at the higher transport and

application layers, so for complete security this should be used

with other forms of security.

6



Figure 6-5 Virtual Private Network

▼ Internet project support environment (IPSEC) is an emerging

Internet IP security protocol that provides network encryption.

▼ Simple key-management for the Internet Protocol (SKIP) adds

more security; however, SKIP drivers must be installed on the

client platform.

Javaapplet

Supplierfirewall

Web server

ServletRDBMS

DMZ

Encrypted path orVPN

Extranet Intranet

6


Security Architecture Details

Since the servlet in the DMZ does no business-specific processing, the

application’s business logic tier has been moved behind the second

firewall (Figure 6-6).

Figure 6-6 Security Architecture Details

There are now two Web servers:

● The first Web server is just a pass-through process.

● The second Web server runs on the intranet and is accessed by

employee applets.

The business logic can be designed as a Java application or Enterprise

JavaBean (with a container).

Note – The application tiers are still the same, even though they have

been moved.

Vendorfirewall

Web server

Servlet

Web server

RDBMS

Businesslogic

Servlet

Mainframe

DMZ

Vendorapplet

JavaapplicationorEnterpriseJavaBean

6


Security Mechanisms

Security options to consider include authentication, access control, and

encryption.

Authentication Options

Authentication options include:

● Passwords. Password information can be encrypted over the

Internet using SSL (provided by the Web browser and Web server).

● One-time passwords using challenge/response authentication

technology. These are safer than static passwords. One-time

passwords are implemented by token cards such as Enigma,

S/Key, and OPIE.

● Single login for the user to access multiple applications. This is

accomplished with a dedicated authentication server such as the

Novera application server.

6


Security Mechanisms

Access Control Options

Access control options include:

● Access control lists (ACLs) which can be implemented by Web

servers or by Java applications using the Java ACL API.

▼ The Java ACL API was introduced with JDK 1.1. This is a low-

level API and the implementer must build the ACL

mechanism.

▼ Access control lists store a profile for every user or group of

users. The profile is consulted to determine which area of data

the user is allowed to access.

● Firewall packet filters, which can filter access using various levels

of granularity (ports, protocols, IP addresses, and so on), are

usually not as fine-grained as ACLs.

● Authorization server support included in Web applications servers

such as Novera.

Encryption Options

Encryption options include:

● Secure socket layer (SSL). As was mentioned earlier, it is the most

common form of encryption used over the Internet.

SSL provides authentication of the Web server to the client, as well as

client authentication to the Web server.

Note – There are various strengths of encryption keys (the longer the

key the harder it is to break). Due to United States export controls,

only 40-bit encryption keys (the shortest) can be currently exported

from the United States and Canada.

6


Security Mechanisms

Encryption Options (Continued)

● Java secure sockets. Data transfers from an applet to a server can

be encrypted by Java applets and applications that use TCP

sockets. This requires that both the Web browser and the applet be

at the JDK 1.1 level.

▼ Secure sockets are provided with the Java Server toolkit or by

third parties.

● Java Cryptography Extension (JCE) package allows a Java

application to encrypt directly (instead of relying on the transport

layer).

▼ The Java applications can use higher strength encryption keys

(up to 2048 bits).

▼ This requires JDK 1.2, and the encryption algorithm must be

licensed from a vendor such as RSA Data Security.

▼ Strong encryption is subject to export restrictions from North

America. Some other countries have laws governing access to

encryption too.

6


Signed Classes

JDK 1.2 Security

A major refinement to Java security took place with JDK 1.2:

● Java protection domains replace the Security Manager

● The Java Security Manager (sandbox) is still available

Protection Domains

A signed class may be granted some degree of trust; that is, given

permission to perform an operation that would otherwise have been

refused, such as open a file. Web browsers give users the choice to run

a signed applet in a different protection domain which allows it to

override the sandbox security. Trusted classes and untrusted classes

are separated into different protection domains for added security

(Figure 6-7).

6


Signed Classes

Protection Domains (Continued)

The protection domain is a set of access permissions (read, write, and

so forth) that apply to an applet or group of classes. This set of

permissions is conventionally stored in a text file (policy file) and may

be managed centrally if appropriate.

Signed Servlets

Unsigned servlets that are loaded across the network are confined to a

sandbox which is similar to the one used by Web browsers, that

restricts access to resources.

Signed servlets are protected by the protection domain feature, the

same as signed applets.

Figure 6-7 Signed Applets and Servlets

Vendorapplet

Vendorfirewall

Web server

Servlet

Web server

RDBMS

Businesslogic

Servlet

Authenticationserver

DMZ

Trustedapplet

Untrustedapplet

Protection domains

6


Signed Applets and Servlets

Digital Signatures

Applets and servlets are signed using a digital signature. The digital

signature uniquely identifies the sender of the applet, just like a

fingerprint. When a signed applet is downloaded to the client, its

digital signature is stored by the Web browser.

Digital signatures use two sets of encryption keys, making them safer

than single key (public) encryption. The originator encrypts the data

with the public key of the recipient; the recipient’s own private key

decrypts the data.

Digital signatures can be used to identify the user of an applet as well

as the originator. They are frequently used by electronic-commerce

systems and by SSL for encryption (the public encryption keys are

digitally signed for added protection).

6



Digital Signatures (Continued)

Digital signatures are implemented using various techniques:

● Smart cards which have embedded digital signatures and can be

used by consumers to make purchases by using the Internet.

● Client software which has an embedded digital signature for the

user and can respond to merchant requests. This normally resides

on the user’s computer.

● Merchant software products by which the merchant obtains a digital

signature from an issuer when the software is initially installed.

● Firewall products may contain embedded digital signatures for

authenticating remote users for access.

Note – Digital signatures are only a mechanism to trace the originator

of an applet or message. They cannot prevent fraud or attack; they can

only trace the source.

6



Digital Certificates

Digital certificates are used to securely transmit the public keys that

are used for encryption, and to verify and digital signatures.

Certificates contain other information as well as the actual public key.

One crucial feature of a certificate is that it is itself signed.

Certificate Authorities (CAs) have been established to verify

individual and institutional identities, and the match with their public

keys. Once this association has been proven a digital certificate that

publishes the key is issued. The certificate is signed by the CA.

6



Message Digests

A message digest is a checksum (hash value) of the contents of a piece of

data. When used, the message digest accompanies the data over the

network. The receiver recomputes the hash value of the data and

compares it to the message digest sent with the data to ensure that the

data has not been accidentally damaged.

Message digests are part of the core JDK 1.2.

6


Security Versus Usability

There is often a trade-off between providing security and usability. The

reason why SSL is so prominent is that it needs no installation or

involvement by the user.

SSL will provide adequate levels of security for most extranet and

Internet users.

Some rules for designing security methods are

● DMZ should not have any confidential information. This

particularly includes the external Web server.

● Choose a security mechanism that is not specific to any Web

browser (for example, SSL).

● Choose a security mechanism that can be used internationally.

6


Security Versus Usability

● Choose a security mechanism that requires no (or minimal) setup

by the user (for example, SSL). The reason is that if it is too

cumbersome to set up, users will simply abandon the idea of

security and proceed without it.

● If you use signed applets or other JDK 1.2 security features, ensure

that all Web browsers support them.

● Choose a security mechanism that can pass through firewalls

(consult Table 6-2).

Note – The SSL socket connection may not be allowed in or out by the

external user’s firewall. If this is the case, you may have to use SHTTP.

It is a general rule of security that permissions must be explicitly

granted. This is normally cited as: “That which is not explicitly

permitted is denied.”

Table 6-2 Security Mechanisms Used Through Firewalls

Protocols That Are NormallyAllowed

Protocols That May BeDisallowed

FTP TELNET

SMTP (email) JDBC vendor protocols (type 3)

HTTP (applet tag) JRMP (RMI)

HTTP IIOP (CORBA)

HTTP (URL) HTTPS

SHTTP

Any socket not explicitlypermitted

6


Security Architecture

The components of the application architecture (Figure 6-8) now

include:

● Authentication with user ID and password. Consider a one-time

password scheme for extra security.

▼ The applet that the suppliers use is downloaded from the Web

server. The applet displays a dialog box for the user to enter

username and password. The user will be allowed three

attempts to log in, after which the applet stops.

● Java applet with SSL encryption over the Internet (provided by

Web browser)

▼ The supplier’s Web browser uses SSL to encrypt the login

details. The login screen uses the HTTPS connection (that is,

the user enters https://applet.url instead of

http://applet.url ).

6


Security Architecture

● Servlet pass-through in DMZ. The servlet passes requests through

the second firewall. Only requests from the servlet are allowed

through.

● Once behind the second firewall, there are several options for

providing multi-level access control (to prevent suppliers from

accessing other supplier information):

▼ Java access control lists using the Java technology ACL API

▼ Using the security provided by the RDBMS vendor (each

supplier is allocated a database user account)

▼ Using a purchased authorization server (such as Novera)

Figure 6-8 Components of the Application Architecture

Supplierapplet

Supplierfirewall

Web server

Servlet

Web server

RDBMS

Businesslogic

Servlet

Mainframe

DMZ

Authenticationserver

User ID and passwordSSL encryption

6


Security Comparison: JDK 1.1 Versus JDK 1.2

Although many security features were introduced in JDK 1.1, the

security model was still the Sandbox security model. With JDK 1.2 the

new Protection Domain Security model was introduced.

Table 6-3 JDK 1.1 and JDK 1.2 Security Comparison

Security Feature Supported in JDK 1.1? Supported in JDK 1.2?

Security model Yes, Sandbox Securitymodel

Yes, Protection DomainSecurity model

Access control lists Yes, java.security.acl Yes, java.security.acl

Message digests Yes, java.security.MessageDigest

Yes, java.security.MessageDigest

Digital Signatures Yes, java.security.Signature

Yes, java.security.Signature

Encryption With JCE 1.1 With JCE 1.2

X.509 certificates Yes, Version 1 Yes, Version 3 implementationsupport

Certificate interfaces No Yes, java.security.cert.X509Extension

Keystore database(certificate andkey/identity database)(Note the change)

Yes,$HOME/identitydb.obj

Yes, $HOME/.keystore

Keystore database tool(Note the change)

Yes, javakey Yes, keytool

JAR signing tool(Note the change)

Yes, javakey Yes, jarsigner

Class loaders Yes,java.lang.ClassLoader

Yes, java.lang.ClassLoaderand java.security(SecureClassLoader added tosupport new security model)

6


Security managers Yes, java.lang.SecurityManager

Yes, for backwardcompatibility, but permissionchecks pass through thejava.security.AccessController class

Tool for building securitypolicy

Not applicable (policyfiles not used in securitymodel)

Yes, policytool

Table 6-3 JDK 1.1 and JDK 1.2 Security Comparison (Continued)

Security Feature Supported in JDK 1.1? Supported in JDK 1.2?

6


Exercise: Evaluation of Security Architecture

Exercise objective – Critique a proposed three-tier Java technology

security architecture and apply the new JDK 1.2 security features to

improve the architecture.

Preparation

In order to successfully complete this exercise, complete the following

tasks:

1. Read the customer’s requirements and security constraints are

detailed in ‘‘Module 6 Case Study’’ on page A-21 in Appendix A,

‘‘Case Studies.” Detailed instructions for completing the exercise

can also be found here.


into your small groups. If you have any questions, ask the


6


Exercise: Evaluation of Security Architecture

Exercise Summary


or discoveries you had during the case study exercise.

● Experiences

● Interpretations

● Conclusions

● Applications

6


Check Your Progress



❑ State the need for signed applets or servlets

❑ State the security constraints and trade-offs that affect Java

application architecture

❑ Design a multi-tier Java technology architecture for use over an

unsecured public network such as the Internet

❑ Evaluate a proposed (or existing) Java software solution

architecture and make recommendations to provide or increase

security

❑ Design a multi-tier architecture for an extranet application

6


Think Beyond

The architect must integrate security into the architecture at the

beginning of the production process. (The consequences of not doing

this could involve huge changes to applications and possible rewrites

at a later time.)

Performance must similarly be taken into consideration when the

architecture is designed. The next module will look at how

performance requirements affect the architecture.


DesigninganArchitecture forPerformance 7

Course Map

This module discusses performance implications of a Java technology

architecture.

Basic Principles



Foundation


Advanced Principles






Deployment


7


Relevance

Discussion – The Java application that you designed has been

deployed. Users are complaining about slow response times. You have

been called in to find the bottleneck and make recommendations.

What could you have done at the architectural design stage to avoid

this?

7

Designing an Architecture for Performance 7-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Evaluate a proposed (or existing) Java technology architecture and

make recommendations to increase performance

● Design a multi-tier Java technology architecture that delivers an

acceptable level of performance and that can be tuned and scaled

as necessary

References



● Cockcroft, Adrian and Pettit, Richard. Sun Performance and

Tuning: Java and the Internet. SunPress.


7


The Customer Application

The application was originally a two-tier application that used HTML

forms and a Web server with local database over a LAN. It was re-

architected as a three-tier application using Java applets and a

purchased application server, and the database was moved to tier

three (Figure 7-1).

Figure 7-1 Performance Customer Example

Customers

Transportproviders

Mobileemployees

Web server

Firewall

InternalWeb

server

Tier one Tier two Tier three

Real-timefeed

Servlet

Localemployees

Extranet

Internet

Firewall

RDBMS(customizedinformation)

Purchasedapplication

server

Mainframe(inventory

andshipping)

Mainframe(on-linetracking)

7


The Customer Architecture

Overview

The architecture is the classic three-tier Java technology architecture

with a dual firewall for security. The authentication is provided by the

purchased application server.

Customers, suppliers, mobile employees, and internal employees use a

Java applet to access the system. The applet is about 300,000 bytes in

size. The applet communicates with tier two using RMI. The tier-two

application server communicates with the two mainframes using

CORBA.

7



Types of Users

The application allows customers to order land, sea, and road

transportation container services, and track the shipments of those

containers from start to destination. There are three types of users:

● Internal employees who access the application from Web browsers

on the company intranet (Ethernet). They are complaining that the

three-tier application is much slower than the old two-tier

application.

● External customers and transport providers who access the

application through an Internet service provider. They also use

email services through the Web browser. Their speed of access

ranges from 28.8 kilobits per second (kbps) to 128 kbps Integrated

Services Digital Network (ISDN) for medium-sized customers and

up to T1 speeds for the larger customers. They are complaining

about slow response times.

● Mobile sales and support staff who dial in directly to the system

using modems ranging from 28.8 kbps to 56 kbps. They are

complaining that the graphics part of the application is unusable.

7



User Authentication

User authentication is provided by the Web server with a user ID and

a password which is encrypted by the Web browser.

Access Control

The mobile employees and suppliers are deemed to be on the

company extranet; thus they have access to information that cannot be

viewed by customers. Access control is provided by the application

server.

7



Application Flow

The process is as follows:

1. Once logged in, the user is presented with a list of functions

(order service, check order status, check container contents, track

container, and so on).

2. This list of functions is customized for each user upon login. For

instance, customers are shown a list of in-progress orders and

containers that are in transit. Customization is done by the

application server. Employees have a wider range of functions.

3. When customers select a container to track, they receive a

graphical display of the container’s location:

▼ A list of customized functions is shown in a frame on the left.A frame at the right shows the graphical display, which showsthe container as a dot with the entire route mapped out.

▼ Customers can then navigate to a more detailed map. The tier-

two application server generates the graphical displays using

on-line tracking information stored on one of the two

mainframes. This mainframe database is constantly updated in

real-time by distribution employees who use hand-held,

wireless devices which feed into the mainframe using satellite

links.

4. The other mainframe holds container inventory and shipping

information and is used when customers order and query

container content. Both mainframes are accessed to produce the

customized screen when the customer logs in.

5. The tier three relational database stores the customized

information for each of the currently logged-in users.

7


Analysis of Customer Architecture

Discussion – What is your initial reaction to the case study?

● Where might some of the performance bottlenecks be?

● What is meant by performance?

● What questions might you ask the customer to obtain more

information?

● How many of these things should the architect have known at the

architecture stage of the application design?

7


Performance Analysis

Note – This module does not cover the performance measurement and

tuning discipline. The focus in this module is on making effective

application design decisions that will prevent performance bottlenecks

before the application goes in production.

Design Performance Factors

There are many factors that determine performance; these include

● Applet download

● Applet response time

● Network latency and throughput

7



Architecture Performance Goals

The architect must work towards a performance goal that is

established when the application requirements are drawn up (for

example, number of users supported, user response time, applet

download time, and so on).

● What were the original performance goals for this application?

● Were they explicitly stated by the customer?

● Were they included in the application design document?

Design Performance Goals

Sometimes the goals may conflict, and various people can have

different views about performance.

● End-user view (and preconceptions). The end-user is only

concerned with his or her individual response times. Waiting for

an application response is a huge productivity loss.

● Administrator view. The system administrator has a wider view of

performance that embraces overall system, memory, and disk

utilization.

7



Customer Application Performance Goals

What are the performance goals for the customer application?

● Get back to the performance level of the old two-tier application?.

● Support the external users and mobile employees on 28.8 kbps

lines with reasonable performance.

● Download the applet in under 1 minute, or support another 500

users with no degradation in current performance.

It might be some or all of these goals.

● Do these goals conflict?

● Is it possible to meet all goals?

● What is the current level of performance? Can it be compared with

the original goal or the performance that was recorded during

testing?

Perception and Reality

Is the user’s perception clouding the issue? If the user is used to sub-

second response times from LAN-based or terminal-based

applications, a GUI interface might appear to be slower. (In this case

performance must be weighed against the added usability of the GUI.)

Customers must understand the overhead associated with object-

oriented interfaces and balance this overhead with the extra

functionality that they are getting. Does this apply here?

7



Prototyping

Prototyping is invaluable for determining the viability of architectures

and protocols. For example, is RMI passing whole serialized objects by

value, or sockets, passing small blocks of data in many separate

messages, better for a particular application?

Use profiling tools when running prototypes, and be sure to simulate

WAN behavior. Measure network utilization, and end-to-end response

times.

See Appendix B, ‘‘References,” for some testing and profiling tools.

7


Architecture Performance Bottlenecks

Performance will always be a trade-off between the productivity gains

of Java technology and object-oriented technology, and possible

implementation limitations due to network and platform capacities.

The architect must be aware of areas in a Java application environment

that might cause performance bottlenecks in order to design the

application appropriately to meet the conflicts of productivity and

performance (Figure 7-2).

Figure 7-2 Java Program Compilation and Execution

Java softwaresource code

Java softwarecompiler (javac )

Javasoftwarebytecode(class)

Bytecodeloader

Bytecodeverifier

Bytecodeinterpreter

JITcompiler

Java runtime

Operating system

Developmentsystem

Deploymentsystem

Javaapplication

Javaapplet

7



Java Technology Issues

The overhead of Java technology is mainly in the following areas:

● Bytecode interpretation and Java programming language

verification checking.

● Memory management (that is done on behalf of the programmer).

Adjusting the size of the heap can increase performance.

● Thread synchronization (before a method can be run, there is a

check to see if other threads are using the method).

● Method calls. There is a cost associated with frequently accessing a

method.

7



Enhancing Performance

Performance can be improved by considering the following:

● RMI. It is tempting to use the facilities of RMI to transfer objects;

however, the size of these objects and the available bandwidth of

the network to transport them must be considered. This might

affect the architecture design in the following ways:

▼ Is there an alternative to shipping objects over slow networks?It may be better to send a subset of the whole object.

▼ Can multiple objects be “packed” into one object for transfer

using RMI?

▼ Can you use compression? JDK 1.2 allows this.

● Security checking. How much security is needed? Does all data

need to be encrypted, or can just some of it be encrypted?

7



Enhancing Performance (Continued)

● Round trips to server. The architecture can be designed to

minimize the number of trips between tiers. Sending whole objects

with RMI can be an advantage here.

● Excessive data over WAN. The amount of data should be

estimated and reduced by tier two if it is excessive for the WAN

speed.

● JVM version. Use a later version of the JVM, which has better

performance. There has been such rapid improvement in this area

that older products yield much slower performance than newer

products and releases.

● Applications. Use applications instead of applets to avoid the

overhead of the bytecode verifier. (You must balance this with the

overhead of distributing the application.)

Note – Java technology performance is constantly being addressed by

Sun and by Java technology licensees. The architect should strive to

keep abreast of all changes. Java HotSpot™ is an alternative virtual

machine (VM) for Java technology that dynamically optimizes Java

software code at runtime to produce better performance than code

compiled with a JIT compiler.

7



Java Applet Environment Issues

The architect should recommend a suitable implementation

environment for the customer.

The Web browser (or the JVM) is the environment for delivering and

running Java applets. Thus, the performance of the following elements

of a Web browser or JVM can have an impact on applet performance:

● Version and implementation of Web browser or JVM.

● Platform performance (memory, CPU speed, and network speed).

This is especially important for non-traditional devices which run

specialized JVMs.

● Multimedia performance. In the past, computers that were used

for heavy graphics had specialized boards and graphics

accelerators. Can the platform support video and graphics with

reasonable response?

7


Tier One Performance Issues

Applet Download Time

Applets are loaded by the applet class loader (part of the JVM). The class

loader opens and closes a TCP socket connection for each class file to

be downloaded. For example, an applet composed of 20 classes would

make 20 separate connections to the Web server.

This is a considerable overhead. Once loaded, applet classes are first

passed through the verifier to check that the class file conforms to the

Java programming language specification. There is a slight overhead

for this checking.

7



Options to Improve Download Time

Architecture design options to improve applet download time include:

● Use Web browsers and Web servers that comply with HTTP 1.1.

With HTTP 1.0, the server disconnects from the client after data is

transferred. In HTTP 1.1, the server keeps the connection open for

additional requests. This saves the overhead of the client having to

repeatedly connect to the server to download applet classes.

● Keep the applet size as small as possible. This might mean

designing the user interface without some of the graphics and

widgets (for instance, a table widget class alone might be 64

Kbytes). In this respect, using core JDK classes is preferable to

third party components.

Performing as much work as possible on the middle tier will also

reduce the size of the applet, but might increase response time

because of extra communication needs.

7



Options to Improve Download Time (Continued)

● Profile the applet at prototype time so you still have a chance to

redesign it. Measure the applet size during testing using a

profiling tool (examples of such tools are listed in Appendix B,

‘‘References”). Be aware of the minimum platform configuration

needed for acceptable performance. If there are many

instantiations of an object, the object may be a candidate for reuse.

● Design a more efficient interface for users who access the system

over slow links (using HTML instead of an applet). The architect

may need to decide if an extranet applet should be different from

an intranet applet.

● Use a JAR file to load multiple classes in one go (in one HTTP

connection). There may be a trade-off here—if all the classes are

downloaded at once, there will be a longer delay initially in applet

startup. However, once running, there will be no further delays.

● Put high priority classes into a JAR file and load those initially.

Load other classes in a background thread.

● Pre-load the applet classes on the client platform to avoid

download (or use an application) or use push technology to

deliver the applet classes in advance. The architect may deem that

this is appropriate for certain intranet applets which need very fast

responses. For network computers, the applets could be stored on

a local file server.

7



Applet Execution Time

Poor applet performance (once the applet has been downloaded) is

usually a result of one or all of the following:

● Lack of platform memory

● Inadequate platform capacity

● Inadequate network bandwidth (or poor network protocol use)

7



Improving Applet Execution

Implementation options to improve applet execution include:

● Ensure each client platform has sufficient memory for the applet

footprint (especially if the client is a network computer). Applets

are removed from memory on a last-accessed basis. While Java

software code is generally smaller than corresponding C code,

applets require more memory than C code. By adding memory to

the employee’s client platforms, you could increase performance.

● Limit the applet’s use of temporary objects, which can stay in

memory long after they are needed. Object allocation is overhead,

as is garbage collection. The applet should be designed to

minimize object allocation and reuse objects in memory-

constrained environments.

7



Improving Applet Execution (Continued)

● Monitor the way classes are downloaded when the applet executes

using applet profiling. Can classes be loaded in advance using JAR

files? The downside of this is that the applet startup time is

greater.

● Ensure the client CPU capacity can support Java technology with

reasonable performance. Use a JIT compiler instead of interpreting

bytecode. Determine if the applets are to be run on slow platforms.

● Ensure the latest versions of Web browsers (JVMs) are deployed.

Use the latest versions of the JDK if possible (for example, JDK 1.2

has improved garbage collection over previous versions).

7



Network Bandwidth Considerations

The architect may need to make design decisions based on the

performance of the network. Check the following aspects of the

design:

● Caching data. In the customer example, you could extract some of

the complex, graphical data from the tier-three databases and

download to the client in advance. The trade-off here is that

additional memory, CPU, and disk resources might be needed on

the client platform. If large amounts of complex data are

anticipated, there is a case for analyzing usage patterns for the

data.

● Object transfer. Think carefully before transferring large objects

over bandwidth constrained links; for example, shipping RMI

objects over 28.8-kbps lines. Examine network protocols (for

instance, HTTP or sockets may offer better performance than RMI

for slow networks). The trade-off is between ease of use of object

orientation and performance.

7



Network Bandwidth Considerations (Continued)

Note – If you designed and developed the architecture using UML

package notation, the network protocol should be isolated so that it

can be switched to a more efficient protocol.

● Network simulation and testing. If there is no real WAN available

for testing, simulate one. Some test tools provide this facility, as

well as network routers.

● Eliminate network trips by consolidating data in the design; for

example:

▼ Combine multiple socket call data into one socket call.

▼ Download the object to the client once, and manipulate it

locally.

▼ Use piggyback techniques to send multiple packets in one trip.

This is especially crucial for database access and processing

rows of data.

● Monitor the network. Make sure that the network itself is not the

problem (you can use basic network test tools such as ping ).

Check for network waits (they may indicate a delay on the server

end). Ensure that you understand when the slowest speeds will be

in use. For remote and external users, check the speeds that are

supported by the ISP.

● Anticipate the overhead of encryption. This often increases as the

encryption key length increases. Longer keys take more CPU

cycles to decrypt.

● Understand the applet deployment environment. Are there local

Web cache servers in close proximity to the user?

7



Network Bandwidth Considerations (Continued)

● For screen scrapers, understand the network characteristics of the

protocol that is being emulated with Java technology.

▼ With a three-tier implementation, the latency and bandwidthrequirements move to tier two (where the screen scraper runs).Different terminals have different network characteristics (referto Table 7-1). With a screen scraper, these networkcharacteristics will still manifest themselves, but they will bemoved from tier one to tier two.

▼ What network protocol is now being used between tier one

and two? Is it proprietary to the screen scraper vendor? Is it

efficient?

Table 7-1 Network Characteristics of Terminals

BandwidthUsage

LatencyTolerated

Level ofInteractivity

IBM 3270 Low Long Frequent

Digital VT220 Low Short Frequent

PC application(C, C++)

Moderate Moderate Medium

X-terminal High Short High

Thin-client(Javatechnology)

Moderate Moderate Medium

7


Tier One Performance Rules

Applet Performance

The overall recommendations for applet performance are to:

● Use a JAR file to download classes over slower network links.

● Design the applet to minimize network requests.

● Reduce the amount of graphics (without sacrificing functionality).

● Optimize the graphics; for example, use double buffering.

● Calculate the graphics on an appropriate system.

▼ Render graphics on the server if the network is fast compared

to the client machine

▼ Render graphics on the client if the network is slow compared

to the client machine

How do these recommendations affect each of the three types of user

of the example application?

7



Internal Users

Internal users’ concerns are in regard to

● Applet download. The applet may be slower to download than the

previous HTML that these users were used to. However, this

should be only an initial delay while the classes are being loaded.

For the 300,000 byte applet, it should take about 5 seconds to

download over a 10 megabit-per-second LAN. If the applet is

much slower than this, it may be due to the customization that is

performed when the user logs on (this will be discussed later).

● Applet execution. If the delay is consistent, and not just when the

customization is being done, investigate

▼ Client memory

▼ Tier two or tier three performance (this will be discussed later)

7



Internal Users (Continued)

● Network. The LAN network should not be a problem for internal

users (unless it is overloaded anyway, which is not a Java

technology architecture issue). Network overload can be detected

by network analysis tools. If necessary, recommend an upgrade

from 10 to 100 megabits per second and to a switched Ethernet for

increased performance.

7



External Users

External users are concerned with

● Applet download. The applet download time will definitely be a

problem for those using 28.8-kbps modems. For the 300,000-byte

applet, in the absence of compression, it will take at least 104

seconds to download. Alternatives might be

▼ Develop a leaner user interface (smaller applet size)

▼ Use JAR files

7



External Users (Continued)


customization is being done, this could indicate that large

amounts of data are being sent across the network in response to

each client request, probably for producing the graphical displays

of shipment locations. Is there a way to minimize the amount of

data by using piggyback techniques, reducing the fine quality of

the graphics, or optimizing the graphics?

▼ Use JIT compilers (or a faster JVM)

▼ Recommend a suitable platform for adequate performance

● Network. Consider using ISDN or high speed land line access if

available.

7



Mobile Employees

The concerns voiced by mobile employees involve

● Applet download. The applet download time will definitely be a

problem for employees using 28.8-kbps modems. As before, the

300,000-byte applet takes at least 104 seconds to download. It

would certainly be preferable to store the applet locally on the

employee’s laptop, or to use an application instead of an applet, to

avoid the download overhead.

7



Mobile Employees (Continued)


customization is being done, this could indicate that large

amounts of data are being sent across the network in response to

each client request. Alternatives might be:

▼ Revisiting the data design. What size of data was designed to

be transferred? Why has this been exceeded? Is the application

being used in a different way? Is tier two making a call to the

database for each row? Can it be designed to access multiple

rows?

▼ Minimizing the amount of data transferred. Can the same

information be displayed to the mobile employees in a

different way, using text or smaller images?

▼ Modifying the applet and application to allow the employees

to work in disconnect mode. This might entail considerable

changes to the application, such as use of local disk to store the

data entered by the employee. This is not a change to be made

at this stage. Disconnect mode must be created in the initial

application design.

● Network. Choose Internet service providers that offer high speed

modem access in as many areas as possible. If appropriate, look

for ISDN access, but remember that although this might be

available in conference centers or the employee’s home, it is

unlikely to be available in hotels.

7


Tier Two Performance Issues

Tier two bottlenecks might be due to

● Inadequate server platform performance

● Database performance

● Network limitations

7



Server Platform Performance

Tier two is the major scalable tier in a three-tier architecture. The

architect must design the architecture to scale at this tier. Poor

performance may be due to an overloaded server platform or

overloaded application server software. However, with a good

architecture, objects can easily move from the overloaded tier to

another platform or tier. You can do this by

● Anticipating the performance capability of the deployment server

(tier two) platform. Is this a new platform or is it to go on an

existing platform?

● If necessary, recommending that some of the workload (for

example, email servers) be moved to another platform.

7



Server Platform Performance (Continued)

● Assessing the scalability of the server platform:

▼ Configure the tier two platform with appropriate memory.

Most application servers will require memory for each

concurrent client that they are processing.

▼ Recommend the server platform be upgraded if it is to run

other workloads in addition to the Web server and the

applications server. Add a second processor to the server

platform. Run the Web server on one processor, the application

server on the other.

● Assessing the performance characteristics of the tier-two

application or purchased application server:

▼ Does the product use threads or processes?

▼ Is there any limitation on the number of threads it can support

(threads equate to users)? Can you add a second application

server if the first server is handling many concurrent clients? A

single application server with many threads will slow down

with too much thread dispatching.

▼ Can it take advantage of multiple CPU processors?

▼ Can multiple instances of application servers be run

concurrently? Can these instances run on separate platforms?

▼ If the application server is doing screen scraping, how much

memory and CPU is required for each user? What are the

vendor’s recommendations? How many users can be

supported on the tier two platform?

▼ Using purchased components, such as application servers or

Enterprise JavaBeans, might mean you have no control over

the performance of those items.

7



Server Platform Performance (Continued)

● Upgrading the server operating system if necessary. An example

would be from Solaris 2.5 to Solaris 2.6, which contains

performance improvements.

● Using JIT compilers for Java server-side applications.

● Using the latest releases of Web server software and JVMs. These

releases usually perform better than older ones.

7



Server Load Balancing

Server load balancing can be accomplished with hardware or software

products (see Appendix B, ‘‘References” for vendors). Load balancing

can also be used for high availability (Figure 7-3).

Figure 7-3 Server Load Balancing

Two instances of an application server can run on separate platforms

or on separate CPUs on the same platform.

Load balancing software can make simple or complex decisions about

how to allocate requests between the servers. Often the simplest, that

is alternate requests to alternate servers, works best in practice.

Client

Client

Loadbalancingsoftware orhardware

Primaryapplicationserver

Secondaryapplicationserver

RDBMS

7


Tier Three Performance Issues

Database Performance

There are several aspects:

● Consider the performance of the database server itself. This is

largely a database administrator task. What is the database load?

Is the database used for other applications? How do they perform?

● Examine database activity for contention (locking).

● Examine database performance improvements such as indexing

and clustering technology.

● Examine the object/relational mapping.

● Examine the SQL commands used.

7


Tier Three Performance Issues

Database Performance (Continued)

● Consider the database design and access patterns. The architect

can have influence here.

▼ Would it be a benefit to cache heavily accessed data from tier

three on the tier two application server? This might make sense

if the data needs to be “joined“from multiple back-end

databases to fulfill an on-line query, or if it is frequently

accessed by multiple clients.

▼ This caching could be done overnight, for instance, if the

application permits this.

▼ In the customer example, users need real-time access, so

caching the on-line tracking information is not a viable option.

However, other information, such as background graphics,

could be cached.

● Consider the protocol used by tier two to access the tier three

database. If the protocol is slow, options include:

▼ Tuning the protocol. Some JDBC drivers support piggybacking

of data and thus cut down the number of trips needed to access

the data. This might be a selection factor in choosing a JDBC

driver.

Network

Ascertain the network speed between tier two and tier three. Is it a

LAN, or is there WAN access to some of the back-end hosts? Can the

network speed be improved, for example, with switched Ethernet on a

LAN?

7


Java Benchmarks

Table 7-2 shows several products and what is measured.

Table 7-2 Java Benchmarks

Benchmark Product What Is Measured

Jstone AWT performance

CaffeineMark Small applets

JavaPerf Medium applets

SPECweb96 Web I/O (static HTML)

Transaction-processing performancecouncil (TPC)

Transaction and databaseperformance by server platform

SPECweb98 Web I/O (dynamic HTML)

SPECjvm98 JVM performance

VolanoMark JVM performance

7


Java Application Performance Rules

Use the following rules when designing Java applications:

● Set performance criteria with customer prior to production.

● Focus or anticipate the key areas which may cause performance

bottlenecks. Address them early in the testing process.

● Prototype an application. Get a feel for potential bottlenecks at this

stage.

● Design with the slowest user of the application in mind (for

example, in the case study the slowest user uses a 28.8-kbps

modem connection).

● Use JAR files. Portions of an application that are typically used

together should be placed in the same JAR file and unrelated

portions of the application should be in separate JAR files.

7


Java Application Performance Rules

● Minimize graphics. Avoid displaying logos on screens; using

images for screen backgrounds; using image buttons (text buttons

and icons are preferable), and so on.

▼ Where graphics improve application functionality, make them

as small as possible or only display them when requested by

the user, not by default.

▼ Where graphics are used, they should be placed in JAR files so

they can be extracted from the JAR file on the client side rather

than being brought across as streams.

● Minimize data transfer. If an application performs a query which

retrieves a large result set from a database, have this object cached

at tier two. Avoid sending this data over a network.

● Group related data access in one network trip. If the retrieval of

one object is likely to be followed by the retrieval of related objects

most of the time, fetch them all at once. Where possible, group

applet validation that requires access to the server.

▼ Several fields can be sent together in an object to the

application server. This technique results in fewer client-to-

server trips, but it means that the user is potentially not

notified of validation errors right away, which is a user

interface drawback.

▼ Static data that is used for applet validation can be cached in

the application server so that it is retrieved only once and not

for each client instance. However, caching is not appropriate

for data that changes frequently.

7


Architecture Performance Rules

Designing

Ensure that you fully understand:

● Performance goals of the application.

● Performance characteristics of the application (data load, network

load, memory load, CPU load, and so on).

● Where the objects run and how they communicate.

● What data is used by objects, what is being sent over the network.

● Performance tolerance of the application; how far it can deviate

from the goal.

7



Designing (Continued)

● Synchronization of the application (transactions, synchronized

access, asynchronous access, publish/subscribe). Synchronous and

transactional applications have to be architected for higher

performance.

● Platform capability of all users (including network access speed).

● Any performance problems that are out of your control as an

architect (for example, mainframe performance issues).

● Growth plans.

Figure 7-4 Performance Criteria

Javatechnologyarchitecture

design

Prototype

Test Profile

Assessperformance

SimulateWAN

Performancegoals

7



Tuning

If you discover too late that performance is an issue, Java technology

performance can be improved with:

● Hardware upgrades (including specific Java optimization

technology)

● Compiler performance upgrades (including optimization flags

within javac and jvc compilers, and JIT compilers)

● Operating system upgrades and features (for example, native

threads)

● JDK and JVM performance upgrades

7


Redesign of Customer Application for Performance

Include in your design

● JAR file for downloading the applet.

● Local application for mobile employees, which avoids the

overhead of download until the applet is modified.

● Recommendations for memory on client platforms.

● Option to display graphical information in a more efficient way.

Users can then decide if they want to have full graphics or not.

This involves changes to the user interface to allow selection of the

option, and to the application server to produce the reduced

graphics.

● Inventory and shipping information can be pulled from the

mainframe when the user logs on (for instance, an asynchronous

thread can be started to accomplish this).

7


Check Your Progress



❑ Make recommendations to improve the performance of the

application when it is deployed

❑ Design an application architecture to meet the customer’s stated

performance goals

7


Think Beyond

Many of the performance issues discussed in this module are

implementation issues that the architect must be aware of at the design

stage. The architect must be aware of the implementation

environment.

What are some of the implementation specifics of the architecture that

you must be aware of?


The JavaTechnologyArchitecture inProduction 8

Course Map

This module looks at architectural design decisions that might affect

the implementation of a Java technology solution.

Basic Principles



Foundation


Advanced Principles






Deployment


8


Relevance

Discussion – The Java application that you designed is about to be put

into production. The customer has asked you for recommendations to

make the implementation a smooth process.

● What can be done when the application is being designed and

built to ensure a smooth transition into production?

● What new hardware/software/network infrastructure is needed

to support the application in production?

● How can the customer manage the application in production?

▼ Tracking changes to classes and libraries

▼ Versioning issues with Web browsers and JVMs

▼ Changes to data

8

The Java Technology Architecture in Production 8-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Objectives


● Design a Java technology architecture that can be easily moved

into production

● Given a Java application prototype or pilot solution, advise on


● Recommend solutions for efficiently deploying and distributing


● Recommend Java application development, reusability techniques,

and project management techniques

8


Application Development Architecture

The container tracking application discussed in Module 7, ‘‘Designing

an Architecture for Performance,” has been developed using the test

configuration shown in Figure 8-1.

Figure 8-1 Application Development Architecture

As illustrated in Figure 8-1,

● Tier one and tier two are on the same LAN segment. Tier one and

two use Java RMI.

● The Web server, application server and RDBMS server are on the

same server platform. The application server uses a local JDBC

driver to access the database.

● Tier three is accessed through an SNA gateway using Java IDL to a

mainframe CORBA application.

Applet TestWebserver

Testapplicationserver

TestRDBMSserver

Mainframe

LAN

SNAgateway


RMI

JDBC

CORBA

8


Application Test Architecture

Testing All User Configurations

The production application must support the following users in

addition to local LAN users:

● Customers over the Internet.

● A remote department of internal users who have their own LAN

on a different segment.

● An entire department who currently use IBM 3270 terminals to

access the mainframe applications directly. These users are being

upgraded to network computers, but still require access to other

mainframe 3270 applications.

● Nomadic users (sales staff) who can access the system for only two

hours a day.

8



Test Configuration

The test configuration should include or simulate the previously listed

users:

● Internet users – Test through firewalls into the company.

● Remote users – Test or simulate the WAN. Some routers provide

the capability to simulate a WAN.

● Terminal users – Test network computer access using an applet.

There should also be tests using a screen scraper product to ensure

these users can still access other mainframe applications.

● Nomadic users – Test dial-in support.

8



Additional Testing

Some additional testing that would be beneficial is

● Test all Web browsers.

● Test the RDBMS tier on a separate platform. This testing should

highlight any problems with running the database access protocols

over a network stack.

● Do stress testing. Automatic testing tools support Java applets and

protocols (see Appendix B, ‘‘References,” for vendors).

● Test any services that are used by the system, such as email,

domain naming system (DNS), and so forth.

8


Deployment Architecture Analysis

Discussion – How does the deployment architecture differ from the

development architecture?

● How do you map the application tiers to physical servers?

● What additional things might you test?

8


Application Deployment Considerations

The Java technology deployment architecture may differ from the

architecture that was tested. This could manifest different

characteristics in terms of performance and usability. Figure 8-2

illustrates how the tiers are deployed in production.

Figure 8-2 Application Deployment Architecture

Internaluser(intranet)

Applicationserver

Mainframe

SNAgateway

Customer

Firewall

Screenscraper

Remoteuser(extranet)


Firewall

Webserver

Firewall

InternalWebserver

RemoteWebserver

RDBMSserver

Mobileuser(extranet)

Firewall

PPP

8



As illustrated by Figure 8-2,

● The client tier may be deployed on a LAN, over a WAN, or over

the Internet. If the Internet is used, a firewall will need to be added

in deployment. What effect will this have on the applet?

▼ How can you be sure the applet will work through firewalls?

(Some firewalls do not allow RMI or Java IDL to pass through.)

▼ Which customers have their own firewalls? The same

considerations apply.

● The Web server is usually in a data center. It may be in the same

data center as the mainframe, or it may access the mainframe over

a remote SNA or TCP/IP link. If the mainframe is remote, has it

been tested in this capacity, or was a local “test” mainframe used?

8



● An additional Web server has been added locally to the group of

remote users. This configuration is recommended for optimal

performance as the client platform is a network computer such as

a JavaStation™ network computer.The local Web/cache server can

hold user files, as well as the boot server for the network

computers.

● The Java application or application server now resides on a

different server platform from the Web server (behind the

firewall). The Web server is simply a pass-through servlet which

invokes the application server through a second firewall (refer to

Module 6, ‘‘Designing a Secure Java Technology Architecture,” for

an example).

Note – If this is the first Java (or Internet) application to be deployed

by the customer, there are many other considerations for

deployment—training of operations staff, security awareness, and so

on.

● The database server on tier three may involve procurement of a

new server platform and disk storage. It also necessitates the

installation of the production RDBMS, RDBMS client-server

middleware, and JDBC drivers on the tier two platform, and the

loading of production data into the database. This differs from the

data that was used during testing.

8



Production Services

As an architect you should ensure that any other services that are

required by the new application are provided in the production

environment.

You might also have to determine where the following services reside

and how they affect the performance of the application:

● Printing

● Email

● File transfer services (for example, FTP)

8



Production Services (Continued)

● Naming services (for example, DNS for name resolution between

host names and IP addresses, Network Information Service (NIS)

for local area network lookups, column address select (CAS) for

locating CORBA objects, and so on)

● ORBs and registries for CORBA and RMI

Note – Applications server products may be pre-built with one or

more of these services.

8



Mobile Users

In the customer example from Module 7, ‘‘Designing an Architecture

for Performance,” mobile users only access the system for one to two

hours a day. To optimize this time, they require a different approach to

applet distribution.

● Applications are pre-loaded onto the hard disk of each laptop.

● New versions can be “pushed” down. When the mobile user logs

on, there is a check to see if the applet image stored at tier two has

changed. If so the user can download the new applet. Web

browsers can use push technology (for example, Marimba) on

behalf of the applet to accomplish this without any changes to the

applet.

8


Network Computers

There are special deployment considerations for the network

computers that are to replace the IBM 3270 terminals. Network

computers rely on these services being provided, ideally over a local

LAN. They include

● A boot server for downloading the network computer operating

system (for example, JavaOS™ for the Sun JavaStation). The boot

image resides on the boot server, and is downloaded when the

users switches on the network computer.

● Dynamic host configuration protocol (DHCP) for assigning IP

addresses dynamically to the network computer.

● Local Web/cache server for performance. This keeps a local cache

of the most frequently used data (including applets and class files)

for the network computer.

8


Network Computers

● Access to DNS servers for naming services so that the network

computer can locate hosts on the IP network

● NFS™ system servers to hold home directory files and directories,

since the network computer has no local storage

● Access to Internet message access protocol (IMAP) based mail

servers. Network computers need to use server-based email

Note – The Java Server Sizing Guide can be downloaded from Sun’s

external Web site. This provides rules for sizing the servers used to

support network computers.

8


Deployment Considerations for Enterprises

Applet and Application Distribution

Though applets are easily distributed using HTTP URL requests from

a Web browser, there might be an additional need to distribute servlets

and applications throughout an enterprise.

In Figure 8-3, local applications servers have been added in Europe

and Asia.

● When new versions of the application are released, new applets

and servlets can be pushed down to the Web cache server in

Europe and Asia.

● Purchased application servers such as Novera provide the

capability to dynamically load new classes to remote application

servers.

8



Applet and Application Distribution (Continued)

Figure 8-3 Deployment Considerations for Enterprises

Webserver

Applicationserver

RDBMSserver

Mainframe

Intranet

Screenscraper

Applet

Applet

RemoteWeb/cacheserver

AppletAsiaWebserver

EuropeWebserver

Applet

Applet andapplicationdistribution

Asiaapplicationserver

Applicationserver

Appletdistribution

8



Rules for Applet Distribution

Generally, for a LAN-based client population, the applet should be

downloaded each time it is requested. The benefits of zero

administration on the client outweigh the download overhead.

For remote LAN-based clients, there may be sufficient demand for a

local Web/cache server.

For WAN-based clients, consider using push technology to push a new

version of the applet and store on client.

For mobile users, seriously consider the use of push technology.

8



Large Applications

Applications with large amounts of users may require multiple Web

servers, applications servers, distributed databases, and transaction-

processing monitors to handle the workload (Figure 8-4).

Figure 8-4 Large Application Deployment Considerations

As illustrated in Figure 8-4, the enterprise now has

● Multiple Web servers. Additional Web servers can be added

without changing the URL used to access the applet. The URL re-

direct feature can be used here.

● Multiple application servers. Multiple application servers might be

required for workload balancing. A load balancing scheme (round-

robin or other) must be devised, unless the application server

already has such a feature built-in.

AppletLANWeb

server

Applicationserver

RDBMSserver

Mainframe

SecondWeb

server

Secondapplication

server

Transactionmonitor

RDBMSserver

EnterpriseJavaBean

DistributedRDBMS

Distributedtransaction

monitorAppletRemote

Webserver

Remoteapplication

server

LoadBalancer

8



Large Applications (Continued)

● Transaction monitors. The majority of Java technology three-tier

applications do not use a transaction monitor such as IBM CICS or

Encina, or BEA Systems Tuxedo. Heavily used transaction-style

applications require a transaction monitor for:

▼ Large numbers of concurrent users (for example, greater than

1000 concurrent users).

▼ Transaction load-balancing from multiple Java application

servers.

▼ Coordination of updates from the Java application servers to

multiple back-end databases (providing two-phase commit).

The transaction monitor can be a container for Enterprise

JavaBean components.

8


Operational Issues

Startup

Web servers and Java application servers must be manually started so

that they can listen for incoming HTTP and TCP requests. The RMI

registry and RMI application servers must also be explicitly started.

The exceptions to this are:

● Servlets, which are invoked by the Web server

● CORBA application servers, which are automatically started by

the ORB

● Enterprise JavaBeans, which are invoked by the container

Note – There should also be scripts to restart servers after they have

failed.

8


Operational Issues

Troubleshooting

Adopting a three-tier architecture requires a new set of management

and monitoring tools to aid in the diagnosis and resolution of

problems. Instead of two processes (client and DBMS server), there

may be several:

● The client tier

● The Web (HTTP) server

● The tier-two application server, servlet, or Enterprise JavaBean

● The RDBMS server

● Middleware such as CORBA

Java RMI and Java IDL add processes of their own, increasing the

number of processes even more. Thus, when something goes wrong, it

is much harder to find the source of the problem. In addition, these

processes are likely to be distributed on multiple platforms over

multiple types of networks.

The design of a three-tier applications should include some means of

remote monitoring and management. It is much easier to incorporate

them at the design phase than it is to insert them after the application

has been developed and deployed.

● CORBA servers and application server products usually provide a

set of centralized monitoring and management tools.

● Third-party management and monitoring tools usually support

the Simple Network Management Protocol (SNMP) standard.

8


Keeping Pace With Change

Among the things that the architect should consider are:

● Versioning

● Reuse

● Maintenance

Versioning

With the application classes being distributed, version control is

crucial and more complicated.

● Versioning control should ensure that the latest Java technology

classes are downloaded to the client and to remote servers.

● Other versioning control should ensure that new versions of Web

browsers and Web servers are deployed and distributed when

available (after testing with the application). This is crucial to time

constraints if the new applet has a higher JDK requirement.

8



Reuse

Reuse of objects at the analysis, design, and development phases pays

off in the long run. To encourage reuse, architects should establish or

promote:

● Centralized object libraries. The contents of these libraries would

be made available to all developers (perhaps using a Web site).

The library should contain documentation about the objects as

well as the owner’s name, JDK dependencies, interfaces, methods,

parameters, and exceptions that are raised by the object. Examples

of reuse objects might be:

▼ Purchased objects, such as JDBC drivers

▼ GUI objects (such as bar charts, tabs, trees, and grids)

▼ JavaBeans

▼ Enterprise JavaBeans

▼ Servlets

▼ Dialog boxes (for consistency among applets)

▼ Sort objects

▼ Table objects

▼ Login processing

● Development of re-usable objects

● Versioning control on the versions of objects in the library.

What happens when an object in the library undergoes an update?

8



Maintenance

Maintenance issues can be raised if:

● JDK releases include changes to Java APIs that could affect

customer’s applet and application code. This will require

regression testing of the customer’s code.

● New versions are made to applications and databases that require

requisite changes to applets or changes to applets that require

newer Web browsers (JVMs). Users who have the old versions of

applets cached or stored must have a mechanism to download the

new applet.

8


Summary of Architecture Project Tasks

Table 8-1 summarizes the tasks you must complete when designing a

Java technology architecture.

Table 8-1 Tasks When Designing a Java Technology Architecture

Task Check

Develop requirements document:

• Use cases

• Interview customers, external users, technical staff,database administrators (DBAs), and so on

• Screen layouts

• Data flow

• Process dependency

Review requirements document

Analyze legacy systems

• Data model

• Database schema

• Applications

Design object architecture

• Packages

• Object class diagram

• Reuse

• UML

8


Distributed object architecture

• Client objects

• Server objects

• Tiers

• Object communication (CORBA, RMI, sockets)

• Database communication (JDBC)

• Legacy communication (screen scraping, peer-to-peer)

• Applications, servlets, native code, and EnterpriseJavaBeans

• Object persistence (ODBMS, object-relational mapping)

Security conformance

• User authentication (authentication servers)

• Access control

Check consistency with security policy

Verify distributed object architecture (with another Javatechnology architect)

Design physical architecture

Deployment diagrams

• Client platforms

• Network

• Server platforms

• Databases

• Firewalls

Interview network and systems staff on

• Performance issues

• Security issues

• Network issues

• Support

• Architecture verification from operational standpoint

Demonstrate prototype to end users

Table 8-1 Tasks When Designing a Java Technology Architecture (Continued)

Task Check

8


Architecture Checklist

Table 8-2 summarizes the things you must check once your Java

technology architecture has been designed.

Table 8-2 Checklist Once Architecture is Designed

Task Check

Client

• 100% Pure Java™

• User interface consistency

• No excessive use ofgraphics/widgets/audio/video

• JavaBean components

• Navigation buttons intuitive and easy to follow

• Printing (JDK 1.2)

• Email (IMAP)

• Security considerations (signed applets, SSL)

• Reuse components where possible

• JDK level for JVM (or Java Plug-in)

• Year 2000 conformance on displayed dates

• Internationalization (locales, resource bundles)

Tier two

• Reuse (Enterprise JavaBeans)

• Servlets

• Authentication server

• Security (JCE, signed JAR files)

• Data design

• Performance design

• Access control to data

• Year 2000 conformance

General

• Training

• Help

• Frequently asked questions (FAQs)

8


Check Your Progress

Check that you can accomplish the following:

❑ Design a Java technology architecture that can be easily moved

into production

❑ Given a Java application prototype or pilot solution, advise on


❑ Recommend solutions for efficiently deploying and distributing


❑ Recommend Java application development, reusability techniques,

and project management techniques

8


Think Beyond

This course has covered the basic rules, considerations, and techniques

for designing Java technology three-tiered architectures. Java

technology is a growing, evolving industry and there are many other

aspects to consider that have not been covered in this course.

These include

● Java Commerce Client, including the Java Wallet, for electronic-

commerce applications

● Java Naming Services, for developing name servers

● Java Management API, for developing network and systems

management solutions

● Embedded JavaChip™ based systems

A-1Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

CaseStudies A

Case Studies

The case studies in this appendix are used in the following modules:

● Module 2, ‘‘Designing a Java Technology Architecture”

● Module 3, ‘‘Java Technology Architecture Details”

● Module 4, ‘‘Integration With Existing Applications and Databases”

● Module 6, ‘‘Designing a Secure Java Technology Architecture”

A

A-2 Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Module 2 Case Study

Instructions

Work in teams to produce the deliverables described here. At the end

of the allowed time, each team should present their solutions.

Presentations should not last more than ten minutes each.

1. Read and familiarize yourself with the case study that follows

these instructions.

2. Prepare for a meeting with the customer tomorrow. There are twodeliverables expected from you.

a. Sketch out a three-tier architecture for the CARES application.

This should show the tiers and the interfaces between the

tiers. You may use any notation to draw the architecture, but

UML notation is preferred; for example

● UML package diagram (logical view)

● UML deployment diagram (physical view)

b. Make a list of questions that you need to ask the customer.

This checklist will include requirements for Webtop clients,

mobile users, client hardware and software mix, client

network bandwidth, client security needs, and so forth.

3. Present your architecture and designs to the customer (in this

case, the other students). You can use any method you prefer to

communicate your design to the customer such as whiteboard,

slides, or notes. At this presentation you must explain how your

object class diagram can benefit the customer and how your

architecture provides scalability, performance and high

availability.

4. The architecture should specify

▼ Tier one design

▼ Tier two design

▼ Communication protocols

▼ Dependencies and constraints

A

Case Studies A-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Module 2 Case Study

Sample Questions to Ask The Customer

Ask the customer questions similar to the following:

● Is there a specification for your current system and network?

● Is there an entity-relationship diagram for the SQL server

database?

● Are your developers familiar with any databases other than SQL

Server?

● Are your developers familiar with Java, C or C++?

A


Module 2 Case Study

DirectContact, Inc.

DirectContact Inc. is a provider of cellular networks to subscribers.

Their business is expanding rapidly.

They have a customer service application called CARES (Customer

and Reseller Express Support) in use at their three customer call

centers in San Francisco, Chicago, and Atlanta. It is used in an

intranet-only environment.

The CARES application is a two-tier design which has a Web front

end. Customer calls arrive at a call center; the calls are then directed to

an available customer representative who uses a Web-browser form to

enter the customer name and account number. The form causes a

transaction to be sent to the database and the results fill out the form

on the Web browser with customer history information, so the

representative can assist the customer in an informed manner. The

transaction is accomplished with a single HTML form so there is no

need for maintaining state.

Figure A-1 Schematic Flow of the Application

Web server

VBapplication

CGI

ODBC

Telephoneswitchnetwork

Billing andcustomerhistory

TELNET

Web browser Tier two

Customeractivitylogs

A


Module 2 Case Study

DirectContact, Inc. (Continued)

If the inquiry relates to the customer’s service availability, a

transaction must be sent to the active telephone switch which holds

the customer’s recent activity logs. This is done using a TELNETremote login to the switch and a specially generated user ID and

password. This transaction interrogates the switch in real-time. The

switches run on UNIX environment servers, networked together.

The customer service representatives use Windows 95 PCs with

Netscape Navigator browsers. The server runs a Netscape Web server

on Windows NT. The form is handled by a CGI script and an

application written in VisualBasic+. The application accesses data

stored in a Microsoft SQL Server database. The business logic and

database access logic are both hard coded in the VisualBasic+

application and are hard to separate out. The application interrogates

the switch in real time to obtain error statistics and logged information

pertaining to the customer.

The Windows NT server is approaching maximum capacity. The

customer perceives that this solution will not scale enough for its

current growth rate, and wants to know if:

1. A Java technology solution can provide more scalability. If so,

how?

2. A Java technology solution can provide more performance, and

how can this be demonstrated, predicted and measured?

3. There would be advantages in a pure object-oriented

environment. How would an object application access the switch,

which is non-object?

4. They can develop a Java technology solution without doing

object-oriented analysis. DirectContact feel that they have no

experience in this area.

5. High-availability can be guaranteed with Java technology and

objects. If so, how?

A


Module 2 Case Study

Constraints

With over 250 service operators in three regional locations servicing a

customer base of 25,000 customers (and growing), the customer prefers

to keep the existing front end, to reduce training requirements and

productivity dips. Thus, your solution needs to process an HTML

form, access the database, and then access the switch, all in real-time.

The customer has decided to standardize on Netscape products for

both the Web browser and the Web server.

The customer has not standardized on a SQL Server as a database, and

is interested in your recommendations.

Since the customer is asking for proof of performance and proof of

concept, you will probably have to develop a prototype so that you

can show the customer the improved performance and flexibility.

A


Module 2 Case Study

Notes

A


Module 3 Case Study

Instructions

Work in teams to produce the deliverables described below. At the end



● Read and familiarize yourself with the case study that follows

these instructions.

● Prepare for a meeting with the customer’s technical architects

tomorrow. There are two deliverables expected from you:

1. Describe the advantages of a multi-tiered enterprise architecture

with respect to the customer’s application.

▼ How would you describe their current architecture in terms

of tiers?

▼ What problems do you see in the current architecture?

▼ What questions do you have for them that will help you

design an architecture?

2. Sketch out a three-tier architecture. This should show the tiers

and the interfaces between the tiers. Focus on the packages (of

classes) that are responsible for the workflow management.

Consider the following:

▼ Should the Internet-based quote request mechanism be an

applet, or an HTML form (possibly with JavaScript

extensions)? How will this communicate with the middle tier?

▼ Should you preserve the Smalltalk presentation and business

logic (which currently runs on the Insurance Agent’s PC), as a

Smalltalk program, or convert it to Java technology? If the

Smalltalk application is split up, how will these components

communicate with each other, and with the databases?

▼ What additional business logic is needed? What other new

features are needed, and how will they be implemented?

▼ How will middle-tier services access data and programs on

the mainframe?

A


Module 3 Case Study

Dynaclaim, Inc.

Dynaclaim Inc. is an insurance company providing auto and home

insurance to customers throughout the United States. They have no

offices, and instead offer their services exclusively through a toll-free

telephone number.

Dynaclaim’s work flow is as follows:

1. A prospective customer calls the “800” number and is connected

to a Customer Service Representative (CSR).

2. The CSR enters the customer’s personal information, and any

other information required for producing a quote. This

information depends on the type of quote (auto, fire, life or

home), on state regulations that vary according to the customer’s

home address, and on the customer’s answers to specific

questions. This information is stored in a DB2 database on the

mainframe.

3. The CSR generates a Request for Quote (RFQ).

4. An Insurance Agent (IA) receives the RFQ. Using the Smalltalk

QuickQuote application, the IA gathers the information needed,

generates a quote, and sends it to the customer using phone, fax,

email, or standard mail. Using the QuickQuote application, the

IA performs the following functions:

a. Pulls the next pending RFQ from a DB2 database “queue”

according to the type of quote requested. Agents have

different backgrounds and specialties, and the application

maintains an “agent profile” in a file stored on the local disk.

b. Enters values from the RFQ to create a batch request to the

mainframe for base rate and standard adjustment

information. The IA specifies the details of the actuarial data

that are needed. Many of these are dependent on the

customer situation.

A


Module 3 Case Study

Dynaclaim, Inc. (Continued)

c. An application on the mainframe extracts the required

actuarial data from an IMS database. The data are stored in a

flat file, which is transferred to the QuickQuote application

running on the agent’s PC. During transfer, the PC is not

available for other operations.

d. When the data file is returned from the mainframe, the IA

initiates a premium calculation. The IA manipulates the

Smalltalk expert system interactively, using the downloaded

data, to produce a competitive quote. This calculation is

compute intensive, and while it is running it is not possible to

run other applications or to process other RFQs. Only a subset

of the downloaded data is used in the premium calculation.

The IA may then refine the quote based on their knowledge of

the specific customer (for example, what has the customer

paid previously for insurance and what amount can the

customer tolerate). The agents are paid a commission fee so

they need to produce the maximum rate that can be tolerated

by the customer.

e. Once the premium is calculated, the IA can call the customer

directly, and can select other formats for generating a written

quote (fax, email, or standard mail). The IA then oversees the

customer order.

f. Customers purchase the insurance by signing a contract and

mailing a check to Dynaclaim.

The turnaround time for a quote is one hour, measured from the time

the customer connects to the CSR to the time an Insurance Agent calls

the customer with a quote. Dynaclaim has kept this time to one hour

by hiring additional IAs as business has grown. The IAs are experts in

the sense that they are highly skilled at using the QuickQuote

application.

A


Module 3 Case Study

Dynaclaim, Inc.

Systems Architecture

Dynaclaim’s system architecture includes the following elements:

● IBM System 390 mainframe running

▼ An IMS hierarchical database containing base insurance ratetables and standard adjustment tables, both used to calculate aquote. A COBOL program, responding to batch requests fromthe Insurance Agent, runs on the mainframe, extracts data fromthis database and returns a flat file to the IA’s Smalltalkapplication.

▼ An IBM DB2 relational database (queue) containing the

customer information entered by the CSR.

▼ A data-entry application driving the 3278 terminals used by the

CSRs.

● 150 Pentium PCs, connected on Wide Area Network (128k),

running Windows 95

▼ The “QuickQuote” application written in Smalltalk, used by

the IAs to pull off the next RFQ, obtain rate information,

calculate a premium, and generate a quote in a variety of

formats

Figure A-2 Dynaclaim’s System Architecture

IBM 3278IBM System 390Pentium PC

IMS (actuarial data)DB2(work queue)

QuickQuote

WAN

InsuranceAgent

Batch requestto mainframe.

Data entry

Flat filereturned.

CSR Application (data entry)

A


Module 3 Case Study

Dynaclaim, Inc.

Requirements

Dynaclaim would like to re-architect their system with the following

goals:

● Provide a way for customers to obtain quotes over the Internet

with a turnaround time of two minutes, measured from when they

finish entering all required information and submit their request

● Reduce the turnaround time on phone requests to 7 minutes or

less

● Preserve the Smalltalk object-oriented expert system logic, which

is well-tested

● Enable IAs to run other applications on the PC while premiums

are calculated

● Increase the volume of business without increasing the IA

headcount

Note – The most important question is why does it take one hour to

produce a quote? Where is the time being spent; what is the

bottleneck? This understanding will be crucial to the success of a

proposed architecture.

A


Module 3 Case Study

Dynaclaim, Inc.

Requirements (Continued)

Due to the design of the QuickQuote application (single threaded) and

the load it places on the system, Insurance Agents can handle only one

RFQ at a time, so they must wait while data is downloaded and

premiums are calculated. Average time breaks down as follows:

● CSR interview = 15 minutes

● Time in queue = 15-20 minutes

● Insurance Agent creation of batch request = 10 minutes

● Queuing on mainframe before batch job runs = 5-7 minutes

● Data file download = 1-2 minutes (approximately 500Kb)

● Insurance premium calculation = 2 minutes

● Quote preparation = 5 minutes

A


Notes

A


Module 4 Case Study

Instructions

Work in teams to produce the deliverables described in this section. At

the end of the allowed time, each team should present their solutions.



these instructions.

2. Prepare for a meeting with the customer’s technical architects

tomorrow. There are three deliverables expected from you:

a. Assessment of the options for integration or migration.

b. Draw the architecture, including communication between the

tiers.

c. Define the business objects needed for storing the POs and

PRs.

Deliverable 1

Assess each of the migration options available to the customer:

● Screen scraping.

● Partial migration. This would involve rewriting the client and

business logic in the Java programming language, and integrating

the result with the existing data.

● Redesigning and rewriting the entire application and data in the

Java programming language.

For each option, determine:

● Does it meet the customer’s needs?

● What value does it bring to the workflow?

● What are the associated costs?

● What are the associated risks?

A


Module 4 Case Study

Instructions

Deliverable 1 (Continued)

● How would the company handle the transition to Java

technology? For example, would there be a period of parallel

running with both the old and new systems running together?

How might the company keep data synchronized in this situation?

Deliverable 2

Draw the architecture for integrating the client and tier-two logic with

the existing mainframe back-end systems.

What additional objects are needed for communication between the

tiers?

Deliverable 3

Make a list of the objects needed for storing the purchase order and

purchase request objects.

A


Module 4 Case Study

Plastic DeSign, Inc.

Plastic DeSign Group is a division of a large world-wide

manufacturing company that produces plastic parts and products.

Your company has put out a bid for migrating the purchasing systems

from the current mainframe environment. You have been asked to

review the bid and produce an architectural design.

Figure A-3 Plastic DeSign’s Current System

Administratorobtainsapprovals forform

Purchasingofficerreviews PR

1st levelapproval

2nd levelapproval

3rd levelapproval

Purchaserequest (PR)entered inmainframe

Negotiateprice andapprove

Purchaseorder (PO)

PO mailed tovendor

Mainframeaccountspayablesystem

Othermainframeaccountingsystems

Requestercompletesform

A


Module 4 Case Study

Plastic DeSign, Inc. (Continued)

The current system of processing purchase requisitions is manual:

1. Requesters fill out a paper form to initiate the purchase request.

The paper form is then passed to an administrator who obtains

signature approvals from the designated approvers. This process

is a serial process and can take up to two weeks to get all the

requisite signatures.

2. When all the signatures are in place, the purchase request is

entered into an IBM system/390 mainframe system from an IBM

3270 terminal. This creates a purchase request (PR) in the

mainframe database. The mainframe database is a hierarchical,

proprietary database that can only be accessed using IBM CICS

transactions.

3. The purchasing officer (buyer) reviews the PR from a Macintosh

computer with IBM 3270 emulation, and, if funding is approved

and available, converts the PR into purchase order (PO). The

vendor is selected and the PO is printed and mailed to the

vendor.

Requirements

PlasticDesign must modify the mainframe application because it is not

Year 2000 compliant. Additionally, they want to take the opportunity

to streamline the purchase order workflow. They are assessing

whether to rewrite the application from scratch (which involves

converting the purchase order database to an ODBMS or RDBMS), or

simply to provide a Web-based front-end to the mainframe purchasing

data.

They are interested in what object design and Java technology can

bring to the table, though they have little object-oriented experience

beyond a few two-tier applications developed using Microsoft

VisualBasic and PowerSoft PowerBuilder.

The new system must support 500 concurrent users, with a total user

population of 3000.

A


Module 4 Case Study

Plastic DeSign, Inc. User Requirements

For this application, there are five main types of user. These

paragraphs describe their roles and responsibilities.

1. Requester. The originator of the PR should be able to enter the

request directly into the system, from any system on the

company network. There should be a login process that uses the

same user IDs and passwords as the mainframe IBM Resource

Access Control Facility (RACF) security system, so that users do

not have to remember a second password. The requester may

create a brand new requisition, an amended requisition from a

previous requisition, or a requisition to extend an existing PO.

2. Administrator. In the current system the administrator manually

enters the data into the system. This will be unnecessary in the

new system, but, the administrator may take on the role of the

requester instead.

3. Approver. The approver(s) should be notified immediately if

there is a PR for them to approve. They need to be able to take

any of the following actions:

a. approve and forward to the next level of approver (if any).

b. edit the PR and then forward.

c. cancel the PR, providing a reason, and notify the requester.

d. return to the requester for changes.

4. Buyer. The purchasing officer needs to be able to locate

prospective vendors by type of product or service. There may be

multiple vendors within in a single PO.

5. Vendors. The supplier of goods. There is a new requirement that

the company wants to allow vendors to check the status of their

POs (this requires additional security). Because of this, the

vendors are part of the system domain in the new architecture.

There could also be other users:

● Auditors

● Finance to check POs against departmental budgets

A


Notes

A


Module 6 Case Study

Instructions

Work in teams to produce the deliverables described here. At the end




these instructions.

2. Prepare for a meeting with the customer’s security specialists

tomorrow. There are two deliverables expected from you:

a. List the security requirements for this application. Explain

how these requirements can be addressed. Can these

requirements all be met by Java technology? If not, what must

be purchased or written?

b. Sketch out a three-tier implementation architecture for this

application. What constraints do the security requirements

impose on the architecture? Refer to the whitepaper on JDK

1.2 security that the instructor hands out.

A


Module 6 Case Study

UV Management Group

UV Management Group is a real-estate management firm that

manages and maintains commercial real estate (residential and office

buildings) across the United States. They sub-contract much of the

maintenance work (such as repairs and cleaning) to contracting

companies located near to each individual building.

Sub-contractors must file quarterly inspection reports on the condition

of the building and grounds. These reports cover each major sub-

system of the building (heating, ventilation, air conditioning, water,

elevators, and so forth) and photographs of the exterior and interior of

the building.

UV Management Group would like to use these reports to do trend

analysis on the conditions of each building. This would allow them to

spot problem properties, and under-performing sub-contractors,

earlier. Unfortunately there are several problems with the current

system which prevent them from achieving this.

● Currently the system uses paper forms which must be keyed into a

database before any analysis can be done on the data. The data

entry job is frequently under-staffed and sometimes ignored,

resulting in out-of-date records in the database and unfiled paper

gathering dust in folders.

● The current system uses textual descriptions of the properties.

These descriptions are highly subjective. Is a building with a “very

good” roof and a boiler that “needs extensive repair” in better or

worse shape than a building with an “OK” roof and an “OK”

boiler?

● There is no standard for submitted photographs. One building

supervisor might take photographs of the entry and lobby.

Another might take photographs of the entire exterior and roof.

Even when photographs of the same part of the same building do

accompany successive reports, different lighting conditions

associated with the time of year make it hard to compare the

photographs from one quarter to the next.

● The photographs are not scanned so there is no electronic way to

review them.

A


Module 6 Case Study

Application Requirements

In order to solve these problems UV Management plans to implement

a Web based reporting system. An applet will replace the current

textual form and will include

● Numerical ratings of each important category

● Objective guidelines on how to assign the numbered rates

The sub-contractors will submit their reports over the Internet. The

system will automatically enter the new report into the database. As

part of the roll-out for this product UV Management will share the cost

of digital cameras for each sub-contractor and define a series of

standard photographs that must be submitted with each report. These

images will be transferred to the PC used by the supervisors to submit

the report. The applet implementing the Web form must be able to

read these images and attach them to the report.

A


Module 6 Case Study

Security Issues

The architecture and deployment plan must address several security

issues:

● Firewall – Since this application will expose parts of UV

management’s internal IT systems to the Internet, there must be an

adequate firewall in place to protect these systems.

● Client side file access – The applet must be able to access the sub-

contractor’s PC’s file system—something applets are normally not

allowed to do.

● Firewall protocols – UV Management has no control over what, if

any, firewall is running on the sub-contractor’s side of the

network, nor over how it is configured.

● Data privacy – While the reports are not as sensitive as medical

data or financial records, they are proprietary information and

should be reasonably protected from unauthorized viewing by

anyone on the Internet.

● Access controls – While sub-contractors must be able to pull up

and review reports for buildings under their control, they must

not be able to access records for any other property. Furthermore,

UV Management’s internal users are not allowed free access to the

data. Some users are allowed to access records only for buildings

for which they are directly responsible. Others users, like auditors

and managers have much greater access.

A


Notes

B-1Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

References B

This appendix contains references for each of the course modules, and

in addition, includes the following:

● Evolution of the JDK

● Benefits of the Java platform

● Java programming language packages

● Java programming language APIs

B

B-2 Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Evolution of Java Technology

JDK 1.0

JDK 1.0 contains

● lang , util , io , net and awt packages

● No printing support

● No database access

● Sandbox security

● No GUI widgets in AWT

JDK 1.1

JDK 1.1 includes

● JDBC

● RMI

● JavaBeans

● AWT enhancements

● Delegation (JDK 1.1) event model

Note – You cannot mix JDK 1.0.2 and JDK 1.1. event models.

● JNI

● Internationalization

● JAR files

● Security enhancements

● APIs for digital signatures and message digests

● Signed JAR files

● Signed applets

● Reflection

B

References B-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Evolution of Java Technology

JDK 1.2

JDK 1.2 consists of

● Java Foundation Classes (JFC)

▼ Swing

▼ JFC which runs on top of AWT

▼ JFC components which are JavaBeans

▼ Drag and drop tools

▼ Two dimensional (2D) graphics

● Security enhancements

▼ Java Protected Domains

▼ Configurable security policy

▼ Support for x509v3 certificates

▼ SSL sockets

● RMI enhancements

▼ Remote object activation

● Java IDL (CORBA)

▼ Java to IDL compiler

▼ Java ORB

● Servlets

● Native thread support

B


Benefits of Java Technology

Some of the benefits of Java technology are

● Platform independence (client, server)

● Decouples application from platform

● 100% Pure Java technology

● Extensive API set

● Server-side Java

● Enterprise Java APIs

● Security

● Compile time and runtime protection

● Memory protection

● Extensible security using Java Security API

● Extensible to non-traditional devices

● Components (JavaBeans, Enterprise JavaBeans)

● Code distribution (applets, servlets)

B


Java Technology Packages

Table B-1 lists some of the Java technology packages and their uses.

Table B-1 Java Technology Packages

Name Use

java.applet Graphics and audio for applets

java.awt GUI component classes, delegation eventmodel, dynamic query of componentproperties, printing, and pop-up menu

java.beans Software component model using eventpassing, may also connect to ActiveXcontrols

java.io File stream read and write, objectserialization

java.lang ClassLoader, SecurityManager, Threads,Runtime, Exceptions, System level control

java.lang.reflect Reflection used to introspect the data fieldsand methods of a Bean class

java.math Conversion precision

java.net TCP/IP socket support, UDP socket support,URLs, encoding to MIME format

java.rmi Java technology to Java technology remoteobject methods execution through whatappears to be local object references

java.security Digital signatures, data encryption, keymanagement and access control

java.sql Database access using SQL (drivers arevendor supplied), use Intersolv bridge forODBC databases

java.txt Text formatting and searching,internationalization

java.util Calendar, date, locale, time zone, system anduser defined properties, StringTokenizer(parser)

B


Summary of Java Technology APIs

Some of the Java technology APIs are listed in Table B-2.

Table B-2 Java Technology APIs

EnterpriseAPI Set

ComponentModel

UserInterfaceAPI Set

LowerLevel APIs Miscellaneous Media

API Set

JNDI (Java

Naming and

Directory

Interface)

JavaBeans AWT

(Abstract

Windowing

Toolkit)

JMS (Java

Message

Service)

JavaMail (to mail-

enable Java

applications)

Two

dimension-

al (2D)

RMI (Remote

Method

Invocation)

Enterprise

JavaBeans

JFC (Java

Foundation

Classes)

JTS (Java

Transaction

Service)

JavaComm

(Device

Communications)

Three

dimension-

al (3D)

JDBC (Java

Database

Connectivity)

JavaHelp (for

adding on-

line help to

Java

applications)

Java Media

Framework

JavaIDL (Java

technology to

CORBA

connectivity)

Java

Accessibility

API (for

creating

applications

for users with

disabilities)

JTAPI (Java

Telephony

API)

Java Security

API

Java Sound

JMAPI (Java

Management

API)

JavaSpeech

Java

Advanced

Imaging

API

B


Module 1 References

Table B-3 lists some references that contain additional information on

the topics covered in Module 3, ‘‘Introduction to the Java Technology

Architecture Process.

Table B-3 References for Module 3, ‘‘Introduction to the Java TechnologyArchitecture Process”

URL Description

http://www.sun.com/javacenters Sun Java Centers Web site

http://java.sun.com/jdc/ Java Developer Connection (subscriptionsite offering support for Java technologydevelopers)

http://www.omg.org Object Management Group (contains thespecification for CORBA)

http://www.rational.com Rational Software Corporation (containsdefinitions of the OMT and UMLtechniques)

http://www.sei.cmu.edu/architecture Software Engineering Institute (part ofCarnegie Mellon University in theUnited States)

http://hillside.net/patterns Design patterns home page

http://java.sun.com/products Overview of Java technology products

http://www.microsoft.com/com Distributed Component Object Model(DCOM) information

B


Module 2 References

Table B-4 lists references that provide additional information on the

topics covered in Module 3, ‘‘Designing a Java Technology

Architecture.”

Table B-4 References for Module 3, ‘‘Designing a Java TechnologyArchitecture”

URL Description

http://java.sun.com/products/java-server/ Information about servlets

http://www.cisco.com Load balancing hardware

http://www.resonate.com Load balancing system

B


Module 3 References

Additional information on the topics covered in Module 3, ‘‘Java

Technology Architecture Details “ can be found at the URLs listed in

Table B-5.

Table B-5 References for Module 3

URL Description

http://java.sun.com/jdc Java developer information site

http://www.roguewave.com Vendor of Java technology widgets

http://www.objectspace.com Vendor of Java ORB product

http://www.inprise.com Vendor of VisiBroker, Java ORB product(formerly Borland)

http://www.omg.org Object Management Group site

B


Module 4 References

Table B-6 lists URLs that contain information on the topics covered in

Module 3, ‘‘Integration With Existing Applications and Databases.”

Table B-6 References for Module 3, ‘‘Integration With Existing Applications andDatabases”

URL Descriptions

http://java.sun.com/jdbc/jdbc.drivers.html How to choose a JDBC driver

http://www.odmg.org The Object Database ManagementGroup

http://www.software.ibm.com IBM software site for DB2, IMSand CICS information

http://www.ibi.com Information Builders (databasegateway)

http://www.intersolv.co m JDBC drivers

http://www.novera.com Object-relational mappingvendor,Novera application server

http://www.persistence.com Object-relational mapping vendorand ODBMS

http://www.weblogic.com Object-relational mapping vendor

http://www.roguewave.com Object-relational mapping vendorand JDBC drivers and tools

http://www.versant.com ODBMS vendor

http://www.objectivity.com ODBMS vendor

http://java.sun.com/products/java-blend JavaSoft object-relationalmapping

http://www.hursley.ibm.com/mqseries IBM messaging information

http://www.openconnect.com WebConnect screen scraperproduct

http://www.sun.com/products-n-solutions NetraJ software with WebConnectbundled

http://www.insignia.com NTRIGUE screen scraper product

B


http://www.citrix.com WinFrame screen scraper product

http://www.graphon.com Go-Joe screen scraper product

http://www.bluelobster.com Blue Lobster Software, mainframeintegration products

http://www.microsoft.com Microsoft Terminal Server

http://home.netscape.com Netscape Application Server

http://www.netdynamics.com NetDynamics application server(now part of Sun)

http://www.weblogic.com Weblogic Tengah applicationserver

http://www.vitria.com Integration product based onmessaging

http://java.sun.com/products/jdbc/ JDBC 2.0 specifications

Table B-6 References for Module 3, ‘‘Integration With Existing Applications andDatabases” (Continued)

URL Descriptions

B


Module 5 References

Table B-7 lists some references that provide additional information on

the topics covered in Module 3, ‘‘Creating New Application

Architectures.”

Table B-7 References for Module 3, ‘‘Creating New Application Architectures”

URL Description

http://webwork.eng.sun.com/products/jndi Information on Java Naming andDirectory Interface (JNDI)

http://www.sun.com/suntest Java software testing tools

http://java.sun.com/beans JavaBeans component model

http://www.marimba.com Marimba push technology

http://www.ibm.com CICS and Encina EJB servers

http://www.hursley.ibm.com/mqseries IBM MQSeries messagingmiddleware

http://www.beasys.com Tuxedo EJB server

http://www.tibco.com Publish/subscribe vendor

http://www.weblogic.com EJB server vendor (Tengah)

http://www.oracle.com EJB server vendor

http://www.persistence.com EJB server vendor

http://www.sybase.com Sybase Jaguar CTS EJB server

http://www.gemstone.com EJB server vendor

http://www.inprise.com EJB server vendor

http://www.ejbhome.com Miscellaneous EJB informationand links

B


Module 6 References

The list of URLS in Table B-8 provide additional information on the

topics covered in Module 3, ‘‘Designing a Secure Java Technology

Architecture.”

Table B-8 References for Module 3, ‘‘Designing a Secure Java TechnologyArchitecture”

URL Description

http://www.rsa.com RSA Data Security supplies encryptionalgorithms

http://www.novera.com Novera management server (supportssecurity)

http://java.sun.com/security Security information from JavaSoft

http://java.sun.com/sfaq Security frequently asked questions

B


Module 7 References

Table B-9 contains references that can provide additional information

on the topics covered in Module 3, ‘‘Designing an Architecture for

Performance.”

Table B-9 References for Module 3, ‘‘Designing an Architecture for Performance”

URL Description

http://www.sun.com/suntest Sun’s testing unit(JavaStar™, JavaScope™, JavaLoad,and JavaSpec™)

http://www.specbench.org SpecWeb96 and SpecWeb98 site

http://www.klg.com/jprobe Jprobe Profiler tool

http://www.parasoft.com/wizard CodeWizard Java technology sourcecode analysis tool

http://www.optimizeit.com OptimizeIt profiling tool

http://www.marimba.com Castanet push technology

http://www.cisco.com LocalDirector load balancer

http://www.ResonateInc.com Load balancing vendor

http://www.segue.com Automated test tools vendor

http://www.merc-int.com Automated test tools vendor

B


Module 8 References

Additional information on the topics covered in Module 8 can be

obtained from the URLs listed in Table B-10.

Table B-10 References for Module 8

URL Description

http://www.novera.com Java application monitoring

http://www.bmc.com Systems management tool vendor

http://www.tivoli.com Systems management tool vendor

http://java.sun.com/products/javasafe Java technology source codemanagement

Glossary-1Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Glossary

4GLFourth-generation language, which is a non-procedural languagedesigned for ease of use. It is typically used to develop two-tierapplications that access relational databases.

ActiveXAn object component that communicates with distributed objectcomponents using Microsoft’s Distributed Component Object Model(DCOM).

AppletJava software that is dynamically loaded by a Web browser from aWeb server when an<applet> tag occurs in an HTML page.

AppletViewerA standalone program that can be used to run and test Java applets.

AuthenticationThe process of verifying that someone’s claimed identity. Techniquescan include using passwords and digital signatures.

ClassAn encapsulation of the attributes and methods that describe an object.The class is the template for individual object instances.

Client-serverA term used to describe a two-tier application architecture.

Client stubAn interface used by a client-based object that contains theinformation needed to invoke a method on a remote object in aCORBA network. The remote object reference held by the clientpoints to the client stub. This stub is specific to the IDL interface fromwhich it was generated.

Glossary-2 Java Technology Architecture Planning and DesignCopyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

ComponentA piece of software with special interfaces that enable it to plug intoother software components as a building block. Components can beassembled into new object applications.

Component modelEnables developers to create new applications using pre-existingsoftware components such as JavaBeans and ActiveX controls. Acomponent model provides certain services including: componentinterface publishing and discovery, event handling for componentcommunication, persistence for component storage, layout control,and support for application builder tools.

CORBACommon Object Request Broker Architecture (CORBA) from theObject Management Group (OMG) is a specification for standards-based object interoperability.

Core LibrariesThe basic set of classes that is shipped with the JDK.

DCOMDistributed Component Object Model; the component model fromMicrosoft.

Digital certificateA digitally signed statement from a trusted entity that vouches for thevalidity of another entity’s public key. Digital certificates are used forauthentication purposes. The certificate associates the specified publickey with its owner.

Digital signatureA string of bits that is computed from some data (the data being“signed”) and the private key of an entity. The signature can be used toverify that the data came from the entity. It cannot be forged as long asthe private key is kept secret.

Distributed object computingA framework for computing based on the convergence of object-oriented and client/server technologies. Distributed object computingblends the distribution advantages of client/server technology with therichness of real-world information contained in object-orientedmodels.

Enterprise JavaBeansAn API that extends the JavaBeans component model, enabling it torun on the server side.

Glossary Glossary-3Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1

Entity-relationship diagramA data model for the design of a relational database. Entities arethings of significance within the business being modeled and therelationships show how the entities communicate and associate witheach other.

HTTPHypertext Transfer Protocol; the most common protocol used on theWorld Wide Web to transfer Web pages (documents with embeddedhypertext links). This protocol runs over TCP.

IETFInternet Engineering Task Force; oversees and maintains Internetstandards such as TCP/IP.

IMAPInternet Message Access Protocol; an Internet protocol for accessingmail on remote mail servers.

Interface Definition Language (IDL)The OMG-standard language used for defining the interfaces forCORBA objects. An IDL interface declares a set of operations,exceptions, and attributes. OMG IDL does not includeimplementations for operations; rather, as its name indicates, it is alanguage for defining interfaces.

Internationalization (I18N)A standard providing support for different languages and cultureswithout having to change the source code of an applet or applicationby calling generalized methods that load data translated into thecorrect language.

Internet InterORB Protocol (IIOP)The OMG-specified network protocol for communicating betweenORBs. Java IDL conforms to IIOP Version 1.0.

JAR fileThe Java archive file format. Multiple files are collected together intoone file. The resulting JAR file is additionally compressed, and can besigned using digital signatures. JAR files may be accessed using theARCHIVES parameter of the HTML<applet> tag, or directly byapplets, applications, and operating system tools. The JAR format iscompatible with the ZIP format.

JavaBeanA reusable software component written in the Java programminglanguage that can be manipulated using a visual builder tool.


JavaBeansA set of APIs that is used to build the component model for Javaapplications.

JavaIDL APIA set of classes and interfaces that are used to define remote objectinterfaces using the CORBA IDL standard. JavaIDL maps to a set ofstubs and skeletons that can be used in a CORBA implementation.

JavaScriptA scripting language from Netscape that is embedded directly intoWeb pages. It is used to add interactivity and validation checking toWeb pages.

JDBCJDBC is an API used by Java applications to access databases usingthe SQL standard syntax.

JDKThe Java Development Kit, which can be downloaded from theJavaSoft Web site and includes Java libraries (packages), compilers,utilities and debuggers used to develop Java source code.

JVMA runtime environment for running Java applets and applications. AJVM is embedded in most Web browser products.

KeyA number that is used to encrypt or decrypt a message, or to sign orverify a message. Longer keys are generally more secure than shorterones. See alsoPrivate KeyandPublic Key.

Localization (L10N)A method used to translate a user interface into the language set of aspecific region or country including local date formats and currencies.

Message digestA function that generates a hash value (or digest) from a specified setof data. The hash value is unique to the data string. The digest can beused to verify that the data has not been altered since it was sent overthe network.

MVCModel-View-Controller (MVC) is a framework for modeling anddesigning GUIs in object-oriented programs such as Smalltalk.


ObjectsSelf-contained software packages consisting of private information(data), private operations (methods) that manipulate private data, and apublic interface (methods) that provides a means of communicatingwith the object. Objects interact by passing messages to each other.

Object methodCode that is executed in response to a message being sent to theobject. There are two types of object methods: interface methods thatallow communication with the object; and internal methods which arenot accessible from outside of the object.

Object modelingA method for modeling the way that businesses operate in the realworld. Objects add value over other ways of modeling by reducingcomplexity and abstracting to a higher-level perspective.

Object-oriented frameworkAn implementation of a set of abstract and concrete object classes thatcollaborate. The framework classes are generic, since they must bemapped to provides hooks for customization or extension.Frameworks enable re-use of object code, as well as object models.

Object referenceA way of identifying an object within an ORB. An object reference isused in method invocations to locate a CORBA object. Objectreferences are the CORBA object equivalent to programminglanguage-specific object pointers. Multiple object references can referto the same CORBA object.

Object Request Broker (ORB)Object-oriented middleware that enables objects to transparentlylocate and activate other objects on a network, regardless of theprocessor type or programming language. ORBs remove the networkcomplexity from the developer.

Object wrappersNon-object code can be “wrapped” and appear to be an object withobject interfaces that can participate in a distributed objectenvironment. The wrapper represents legacy code as well as a realobject.

ODBCOpen Database Connectivity; a standard API from Microsoft that canbe used to access various SQL databases using a common API. ODBCdrivers are supplied by database vendors and third-party softwarecompanies.


PersistenceObjects normally cease to exist once the process that created themends. Any technique that allows objects to be stored betweeninvocations of the programs that use them may be described aspersistence.

Port numberA port number is used in TCP systems to identify the type ofincoming request. By convention, TCP protocols such as FTP andHTTP use specific port numbers.

Private keyKeys are used for encryption and digital signatures (seeKey). Aprivate key is typically kept secret by an individual or organization. Itmay then be used to decrypt messages sent using the correspondingpublic key, or to sign messages for public distribution. A private key isalways associated with a single public key. Note that sometimes theterms private key and public key are used in the opposite sense whendiscussing digital signatures. That is, the term private key issometimes used to mean the key used for decryption; in digitalsignatures, this is the key that is given out freely.

Public keySee alsoPrivate Key. A public key is made freely available toeveryone who needs to have trusted interactions with that entity. Thekey is used to encrypt messages that may then be decrypted only bythe proper recipient (who holds the corresponding private key) or toverify a digital signature. Note also the warning about transposition ofthe terms public key and private key, mentioned under the entryPrivate key.

RMI APIRemote method invocation is an object interface that enables Javaapplets and applications to invoke methods that exist in remote Javaapplets and applications.

Screen scraperA middleware product that uses terminal emulation to connect to aterminal-based application. Using that connection, data can beprogrammatically extracted from, or inserted into, fields in theterminal-based interface. This allows new front ends to be added to theterminal-based program. For example, a GUI is commonly provided inplace of the old interface.


SMTPSimple Mail Transfer Protocol; the Internet standard email protocol,used to communicate between mail systems and propagate mail fromone system to another.

SocketAn API that enables two applications to engage in a bound session andexchange information over a network. Sockets are used by the HTTPserver as well as by Java software code. Sockets are most commonlyused on TCP/IP networks, but are sometimes found on other systems.

TCPTransport Control Protocol; the upper part of the TCP/IP protocolstack. TCP is responsible for reliability, flow-control, and ordering ofbidirectional data over the network.

TELNETA program used to log in to a remote server.

Terminal emulationA piece of software that provides a “green screen” on a client platformwindow of Web browser.

ThreadA lightweight execution context that uses less resources than aprocess.

Three-tier architectureAn evolution from client-server architecture, which separates theclient user interface, application business logic, and database access,and assigns them to separate tiers.

XMLExtensible Markup language; a successor to HTML.

Please

Recycle

Copyright 1999 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, California 94303, Etats-Unis. Tous droits

réservés.

Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la

copie, la distribution, et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune

forme, par quelque moyen que ce soit, sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.

Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un

copyright et licencié par des fournisseurs de Sun.

Des parties de ce produit pourront être dérivées du systèmes Berkeley 4.3 BSD licenciés par l’Université de Californie.

UNIX est une marque déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company Ltd.

Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaSoft, JavaBeans, Enterprise JavaBeans, JDBC, SunTea, 100% Pure

Java, JavaHelp, SunLink, JDK, JavaStation, JavaStar, JavaScope, JavaSpec, JavaScript, Java HotSpot, Java Workshop,

JavaOS, Java Naming and Directory Interface, Solstice Sunscreen, et NFS sont des marques de fabrique ou des marques

déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays.

Toutes les marques SPARC sont utilisées sous licence sont des marques de fabrique ou des marques déposées de SPARC

International, Inc. aux Etats-Unis et dans d’autres pays.

Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc. Netscape

Navigator est une marque de Netscape Communications Corporation.

L’interfaces d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses

utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour larecherche et le développement du concept

des interfaces d’utilisation visuelle ou graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive

de Xerox sur l’interface d’utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent

en place l’interface d’utilisation graphique OPEN LOOK et qui en outre se conforment aux licences écrites de Sun.

L’accord du gouvernement américain est requis avant l’exportation du produit.

Le système X Window est un produit de X Consortium, Inc.

LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET

GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA

LOI APPLICABLE, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE

MARCHANDE, A L’APTITUDE A UNE UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.

Date post:	24-Apr-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

JavaTechnologyArchitecturePlanning andDesign€¦ · Sun acknowledges the pioneering efforts of...

Documents