Subscribe
Issue No.03 - May/June (2006 vol.23)
pp: 100-102
ABSTRACT
<p><strong>Are You Fit?</strong><div>Anthony Akins</div><div>Review of <em>Fit for Software Development: Framework for Integrated Tests</em> by Rick Mugridge and Ward Cunningham.</div></p><p><strong>Rethinking Secure Database Systems</strong><div>Radu State</div><div>Review of <em>Cryptography in the Database: The Last Line of Defense</em> by Kevin Kenan.</div></p><p><strong>Web Services: More Than Just SOAP</strong><div>Art Sedighi</div><div>Review of <em>Service-Oriented Software System Engineering: Challenges and Practices</em> by Zoran Stojanovic and Ajantha Dahanayake, eds.</div></p>
Are You Fit?
Anthony Akins
Fit for Software Development: Framework for Integrated Tests by Rick Mugridge and Ward Cunningham, Prentice Hall, 2005, ISBN 0-321-26934-9, 355 pp., US44.99. I'm writing this review while watching the 2006 Winter Olympics. In every event, I see the importance of fitness, balance, and agility. The best athletes make small adjustments to stay aligned, in balance, and on track. They waste little effort because every movement is integral to overall performance. Then I return to the world of software development, where everyone works hard, but progress doesn't match the effort expended; where we rarely take the time to reflect on what we've done, should have done, and want to do next. There's too much work to do, so we keep our heads down, hoping things will get better but fearing they won't. Can we learn from the Olympic athlete? What can we do to be fit, balanced, and agile? A good beginning is reading and practicing the ideas in Fit for Software Development: Framework for Integrated Tests by Rick Mugridge and Ward Cunningham. This book can help you assess your software, and it introduces a tool and methods to make your software more fit, balanced, and agile. Fit (Framework for Integrated Tests), an emerging tool in the agile development toolbox, is a testing tool for writing business-facing tests. It provides a simple interface for describing and testing business rules and calculations. To use Fit, you need tables that describe the application behavior, fixtures that connect the tables to the application being tested, and the Fit framework itself. You can create tables in a spreadsheet or in HTML. Fit's three basic flavors test • calculations, • actions and events (business processes and workflow), and • lists and collections. Creating fixtures requires programming experience and familiarity with the software being tested. According to the authors, Fit addresses the two tasks or issues essential to a software application's overall health: its quality and value. It • communicates what a software application needs (improved through concrete examples described in the Fit tables), and • confirms whether the software does what it should as it grows more complex (improved through automated testing of the Fit tables' content). The book's first section applies to those without a programming background who understand the business rules and processes that the software application is being developed for. This section introduces the concept of Fit tables and shows how to develop them. The second section is for those with programming experience who would be developing the system's fixtures. These two sections are interlaced, using the same problem scenario to build a set of Fit tables describing the desired application behavior and then build a set of fixtures to connect the tables to the application. The final section provides additional information on custom development of fixtures and connections. Fit's discovery and communication tool is its greatest promise. Throughout the book, the authors provide suggestions for improving communication and testing on software development projects. The ones that rang true for me were • Using Fit tables to clearly communicate new functionality the system needs. In this case, they help business-people communicate to the developer what the software needs. Additionally, writing one or more Fit tables for a story or use case helps customers and developers think, discuss, and agree on what the software application should do. • Using test infection to improve the software's health. In this case, infection is a good thing and should occur slowly by focusing initially on areas that should change. Test infection is developing tests (that is, Fit tables and fixtures) for the area undergoing change. Code is test infected if its structure and organization enable testing. • Using test smells to determine problems. Test smells are situations where you suspect something is wrong with a test but can't immediately see or confirm it. Some examples of test smells are brain twisters (where it's difficult to tell whether a test is correct), tangled tables (interrelated tests that are mixed together, resulting in a long, convoluted table or test), and unnecessary detail (the table or test has superfluous information, but unless you're very familiar with it, you won't know what's necessary). The authors thoroughly introduce Fit from the customer's and developer's perspectives. Their ideas and suggestions about testing are well worth reading and practicing. But is this book for you? You must ask yourself two questions: Do I want to get fit? Am I ready to get fit? If you answered yes to both questions, it's time to get Fit for Software Development. You'll know you're on the way to being fit when • you know that a software part needs attention because of current or past problems, • simple and clear business rules for the part exist (or someone can clarify questions), and • people familiar with the business and testing are eager to participate and have management's support to do so. Anthony Akins is a senior consultant at Valtech Technologies. Contact him at anthony.akins@valtech.com. Secure Data Systems Radu State Cryptography in the Database: The Last Line of Defense by Kevin Kenan, Symantec Press, 2005, ISBN 0-321-32073-5, 276 pp., US29.69.
I was baited by this book's title, wondering how cryptography and databases could be brought together. Intuitively, we can imagine that a database can store data items securely, but I had more difficulty trying to imagine why someone would do it. After all, well-configured access control mechanisms and sound operational practice would be largely sufficient.
Reading Cryptography in the Database made me rethink what I considered secure database systems to be. The book's subtitle— The Last Line of Defense— describes its scope succinctly. When all external defensive protections (such as firewalls, intrusion detectors, application-level prevention systems, and database-driven access control) break, a well-designed cryptographic architecture might be the silver bullet for deterring a malicious user from improperly using your database system.
Securing database systems is an important topic for many enterprises and government agencies because companies that store sensitive, confidential data must enforce and meet many laws and security standards. Such data can come from healthcare and medical sources, commercial and financial transactions, even online protection requirements for children. Kevin Kenan describes a cryptographic infrastructure for database systems that can serve as a generic security mechanism for any cryptographic database project. This infrastructure is based on seven functional components:

• a cryptographic engine, which performs the cryptographic operations (for example, ciphering and deciphering using secret keys that can be used to encrypt and decrypt either subsets of columns or rows in a database);

• protected data, or the stored enciphered data;

• the key vault, which stores cryptographic keys;

• the key manager, which manages these keys;

• the key manifest, which facilitates the keys' management;

• cryptographic consumers, or applications requiring cryptographic operations; and

• a cryptographic provider, to whom these operations are outsourced.

Starting with this simple functional architecture, the book delves into each component's specifics, focusing on the essential features. One example is key life-cycle management, where specific operations must be performed when cryptographic keys are created, expired, or terminated.
Kenan does an excellent job of showing how to define the key scope (that is, the subsets of rows or columns to be protected) and how this choice impacts the key life-cycle management's complexity. We must pay special attention to the storage of encryption keys because their compromise is synonymous with compromise of the entire database. The key vault is mainly responsible for these purposes, and Kenan describes and illustrates the possible design choices—key servers and key stores.
About half the book is programming-oriented, covering the cryptographic infrastructure's design and Java-based implementation. About one chapter covers each functional entity, and abundant comments and additional explanations make for an easily understandable discussion. I usually dislike tons of programming code inside a book, preferring an accompanying CD-ROM; in this case, however, Kenan's slow pace in presenting the general software design and code examples provides a well-thought-out balance between pedagogic precision and immediately usable code.
Cryptography in the Database has the necessary ingredients to become a database security reference book. Pragmatic and application-oriented, it targets an important topic and provides a directly usable solution for the impatient reader. It contains the right amount of background material for understanding the cryptography- and database-related chapters without overwhelming you with advanced graduate-level mathematics (as most cryptography-oriented books typically do).
The target audience is database system programmers and administrators working on high-security database projects. The code examples are in Java, assuring a large specter of system-level portability. For those of us using other programming languages, the infrastructure's software design is relatively straightforward and easy to port.
I warmly recommend Cryptography in the Database to all interested in database security and applied cryptography.
Radu State is a senior researcher at INRIA. He also teaches a graduate-level computer security class at Henri Poincaré University. Contact him at radu.state@loria.fr.
Web Services: More Than Just SOAP
Art Sedighi
Service-oriented Software System Engineering: Challenges and Practices by Zoran Stojanovic and Ajantha Dahanayake, eds., Idea Group, 2005, ISBN 1-59140-427-4, 413 pp., US\$69.95.
One big challenge facing Web services adoption is that successfully implementing and deploying a service-oriented project means changing our approach to the project as a whole. Service-oriented Software System Engineering: Challenges and Practices is a collection of papers that focuses on new methods of managing, running, and implementing a service-oriented project. Both the authors and the editors convey how to bridge the old and the new methodologies.
Several authors discuss CORBA and the Component Object Model to explain the rationale behind a service. Both technologies use Component Bases Development techniques and methodologies. The book doesn't explain protocols and standards—other than semantics such as UML, software engineering has no associated protocols. Instead, the chapters (one paper each) focus on techniques, methods, concepts, and best practices.
The book begins by simply talking about what it means to have a process that considers service orientation's differences and overall trends. After the basics, the text focuses on the software engineering aspects, tools, and techniques that are part of Web services. Various authors discuss UML and model-driven architecture, specifically proposed extensions to UML (see the chapters "UniFrame—A Unified Framework for Developing Service-oriented, Component-based Distributed Software Systems" and "Service-oriented Computing and the Model-driven Architecture").
Modeling and architecture lead to design and, more important, design patterns for service orientation. The chapter on service patterns for enterprise information systems closes the loop on Web services' engineering aspects. The patterns discussed are ones that you're probably familiar with from Erich Gamma's book, with a focus on service orientation. A must-read paper for any architect!
The chapters become more interesting when they focus on software engineering and specific aspects of Web services, such as security and mobility. We've all heard of Web services security challenges, but not in regard to implementation techniques and practices. Service orientation takes on a whole new challenge when mobility and agents come into play. The editors include an introductory paper at the beginning of the section, focusing on mobile services' engineering aspects.
The last three chapters are case studies that consider the topics in the other chapters, including implementing an online security system, in which the authors build a secure Web-services Web site, referring to the techniques and tools that the book introduced.
Not many books cover service orientation's engineering aspects, so this text is especially valuable. The papers demonstrate practical and useful techniques for software engineers and architects designing and implementing complex Web services solutions.
Art Sedighi is a senior consulting engineer at Data-Synapse and a freelance writer. Contact him at sediga@alum.rpi.edu; www.artsedighi.com.