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
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).
iii
Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
v
Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
vii
Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
ix
Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
xi
Copyright 1998 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
xiii
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
Technology Architecture
Deployment
About This Course xv
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
● 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
● 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.
About This Course xvii
Copyright 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
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
About This Course xix
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
About This Course xxi
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
About This Course xxiii
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
● List the common Java technology APIs and briefly describe the purpose of each
About This Course xxv
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
● 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.
About This Course xxvii
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
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:
1-1
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
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
Technology Architecture
Deployment
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
Introduction to the Java Technology Architecture Process 1-3
Copyright 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 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.
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
Introduction to the Java Technology Architecture Process 1-5
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
Introduction to the Java Technology Architecture Process 1-7
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
Introduction to the Java Technology Architecture Process 1-9
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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.
Introduction to the Java Technology Architecture Process 1-11
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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
Introduction to the Java Technology Architecture Process 1-13
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
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.
Introduction to the Java Technology Architecture Process 1-15
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
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.
Introduction to the Java Technology Architecture Process 1-17
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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.
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
Introduction to the Java Technology Architecture Process 1-19
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
Business logic tier
API
TCP layer
IP layer
Network
Data access tier
API
TCP layer
IP layer
Network
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
Introduction to the Java Technology Architecture Process 1-21
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
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
Introduction to the Java Technology Architecture Process 1-23
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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.
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
Introduction to the Java Technology Architecture Process 1-25
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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 methodson 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.
Advantages of Distributed Object Architectures
Introduction to the Java Technology Architecture Process 1-27
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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)
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
Introduction to the Java Technology Architecture Process 1-29
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1 Platform
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
No built-in security for Internet
API Use Java technology API set
enhances usability of Java technology
Lack of enterprise APIs
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)
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
Introduction to the Java Technology Architecture Process 1-31
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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.
Introduction to the Java Technology Architecture Process 1-33
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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).
Advantages of Three-Tier Architectures
Introduction to the Java Technology Architecture Process 1-35
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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.
Introduction to the Java Technology Architecture Process 1-37
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
Network must be available.
Performs best on high-speed local
Better for high-performance
Example Message queuing
IBM MQSeries.
Remote procedure call.
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.
Introduction to the Java Technology Architecture Process 1-39
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
Client
Introduction to the Java Technology Architecture Process 1-41
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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)
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)
Introduction to the Java Technology Architecture Process 1-43
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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++
Think Beyond
2-1
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.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
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
Technology Architecture
Deployment
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?
Designing a Java Technology Architecture 2-3
Copyright 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:
● 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.
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
Audit checks Expense
payment Expense
approval Employee
Designing a Java Technology Architecture 2-5
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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.
Designing a Java Technology Architecture 2-7
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
Architecture Analysis
Customer Appraisal
When preparing the appraisal, determine: ● What the prime issue is for this customer
Designing a Java Technology Architecture 2-9
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
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.
Designing a Java Technology Architecture 2-11
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.
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:
Designing a Java Technology Architecture 2-13
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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
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.
Designing a Java Technology Architecture 2-15
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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?
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
Designing a Java Technology Architecture 2-17
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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?
Architecture Analysis
Readiness of Customer (Continued)
Designing a Java Technology Architecture 2-19
Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. Enterprise Services July 1999, Revision A.1
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.