SOA Inheritance Compensation Templates

Question

I find Inheritance and the concept of a base class as the strongest point of OOP. But this is not encouraged in SOA. So, what are the popular patterns for overcoming this limitation in SOA? Could you provide tutorials that explain (with code demonstration in WCF) these patterns?

Note. This is NOT a general question about the templates available in SOA. But this is more specific to the above problem.

Note. I am using WCF for SOA.

---

Reading:

• "Do not use the abstract base class in design, but in modeling / analysis"

• How should the SOA architecture be implemented?

• How to work with Java polymorphism in a service oriented architecture

• How to get to speed on SOA?

• What is a service oriented architecture?

• Do DDD and SOA really work well together?

• SOA and WCF design questions: is this an unusual system design?

• Designing Contracts and Operations with WCF Data

• Expando Objects in C # 4.0

Answer 1

Regardless of whether you are thinking of SOA, SOAP, REST, or messaging, services are document-centric. Services are not object oriented .

While polymorphism is a powerful design tool in OOD, it is not applicable in SOA because SOA modeling does not include classes.

Answer 2

I find Inheritance and the concept of a base class as the strongest point of OOP.

Do not overestimate the power of inheritance - almost all GoF templates avoid the misuse of inheritance.

But this is not recommended in SOA.

No, this is not encouraged at all. What for? Because in SOA, you have a service that provides some operations. The service itself is determined by the description of the service (contract / interface). In the case of a contract with a SOAP service, it is described in WSDL. If you need to have another service providing the same set of operations with slightly different behavior, you simply implement the interface again and the target client for the new service (by providing a new endpoint URL). Thus, inheritance with a service contract "works", but it does not work exactly the same with data contracts.

Each overhead operation usually takes some data and returns some data. This data is again described in the service description. In the case of SOAP service data, the data is described as XSD. When you send data from the client to the service (or in the opposite direction), the data must be serialized and the recipient should be able to deserialize it (if you do not want to work with SOAP envelopes directly or if you do not want to use xsd: any = untyped XML as received data). If you want to use inheritance in a data contract, you must somehow include information about derivative contracts in the service description. Only after including this information in the description of the service can you inform consumers of the existence of inherited data contracts (they need this information to work with derived types).

WCF offers the ability to work with legacy data contracts. You can use the KnownTypeAttribute , ServiceKnownTypeAttribute attribute or DataContractResolver . You can also check out this great article for more details.

In the case of incompatible and closely related systems (without SOA), you can also use the NetDataContractSerializer , which allows you to use inheritance without any because each serialized message contains information about the type of CLR needed for deserialization, and clients with the service must share the data collection.

Answer 3

One reason why inheritance is not recommended in SOA is because your code is model oriented. You have well-defined entry and exit models, and your code should translate between them, as well as execute any business logic.

Having inheritance simply means that the relationships between your objects are difficult to model and / or change over time. Basically, this means using POCO model objects.

If you want to add business logic to your key, use mixins to simulate inheritance.