Identifying and Specifying Web Services

A question I am worrying about at the moment...
My client intends developing a set of Web Services to allow 3rd parties to sell (and possibly service) their insurance products. The question is, how do they decide what services to expose and how?

This is actually a huge and distinctly non-trivial question to answer. I'm curious as to how things have moved on from when we did the Archtiectrue Conundrum work a couple of years ago. [The Blog we created of some resources we found is still here].

From a thread in the CSC RFA, Glen Best has provided a few links on service modelling. RFA Response.

It seems to me that you need to define a framework and set of patterns you are going to use before you start building. Questions to answer include:

What does the orchestration (or choreography) of the services?

How are the services monitored and managed?

How do you provide resilience and performance?

What is the security model and how is it implemented?

By the way Andrew's Blog has an excellent discussion on Service Versioning, which is part of the story.

As for how to expose the web services, there are some who would say that the services should be "RESTful". See here for example, for some tips on that. How well is this accepted? Or are people just using XML/SOAP?

Of course Web Services Interoperability is an important part of the story. But what is the level of adoption of the standard and when should we look to intercept which standards as they are defined and ratified?

Questions, questions... I've got a bit of catching up to do. Not least to find ouy what Zapthink are saying these days - I was quite impressed with their analysis in this area a couple of years ago.