Java Architect Notes

Here are some comments on the Java Architect certification based on what I learned from Sun’s Java Technology Architecture Planning & Design course and on my experiences in sitting the exam. I’ve tried to tie in my comments to specific objectives for the certification. Don’t expect to find questions and answers in here! Those of us who passed the certification worked hard to get it, and no one wants to see the certification being devalued.

Module 1: Introduction to the Architect Process using Java technology.

1. Describe the duties performed by a Java Architect.

An architect of Java applications needs to be business-aware as well as technology-aware. An architect may be called in to advise management on how to take an existing system to production status, or to define requirements for a new system, or to develop a project plan which might include recommendations for training and mentoring the customer's staff.

The customer may have already produced a proposed architecture and simply want the architect to lend his expertise in evaluating it.

Java architects may be involved at all stages in the development lifecycle, although will generally not actually do the coding himself.

There are obviously constraints on the architecture which may be employed in any situation. These might include:

· The customer's existing systems (including legacy data, infrastructure etc)

· The network bandwidth

· The customer's budget, skills of the customer's development staff etc

· Security requirements

2. State how Java architecture design fits into the application development lifecycle.

Java architecture design fits in between object-oriented analysis and object-oriented design.

A good architecture should involve the creation of a robust solution, which is scalable, preferably portable (clearly the platform independence of Java fits in here), performs well, is well documented, and is successfully integrated with any existing system and/or data.

The types of diagram which an architect may produce are class diagrams, UML package diagrams, dependency diagrams and UML deployment diagrams. Other UML diagrams may also be used for example sequence diagrams or collaboration diagrams.

3. State the advantages of a distributed object architecture implementation.

There are many advantages of a distributed object architecture implementation. Perhaps the most important is that a distributed architecture is much more scalable.

UML notation which should be known: learn the notation for a package, an object instance, and active object instance, a node and a component. Nodes are used to indicate deployment tiers, components are used to indicate particular classes and how they interact.

Should understand the concepts of separating an architecture into layers (or tiers). Presentation (user interface) should be separated from the business logic which should be separated from the data access logic. These three layers or tiers are logically separate but may be physically on the same machine (although the solution will not be particularly scalable if the business logic needs to be on the same machine as the data access logic). The separation logically of these tiers allows for different distribution models. This makes the solution scalable and flexible. The solution is scalable because more servers can be added in the middle tier. The solution is flexible because, by separating the presentation, business logic and data access logic, the tiers may physically reside anywhere.

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 comprimised 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.

Applets, Applications and Servlets

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 standardise 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.

4. Explain the Advantages of such a Java Solution compared to alternative solution compared to alternative solution technologies such as C++.

Java enthusiasts can go nuts here! Obviously Java is a truly object-oriented language (C++ is not) and Java is platform independent (C++ is not) and Java is garbage-collected (C++ is not). Also, C++ has no in-built support for Internet security.

Module 2: Designing a Java technology architecture.

1. Evaluate the applicability of a Java solution for a given customer application requirement.

Need to consider the infrastructure which the customer already has in place, the in-house skills which the customer currently has and the customers long-term plans and goals.

Consider:

· Is the application to be deployed via the Internet/intranet/extranet? If so, Java’s security features would be a plus for the customer.

· Does it appear that the application may be quite volatile? Application maintenance is made more manageable in Java (see comment above 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.

2. State the major architectural issues and trade-offs faced when designing a distributed Java solution.

Pretty much covered by the above.

3. Design a basic three tier architecture for a set of customer requirements.

You’re on your own here..

4. Discuss the advantages of Java servlets compared to CGI scripts.

As discussed above.

Module 3: Java technology architecture details.

1. For a given set of business requirements, design a three (or n) tier object-oriented application architecture.

You’re on your own here..

2. Design a detailed architecture including Java applet and application server design.

You’re on your own here.

3. Compare a distributed Java architecture with the OMG CORBA and Microsoft alternatives.

The Microsoft DCOM architecture is quite like CORBA. Good idea to read a little about DCOM. It doesn’t have proven scalability, which CORBA does, and there is currently no centralised naming service. You can’t use it to integrate with legacy applications, which you can with CORBA. CORBA is for communication between object-oriented applications, but you can get round this by putting an ‘object wrapper’ around non object-oriented applications. Both CORBA and DCOM are based on quite complex frameworks. RMI is based on a fairly simple framework, but can only be used to communicate between Java applications (I use the term applications loosely here, I also mean servlets and applets). Only RMI is garbage collected. CORBA is the most mature and is an ‘open’ standard.

4. Discuss the pros and cons of these distributed architectures for a set of customer requirements.

You’re on your own here.

Module 4: Integrations with existing applications and databases.

1. Design a three (or n) tier Java architecture where the third tier is an existing application, file or database.

Common integration techniques are to use JDBC (used to access RDBMSs), Screen scrapers (if the legacy system does not have a published interface or the documentation has been lost), Object wrappers (can wrap up an existing non object-oriented system and then use CORBA to communicate), or alternatively to use any published interface to the legacy system (for example, the legacy system might support TCP sockets).

2. Design a detailed architecture for integrating Java with existing databases and applications.

You’re on your own here.

3. State the advantages and disadvantages of using screen scrapers to access applications at tier three.

Disadvantage is that screen scraping is generally pretty slow, and the application cannot be modified to allow additional functionality. All you can really do is put a new interface on an old application using screen scraping. An advantage is that it can be implemented without any disruption to existing legacy applications, and also the training requirements for the new system should be minimal.

4. State the advantages and disadvantages of object mapping for legacy system access.

Advantage is object technology throughout the architecture, but disadvantage is that you have to write the wrapper code.

Module 5: Architecting new applications.

1. Recommend a migration strategy for an existing application.

Either migrate applications or use screen scraping. Migrate where possible, especially if the legacy applications are hard to maintain, have a lot of new requirements, have swiftly evolving requirements etc.

Weigh up cost of migration, new infrastructure costs, training costs etc. against value to the customer of new system.

2. Design a three (or n) tier architecture using Enterprise JavaBeans.

Read as much as you can about EJBs. EJBs run in Containers which run within Servers. The Container looks after the lifecycle of the EJB. The Server can run one or more Containers, and provides access to a distributed transaction mechanism. EJBs have Home and Remote interfaces. Read a bit about these.

3. Describe how Java can be used for transaction processing.

A transaction processing monitor container provides support for transaction processing.

4. Discuss alternative Java architectures, for example, publish/subscribe.

See Objective 3 in Module 1.

5. State the advantages and disadvantages of partial migration using Java applets and applications.

You’re on your own here. Just use common sense.

Module 6: Designing a secure Java technology architecture.

1. State the security constraints and trade-offs that affect Java application architecture.

Security versus usability trade-off. Read about firewalls, demilitarized zones (DMZs), SSL (Secure Sockets Layer), message digests, digital signatures, Access Control Lists (ACLs), HTTPS, SHTTP, VPNs (Virtual Private Networks (usually implemented in hardware)), JCE (Java Cryptography Extension).

JCE and SHTTP operate at the application layer of the OSI model, SSL operates at the transport layer of the OSI model, VPNs operate at the network layer of the OSI model. SSL uses RSA public key cryptography.

2. Design a three (or n) tier Java architecture for use over an unsecured public network such as the Internet.

You’re on your own here.

3. Evaluate a proposed (or existing) Java solution architecture and make recommendations to provide or increase security.

You’re on your own here.

4. Design a three (or n) tier architecture for an extranet application.

You’re on your own here.

Module 7: Designing an architecture for performance.

1. Evaluate a proposed (or existing) Java architecture and make recommendations to increase performance

Use jar files where possible to speed up applet download. Transfer of objects using RMI is very slow - can this be avoided? JDK1.2 supports compression. Later versions of JVM have better optimisation. Bytecode is verified when running applets. Use of applications in tier one is faster therefore, because there is no bytecode verification.

To further speed up applet download, can just initially download those classes necessary to present the GUI, then download the rest of the classes in a separate thread in the background.

Cut down on round trips to the server where possible.

HTTP1.1 supports keeping the connection to the server upon for additional requests. Where possible, use browsers and Web servers that support HTTP1.1.

Can use a profiling tool such as JavaPerf or CaffeineMark to profile applets.

2. Design a multi-tier Java architecture to meet an acceptable level of performance and that can be tuned and scaled as necessary.

Your design will be scalable because extra servers can be added in as necessary. Provided that you considered performance when you were creating the design, the ‘tuning’ referred to is mostly just a case of recommending memory or other hardware upgrades. You could also offer a choice of applets for users to download (e.g. minimal graphics for remote users and the fully whammy for intranet users).

You shouldn’t design something that, when it comes to the production stage, turns out to be way too slow and then tell the customer that they’ll need to upgrade all of their hardware. This is really what prototyping is for. You should discover at the prototype stage whether the architecture can meet (or very nearly meet) its performance targets. You can then make recommendations to the customer as necessary. The customer will NOT be impressed if you announce at the last minute that they need to spend many thousands of pounds/dollars to get the system usable!

Module 8: The Java technology architecture in production.

1. Design a Java architecture that can be easily moved into production.

You’re on your own here.

2. Given a Java prototype or pilot application solution, advise on how it can be effectively moved to production status.

Test or simulate all user configurations (Internet users (to test through firewalls), remote users, dial-in users etc) which the system is to cope with. Test any services used. Simulate the network environment as closely as possible.

3. Recommend solutions for efficiently deploying and distributing Java solutions in production.

You’re on your own here. Just bear in mind that in production, tiers may reside in physically different places, and the data will be production data rather than test data.

4. Recommend Java application development, Java reusability techniques, and project management techniques.

You’re on your own here.

Further Tips

This document isn’t written so that anyone who reads it can pass the exam with no further study, but rather to highlight the kinds of things which Sun expect you to know. The objectives given for the Architect exam on Sun’s Web site are very vague, and it is difficult for people to gain sufficient confidence to sit the exam when it is so unclear precisely what material needs to be covered. Hopefully this document will help a little.

In addition to background reading on any of the technologies mentioned above, I would particularly recommend:

· Learning about RMI architecture and features

· Learning about CORBA architecture and features

· Learning about EJB architecture and features (probably a good idea to read about JavaBeans first!)

· Learning about JDBC architecture (and its relationship with SQL).

· Learn a little about OODBMSs and OQL.

Whitepapers available via Sun’s Web site should be quite a help with this.

Book

I have found ‘Client/Server Programming with Java and CORBA’ by Robert Orfali and Dan Harkey to be very helpful reading.