How to understand the role of Service?

[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.

[Dave Sexton]

Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton

[dotNeter]

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/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp

Dave Sexton wrote:

Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton

[Dave Sexton]

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.

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11*********************@i3g2000cwc.googlegrou ps.com...

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/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp

Dave Sexton wrote:

>Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton

[dotNeter]

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 Sexton wrote:

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.

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11*********************@i3g2000cwc.googlegrou ps.com...

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/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp

Dave Sexton wrote:

Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton

[Dave Sexton]

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?

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11**********************@i42g2000cwa.googlegr oups.com...

>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 Sexton wrote:

>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.

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11*********************@i3g2000cwc.googlegrou ps.com...

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/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp

Dave Sexton wrote:
Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton

[dotNeter]

Whoa! So that it is. This makes perfect sense.
thx you very much.

Dave Sexton wrote:

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?

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11**********************@i42g2000cwa.googlegr oups.com...

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 Sexton wrote:

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.

--
Dave Sexton

"dotNeter" <Bu************@gmail.comwrote in message news:11*********************@i3g2000cwc.googlegrou ps.com...
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/de...sp02182004.asp
http://msdn.microsoft.com/library/de...sp04212004.asp

Dave Sexton wrote:
Hi,

The services, talked here, are things used in IServiceContainer,
IServiceProvider, etc.

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...rviceInterface

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.

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.

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.

Review design patterns and gather experience if you don't understand them.

--
Dave Sexton