I'm pretty much in agreement with Steve. The "point services" are difficult to avoid when the predominant culture has a single project team building both consumer and provider. The path of least resistance is to make a very project-specific service. At the same time, however, I have no issues with services that have only one consumer. If it makes sense for it to be in a separate ownership domain, allowing consumer and provider to move freely rather than in lock step, that's a good thing.
Regarding proliferation of interfaces, I'm in favor of both a lower bound (once multiple versions are available) and an upper bound on the number of versions in production. I've blogged on this: http://www.biske.com/blog/?p=144 -tb Todd Biske http://www.biske.com/blog/ Sent from my iPhone On Oct 30, 2007, at 10:36 AM, "Rob Eamon" <[EMAIL PROTECTED]> wrote: > --- In [email protected], "Steve Jones" > <[EMAIL PROTECTED]> wrote: >> >> ...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. > > This is indeed my concern. It would seem to be a symptom of doing > things the same old way but now with services. > > IMO, this is where many service oriented efforts will go awry, much > in the same fashion that EAI fell into disfavor. EAI was an approach- > not-a-technology too, but many people associated it with specific > technologies and ended up doing point-to-point solutions in a new- > fangled way--and then were surprised when the system exhibited > inflexibility (and blamed the tools). "But I'm using pub/sub so the > solution is completely decoupled." Not so, Skippy. :-) > > -Rob > > > > > > Yahoo! Groups Links > > >
