WebServices-There is more to a contract then its data-types
I supply WebServices in my day to day work for a number of different 3rd party vendors working in or for the Telecom and Cable industry. An advantage of using WebServices is that once a contract is defined, it is a firm contract between a supplier of a service and its clients. However, when defining a contract, it is important to model the data in business terms. If your service is just a pass-thru to a database or a set of database calls, you are missing the point to a Service Oriented Architecture and potentially harming your clients (see WOTL Blog Entry).
Your contract is more then just a set of data-types and exceptions. It is also about the data and if you do not model the data in terms of the business, then you are coupling your clients to any underlying system or database that your services is communicating/integrating. The problem with presenting a set of services that merely map directly to a database record is that if the meaning of your data changes, your clients will be ill-prepared for the change. As a writer of a service, you have a responsibility of always presenting the data in your service in terms of the business. If you are having a tough time doing this, then you should seriously look at your justification for a Service Oriented Architecture in the first place.
For example, let’s say your service is accessing a system to check on the state of an order existing in yet another system. Chances are it is an older data-driven system and it will have arcane values describing the state of an order (e.g. CP for Complete or IC for Incomplete). If you just pass these values directly back to a client then you are tying your clients to an underlying implementation of this 3rd party system that your client should really care less about. If this underlying system changes (e.g. now uses CMP for complete) or adds a new status, then all of your clients will be affected. Instead, you should define an element in your application domain for OrderStatus and then go about mapping the underlying system’s status values. If an underlying status value changes (e.g. CP==CMP), then you merely need to remap. If a new status is added, you can at the very least map it to an existing status or re-release your service with the change. Either way, you are presenting a layer of abstraction to your clients and presenting real business value.
-Mathew Nolton