How to understand the role of Service?

  • Thread starter Thread starter dotNeter
  • Start date Start date
D

dotNeter

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time. But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.

So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
 
Hi,
The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.
Click to expand...

The term "Service" and "Provider", as in IServiceProvider, refer to specific design patterns (as does "Container", which is
self-explanatory IMO).

ServiceInterface pattern:
http://patternshare.org/default.aspx/Home.PP.ServiceInterface

The provider pattern decouples a service's implementation with the mechanisms for discovery and consumption. I can't find a
reference to this pattern on patternshare.org. Maybe someone else has links they could mention.
In my opinion, everything can be a service, and a service is generally
used for providing specific features for service consumers, at design
time.
Click to expand...

Many things that aren't commonly referred to as services can be thought of as services, but actually referring to them as services
would create ambiguity when used out of context. For instance, you don't normally call an object's methods, "services" unless you
are creating a logical design. The term "service" is probably overused anyway, but here we are referring to a specific design
pattern.

You can also use these design patterns, as well as the actual interfaces, at runtime. From the perspective of the VS.NET
development team, their application uses them at runtime. You could use these patterns as well in your own applications. You get
some basic support for services in your own applications just by deriving a class from System.ComponentModel.Component. Web
services are another example of services being consumed at runtime. There are many, many more examples.
But, I think the cnsumers must completely know all aspects of
that service. This sounds not good, and breaks the decoupling rule.
Click to expand...

I don't think a consumer must know all aspects of a service that it consumes, otherwise it would break encapsulation. A service
could very well implement multiple service interfaces if they must share data. The consumer need only be concerned with the
interface on which it's performing it's work.

As for breaking the "decoupling rule", I think the service pattern intends to do just the opposite by creating a loose coupling
between the service implementation and the applications that use it, unless you are referring to a rule of which I'm unaware. I'm
referring to the notion that loose coupling of components is generally better.
So how to understand the role of Service, in a software engineering
perspective.
Thx in advance.
Click to expand...

Review design patterns and gather experience if you don't understand them.
 
Very appreciated for your detailed explanation.

Yes, I had a misunderstanding. Service pattern decouples the service
prodiver and the consumer. And the *CONTACT* is the key point which
maintains the interop between the service and the consumer.

I don't know if the following links referring to MS Provider pattern
are the desired stuffs, see,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp04212004.asp
 
Hi,

Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.

I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being "provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.

Sound good or have I described a different pattern altogether?

The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms" is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
 
A mechanism for discovery and consumption?
Interfaces are enough for exposing what consumers can do, then why
still need discovery?
I'm a little confused. Is it the reason that there is no real provider?
I guess.

Dave said:
Hi,

Thanks for the links, but the ASP.NET provider pattern is an example of an abstract base class with configuration. I was hoping
there was documentation of a component-based design pattern, one that did not use xml configuration as a part of the solution,
named, "Provider". I guess there is none.

I assume, somewhat like that used by ASP.NET, the pattern consists of an abstract base class that is the contract being "provided",
a concrete implementation of that contract, a strong-typed collection for that contract, an abstract service class that exposes that
collection as a property and a default "provider" as a property, and a concrete implementation of the service class. The service
could also be an interface implementation, which is usually how services are exposed to consumers through a provider.

Sound good or have I described a different pattern altogether?

The goal of the pattern, IMO as I stated in my previous post, is to decouple a service's implementation with the mechanisms for
discovery and consumption. I guess "mechanisms" is a pretty lose term and that view, if accurate, would explain why there is no
definitive "Provider" pattern.
Click to expand...
 
Hi,

I see a "provider" as providing one or more services so that services can be "discovered" at runtime, instead of just directly
accessing a class that implements a service.

For instance, say that I know of a service interface that exposes methods for logging. The interface provides a loose coupling
between an implementation of logging, which can be file-based or use the event log service (another service), and the consumer.
However, as a consumer I would still need to acquire an implementation of that interface. If I know of a class named,
"EventLogService" that implements the logging service interface I could create an instance of that class, however the provider
pattern would enable a different mechanism for discovery. Using a provider I'm able to discover services at runtime based on a
specific service interface without being aware of the mechanisms for service registration, effectively decoupling the mechanisms for
discovery from registration and implementation. I no longer need to be aware of the "EventLogService" class. I just simply need to
be aware that I want to use, say, the default provider. Provider service registration, in ASP.NET 2.0, happens to use xml
configuration and a static class as the entry point for service discovery at runtime.

Does that clear it up?
 
Whoa! So that it is. This makes perfect sense.
thx you very much.

Dave said:
Hi,

I see a "provider" as providing one or more services so that services can be "discovered" at runtime, instead of just directly
accessing a class that implements a service.

For instance, say that I know of a service interface that exposes methods for logging. The interface provides a loose coupling
between an implementation of logging, which can be file-based or use the event log service (another service), and the consumer.
However, as a consumer I would still need to acquire an implementation of that interface. If I know of a class named,
"EventLogService" that implements the logging service interface I could create an instance of that class, however the provider
pattern would enable a different mechanism for discovery. Using a provider I'm able to discover services at runtime based on a
specific service interface without being aware of the mechanisms for service registration, effectively decoupling the mechanisms for
discovery from registration and implementation. I no longer need to be aware of the "EventLogService" class. I just simply need to
be aware that I want to use, say, the default provider. Provider service registration, in ASP.NET 2.0, happens to use xml
configuration and a static class as the entry point for service discovery at runtime.

Does that clear it up?
Click to expand...
 
Back
Top