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