Client Integration Mini-Checklist for Services

May 27, 2012

Working with clients who are consuming your services? Here is a mini-checklist of questions to ask:

  1. While executing request/reply on the service interface is there a timeout value set on the call?
  2. Is there code/logic to handle SOAP Faults /system exceptions when invoking the service?
  3. Is building service header separated from the payload? This will facilitate reuse across services that share common header parameters
  4. If there are certain error codes that the calling code can handle, is there logic for each of them?
  5. Is the physical end point information (URL string for HTTP, Queue connection and name for MQ/EMS) stored in an external configuration file?
  6. Is UTF-8 encoding used while sending XML requests to the service i.e. by making use of platform-specific UTF encoding objects?
  7. If using form-encoding are unsafe characters such as ‘&’, ‘+’, ‘@’ escaped using appropriate %xx (hexadecimal) values?
  8. While processing the service response is the logic for parsing/processing SOAP and service-specific headers decoupled from processing the business data elements?
  9. Is the entire request/reply operation – invocation and response handling logic – encapsulated into its own class or method call?
  10. While performing testing, is the appropriate testing environment URL/queue manager being used?
  11. Is a valid correlation id being used in the service request? This is very essential for aynchronous request/reply over JMS (JMS Header) or HTTP (callback handler)

What I’m Reading

May 26, 2012

Reading a couple of patterns books:

Service Design Patterns

Patterns for Fault Tolerant Software


Every Project Is An Opportunity

May 26, 2012

Succeed with systematic reuse by pursuing opportunities across every project. Every single project. Explore synergies across projects to not only identify new reusable components but also update existing ones. Here are a few common areas that yield reusable components:

  • Data access and updates – is there a single suite of APIs for managing core data? are there redundant implementations, overlapping calls, across projects?
  • Domain rules – are domain rules organized in a clear and well maintainable manner? or are they split across layers and implemented using multiple technologies/strategies?
  • Processing templates – are there a common set of steps of relevance in your domain? are these steps always executed in a consistent manner? is there an opportunity to Templatize the steps?
  • Config management – how are applications managing configuration properties? how do they enable properties for a particular environment? how does an application get only properties that it is entitled to?

The above isn’t exhaustive but gives you a flavor for the kinds of questions that will drive opportunities for systematic reuse


%d bloggers like this: