2

Let's say I have a text file of basic mathematical functions.

I want to make a web service that answers these mathematical functions. Say the first one is y=x*x. If I wanted to turn this into a web service, I could simply do this:

[WebMethod]
public int A(int x)
{
  return x*x;
}

However, I've extracted the function from the list by hand and coded it into a function by hand. That's not what I want to do. I want the wsdl for the service to be generated at call time directly from the text file, and I want the web method calls to the service to go to a specific method that also parses the text file at run time.

How much heavy lifting is this? I've found a sample on how to generate WSDLs dynamically at this link, but there's a lot more to do beyond that and I don't want to bark up this tree if there are parts of the project that arn't feasible. Does anyone have any links, guides, books, or positive experiences trying this kind of thing?

quillbreaker
  • 6,119
  • 3
  • 29
  • 47
  • Maybe you should consider generating WSDL and code as part of a continuous integration process that is triggered whenever the text file changes. For example, you(or some program/database) updates the text file, and this automatically triggers a code generation/compilation/deployment. This could be done with CI Factory and some NANT scripts. The scary part is getting this to work reliably, but I think you'd have the same problem either way. If you generate WSDL and generate code at runtime with something like Refletion.Emit, you still have the same risks in terms of reliability/testability. – AaronLS Apr 09 '10 at 21:28
  • It's a good thought, but the goal (which I confess I didn't go into) is to lock down the C# service code. – quillbreaker Apr 09 '10 at 21:44
  • I could work with WCF or the older VS2003 style services, by the way. – quillbreaker Apr 09 '10 at 21:45

3 Answers3

3

This related StackOverflow question post might give you a lead.

The tip here is to use the SoapExtensionReflector class.

As I see it, you might be able to use that class as follows:

  1. Create a web service containing 1 dummy method.
  2. Subclass the SoapExtensionReflector and configure it in web.config.
  3. As soon as your subclass is called for the dummy method, read the file with functions and dynamically add a method to the WSDL file for each function.

As you might agree, this sounds easier than it is, and I would personally prefer not to go there at all. The resulting code will probably be a bit of a maintenance nightmare.

Good luck :)

EDIT: it might actually be easier to write a little code generator, which generates the C# web service code from your file with functions. Then, let the WSDL generation be up to the framework you are using (e.g. WCF).

Obviously, this kind of kills the whole dynamic aspect of it + you would need to redeploy after ever change in the functions file. But then again, the cycle of 'generate code - build - redeploy' could easily be automated with some MSBuild tasks.

I guess the usefulness of such a solution depends on how often your file with functions changes...

Community
  • 1
  • 1
Eric Eijkelenboom
  • 6,943
  • 2
  • 25
  • 29
1

I believe it's possible to add a metadata exchange endpoint programmatically in WCF - you may want to look into that. That would allow you to dynamically return WSDL to potential service clients who could query your webservice at runtime to determine which entry points are available. But it's definetely a bit of work - and not for the faint of heart.

LBushkin
  • 129,300
  • 32
  • 216
  • 265
1

Is a dynamic WSDL an absolute requirement? Not having a static WSDL also means you can't have a static (auto-generated) proxy class, which is a real PITA. Instead, you could expose the function signatures as plain old data, rather than as WSDL metadata:

[ServiceContract]
public interface IMathFunctions
{
  [OperationContract]
  FunctionDescription[] GetFunctionList();

  [OperationContract]
  object RunFunction(string funcName, object[] args);
}

public class FunctionDescription
{
  string Name { get; set; }
  Argument[] Arguments { get; set; }
  TypeCode ReturnType { get; set; }
}

Public class Argument
{
  String Name { get; set; }
  TypeCode Type { get; set; }
}

You will need to use the [DataContract] and [DataMember] attributes on the FunctionDescription and Argument classes when using a version of .NET earlier than 3.5 SP1.

Allon Guralnek
  • 15,813
  • 6
  • 60
  • 93
  • There are applications (Sharepoint is one) that know how to integrate with arbitrary SOAP web services. If I build a service within SOAP instead of a SOAP service, there could be integration difficulties. – quillbreaker Apr 14 '10 at 14:26