Chapter 14: Exploring the Faux Implementation Pattern

Overview

The past several chapters have assumed that a client of the EventService Web Service will deploy their subscriber to a full Web Service environment to subscribe to a few events. In many ways, this is like using a mainframe to play your MP3 files. Not only do you waste the full potential of the environment, you introduce a whole host of unnecessary issues, especially if you have a small client. In the case study, for example, you deploy Apache Tomcat and the Apache Axis environment to subscribe to an event. You then build and deploy a Web Service that uses the Connector pattern from Chapter 13, "Exploring the Physical Tiers Pattern," to ensure that the application can receive events from the client-side Web tier . This is a lot of work for little return.

A better approach for your client may be to find a way to leverage the strict Web Service interface and the Simple Object Access Protocol (SOAP) definition, but in a lighter manner. For example, you can leverage the SOAP definition of messages sent from the EventService Web Service to a Subscriber to build your own Web Service environment without Apache Axis. This environment can receive and parse a single event from an event service, but it leaves out flexibility in exchange for simplicity and a smaller footprint. In a sense, you can fake out the EventService Web Service by simply reading data off a socket and avoiding Apache Axis. This lightweight technique allows you to toss away the client-side Web Service environment and simplify client install and deployment. This approach of implementing a strict interface in a way that the architect or designer may not have expected is the Faux Implementation pattern.

The concept of a faux implementation is not new to programmers. Given a well-defined interface and behavior specification, programmers build faux implementations all the time. In some cases, one could even argue that there is no such thing as a faux implementation. In this argument, as long as the expected interface and behavior appears, there is no reason to consider the implementation a fake.

Web Service environments can use the Faux Implementation pattern in several places:

Building tests You use the Faux Implementation pattern to build tests for your service implementations. This practice is especially important for implementations that depend on live, external Web Services. You do not want to test your real, external service without first trying your service implementation on a mocked-up, fake version of the external Web Service that you write. With this technique, you can get rid of the worst of your bugs before you even try to use the external Web Service.

Lightening the burden If you use the Web Service “based Publish/ Subscribe pattern and the Observer pattern that require a Web Service subscriber, you should expect that consumers of your events will use the Faux Implementation pattern. This pattern lightens the burden on the clients who do not want to deploy a full Web Service environment, such as Apache Axis, for their simple application.

The Faux Implementation pattern is important in testing a system, maintaining a system over generations of software and hardware, and allowing you to think outside of the box for implementing clients that must adhere to a particular interface. This chapter discusses some of the common uses of the Faux Implementation pattern to show you its diversity, and then the chapter discusses its structure and gives a Web Service implementation of this pattern.

Note  

Faux implementation has its roots in the Interface pattern, used throughout object-oriented computing. Formal treatments of the Faux Implementation pattern are becoming available, particularly as extreme programming becomes more common. Extreme programming often uses the Faux Implementation pattern as a mechanism for building tests for a component and running the tests before a component is completed. The Faux Implementation pattern allows developers to explore how their real implementation should behave before they execute the actual implementation.