Hi Jim,
The answer of course is "it depends". It depends on factors such as will
you have control over each of the implemenations (assuming here that you
choose to implement more than one "service". In this regard, the term "web
service" can be a bit misleading. A service implementation (a la Visual
Studio .NET) project can contain more than one method. Some people call
each method "a service". Others call the project file "the service".
Others are equating a single URL and set of SoapAction values as the
service boundary.
The clearest, at least to me, definition of a service is defined by
governance rather than implementation specifics. If you will be in control
of every piece of the implementation, and all of the parts you are
considering are directly related, then from a governance perspective you
could argue that this is one service. The current advice re: Service
Orientation is that "services are autonomous" - and I've used a governance
viewpoint here to define what I mean by autonomous. If you could choose to
change the version of all of the parts, for instance, then you have
governance over the entire service. Since you are stating that these parts
would all be coordinated from a web part - then I'm assuming they are
related - so now you have governance over a set of related
methods/implementations.
Of course, as I stated at the start, "it depends".
I hope this helps
Dan Rogers
Microsoft Corporation
--------------------
