You can implement a service factory in many ways. Most service factory implementations are highly dependent on the application and the particular type of service that the factory selects. Follow these tips when implementing a service factory:
Determine early whether you need a flexible selection policy or whether your policy just needs to locate any available service: In the former case, use a selection policy similar to those presented in San Francisco Design Patterns: Blueprints for Business Software (Addison- Wesley, 2000). In the latter case, keep the selection policy simple and contained so that you can replace it later if the need arises.
If there are a stable number of businesses that the company deals with to fulfill a particular business process, allow an administrator to enter the business names and cache the binding information for the service: This scenario will be extremely common. Consider the shippers you support. It is highly unlikely that a customer expects any shipper other than the top three, so you might as well hard-code this information into your Service Factory pattern implementation. Maintaining the Service Factory pattern to isolate this decision and this point of variability in your application is critical because the supported shippers could change over time.
Additional interactions with services (after the initial location) may be necessary to determine if a service meets the application's criteria: Directories simply do not contain the current state of a business object's properties, such as how many pounds of coffee a business has in its warehouse.
Cache information whenever possible in a service factory implementation: The performance of a factory implementation will probably be poor because of the high dependence on network- intensive operations. The directory lookup is a potential bottleneck, and service selection criteria often require interactions with each service to determine if the service is a sufficient match for the application. These secondary interactions will be necessary to determine the best match to your application beyond the first-class directory information. For example, if you locate two potential shippers, your customer may want the lowest shipping rate. Additional interactions are necessary with the Web Service implementations themselves because this information does not reside in the service directory. By the time you have chosen a suitable service implementation, you may have tens or hundreds of network operations to conduct.
The Service Factory pattern is also a suitable abstraction for building a dynamic reference to a single Web Service: For example, consider the case that you know enough information about a business to locate the only possible service implementation in UDDI. The service factory is still a good way to abstract out the location and development of the service's adapter from the mainline code. For this reason, you can use the service factory to apply to a single service reference as well as multiple service references that need to be whittled down to a single service for the main program.
If you allow the application to specify service criteria to the service factory, do not expose the directory interface to the application: Choosing one directory Application Programming Interface (API) should not imply that this API is either stable or long lived. Web Services will be in a state of change for several years to come, and APIs will always evolve . Coupling the application to the directory interface is a poor choice.