Q25. How can I maintain a single instance of an object in an applet?

In start(), instead of always creating a new object, return the existing one if it exists or create a new one if it doesn't.

Q26. What is the best way to generate a universally uniqueobject ID? Do I need to use an external resource like a file
or database, or can I do it all in memory?

I need to generate unique id's that will be used for node 'ID' attribute values within XML documents. This id must be unique system-wide. The generator must be available to a number of servlets that add various node structures to my XML docs as a service. What is the best way to tackle this? The 'possible' ways I can see:

• Keep the maximum ID value in a flat-file where the service would read it upon startup and increment it. Upon shutdown or failure, it would write the latest max id to the file.
• Calculate the max id by searching the XML itself. This will be tougher since XML
requires an alpha-numeric value (not strictly numeric).
• Use a database (MySQL) with a two-field table where one field is the incremental
counter.

I just have this feeling that none of the above are the most efficient ways of doing this. Regards, -Andy] There is an additional way to do that that doesn't rely on an external file (or database) like the one you have presentred. If has been presented in the EJB Design Patterns book, written by Floyd Marinescu, and available in a pdf format for free from the given link. The suggested solution is based on the UUID for EJB pattern, that comes out from this question:

How can universally unique primary keys can be generated in menory without requiring a
database or a singleton?

Without enetring in the specifics (you can fully check out the pattern by reading the
appropriate chapter), the solution is to generate a 32 digit key, encoded in hexadecimal composed as follows:

1. Unique down to the millisecond. Digits 1-8 are are the hex encoded lower 32 bits of the System.currentTimeMillis() call.
2. Unique across a cluster. Digits 9-16 are the encoded representation of the 32 bit
integer of the underlying IP address.
3. Unique down to the object in a JVM. Digits 17-24 are the hex representation of the
call to System.identityHashCode(), which is guaranteed to return distinct integers for
distinct objects within a JVM.
4. Unique within an object within a millisecond. Finally digits 25-32 represent a
random 32 bit integer generated on every method call using the cryptographically
strong java.security.SecureRandom class.

Q27. Is there some kind of Design pattern which would make it possible to use the Same code base in EJB and non
EJB context?

A good suggestion would be using Delegation
class PieceOfCode {
public Object myMethod() {}
}
class EJBImpl ... {
PieceOfCode poc = new PieceOfCode();
public Object myMethod() {
return poc.myMethod();
}
}
This should not be a violation of EJB specs, since EJBs can use simple java classes for their use. Think about Dependant Objects and so on.

Q28. What is session facade?

Session facade is one design pattern that is often used while developing enterprise
applications. It is implemented as a higher level component (i.e.: Session EJB), and it contains all the iteractions between low level components (i.e.: Entity EJB). It then provides a single interface for the functionality of an application or part of it, and it decouples lower level components simplifying the design. Think of a bank situation, where you have someone that would like to transfer money from one account to another. In this type of scenario, the client has to check that the user is authorized, get the status of the two accounts, check that there are enough money on the first one, and then call the transfer. The entire transfer has to be done in a single transaction otherwise is something goes south, the situation has to be restored.
As you can see, multiple server-side objects need to be accessed and possibly modified. Multiple fine-grained invocations of Entity (or even Session) Beans add the overhead of network calls, even multiple transaction. In other words, the risk is to have a solution that has a high network overhead, high coupling, poor reusability and mantainability. The best solution is then to wrap all the calls inside a Session Bean, so the clients will have a single point to access (that is the session bean) that will take care of handling all the rest. Obviously you need to be very careful when writing Session Facades, to avoid the abusing of it (often called "God-Bean").
For a detailed description of this pattern, check this page:
Core J2EE Patterns – Session Facade or get Floyd Marinescu's EJB Design Patterns, in PDF format.