img
Home > Candidate Patterns > Relaxed Service Implementation

Relaxed Service Implementation

How can we build a service that has a standardized WSDL but still can accept input data of poor quality and perform its tasks?

Problem

Standardized service contracts are a great way to let consumers and services interact and still be loosely coupled. A popular way to describe contracts is WSDL definitions. WSDL definitions also make life easier for client developers in that it allows them generate the code necessary to actually call the services. Sometimes though, the auto-generation doesn't work properly. If you are using outdated technology there may be no support for auto generating clients. Another reason is that different technical platforms interpret the definitions differently. Due to these reasons a service might receive input data of poor quality.

Solution

Publish a standardized WSDL but allow any kind of message to get through the message processing layer. Let the underlying implementation inspect the message and act according to the contents of the message.

Application

Schema validation is moved to the underlying service logic or a service agent. When schema validation fails parsing techniques, e.g. Xpath, are used to further process the incoming message.

Impacts

Requires additional development effort, might affect performance and security.

Status

Under Review

Contributors

Herbjorn Wilhelmsen

Problem

When building services as Web services, standardized WSDL definitions make life easier for client developers in that it allows them to generate the code necessary to actually call the services. However, legacy systems don't always give you that option and producing code by hand for calling a service may be both tedious and error prone - especially when complex XML schemas and/or multiple XML schemas are involved. Even state of the art languages and tools sometimes generate incompatible code due to differences between the implementation of standard datatypes and serialization that exists between different technology platforms. In these situations the service might receive calls with invalid messages and further development efforts will be necessary from the consumer side if the service is to be used.

Another unrelated problem is that not all service consumers can update their clients when an old version of a service is taken out of production. These consumers will experience problems when sending messages to the service that are compliant with the old XML schemas.

Solution

A standardized WSDL definition is published so that client developers may generate code. When a new version is developed, the existing WSDL definition is replaced by a new WSDL definition. By doing this, new consumers of the service will always attempt to use the service in accordance with the newest WSDL definition. An alternative is to publish successive versions of the WSDL in parrallel with distinct URIs. The advantage of this is that you can point new consumers a the WSDL located at the new URI while at the same time allowing existing consumers to rebuild existing clients without the risk of breaking their implementations due to new requirements or data-formats introduced in the new WSDL.

The message processing layer of the service accepts any message from the consumer; the underlying implementation inspects the message to see what it contains and acts accordingly. If the message conforms to any of the message schemas (current or previous) it will validate using schema validation techniques; the answer - if required - is formatted with the schema version that the consumer expects. If the message doesn' comply with any relevant schema it can be parsed to search for content that is meaningful to the service and the service can then make an attempt at performing the task that the consumer wanted the service to perform.

Application

Schema validation is moved to the underlying service logic or a service agent. When schema validation fails parsing techniques, e.g. Xpath, are used to further process the incoming message.

Impacts

The addition of schema validation and parsing adds additional development effort as this is normally handled by standard message processing layers. Inspecting messages, attempting validation and parsing messages adds performance overhead. Governance may become more difficult due to the decentralization of validation and the fact that the codebase will grow in comparison to stricter service implementations relying on standardized message processing layers to validate incoming messages. The application of this pattern could even create an opportunity for malicious users to send dangerous content that exploits the message parsing functionality to trigger unwanted behavior.

Additionally, parsing large messages can consume large amounts of resources potentially providing the opportunity for a denial of service attack: In effect forcing the service to spend resources on parsing messages instead of servicing requests. The security risks could be handled by setting limits on maximum message size, nesting depth or the time spent on parsing before the parser aborts and / or moving validation and parsing logic to other services or service agents.

Extra validation and parsing might of course affect performance adversely.

Relationships

With Relaxed Service Implementation the validation logic/parsing should ideally be implemented using a Service Agent or a Service Façade. In that respect it is similar to Validation Abstraction but there is one big difference: A WSDL definition with detailed policy and validation information can be published. The contract is not fully decoupled from the service implementation as required by Decoupled Contract and Relaxed Service Implementation can be used together with Validation Abstraction.

When applying this pattern with the aim of supporting multiple versions of a technical service contract Concurrent Contracts is a viable alternative.

Contributor Notes

The name of this pattern was inspired by RESTful services. REST doesn' have contracts in the same way that SOAP/WSDL services do. Some RESTful services are even referred to as POX (Plain Old XML) services as these services have open message formats with only one restriction: Messages are sent using XML. These services need to inspect incoming message to see what kind of message the consumer sent, alternatively parse the XML before performing any other tasks.

This pattern may be implemented in programming languages like .Net and Java, but also with intermediation technologies such as XML appliances and ESBs.

- Herbjorn Wilhelmsen