What suggested guidelines would you list for "when to use a web service?"

Question

I'm working with an older set of developers who "enjoy" interop at the database level and I'm trying to put together a solid list of "guidelines" for my team so they know "when to use a web service"

Other than "when you want 2+ systems to inter operate" - what would you list here?

Answer 1

• Access to the data needs to extend beyond this organization.
• Access needs to be available to developers working in many languages.
• The underlying implementation (i.e. language used to work with the data internally or storage of the data) will change over time, but the data itself and how it is presented will stay consistent for many apps which need to use it.

Answer 2

Web Services are best used when you want to expose a standard common interface for interacting with an application across multiple client applications and disperate networks.

Answer 3

Use web services:

• to provide interop between languages (Java, C#, etc.) (1)

• to provide an interface into your stuff to your customers / the general public (and don't know what they'll be using)

• to provide controlled access to RPCs or data across the internet

(1) The irony is that java and C# SOAP web services take nearly every opportunity to be incompatible with each other.

Answer 4

• when you expect the database logical (or physical) struture to change (but not of course the model for that may impact the Webservices API, of course)
• [more generally] when you wish to insulate the "consumers" of data from database details

Answer 5

In addition to all the above I've found web service contracts brilliant for abstracting away from database schemas towards more of a "canonical data model" view of a business.

This helps business users, business analysts and developers agree on common vocabularies and concepts which can then be modelled in message contracts.