OCMJEA

Authentication
Authentication is the process of confirming the identity of a party with whom one is communicating.

Cipher Suite
A cipher suite is a combination of cryptographic parameters that define the security algorithms and key sizes used for authentication, key agreement, encryption, and integrity protection.

Certificate
A certificate is a digitally signed statement vouching for the identity and public key of an entity (person, company, etc.). Certificates can either be self-signed or issued by a Certification Authority (CA). Certification Authorities are entities that are trusted to issue valid certificates for other entities. Well-known CAs include VeriSign, Entrust, and GTE CyberTrust. X509 is a common certificate format, and they can be managed by the JDK’s keytool.

Cryptographic Hash Function
A cryptographic hash function is similar to a checksum. Data is processed with an algorithm that produces a relatively small string of bits called a hash. A cryptographic hash function has three primary characteristics: it is a one-way function, meaning that it is not possible to produce the original data from the hash; a small change in the original data produces a large change in the resulting hash; and it does not require a cryptographic key.

Cryptographic Service Provider
In the JCA, implementations for various cryptographic algorithms are provided by cryptographic service providers, or “providers” for short. Providers are essentially packages that implement one or more engine classes for specific algorithms. An engine class defines a cryptographic service in an abstract fashion without a concrete implementation.

Digital Signature
A digital signature is the digital equivalent of a handwritten signature. It is used to ensure that data transmitted over a network was sent by whoever claims to have sent it and that the data has not been modified in transit. For example, an RSA-based digital signature is calculated by first computing a cryptographic hash of the data and then encrypting the hash with the sender’s private key.

Encryption and Decryption
Encryption is the process of using a complex algorithm to convert an original message, or cleartext, to an encoded message, called ciphertext, that is unintelligible unless it is decrypted. Decryption is the inverse process of producing cleartext from ciphertext. The algorithms used to encrypt and decrypt data typically come in two categories: secret key (symmetric) cryptography and public key (asymmetric) cryptography.

Handshake Protocol
The negotiation phase during which the two socket peers agree to use a new or existing session. The handshake protocol is a series of messages exchanged over the record protocol. At the end of the handshake new connection-specific encryption and integrity protection keys are generated based on the key agreement secrets in the session.

Key Agreement
Key agreement is a method by which two parties cooperate to establish a common key. Each side generates some data which is exchanged. These two pieces of data are then combined to generate a key. Only those holding the proper private initialization data will be able to obtain the final key. Diffie-Hellman (DH) is the most common example of a key agreement algorithm.

Key Exchange
One side generates a symmetric key and encrypts it using the peer’s public key (typcially RSA). The data is then transmitted to the peer, who then decrypts the key using its corresponding private key.

Key Managers and Trust Managers
Key managers and trust managers use keystores for their key material. A key manager manages a keystore and supplies public keys to others as needed, e.g., for use in authenticating the user to others. A trust manager makes decisions about who to trust based on information in the truststore it manages.

Keystores and Truststores
A keystore is a database of key material. Key material is used for a variety of purposes, including authentication and data integrity. There are various types of keystores available, including “PKCS12″ and Sun’s “JKS.”

Generally speaking, keystore information can be grouped into two different categories: key entries and trusted certificate entries. A key entry consists of an entity’s identity and its private key, and can be used for a variety of cryptographic purposes. In contrast, a trusted certificate entry only contains a public key in addition to the entity’s identity. Thus, a trusted certificate entry can not be used where a private key is required, such as in a javax.net.ssl.KeyManager. In the JDK implementation of “JKS”, a keystore may contain both key entries and trusted certificate entries.

A truststore is a keystore which is used when making decisions about what to trust. If you receive some data from an entity that you already trust, and if you can verify that the entity is the one it claims to be, then you can assume that the data really came from that entity.

An entry should only be added to a truststore if the user makes a decision to trust that entity. By either generating a keypair or by importing a certificate, the user has given trust to that entry, and thus any entry in the keystore is considered a trusted entry.

It may be useful to have two different keystore files: one containing just your key entries, and the other containing your trusted certificate entries, including Certification Authority (CA) certificates. The former contains private information, while the latter does not. Using two different files instead of a single keystore file provides for a cleaner separation of the logical distinction between your own certificates (and corresponding private keys) and others’ certificates. You could provide more protection for your private keys if you store them in a keystore with restricted access, while providing the trusted certificates in a more publicly accessible keystore if needed.

Message Authentication Code
A Message Authentication Code (MAC) provides a way to check the integrity of information transmitted over or stored in an unreliable medium, based on a secret key. Typically, MACs are used between two parties that share a secret key in order to validate information transmitted between these parties.
A MAC mechanism that is based on cryptographic hash functions is referred to as HMAC. HMAC can be used with any cryptographic hash function, such as Message Digest 5 (MD5) and Secure Hash Algorithm (SHA), in combination with a secret shared key. HMAC is specified in RFC 2104.

Public Key Cryptography
Public key cryptography uses an encryption algorithm in which two keys are produced. One key is made public while the other is kept private. The public key and the private key are cryptographic inverses; what one key encrypts only the other key can decrypt. Public key cryptography is also called asymmetric cryptography.

Record Protocol
The record protocol packages all data whether application-level or as part of the handshake process into discrete records of data much like a TCP stream socket converts an application byte stream into network packets. The individual records are then protected by the current encryption and integrity protection keys.

Secret Key Cryptography
Secret key cryptography uses an encryption algorithm in which the same key is used both to encrypt and decrypt the data. Secret key cryptography is also called symmetric cryptography.

Session
A session is a named collection of state information including authenticated peer identity, cipher suite, and key agreement secrets which are negotiated through a secure socket handshake and which can be shared among multiple secure socket instances.

Java 2 Security

In JDK 1.1, any downloaded code, such as applets, was considered untrusted and consequently run in a restricted sandbox, whereas local applications and signed applets were given full access to the system resources. The Java 2 security model changes this coarse-grained approach to a fine-grained, policy-driven approach. When code is loaded, a policy file is read, and the allowed permissions are granted to the code. The permissions can be anything from read or write access to a directory to connect permission to a host computer. Code can access the resource only if it has been granted the required permissions for accessing that resource. Permission classes are extensible, so custom permissions and properly configured policy files provide the required granularity of security.

Applets are Java programs that run inside the Web browser. They are typically embedded in a Web page to add dynamic behavior. Applets are loaded with a restrictive policy file. The most important restrictions are:

• Making network connections to arbitrary hosts other than the originating host.
• Reading/writing on the client file system.
• Starting other programs on the client.
• Loading native libraries.
• Defining native methods.
• Any operation that could be detrimental to the client system. (This excludes attacks such as excessive usage of CPU, memory, and network resources, as they can be handled at the OS level.)

It is important to know that these restrictions do not apply to applets loaded from the local file system whose classes are present in the client’s CLASSPATH.

Security Fundamentals

Following are some of the fundamental terminologies you must be familiar with when dealing with security issues:

• Principal
  Any identifiable person, role, or a system.
• Authentication
  The means by which communicating entities prove to one another that they are acting on behalf of specific identities authorized for access (that is, the process by which a user or a system is identified by the other party). For example, a customer logs in to a bank’s Web site using his or her login and password. This combination of user name and password identifies the user to the system.
• Authorization
  The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints. For example, a manager can see all the employee details, whereas employees can only see their details.
• Data integrity
  The means used to prove that information has not been modified by a third party while in transit. For example, if you send a file and its checksum separately, the receiving party can compute the file’s checksum and match it with the received checksum to ensure the file’s contents were not tampered with along the way.
• Confidentiality (data privacy)
  The means used to ensure that information is made available only to the users who are authorized to access it. For example, you can encrypt the data and send. The receiver who has the decrypting key alone would be able to read the data.

Cryptography

Cryptography is the practice and study of encryption and decryption — encoding data so it can only be decoded by intended recipients and rendered unreadable for others. There are two forms of encryption:

• Symmetric
• Asymmetric

Symmetric

Both sender and recipient know a common key used to encrypt and decrypt messages. Because the keys are same for both encrypting and decrypting, it is known as symmetric encryption.

One benefit of this method is:

• Requires significantly less resources in terms of CPU cycles to encrypt and decrypt the data.

A disadvantage of this method is:

• Both the sender and receiver must share the key in a secure way. If it is leaked to a third party, the entire mechanism becomes futile.

Asymmetric

Two different but related keys are used in such a way that one key, called a private key, is kept as a secret, while the other public key is available to anyone. The two fundamental principles that drive this method are:

• One key cannot be deduced from the other.
• Messages encrypted with one key can only be decrypted by the other and vice versa.

One advantage of this method is:

• Completely eliminates the need to securely share the keys, as a sender can use the recipient’s public key to encrypt the message, which can be read only by the recipient using his or her secure private key.

One downside of this method is:

• It is computationally expensive.

In reality, you can use both forms of encryption in combination for enhanced security and efficient use. You can use symmetric encryption to encrypt the message, thereby reducing the computational cost involved in decrypting; the shared key (which would be small compared to the data) is encrypted using the asymmetric encryption, eliminating the necessity to transfer the keys securely.

Network topologies for implementing security

The layout of the network has a strong correlation with the security of the network. Multiple entry points to the network without proper access control mechanisms are a boon for intruders looking to penetrate corporate networks. For enhanced security, the entry points into the network have to be restricted and must be guarded by well-configured firewalls. Once the topology is set, there must be constant monitoring of the firewall, server, and other network equipment log files to uncover any malicious activities, such as unauthorized intrusions, in a timely manner.

Simple firewall

This is a simple model in which the internal network and the external network are separated by a firewall.

Two firewalls and DMZ

You use this model when you must offer a significant amount of services to the external network. You place the externally accessible servers in a demilitarized zone (DMZ) surrounded by firewalls on either side of the network. You configure the inner firewall more restrictively than the other firewall. Any communication from the external network to the internal network happens only through the servers deployed in the DMZ.

Tunneling

The firewall setup does not generally allow every protocol to communicate through it. Opening up numerous ports can result in an extremely vulnerable firewall. So, administrators generally allow only well-defined protocols, such as HTTP and HTTPS.

You can use tunneling to access an external service that is not allowed by the firewall by piggy-backing the requests onto a protocol that is allowed by the firewall (for example, using HTTP as a covert channel for invoking Web services).

Similarly, external networks can tunnel into an internal network. But this is not good practice as it allows anyone with malicious intentions to bypass the firewall rules.

Common Architectures

• Load Balancing Web Applications
• JEE clustering Part1
• JEE clustering Part2
• Client server computing

Design Patterns

• Enterprise Java Patterns
• J2EE Patterns
• Design Patterns for Optimizing the Performance of J2EE Applications

Security

• Java SE Security
• Java Security Evolution and Concepts
• Security Inside the Java Virtual Machine
• How firewalls work?
• What you need to know before setting up a firewall?

Introduction

A message is a unit of serializable data exchanged between two or more distributed components running in the same machine or different machine. By using a message-oriented middleware (MOM) infrastructure, an application can create, send, and receive messages. This lets you combine separate business components into a reliable, yet flexible system. Several vendors provide MOM, and in J2EE, Java Messaging Service (JMS) offers a generic way to access these systems. In this section, let’s explore the different messaging modes and models and learn how to choose the correct one for a given scenario.

Communication modes

There are two modes of communication depending on the level of coupling between the sender and receiver:

• Synchronous
• Asynchronous

Synchronous

A distributed component sends a message to another active component and waits for the reply (also known as blocking call) to proceed further. The synchronous communication is tightly coupled because both the sender and receiver have knowledge about each other. The sender is responsible for retries in case of failures.

The benefits of synchronous communication are:

• This mode is fail-safe and is used for transaction processing.
• Sender can receive the response immediately in realtime.
• When multiple messages are sent, they reach the destination in the same order in which they are sent.
• It is a reliable communication mode.

You can use this mode when the sender:

• Wants to have more control over the message.
• Needs real-time response.
• Wants to maintain the order of message processing.
• Wants to retry in case of message failure.

Asynchronous

A distributed component can send messages to any other component via MOM and continue its processes without waiting for the response. This communication mechanism is loosely coupled, where sender and receiver need not have knowledge about each other because a central intermediary, the MOM, exists. Messages can arrive at the destination in any sequence and not necessarily in same order in which they are sent. MOM is responsible for retry in case of failure in the communication.

The benefits of asynchronous communication are:

• Sender need not wait till the message gets processed. The responsibility is delegated to the MOM.
• Messages can be queued. Sender and receiver need not be always available to receive the messages.
• It is loosely coupled because the sender and receiver do not directly communicate; they communicate through MOM.

You can use this mode when the sender:

• Wants to broadcast the message.
• Needs no response, or the response is not needed immediately.
• Wants to use the system hardware efficiently.
• Wants to do transaction processing in high volume.

Messaging models

There are two types of messaging models depending on whether you require one-to-one message delivery or a one-to-many broadcast delivery. The models are:

• Point-to-point messaging. In this model, the sender sends the messages to a destination known as queue, and the receiver consumes the message from the queue. A queue is designated to only one receiver. More than one sender can send the messages to a queue, but only one consumer receives that message from the queue. The messages in the queue are processed on a first-in-first-out (FIFO) basis. The messages stay in the queue until they are consumed by the consumer or until the messages’ expiry time. A sender can also send the message directly to the consumer instead of placing it in the queue. A consumer can acknowledge the successful processing of the message.
• Publish-subscribe messaging. In this model, publishers publish the messages to a topic. The subscribers who subscribe to that topic then receive the message. The message stays in the topic until it is sent to the active subscribers. If some subscribers are not active, the messages are not delivered to them. There is a special type of subscription known as a durable subscription in which the messages will not be lost if the subscriber is not active. Rather, the messages are delivered once the subscriber becomes active.

Technology and scenarios

The following table summarizes the technologies you can use for different scenarios.

HTTP
Client-Server Architecture The HTTP protocol is based on a request/response paradigm. The communication generally takes place over a TCP/IP connection on the Internet. The default port
is 80, but other ports can be used. This does not preclude the HTTP/1.0 protocol from being implemented on top of any other protocol on the Internet, so long
as reliability can be guaranteed.
The HTTP protocol is connectionless and stateless After the server has responded to the client’s request, the connection between client and server is dropped
and forgotten. There is no “memory” between client connections. The pure HTTP server implementation treats every request as if it was brand-new, i.e. without
context.
An extensible and open representation for data types HTTP uses Internet Media Types (formerly referred to as MIME Content-Types) to provide open and
extensible data typing and type negotiation. When the HTTP Server transmits information back to the client, it includes a MIME-like (Multipart Internet Mail
Extension) header to inform the client what kind of data follows the header. Translation then depends on the client possessing the appropriate utility (image
viewer, movie player, etc.) corresponding to that data type.

HTTPS(Secure Hypertext Transfer Protocol)
HTTPS (Secure Hypertext Transfer Protocol) is a Web protocol developed by Netscape and built into its browser that encrypts and decrypts user page requests
as well as the pages that are returned by the Web server. HTTPS is really just the use of Netscape’s Secure Socket Layer (SSL) as a sublayer under its
regular HTTP application layer. (HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP.) SSL uses a 40 or 128-bit key
size for the RC4 stream encryption algorithm, which is considered an adequate degree of encryption for commercial exchange.
Suppose you use a Netscape browser to visit a Web site such as NetPlaza (http://www.netplaza.com/) and view their catalog. When you’re ready to order, you
will be given a Web page order form with a URL that starts with https://. When you click “Send,” to send the page back to the catalog retailer, your
browser’s HTTPS layer will encrypt it. The acknowledgement you receive from the server will also travel in encrypted form, arrive with an https:// URL, and
be decrypted for you by your browser’s HTTPS sublayer.
HTTPS and SSL support the use of X.509 digital certificates from the server so that, if necessary, a user can authenticate the sender. SSL is an open,
nonproprietary protocol that Netscape has proposed as a standard to the World Wide Consortium (W3C). HTTPS is not to be confused with SHTTP, a security-
enhanced version of HTTP developed and proposed as a standard by EIT.
Resource:Whatis.com/https.htm

IIOP
CORBA and IIOP assume the client/server model of computing in which a client program always makes requests and a server program waits to receive requests
from clients. When writing a program, you use an interface called the General Inter-ORB Protocol (GIOP). The GIOP is implemented in specialized mappings for
one or more network transport layers. Undoubtedly, the most important specialized mapping of GIOP is IIOP, which passes requests or receives replies through
the Internet’s transport layer using the Transmission Control Protocol (TCP). Other possible transport layers would include IBM’s Systems Network
Architecture (SNA) and Novell’s IPX.
For a client to make a request of a program somewhere in a network, it must have an address for the program. This address is known as the Interoperable
Object Reference (IOR). Using IIOP, part of the address is based on the server’s port number and Internet Protocol (IP) address. In the client’s computer, a
table can be created to map IORs to proxy names that are easier to use. The GIOP lets the program make a connection with an IOR and then send requests to it
(and lets servers send replies). A Common Data Representation (CDR) provides a way to encode and decode data so that it can be exchanged in a standard way.
CORBA is not the only architecture that uses IIOP. Because a TCP/IP-based proxy is usable on almost any machine that runs today, more parties now use IIOP.
When another architecture is IIOP-compliant, it not only establishes a well-proven communication transport for its use, but it also can communicate with any
ORB implementation that is IIOP-compliant. The possibilities are endless.
reference: http://www.blackmagic.com/people/gabe/iiop.html

JRMP
The Transport layer employs JRMP, also known as the RMI Wire Protocol, to send method invocations and associated parameters and to return values and
exceptions from one Java virtual machine (JVM) to another. JRMP is a simple protocol consisting of five messages, plus an extra five for multiplexing flow
control.
All JRMP sessions consist of a header followed by one or more messages. The header contains just the ASCII codes for the characters JRMI , the protocol
version, and the “subprotocol” to be used. There are three subprotocols: SingleOpProtocol, StreamProtocol, and MultiplexProtocol. SingleOpProtocol signifies
that only one message follows a header before the end of a session (i.e., the connection closes). StreamProtocol and MultiplexProtocol can transfer one or
more messages. The latter is used when multiplexing calls from both client and server on a single socket, as described below.
Communicating clients and servers typically each open a socket to the other (i.e., both systems connect and listen for connections). The client’s socket
typically invokes methods on server-side objects, and the server’s socket calls client-side objects (e.g., callbacks). The figure shows a hypothetical
StreamProtocol situation. The client sends the Call message to invoke a server object’s method; the server then invokes this method and replies with a Return
containing any results. Assuming that a remote object is returned, the client then sends a DgcAck message to let the server’s garbage collector know that it
has received the remote object. On another socket, the server sends a Ping to find out whether the client is alive, which replies with a PingAck.
Default applet security restrictions deny applets the right to open sockets back to any server other than their originating host; they also block any attempt
to listen for socket connections. This being the case, how do clients listen for server connections?
Enter the MultiplexProtocol and its group of five messages: Open , Close , CloseAck , Request, and Transmit. They allow client and server to simulate the
StreamProtocol’s two-way communication using a single socket. In the current implementation, up to 256 virtual connections can be opened, each identified by
a unique ID.
Unfortunately, connecting via a socket back to the server is not always possible for applets running behind firewalls (e.g., on a corporate intranet), which
typically block any attempt to open a socket back to the Internet. Should it fail to open a connection, an RMI client wraps its method invocation inside the
body of an HTTP request (which is the protocol browsers use to communicate with Web servers), and the RMI server sends any results as an HTTP response.
This workaround is a smart solution, since HTTP is a firewall-trusted protocol. Still, performance takes a hit due to the time needed to convert messages to
HTTP requests. In addition, no multiplexing of invocations can be accomplished, because keeping the connection open between client and server is not part of
HTTP 1.0. The primary reason for SingleOpProtocol’s existence is to encapsulate RMI through HTTP.
Reference: http://www.byte.com/art/9802/sec4/art3.htm

RMI
RMI This is a possible if the objects in the user interface and the business layers are all Java objects. The persistence layer is mostly
accessed through JDBC. Other relational object mapping of the data layer is also possible. Advantage of RMI Object are passed by value. The server/ client
can reconstitute the objects easily. Data type can be any Java objects. Any Java objects can be passed as arguments. Arguments has to implement the
serializable interface Disadvantage of RMI Heterogeneous objects are not supported. Corba If the objects in the client layer and the business layer are
heterogeneous, i.e. the objects are implemented in C, C++ Java, Smalltalk then Corba is most suitable. Advantage of Corba Heterogeneous objects are
supported. Disadvantage of Corba Objects are not passed by value, only the argument data is passed. The server/ client has to reconstitute the objects with
the data. Only commonly accepted data types can be passed as arguments. Dcom This works best in windows environment. Distributed Object Communication Advantages Disadvantages HTTP Simple, Established Has to communicate to a Servlet, Java Server pages Cannot communicate to a Java class directly RMI Object are passed by value. The server/ client can reconstitute the objects easily. Object are passed by reference Data type can be any Java objects. Any
Java objects can be passed as arguments. Arguments has to implement the Serializable interface Heterogeneous objects are not supported. Corba Heterogeneous objects are supported. Objects are not passed by value, only the argument data is passed. The server/ client has to reconstitute the
objects with the data. Only commonly accepted data types can be passed as arguments Dcom If windows is the deployment platform suits well with the operating system This works in windows environment at best Distributed Object Frameworks Distributed Object Frameworks are RMI, Corba, Dcom, EJB. Basic Three-Tier Java Technology Architecture The three-Tier Java
Technology Architectureis achieved by HTML, Applet, Java Application on the client. Servlet, Java Server Pages on the Middle Tier. JDBC communication to the
persistence or Database layer Client C to M comm. Middle M to P comm. Persistence HTML HTML with applet HTTP Servlet Java Server Pages JDBC RDBMS Legacy File Java Application JRMP RMI Server JDBC RDBMS Legacy File Java Application RMI- II0P EJB JDBC RDBMS Legacy File Java Application ( Not a Java 3 tier) IIOP Corba JDBC RDBMS Legacy File

Conclusion

HTTP and HTTPS are very similar protocols with only the fact that HTTPS provides a layer of security(the SSL). They are both capable of passing a variety of
data types but there is no logic, objects may only be executed if there’s another protocol to handle them. HTTP is the lowest layer of logic and can only be
used as a delivery mechanism for other protocols. JRMP is a robust object server that communicates well when working with JAVA based objects. It is capable
of passing objects refrences rather than just values that have to be reconstituted so that the object may be executed by the client rather than the server.
In the even that the server is secure or cannot communicate in the most efficient manner JRMP falls back to HTTP. JRMP is only capable of passing JAVA
objects. IIOP is the most flexible of the transport mechanisms, it can communicate objects created in C, C++, JAVA, and smalltalk but only passes data by
value requiring the server to do all the work and requiring that only common data types be passed as arguments making it more restrictive than JRMP which
allows any JAVA data type.

Default Port numbers for the above protocols:
Http : 80, 8080
HTTPS,SSL: 443, 8443
JRMP: 1099
LDAP: 389
LDAP Over SSL – IIOP: 636

A system architecture should address both functional (business) requirements and nonfunctional (service-level) requirements. During the initial phases, an architect has to define the quality of service measurement for each of the service-level requirements. Normally, there is a trade-off between these requirements. For example, to achieve better extensibility, an architect might introduce a modular architecture with many objects, thereby increasing the memory requirements, which impacts the performance. The service-level requirements of prime importance are:

• Scalability
• Maintainability
• Reliability
• Availability
• Extensibility
• Performance
• Manageability
• Security

Scalability

Scalability is the ability to accommodate more users with the required quality of service as the transactional load increases. A scalable system responds within acceptable limits even when there is an increased load. To scale a system that has met capacity, you can add hardware vertically or horizontally, thus leading to the following two types of scaling:

• Vertical scaling
  Vertical scaling is achieved by adding capacity (memory, CPUs, etc.) to existing servers. This requires only a few or no changes to the system’s architecture. This type of scaling helps in increasing the capacity to serve more clients and requires less management of the resources. This type of scaling is comparatively easier and cheaper than horizontal scaling.

• Horizontal scaling
  Horizontal scaling is achieved by adding servers to the system. This increases the server’s reliability, availability, and flexibility. Depending on the load-balancing algorithm, it sometimes also increases the performance. But horizontal scaling increases the complexity of the system architecture resulting in a decrease in manageability.J2EE architecture supports horizontal and vertical scaling. In horizontal scaling, the server can manage more components. In vertical scaling, with the help of load balancing and clustering, more clients can be served.

Maintainability

Maintainability is the ability to correct flaws in the existing functionality without impacting any other components. To enhance the maintainability, the system design should be modular, and proper documents should be present for the system. This requirement cannot be measured during the deployment of the system.

Reliability

Reliability is the ability to ensure the integrity and consistency of the application and all of its transactions. You can increase reliability through the use of horizontal scalability, such as by adding more servers. The increase in reliability also increases the availability.

Availability

Availability is about assuring that services are available to the required number of users for the required proportion of time. The term 24×7 refers to the total availability. You can achieve total availability through a fault-tolerance mechanism such as replication. There are two types of replication, active and passive.

Extensibility

Extensibility is the ability to modify or add functionality without impacting the existing functionality. The key to an extensible design is to create an effective object-oriented (OO) design with low coupling, interfaces, and encapsulation. J2EE supports extensibility because it is component-based and allows you to separate an application’s roles.

Performance

Performance is usually measured in throughput. Throughput is a system’s response time. You can also determine performance using the number of transactions per unit time. By using load balancing and load distribution, you can increase the system’s performance.

DNS Round Robin is a load-distribution algorithm, in which the first request is served by the first server and the subsequent requests are served by the subsequent servers. If there are five servers, then the sixth request is served by the first server. In load balancing, the request is served by the server with the lesser load.

You can also increase performance with efficient programming. For example, minimizing the number of network calls in the distributed application results in performance gains. Resource pooling and caching are also other ways of increasing performance.

Manageability

Manageability refers to the ability to monitor the system resources to ensure continued health of the system. A manageable system lets you dynamically configure the system without actually changing it.

Distributed applications are more complex to manage compared to monolithic applications, but distributed applications are more scalable, reliable, and available. So, it’s a trade-off between manageability and other service-level requirements.

Security

Security ensures that information is not accessed, modified, or disclosed except in accordance with the security policy. A highly secure system is more costly and also harder to define and develop. The easier way to secure an application is by creating an architecture with separate functional components and applying security zones so that attacks are localized and impact is minimized, if they occur.

Security attacks generally try to compromise confidentiality and integrity of the system. Sometimes, they also take the form of denial of service (DoS) attacks that bring down a system by flooding it with messages. You can address security by using technologies such as firewalls, demilitarized zone (DMZ), data encryption, and digital certificates and methodologies such as good security policies and procedures.

Section 1: Application Design Concepts and Principles

• Explain the main advantages of an object-oriented approach to system design including the effect of encapsulation, inheritance, and use of interfaces on architectural characteristics.
• Describe how the principle of “separation of concerns” has been applied to the main system tiers of a Java Platform, Enterprise Edition application. Tiers include client (both GUI and web), web (web container), business (EJB container), integration, and resource tiers.
• Describe how the principle of “separation of concerns” has been applied to the layers of a Java EE application. Layers include application, virtual platform (component APIs), application infrastructure (containers), enterprise services (operating system and virtualization), compute and storage, and the networking infrastructure layers.

Section 2: Common Architectures

• Explain the advantages and disadvantages of two-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
• Explain the advantages and disadvantages of three-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security
• Explain the advantages and disadvantages of multi-tier architectures when examined under the following topics: scalability, maintainability, reliability, availability, extensibility, performance, manageability, and security.
• Explain the benefits and drawbacks of rich clients and browser-based clients as deployed in a typical Java EE application.
• Explain appropriate and inappropriate uses for web services in the Java EE platform

Section 3: Integration and Messaging

• Explain possible approaches for communicating with an external system from a Java EE technology-based system given an outline description of those systems and outline the benefits and drawbacks of each approach.
• Explain typical uses of web services and XML over HTTP as mechanisms to integrate distinct software components.
• Explain how JCA and JMS are used to integrate distinct software components as part of an overall Java EE application.

Section 4: Business Tier Technologies

• Explain and contrast uses for entity beans, entity classes, stateful and stateless session beans, and message-driven beans, and understand the advantages and disadvantages of each type.
• Explain and contrast the following persistence strategies: container-managed persistence (CMP) BMP, JDO, JPA, ORM and using DAOs (Data Access Objects) and direct JDBC technology-based persistence under the following headings: ease of development, performance, scalability, extensibility, and security.
• Explain how Java EE supports the deployment of server-side components implemented as web services and the advantages and disadvantages of adopting such an approach.
• Explain the benefits of the EJB 3 development model over previous EJB generations for ease of development including how the EJB container simplifies EJB development.

Section 5: Web Tier Technologies

• State the benefits and drawbacks of adopting a web framework in designing a Java EE application
• Explain standard uses for JSP pages and servlets in a typical Java EE application.
• Explain standard uses for JavaServer Faces components in a typical Java EE application.
• Given a system requirements definition, explain and justify your rationale for choosing a web-centric or EJB-centric implementation to solve the requirements. Web-centric means that you are providing a solution that does not use EJB components. EJB-centric solution will require an application server that supports EJB components.

Section 6: Applicability of Java EE Technology

• Given a specified business problem, design a modular solution that solves the problem using Java EE.
• Explain how the Java EE platform enables service oriented architecture (SOA) -based applications.
• Explain how you would design a Java EE application to repeatedly measure critical non-functional requirements and outline a standard process with specific strategies to refactor that application to improve on the results of the measurements.

Section 7: Patterns

• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition and named using the names given in that book.
• From a list, select the most appropriate pattern for a given scenario. Patterns are limited to those documented in the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software and are named using the names given in that book.
• From a list, select the benefits and drawbacks of a pattern drawn from the book – Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software.
• From a list, select the benefits and drawbacks of a specified Core J2EE pattern drawn from the book – Alur, Crupi and Malks (2003). Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition.

Section 8: Security

• Explain the client-side security model for the Java SE environment, including the Web Start and applet deployment modes.
• Given an architectural system specification, select appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features
• Identify and classify potential threats to a system and describe how a given architecture will address the threats.
• Describe the commonly used declarative and programmatic methods used to secure applications built on the Java EE platform, for example use of deployment descriptors and JAAS.