SOA tips

David Pallman from Neudesic has been blogging a set of SOA tips that most developers should consider as part of their SOA projects (via Sam Gentile). Although the posts are titled WCF tips some of the principles are relevant to any Web Services/SOA implementation. I've decided to provide a first iteration with some complements to David's thoughts.

Consider versioning

Tip: When designing service contracts keep in mind that contracts are not static entities and are subject to change.

Rationale: Service contracts are dynamic entities that evolve during over time. Designing for versioning facilitates the evolution of the services without breaking the existing clients

What happens if I don't: Most likely you will find yourself in a situation in which you have to affect some of your consumers in order to deploy new versions of the services.

Leverage consumer-driven contracts (related with the above)

Tip: Distributed different versions of contracts to specific client based on the functionality they are looking to leverage.

Rationale: The classic approach to service orientation states that services implement a one or multiple static contracts that are used by all the consumers. However, this approach assumes that all consumers will use the same interface for interacting with the service weather in reality they might only be interested in using a set of specific features. Distributing specific contracts to consumers facilitates important aspects of SOA such as versioning. This approach is known as consumer driven contracts.

What happen if I don't: All the consumers will have the same interface to communicate with the services and consequently the versioning strategy becomes even more important.

Design interoperable contracts

Tip: Interoperability is a key component of any successful SOA history. When designing service contracts, make sure that the contracts can be consumed using heterogeneous technologies.

Rationale: At this point we all know that XML and objects don't match very well. The first step of achieving interoperability is making sure that service, data and message contracts can be interpreted by the consumer technology.

What happens if I don't: You are limiting the functionality of the service to the consumers that can interoperate with it.

Design code first- contract aware

Tip: Apply a code first approach to maximize the productivity of your development team and a contract first approach to maximize interoperability.

Rationale: The debate between contract-first and code-first has been around for years. The causes of the problem resides in, surprise surprise, the fact that XML and object don't match very well. I think the correct answer for real world applications is a combination of both approaches. Only a few people know WSDL well enough to design contract-first services that also have an optimal representation in the object oriented language in which the service is implemented. Similarly, if you only design code-first services most likely the result WSDL might be suboptimal. In my last article for SOA World you can find more details about this technique.

What happens if I don't: A poor contract design will impact everything in your SOA application.

Don't use transaction across multiple services.

Tip: Transactions across multiple services is one of the aspects that can break the scalability of SOA applications. Services can perform transactional operations but expanding the transaction across multiple services is not a recommended practice for most real world applications.

Rationale: There are several WS-* protocols that can be used to implement either atomic or long running transactions. After a few years debating, the vendors seems to agree that the combination of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity is the way to tackle this problem. However, only WCF and Sun WSIT provide solid implementations of WS-AT although there are other emerging implementations such as Axis2. This means that right now is unlikely to achieve high levels of interoperability when using any of those protocols. Most  important, distributed transactions across services are always resource-expensive operations that limit the loosely coupling and scalability of SOA applications

What happens if I don't: Good luck with that.

 Leverage WS-* protocols on the right way

Tip: Make sure to apply the correct WS-* protocol to the specific scenario you are trying to implement.

Rationale: Nowadays the vendors have produced more than one hundred WS-* specifications, several versions of the same protocol and around a dozen of implementations. Leveraging the right WS-* protocol for a specific scenario is a combination of both understanding the protocol as well as the specific implementation you are using. The use of WS-* protocols directly impact important SOA aspects such as versioning and interoperability, governance, etc.

What happens if I don't: Applying the incorrect WS-* protocols can affect the complete behavior of a SOA solution not to mention cost to maintenance and versioning.

I will follow up this post with more tips specific related to the use of WS-* protocols.