написание веб-сервиса с динамически определяемыми веб-методами - PullRequest
Новая
       22

написание веб-сервиса с динамически определяемыми веб-методами

2 голосов
/ 10 апреля 2010

Допустим, у меня есть текстовый файл основных математических функций.

Я хочу создать веб-сервис, который отвечает этим математическим функциям. Скажем, первый - это y = x * x. Если бы я хотел превратить это в веб-сервис, я мог бы просто сделать это: 

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

Однако я извлек функцию из списка вручную и закодировал ее в функцию вручную. Это не то, что я хочу сделать. Я хочу, чтобы wsdl для службы генерировался во время вызова непосредственно из текстового файла, и я хочу, чтобы вызовы веб-метода для службы переходили к определенному методу, который также анализирует текстовый файл во время выполнения.

Сколько это тяжелая работа? Я нашел пример того, как динамически генерировать WSDL на этой ссылке , но помимо этого есть еще много чего, и я не хочу расшаривать это дерево, если есть части проекта, которые неосуществимо. У кого-нибудь есть какие-либо ссылки, руководства, книги или положительный опыт, пробующий подобные вещи?

Ответы [ 3 ]

3 голосов
/ 16 апреля 2010

Этот связанный вопрос StackOverflow сообщение может дать вам преимущество.

Совет здесь заключается в использовании класса SoapExtensionReflector .

На мой взгляд, вы можете использовать этот класс следующим образом:

  1. Создать веб-сервис, содержащий 1 фиктивный метод.
  2. Подкласс SoapExtensionReflector и настройте его в web.config.
  3. Как только ваш подкласс вызывается для фиктивного метода, прочитайте файл с функциями и динамически добавьте метод в файл WSDL для каждой функции.

Как вы можете согласиться, это звучит проще, чем есть, и я лично предпочел бы вообще не ходить туда. Полученный код, вероятно, будет чем-то вроде кошмара обслуживания.

Удачи:)

РЕДАКТИРОВАТЬ: на самом деле может быть проще написать небольшой генератор кода, который генерирует код веб-службы C # из вашего файла с функциями. Затем позвольте генерации WSDL соответствовать используемой вами платформе (например, WCF).

Очевидно, что этот вид убивает весь его динамический аспект + вам нужно будет повторно развернуть его после любого изменения в файле функций. Но опять же, цикл «генерация кода - сборка - повторное развертывание» можно легко автоматизировать с помощью некоторых задач MSBuild.

Полагаю, полезность такого решения зависит от того, как часто меняется ваш файл с функциями ...

1 голос
/ 14 апреля 2010

Является ли динамический WSDL абсолютным требованием? Отсутствие статического WSDL также означает, что у вас не может быть статического (автоматически сгенерированного) прокси-класса, который является настоящим PITA. Вместо этого вы можете представить сигнатуры функций как простые старые данные, а не как метаданные WSDL: 

[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; }
}

Вам потребуется использовать атрибуты [DataContract] и [DataMember] в классах FunctionDescription и Argument при использовании версии .NET более ранней, чем 3.5 SP1.

1 голос
/ 10 апреля 2010

Я полагаю можно программно добавить конечную точку обмена метаданными в WCF - вы можете посмотреть на это. Это позволит вам динамически возвращать WSDL потенциальным сервисным клиентам, которые могут запросить ваш веб-сервис во время выполнения, чтобы определить, какие точки входа доступны. Но это определенно немного работы - и не для слабонервных.

...