SOA - The four tenets [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

I'm reading about SOA and the four tenets thats required to make a SOA-application. I have tried different sources, but the explainations is twisting. Im searching for something that is a bit less abstract. Is my interpretation correct?

The four tenets is:

1. Services have explicit boundaries
2. Services are autonomous
3. Services share schema and contract, not class
4. Services interoperate based on policy

My interpretation is:

1. The methods that a client may use shall be easy to use and well defined.
2. Services shall not be dependent on others. Change of one service shall not affect another in any way.
3. A scheme represent the data that will be sent, contract contains the defined methods for a service. To make a system loose coupled you share scheme and contract instead of classes and objects.
4. A policy to use a service may be that a particular type of binding is required so it may be used. Anyone that want to use this service, must connect to it with this type of binding.

Answer 1

Got answer at programmers.stackexchange.com. Im reposting answer from GlenH7:

You're pretty close with your abstractions, yes.

1. Yes. Well encapsulated is another way of looking at this.
2. Yes, but... Service can rely on other services for functionality, especially if that avoids duplication of code. The nuance here is in the definition of dependent, I guess.
3. Yes. Services perform a contract for a scheme. User provides XYZ data and the Service will provide ABC action per the contract.
4. I view services as operating against a business policy. Business policy shouldn't get to the level of specifying binding. From the implementing business policy point of view, you can see where some services would be dependent upon other services in order to fulfill their contract without duplicating code. At a broader level, business policy is just a bunch of rules. Rules that hopefully interoperate nicely with each. But just like human resources, business rules have a nasty habit of not getting along with each other as well. Services are the instantiation of those business rules. From a lower level point of view, if the caller doesn't use the advertised binding(s) then the caller will (obviously) be unable to utilize the service. So while your statement is correct, it's a bit of a tautology which doesn't enhance your understanding as much.