Our sister site, TSS.com has got a spirited discussion going about WSDLs, REST, XML, JSON and Java APIs. Some are arguing “the best WSDL is no WSDL at all.”

I recently ran into an architect who was trying to wrap his head around SOA. He had sorted out most of it, but one thing was gnawing at him: what makes for a good WSDL?

Obviously that can change dependent on the service in question, but it dawned on me that a good set of examples would be in order. Thomas Erl has listed some essentials for what should be in a service description:

• the service endpoint
• each service operation
• every input and output message supported by each operation
• the data representation model of each message’s contents
• rules and characteristics of the service and its operations

That’s a great starting point, but it’s no substitute for the finished product. Fortunately there is a reservoir of WSDL expertise out there, namely you, or at least some of you who are reading this. What we’re looking for is your WSDL examples. Send them to us and we’ll publish them so that other architects and developers will have some concrete examples to reference.

It can be WSDL 2.0 or WSDL 1.1. If some of you have tried to use WADL for REST-based services, we’re interested in that as well. You should include an explainer of why you made the choices you did and any key takeaways for those who are referencing your example. What we’ll do is create a specific spot on the SearchSOA.com site for all the submissions, a working WSDL resource center.

Enough people are doing this that we ought to provide them with guidance on how to do it well. You can e-mail submissions directly to mmeehan@techtarget.com.

I was talking with Wayne Ariola, Parasoft’s vice president of strategy and corporate development, last week about the concept of SOA quality. Parasoft’s been using the term “SOA quality” as part of the latest rollout of its SOAtest product, which now is able to query UDDI registries so that WSDL verification tests can be performed at the time they’re published.

Quality is a key element in software development and it should go without saying that the more business that gets pumped through Web services, the more important it will be to have a good QA process in place for those services. Noting that “lack of central visibility” is normal in the classic software development lifecyle, Ariola listed what he thinks are key elements in that SOA quality process.

1. SOA necessitates centralization, a role played by the registry/repository. He argued that stovepipes become inevitable without it.

2. A health check needs to be performed to make sure the asset meets the requirements. Among the potential requirements, he highlighted defining the asset’s consistency and the boundaries for its reuse.

3. You need a convenient way to emulate the service. Taking down a component could cause unintended chaos once it’s being leveraged in multiple places. Testing and changes are best handled in the virtual arena in order to avoid that trap.

4. If a component or service is going to reused, the testing expectations need to be made readily available so that different orchestration scenarios can be vetted. In general the testing environment should be as open and accessible as possible.
5. Make sure you fully and accurately define your SLAs, future users of that service will need to understand the true behavior expectations behind it.

6. Be prepared to do some sort of compliance monitoring in order to make sure your services are being properly used.