Returning interfaces from web-services and remoting servers?

[Guest]

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

 

[Guest]

Your best bet is probably to have local assemblies that define your
interfaces and interface implementations. The implementations would be
responsible for connecting to the web service to meet the contract for the
interface(s) they implement. The web service is just a way to pass data
around.

You might want to read up on service-oriented architectures before you start
development. There is lots of good info on the subject on the web. Also,
you could check out Rockford Lhotka's CSLA framework for his ideas on how to
properly-wrap data logic. Some links follow:

http://www.lhotka.net/
http://www.terski.com/blog/#aec62f263-9e18-4c9b-817a-199ce369a4d9

 

[Ben Fidge]

Thanks for the advice. I'd already decided on using a client-side proxy that
deals with the brokering of the data, and I also see the remoting server and
web-service as purely "pass-through" layers.

I was rather hoping that the web-service, remoting server etc would all
support the same interface as this will be well defined.

Thanks for the info anyhow. I'll definitely read up on SOA as you suggest.

Ben

 

[Guest]

Hey Ben,

You could certainly make it appear like the web service and remoting server
use the same, well-defined interface. Just define the interface that
represents the service functionality you need, then create your client-side
proxy for connecting to either a web service or remoting server, and make the
proxy satisfy the interface contract.

This is a good rule of thumb to use anyways -- clearly separating concerns
at each layer in your architecture. The web service/remoting server, and the
underlying infrastructure that they represent, can usually be thought of as
part of the data layer, and they have a separate set of needs from the
interface that clients in higher layers might want to interact with.

For example, let's say that your CM system works with various documents that
you've defined an IDocument interface for. In order to get IDocument
instances, you've defined an IDocumentFinder that has method FindDocument(int
id). Your UI or UI process code could simply obtain an instance of
IDocumentFinder, call the simple FindDocument method, and obtain the
IDocument instance it's after. You could have IDocumentFinder
implementations that connect to a web server, remote server, or access some
other data store directly -- it doesn't matter . The key is to think of
web services in the proper context, then everything falls into place.