CODEWITHSUNDEEP
c#.netweb-services
haughtonomous
haughtonomous

Reputation: 4850

How to make an existing C# dll available as a web service

In principal this looks like a simple job, but I wonder if anyone can take me through the basic steps?

I have an application API, implemented as a C# class library project in the application solution. People can thus write their own conventional .Net applications using this API by referencing the dll directly.

I now need to make exactly the same functionality available as a web service so applications can be written to remotely access the same API over http. Ideally I would just like to tag the API classes and methods with appropriate web service attributes, but I suspect there is more to it than that. I also must have the API dll continue to work as an API for desktop applications as it does at present.

Is this do-able? If so, what are the steps I need to take?

Upvotes: 2

Views: 2459

Answers (1)

maxwellb
maxwellb

Reputation: 13954

The web service can be composed mostly of wrapper methods. Take the simple case...

If your API method in the assembly is

public void DoFoo(string bar)

Then your web API method (your choice of implementation, such as WebAPI, ASMX web service, etc) will look like

public void DoFoo(string bar) {
    // ... initialization or validation
    try {
        refToDll.DoFoo(bar);
    } catch (Exception e) {
        // implementation specific return of error.
    }
}

If you have mostly static methods or those taking primitive types, that becomes more easy. If your API has types defined, this becomes harder. You will need to change the type signature and reimplement methods. Without your API it would be difficult to make specific suggestions. However, there are several options. If you had

 public class BazClass {
     public string GetScore() {
         return scores.Sum();
     }
 }

You basically need to ensure that the remote side (the web API) can reconstruct the context from your client side. You have to pass in a serializable instance or other representation of BazClass and let the remote API work on it. It just doesn't exist otherwise. You could also create a bunch of methods that store state on the server and you work with a "handle" on the client side, or object reference, but that will have to be a design decision (just look at interop with native libraries, and handles, and translate to cross network). Example:

public string BazGetScore(Transport.BazClass baz) {
     // Depending on the framework and class (all public getters/setters)?
     // your framework may allow for transparent serialization
     BazClass bazReal = bazFactory(baz);
     string score = bazReal.GetScore();
     return score;
 }

How much of your source API is based on interfaces? This may make the creation of a Proxy class much more transparent to your end user. If you have

public class Baz : IBaz { ... }

Then you can create a Proxy class that acts just like an IBaz but calls the remote API instead of acting locally. Depending on your framework and tooling, this may be able to be facilitated by the tools.

namespace RemoteAPIProxy {
    public class Baz : IBaz {
        public string GetScore() {
            // initialization of network, API, etc
            Transport.Baz baz = new Transport.Baz.From(this);
            string score = CallRemoteAPI("BazGetScore", baz);
            return score;
        }
    }
}

In summary, you may have to make some intermediate classes depending on if you need to support state, non-public methods, or full scope. The "how" can mostly be considered just another wrapper, but you need to be conscious of how you get your local state over the wire and into the context of the remote API. Use interfaces, serialization helpers, and lightweight transport objects for state to help with the "glue". Remember, the only "I" in "API" is for "Interface", so you might want to make sure you have some. Good luck!

Upvotes: 2

Related Questions