• Does it appear that the application may be quite volatile?

Application maintenance is made more manageable in Java.
(see about reduced client administration when using applets)

• Does the customer already have some in-house object oriented development skills?

If not, obviously need to recommend some training.
 
• Is platform independence a big issue for the customer?

If the customer has a large pool of developers skilled in Visual Basic, and the application is not going to be Internet / intranet / extranet deployed, then perhaps Java is not what the customer needs.  Take another look at what the customer is trying to achieve and whether the customer is really ready for object technology.

The study of software architecture concerns itself with achieving non-functional qualities (portability, scalability, performance, modifiability, integrability, etc.) in large systems.

Software architectural analysis, in particular, looks at how to analyze existing systems, or designed (but not yet built) systems, with a view to predicting its non-functional qualities. Achieving software quality through architecture level analysis
 

•  Establishing a process for architecture analysis and reviews.

This includes codifying current best practices in industry.

• Searching for, and empirically validating, the building blocks of design at the architectural level, and inking this to the achievement of non-functional qualities.

•  Devising a set of primitives with which to describe architectural mechanisms

(the things that we informally think of as components and connectors).

•  Adding tool support for architectural design and analysis.

Two tier software architecture
Two tier application  has two tier with
              Client tier providing user interface and business logic.
              Data tier providing the persistence.

The two tier design allocates the user system interface exclusively to the client. It places database management on the server and splits the processing management between client and server, creating two layers.
In general, the user system interface client invokes services from the database management server. In many two tier designs, most of the application portion of processing is in the client environment. The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures and triggers). Clients commonly communicate with the server through SQL statements. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.

Advantage of two tier architecture
Two tier application was advantageous in ease of development, user interface and security.

Disdvantage of two tier architecture
The disadvantage of the two tier application was  in the deployment phase.
Whenever the application logic changed the two tier application needed the application to be redistributed at each and every installed client computers.

Costs and Limitations

Scalability. The two tier design will scale-up to service 100 users on a network. It appears that beyond this number of users, the performance capacity is exceeded. This is because the client and server exchange "keep alive" messages continuously, even when no work is being done, thereby saturating the network
Implementing business logic in stored procedures can limit scalability because as more application logic is moved to the database management server, the need for processing power grows. Each client uses the server to execute some part of its application code, and this will ultimately reduce the number of users that can be accommodated.

Interoperability . The two tier architecture limits interoperability by using stored procedures to implement complex processing logic (such as managing distributed database integrity) because stored procedures are normally implemented using a commercial database management system's proprietary language. This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten. Moreover, database management system's proprietary languages are generally not as capable as standard programming languages in that they do not provide a robust programming environment with testing and debugging, version control, and library management capabilities.

System administration and configuration . Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client. The typical lack of uniformity in the client configurations and lack of control over subsequent configuration changes increase administrative workload.

Batch jobs . The two tiered architecture is not effective running batch programs. The client is typically tied up until the batch job finishes, even if the job executes on the server; thus, the batch job and client users are negatively affected
 

The three tier software architecture
        An architeture evolved in the 1990s to overcome the limitation of the deployment disadvantage of the two tier architecture. A middle tier was introduced inbetween the client tier and data tier. The middle tier providing mangement of process. The business logic resided in the middle tier. The middle tier provided scalability by distributing the business logic on various computers.The three tier architecture is used when an effective distributed client/server design is needed that provides increased performance, flexibility, maintainability, reusability, and scalability, while hiding the complexity of distributed processing from the user.
 
    By moving the business logic to the middle tier, client tier became thin client from a fat client. The client requested business logic services from the middle tier. This made easy to change the business logic in the middle tier without any redistribution of application to all installed client computers.

Isolation of concerns
The major advantage is that the front end clients are clearly separated from the back end data manipulation facilities. This allows details of the data storage mechanisms such as which database is used, record structure and field names to be abstracted away from the client processes. All the front end sees is an abstract operation request which takes input and output parameters.
        E nabling database migration
        D atabase restructuring, upgrades, migration or other changes can be performed without the
            necessity   to  stop or alter the client programs.
        F ront end modifications
        S imilarly, new front end clients can be introduced or old ones removed without any need to modify the
            databases or provide new access mechanisms.
        D ata from multiple sources

A client may require data from a number of servers. This can be handled easily because a Controller which  automatically splits the data operation request into several sub-operations. Each sub-operation is then performed by the appropriate data agent and the combined results forwarded to the calling client.

Application Architecture Design
// provide later
 

Applications, Servlets and CGI Scripts
 

What is a Servlet?
        A servlet is a web component, managed by a container, that generates dynamic content. Servlets are
small, platform independent Java classes compiled to an architecture neutral bytecode that can be
loaded dynamically into and run by a web server. Servlets interact with web clients via a request
response paradigm implemented by the servlet container. This request-response model is based on
the behavior of the Hypertext Transfer Protocol (HTTP).

What is a Servlet Container?
The servlet container, in conjunction with a web server or application server, provides the network services over which requests and responses are set, decodes MIME based requests, and formats MIME based responses. A servlet container also contains and manages servlets through their lifecycle.

A servlet container can either be built into a host web server or installed as an add-on component to a Web Server via that server’s native extension API. Servlet Containers can also be built into or possibly installed into web-enabled Application Servers.

All servlet containers must support HTTP as a protocol for requests and responses, but may also
support additional request / response based protocols such as HTTPS (HTTP over SSL). The
minimum required version of the HTTP specification that a container must implement is HTTP/1.0. It is strongly suggested that containers implement the HTTP/1.1 specification as well.
A Servlet Container may place security restrictions on the environment that a servlet executes in.

In a Java 2 Platform Standard Edition 1.2 (J2SE) or Java 2 Platform Enterprise Edition 1.2 (J2EE) environment, these restrictions should be placed using the permission architecture defined by Java 2 Platform. For example, high end application servers may limit certain action, such as the creation of a Thread object, to insure that other components of the container are not negatively impacted.

Java Servlets provide web developers with a simple, consistent mechanism for extending the functionality of a web server and for accessing existing business systems. A servlet can almost be thought of as an applet that runs on the server side -- without a face. Java Servlets have made many web applications possible.

Servlets are the Java platform technology of choice for extending and enhancing Web servers. Servlets provide a component-based, platform-independent method for building web-based applications, without the performance limitations of CGI programs. And unlike proprietary server extension mechanisms (such as the Netscape Server API or Apache modules), Servlets are server- and platform-independent. This leaves you free to select a "best of breed" strategy for your servers, platforms, and tools.

Written in Java, Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise databases. Servlets also access library of HTTP-specific calls, and all the benefits of the mature Java language, including portability, performance, reusability, and crash protection.

Today, Servlets are a popular choice for building interactive web applications. Third-party Servlet containers are available for Apache Web Server, iPlanet Web Server (formerly Netscape Enterprise Server), Microsoft IIS, and others. Servlet containers can also be integrated with web-enabled application servers, such as BEA WebLogic Application Server, IBM WebSphere, Netscape Application Server, and others.

You might want to check out the latest information on JavaServer Pages (JSP). JSP technology is an extension of the servlet technology created to support authoring of HTML and XML pages. It makes it easier to combine fixed or static template data with dynamic content. Even if you're comfortable writing servlets, there are several compelling reasons to investigate JSP technology as a complement to your existing work.
 
 
 

Comparing Servlets with Other Technologies
        In functionality, servlets lie somewhere between Common Gateway Interface (CGI) programs and proprietary server extensions such as the Netscape Server API (NSAPI) or Apache Modules.
Servlets have the following advantages over other server extension mechanisms:

• They are generally much faster than CGI scripts because a different process model is used.

• In CGI a process is started for every request Servlet is started only once.

• Since a CGI process is started for every request, you cannot maintain the state on the server.

            Think you need to add a sequence number to the client HTML saying " you accesses this page "12" ( xx) times.For this you may need to add a hidden column in the HTML and acesses it to increment and display the next time.Hence it is state less

• They use a standard API that is supported by many web servers.

• They have all the advantages of the Java programming language, including ease of development and

     platform independence.
 
• They can access the large set of APIs available for the Java platform.

• Servlets can handle requests in multithreading.

In servlets , they are in memory for 24 hours x 7 days a week, so you can have a variable to hold the poolable resources such as database connection or user information.
 
• Servlets use Java, hence ultimate use of Java API, Java security, threading, accessing EJB is possible.

• A servlet can interact with other resources (files, databases, applets,applications written in Java or in other languages) to construct the response that will be sent back to the client and, if needed, to save

information about the request-response interaction.
 
• With a servlet approach, the server can grant full access to local facilities, such as databases, and trust that the servlet itself will control the amount and precise nature of access that is effectively afforded to external users.

•  Servlets can be client programs of other services, for example, when they are used in distributed application systems.

•  It is possible to invoke servlets from a local or remote disk across the network.

•  Servlets can be chained. This means that one servlet can call another servlet, thus becoming its client. It can also call several servlets in sequence.

•  Servlets can be dynamically called from within HTML pages, using the special HTML <SERVLET> tag. This function is also known as servlet tag technique.

•  The Java Servlet API is protocol-independent. It does not assume anything about the protocol used to transmit it on the Internet. You can write a servlet without having to consider what the transmission protocol will be.

•  Like all Java programs, servlets can use all the capabilities of the object oriented Java language

• They can be rapidly developed.

• A servlet service routine is only a thread and not an entire operating system process. That is why a servlet can handle connections with multiple clients, accepting requests and downloading responses back to the

multiple   clients. This is a more efficient mechanism than using CGI-BINs.
 
• Servlets are portable. They run on a variety of servers without needing to be rewritten.

• Memory access violations are not possible, so faulty servlets will not crash servers.

• Finally, Java servlets must respect the security rules of the Java platform where they run.

Tier One Choices:  Applet, Application, HTML, HTML + JavaScript

The main performance hit in three-tier communication is the trip between tiers one and two (imagine a user in Australia using a browser to access an applet which is being downloaded from the UK, and the server application and database live on a LAN situated in the UK).  HTTP is slow.

For an Internet / intranet / extranet based application:
            Use an HTML form or forms only if trips between the client and server machines will be minimal and local validation of input is not required.  Use HTML forms + JavaScript if trips between the client and server machines will be minimal and some local validation of input is required.  If the system is required to cope with users operating in different locales, for example, then applets would be a good choice because they can use Resource Bundles.  Resource bundles are a feature of JDK1.1 so the applet must be run within a browser which supports JDK1.1 (Version 4 browsers).  The Version 4 browsers (i.e. Netscape 4.x and Internet Explorer 4.x do not consistently support the JDK1.1 event model, so the Java plug-in will be required to standardize the situation).  If the customer has no control over the types of browsers which users of the system will be accessing the system with, then use HTML or HTML + JavaScript (note:  HotJava does not support JavaScript).  The customer can really only control the browsers used by intranet users.

The advantage of deploying an application using applets is that the user automatically gets the latest version of the application because a new copy is downloaded each time (there are settings on browsers to change this policy).  This clearly reduces client-side administration drastically.  If applications are chosen for tier one then these must be kept up-to-date manually.  The advantage of using applications on tier one is that the applet security restrictions do not apply.  Applet security restrictions mean that untrusted applets cannot access local hard disk or local print services and may not connect to any machine other than that which it was downloaded from. Untrusted applets cannot obtain information about the client platform and they cannot load client libraries or DLLs.  The cannot run any programs or scripts on the client machine either.  All JDK1.0 applets are untrusted.  In JDK1.1 and JDK1.2 applets may be signed, and signed applets may access local hard disks and print services if the user chooses to trust them.  In JDK1.2 the concept of protection domains and policies is introduced, whereby the user can assign a degree of trust to a particular class or classes.

Tier Two Choices:  Servlet, Application

If HTML forms (with or without JavaScript) are employed in the first tier, these must communicate using HTTP to a Web server on the second tier. The Web server may communicate with non-Java code using, for example, CGI (Common Gateway Interface).  CGI requests are handled by creating a new process for each request, which takes up considerable server resources, and severely limits the number of requests which can be handled.

If applets are employed in the first tier, these are initially downloaded using HTTP and then may connect back to a servlet running within the Web server on tier two using RMI, or alternatively connect back to an application running on tier two using RMI.  Servlet requests are handled in separate threads rather than separate processes, and so use far less system resources than CGI requests.  Consequently the system can support many more servlet requests than CGI requests

Tier Three Choices:

The existence of legacy data often means there is no choice on this tier.  Java applications/servlets can interface to a RDBMS (Relational DataBase Management System) using JDBC (it is possible to obtain JDBC drivers for almost all RDBMSs from either the database vendor or from a third-party vendors if the database vendor cannot supply one).  Non-Java programs (e.g. CGI programs) access  RDBMSs using ODBC.

Object-oriented applications sitting on the third tier can be accessed using CORBA (read about Java IDL), and non object oriented applications sitting on the third tier can be accessed using sockets (if a published interface exists).

Obviously, a Java application sitting on the third tier can be accessed from the second tier using RMI if the second tier app is Java.

Map names to network objects like you would use a telephone directory. Naming services bind names to objects. A context is a se of name-to-binding objects. A naming service lookup results in the named object being retrieved based on its name. The process of using a name to look up a named resource is called name resolution. Names can be atomic (index.html), compound (/java/index.class) or composite (http://ww.k.com/java/bu.class).

Directory services build upon naming services. X.500, NDS and NIS are examples of Directory services of which NDS and NIS are proprietary. LDAP was created as a front end for X500 directory services but has replaced it on many servers. It is non-proprietary, runs over TCP/IP and is a manageable subset of X.500. version 3 is current. X.500 is for large directory services on WANs and LDAP is suited to large enterprises. X.500 requires the use of the higher-level OSI protocol layers;

LDAP works over TCP/IP JNDI is an API for developing naming and directory service clients that work with multiple naming and directory services such as LDAP and NIS+ JMAPI provides an integrated solution for system, network and service management of distributed systems. Java is suitable due to the heterogeneous state of distributed systems.
 

Communication Protocols in a Three-Tier Architecture

HTTP, RMI, IIOP, JDBC, JDBC – DBC    (See module 1 also)

The different methods of tier-to-tier communication are RMI (Remote Method Invocation), IIOP (Internet Inter-ORB Protocol), RPC (Remote Procedure Call) and Sockets.

RMI :  (Java app to Java app), runs over Java Remote Method Protocol (JRMP)
IIOP :  Internet Inter-ORB Protocol (Object-oriented app to object oriented app)(The protocol which CORBA runs over)
RPC : Procedure call to another program.
Sockets :  Transfer a stream of bytes between two programs (programs communicating using sockets obviously need to agree on some sort of protocol)

Both RMI and IIOP are object oriented: object call to method on another object.  With RMI the return values and parameters are objects.  With IIOP the return values and parameters are structures.  With RPC the return values and parameters are structures.  RMI and CORBA are usually implemented on top of RPCs or sockets.
 

There are different communication models between the tiers:

Asynchronous communication : Publish/subscribe model (based on events - like the JDK1.1 event model) Calling application just carries on processing after making a request.  An example of this is message queuing.  This model is not compromised by the network being temporarily unavailable.

Synchronous communication : Calling application waits for a response to its request before continuing.  This type of communication requires the network to be available.

Conversationalcommunication :  Calling application can either wait for a reply before continuing processing, or carry on without waiting.  This type of communication also requires the network to be available.
 
 

Remote Method Invocation (RMI)

Remote Method Invocation (RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. A Java technology-based program can make a call on a remote object once it obtains a reference to the remote object, either by looking up the remote object in the bootstrapnaming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server, and that server can also be a client of other remote objects. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object oriented polymorphism.
 

RMI applications are often comprised of two separate programs: a server and a client. A typical server application creates some remote objects, makes references to them accessible, and waits for clients to invoke methods on these remote objects. A typical client application gets a remote reference to one or more remote objects in the server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.

Distributed object applications need to
 

•  Locate remote objects: Applications can use one of two mechanisms to obtain references to remote objects. An application can register its remote objects with RMI's simple naming facility, the rmiregistry, or the application can pass and return remote object references as part of its normal operation.

• Communicate with remote objects: Details of communication between remote objects are handled by RMI; to the programmer, remote communication looks like a standard Java method invocation.

• Load class bytecodes for objects that are passed around: Because RMI allows a caller to pass objects to remote objects, RMI provides the necessary mechanisms for loading an object's code, as well as for transmitting its data.

( To add fig rmi later)
 
 

Advantages of Dynamic Code Loading

One of the central and unique features of RMI is its ability to download the bytecodes (or simply code) of an object's class if the class is not defined in the receiver's virtual machine. The types and the behavior of an object, previously available only in a single virtual machine, can be transmitted to another, possibly remote, virtual machine. RMI passes objects by their true type, so the behavior of those objects is not changed when they are sent to another virtual machine. This allows new types to be introduced into a remote virtual machine, thus extending the behavior of an application dynamically. The compute engine example in this chapter uses RMI's capability to introduce new behavior to a distributed program.
Remote Interfaces, Objects, and Methods

Like any other application, a distributed application built using Java RMI is made up of interfaces and classes.

The interfaces define methods, and the classes implement the methods defined in the interfaces and, perhaps, define additional methods as well. In a distributed application some of the implementations are assumed to reside in different virtual machines. Objects that have methods that can be called across virtual machines are remote objects.

An object becomes remote by implementing a remote interface, which has the following characteristics.
 

• A remote interface extends the interface java.rmi.Remote.
• Each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.

A stub for a remote object implements the same set of remote interfaces that the remote object implements. This allows a stub to be cast to any of the interfaces that the remote object implements. However, this also means that only those methods defined in a remote interface are available to be called in the receiving virtual machine.
 

RMI provides a simple and direct model for distributed computation with Java objects. These objects can be new Java objects, or can be simple Java wrappers around an existing API. Java embraces the "Write Once, Run Anywhere model. RMI extends the Java model to be run everywhere."

Because RMI is centered around Java, it brings the power of Java safety and portability to distributed computing. You can move behavior, such as agents and business logic, to the part of your network where it makes the most sense. When you expand your use of Java in your systems, RMI allows you to take all the advantages with you.

RMI connects to existing and legacy systems using the standard Java native method interface JNI. RMI can also connect to existing relational database using the standard JDBC? package. The RMI/JNI and RMI/JDBC combinations let you use RMI to communicate today with existing servers in non-Java languages, and to expand your use of Java to those servers when it makes sense for you to do so. RMI lets you take full advantage of Java when you do expand your use.

Advantages
At the most basic level, RMI is Java's remote procedure call (RPC) mechanism. RMI has several advantages over traditional RPC systems because it is part of Java's object oriented approach. Traditional RPC systems are language-neutral, and therefore are essentially least-common-denominator systems-they cannot provide functionality that is not available on all possible target platforms.
RMI is focused on Java, with connectivity to existing systems using native methods. This means RMI can take a natural, direct, and fully-powered approach to provide you with a distributed computing technology that lets you add Java functionality throughout your system in an incremental, yet seamless way.
The primary advantages of RMI are:

Object Oriented: RMI can pass full objects as arguments and return values, not just predefined data types. This means that you can pass complex types, such as a standard Java hashtable object, as a single argument. In existing RPC systems you would have to have the client decompose such an object into primitive data types, ship those data types, and the recreate a hashtable on the server. RMI lets you ship objects directly across the wire with no extra client code.

Mobile Behavior : RMI can move behavior (class implementations) from client to server and server to client. For example, you can define an interface for examining employee expense reports to see whether they conform to current company policy. When an expense report is created, an object that implements that interface can be fetched by the client from the server. When the policies change, the server will start returning a different implementation of that interface that uses the new policies. The constraints will therefore be checked on the client side-providing faster feedback to the user and less load on the server-without installing any new software on user's system. This gives you maximal flexibility, since changing policies requires you to write only one new Java class and install it once on the server host.

Design Patterns: Passing objects lets you use the full power of object oriented technology in distributed computing, such as two- and three-tier systems. When you can pass behavior, you can use object oriented design patterns in your solutions. All object oriented design patterns rely upon different behaviors for their power; without passing complete objects-both implementations and type-the benefits provided by the design patterns movement are lost.

Safe and Secure: RMI uses built-in Java security mechanisms that allow your system to be safe when users downloading implementations. RMI uses the security manager defined to protect systems from hostile applets to protect your systems and network from potentially hostile downloaded code. In severe cases, a server can refuse to download any implementations at all.

Easy to Write/Easy to Use : RMI makes it simple to write remote Java servers and Java clients that access those servers. A remote interface is an actual Java interface. A server has roughly three lines of code to declare itself a server, and otherwise is like any other Java object. This simplicity makes it easy to write servers for full-scale distributed object systems quickly, and to rapidly bring up prototypes and early versions of software for testing and evaluation. And because RMI programs are easy to write they are also easy to maintain.

Connects to Existing/Legacy Systems : RMI interacts with existing systems through Java's native method interface JNI. Using RMI and JNI you can write your client in Java and use your existing server implementation. When you use RMI/JNI to connect to existing servers you can rewrite any parts of you server in Java when you choose to, and get the full benefits of Java in the new code. Similarly, RMI interacts with existing relational databases using JDBC without modifying existing non-Java source that uses the databases.

 Write Once, Run Anywhere : RMI is part of Java's "Write Once, Run Anywhere" approach. Any RMI based system is 100% portable to any Java Virtual Machine*, as is an RMI/JDBC system. If you use RMI/JNI to interact with an existing system, the code written using JNI will compile and run with any Java virtual machine.

Distributed Garbage Collection: RMI uses its distributed garbage collection feature to collect remote server objects that are no longer referenced by any clients in the network. Analogous to garbage collection inside a Java Virtual Machine, distributed garbage collection lets you define server objects as needed, knowing that they will be removed when they no longer need to be accessible by clients.

Parallel Computing: RMI is multi-threaded, allowing your servers to exploit Java threads for better concurrent processing of client requests.

The Java Distributed Computing Solution : RMI is part of the core Java platform starting with JDK? 1.1, so it exists on every 1.1 Java Virtual Machine. All RMI systems talk the same public protocol, so all Java systems can talk to each other directly, without any protocol translation overhead.
 

Architecture Overview
( To add later)
 
 

Object Naming and Locating
The Java Naming and Directory Interface  (JNDI) is a standard extension to the JavaTM platform, providing Java technology-enabled applications with a unified interface to multiple naming and directory services in the enterprise. As part of the Java Enterprise API set, JNDI enables seamless connectivity to heterogeneous enterprise naming and directory services. Developers can now build powerful and portable directory-enabled applications using this industry standard.
 

Overview of the Architecture
The JNDI architecture consists of the JNDI API and the JNDI SPI. The JNDI API allows Java
applications to access a variety of naming and directory services. The JNDI SPI is designed to
be used by arbitrary service providers including directory service providers. This enables a
variety of directory and naming services to be plugged in transparently to the Java application
(which uses only the JNDI API). Figure 2 shows the JNDI architecture and includes a few
service providers of directory and naming contexts as examples.