The example provided in this section demonstrates the mechanics of an adapter service implementation by making full use of design-time and runtime interactions while emulating interactions with an external adapter resource.

The example adapter service simulates a simple database update service, allowing the user of the adapter to select table and column names that create the runtime signature for the resulting adapter service node. Table and column names are provided from hard-coded lists in a mock-connection implementation, as if the data were actually retrieved from the adapter resource. The example also includes interactions with the pipeline based on a dynamic service signature. The example is self-contained; it does not actually interact with any external resource.

The model for adapter services forces syntactic and semantic coupling of code in different methods and classes. Because of this, it might be difficult to understand the process of creating an adapter service by looking at the classes (or even methods) as a unit of work in the development process. For example, adding a metadata parameter can require updating two or more methods in the Adapter Service implementation class, updating up to three methods in the associated connection classes, and adding two entries in the resource bundle. Thus, this section approaches the implementation of a service as a series of activities that you perform, each of which may traverse multiple methods and classes.

This section provides examples of the resulting code, and refers to specific lines.

The tasks for creating an adapter service are as follows: