How to deal with Java Polymorphism in Service Oriented Architecture

Question

What is the path of least evil when dealing with polymorphism and inheritance of entity types in a service-oriented architecture?

A principle of SOA (as I understand

Answer 1

I think there is a confusion of concerns here. SOA is an architectural way to solve interaction between components. Each component within a SOA solution will handle a context within a larger domain. Each context is a domain of it self. In other words, SOA is something that allows for lose coupling in between domain contexts, or applications.

Object Orientation in Java, when working in this kind of an environment, will apply to each domain. So hierarchies and rich domain objects modelled using something like domain driven design will live on a level below the services in a SOA solution. There is a tier between the service exposed to other contexts and the detailed domain model which will create rich objects for the domain to work with.

To solve each context/applications architecture with SOA will not provide a very good application. Just as solving the interaction between them using OO.

So to try to answer the bounty question more specifically: It's not a matter of engineering around the issue. It's a matter of applying the correct pattern to each level of design.

For a large enterprise ecosystem SOA is the way I would solve interaction in between systems, for example HR system and payroll. But when working with HR (or probably each context within HR) and payroll I would use the patterns from DDD.

I hope that clears the waters a bit.