best return from WCF service to other .NET consumers?

[Kai Fransson]

We have a web application today in Framework 3.5. The application consists of
a Data Access Layer, Business Logic Layer and a Front Layer of ASP.NET
webpages. In the DAL, a number of typed datasets are defined, and it is these
typed datasets that are used as data transfer objects throughout the
application.

Now we want to expose functionality, from the application, to other .NET
systems, through a WCF service. What should we let the WCF service expose to
other systems?

Here are the alternatives we have talked about:

1. Expose the DataSets we already have (simply return the typed datasets as
regular DataSet)
- Very convinient, byt the existing typed datasets were originally created
for internal use, and look much like the database itself, when it comes to
fieldnames, tables etc.

2. Create new typed datasets in the front layer.
- Requires defining new typed datasets ("external datasets") in the front
layer, and implementing custom transfer of data from "internal dataset" to
"external dataset" in the front layer.

3. Expose only XML formatted strings.
- Requires custom transfer of data from typed dataset to XML in the front
layer.

All we know of the future consumers of this new service is that .NET and
Framework 3.5 is ok. We will of course be able to send them a documentation,
describing how to consume our new webservice.

What would be the best thing to return from the service? Any advice is
greatly appreciated!

 

[John Saunders]

Here are the alternatives we have talked about:

1. Expose the DataSets we already have (simply return the typed datasets
as
regular DataSet)
- Very convinient, byt the existing typed datasets were originally created
for internal use, and look much like the database itself, when it comes to
fieldnames, tables etc. ....

What would be the best thing to return from the service? Any advice is
greatly appreciated!

None of the above.

Follow the Data Transfer Objects pattern. Create a set of objects which
represent data with no behavior. Their purpose is only to transfer data from
one layer to another (for instance, from the service to its clients). As a
result, these objects will not be platform-specific as a DataSet is, typed
or not.

Another point to consider is that you should be exposing functionality from
your service, rather than just data. A process I find useful is to produce
UML use case diagrams relating to the functionality to be exposed. I go as
far as to relate the use cases using "include" and "extend" connections.
When done, you will find that you have a set of use cases that are directly
used by the actors in the diagrams, and a set of use cases that are only
used by other use cases (of course, you may find some that are used by both,
but I find this to be suspect). The use cases that are directly used by
actors represent operations that should be exposed by your service to its
clients (the actors). The other use cases represent behaviors that may be
used by other use cases, but do not directly need to be exposed to clients.

This process produces services that meet the requirements (assuming that the
use cases are written based on the requirements), and which are at an
appropriately high level for use in an SOA.

In most cases, you will find that these services aren't so much about data,
as they are about the business functionality that your application already
provides, but which are factored so as to cater to a more abstract set of
usages.

I hope this helps,
John