There are three types of interface to consider in this for me 1) Version based differences 2) Facade/Functional differences 3) Point differences
by 1) I mean that a service has a set of operations and schema and these elements are updated to produce a similar but distinct interface. This is standard versioning and evolution and okay if managed properly. by 2) I mean cases where the same underlying service can have distinct business views, for instance a procurement service which has a view for those people buying things and a view for those approving things. Another example would be a sales service which has a customer view and a sales operations/marketing view. These are also okay as they represent different virtual services on the same underlying business service. The key is to link them to differing business contexts and not allow them to proliferate one for each client. by 3) I mean when people ask for a new version for their project and its delivered. These are the wrong ones, they aren't created for a general business context they are created for a specific point solution and represent a project specific change. These create major issues of complexity, management and cost. Another one I'd add as a wrong case is the one underlying service with one "service" interface per operation. This is needless complexity. Steve On 29/10/2007, Rob Eamon <[EMAIL PROTECTED]> wrote: > > Understanding that managing the number of interfaces of a given service > is a Good Thing, what are the thoughts that multiple interfaces (for > versioning or functionality purposes) may lead to point solutions and > one-offs? Does this particular aspect of services *tend* to encourage > poor practice in terms of proliferating interfaces? > > -Rob > > >
