Service APIs Client-Service Interactions Request and Response Management Service Implementation Service Infrastructures Service Evolution

Request Mapper

A web service receives XML. The service owner has little to no control over the design of request structures.
How can a service process data from requests that are structurally different yet semantically equivalent?
In an ideal scenario, one organization controls the design of all message structures that are exchanged, and there is only one version of each message. Unfortunately, this scenario rarely occurs in the real world because external departments or businesses with competing or divergent agendas usually don't agree on the design of these structures. The service developer may therefore be compelled to accept multiple requests that are semantically equivalent (i.e. used for the same purpose) yet are structurally different. These developers could write distinct services for each request variation, but this inevitably leads to maintenance problems. Service developers might therefore decide to forward each request to a service or background process that transforms each request to a common structure before invoking the requisite logic. This, however, increases complexity and latency, and makes it much harder for the client to acquire a response. In an attempt to mitigate these issues, service developers could include the transformation logic directly within the service, but this tends to make the service harder to read and maintain.
Create specialized classes that leverage structure-specific APIs to target and move select portions of requests directly to domain layer entities or to a common set of intermediate objects that can be used as input arguments to such entities. Load a particular mapper based on key content found in the request.
Request Mapper: Create specialized classes that leverage structure-specific APIs to target and move select portions of requests directly to domain layer entities or to a common set of intermediate objects that can be used as input arguments to such entities.  Load a particular mapper based on key content found in the request.
Request Mappers are a specialization of the Mapper pattern. They are used to isolate request structures from domain layer entities and enable each to evolve independently. Request Mappers are responsible for parsing data from requests and moving this data into domain entities like Table Modules, objects in a Domain Model, or into intermediate structures that can be used as inputs to such entities.
Request Mappers may be explicitly selected by the service implementation code. Alternatively, the service may delegate this responsibility to a Factory Method or an Inversion of Control container. Once the service acquires a mapper interface, it invokes one or more methods on the interface in order to initiate parsing and to acquire the resultant domain entities or intermediate objects. Request Mappers may select request data by using "traditional" imperative statements through languages like C# or Java, dynamic languages (e.g. Javascript), or declarative mechanisms like XPath and XSLT.