This looks like a domain model gone sour (not an antipattern name, BTW :) It stems from the illusion that there is such a thing as a well-defined domain model. In reality, there are some aspects of the problem domain that can be elegantly modelled, but at the finer level of detail there are exceptions upon exceptions and special cases upon special cases, each specific to a single service method, that destroy this elegance.
The appearance of many nested objects is often the result of a continuous process of "grinding down" the domain model to ever finer granularities, in the hope that every instance variable may be reused in different contexts. There is a breaking point where the dogmatic imperative to reuse each and every domain attribute just stops making sense.
My way out of this is to stop trying to create a one-size-fits-all domain model and use objects specifically designed for each service call. These objects may rely upon some of the well-defined domain objects, but add any specific information separately and in a way that doesn't interfere with other service calls.