Tech Ed - Patterns & anti patterns with SOA

We went to this lecture by Ron Jacobs who is fast becoming one of our favorite speakers, he is really interesting and engaging :)

Basically he was saying that using SOA technologies does not guarantee success and there is never a right answer coz as usual everything has pros & cons.

The goal of this is to have a friction free interaction between systems so there are no problems such as different file types or transportation methods.

He made an interesting point that SOA is not a noun; it’s a style of architecture which emphasizes on standard based communication.

He highlighted that tightly coupled systems defiantly have there place as if everything is lose its slow as hell :)

We must aim when designing SOA for a good set of explicit behaviors over implicit where the client has to ‘try things out’ to find out how things work.

He told us to think of service granularity at a business process level and that each of these have their interface.

As all boundaries should be explicit he gave a great metaphor of an explicit boundary being an international boarder between countries and that you know where they are clear and when you cross them you are not in control of anything. So when we are not in control of things such as server or config we know we have an explicit international boundary that will be an interface to a service. As with international borders we need to think carefully about how many we have and how we control them as they are expensive and problematic if they are not controlled. For internal business boundaries you can do anything you want and this includes tightly coupled objects to improve performance.

He spoke about Anti Patterns (patterns that show how to do things wrong so that you can make sure you don’t do the same). He discussed the following:

• CRUDy interface - when you create an interface with simple CRUD commands on it when this should be a full business process with logic.
• Enumeration - should not have enumeration commands such getnext() that go against the atomic nature of a service and causes the server to hold a big amount of data whilst a client navigates it.
• Chatty interface - bad when a service offers lots of methods that must be called in a sequence of calls by the client to carry out an operation. The client may call one command but never get to call any others and the service is left in an inconsistent state. We should design larger web service method and do all the steps in there.
• Loosy Goosy :) - where a service tries to be uber generic with a single command that takes a lump of xml and returns a lump of xml and uses a word doc to define the contract. This is hard to test and hard for the client to use as it may implicitly change. Sometimes this is done to stop versioning problems. Now this is easier with serialization improvements in .NET 2.0, but the message is to “receive liberally and send explicitly”.

He explained that the best way to start a SOA design is to start with the process and understand it. Then create the contract by defining the messages, operations and by group them.
Use portable types - returning datasets is not good, this can be used internally but for external service we should decouple internal and external objects by unloading one internal object into another external object.

His advice is to think of moving bits of paper not calling methods.

Ron has some really good web casts that he has shown at the event we can take a look over at http://www.arcast.net/