"Is WSDL the Indispensable API?"

Eoin Lane

Microsoft left out in the cold

Eoin,

I realize that JavaWorld is obviously focused on Java, and that 99 out of 100 readers would probably like to see Bill Gates swinging from a willow, but in your section titled "Middleware: A Brief History," you are remiss in failing to mention Microsoft's role in the evolution.

But more disturbing, you suggest that "EJBs (Enterprise JavaBeans) introduced distributed components" and "EJBs also introduced containers," which is totally inaccurate. Like it or not, Microsoft's COM/DCOM/MTS/DTC first brought us a component runtime (the model Sun Microsystems used to develop its enterprise Java strategy) to transparently provide services such as declarative security, lifetime management, object pooling, and distributed transactions. Microsoft continues to lead the way while Sun desperately tries to keep up.

For instance COM+ developers have enjoyed declarative asynchronous components and component events for years now. In Java, we have to write to a JMS (Java Message Service) queue to use MDBs, which is as annoying as writing JDBC (Java Database Connectivity) code; and we lose type safety along the way. Also, Web services, the crux of your article, came from Microsoft and DevelopMentor à la SOAP (Simple Object Access Protocol).

So I think you need to give the devil his due, even if it turns out he actually is the devil!

Ed MacDonald

Ed, You are totally right, and I stand corrected. I actually had a paragraph in the article about Microsoft and its valuable contribution to the middleware evolution but took it out because the article was getting too unwieldy. However, in hindsight and in light of your comments I should have left it in. While I am no great fan of Microsoft and my knowledge of the COM architecture is at best second hand, I believe the company's new incarnation of .Net built around Web services standards shows great vision, and I shudder to think what the future of programming will hold for us in another couple of years. Thank you for your comments and frankness and for keeping me in line. Eoin Lane

"Sync up Palm OS with J2ME"

Jeb Beich

In sync with iPAQ

Jeb,

How do I program a Java class file into an iPAQ H3660 (with support for a wireless adapter card)?

Ne Beng

Ne, In order to execute a Java application on your iPAQ, you will first need a runtime environment—a version of the JVM—installed on your device. You must determine the operating system (in this case Microsoft's Pocket PC) and find a JVM that runs on it. You should check out JavaWorld's article, "Think Small: Java on Compaq's iPAQ" (October 2001), if you haven't already. Companies like Insignia, mentioned in the above article, provide runtime environments for many different devices. If you do decide to use a runtime environment such as one mentioned in the article, you will be working with a specific subset of the Java 2 Platform Standard Edition known as PersonalJava, which includes most of what you will find in J2SE. Read this spec to find out PersonalJava's specifics. You create your class files based on this specification. Then use a tool at http://java.sun.com/products/personaljava/javacheck.html to make sure your class files are compliant with the spec. Sun even has a PersonalJava emulator at: http://java.sun.com/products/personaljava/pj-emulation.html. Once you have developed an application that meets the PersonalJava specifications (and possibly tested it out on the emulator), you should be all set to try it out on your iPAQ's PersonalJava runtime. Jeb Beich

"Eliminate JDBC Overhead"

Ryan Daigle

Yet another framework?

Ryan,

I don't understand the purpose of this framework. Isn't it just reinventing the wheel? Doesn't EJB (Enterprise JavaBeans) 2.0 with CMP (container-managed persistence) already fulfill this framework's requirements? You write this article in the context of developing J2EE (Java 2 Platform, Enterprise Edition) apps, so it doesn't seem to make any sense to write yet another framework. Just go EJB.

Greg Turner

Greg, I have come across many companies/projects that don't utilize EJBs for a variety of reasons:

  • Performance issues
  • They cloud domain objects with persistence logic
  • The application doesn't need the level of persistence management that EJBs provide

While I don't mean to spark a discussion of the merits/drawbacks of EJBs, the fact is several J2EE applications do not utilize EJBs. I hope that those implementations can benefit from the outlined framework. Also, within an EJB, do you have to make SQL calls in the various

ejbStore

/

ejbRemove

, etc. methods? Could the framework described in this article be used from within the EJB itself? Ryan Daigle

Java 101

"Achieve Strong Performance with Threads"

Part 1: Introducing threads, the Thread class, and runnables

Part 2: Use synchronization to serialize thread access to critical code sections

Jeff Friesen

Clarification on synchronization, please

Jeff,

The second part of your article on threads was great. I'm waiting for the others.

Question 1: Are these ideas of synchronized access to methods encouraged in distributed system classes that access the same method on the server class? What about in cases of database classes (also in a distributed system) where I have just one open connection? Should I use the mentioned method synchronization to assure an organized use of the connection and thus avoid reading data before it has been completely updated, for example?

Question 2: Is the lock performed only over the method that has the synchronized keyword or over all the synchronized methods that use the referenced objects in a synchronized method? The article showed the lock for one synchronized method. What if I had other synchronized methods in the same class that use the same class variables, or even other variables? Would these other methods be concurrent to the one in the article? In other words: Are all synchronized methods concurrent within the class, no matter what signature they have? Would the lock still work for synchronized methods in different classes?

Tiago Flach

Tiago,

Answer to Question 1:

Yes. If you are looking at batches of operations, you will undoubtedly need to use synchronization. However, if you are looking at calling a single resource method (such as a JDBC (Java Database Connectivity) method) here and a resource method there (and if the resource method is synchronized), you probably do not need to worry about synchronization. When working with distributed systems, database systems, and any other kind of resource, keep the following in mind: If you write a method that performs several resource operations that a thread must complete before another thread calls that method and starts to execute those operations (or calls another method and starts to execute a related group of operations), you will need to synchronize those methods. Otherwise, inconsistencies will develop. It doesn't matter if individual operations are synchronized. The idea is that the whole batch of operations must complete to prevent inconsistencies.

Answer to Question 2:

For synchronization to work, all synchronized instance (that is, nonstatic) methods within a given class must work with the same object lock; but that only happens if those methods are called using one or more object reference variables that reference the same object. To understand that concept, first examine the following code fragment:

class Fred
{
    synchronized void a ()
    {
          // Appropriate code to execute.
    }
    synchronized void b ()
    {
         // Appropriate code to execute.
    }
}

The code fragment introduces two synchronized methods in the same class:

a()

and

b()

. Assume the following code fragment executes in some other method:

Fred f = new Fred ();

Suppose you have two threads and one thread executes

f.a ();

. Now suppose the other thread calls

f.b ();

while the first thread is still within

a()

. The thread calling

b()

will have to wait until the thread executing within

a()

leaves

a()

, because the thread inside

a()

holds the lock that associates with the object that

f

references—and the thread that wants to execute

b()

must acquire that lock. As a result, synchronization takes place. Now assume the following code fragment executes in some other method:

Fred f1 = new Fred ();
Fred f2 = new Fred ();

Suppose one thread calls

f1.a ();

and is still in that method when the other thread calls

f2.b ();

. Because each thread calls its respective method using a different object reference variable (which is referencing a different

Fred

object), both threads acquire different locks and gain access to their critical code sections—the code within their synchronized methods. In this case, there is no synchronization. As a result, care must be used to ensure all threads use the same object when calling various synchronized instance methods within the same class. Note: This discussion can be applied to class (that is, static methods). However, remember that class methods work with the class lock—the lock that associates with a class's

Class

object. Jeff Friesen