Enabling Self-Service for Easier Service Integrations

May 31, 2011

There are a number of benefits with exposing services and enabling application to application integration through them. However, when the number of services increase, the support and integration effort involved goes up as well – moving to a self-service model for service integrations makes it simpler and faster for clients, cheaper and more reliable for the service provider. Here are a few tips to make this happen:

  • Ensure all service interfaces are URL accessible – e.g. WSDL, associated XSD schemas etc. are hosted in a consistent structure that tools like WSDL2Java or wsdl.exe can point to and generate client side code
  • Templatize the WSDL and XSD to capture client-specific information such as application identifier and name (e.g. if your service interface mandates these values, you can default them to use the appropriate client-specific value).
  • Capture authentication and authorization requirements and similar to above point, generate code to set appropriate message headers (e.g. SOAP Header or JMS Header as appropriate) – this will be common to most clients except the exact credentials will vary
  • Keep documentation up to date as part of the build and deployment process – e.g. if you are deploying services to a client facing environment (e.g. integration testing), deploy documentation as well as part of the exercise. For instance, generate javadoc style XML schema documentation and maven site-deploy target can be leveraged to upload the generated artifacts to a web application.
  • Capture and maintain service metadata – this metadata should not only cover functional aspects but non-functional attributes as well. For instance, if your service cannot honor a response time requirement, it is critical to know that during the integration effort and not after the client has migrated their code to a production environment. This could translate to a service enhancement or an alternate integration approach altogether

This is by no means an exhaustive list but meant to give a window into the opportunities and benefits that self-service can provide.

Software Reuse Quick Tip #28

May 2, 2011

Distribute Configuration For Various Testing Needs

If a reusable component requires runtime configuration (properties, XML files etc.) alongside the binaries, make it easier for the asset’s consumer to integrate these artifacts in their tests. For instance, using maven assembly the configuration files can be packaged as a jar file and added in the test scope. This will make the configuration available in the classpath when executing unit tests in the module. The configuration can be packaged per environment and using the dependency classifier the appropriate artifact can be used. This approach works for integration and performance testing as well – for instance, performance tests might use a different set of values for the configuration artifacts since they execute in a dedicated environment.

%d bloggers like this: