Typical Security Structure With Firewalls (Continued)

Typical Security Structure With Firewalls (Continued)

In Figure 6-3, two firewalls are installed. The first one filters requests from the Internet. The second firewall server protects the company’s intranet. The only way to get through this second firewall is with a trusted application.

Designing a Secure Java Technology Architecture

6-11

DMZ

The area between the two firewalls is known as the demilitarized zone (DMZ). Because this is a semi-secure area, do not install any sensitive data here.

The Web server and servlet run here. However, the servlet simply acts as a proxy between the applet and business logic processing located behind the second firewall. The servlet passes client requests to the application business logic tier and to the back-end information systems. Thus, neither the user nor the servlet has direct contact to tier three data or applications. In essence, an extra tier has been added to the Java technology architecture.

Other services such as file transfer protocol (FTP) and email run in the DMZ. The DMZ can be a staging area for mail and FTP files that are transferred between the Internet and the company intranet.

For electronic-commerce applications, the commerce server catalog and shopping cart can run in the DMZ. However, no proprietary company business processes should run here.

Catalog data that the users browse can be placed here; however, order information must be passed through the second firewall to be processed.

6-12

Java Technology Architecture Planning and Design

Basic Security Architecture

Firewalls and Scalability

Obviously, firewalls can become a bottleneck, since everything is funneled through them. Firewalls are very efficient at scanning ports and filtering packets; however, overhead might be incurred if the firewall has to scan the contents of a packet (for example, looking for the <applet> tag within HTML).

The architect must anticipate the affect of the firewall on the overall architecture performance. Questions to ask are

● How robust is the firewall? ● How scalable is it? ● How many packets per second can it process?

The two firewalls serve different purposes; thus, they should be from different vendors. If someone manages to break into the first firewall, they might easily be able to break into a second firewall if it was from the same vendor.

Designing a Secure Java Technology Architecture

6-13

Basic Security Architecture

Assess the Security Infrastructure

Use the following questions in your assessment. ● Security policy – Does the company have an existing security

policy? Does this cover the Internet and access to systems by outsiders?

● Remote access procedures – Are there procedures and rules in place to govern remote access by employees, partners, and suppliers? Many companies use dial-back modems for remote

access.

6-14

Java Technology Architecture Planning and Design

Discussion – What security exposures have not been addressed by the dual firewall architecture?

Designing a Secure Java Technology Architecture

6-15

Security and Application Architecture

Can the same application architecture suffice for both intranet and extranet use? The basic security requirements for the PlasicDeSign application, or for an extranet application, are:

● Authentication of external users – Is the current user validation mechanism sufficient? Though this might appear to be sufficient,

the users are responsible for changing passwords frequently and to choose passwords that cannot be easily guessed. Does there need to be password access for the employees?

● Access control – There must be multi-level access control for employees, buyers, and vendors. In its current form, the business

logic will allow any vendor to query any other vendor’s purchase order data just by entering a valid purchase order number.

● Privacy – The Internet is an unsafe network. Passwords and other sensitive data must be encrypted when they are sent over the Internet.

6-16

Java Technology Architecture Planning and Design

Table 6-1 shows some solutions to various security requirements. Table 6-1 Addressing Security Requirements

Comment on Java Technology Requirement

Solution(s)

Signed applets and digital

• Signed applets

signatures require the Security API in JDK 1.1

• Digital signatures

Access control lists are often level)

Access control (multi-

• Access control lists

implemented by Web server Privacy of data

(ACLs)

• Encryption, such as

Web browser and Web server

SSL

support for SSL encryption of

• Virtual private

HTML

network (VPN)

Java Cryptography Extension (JCE) for encrypting application data streams requires JCE addition to JDK 1.1

Prevention of Internet

Digital signatures require JDK 1.1 spoofing

• Firewall scanning

• Digital signatures

Virus protection

• Firewall scanning

The sandbox prevents virus transmission by applets

Message digests and signed JAR alteration

Prevention of data

• Message digests and

signatures

files require JDK 1.1

• Signed JAR files

Prevention of Internet

• Web proxy server

attacks

• Firewalls

Designing a Secure Java Technology Architecture

6-17

The Java virtual machine instructions provide the fundamental basis for security. The Sandbox is implemented on that foundation. There are variations on this security which can be used in Java technology architectures to provide additional levels of security for applications. Some of the more advanced forms of security will now be examined.

6-18

Java Technology Architecture Planning and Design

Security can be applied to an application at different layers (Figure 6-4).

SET, S/MIME, PGP

SET, S/MIME, PGP

Application

JCE, S-HTTP

JCE, S-HTTP

HTTP Transport

HTTP

SSL (https)

SSL (https)

IPSEC, SKIP

IPSEC, SKIP

IP

IP

SET = Secure electronic transaction S/MIME = Secure/ multipurpose internet mail extension PGP = Pretty good privacy

S-HTTP = Secure hypertext transfer protocol IPSEC = Internet project support environment SKIP = Simple key-management for Internet protocols

Figure 6-4

Security Techniques and Layering

Designing a Secure Java Technology Architecture

6-19

Security Techniques and Layering

Three layers are shown in Figure 6-4: ● Application layer. The data is encrypted at the application layer

before it gets to the transport layer. The applications must use encryption keys or encryption algorithms directly (these must be licensed from security vendors such as RSA Data Security, Inc.).

▼ Secure Electronic Transactions (SET) is a standard promoted by credit card companies for making secure payments over the

Internet. The Java Electronic Commerce Framework (JECF) incorporates the SET standard.

▼ Mail applications use secure multipurpose internet mail extension (S/MIME) and pretty good privacy (PGP) to encrypt data.

▼ The Java Cryptography Extension (JCE) is an API for encrypting data between Java applications at the application level.

▼ Secure HTTP (S-HTTP) is a secure form of the HTTP protocol that can be used between Web browsers and Web servers.

6-20

Java Technology Architecture Planning and Design

● Transport layer. Transport layer security encrypts data below the application layer, and is the most common form of security over

the Internet. ▼ SSL is the most common transport security mechanism. It

encrypts all data that passes over a secure socket, but not the TCP/IP header information.

▼ SSL uses public key cryptography from RSA Data Security. The Web site administrator generates a public/private key pair

when the SSL Web server is being configured. The Web browser does not need any special configuration.

● Network layer. Network layer security encrypts date through the network and is used by virtual private networks (VPNs). VPNS

are a secure “tunnel” or path through an unsecure network such as the Internet (see Figure 6-5). VPNs can be used to provide secure access by partners and suppliers (extranet).

VPNs are usually implemented by hardware at each end. Application data is exposed at the higher transport and application layers, so for complete security this should be used with other forms of security.

Designing a Secure Java Technology Architecture

6-21

Extranet Intranet

DMZ

Supplier firewall

Web server

Java RDBMS

Servlet

applet

Encrypted path or VPN

Figure 6-5

Virtual Private Network

▼ Internet project support environment (IPSEC) is an emerging Internet IP security protocol that provides network encryption.

▼ Simple key-management for the Internet Protocol (SKIP) adds more security; however, SKIP drivers must be installed on the

client platform.

6-22

Java Technology Architecture Planning and Design

Since the servlet in the DMZ does no business-specific processing, the application’s business logic tier has been moved behind the second firewall (Figure 6-6).

DMZ

RDBMS Vendor

firewall Business logic

Web server

Vendor Java applet

application

Servlet

or Enterprise JavaBean

Web server Servlet

Mainframe

Figure 6-6

Security Architecture Details

There are now two Web servers: ● The first Web server is just a pass-through process. ● The second Web server runs on the intranet and is accessed by

employee applets. The business logic can be designed as a Java application or Enterprise

JavaBean (with a container).

Note – The application tiers are still the same, even though they have been moved.

Designing a Secure Java Technology Architecture

6-23

Security Mechanisms

Security options to consider include authentication, access control, and encryption.

Authentication Options

Authentication options include: ● Passwords. Password information can be encrypted over the

Internet using SSL (provided by the Web browser and Web server). ● One-time passwords using challenge/response authentication

technology. These are safer than static passwords. One-time passwords are implemented by token cards such as Enigma, S/Key, and OPIE.

● Single login for the user to access multiple applications. This is accomplished with a dedicated authentication server such as the Novera application server.

6-24

Java Technology Architecture Planning and Design

Access Control Options

Access control options include: ● Access control lists (ACLs) which can be implemented by Web

servers or by Java applications using the Java ACL API. ▼ The Java ACL API was introduced with JDK 1.1. This is a low-

level API and the implementer must build the ACL mechanism.

▼ Access control lists store a profile for every user or group of users. The profile is consulted to determine which area of data

the user is allowed to access. ● Firewall packet filters, which can filter access using various levels

of granularity (ports, protocols, IP addresses, and so on), are usually not as fine-grained as ACLs.

● Authorization server support included in Web applications servers

such as Novera.

Encryption Options

Encryption options include: ● Secure socket layer (SSL). As was mentioned earlier, it is the most

common form of encryption used over the Internet. SSL provides authentication of the Web server to the client, as well as

client authentication to the Web server.

Note – There are various strengths of encryption keys (the longer the key the harder it is to break). Due to United States export controls, only 40-bit encryption keys (the shortest) can be currently exported from the United States and Canada.

Designing a Secure Java Technology Architecture

6-25

Encryption Options (Continued)

● Java secure sockets. Data transfers from an applet to a server can

be encrypted by Java applets and applications that use TCP sockets. This requires that both the Web browser and the applet be at the JDK 1.1 level.

▼ Secure sockets are provided with the Java Server toolkit or by

third parties. ● Java Cryptography Extension (JCE) package allows a Java

application to encrypt directly (instead of relying on the transport layer).

▼ The Java applications can use higher strength encryption keys

(up to 2048 bits). ▼ This requires JDK 1.2, and the encryption algorithm must be

licensed from a vendor such as RSA Data Security. ▼ Strong encryption is subject to export restrictions from North

America. Some other countries have laws governing access to encryption too.

6-26

Java Technology Architecture Planning and Design

Signed Classes

JDK 1.2 Security

A major refinement to Java security took place with JDK 1.2: ● Java protection domains replace the Security Manager ● The Java Security Manager (sandbox) is still available

Protection Domains

A signed class may be granted some degree of trust; that is, given permission to perform an operation that would otherwise have been refused, such as open a file. Web browsers give users the choice to run

a signed applet in a different protection domain which allows it to override the sandbox security. Trusted classes and untrusted classes are separated into different protection domains for added security (Figure 6-7).

Designing a Secure Java Technology Architecture

6-27

Protection Domains (Continued)

The protection domain is a set of access permissions (read, write, and so forth) that apply to an applet or group of classes. This set of permissions is conventionally stored in a text file (policy file) and may

be managed centrally if appropriate.

Signed Servlets

Unsigned servlets that are loaded across the network are confined to a sandbox which is similar to the one used by Web browsers, that restricts access to resources.

Signed servlets are protected by the protection domain feature, the same as signed applets.

DMZ

RDBMS Vendor

firewall

Web server

Business Vendor

logic

Servlet

applet Web server Servlet

Authentication server

Protection domains

Figure 6-7

Signed Applets and Servlets

6-28

Java Technology Architecture Planning and Design

Signed Applets and Servlets

Digital Signatures

Applets and servlets are signed using a digital signature. The digital signature uniquely identifies the sender of the applet, just like a fingerprint. When a signed applet is downloaded to the client, its digital signature is stored by the Web browser.

Digital signatures use two sets of encryption keys, making them safer than single key (public) encryption. The originator encrypts the data with the public key of the recipient; the recipient’s own private key decrypts the data.

Digital signatures can be used to identify the user of an applet as well as the originator. They are frequently used by electronic-commerce systems and by SSL for encryption (the public encryption keys are digitally signed for added protection).

Designing a Secure Java Technology Architecture

6-29

Digital Signatures (Continued)

Digital signatures are implemented using various techniques: ● Smart cards which have embedded digital signatures and can be

used by consumers to make purchases by using the Internet. ● Client software which has an embedded digital signature for the

user and can respond to merchant requests. This normally resides on the user’s computer.

● Merchant software products by which the merchant obtains a digital signature from an issuer when the software is initially installed.

● Firewall products may contain embedded digital signatures for

authenticating remote users for access.

Note – Digital signatures are only a mechanism to trace the originator of an applet or message. They cannot prevent fraud or attack; they can only trace the source.

6-30

Java Technology Architecture Planning and Design

Signed Applets and Servlets

Digital Certificates

Digital certificates are used to securely transmit the public keys that are used for encryption, and to verify and digital signatures. Certificates contain other information as well as the actual public key. One crucial feature of a certificate is that it is itself signed.

Certificate Authorities (CAs) have been established to verify individual and institutional identities, and the match with their public keys. Once this association has been proven a digital certificate that publishes the key is issued. The certificate is signed by the CA.

Designing a Secure Java Technology Architecture

6-31

Signed Applets and Servlets

Message Digests

A message digest is a checksum (hash value) of the contents of a piece of data. When used, the message digest accompanies the data over the network. The receiver recomputes the hash value of the data and compares it to the message digest sent with the data to ensure that the data has not been accidentally damaged.

Message digests are part of the core JDK 1.2.

6-32

Java Technology Architecture Planning and Design

Security Versus Usability

There is often a trade-off between providing security and usability. The reason why SSL is so prominent is that it needs no installation or involvement by the user.

SSL will provide adequate levels of security for most extranet and Internet users.

Some rules for designing security methods are ● DMZ should not have any confidential information. This

particularly includes the external Web server. ● Choose a security mechanism that is not specific to any Web

browser (for example, SSL). ● Choose a security mechanism that can be used internationally.

Designing a Secure Java Technology Architecture

6-33

● Choose a security mechanism that requires no (or minimal) setup by the user (for example, SSL). The reason is that if it is too

cumbersome to set up, users will simply abandon the idea of security and proceed without it.

● If you use signed applets or other JDK 1.2 security features, ensure

that all Web browsers support them. ● Choose a security mechanism that can pass through firewalls

(consult Table 6-2).

Table 6-2 Security Mechanisms Used Through Firewalls

Protocols That Are Normally

Protocols That May Be

SMTP (email)

JDBC vendor protocols (type 3)

HTTP (applet tag)

JRMP (RMI)

HTTP

IIOP (CORBA)

HTTP (URL)

HTTPS SHTTP Any socket not explicitly

permitted

Note – The SSL socket connection may not be allowed in or out by the external user’s firewall. If this is the case, you may have to use SHTTP.

It is a general rule of security that permissions must be explicitly granted. This is normally cited as: “That which is not explicitly permitted is denied.”

6-34

Java Technology Architecture Planning and Design

Security Architecture

The components of the application architecture (Figure 6-8) now include:

● Authentication with user ID and password. Consider a one-time

password scheme for extra security. ▼ The applet that the suppliers use is downloaded from the Web

server. The applet displays a dialog box for the user to enter username and password. The user will be allowed three attempts to log in, after which the applet stops.

● Java applet with SSL encryption over the Internet (provided by

Web browser) ▼ The supplier’s Web browser uses SSL to encrypt the login

details. The login screen uses the HTTPS connection (that is, the user enters https://applet.url instead of http://applet.url ).

Designing a Secure Java Technology Architecture

6-35

● Servlet pass-through in DMZ. The servlet passes requests through the second firewall. Only requests from the servlet are allowed

through. ● Once behind the second firewall, there are several options for

providing multi-level access control (to prevent suppliers from accessing other supplier information):

▼ Java access control lists using the Java technology ACL API ▼ Using the security provided by the RDBMS vendor (each

supplier is allocated a database user account) ▼ Using a purchased authorization server (such as Novera)

DMZ

RDBMS Supplier

firewall

Web server

Business Supplier

logic

Servlet

applet Web server

Servlet User ID and password SSL encryption

Mainframe

Authentication server

Figure 6-8

Components of the Application Architecture

6-36

Java Technology Architecture Planning and Design

Although many security features were introduced in JDK 1.1, the security model was still the Sandbox security model. With JDK 1.2 the new Protection Domain Security model was introduced.

Table 6-3 JDK 1.1 and JDK 1.2 Security Comparison

Security Feature

Supported in JDK 1.1?

Supported in JDK 1.2?

Security model

Yes, Sandbox Security

Yes, Protection Domain

Security model Access control lists

model

Yes, java.security.acl Yes, java.security.acl Message digests

Yes, java.security.

Yes, java.security.

MessageDigest Digital Signatures

MessageDigest

Yes, java.security.

Yes, java.security.

With JCE 1.1

With JCE 1.2

X.509 certificates

Yes, Version 1

Yes, Version 3 implementation support

Certificate interfaces

No

Yes, java.security.cert. X509Extension

Keystore database

Yes, $HOME/.keystore (certificate and

Yes,

$HOME/identitydb.obj

key/identity database) (Note the change)

Keystore database tool

Yes, javakey

Yes, keytool

(Note the change) JAR signing tool

Yes, jarsigner (Note the change)

Yes, javakey

Class loaders

Yes,

Yes, java.lang.ClassLoader java.lang.ClassLoader and java.security (SecureClassLoader added to support new security model)

Designing a Secure Java Technology Architecture

6-37

Security Feature

Supported in JDK 1.1?

Supported in JDK 1.2?

Security managers

Yes, java.lang.

Yes, for backward

SecurityManager

compatibility, but permission checks pass through the java.security. AccessController class

Tool for building security Not applicable (policy Yes, policytool policy

files not used in security model)

6-38

Java Technology Architecture Planning and Design

Exercise objective – Critique a proposed three-tier Java technology security architecture and apply the new JDK 1.2 security features to improve the architecture.

Preparation

In order to successfully complete this exercise, complete the following tasks:

1. Read the customer’s requirements and security constraints are detailed in ‘‘Module 6 Case Study’’ on page A-21 in Appendix A, ‘‘Case Studies.” Detailed instructions for completing the exercise can also be found here.

2. Read and familiarize yourself with the case study before you go into your small groups. If you have any questions, ask the instructor for clarification.

Designing a Secure Java Technology Architecture

6-39

Exercise Summary

Discussion – Take a few minutes to discuss what experiences, issues, or discoveries you had during the case study exercise.

Java Technology Architecture Planning and Design

Before continuing on to the next module, check that you are able to accomplish or answer the following:

❑ State the need for signed applets or servlets ❑ State the security constraints and trade-offs that affect Java

application architecture ❑ Design a multi-tier Java technology architecture for use over an

unsecured public network such as the Internet ❑ Evaluate a proposed (or existing) Java software solution

architecture and make recommendations to provide or increase security

❑ Design a multi-tier architecture for an extranet application

Designing a Secure Java Technology Architecture

6-41

The architect must integrate security into the architecture at the beginning of the production process. (The consequences of not doing this could involve huge changes to applications and possible rewrites at a later time.)

Performance must similarly be taken into consideration when the architecture is designed. The next module will look at how performance requirements affect the architecture.

6-42

Java Technology Architecture Planning and Design

Designing an Architecture for Performance

Course Map

This module discusses performance implications of a Java technology architecture.

Foundation

Introduction to the Java Technology Architecture Process

Basic Principles

Designing a Java

Java Technology

Technology Architecture

Architecture Details

Advanced Principles

Integration With Existing

Creating New

Applications and Databases

Application Architectures

Security and Performance Principles

Designing a Secure Java

Designing an Architecture

Technology Architecture

for Performance

Deployment

The Java Technology Architecture in Production

7-1

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

Discussion – The Java application that you designed has been deployed. Users are complaining about slow response times. You have been called in to find the bottleneck and make recommendations.

What could you have done at the architectural design stage to avoid this?

7-2

Java Technology Architecture Planning and Design

Upon completion of this module, you should be able to: ● Evaluate a proposed (or existing) Java technology architecture and

make recommendations to increase performance ● Design a multi-tier Java technology architecture that delivers an

acceptable level of performance and that can be tuned and scaled as necessary

References

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

● Cockcroft, Adrian and Pettit, Richard. Sun Performance and

Tuning: Java and the Internet. SunPress. ● Appendix B, ‘‘References.”

Designing an Architecture for Performance

7-3

The application was originally a two-tier application that used HTML forms and a Web server with local database over a LAN. It was re- architected as a three-tier application using Java applets and a purchased application server, and the database was moved to tier three (Figure 7-1).

Tier one

Tier two

Tier three Real-time

feed Customers

Internet Mainframe

tracking) Transport

Web server

Servlet

providers Purchased application

server Extranet

RDBMS (customized information)

Local employees

Mobile employees

Mainframe (inventory and shipping)

Internal Web server

Figure 7-1

Performance Customer Example

7-4

Java Technology Architecture Planning and Design

The Customer Architecture

Overview

The architecture is the classic three-tier Java technology architecture with a dual firewall for security. The authentication is provided by the purchased application server.

Customers, suppliers, mobile employees, and internal employees use a Java applet to access the system. The applet is about 300,000 bytes in size. The applet communicates with tier two using RMI. The tier-two application server communicates with the two mainframes using CORBA.

Designing an Architecture for Performance

7-5

Types of Users

The application allows customers to order land, sea, and road transportation container services, and track the shipments of those containers from start to destination. There are three types of users:

● Internal employees who access the application from Web browsers on the company intranet (Ethernet). They are complaining that the

three-tier application is much slower than the old two-tier application.

● External customers and transport providers who access the application through an Internet service provider. They also use email services through the Web browser. Their speed of access ranges from 28.8 kilobits per second (kbps) to 128 kbps Integrated Services Digital Network (ISDN) for medium-sized customers and up to T1 speeds for the larger customers. They are complaining about slow response times.

● Mobile sales and support staff who dial in directly to the system using modems ranging from 28.8 kbps to 56 kbps. They are complaining that the graphics part of the application is unusable.

7-6

Java Technology Architecture Planning and Design

The Customer Architecture

User Authentication

User authentication is provided by the Web server with a user ID and

a password which is encrypted by the Web browser.

Access Control

The mobile employees and suppliers are deemed to be on the company extranet; thus they have access to information that cannot be viewed by customers. Access control is provided by the application server.

Designing an Architecture for Performance

7-7

Application Flow

The process is as follows:

1. Once logged in, the user is presented with a list of functions (order service, check order status, check container contents, track container, and so on).

2. This list of functions is customized for each user upon login. For instance, customers are shown a list of in-progress orders and containers that are in transit. Customization is done by the application server. Employees have a wider range of functions.

3. When customers select a container to track, they receive a graphical display of the container’s location:

A list of customized functions is shown in a frame on the left.

A frame at the right shows the graphical display, which shows the container as a dot with the entire route mapped out.

▼ Customers can then navigate to a more detailed map. The tier- two application server generates the graphical displays using

on-line tracking information stored on one of the two mainframes. This mainframe database is constantly updated in real-time by distribution employees who use hand-held, wireless devices which feed into the mainframe using satellite links.

4. The other mainframe holds container inventory and shipping information and is used when customers order and query container content. Both mainframes are accessed to produce the customized screen when the customer logs in.

5. The tier three relational database stores the customized information for each of the currently logged-in users.

7-8

Java Technology Architecture Planning and Design

Discussion – What is your initial reaction to the case study? ● Where might some of the performance bottlenecks be? ● What is meant by performance? ● What questions might you ask the customer to obtain more

information? ● How many of these things should the architect have known at the

architecture stage of the application design?

Designing an Architecture for Performance

7-9

Performance Analysis

Note – This module does not cover the performance measurement and tuning discipline. The focus in this module is on making effective application design decisions that will prevent performance bottlenecks before the application goes in production.

Design Performance Factors

There are many factors that determine performance; these include ● Applet download ● Applet response time ● Network latency and throughput

7-10

Java Technology Architecture Planning and Design

Architecture Performance Goals

The architect must work towards a performance goal that is established when the application requirements are drawn up (for example, number of users supported, user response time, applet download time, and so on).

● What were the original performance goals for this application? ● Were they explicitly stated by the customer? ● Were they included in the application design document?

Design Performance Goals

Sometimes the goals may conflict, and various people can have different views about performance.

● End-user view (and preconceptions). The end-user is only concerned with his or her individual response times. Waiting for an application response is a huge productivity loss.

● Administrator view. The system administrator has a wider view of performance that embraces overall system, memory, and disk utilization.

Designing an Architecture for Performance

7-11

Customer Application Performance Goals

What are the performance goals for the customer application? ● Get back to the performance level of the old two-tier application?.

● Support the external users and mobile employees on 28.8 kbps

lines with reasonable performance. ● Download the applet in under 1 minute, or support another 500

users with no degradation in current performance. It might be some or all of these goals.

● Do these goals conflict? ● Is it possible to meet all goals? ● What is the current level of performance? Can it be compared with

the original goal or the performance that was recorded during testing?

Perception and Reality

Is the user’s perception clouding the issue? If the user is used to sub- second response times from LAN-based or terminal-based applications, a GUI interface might appear to be slower. (In this case performance must be weighed against the added usability of the GUI.)

Customers must understand the overhead associated with object- oriented interfaces and balance this overhead with the extra functionality that they are getting. Does this apply here?

7-12

Java Technology Architecture Planning and Design

Prototyping

Prototyping is invaluable for determining the viability of architectures and protocols. For example, is RMI passing whole serialized objects by value, or sockets, passing small blocks of data in many separate messages, better for a particular application?

Use profiling tools when running prototypes, and be sure to simulate WAN behavior. Measure network utilization, and end-to-end response times.

See Appendix B, ‘‘References,” for some testing and profiling tools.

Designing an Architecture for Performance

7-13

Performance will always be a trade-off between the productivity gains of Java technology and object-oriented technology, and possible implementation limitations due to network and platform capacities.

The architect must be aware of areas in a Java application environment that might cause performance bottlenecks in order to design the application appropriately to meet the conflicts of productivity and performance (Figure 7-2).

Java software

Bytecode

source code

loader Java

Java

application Java software

applet

compiler (javac)

Bytecode verifier

Java software bytecode

Java runtime Operating system

Figure 7-2

Java Program Compilation and Execution

7-14

Java Technology Architecture Planning and Design

Architecture Performance Bottlenecks

Java Technology Issues

The overhead of Java technology is mainly in the following areas: ● Bytecode interpretation and Java programming language

verification checking. ● Memory management (that is done on behalf of the programmer).

Adjusting the size of the heap can increase performance. ● Thread synchronization (before a method can be run, there is a

check to see if other threads are using the method). ● Method calls. There is a cost associated with frequently accessing a

method.

Designing an Architecture for Performance

7-15

Architecture Performance Bottlenecks

Enhancing Performance

Performance can be improved by considering the following: ● RMI. It is tempting to use the facilities of RMI to transfer objects;

however, the size of these objects and the available bandwidth of the network to transport them must be considered. This might affect the architecture design in the following ways:

▼ Is there an alternative to shipping objects over slow networks? It may be better to send a subset of the whole object.

▼ Can multiple objects be “packed” into one object for transfer

using RMI? ▼ Can you use compression? JDK 1.2 allows this.

● Security checking. How much security is needed? Does all data need to be encrypted, or can just some of it be encrypted?

7-16

Java Technology Architecture Planning and Design

Enhancing Performance (Continued)

● Round trips to server. The architecture can be designed to minimize the number of trips between tiers. Sending whole objects

with RMI can be an advantage here. ● Excessive data over WAN. The amount of data should be

estimated and reduced by tier two if it is excessive for the WAN speed.

● JVM version. Use a later version of the JVM, which has better performance. There has been such rapid improvement in this area

that older products yield much slower performance than newer products and releases.

● Applications. Use applications instead of applets to avoid the overhead of the bytecode verifier. (You must balance this with the

overhead of distributing the application.)

Note – Java technology performance is constantly being addressed by Sun and by Java technology licensees. The architect should strive to keep abreast of all changes. Java HotSpot™ is an alternative virtual machine (VM) for Java technology that dynamically optimizes Java software code at runtime to produce better performance than code compiled with a JIT compiler.

Designing an Architecture for Performance

7-17

Architecture Performance Bottlenecks

Java Applet Environment Issues

The architect should recommend a suitable implementation environment for the customer.

The Web browser (or the JVM) is the environment for delivering and running Java applets. Thus, the performance of the following elements of a Web browser or JVM can have an impact on applet performance:

● Version and implementation of Web browser or JVM. ● Platform performance (memory, CPU speed, and network speed).

This is especially important for non-traditional devices which run specialized JVMs.

● Multimedia performance. In the past, computers that were used for heavy graphics had specialized boards and graphics accelerators. Can the platform support video and graphics with

reasonable response?

7-18

Java Technology Architecture Planning and Design

Tier One Performance Issues

Applet Download Time

Applets are loaded by the applet class loader (part of the JVM). The class loader opens and closes a TCP socket connection for each class file to

be downloaded. For example, an applet composed of 20 classes would make 20 separate connections to the Web server.

This is a considerable overhead. Once loaded, applet classes are first passed through the verifier to check that the class file conforms to the Java programming language specification. There is a slight overhead for this checking.

Designing an Architecture for Performance

7-19

Tier One Performance Issues

Options to Improve Download Time

Architecture design options to improve applet download time include: ● Use Web browsers and Web servers that comply with HTTP 1.1.

With HTTP 1.0, the server disconnects from the client after data is transferred. In HTTP 1.1, the server keeps the connection open for additional requests. This saves the overhead of the client having to repeatedly connect to the server to download applet classes.

● Keep the applet size as small as possible. This might mean designing the user interface without some of the graphics and

widgets (for instance, a table widget class alone might be 64 Kbytes). In this respect, using core JDK classes is preferable to third party components.

Performing as much work as possible on the middle tier will also reduce the size of the applet, but might increase response time because of extra communication needs.

7-20

Java Technology Architecture Planning and Design

Options to Improve Download Time (Continued)

● Profile the applet at prototype time so you still have a chance to redesign it. Measure the applet size during testing using a

profiling tool (examples of such tools are listed in Appendix B, ‘‘References”). Be aware of the minimum platform configuration needed for acceptable performance. If there are many instantiations of an object, the object may be a candidate for reuse.

● Design a more efficient interface for users who access the system over slow links (using HTML instead of an applet). The architect

may need to decide if an extranet applet should be different from an intranet applet.

● Use a JAR file to load multiple classes in one go (in one HTTP connection). There may be a trade-off here—if all the classes are

downloaded at once, there will be a longer delay initially in applet startup. However, once running, there will be no further delays.

● Put high priority classes into a JAR file and load those initially.

Load other classes in a background thread. ● Pre-load the applet classes on the client platform to avoid

download (or use an application) or use push technology to deliver the applet classes in advance. The architect may deem that this is appropriate for certain intranet applets which need very fast responses. For network computers, the applets could be stored on

a local file server.

Designing an Architecture for Performance

7-21

Tier One Performance Issues

Applet Execution Time

Poor applet performance (once the applet has been downloaded) is usually a result of one or all of the following:

● Lack of platform memory ● Inadequate platform capacity ● Inadequate network bandwidth (or poor network protocol use)

7-22

Java Technology Architecture Planning and Design

Tier One Performance Issues

Improving Applet Execution

Implementation options to improve applet execution include: ● Ensure each client platform has sufficient memory for the applet

footprint (especially if the client is a network computer). Applets are removed from memory on a last-accessed basis. While Java software code is generally smaller than corresponding C code, applets require more memory than C code. By adding memory to the employee’s client platforms, you could increase performance.

● Limit the applet’s use of temporary objects, which can stay in memory long after they are needed. Object allocation is overhead, as is garbage collection. The applet should be designed to minimize object allocation and reuse objects in memory- constrained environments.

Designing an Architecture for Performance

7-23

Improving Applet Execution (Continued)

● Monitor the way classes are downloaded when the applet executes using applet profiling. Can classes be loaded in advance using JAR

files? The downside of this is that the applet startup time is greater.

● Ensure the client CPU capacity can support Java technology with reasonable performance. Use a JIT compiler instead of interpreting bytecode. Determine if the applets are to be run on slow platforms.

● Ensure the latest versions of Web browsers (JVMs) are deployed. Use the latest versions of the JDK if possible (for example, JDK 1.2 has improved garbage collection over previous versions).

7-24

Java Technology Architecture Planning and Design

Tier One Performance Issues

Network Bandwidth Considerations

The architect may need to make design decisions based on the performance of the network. Check the following aspects of the design:

● Caching data. In the customer example, you could extract some of the complex, graphical data from the tier-three databases and

download to the client in advance. The trade-off here is that additional memory, CPU, and disk resources might be needed on the client platform. If large amounts of complex data are anticipated, there is a case for analyzing usage patterns for the data.

● Object transfer. Think carefully before transferring large objects over bandwidth constrained links; for example, shipping RMI

objects over 28.8-kbps lines. Examine network protocols (for instance, HTTP or sockets may offer better performance than RMI for slow networks). The trade-off is between ease of use of object orientation and performance.

Designing an Architecture for Performance

7-25

Network Bandwidth Considerations (Continued)

Note – If you designed and developed the architecture using UML package notation, the network protocol should be isolated so that it can be switched to a more efficient protocol.

● Network simulation and testing. If there is no real WAN available for testing, simulate one. Some test tools provide this facility, as

well as network routers. ● Eliminate network trips by consolidating data in the design; for

example: ▼ Combine multiple socket call data into one socket call.

▼ Download the object to the client once, and manipulate it

locally. ▼ Use piggyback techniques to send multiple packets in one trip.

This is especially crucial for database access and processing rows of data.

● Monitor the network. Make sure that the network itself is not the problem (you can use basic network test tools such as ping). Check for network waits (they may indicate a delay on the server

end). Ensure that you understand when the slowest speeds will be in use. For remote and external users, check the speeds that are supported by the ISP.

● Anticipate the overhead of encryption. This often increases as the encryption key length increases. Longer keys take more CPU

cycles to decrypt. ● Understand the applet deployment environment. Are there local

Web cache servers in close proximity to the user?

7-26

Java Technology Architecture Planning and Design

Network Bandwidth Considerations (Continued)

● For screen scrapers, understand the network characteristics of the protocol that is being emulated with Java technology.

▼ With a three-tier implementation, the latency and bandwidth requirements move to tier two (where the screen scraper runs).

Different terminals have different network characteristics (refer to Table 7-1). With a screen scraper, these network characteristics will still manifest themselves, but they will be moved from tier one to tier two.

Table 7-1 Network Characteristics of Terminals

Bandwidth

Latency

Level of

Digital VT220

PC application Moderate

Moderate

Medium

(C, C++) X-terminal

(Java technology)

▼ What network protocol is now being used between tier one and two? Is it proprietary to the screen scraper vendor? Is it efficient?

Designing an Architecture for Performance

7-27

Tier One Performance Rules

Applet Performance

The overall recommendations for applet performance are to: ● Use a JAR file to download classes over slower network links. ● Design the applet to minimize network requests. ● Reduce the amount of graphics (without sacrificing functionality). ● Optimize the graphics; for example, use double buffering. ● Calculate the graphics on an appropriate system.

▼ Render graphics on the server if the network is fast compared

to the client machine ▼ Render graphics on the client if the network is slow compared

to the client machine How do these recommendations affect each of the three types of user

of the example application?

7-28

Java Technology Architecture Planning and Design

Tier One Performance Rules

Internal Users

Internal users’ concerns are in regard to ● Applet download. The applet may be slower to download than the

previous HTML that these users were used to. However, this should be only an initial delay while the classes are being loaded. For the 300,000 byte applet, it should take about 5 seconds to download over a 10 megabit-per-second LAN. If the applet is much slower than this, it may be due to the customization that is performed when the user logs on (this will be discussed later).

● Applet execution. If the delay is consistent, and not just when the

customization is being done, investigate ▼ Client memory

▼ Tier two or tier three performance (this will be discussed later)

Designing an Architecture for Performance

7-29

Internal Users (Continued)

● Network. The LAN network should not be a problem for internal users (unless it is overloaded anyway, which is not a Java

technology architecture issue). Network overload can be detected by network analysis tools. If necessary, recommend an upgrade from 10 to 100 megabits per second and to a switched Ethernet for increased performance.

7-30

Java Technology Architecture Planning and Design

Tier One Performance Rules

External Users

External users are concerned with ● Applet download. The applet download time will definitely be a

problem for those using 28.8-kbps modems. For the 300,000-byte applet, in the absence of compression, it will take at least 104 seconds to download. Alternatives might be

▼ Develop a leaner user interface (smaller applet size) ▼ Use JAR files

Designing an Architecture for Performance

7-31

External Users (Continued)

● Applet execution. If the delay is consistent, and not just when the customization is being done, this could indicate that large

amounts of data are being sent across the network in response to each client request, probably for producing the graphical displays of shipment locations. Is there a way to minimize the amount of data by using piggyback techniques, reducing the fine quality of the graphics, or optimizing the graphics?

▼ Use JIT compilers (or a faster JVM) ▼ Recommend a suitable platform for adequate performance

● Network. Consider using ISDN or high speed land line access if

available.

7-32

Java Technology Architecture Planning and Design

Tier One Performance Rules

Mobile Employees

The concerns voiced by mobile employees involve ● Applet download. The applet download time will definitely be a

problem for employees using 28.8-kbps modems. As before, the 300,000-byte applet takes at least 104 seconds to download. It would certainly be preferable to store the applet locally on the employee’s laptop, or to use an application instead of an applet, to avoid the download overhead.

Designing an Architecture for Performance

7-33

Mobile Employees (Continued)

● Applet execution. If the delay is consistent, and not just when the customization is being done, this could indicate that large

amounts of data are being sent across the network in response to each client request. Alternatives might be:

▼ Revisiting the data design. What size of data was designed to

be transferred? Why has this been exceeded? Is the application being used in a different way? Is tier two making a call to the database for each row? Can it be designed to access multiple rows?

▼ Minimizing the amount of data transferred. Can the same information be displayed to the mobile employees in a different way, using text or smaller images?

▼ Modifying the applet and application to allow the employees to work in disconnect mode. This might entail considerable changes to the application, such as use of local disk to store the

data entered by the employee. This is not a change to be made at this stage. Disconnect mode must be created in the initial application design.

● Network. Choose Internet service providers that offer high speed modem access in as many areas as possible. If appropriate, look

for ISDN access, but remember that although this might be available in conference centers or the employee’s home, it is unlikely to be available in hotels.

7-34

Java Technology Architecture Planning and Design

Tier Two Performance Issues

Tier two bottlenecks might be due to ● Inadequate server platform performance

● Database performance ● Network limitations

Designing an Architecture for Performance

7-35

Tier Two Performance Issues

Server Platform Performance

Tier two is the major scalable tier in a three-tier architecture. The architect must design the architecture to scale at this tier. Poor performance may be due to an overloaded server platform or overloaded application server software. However, with a good architecture, objects can easily move from the overloaded tier to another platform or tier. You can do this by

● Anticipating the performance capability of the deployment server (tier two) platform. Is this a new platform or is it to go on an

existing platform? ● If necessary, recommending that some of the workload (for

example, email servers) be moved to another platform.

7-36

Java Technology Architecture Planning and Design

Server Platform Performance (Continued)

● Assessing the scalability of the server platform:

▼ Configure the tier two platform with appropriate memory. Most application servers will require memory for each

concurrent client that they are processing. ▼ Recommend the server platform be upgraded if it is to run

other workloads in addition to the Web server and the applications server. Add a second processor to the server platform. Run the Web server on one processor, the application server on the other.

● Assessing the performance characteristics of the tier-two

application or purchased application server: ▼ Does the product use threads or processes? ▼ Is there any limitation on the number of threads it can support

(threads equate to users)? Can you add a second application server if the first server is handling many concurrent clients? A single application server with many threads will slow down with too much thread dispatching.

▼ Can it take advantage of multiple CPU processors? ▼ Can multiple instances of application servers be run

concurrently? Can these instances run on separate platforms? ▼ If the application server is doing screen scraping, how much

memory and CPU is required for each user? What are the vendor’s recommendations? How many users can be supported on the tier two platform?

▼ Using purchased components, such as application servers or Enterprise JavaBeans, might mean you have no control over the performance of those items.

Designing an Architecture for Performance

7-37

Tier Two Performance Issues

Server Platform Performance (Continued)

● Upgrading the server operating system if necessary. An example would be from Solaris 2.5 to Solaris 2.6, which contains

performance improvements. ● Using JIT compilers for Java server-side applications. ● Using the latest releases of Web server software and JVMs. These

releases usually perform better than older ones.

7-38

Java Technology Architecture Planning and Design

Server Load Balancing

Server load balancing can be accomplished with hardware or software products (see Appendix B, ‘‘References” for vendors). Load balancing can also be used for high availability (Figure 7-3).

software or hardware

Client

Secondary application server

Figure 7-3

Server Load Balancing

Two instances of an application server can run on separate platforms or on separate CPUs on the same platform.

Load balancing software can make simple or complex decisions about how to allocate requests between the servers. Often the simplest, that is alternate requests to alternate servers, works best in practice.

Designing an Architecture for Performance

7-39

Tier Three Performance Issues

Database Performance

There are several aspects: ● Consider the performance of the database server itself. This is

largely a database administrator task. What is the database load? Is the database used for other applications? How do they perform?

● Examine database activity for contention (locking). ● Examine database performance improvements such as indexing

and clustering technology. ● Examine the object/relational mapping. ● Examine the SQL commands used.

7-40

Java Technology Architecture Planning and Design

Database Performance (Continued)

● Consider the database design and access patterns. The architect

can have influence here. ▼ Would it be a benefit to cache heavily accessed data from tier

three on the tier two application server? This might make sense if the data needs to be “joined“from multiple back-end databases to fulfill an on-line query, or if it is frequently accessed by multiple clients.

▼ This caching could be done overnight, for instance, if the

application permits this. ▼ In the customer example, users need real-time access, so

caching the on-line tracking information is not a viable option. However, other information, such as background graphics, could be cached.

● Consider the protocol used by tier two to access the tier three database. If the protocol is slow, options include:

▼ Tuning the protocol. Some JDBC drivers support piggybacking of data and thus cut down the number of trips needed to access

the data. This might be a selection factor in choosing a JDBC driver.

Network

Ascertain the network speed between tier two and tier three. Is it a LAN, or is there WAN access to some of the back-end hosts? Can the network speed be improved, for example, with switched Ethernet on a LAN?

Designing an Architecture for Performance

7-41

Table 7-2 shows several products and what is measured. Table 7-2 Java Benchmarks

Benchmark Product

What Is Measured

Jstone

AWT performance

CaffeineMark

Small applets

JavaPerf

Medium applets

SPECweb96 Web I/O (static HTML) Transaction-processing performance

Transaction and database council (TPC)

performance by server platform SPECweb98

Web I/O (dynamic HTML) SPECjvm98

JVM performance

VolanoMark

JVM performance

7-42

Java Technology Architecture Planning and Design

Java Application Performance Rules

Use the following rules when designing Java applications: ● Set performance criteria with customer prior to production. ● Focus or anticipate the key areas which may cause performance

bottlenecks. Address them early in the testing process. ● Prototype an application. Get a feel for potential bottlenecks at this

stage. ● Design with the slowest user of the application in mind (for

example, in the case study the slowest user uses a 28.8-kbps modem connection).

● Use JAR files. Portions of an application that are typically used together should be placed in the same JAR file and unrelated portions of the application should be in separate JAR files.

Designing an Architecture for Performance

7-43

● Minimize graphics. Avoid displaying logos on screens; using images for screen backgrounds; using image buttons (text buttons

and icons are preferable), and so on. ▼ Where graphics improve application functionality, make them

as small as possible or only display them when requested by the user, not by default.

▼ Where graphics are used, they should be placed in JAR files so they can be extracted from the JAR file on the client side rather

than being brought across as streams. ● Minimize data transfer. If an application performs a query which

retrieves a large result set from a database, have this object cached at tier two. Avoid sending this data over a network.

● Group related data access in one network trip. If the retrieval of one object is likely to be followed by the retrieval of related objects most of the time, fetch them all at once. Where possible, group applet validation that requires access to the server.

▼ Several fields can be sent together in an object to the application server. This technique results in fewer client-to-

server trips, but it means that the user is potentially not notified of validation errors right away, which is a user interface drawback.

▼ Static data that is used for applet validation can be cached in the application server so that it is retrieved only once and not

for each client instance. However, caching is not appropriate for data that changes frequently.

7-44

Java Technology Architecture Planning and Design

Architecture Performance Rules

Designing

Ensure that you fully understand: ● Performance goals of the application. ● Performance characteristics of the application (data load, network

load, memory load, CPU load, and so on). ● Where the objects run and how they communicate. ● What data is used by objects, what is being sent over the network. ● Performance tolerance of the application; how far it can deviate

from the goal.

Designing an Architecture for Performance

7-45

Designing (Continued)

● Synchronization of the application (transactions, synchronized access, asynchronous access, publish/subscribe). Synchronous and

transactional applications have to be architected for higher performance.

● Platform capability of all users (including network access speed). ● Any performance problems that are out of your control as an

architect (for example, mainframe performance issues). ● Growth plans. Java

technology architecture design

Simulate WAN

Assess

Performance

performance goals

Figure 7-4

Performance Criteria

7-46

Java Technology Architecture Planning and Design

Architecture Performance Rules

Tuning

If you discover too late that performance is an issue, Java technology performance can be improved with:

● Hardware upgrades (including specific Java optimization

technology) ● Compiler performance upgrades (including optimization flags

within javac and jvc compilers, and JIT compilers) ● Operating system upgrades and features (for example, native

threads) ● JDK and JVM performance upgrades

Designing an Architecture for Performance

7-47

Redesign of Customer Application for Performance

Include in your design ● JAR file for downloading the applet. ● Local application for mobile employees, which avoids the

overhead of download until the applet is modified. ● Recommendations for memory on client platforms. ● Option to display graphical information in a more efficient way.

Users can then decide if they want to have full graphics or not. This involves changes to the user interface to allow selection of the option, and to the application server to produce the reduced graphics.

● Inventory and shipping information can be pulled from the mainframe when the user logs on (for instance, an asynchronous

thread can be started to accomplish this).

7-48

Java Technology Architecture Planning and Design

Before continuing on to the next module, check that you are able to accomplish or answer the following:

❑ Make recommendations to improve the performance of the

application when it is deployed ❑ Design an application architecture to meet the customer’s stated

performance goals

Designing an Architecture for Performance

7-49

Many of the performance issues discussed in this module are implementation issues that the architect must be aware of at the design stage. The architect must be aware of the implementation environment.

What are some of the implementation specifics of the architecture that you must be aware of?

7-50

Java Technology Architecture Planning and Design

The Java Technology Architecture in Production

Course Map

This module looks at architectural design decisions that might affect the implementation of a Java technology solution.

Foundation

Introduction to the Java Technology Architecture Process

Basic Principles

Designing a Java

Java Technology

Technology Architecture

Architecture Details

Advanced Principles

Integration With Existing

Creating New

Applications and Databases

Application Architectures

Security and Performance Principles

Designing a Secure Java

Designing an Architecture

Technology Architecture

for Performance

Deployment

The Java Technology Architecture in Production

8-1

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

Discussion – The Java application that you designed is about to be put into production. The customer has asked you for recommendations to make the implementation a smooth process.

● What can be done when the application is being designed and built to ensure a smooth transition into production?

● What new hardware/software/network infrastructure is needed

to support the application in production? ● How can the customer manage the application in production?

▼ Tracking changes to classes and libraries ▼ Versioning issues with Web browsers and JVMs ▼ Changes to data

8-2

Java Technology Architecture Planning and Design

Upon completion of this module, you should be able to: ● Design a Java technology architecture that can be easily moved

into production ● Given a Java application prototype or pilot solution, advise on

how it can be effectively moved to production status ● Recommend solutions for efficiently deploying and distributing

Java technology solutions in production ● Recommend Java application development, reusability techniques,

and project management techniques

The Java Technology Architecture in Production

8-3

The container tracking application discussed in Module 7, ‘‘Designing an Architecture for Performance,” has been developed using the test configuration shown in Figure 8-1.

Tier one

Tier two

Tier three

CORBA Test

server JDBC

Test RDBMS server

Figure 8-1

Application Development Architecture

As illustrated in Figure 8-1, ● Tier one and tier two are on the same LAN segment. Tier one and

two use Java RMI. ● The Web server, application server and RDBMS server are on the

same server platform. The application server uses a local JDBC driver to access the database.

● Tier three is accessed through an SNA gateway using Java IDL to a

mainframe CORBA application.

8-4

Java Technology Architecture Planning and Design

Application Test Architecture

Testing All User Configurations

The production application must support the following users in addition to local LAN users:

● Customers over the Internet. ●

A remote department of internal users who have their own LAN on a different segment.

● An entire department who currently use IBM 3270 terminals to access the mainframe applications directly. These users are being

upgraded to network computers, but still require access to other mainframe 3270 applications.

● Nomadic users (sales staff) who can access the system for only two

hours a day.

The Java Technology Architecture in Production

8-5

Application Test Architecture

Test Configuration

The test configuration should include or simulate the previously listed users:

● Internet users – Test through firewalls into the company. ● Remote users – Test or simulate the WAN. Some routers provide

the capability to simulate a WAN. ● Terminal users – Test network computer access using an applet.

There should also be tests using a screen scraper product to ensure these users can still access other mainframe applications.

● Nomadic users – Test dial-in support.

8-6

Java Technology Architecture Planning and Design

Application Test Architecture

Additional Testing

Some additional testing that would be beneficial is ● Test all Web browsers. ● Test the RDBMS tier on a separate platform. This testing should

highlight any problems with running the database access protocols over a network stack.

● Do stress testing. Automatic testing tools support Java applets and protocols (see Appendix B, ‘‘References,” for vendors).

● Test any services that are used by the system, such as email,

domain naming system (DNS), and so forth.

The Java Technology Architecture in Production

8-7

Discussion – How does the deployment architecture differ from the development architecture?

● How do you map the application tiers to physical servers? ● What additional things might you test?

8-8

Java Technology Architecture Planning and Design

The Java technology deployment architecture may differ from the architecture that was tested. This could manifest different characteristics in terms of performance and usability. Figure 8-2 illustrates how the tiers are deployed in production.

Tier one

Tier two

Tier three

Application RDBMS Customer

Remote Remote user

Web SNA (extranet)

server gateway

Mobile

PPP

user (extranet)

Figure 8-2

Application Deployment Architecture

The Java Technology Architecture in Production

8-9

Application Deployment Considerations

As illustrated by Figure 8-2, ● The client tier may be deployed on a LAN, over a WAN, or over

the Internet. If the Internet is used, a firewall will need to be added in deployment. What effect will this have on the applet?

▼ How can you be sure the applet will work through firewalls? (Some firewalls do not allow RMI or Java IDL to pass through.)

▼ Which customers have their own firewalls? The same

considerations apply. ● The Web server is usually in a data center. It may be in the same

data center as the mainframe, or it may access the mainframe over

a remote SNA or TCP/IP link. If the mainframe is remote, has it been tested in this capacity, or was a local “test” mainframe used?

8-10

Java Technology Architecture Planning and Design

● An additional Web server has been added locally to the group of remote users. This configuration is recommended for optimal

performance as the client platform is a network computer such as

a JavaStation ™ network computer.The local Web/cache server can hold user files, as well as the boot server for the network computers.

● The Java application or application server now resides on a different server platform from the Web server (behind the

firewall). The Web server is simply a pass-through servlet which invokes the application server through a second firewall (refer to Module 6, ‘‘Designing a Secure Java Technology Architecture,” for an example).

Note – If this is the first Java (or Internet) application to be deployed by the customer, there are many other considerations for deployment—training of operations staff, security awareness, and so on.

● The database server on tier three may involve procurement of a new server platform and disk storage. It also necessitates the

installation of the production RDBMS, RDBMS client-server middleware, and JDBC drivers on the tier two platform, and the loading of production data into the database. This differs from the data that was used during testing.

The Java Technology Architecture in Production

8-11

Application Deployment Considerations

Production Services

As an architect you should ensure that any other services that are required by the new application are provided in the production environment.

You might also have to determine where the following services reside and how they affect the performance of the application:

● Printing ● Email ● File transfer services (for example, FTP)

8-12

Java Technology Architecture Planning and Design

Production Services (Continued)

● Naming services (for example, DNS for name resolution between host names and IP addresses, Network Information Service (NIS)

for local area network lookups, column address select (CAS) for locating CORBA objects, and so on)

● ORBs and registries for CORBA and RMI

Note – Applications server products may be pre-built with one or more of these services.

The Java Technology Architecture in Production

8-13

Application Deployment Considerations

Mobile Users

In the customer example from Module 7, ‘‘Designing an Architecture for Performance,” mobile users only access the system for one to two hours a day. To optimize this time, they require a different approach to applet distribution.

● Applications are pre-loaded onto the hard disk of each laptop. ● New versions can be “pushed” down. When the mobile user logs

on, there is a check to see if the applet image stored at tier two has changed. If so the user can download the new applet. Web browsers can use push technology (for example, Marimba) on behalf of the applet to accomplish this without any changes to the applet.

8-14

Java Technology Architecture Planning and Design

Network Computers

There are special deployment considerations for the network computers that are to replace the IBM 3270 terminals. Network computers rely on these services being provided, ideally over a local LAN. They include

A boot server for downloading the network computer operating system (for example, JavaOS ™ for the Sun JavaStation). The boot image resides on the boot server, and is downloaded when the users switches on the network computer.

● Dynamic host configuration protocol (DHCP) for assigning IP addresses dynamically to the network computer.

● Local Web/cache server for performance. This keeps a local cache of the most frequently used data (including applets and class files)

for the network computer.

The Java Technology Architecture in Production

8-15

● Access to DNS servers for naming services so that the network

computer can locate hosts on the IP network ● NFS ™ system servers to hold home directory files and directories,

since the network computer has no local storage ● Access to Internet message access protocol (IMAP) based mail

servers. Network computers need to use server-based email

Note – The Java Server Sizing Guide can be downloaded from Sun’s external Web site. This provides rules for sizing the servers used to support network computers.

8-16

Java Technology Architecture Planning and Design

Applet and Application Distribution

Though applets are easily distributed using HTTP URL requests from

a Web browser, there might be an additional need to distribute servlets and applications throughout an enterprise.

In Figure 8-3, local applications servers have been added in Europe and Asia.

● When new versions of the application are released, new applets and servlets can be pushed down to the Web cache server in

Europe and Asia. ● Purchased application servers such as Novera provide the

capability to dynamically load new classes to remote application servers.

The Java Technology Architecture in Production

8-17

Applet and Application Distribution (Continued)

Web server

RDBMS

Applet and

server

application distribution

Mainframe Applet

Application

Web

server server

distribution Remote

Applet

Web/cache server

Figure 8-3

Deployment Considerations for Enterprises

8-18

Java Technology Architecture Planning and Design

Deployment Considerations for Enterprises

Rules for Applet Distribution

Generally, for a LAN-based client population, the applet should be downloaded each time it is requested. The benefits of zero administration on the client outweigh the download overhead.

For remote LAN-based clients, there may be sufficient demand for a local Web/cache server.

For WAN-based clients, consider using push technology to push a new version of the applet and store on client.

For mobile users, seriously consider the use of push technology.

The Java Technology Architecture in Production

8-19

Large Applications

Applications with large amounts of users may require multiple Web servers, applications servers, distributed databases, and transaction- processing monitors to handle the workload (Figure 8-4).

RDBMS Balancer

server Transaction

Distributed Distributed

transaction RDBMS Applet

Figure 8-4

Large Application Deployment Considerations

As illustrated in Figure 8-4, the enterprise now has ● Multiple Web servers. Additional Web servers can be added

without changing the URL used to access the applet. The URL re- direct feature can be used here.

● Multiple application servers. Multiple application servers might be required for workload balancing. A load balancing scheme (round- robin or other) must be devised, unless the application server already has such a feature built-in.

8-20

Java Technology Architecture Planning and Design

Large Applications (Continued)

● Transaction monitors. The majority of Java technology three-tier applications do not use a transaction monitor such as IBM CICS or

Encina, or BEA Systems Tuxedo. Heavily used transaction-style applications require a transaction monitor for:

▼ Large numbers of concurrent users (for example, greater than

1000 concurrent users). ▼ Transaction load-balancing from multiple Java application

servers. ▼ Coordination of updates from the Java application servers to

multiple back-end databases (providing two-phase commit). The transaction monitor can be a container for Enterprise JavaBean components.

The Java Technology Architecture in Production

8-21

Operational Issues

Startup

Web servers and Java application servers must be manually started so that they can listen for incoming HTTP and TCP requests. The RMI registry and RMI application servers must also be explicitly started. The exceptions to this are:

● Servlets, which are invoked by the Web server ● CORBA application servers, which are automatically started by

the ORB ● Enterprise JavaBeans, which are invoked by the container

Note – There should also be scripts to restart servers after they have failed.

8-22

Java Technology Architecture Planning and Design

Troubleshooting

Adopting a three-tier architecture requires a new set of management and monitoring tools to aid in the diagnosis and resolution of problems. Instead of two processes (client and DBMS server), there may be several:

● The client tier ● The Web (HTTP) server ● The tier-two application server, servlet, or Enterprise JavaBean ● The RDBMS server ● Middleware such as CORBA

Java RMI and Java IDL add processes of their own, increasing the number of processes even more. Thus, when something goes wrong, it is much harder to find the source of the problem. In addition, these processes are likely to be distributed on multiple platforms over multiple types of networks.

The design of a three-tier applications should include some means of remote monitoring and management. It is much easier to incorporate them at the design phase than it is to insert them after the application has been developed and deployed.

● CORBA servers and application server products usually provide a set of centralized monitoring and management tools.

● Third-party management and monitoring tools usually support the Simple Network Management Protocol (SNMP) standard.

The Java Technology Architecture in Production

8-23

Keeping Pace With Change

Among the things that the architect should consider are: ● Versioning ● Reuse ● Maintenance

Versioning

With the application classes being distributed, version control is crucial and more complicated.

● Versioning control should ensure that the latest Java technology classes are downloaded to the client and to remote servers.

● Other versioning control should ensure that new versions of Web browsers and Web servers are deployed and distributed when

available (after testing with the application). This is crucial to time constraints if the new applet has a higher JDK requirement.

8-24

Java Technology Architecture Planning and Design

Reuse

Reuse of objects at the analysis, design, and development phases pays off in the long run. To encourage reuse, architects should establish or promote:

● Centralized object libraries. The contents of these libraries would

be made available to all developers (perhaps using a Web site). The library should contain documentation about the objects as well as the owner’s name, JDK dependencies, interfaces, methods, parameters, and exceptions that are raised by the object. Examples of reuse objects might be:

▼ Purchased objects, such as JDBC drivers ▼ GUI objects (such as bar charts, tabs, trees, and grids) ▼ JavaBeans ▼ Enterprise JavaBeans ▼ Servlets ▼ Dialog boxes (for consistency among applets) ▼ Sort objects ▼ Table objects ▼ Login processing

● Development of re-usable objects ● Versioning control on the versions of objects in the library.

What happens when an object in the library undergoes an update?

The Java Technology Architecture in Production

8-25

Maintenance

Maintenance issues can be raised if: ● JDK releases include changes to Java APIs that could affect

customer’s applet and application code. This will require regression testing of the customer’s code.

● New versions are made to applications and databases that require requisite changes to applets or changes to applets that require newer Web browsers (JVMs). Users who have the old versions of

applets cached or stored must have a mechanism to download the new applet.

8-26

Java Technology Architecture Planning and Design

Table 8-1 summarizes the tasks you must complete when designing a Java technology architecture.

Table 8-1 Tasks When Designing a Java Technology Architecture

Task Check

Develop requirements document: • Use cases • Interview customers, external users, technical staff,

database administrators (DBAs), and so on • Screen layouts • Data flow • Process dependency

Review requirements document Analyze legacy systems

• Data model • Database schema • Applications

Design object architecture • Packages • Object class diagram • Reuse • UML

The Java Technology Architecture in Production

8-27

Task Check

Distributed object architecture • Client objects • Server objects • Tiers • Object communication (CORBA, RMI, sockets) • Database communication (JDBC) • Legacy communication (screen scraping, peer-to-peer) • Applications, servlets, native code, and Enterprise

JavaBeans • Object persistence (ODBMS, object-relational mapping)

Security conformance • User authentication (authentication servers) • Access control Check consistency with security policy

Verify distributed object architecture (with another Java technology architect)

Design physical architecture Deployment diagrams

• Client platforms • Network • Server platforms • Databases • Firewalls Interview network and systems staff on • Performance issues • Security issues • Network issues • Support • Architecture verification from operational standpoint

Demonstrate prototype to end users

8-28

Java Technology Architecture Planning and Design

Table 8-2 summarizes the things you must check once your Java technology architecture has been designed.

Table 8-2 Checklist Once Architecture is Designed

• 100% Pure Java ™

• User interface consistency • No excessive use of

graphics/widgets/audio/video • JavaBean components • Navigation buttons intuitive and easy to follow • Printing (JDK 1.2) • Email (IMAP) • Security considerations (signed applets, SSL) • Reuse components where possible • JDK level for JVM (or Java Plug-in) • Year 2000 conformance on displayed dates • Internationalization (locales, resource bundles)

Tier two • Reuse (Enterprise JavaBeans) • Servlets • Authentication server • Security (JCE, signed JAR files) • Data design • Performance design • Access control to data • Year 2000 conformance

General • Training • Help • Frequently asked questions (FAQs)

The Java Technology Architecture in Production

8-29

Check that you can accomplish the following: ❑ Design a Java technology architecture that can be easily moved

into production ❑ Given a Java application prototype or pilot solution, advise on

how it can be effectively moved to production status ❑ Recommend solutions for efficiently deploying and distributing

Java technology solutions in production ❑ Recommend Java application development, reusability techniques,

and project management techniques

8-30

Java Technology Architecture Planning and Design

This course has covered the basic rules, considerations, and techniques for designing Java technology three-tiered architectures. Java technology is a growing, evolving industry and there are many other aspects to consider that have not been covered in this course.

These include ● Java Commerce Client, including the Java Wallet, for electronic-

commerce applications ● Java Naming Services, for developing name servers ● Java Management API, for developing network and systems

management solutions ● Embedded JavaChip ™ based systems

The Java Technology Architecture in Production

8-31

Case Studies

Case Studies

The case studies in this appendix are used in the following modules: ● Module 2, ‘‘Designing a Java Technology Architecture” ● Module 3, ‘‘Java Technology Architecture Details” ● Module 4, ‘‘Integration With Existing Applications and Databases” ● Module 6, ‘‘Designing a Secure Java Technology Architecture”

A-1

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

Instructions

Work in teams to produce the deliverables described here. At the end of the allowed time, each team should present their solutions. Presentations should not last more than ten minutes each.

1. Read and familiarize yourself with the case study that follows these instructions.

2. Prepare for a meeting with the customer tomorrow. There are two deliverables expected from you.

a. Sketch out a three-tier architecture for the CARES application. This should show the tiers and the interfaces between the tiers. You may use any notation to draw the architecture, but UML notation is preferred; for example

UML package diagram (logical view)

UML deployment diagram (physical view)

b. Make a list of questions that you need to ask the customer. This checklist will include requirements for Webtop clients, mobile users, client hardware and software mix, client network bandwidth, client security needs, and so forth.

3. Present your architecture and designs to the customer (in this case, the other students). You can use any method you prefer to communicate your design to the customer such as whiteboard, slides, or notes. At this presentation you must explain how your object class diagram can benefit the customer and how your architecture provides scalability, performance and high availability.

4. The architecture should specify ▼ Tier one design

▼ Tier two design ▼ Communication protocols ▼ Dependencies and constraints

A-2

Java Technology Architecture Planning and Design

Sample Questions to Ask The Customer

Ask the customer questions similar to the following: ● Is there a specification for your current system and network? ● Is there an entity-relationship diagram for the SQL server

database? ● Are your developers familiar with any databases other than SQL

Server? ● Are your developers familiar with Java, C or C++?

Case Studies

A-3

DirectContact, Inc.

DirectContact Inc. is a provider of cellular networks to subscribers. Their business is expanding rapidly.

They have a customer service application called CARES (Customer and Reseller Express Support) in use at their three customer call centers in San Francisco, Chicago, and Atlanta. It is used in an intranet-only environment.

The CARES application is a two-tier design which has a Web front end. Customer calls arrive at a call center; the calls are then directed to an available customer representative who uses a Web-browser form to enter the customer name and account number. The form causes a transaction to be sent to the database and the results fill out the form on the Web browser with customer history information, so the representative can assist the customer in an informed manner. The transaction is accomplished with a single HTML form so there is no need for maintaining state.

Web browser

Tier two

TELNET Web server

CGI

Telephone Customer

switch

VB

activity network

Billing and customer history

Figure A-1

Schematic Flow of the Application

A-4

Java Technology Architecture Planning and Design

DirectContact, Inc. (Continued)

If the inquiry relates to the customer’s service availability, a transaction must be sent to the active telephone switch which holds the customer’s recent activity logs. This is done using a TELNET remote login to the switch and a specially generated user ID and password. This transaction interrogates the switch in real-time. The switches run on UNIX environment servers, networked together.

The customer service representatives use Windows 95 PCs with Netscape Navigator browsers. The server runs a Netscape Web server on Windows NT. The form is handled by a CGI script and an application written in VisualBasic+. The application accesses data stored in a Microsoft SQL Server database. The business logic and database access logic are both hard coded in the VisualBasic+ application and are hard to separate out. The application interrogates the switch in real time to obtain error statistics and logged information pertaining to the customer.

The Windows NT server is approaching maximum capacity. The customer perceives that this solution will not scale enough for its current growth rate, and wants to know if:

1. A Java technology solution can provide more scalability. If so, how?

2. A Java technology solution can provide more performance, and how can this be demonstrated, predicted and measured?

3. There would be advantages in a pure object-oriented environment. How would an object application access the switch, which is non-object?

4. They can develop a Java technology solution without doing object-oriented analysis. DirectContact feel that they have no experience in this area.

5. High-availability can be guaranteed with Java technology and objects. If so, how?

Case Studies

A-5

Constraints

With over 250 service operators in three regional locations servicing a customer base of 25,000 customers (and growing), the customer prefers to keep the existing front end, to reduce training requirements and productivity dips. Thus, your solution needs to process an HTML form, access the database, and then access the switch, all in real-time.

The customer has decided to standardize on Netscape products for both the Web browser and the Web server.

The customer has not standardized on a SQL Server as a database, and is interested in your recommendations.

Since the customer is asking for proof of performance and proof of concept, you will probably have to develop a prototype so that you can show the customer the improved performance and flexibility.

A-6

Java Technology Architecture Planning and Design

Notes

Case Studies

A-7

Instructions

Work in teams to produce the deliverables described below. At the end of the allowed time, each team should present their solutions. Presentations should not last more than ten minutes each.

● Read and familiarize yourself with the case study that follows

these instructions. ● Prepare for a meeting with the customer’s technical architects

tomorrow. There are two deliverables expected from you:

1. Describe the advantages of a multi-tiered enterprise architecture with respect to the customer’s application.

▼ How would you describe their current architecture in terms

of tiers? ▼ What problems do you see in the current architecture? ▼ What questions do you have for them that will help you

design an architecture?

2. Sketch out a three-tier architecture. This should show the tiers and the interfaces between the tiers. Focus on the packages (of classes) that are responsible for the workflow management. Consider the following:

▼ Should the Internet-based quote request mechanism be an applet, or an HTML form (possibly with JavaScript

extensions)? How will this communicate with the middle tier? ▼ Should you preserve the Smalltalk presentation and business

logic (which currently runs on the Insurance Agent’s PC), as a Smalltalk program, or convert it to Java technology? If the Smalltalk application is split up, how will these components communicate with each other, and with the databases?

▼ What additional business logic is needed? What other new features are needed, and how will they be implemented?

▼ How will middle-tier services access data and programs on

the mainframe?

A-8

Java Technology Architecture Planning and Design

Dynaclaim, Inc.

Dynaclaim Inc. is an insurance company providing auto and home insurance to customers throughout the United States. They have no offices, and instead offer their services exclusively through a toll-free telephone number.

Dynaclaim’s work flow is as follows:

1. A prospective customer calls the “800” number and is connected to a Customer Service Representative (CSR).

2. The CSR enters the customer’s personal information, and any other information required for producing a quote. This information depends on the type of quote (auto, fire, life or home), on state regulations that vary according to the customer’s home address, and on the customer’s answers to specific questions. This information is stored in a DB2 database on the mainframe.

3. The CSR generates a Request for Quote (RFQ).

4. An Insurance Agent (IA) receives the RFQ. Using the Smalltalk QuickQuote application, the IA gathers the information needed, generates a quote, and sends it to the customer using phone, fax, email, or standard mail. Using the QuickQuote application, the IA performs the following functions:

a. Pulls the next pending RFQ from a DB2 database “queue” according to the type of quote requested. Agents have different backgrounds and specialties, and the application maintains an “agent profile” in a file stored on the local disk.

b. Enters values from the RFQ to create a batch request to the mainframe for base rate and standard adjustment information. The IA specifies the details of the actuarial data that are needed. Many of these are dependent on the customer situation.

Case Studies

A-9

Dynaclaim, Inc. (Continued)

c. An application on the mainframe extracts the required actuarial data from an IMS database. The data are stored in a flat file, which is transferred to the QuickQuote application running on the agent’s PC. During transfer, the PC is not available for other operations.

d. When the data file is returned from the mainframe, the IA initiates a premium calculation. The IA manipulates the Smalltalk expert system interactively, using the downloaded data, to produce a competitive quote. This calculation is compute intensive, and while it is running it is not possible to run other applications or to process other RFQs. Only a subset of the downloaded data is used in the premium calculation. The IA may then refine the quote based on their knowledge of the specific customer (for example, what has the customer paid previously for insurance and what amount can the customer tolerate). The agents are paid a commission fee so they need to produce the maximum rate that can be tolerated by the customer.

e. Once the premium is calculated, the IA can call the customer directly, and can select other formats for generating a written quote (fax, email, or standard mail). The IA then oversees the customer order.

f. Customers purchase the insurance by signing a contract and

mailing a check to Dynaclaim. The turnaround time for a quote is one hour, measured from the time

the customer connects to the CSR to the time an Insurance Agent calls the customer with a quote. Dynaclaim has kept this time to one hour by hiring additional IAs as business has grown. The IAs are experts in the sense that they are highly skilled at using the QuickQuote application.

A-10

Java Technology Architecture Planning and Design

Dynaclaim, Inc.

Systems Architecture Dynaclaim’s system architecture includes the following elements:

● IBM System 390 mainframe running

▼ An IMS hierarchical database containing base insurance rate tables and standard adjustment tables, both used to calculate a

quote. A COBOL program, responding to batch requests from the Insurance Agent, runs on the mainframe, extracts data from this database and returns a flat file to the IA’s Smalltalk application.

▼ An IBM DB2 relational database (queue) containing the

customer information entered by the CSR.

A data-entry application driving the 3278 terminals used by the CSRs.

● 150 Pentium PCs, connected on Wide Area Network (128k),

running Windows 95 ▼ The “QuickQuote” application written in Smalltalk, used by

the IAs to pull off the next RFQ, obtain rate information, calculate a premium, and generate a quote in a variety of formats

Data entry

IBM 3278 QuickQuote

Pentium PC

WAN

IBM System 390

IMS (actuarial data) Insurance

Batch request

to mainframe.

DB2(work queue)

Agent

Flat file

CSR Application (data entry)

returned.

Figure A-2

Dynaclaim’s System Architecture

Case Studies

A-11

Dynaclaim, Inc.

Requirements Dynaclaim would like to re-architect their system with the following

goals: ● Provide a way for customers to obtain quotes over the Internet

with a turnaround time of two minutes, measured from when they finish entering all required information and submit their request

● Reduce the turnaround time on phone requests to 7 minutes or

less ● Preserve the Smalltalk object-oriented expert system logic, which

is well-tested ● Enable IAs to run other applications on the PC while premiums

are calculated ● Increase the volume of business without increasing the IA

headcount

Note – The most important question is why does it take one hour to produce a quote? Where is the time being spent; what is the bottleneck? This understanding will be crucial to the success of a proposed architecture.

A-12

Java Technology Architecture Planning and Design

Dynaclaim, Inc.

Requirements (Continued) Due to the design of the QuickQuote application (single threaded) and

the load it places on the system, Insurance Agents can handle only one RFQ at a time, so they must wait while data is downloaded and premiums are calculated. Average time breaks down as follows:

● CSR interview = 15 minutes ● Time in queue = 15-20 minutes ● Insurance Agent creation of batch request = 10 minutes ● Queuing on mainframe before batch job runs = 5-7 minutes ● Data file download = 1-2 minutes (approximately 500Kb) ● Insurance premium calculation = 2 minutes ● Quote preparation = 5 minutes

Case Studies

A-13

A-14

Java Technology Architecture Planning and Design

Instructions

Work in teams to produce the deliverables described in this section. At the end of the allowed time, each team should present their solutions. Presentations should not last more than ten minutes each.

1. Read and familiarize yourself with the case study that follows these instructions.

2. Prepare for a meeting with the customer’s technical architects tomorrow. There are three deliverables expected from you:

a. Assessment of the options for integration or migration.

b. Draw the architecture, including communication between the

tiers.

c. Define the business objects needed for storing the POs and

PRs.

Deliverable 1 Assess each of the migration options available to the customer: ● Screen scraping.

● Partial migration. This would involve rewriting the client and business logic in the Java programming language, and integrating

the result with the existing data. ● Redesigning and rewriting the entire application and data in the

Java programming language. For each option, determine: ● Does it meet the customer’s needs?

● What value does it bring to the workflow? ● What are the associated costs? ● What are the associated risks?

Case Studies

A-15

Instructions

Deliverable 1 (Continued) ● How would the company handle the transition to Java

technology? For example, would there be a period of parallel running with both the old and new systems running together? How might the company keep data synchronized in this situation?

Deliverable 2 Draw the architecture for integrating the client and tier-two logic with

the existing mainframe back-end systems. What additional objects are needed for communication between the

tiers? Deliverable 3

Make a list of the objects needed for storing the purchase order and purchase request objects.

A-16

Java Technology Architecture Planning and Design

Plastic DeSign, Inc.

Plastic DeSign Group is a division of a large world-wide manufacturing company that produces plastic parts and products. Your company has put out a bid for migrating the purchasing systems from the current mainframe environment. You have been asked to review the bid and produce an architectural design.

Purchasing Requester

Administrator

Purchase

officer completes

obtains

request (PR)

reviews PR form

approvals for

entered in

1st level

price and

approval

approve

2nd level

order (PO)

payable system

Other

3rd level

mainframe

PO mailed to

Figure A-3

Plastic DeSign’s Current System

Case Studies

A-17

Plastic DeSign, Inc. (Continued)

The current system of processing purchase requisitions is manual:

1. Requesters fill out a paper form to initiate the purchase request. The paper form is then passed to an administrator who obtains signature approvals from the designated approvers. This process is a serial process and can take up to two weeks to get all the requisite signatures.

2. When all the signatures are in place, the purchase request is entered into an IBM system/390 mainframe system from an IBM 3270 terminal. This creates a purchase request (PR) in the mainframe database. The mainframe database is a hierarchical, proprietary database that can only be accessed using IBM CICS transactions.

3. The purchasing officer (buyer) reviews the PR from a Macintosh computer with IBM 3270 emulation, and, if funding is approved and available, converts the PR into purchase order (PO). The vendor is selected and the PO is printed and mailed to the vendor.

Requirements

PlasticDesign must modify the mainframe application because it is not Year 2000 compliant. Additionally, they want to take the opportunity to streamline the purchase order workflow. They are assessing whether to rewrite the application from scratch (which involves converting the purchase order database to an ODBMS or RDBMS), or simply to provide a Web-based front-end to the mainframe purchasing data.

They are interested in what object design and Java technology can bring to the table, though they have little object-oriented experience beyond a few two-tier applications developed using Microsoft VisualBasic and PowerSoft PowerBuilder.

The new system must support 500 concurrent users, with a total user population of 3000.

A-18

Java Technology Architecture Planning and Design

Plastic DeSign, Inc. User Requirements

For this application, there are five main types of user. These paragraphs describe their roles and responsibilities.

1. Requester . The originator of the PR should be able to enter the request directly into the system, from any system on the company network. There should be a login process that uses the same user IDs and passwords as the mainframe IBM Resource Access Control Facility (RACF) security system, so that users do not have to remember a second password. The requester may create a brand new requisition, an amended requisition from a previous requisition, or a requisition to extend an existing PO.

2. Administrator. In the current system the administrator manually enters the data into the system. This will be unnecessary in the new system, but, the administrator may take on the role of the requester instead.

3. Approver. The approver(s) should be notified immediately if there is a PR for them to approve. They need to be able to take any of the following actions:

a. approve and forward to the next level of approver (if any).

b. edit the PR and then forward.

c. cancel the PR, providing a reason, and notify the requester.

d. return to the requester for changes.

4. Buyer. The purchasing officer needs to be able to locate prospective vendors by type of product or service. There may be multiple vendors within in a single PO.

5. Vendors. The supplier of goods. There is a new requirement that the company wants to allow vendors to check the status of their POs (this requires additional security). Because of this, the vendors are part of the system domain in the new architecture.

There could also be other users: ● Auditors ● Finance to check POs against departmental budgets

Case Studies

A-19

A-20

Java Technology Architecture Planning and Design

Instructions

Work in teams to produce the deliverables described here. At the end of the allowed time, each team should present their solutions. Presentations should not last more than ten minutes each.

1. Read and familiarize yourself with the case study that follows these instructions.

2. Prepare for a meeting with the customer’s security specialists tomorrow. There are two deliverables expected from you:

a. List the security requirements for this application. Explain how these requirements can be addressed. Can these requirements all be met by Java technology? If not, what must

be purchased or written?

b. Sketch out a three-tier implementation architecture for this application. What constraints do the security requirements impose on the architecture? Refer to the whitepaper on JDK

1.2 security that the instructor hands out.

Case Studies

A-21

UV Management Group

UV Management Group is a real-estate management firm that manages and maintains commercial real estate (residential and office buildings) across the United States. They sub-contract much of the maintenance work (such as repairs and cleaning) to contracting companies located near to each individual building.

Sub-contractors must file quarterly inspection reports on the condition of the building and grounds. These reports cover each major sub- system of the building (heating, ventilation, air conditioning, water, elevators, and so forth) and photographs of the exterior and interior of the building.

UV Management Group would like to use these reports to do trend analysis on the conditions of each building. This would allow them to spot problem properties, and under-performing sub-contractors, earlier. Unfortunately there are several problems with the current system which prevent them from achieving this.

● Currently the system uses paper forms which must be keyed into a database before any analysis can be done on the data. The data

entry job is frequently under-staffed and sometimes ignored, resulting in out-of-date records in the database and unfiled paper gathering dust in folders.

● The current system uses textual descriptions of the properties. These descriptions are highly subjective. Is a building with a “very

good” roof and a boiler that “needs extensive repair” in better or worse shape than a building with an “OK” roof and an “OK” boiler?

● There is no standard for submitted photographs. One building supervisor might take photographs of the entry and lobby.

Another might take photographs of the entire exterior and roof. Even when photographs of the same part of the same building do accompany successive reports, different lighting conditions associated with the time of year make it hard to compare the photographs from one quarter to the next.

● The photographs are not scanned so there is no electronic way to

review them.

A-22

Java Technology Architecture Planning and Design

Application Requirements

In order to solve these problems UV Management plans to implement

a Web based reporting system. An applet will replace the current textual form and will include

● Numerical ratings of each important category ● Objective guidelines on how to assign the numbered rates

The sub-contractors will submit their reports over the Internet. The system will automatically enter the new report into the database. As part of the roll-out for this product UV Management will share the cost of digital cameras for each sub-contractor and define a series of standard photographs that must be submitted with each report. These images will be transferred to the PC used by the supervisors to submit the report. The applet implementing the Web form must be able to read these images and attach them to the report.

Case Studies

A-23

Security Issues

The architecture and deployment plan must address several security issues:

● Firewall – Since this application will expose parts of UV management’s internal IT systems to the Internet, there must be an adequate firewall in place to protect these systems.

● Client side file access – The applet must be able to access the sub- contractor’s PC’s file system—something applets are normally not

allowed to do. ● Firewall protocols – UV Management has no control over what, if

any, firewall is running on the sub-contractor’s side of the network, nor over how it is configured.

● Data privacy – While the reports are not as sensitive as medical data or financial records, they are proprietary information and

should be reasonably protected from unauthorized viewing by anyone on the Internet.

● Access controls – While sub-contractors must be able to pull up and review reports for buildings under their control, they must

not be able to access records for any other property. Furthermore, UV Management’s internal users are not allowed free access to the data. Some users are allowed to access records only for buildings for which they are directly responsible. Others users, like auditors and managers have much greater access.

A-24

Java Technology Architecture Planning and Design

Case Studies

A-25

References

This appendix contains references for each of the course modules, and in addition, includes the following:

● Evolution of the JDK ● Benefits of the Java platform ● Java programming language packages ● Java programming language APIs

B-1

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

JDK 1.0

JDK 1.0 contains ● lang , util, io, net and awt packages ● No printing support ● No database access ● Sandbox security ● No GUI widgets in AWT

JDK 1.1

JDK 1.1 includes ● JDBC ● RMI ● JavaBeans ● AWT enhancements ● Delegation (JDK 1.1) event model

Note – You cannot mix JDK 1.0.2 and JDK 1.1. event models.

● JNI ● Internationalization ● JAR files ● Security enhancements ● APIs for digital signatures and message digests ● Signed JAR files ● Signed applets ● Reflection

B-2

Java Technology Architecture Planning and Design

JDK 1.2

JDK 1.2 consists of ● Java Foundation Classes (JFC)

▼ Swing ▼ JFC which runs on top of AWT ▼ JFC components which are JavaBeans ▼ Drag and drop tools ▼ Two dimensional (2D) graphics

● Security enhancements ▼ Java Protected Domains

▼ Configurable security policy ▼ Support for x509v3 certificates ▼ SSL sockets

● RMI enhancements ▼ Remote object activation

● Java IDL (CORBA) ▼ Java to IDL compiler ▼ Java ORB

● Servlets ● Native thread support

References

B-3

Some of the benefits of Java technology are ● Platform independence (client, server) ● Decouples application from platform ● 100% Pure Java technology ● Extensive API set ● Server-side Java ● Enterprise Java APIs ● Security ● Compile time and runtime protection ● Memory protection ● Extensible security using Java Security API ● Extensible to non-traditional devices ● Components (JavaBeans, Enterprise JavaBeans) ● Code distribution (applets, servlets)

B-4

Java Technology Architecture Planning and Design

Table B-1 lists some of the Java technology packages and their uses. Table B-1 Java Technology Packages

Name

Use

java.applet

Graphics and audio for applets

java.awt GUI component classes, delegation event model, dynamic query of component properties, printing, and pop-up menu

java.beans Software component model using event passing, may also connect to ActiveX controls

java.io File stream read and write, object serialization

java.lang ClassLoader, SecurityManager, Threads, Runtime, Exceptions, System level control

java.lang.reflect Reflection used to introspect the data fields and methods of a Bean class

java.math

Conversion precision

java.net TCP/IP socket support, UDP socket support, URLs, encoding to MIME format

java.rmi Java technology to Java technology remote object methods execution through what appears to be local object references

java.security Digital signatures, data encryption, key management and access control

java.sql Database access using SQL (drivers are vendor supplied), use Intersolv bridge for ODBC databases

java.txt

Text formatting and searching, internationalization

java.util Calendar, date, locale, time zone, system and user defined properties, StringTokenizer (parser)

References

B-5

Some of the Java technology APIs are listed in Table B-2. Table B-2 Java Technology APIs

User

Enterprise Component

Lower

Media

Miscellaneous API Set

Interface

Model

Level APIs

API Set

API Set

JavaMail (to mail- Two Naming and

JNDI (Java JavaBeans

AWT

JMS (Java

dimension- Directory

(Abstract

Message

enable Java

applications) al (2D) Interface)

Three Method

RMI (Remote Enterprise

JFC (Java

JTS (Java

JavaComm

dimension- Invocation)

Communications) al (3D) JDBC (Java

Classes)

Service)

Java Media Database

JavaHelp (for

Framework Connectivity)

adding on-

line help to Java applications)

JavaIDL (Java

JTAPI (Java technology to

Java

Telephony CORBA

Accessibility

API) connectivity)

API (for

creating applications for users with disabilities)

Java Security Java Sound API

JMAPI (Java JavaSpeech Management API)

Java Advanced Imaging API

B-6

Java Technology Architecture Planning and Design

Table B-3 lists some references that contain additional information on the topics covered in Module 3, ‘‘Introduction to the Java Technology Architecture Process.

Table B-3 References for Module 3, ‘‘Introduction to the Java Technology Architecture Process”

URL

Description

http://www.sun.com/javacenters Sun Java Centers Web site http://java.sun.com/jdc/

Java Developer Connection (subscription site offering support for Java technology developers)

http://www.omg.org Object Management Group (contains the specification for CORBA)

http://www.rational.com Rational Software Corporation (contains definitions of the OMT and UML techniques)

http://www.sei.cmu.edu/architecture Software Engineering Institute (part of Carnegie Mellon University in the United States)

http://hillside.net/patterns Design patterns home page http://java.sun.com/products

Overview of Java technology products http://www.microsoft.com/com

Distributed Component Object Model (DCOM) information

References

B-7

Table B-4 lists references that provide additional information on the topics covered in Module 3, ‘‘Designing a Java Technology Architecture.”

Table B-4 References for Module 3, ‘‘Designing a Java Technology Architecture”

URL Description

http://java.sun.com/products/java-server/ Information about servlets http://www.cisco.com

Load balancing hardware http://www.resonate.com

Load balancing system

B-8

Java Technology Architecture Planning and Design

Additional information on the topics covered in Module 3, ‘‘Java Technology Architecture Details “ can be found at the URLs listed in Table B-5.

Table B-5 References for Module 3

URL

Description

http://java.sun.com/jdc Java developer information site http://www.roguewave.com

Vendor of Java technology widgets http://www.objectspace.com

Vendor of Java ORB product http://www.inprise.com

Vendor of VisiBroker, Java ORB product (formerly Borland)

http://www.omg.org Object Management Group site

References

B-9

Table B-6 lists URLs that contain information on the topics covered in Module 3, ‘‘Integration With Existing Applications and Databases.”

Table B-6 References for Module 3, ‘‘Integration With Existing Applications and

http://java.sun.com/jdbc/jdbc.drivers.html How to choose a JDBC driver http://www.odmg.org

The Object Database Management Group

http://www.software.ibm.com IBM software site for DB2, IMS and CICS information

http://www.ibi.com Information Builders (database gateway)

http://www.intersolv.co m

JDBC drivers

http://www.novera.com Object-relational mapping vendor, Novera application server

http://www.persistence.com Object-relational mapping vendor and ODBMS

http://www.weblogic.com Object-relational mapping vendor http://www.roguewave.com

Object-relational mapping vendor and JDBC drivers and tools

http://www.versant.com ODBMS vendor http://www.objectivity.com

ODBMS vendor http://java.sun.com/products/java-blend

JavaSoft object-relational mapping

http://www.hursley.ibm.com/mqseries IBM messaging information http://www.openconnect.com

WebConnect screen scraper product

http://www.sun.com/products-n-solutions NetraJ software with WebConnect bundled

http://www.insignia.com NTRIGUE screen scraper product

B-10

Java Technology Architecture Planning and Design

Databases” (Continued)

URL

Descriptions

http://www.citrix.com WinFrame screen scraper product http://www.graphon.com

Go-Joe screen scraper product http://www.bluelobster.com

Blue Lobster Software, mainframe integration products

http://www.microsoft.com Microsoft Terminal Server http://home.netscape.com

Netscape Application Server http://www.netdynamics.com

NetDynamics application server (now part of Sun)

http://www.weblogic.com Weblogic Tengah application server

http://www.vitria.com Integration product based on messaging

http://java.sun.com/products/jdbc/ JDBC 2.0 specifications

References

B-11

Table B-7 lists some references that provide additional information on the topics covered in Module 3, ‘‘Creating New Application Architectures.”

Table B-7 References for Module 3, ‘‘Creating New Application Architectures”

URL

Description

http://webwork.eng.sun.com/products/jndi Information on Java Naming and

Directory Interface (JNDI) http://www.sun.com/suntest

Java software testing tools http://java.sun.com/beans

JavaBeans component model http://www.marimba.com

Marimba push technology http://www.ibm.com

CICS and Encina EJB servers http://www.hursley.ibm.com/mqseries

IBM MQSeries messaging middleware

http://www.beasys.com Tuxedo EJB server http://www.tibco.com

Publish/subscribe vendor http://www.weblogic.com

EJB server vendor (Tengah) http://www.oracle.com

EJB server vendor http://www.persistence.com

EJB server vendor http://www.sybase.com

Sybase Jaguar CTS EJB server http://www.gemstone.com

EJB server vendor http://www.inprise.com

EJB server vendor http://www.ejbhome.com

Miscellaneous EJB information and links

B-12

Java Technology Architecture Planning and Design

The list of URLS in Table B-8 provide additional information on the topics covered in Module 3, ‘‘Designing a Secure Java Technology Architecture.”

Table B-8 References for Module 3, ‘‘Designing a Secure Java Technology Architecture”

URL

Description

http://www.rsa.com RSA Data Security supplies encryption algorithms

http://www.novera.com Novera management server (supports security)

http://java.sun.com/security Security information from JavaSoft http://java.sun.com/sfaq

Security frequently asked questions

References

B-13

Table B-9 contains references that can provide additional information on the topics covered in Module 3, ‘‘Designing an Architecture for Performance.”

Table B-9 References for Module 3, ‘‘Designing an Architecture for Performance”

URL

Description

http://www.sun.com/suntest

Sun’s testing unit (JavaStar ™ , JavaScope ™ , JavaLoad, and JavaSpec ™ )

http://www.specbench.org SpecWeb96 and SpecWeb98 site http://www.klg.com/jprobe

Jprobe Profiler tool

http://www.parasoft.com/wizard CodeWizard Java technology source code analysis tool

http://www.optimizeit.com OptimizeIt profiling tool http://www.marimba.com

Castanet push technology http://www.cisco.com

LocalDirector load balancer http://www.ResonateInc.com

Load balancing vendor http://www.segue.com

Automated test tools vendor http://www.merc-int.com

Automated test tools vendor

B-14

Java Technology Architecture Planning and Design

Additional information on the topics covered in Module 8 can be obtained from the URLs listed in Table B-10.

Table B-10 References for Module 8

URL

Description

http://www.novera.com Java application monitoring http://www.bmc.com

Systems management tool vendor http://www.tivoli.com

Systems management tool vendor

http://java.sun.com/products/javasafe Java technology source code management

References

B-15

Glossary

4GL

Fourth-generation language, which is a non-procedural language designed for ease of use. It is typically used to develop two-tier applications that access relational databases.

ActiveX

An object component that communicates with distributed object components using Microsoft’s Distributed Component Object Model (DCOM).

Applet

Java software that is dynamically loaded by a Web browser from a Web server when an <applet> tag occurs in an HTML page.

AppletViewer

A standalone program that can be used to run and test Java applets.

Authentication

The process of verifying that someone’s claimed identity. Techniques can include using passwords and digital signatures.

Class

An encapsulation of the attributes and methods that describe an object. The class is the template for individual object instances.

Client-server

A term used to describe a two-tier application architecture.

Client stub

An interface used by a client-based object that contains the information needed to invoke a method on a remote object in a CORBA network. The remote object reference held by the client points to the client stub. This stub is specific to the IDL interface from which it was generated.

Glossary-1

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

A piece of software with special interfaces that enable it to plug into other software components as a building block. Components can be assembled into new object applications.

Component model

Enables developers to create new applications using pre-existing software components such as JavaBeans and ActiveX controls. A component model provides certain services including: component interface publishing and discovery, event handling for component communication, persistence for component storage, layout control, and support for application builder tools.

CORBA

Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) is a specification for standards- based object interoperability.

Core Libraries

The basic set of classes that is shipped with the JDK.

DCOM

Distributed Component Object Model; the component model from Microsoft.

Digital certificate

A digitally signed statement from a trusted entity that vouches for the validity of another entity’s public key. Digital certificates are used for authentication purposes. The certificate associates the specified public key with its owner.

Digital signature

A string of bits that is computed from some data (the data being “signed”) and the private key of an entity. The signature can be used to verify that the data came from the entity. It cannot be forged as long as the private key is kept secret.

Distributed object computing

A framework for computing based on the convergence of object- oriented and client/server technologies. Distributed object computing blends the distribution advantages of client/server technology with the richness of real-world information contained in object-oriented models.

Enterprise JavaBeans

An API that extends the JavaBeans component model, enabling it to run on the server side.

Glossary-2

Java Technology Architecture Planning and Design

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

A data model for the design of a relational database. Entities are things of significance within the business being modeled and the relationships show how the entities communicate and associate with each other.

HTTP

Hypertext Transfer Protocol; the most common protocol used on the World Wide Web to transfer Web pages (documents with embedded hypertext links). This protocol runs over TCP.

IETF

Internet Engineering Task Force; oversees and maintains Internet standards such as TCP/IP.

IMAP

Internet Message Access Protocol; an Internet protocol for accessing mail on remote mail servers.

Interface Definition Language (IDL)

The OMG-standard language used for defining the interfaces for CORBA objects. An IDL interface declares a set of operations, exceptions, and attributes. OMG IDL does not include implementations for operations; rather, as its name indicates, it is a language for defining interfaces.

Internationalization (I18N)

A standard providing support for different languages and cultures without having to change the source code of an applet or application by calling generalized methods that load data translated into the correct language.

Internet InterORB Protocol (IIOP)

The OMG-specified network protocol for communicating between ORBs. Java IDL conforms to IIOP Version 1.0.

JAR file

The Java archive file format. Multiple files are collected together into one file. The resulting JAR file is additionally compressed, and can be signed using digital signatures. JAR files may be accessed using the ARCHIVES parameter of the HTML <applet> tag, or directly by applets, applications, and operating system tools. The JAR format is compatible with the ZIP format.

JavaBean

A reusable software component written in the Java programming language that can be manipulated using a visual builder tool.

Glossary Glossary-3

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

A set of APIs that is used to build the component model for Java applications.

JavaIDL API

A set of classes and interfaces that are used to define remote object interfaces using the CORBA IDL standard. JavaIDL maps to a set of stubs and skeletons that can be used in a CORBA implementation.

JavaScript

A scripting language from Netscape that is embedded directly into Web pages. It is used to add interactivity and validation checking to Web pages.

JDBC

JDBC is an API used by Java applications to access databases using the SQL standard syntax.

JDK

The Java Development Kit, which can be downloaded from the JavaSoft Web site and includes Java libraries (packages), compilers, utilities and debuggers used to develop Java source code.

JVM

A runtime environment for running Java applets and applications. A JVM is embedded in most Web browser products.

Key

A number that is used to encrypt or decrypt a message, or to sign or verify a message. Longer keys are generally more secure than shorter ones. See also Private Key and Public Key.

Localization (L10N)

A method used to translate a user interface into the language set of a specific region or country including local date formats and currencies.

Message digest

A function that generates a hash value (or digest) from a specified set of data. The hash value is unique to the data string. The digest can be used to verify that the data has not been altered since it was sent over the network.

MVC

Model-View-Controller (MVC) is a framework for modeling and designing GUIs in object-oriented programs such as Smalltalk.

Glossary-4

Java Technology Architecture Planning and Design

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

Self-contained software packages consisting of private information (data), private operations (methods) that manipulate private data, and a public interface (methods) that provides a means of communicating with the object. Objects interact by passing messages to each other.

Object method

Code that is executed in response to a message being sent to the object. There are two types of object methods: interface methods that allow communication with the object; and internal methods which are not accessible from outside of the object.

Object modeling

A method for modeling the way that businesses operate in the real world. Objects add value over other ways of modeling by reducing complexity and abstracting to a higher-level perspective.

Object-oriented framework

An implementation of a set of abstract and concrete object classes that collaborate. The framework classes are generic, since they must be mapped to provides hooks for customization or extension. Frameworks enable re-use of object code, as well as object models.

Object reference

A way of identifying an object within an ORB. An object reference is used in method invocations to locate a CORBA object. Object references are the CORBA object equivalent to programming language-specific object pointers. Multiple object references can refer to the same CORBA object.

Object Request Broker (ORB)

Object-oriented middleware that enables objects to transparently locate and activate other objects on a network, regardless of the processor type or programming language. ORBs remove the network complexity from the developer.

Object wrappers

Non-object code can be “wrapped” and appear to be an object with object interfaces that can participate in a distributed object environment. The wrapper represents legacy code as well as a real object.

ODBC

Open Database Connectivity; a standard API from Microsoft that can

be used to access various SQL databases using a common API. ODBC drivers are supplied by database vendors and third-party software companies.

Glossary Glossary-5

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

Objects normally cease to exist once the process that created them ends. Any technique that allows objects to be stored between invocations of the programs that use them may be described as persistence.

Port number

A port number is used in TCP systems to identify the type of incoming request. By convention, TCP protocols such as FTP and HTTP use specific port numbers.

Private key

Keys are used for encryption and digital signatures (see Key). A private key is typically kept secret by an individual or organization. It may then be used to decrypt messages sent using the corresponding public key, or to sign messages for public distribution. A private key is always associated with a single public key. Note that sometimes the terms private key and public key are used in the opposite sense when discussing digital signatures. That is, the term private key is sometimes used to mean the key used for decryption; in digital signatures, this is the key that is given out freely.

Public key

See also Private Key. A public key is made freely available to everyone who needs to have trusted interactions with that entity. The key is used to encrypt messages that may then be decrypted only by the proper recipient (who holds the corresponding private key) or to verify a digital signature. Note also the warning about transposition of the terms public key and private key, mentioned under the entry Private key.

RMI API

Remote method invocation is an object interface that enables Java applets and applications to invoke methods that exist in remote Java applets and applications.

Screen scraper

A middleware product that uses terminal emulation to connect to a terminal-based application. Using that connection, data can be programmatically extracted from, or inserted into, fields in the terminal-based interface. This allows new front ends to be added to the terminal-based program. For example, a GUI is commonly provided in place of the old interface.

Glossary-6

Java Technology Architecture Planning and Design

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

Simple Mail Transfer Protocol; the Internet standard email protocol, used to communicate between mail systems and propagate mail from one system to another.

Socket

An API that enables two applications to engage in a bound session and exchange information over a network. Sockets are used by the HTTP server as well as by Java software code. Sockets are most commonly used on TCP/IP networks, but are sometimes found on other systems.

TCP

Transport Control Protocol; the upper part of the TCP/IP protocol stack. TCP is responsible for reliability, flow-control, and ordering of bidirectional data over the network.

TELNET

A program used to log in to a remote server.

Terminal emulation

A piece of software that provides a “green screen” on a client platform window of Web browser.

Thread

A lightweight execution context that uses less resources than a process.

Three-tier architecture

An evolution from client-server architecture, which separates the client user interface, application business logic, and database access, and assigns them to separate tiers.

XML

Extensible Markup language; a successor to HTML.

Glossary Glossary-7

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

réservés. Ce produit ou document est protégé par un copyright et distribué avec des licences qui en restreignent l’utilisation, la

copie, la distribution, et la décompilation. Aucune partie de ce produit ou document ne peut être reproduite sous aucune forme, par quelque moyen que ce soit, sans l’autorisation préalable et écrite de Sun et de ses bailleurs de licence, s’il y en a.

Le logiciel détenu par des tiers, et qui comprend la technologie relative aux polices de caractères, est protégé par un copyright et licencié par des fournisseurs de Sun.

Des parties de ce produit pourront être dérivées du systèmes Berkeley 4.3 BSD licenciés par l’Université de Californie. UNIX est une marque déposée aux Etats-Unis et dans d’autres pays et licenciée exclusivement par X/Open Company Ltd.

Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaSoft, JavaBeans, Enterprise JavaBeans, JDBC, SunTea, 100% Pure Java, JavaHelp, SunLink, JDK, JavaStation, JavaStar, JavaScope, JavaSpec, JavaScript, Java HotSpot, Java Workshop, JavaOS, Java Naming and Directory Interface, Solstice Sunscreen, et NFS sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et dans d’autres pays.

Toutes les marques SPARC sont utilisées sous licence sont des marques de fabrique ou des marques déposées de SPARC International, Inc. aux Etats-Unis et dans d’autres pays.

Les produits portant les marques SPARC sont basés sur une architecture développée par Sun Microsystems, Inc. Netscape Navigator est une marque de Netscape Communications Corporation.

L’interfaces d’utilisation graphique OPEN LOOK et Sun™ a été développée par Sun Microsystems, Inc. pour ses utilisateurs et licenciés. Sun reconnaît les efforts de pionniers de Xerox pour larecherche et le développement du concept des interfaces d’utilisation visuelle ou graphique pour l’industrie de l’informatique. Sun détient une licence non exclusive

de Xerox sur l’interface d’utilisation graphique Xerox, cette licence couvrant également les licenciés de Sun qui mettent en place l’interface d’utilisation graphique OPEN LOOK et qui en outre se conforment aux licences écrites de Sun.

L’accord du gouvernement américain est requis avant l’exportation du produit. Le système X Window est un produit de X Consortium, Inc. LA DOCUMENTATION EST FOURNIE “EN L’ETAT” ET TOUTES AUTRES CONDITIONS, DECLARATIONS ET

GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES, DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L’APTITUDE A UNE UTILISATION PARTICULIERE OU A L’ABSENCE DE CONTREFAÇON.

Please Recycle