Sponsored Link •
This article, the first of a two-part series, describes the challenge of understanding and debugging JavaSpace-based systems, and presents a local logging architecture that allows you to record and analyze the behavior of such systems.
In this two-part series of articles, we are going to look at how to build a system that lets you invisibly record activities of JavaSpace clients by producing space events and logging them for immediate or future analysis. We will specifically concentrate on the collection of events associated with the JavaSpaces API calls (rather than the way we view and analyze the events). We will develop a system architecture over several iterations and show the various architectural models that you can use to implement a space-based logging system. In addition, we will give you a taste of several implementations of the logging system. By characterizing each solution, we can improve the system design and understand the situations in which you might use the various solutions. We will assume some basic knowledge of Jini and JavaSpaces. See Resources for links to Jini and JavaSpaces tutorials.
In many cases, we have found building distributed systems with JavaSpaces lets us reach solutions quicker than with traditional techniques. With the right approach, JavaSpaces can help alleviate problems common to many distributed systems, such as partial failure and tight coupling between clients and services.
Although using JavaSpaces provides us with a means (among other things) to build loosely coupled systems, using JavaSpaces can lead to a lower level of predictability and confidence in the system's overall behavior. Or, to put it another way, by using JavaSpaces you can give up some control and visibility over the system's activities as a whole.
When you deploy space-based systems, you need to have some confidence that they will work and continue to work as you scale them up. At design and build time it is easy for developers make errors based on false assumptions about the way a space-based system will operate. Therefore, we suggest you always build a small system subset that you intend to deploy to test your assumptions of the system's behavior against what you can observe.
Hint: Build and test in the small first to test your assumptions.
Even with small systems, finding out what occurs 'in the space' can be difficult. Shifting reads, writes, and takes in your code or inserting debug statements in important places may give you clues. But these techniques are effective only in the simplest systems, where you can easily imagine the flow of objects around the system. Systems of anything other than the most trivial complexity require not only stretching your imagination, but also using tools to help you imagine space activity. Tools that let systems developers or designers view the activities of the system's various clients can help restore confidence in understanding the system's behavior as a whole.
In general, software debuggers apply to one executable and let you observe the behavior of the software you have written. So you not only use debuggers to debug systems, but also to understand the way they work. Debuggers also provide clues for code refactoring and perhaps optimizing the local system's behavior.
When you apply this model to spaces, you need a tool that lets you see a distributed system's behavior as a whole. In the same way local debuggers let you see a local program's behavior and individual thread activity, you need to see what each client of the space does in order to see how your whole system behaves.
One of the most useful tools we have developed while designing and building space-based systems has been a logging system that lets you record the operations performed on the space's API. Later in this article, we'll analyze the log to see which operations were performed and in what order.