What is the contract to service relationship: 1 to 1? Many to 1?
>From a consumer point of view, should different contracts be viewed as different services? Or does it not matter? If multiple services share a common implementation does it matter from an SO architecture viewpoint? Or is this an implementation detail with the implementation architecture being independent of the service architecture? At what point does a single service with multiple contracts (assuming this is a reasonable construct) and each contract having multiple interfaces does the "service" become unwieldy? -Rob --- In [email protected], Dennis Djenfer <d...@...> wrote: > > Michael, I don't think your interpretation of the pattern is > entirely correct. I agree it's unpedagogical to bring forward a > bad practice (class->WSDL) as one of the argument for the pattern, > but the patterna also has other values, e.g managing of multiple > contracts, which Erl also mentions. It's a "classic" pattern and > basically gives you another level of indirection for the internal > design of your services. I think many people, at least the vendors, > would refer to this pattern as virtualization. > > // Dennis Djenfer
