You want to define your data types with XML Schema to use within your SOA, but Schema is so flexible that you aren’t sure how to do it. You want to follow patterns and best practices for Schema that make the most sense specifically in an SOA context.
Follow one of the Schema design patterns discussed here: Russian Doll, Salami Slice, or Venetian Blind.
There are several generally accepted design patterns that apply when creating XML schemas. The inherent flexibility that XML Schema affords means that it can be difficult to figure out how to start writing them in a consistent, clear manner that will give you the perfect combination of expressiveness, flexibility, and strong-enough typing. This is all aggravated when your aim is to design them for an SOA in a way that allows you both to generate to Java code and to use as raw XML.
Schema defines basic building blocks for defining entities: simple types, complex types, elements, and attributes. Beyond these, there are many choices to make regarding global or local types, namespace qualification, and more. Making uninformed choices at this level can crush your SOA, inadvertently limiting its flexibility. Without careful schema design, you could work very hard to make loosely coupled services that are composed using orchestrations and brokered ESBs for different domains, only to suddenly find that in reality the services in your SOA are very tightly coupled at the root because of a poor choice in ...