I don't understand this comment.
Whether you define your model in terms of XML schema, in WSDLs, or in terms of Java classes, is irrelevant and services that use different models will always have the problems mentioned. Standard models for the same kinds of data would help in either situation. Ideally, a company's web services, or a company's applications would try to use the same models for the same types of objects. In this case, neither code-centric nor WSDL-centric would have the advantage. From the point of view of maintainability and reusability, I'd go for separating business functionality from the infrastructure for deploying that functionality (in this case, web services). I can then change the deployment infrastructure, without having to rework the business functionality.
Tony
| "Dennis Sosnoski"
<[EMAIL PROTECTED]>
17-Nov-2004 21:14
|
|
The problem with this approach is that you're exporting your object
model. This works fine for simple applications where you've got clients
that only talk to one web service and services that only work with one
client. Beyond that level it starts to get really messy, since the same
data may be used with multiple services. If each one exports its own
object model you then have to write code to shuffle the data from one
model to another. This approach becomes completely unmanageable when you
get to complex data structures (like many forms of enterprise data) that
may involve dozens of components.
If you're going to be making web services a serious part of your future
development you're better off developing standard data representations
(in the form of XML schemas) that can be shared across services. That
way applications which are working with the same type of data will be
using compatible formats for the XML exchanges, even though their
internal data structures may be different. Of course, you won't gain the
most benefit from this approach until you can use a SOAP framework that
lets you to decouple the XML format from your data structures. Even if
you can't do it with the current production frameworks, though, you can
still plan for this flexibility in the future.
