So, you do not think that web services can be "self-contained"? I.e. a client sends a message to a web service, the core processing logic is encapsulated within the web service, and the result is send back.
I think a web service can certainly be designed the way you mention. However, I also think it would be a poorly designed web
service in direct conflict with the intent of the technology. This is similar to bundling all types of business logic, data processing
logic, presentation logic into one long
JSP page. At a syntax-level it can certainly be done, and can be made to execute without error,
but is this a good design? Will it easily support change in the future? Is it easy to understand and to teach to others?
An
application that has a web service interface or is "exposed" as a web service is sometimes described as a "web service" or
a "service-enabled application." And sometimes web writers and authors may not clearly describe what they are writing about. And in some cases the author
is describing the type of implementation similar to what you describe.
There are many different ways to design web services, but what I describe above is the easiest to understand and implement.
The XSD language is a complicated language and when it is married to other technologies, it typically makes them a burden, and difficult
to manage and implement, e.g. JAXB, web services. And in many cases XSD really is not required, but is simply there as a result
of someone's technical wet dream on caffeine. My perspective is tainted a bit by many years of SGML programming with DTD and
other esoteric languages that very few know about.
When you add XSD aspects to OO inheritence and "OO design aspects " of an implementation, and bundle this into the web service mix, you
will end up with a pot of technical mush... it may work, but is still mush.
Ideally, a web service should simply transport data, e.g. data values, method names to invoke, etc. Designers should
avoid contaminating
a web service interface with "specialized" types which require overly complex coding and introduce dependencies. In practice, this typically makes
things more difficult than it has to be...a common sympton when there is an absence of business leadership and the
right amount of technical management.
Apparently, in your situation the web service author has forced you into considering all types of crap when attempting to write client code for
his/her web service. This is reflective of "this" implementation, but does not reflect modern best practice.
The following two books are very good and should help you understand the concepts of "service" in a SOA and "web service."
Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap
Published by IBM Press
Enterprise SOA: Service-Oriented Architecture Best Practices
Published by Pearson Education, Inc.