What is different for the developer when building an SOA solution?

This has always perplexed me. How do I explain the signifigance of SOA to a developer? In essence, it comes down to design specifications and standards such that they are encouraged (forced) to code in a certain fashion. I encourage you to attend Online developer days to hear from a developer, Todd Mackey, about his perspective. He will be comparing the tenant/principles of SOA to those held dear by the OO&AD crowd. The more things change, the more they stay the same.

There are some things that are new and even scare the most agile of architects. They include:

1. Coding for the service to behave in test and production mode, via a metadata flag
2. Event enable the solution such that high level interfaces can be portrayed in WSDL if you decided later that WS was a good idea after all.
3. Expect changing requirements
4. Build for change because it will.

Thats all for now. I will post the work from Todd after he delivers it this Friday.

Later,
Murray
The SOA Integration Ninja