List of Return Codes for SOA

November 18, 2009

List of Return Codes

I wrote earlier about the idea of using consistent error codes for reusable assets. As a follow up, here is a document with a list of reusable return codes that can be used when building service capabilities as part of SOA initiatives. They are categorized into:

  • request processing
  • data processing
  • dependency access
  • transactions

This isn’t an exhaustive list by any means but can get you started in terms of achieving consistency across services and projects.The service consumer can use the return code to understand the service provider’s response. This consistent, uniform categorization of return codes can help you reuse error handlers (e.g. handle a particular error in the same way regardless of which service capability raised it).  It will also help with production support and troubleshooting – less learning curve for support staff and developers to categorize errors at runtime.

Note: The return code derived based on errors need not necessarily be the return code sent back to the service consumer. It is entirely possible that you return a friendly error to the consumer and a detailed error to production support.

Are there additional ones to include in this list?

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Keeping WSDLs Modular and Simpler to Maintain

June 5, 2009

Here are few tips for keeping Web Services Description Language (WSDL) documents modular and simpler to maintain:

  • Import XML schemas for elements referenced by method contracts. Do not embed types/elements into the WSDL – because you will have multiple schema definitions that can quickly go out of synch. Organize XML schemas using a standard directory structure and host them externally. You can use the schemaLocation attribute to point to the physical location of the schema.
  • Follow a consistent naming convention for WSDL namespaces. I use<DomainName>/<ServiceName>_<ServiceVersion&gt;. This will make it easier for consumers when they generate service proxies and bindings.
  • Use WSDL templates with variables for specifying transport specific information (e.g. when using HTTP you can have a variable for service endpoint host, port, etc. Alternatively, when using Java Message Service (JMS) you can specify queue name, user name, password etc.). Using an ant script with property files you can replace these variables with service specific values.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: