and management techniques offer hope.
Getting There from Here
A challenge common to all distributed applications is that someone, somewhere has to get information from here to there and back. One of the most costly aspects of distributed software has been in building the underlying communication mechanisms. Writing directly to TCP/IP or Sequenced Packet Exchange (SPX) is not particularly pleasant, and slightly higher-level solutions like Sockets and Transport Level Interface (TLI) are only marginally better.
The need for easy-to-use communication mechanisms has inspired middleware technologies like the Common Object Request Broker Architecture (CORBA) specification from the Object Management Group (OMG). This specification lays out a mechanism for communication between distributed objects using object request brokers (ORBs) by way of an interface definition language
(IDL). In this architecture, clients desiring to access the services of another object make requests to an ORB, which brokers a connection between the two and permits the client to access the object implementation. Many companies are now developing middleware products that are either based on or are compliant with CORBA, including IBM's SOMobjects Developer Toolkit.
Similarly, within the Windows environment, Microsoft's Distributed COM (or DCOM, formerly known as Network OLE) lets you build applications with objects that work together on distributed machines. Objects can communicate using DCOM without any object knowing the physical location of any other object. Microsoft exhibits a wait-and-see attitude toward CORBA.
Microsoft based its Distributed COM remote procedure call on the Open Software Foundation's Distributed Computing Environment (OSF's DCE). This potentially means that, sometime in the future, distributed objects in Windows applications will be able to communicate with non-Microsoft
operating systems.
Middleware products can make it easier for objects to communicate in situations where nothing better exists. Luckily for developers of distributed applications, something better does exist in the form of distributed databases. Development environments for client/
server database applications can help you build sophisticated clients to access the services provided by back-end database products such as Gupta's SQLBase and Microsoft's SQL Server. These tools embed middleware capabilities within higher-level functions, so you don't have to worry about the gritty details of getting packets from here to there. Leading development packages include Borland International's Delphi Client/Server Suite 2.0; Microsoft's Visual Basic Enterprise Edition 4.0; Gupta's SQL Windows 5.0; and Powersoft's PowerBuilder Enterprise for Windows.
To pick the right tool for your applications, make sure the product you're considering supports all the database engines used throughout your organization (
some environments, such as Borland's Delphi Client/Server Suite 2.0 and Microsoft Visual Basic Enterprise Edition 4.0, can access up to eight different database engines). Also look for strong SQL support. Products that offer this include Delphi, Visual Basic, and SQLWindows 5.0. For database administration, the best tools, like Delphi, let you administer from within the tool. The visualizers in Gupta's SQLWindows especially stand out. Finally, data integrity can make or break your application. Because of this, development tools should offer programmatic access to referential integrity, as Visual Basic does.
Juggling Developers
Development tools aid you in building distributed software, but they aren't the complete answer for high-quality applications. One axiom of client/server development holds that quality must be paid attention to early in the software life cycle, and programmers must be closely involved in quality assurance during all phases of development. That sounds grea
t on paper, but it runs counter to the traditional waterfall model of software development that places software testing near the end of the process.
Compounding this problem is the fact that many companies still live with a wall (and some hostility) between the development and testing organizations. Development builds product until they decide it's done, and they toss it over the wall to the QA department. The testing team stands at the end of the assembly line with a piece of chalk, scrawling a big "X" on products doomed for reworking and throwing them back over the wall.
Add distributed development to the mix and the goal of quality software written on time seems impossible. To handle the increased complexity of distributed products, development and test engineers must live in greater harmony and interact earlier in the development process. And what do you do when the development department sees quality assurance as the testing department's job? Or when developers are expected to do unit testing
but don't know how to start?
The best way to make the development and testing teams harmonize is to make system defect information available to all members of the team. Distributed bug-tracking systems allow test engineers to communicate with development engineers regardless of physical location. Tracking systems include CA-Endevor/ WSX from Computer Associates; CaseWare from Continuus Software; and Cohesion Team/SEE from Digital Equipment. These systems can automatically pass work among members of a development group, regardless of where they may be. You can augment these systems by combining the bug-tracking system with an automated testing facility (see the article "Testing, Testing"). This way, tests can automatically run while an engineer is gone for the night, and bug reports can be waiting in the morning.
So how do you get development engineers and QA experts to convert to new policies and technologies? The most common approach -- to mandate change and then live with armed rebellion until
the most hostile individuals either go away or stop whining -- is probably not the best. A more Trojan Horse approach works on the psyche of the development engineer. You take a product like
Pure Software's Purify
, which runs in the background and automatically reports problems. You can get development engineers to buy into background testing by emphasizing one of its important benefits: Because testing tells developers about problems before the QA staff uncovers them, developers are saved the embarrassment of having bugs entered into the tracking system where they will be visible to management. The engineer is now doing unit testing, albeit not in a structured way.
Another example is code coverage tools, such as QC/Coverage (CenterLine Software) and PureCoverage (Pure Software). Code coverage -- keeping track of how much code actually was tested during a test -- is often viewed as a QA function, since that department is the one preoccupied with how much of the code their system te
sts are touching. But why shouldn't development engineers use these tools whenever they take the product for a spin? Shouldn't they also have a clue about how much coverage they are getting before it enters formal system testing? Despite the distributed nature of the development, such tools help ensure software quality during the development process, without what often seems like the intrusion of formal testing.
Unwanted Blasts from the Past
Legacy code is another nasty problem developers face. Imagine this: You've just been handed 50,000 lines of code you've never seen before, and you need to find and fix a single bug. You probably spend two full weeks just tracking your way through the code, change one line, recompile, and the bug goes away. You hope. You also hope that you haven't introduced some other bug by failing to understand dependencies in the code that weren't visible using grep. And how does your effort affect the other far-flung members of the development team?
Disc
over, from Software Emancipation Technology, is one tool that provides developers with a view of code dependencies and allows for sharing information among members of a distributed team. One of the first things engineers often do when faced with legacy code is build a picture that can help them understand where to hunt for a bug. Automated tools can build these pictures and share the knowledge with distant teammates.
Fighting Fire with Fire
When technology grows in complexity, the source of quality lies in the same technology. If distribution is your problem, distribution can also be your solution. As project management tools grow in complexity, their functions will evolve and interconnect. Bug tracking and code coverage testing will unite to form distributed development tools. One of the most visible waves involves the use of distributed objects as building blocks for distributed systems.
Perhaps the best example of this is also the world's most distributed system. Software Ema
ncipation plans to allow Discover to provide its wealth of information by way of Hypertext Markup Language (HTML), so that distributed teams can browse source code and other information on the Web. Again, this is using a distributed system (the Web) to support distributed development.
Others take this idea a step further and suggest that we should look at using the already distributed Web to replace traditional forms of distributed client/server applications. And why not? With Common Gateway Interface (CGI), we can input information via a Web page, and with Java applets, portions of a distributed application can download to a client workstation and execute. Netscape Navigator as a universal client front end? Stranger things have happened. But we can be sure that development teams are going to keep spreading out, and applications are spreading out with them. Whether you're a developer or a coordinator, make sure you've got the right tools before you're spread too thin.
Where to Find
Borland International
Scotts Valley, CA
Phone: (408) 431-1000
Internet:
http://www.borland.com
Developing Quality
