Returning interfaces from web-services and remoting servers?

[Ben Fidge]

Hi

I'm just about to start the design and development of a large in-house
Content Management System. The system will be ASP.NET based with a Sql Server
back-end and will be developed be using VS.NET 2003 Ent. architect.

Due to high demand (~10,000 users), and varying network setups across sites
using the system, I want to deliver an n-tier solution where the data layer
can be implemented as either a web-service, remoting server or a simple dll
assembly. Each particular installation will specify in web.config which
method to employ according ot its own specifics.

In order to provide the desired level of abstraction, and "flatten" the
three technologies, I'd like to be able to return the data-access classes as
interfaces to the client. This will simplify client-side development as the
client code will only need to be aware of the interfaces and not the
implementations. I plan to have a client-side proxy that is responsible for
brokering instances of the data access classes.

My questions are:

- Can web-services and remoting servers implement interfaces?
- Can WebMethods etc return/receive interfaces instead of classes?
- Is there a better way of doing this?

Any enlightenment most gratefully received,

Ben

[Henrik Gøttig]

> My questions are:

>
> - Can web-services and remoting servers implement interfaces?
> - Can WebMethods etc return/receive interfaces instead of classes?
> - Is there a better way of doing this?
>

Hi Ben

You should definately read the following article. I guess it would
answer at least the first two questions.

I would go the interface way, too, because you can have several
providers (implementations) of the same interface. One could make a
mechanism to switch between implementations...but the the interface (for
the client) will remain the same.
Basically. The OO paragidm "Program to an interface, not an
implementation" still goes in the WS world.

Here's the link (watch for linebreaks)

[url]http://www.topxml.com/reblogger/xml_news/4793_Interface_Based_Service_Contracts_in_the_NET_ Framework_2_0.asp[/url]


Regards

Henrik
[url]http://websolver.blogspot.com[/url]

[Ben Fidge]

Henrik,

A very fascinating article, and is definitely what I need for the
web-service scenario. Unfortunately, I'm not going to be able to use .NET 2.0
for this project. It's to be written entirely in VS.NET 2003 and .NET 1.1.

Still, the ideas presented in that article are food for thought. I think
what I'll do is expose the VS.NET generated client side stubbs using shims
that implement my interfaces in a kind of go-between assembly, so the client
benefits from the desired transparency. The interfaces will be defined in a
lightweight assembly that resides on both sides of the divide.

Thanks

Ben


"Henrik Gøttig" wrote:

> > My questions are:
> >
> > - Can web-services and remoting servers implement interfaces?
> > - Can WebMethods etc return/receive interfaces instead of classes?
> > - Is there a better way of doing this?
> >

>
> Hi Ben
>
> You should definately read the following article. I guess it would
> answer at least the first two questions.
>
> I would go the interface way, too, because you can have several
> providers (implementations) of the same interface. One could make a
> mechanism to switch between implementations...but the the interface (for
> the client) will remain the same.
> Basically. The OO paragidm "Program to an interface, not an
> implementation" still goes in the WS world.
>
> Here's the link (watch for linebreaks)
>
> [url]http://www.topxml.com/reblogger/xml_news/4793_Interface_Based_Service_Contracts_in_the_NET_ Framework_2_0.asp[/url]
>
>
> Regards
>
> Henrik
> [url]http://websolver.blogspot.com[/url]
>

[Henrik Gøttig]

Hi Ben

> A very fascinating article, and is definitely what I need for the
> web-service scenario. Unfortunately, I'm not going to be able to use .NET 2.0
> for this project. It's to be written entirely in VS.NET 2003 and .NET 1.1.

No problem.
Check this article:
[url]http://www.fawcette.com/archives/premier/mgznarch/vbpj/2001/10oct01/ws0110/ws0110-1.asp[/url]

It uses an abstract class implementing the interface. In .NET 1.1 you
can apply WebService attributes to classes only, also abstract classes.

When your client need to interact with the service expose only the
interface, not the abstract class.

>
> Still, the ideas presented in that article are food for thought. I think
> what I'll do is expose the VS.NET generated client side stubbs using shims
> that implement my interfaces in a kind of go-between assembly, so the client
> benefits from the desired transparency. The interfaces will be defined in a
> lightweight assembly that resides on both sides of the divide.

This sounds pretty much as the same thing the above article is suggesting.

Regards

Henrik