In the spirit of both the Gang of Four’s Design Patterns book and the SOA Patterns book/site, I’m going to try to document a couple different SOA Patterns that I’ve found useful, but haven’t seen documented anywhere else. This is a work in progress, and as always, feedback on theses patterns is appreciated.
Service Ping
Intent
To test a client configuration to a known service endpoint. Ping allows for the testing of the communication channel between a client and a service endpoint, without testing of the service implementation.
Motivation
When building and deploying services it is easy to build integration tests that will test both the configuration of the service and the implementation of the service, but it is just as important to test the service implementation and the service communication channel configuration in isolation. By isolating what is under test using a Ping, we reduce the number of variables that may affect the results so we can derive useful information on whether the unit is actually correct. Since many service frameworks (like WCF) allow for the communication channel to be configured using a configuration file the service configuration can easily be changed without updating the service implementation code. Since these configuration files are typically part of the deployment process, these Ping tests can be used to test the service after deployment.
Applicability
Use the Ping Pattern when:
- You want to test just a service endpoint’s communication channel configuration to a known client configuration.
- You want to test that a service endpoint is available and ready to accept requests
Structure
The Ping pattern can be implemented 2 ways
- Adding a Ping Method to the service that has no parameters and an empty response.
- Adding a Ping Header to the request message header and sends back an empty response
Participants
- Client
- Defines the expected communications channel configuration, sends the Ping Request and expects an empty response
- Service Endpoint
- Defines the location of the service and a specific communication configuration.
- Service Ping Behavior
- Intercepts the Ping request message before calling the service’s implementation, and returns an empty response.
Collaboration
The client sends a Ping Request to the Service Endpoint and expects an empty response to signify that the request was received.
Consequences
The Ping Method and Ping Header have different trade-offs.
Ping Method
- Pros
- Gives a simple, easy to use, and known, method to call when implementing the Ping Pattern.
- Easier to secure, since most services secure at the method level.
- Does not require a request body
- Cons
- Adds an extra method to a service’s contract that is not part of the service’s implementation.
- If the service is unable to intercept the ping, then the service implementation could be executed.
Ping Header
- Pros
- Does not change the service’s contract
- Tests security for the method that is used as part of the Ping Request.
- Cons
- Does not explicitly indicate which method for a service to call.
- May require a request body.
Implementation
The Service Ping pattern is implemented by way of adding a Service Ping Behavior to the Service. The Service Ping Behavior should be intercept the request just before the Service Implementation is called, but after the request is validated by security.
Known Uses
The Tellago Studio’s Product, SO-Aware implements the Ping Pattern, using the Ping Header implementation. SO-Aware enables an enterprise to store their service configurations in a service repository, which makes it easy for the enterprise to monitor and manage service configurations without having to access the servers the services are deployed on. Any changes made to the service endpoint configuration can easily be regression tested using the Ping Pattern tests, immediately verifying that the changes will not adversely affect clients.
Related Patterns