Java Technology Architecture Planning and Design

(1)

Sun Microsystems, Inc. MS BRM01-209

500 Eldorado Boulevard Broomfield, Colorado 80021 U.S.A.

®

and Design

Part Number 805-4478-01 Revision A.1, July 1999

SL-410

(2)

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).

(3)

iii

About This Course... xiii

Course Map... xiv

Module-by-Module Overview ... xv

Course Objectives... xviii

Skills Gained by Module... xix

Guidelines for Module Pacing ... xx

Topics Not Covered... xxi

How Prepared Are You?... xxii

Introductions ... xxiv

How to Use Course Materials ... xxv

Course Icons and Typographical Conventions ... xxvii

Icons ... xxvii

Typographical Conventions ... xxviii

(4)

Distributed Object Frameworks... 1-27 Object Languages ... 1-28 Basic Three-Tier Java Technology Architecture ... 1-30 Overview ...1-30 Applets, Applications, and Servlets ...1-33 Advantages of Three-Tier Architectures ... 1-34 Comparison of Three-Tier Communication Mechanisms ... 1-36 Overall Java Technology Architecture... 1-40 Java Technology Architecture Issues ... 1-42 Check Your Progress ... 1-43 Think Beyond ... 1-44

(5)

v

Tier One ...2-58 Tier Two ...2-59 Tier Three ...2-60 Three-Tier Advantages...2-60 Architecture Considerations Applied...2-61 ECARS Benefits ... 2-62 Exercise: Designing a High-Level, Three-Tier Architecture ... 2-63 Preparation...2-63 Exercise Summary...2-64 Check Your Progress ... 2-65 Think Beyond ... 2-66

(6)

Applet Rules ... 3-37 Tier Two Design Choices ... 3-39 MedBroker Tier Two Design Summary... 3-42 Trade-offs ...3-42 Services to Build into the Application ...3-44 Java IDL Architecture Overview ... 3-46 Tier Three Design... 3-47 The Final MedBroker Architecture... 3-49 Exercise: Design a Heterogeneous Object Architecture ... 3-51 Preparation...3-51 Exercise Summary...3-52 Check Your Progress ... 3-53 Think Beyond ... 3-54

(7)

vii

Performance Issues ...4-40 Assessing Screen Scrapers ... 4-42 Evaluating Alternate Architectures for QuickQuote ... 4-44 Review of Current Architecture...4-44 Alternate QuickQuote Database Architectures ...4-45 Using Messaging for QuickQuote Persistence ...4-46 Using an ODBMS for QuickQuote Persistence...4-48 Summary of Alternatives... 4-50 Exercise: Designing a High-Level Three-Tier Architecture ... 4-51 Preparation...4-51 Exercise Summary...4-52 Check Your Progress ... 4-53 Think Beyond ... 4-54

(8)

Architecture Implications ...5-41 Programmer Implications...5-42 The Publish/Subscribe Architecture... 5-43 Events...5-43 Publishers and Subscribers...5-44 Benefits of Publish and Subscribe...5-45 Publish/Subscribe and Three-Tier Architectures ... 5-47 Implementing Publish and Subscribe ...5-47 Publish/Subscribe Examples ...5-48 Assessing Publish/Subscribe Feasibility... 5-50 Assessing Alternate Architectures for PlasticDeSign, Inc... 5-51 PlasticDeSign, Inc. Case Study...5-51 Enterprise JavaBeans Alternative ...5-52 Publish/Subscribe Alternative...5-54 Check Your Progress ... 5-55 Think Beyond ... 5-56

(9)

ix

Security Comparison: JDK 1.1 Versus JDK 1.2 ... 6-37 Exercise: Evaluation of Security Architecture... 6-39 Preparation...6-39 Exercise Summary...6-40 Check Your Progress ... 6-41 Think Beyond ... 6-42

(10)

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

The Java Technology Architecture in Production...8-1 Relevance... 8-2 Objectives ... 8-3 Application Development Architecture ... 8-4 Application Test Architecture ... 8-5 Testing All User Configurations ...8-5 Test Configuration ...8-6 Additional Testing ...8-7 Deployment Architecture Analysis... 8-8 Application Deployment Considerations... 8-9 Production Services ...8-12 Mobile Users ...8-14 Network Computers... 8-15 Deployment Considerations for Enterprises ... 8-17 Applet and Application Distribution...8-17 Rules for Applet Distribution...8-19 Large Applications...8-20 Operational Issues... 8-22 Startup ...8-22 Troubleshooting ...8-23 Keeping Pace With Change ... 8-24 Versioning ...8-24 Reuse...8-25 Maintenance...8-26 Summary of Architecture Project Tasks ... 8-27 Architecture Checklist ... 8-29 Check Your Progress ... 8-30 Think Beyond ... 8-31

(11)

xi

Module 4 Case Study... A-15 Instructions ...A-15 Plastic DeSign, Inc...A-17 Requirements...A-18 Plastic DeSign, Inc. User Requirements...A-19 Module 6 Case Study... A-21 Instructions ...A-21 UV Management Group...A-22 Application Requirements...A-23 Security Issues ...A-24

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

(12)

(13)

xiii

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

(14)

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 Technology Architecture Details Designing a Java

Technology Architecture

Foundation

Introduction to the Java Technology Architecture Process

Advanced Principles

Creating New Application Architectures Integration With Existing

Applications and Databases

Security and Performance Principles

Designing an Architecture for Performance Designing a Secure Java

Deployment

(15)

About This Course xv

● _{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

(16)

● _{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.

(17)

About This Course xvii

● _{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}

(18)

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

(19)

About This Course xix

The skills forJava 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 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 CORBA and 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 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

(20)

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 Java Technology Architecture Process

A.M.

Module 2 – Designing a Java Technology Architecture

P.M.

Module 3 – Java Technology Architecture Details

A.M./P.M.

Module 4 – Integration With Existing Applications and Databases

P.M. A.M.

Module 5 – Creating New Application Architectures

A.M/P. M.

Module 6 – Designing a Secure Java Technology Architecture

P.M. A.M.

Module 7 – Designing an Architecture for Performance

A.M.

Module 8 – The Java Technology Architecture in Production

(21)

About This Course xxi

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:Java Analysis and Design Using UML.

● _{Java technology programming – Covered in SL-275:} _Java Programming

● _{Java technology distributed programming concepts and}

application programming interfaces (APIs) – Covered in SL-301: Distributed Programming with Java

(22)

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

(23)

About This Course xxiii

● _{List the common Java technology APIs and briefly describe the} purpose of each

(24)

(25)

About This Course xxv

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.

(26)

● _{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.

(27)

About This Course xxvii

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.

(28)

Typographical Conventions

Courieris used for the names of command, files, and directories, as well as on-screen computer output. For example:

Use ls -alto list all files. system% You have mail.

Courier boldis used for characters and numbers that you type. For

example:

system% su

Password:

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 rmfilename.

Palatino italicsis used for book titles, new words or terms, or words that are emphasized. For example:

(29)

1-1

Architecture Process

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

Java Technology Architecture Details Designing a Java

Foundation

Advanced Principles

Security and Performance Principles

Deployment

(30)

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}

(31)

Introduction to the Java Technology Architecture Process 1-3

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 Database} Applications. Prentice Hall.

● _{Fowler, Martin. 1997.} _{UML Distilled} _{Addison-Wesley.}

● _{Harmon and Watson. 1998.} _{Understanding UML: the Developers} Guide (With a Web-based Application in Java). Morgan.

(32)

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

Network architecture

Java technology architecture

Data architecture Security

(33)

What Does an Architect Do?

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}

(34)

What Does an Architect Do?

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

(35)

What Does an Architect Do?

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}

(36)

What Does an Architect Do?

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

(37)

What Does an Architect Do?

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}

(38)

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.

(39)

System Architecture in Perspective

An Example Process

Figure 1-2 Object-Oriented Deployment Project

Deployment use case diagrams

Unknown business build or buy

State, Process, Interaction, and Sequence diagrams

Build or buy tools Language choice

Object classes Reuse library UML package design OMT subsystem design

(40)

System Architecture in Perspective

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

(41)

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

(42)

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.

(43)

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

(44)

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.

(45)

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.

(46)

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

(47)

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

Business logic tier

API

TCP layer

IP layer

Network

Data access tier

API

TCP layer

IP layer

Network

(48)

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 differentdistribution modelsof the architecture. For instance, multiple tiers may beimplementedto run on the same hardware platform or on separate platforms, and

(49)

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

(50)

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

Server

(51)

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.

(52)

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,

Remote Method Invocation (RMI)

Object may receive arguments of

previously unknown types; classes may be loaded as needed. Object call to method

on another object. Parameters and return values are objects.

Internet Inter-ORB protocol (IIOP)

Object must receive arguments of known types. Methods must be preinstalled on server.

Object call to method on another object. Parameters and return values are structures.

RPC

Data and execution requests transferred between client and server. Procedures preloaded on server. Procedure call to

another program. Parameters and return values are structures.

Socket

Only data is

transferred between client and server. Interpretation must be explicitly coded. Socket call transfers

(53)

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.

(54)

Advantages of Distributed Object Architectures

(55)

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)

(56)

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

Standard

Implementation

Implementations may vary by vendor

(standard is maintained by Java technology licensing)

Implementations vary across vendors

(57)

Dependence

Cross-platform virtual machine (many

implementations)

Platform dependent Cross-platform virtual machine (few

implementations)

Security Provides security for

Internet (sandbox)

No built-in security for Internet

API Use Java technology API set

enhances usability of Java technology

Lack of enterprise APIs

Cost Sun’s JDK is free. Some development systems are chargeable

GNU is Not UNIX (GNU) compilers are free, otherwise there may be a small cost for the compiler

Cost issue for Smalltalk environment

Features Safe language (no

pointer manipulation) and garbage collection

Pointers and memory leaks

Garbage collection

Table 1-1 Comparison of Object Languages (Continued)

(58)

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 two Tier three

• User interface • Input validation

• Data input • Local

calculations

• Business logic

• Business rules • Client session

management

• Database connection • Remote object

access

• Web browser with optional Java applet

• Java application

• Web (HTTP) server

• Java application or servlet • Non-Java application

• Middleware such as transaction monitors • Protocol converters

• Terminal emulators

• Database products

• Legacy products and applications

• Transaction processing systems Logical application view

(59)

Basic Three-Tier Java Technology Architecture

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}

(60)

Basic Three-Tier Java Technology Architecture

Overview (Continued)

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} technology architecture.

(61)

Basic Three-Tier Java Technology Architecture

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 applicationsare 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).

(62)

Advantages of Three-Tier Architectures

(63)

(64)

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.

(65)

Comparison of Three-Tier Communication Mechanisms

Table 1-2 Three-Tier Communication Mechanisms

Asynchronous Synchronous Conversational/ Peer-to-Peer

Application Characteristics

Loosely coupled application design. No wait time.

Tightly coupled application design. Wait time for remote procedure to execute.

Tightly coupled application design.

No wait time.

Network Characteristics

Can work in disconnect mode. Network does not have to be

available.

Network must be available.

Performs best on high-speed local

Better for high-performance

Example Message queuing

IBM MQSeries.

Remote procedure call.

(66)

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.

(67)

(68)

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

Client

(69)

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)

(70)

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)

(71)

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++

(72)

Think Beyond

(73)

2-1

Architecture

2

Course Map

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

Basic Principles

Java Technology Architecture Details

Designing a Java Technology Architecture

Foundation

Advanced Principles

Security and Performance Principles

Deployment

(74)

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?

(75)

Designing a Java Technology Architecture 2-3

Objectives

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

● _{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} technology architecture

References

Additional resources –The following references can provide additional details on the topics discussed in this module:

● _{Berg, Daniel J. and Fritzinger, Steven.} _{Advanced Techniques for Java} Developers.Wiley. 1998.

(76)

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

Expense request

Expense report

Request approval

Approval code Email

Database Email

Email

Audit checks Expense

payment Expense

approval Employee

(77)

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

(78)

Customer Application

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.

(79)

Customer Application

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.

(80)

Architecture Analysis

Customer Appraisal

When preparing the appraisal, determine: ● _{What the prime issue is for this customer}

(81)

Architecture Analysis

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.}

(82)

Architecture Analysis

Java Technology Architecture Assessment

What advantages will the three-tier Java technology architecture provide 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.

(83)

Architecture Analysis

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.

(84)

Architecture Analysis

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:

(85)

Architecture Analysis

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

(86)

Architecture Analysis

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.

(87)

Architecture Analysis

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?

(88)

Architecture Analysis

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}

(89)

Architecture Analysis

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?

(90)

Architecture Analysis

Readiness of Customer (Continued)

(91)

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 a geographic region (for example, English/USA, French/Canada, or German/Switzerland).

● End users, or their system administrators, can specify their preferred locale in terms of ISO standard language and country codes. The locale definition can then be obtained by the Java application which can interpret it and display text in the correct language and format (for example date formats and currencies).

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

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