SOA and RL(Real Life)

WS-* is probably the most popular SOA base.
But if you want real improvements on the base level focus on decoupled components!
Decoupled is the thing that will keep your code clean and easy.

Of course this is not real life where SOA = WS. SOAP(Simple Object Access Protocol) please remove S out of SOAP or at least change it to something like OAP(Object Access Protocol). Have you tried to understand all the specs for WS? XML is easy and readable, XML Schemas introduce complexity(but NP), but WS has so many elements that I get lost in them. WS is slow, WS is complex, WS is not easy.

Writing decoupled components implies such techniques as coding against interfaces, breaking down components into logically separate modules(not just refactoring classes) and other decoupling methods.
When you look at 3 tier architectures, MVC and IoC(Dependency injection) you will see that they are decoupled into logical(not everywhere) parts.
When not to go berserk and decouple everything from everything example: Accounting logic should not be decoupled from Tax application logic(most of the times), file storage logic is logically with file attribute logic.
What you see that is not core part(and in "core" I mean that logic that is bound to the process that invokes it) is usually should be moved out of the code and expose it as a "service"(no reference to SOA or WS).

The best thing that works for me is just imagining thing in reality.
How would you use accounting services?

1. You would go to an accountant and request to calculate your taxes. You do not care what the accountant does as long as you get the correct result.
2. When you have cash and want to deposit it you go to the bank, wait in line and give your money, id and deposit form and you wait for response that your transaction is complete(In this scenario money = data, bank teller = DA component, safe = data store).
   
3. Your secretary is writing a letter after you.(your words = data, secretary = DA component, pen and paper = data store, and you may even get corruption)
   

In 1 - you don't have to learn all the tax laws = easier life, 2 - you don't have to store money at home = less chances to be robbed, 3 - you don't need to write and check spelling(I was not the best speller in school maybe you were?)

JUST TO NOTE: COMMUNITY EVOLVED STANDARDS ARE GENERALLY BETTER THAN A STANDARD CREATED BY A STANDARD BODY!

DA - data access

Hide the developers! The "business" is coming

What a the developer on the ground needs the most is simplicity. Any developer should be like a technical guy. The architect/project lead comes and says do that and that and do not worry about anything else. That is why there are PMs and architects - they are the "buffer" between all the crazy requests end client makes, even on the latter stages of the project. I recently was in a project that wanted to introduce new requirements and concept change 2 weeks after the development phase had ended and all functionality was finalized.

If you are a developer that is talking to "the client" your productivity as a developer falls tremendously. Be careful what you promise and NEVER EVER say "yes".
If you ever tried to look at how the specification is being created you'll see that for every requirement PMs battle with "the client". I wouldn't call it a requirement session but rather requirement battlefield.

Be careful though as a developer you have to protect yourself against bad PMs and architects. Never let PM or architect say "this is easy" when you know that this is not easy with the technology that was selected. When youre alone from you team in a meeting with "the client" always say "we will have to check it and we'll get back to you on it" because even "ok" will seem to the client that you are ready to accept his terms where you may be not.

So remember if you're a developer concentrate on the technical side and leave "the client" to PM.

"business" - is usually the end client of the project.

(Most of this stuff is my personal mental note)