Beautiful Code [300]
Labor-Saving Architecture: An Object-Oriented Framework for Networked Software > Conclusion
26.5. Conclusion
The logging server application presented in this chapter provides a digestible but realistic vehicle for showing how to apply OO design/programming techniques, patterns, and frameworks to implementation software for networked applications. In particular, our OO framework demonstrates a number of beautiful design elements, ranging from abstract design to concrete elements in the implementations of the different concurrency models. Our design also uses C++ features, such as templates and virtual functions, in conjunction with design patterns, such as Wrapper Facade and the Template Method, to create a family of logging servers that is portable, reusable, flexible, and extensible.
The Template Method pattern in the Logging_Server base class's run( ) method allowed us to define common steps in a logging server, deferring specialization of individual steps of its operation to hook methods in derived classes. While this pattern helped factor out common steps into the base class, it did not adequately address all our required points of variability, such as synchronization and IPC mechanisms, For these remaining dimensions, therefore, we used the Wrapper Facade pattern to hide semantic and syntactic differences, ultimately making use of these dimensions entirely orthogonal to the implementation of individual concurrency models. This design allowed us to use parameterized classes to address these dimensions of variability, which increased the flexibility of our framework without affecting its performance adversely.
Finally, our individual implementations of concurrency models, such as thread-per-connection and process-per-connection, used wrapper facades to make their implementations more elegant and portable. The end result was a labor-saving software architecture that enabled developers to reuse common design and programming artifacts, as well as provide a means to encapsulate variabilities in a common, parameterizable way.
A concrete implementation of this logging server framework may be found at http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/examples/Beautiful_Code, and in the ACE distribution in the file ACE_wrappers/examples/Beautiful_Code.
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 Internet, in magazines, and at trade shows, they figured they'd better get on the bus before it was too late.
Don't get me wrong. I'm not against Web Services. I'm just not a big fan of making technical decisions based solely on whatever happens to be in style at the moment. This chapter will address some of the reasons for using a Web Services architecture, as well as explore some of the options to consider when integrating systems with the outside world.
In this chapter, I'll walk you through a real-life project that involves exposing a set of services to a business partner, and discuss some design choices that were made along the way. Technologies that were used included Java (J2EE), XML, the Rosettanet E-Business protocol, and a function library used to communicate with a program running on an AS/400 system. I will also cover the use of interfaces and the factory design pattern as I show how I made the system extensible for future distributors who may