EXPERT RESPONSE
One of the relatively common optimization techniques associated with SOA is that of validation abstraction; essentially the reduction of validation detail within a schema so as to reduce consumer coupling requirements and increase longevity of service contracts. To carry out this technique requires the deferral of some validation logic into the underlying service logic. So, what this means is that it is ok to move validation logic away from the contract layer, as long as there is a good reason to do so.
Often validation logic is associated with the business context of the service as a whole. For example, validation logic can be related to business rules that belong within the processing boundary of a business service (in the absence of decision services and business rules engines). Therefore, if you had an Underwriting Entity Service, it would make sense to place underwriting-related validation logic within this service (as part of the contract or embedded within the service logic).
I don't see anything wrong with a separate Validation Service, especially if it abstracts a great deal of reusable logic that can be applied to fulfill numerous validation requirements (in support of numerous services). However, if you are building an entity service layer and validation logic across these entities is distinct, then it might make more sense to contain them within the individual services so that they can be independently governed and evolved. It really comes down to the nature of the validation logic itself.
|
