Beautiful Code [70]
Different locking strategies (such as thread-level or process-level recursive mutex, nonrecursive mutex, readers/writer lock, null mutex, etc.) that developers can use to serialize access to resources, such as a count of the number of requests, shared by multiple threads.
Different log record formats that can be transmitted from client to server. Once received by the server, the log records can be handled in different ways—e.g., printed to console, stored to a single file, or even one file per client to maximize parallel writes to disk.
It is relatively straightforward to implement any one of these combinations, such as running one thread per connection-logging server using socket-based IPC and a thread-level nonrecursive mutex. A one-size-fits-all solution, however, is inadequate to meet the needs of all logging services because different customer requirements and different operating environments can have significantly different impacts on time/space trade-offs, cost, and schedule. A key challenge is therefore to design a configurable logging server that is easily extensible to meet new needs with a minimum of effort.
At the heart of the solution to this challenge is a thorough understanding of the patterns and associated design techniques needed to develop OO frameworks that efficiently:
Capture common structure and behavior in base classes and generic classes
Enable selective customization of behavior via subclasses and by providing concrete parameters to generic classes
Figure 26-2 illustrates the design of an OO logging server framework that realizes these goals. The core of this design is the Logging_Server class, which defines the common structure and functionality for the logging server via the use of:
C++ parameterized types, which allow developers to defer the selection of data types used in generic classes or functions until their point of instantiation
The Template Method pattern, which defines the skeleton of an algorithm, delegating individual steps to methods that may be overridden by subclasses
The Wrapper Facade pattern, which encapsulates non-object-oriented APIs and data within type-safe object-oriented classes
Subclasses and concrete instantiations of Logging_Server refine this common reusable architecture to customize variable steps in the logging server behavior by selecting desired IPC mechanisms, concurrency models, and locking strategies. The Logging_Server is thus a product-line architecture [#]that defines an integrated set of classes that collaborate to define a reusable design for a family of related logging servers.
[#]Software Product Lines: Practices and Patterns, Paul Clements and Linda Northrop, Addison-Wesley, 2001.
Figure 26-2. Object-oriented design for the logging server framework
The remainder of this chapter is organized as follows. The next section describes the OO design of the logging server framework, exploring its architecture and the forces that influence the design of the OO framework to illustrate why we selected certain patterns and language features, as well as summarizing alternative approaches that we rejected for various reasons. Two further sections present several C++ sequential programming instantiations of the logging server framework and of concurrent programming instantiations of this framework. We conclude by summarizing the beauty of the OO software concepts and techniques in this chapter.
Integrating Business Partners the RESTful Way > Project Background
27. Integrating Business Partners the RESTful Way
Andrew Patzer
A few years back, when i was a consultant, I went through a period of a year or two when it seemed that every client I spoke with was absolutely certain he needed a Web Services solution for his business. Of course, not many of my clients actually understood what that meant or the reasons why they might need that kind of architecture, but since they kept hearing about Web Services on the