XSD используется для определения типов данных , а не интерфейсов или протоколов. Я бы пошел на смешивание WSDL и XSD. Я имею в виду, вы создаете WSDL, который определяет интерфейсы и методы, а затем связываете аргументы этих методов с типами, определенными в XSD, внутренними или внешними по отношению к WSDL.
Образцы здесь . Как видите, logbus-management.wsdl не только включает XSD сам по себе, но также строго ссылается на пространство имен filter из logbus-filters.xsd.
Из этого WSDL вы можете использовать, в моем случае wsdl /serverInterfaces logbus-management.wsdl logbus-filters.xsd, и получить как C # interface s, так и все типы данных в одном файле исходного кода C #. Если вы также сгенерируете прокси через Visual Studio, вы можете получить SOAP. Вам может понадобиться веб-служба (например, ASP.NET, возможно, в serverless mode), но я не уверен, что вы можете запустить SOAP с удаленным взаимодействием (вам следует) или использовать WCF.
Надеюсь, я вам помог.
Последующий
Теперь вам нужно использовать Remoting, чтобы позволить процессу связаться. Здесь Я нашел учебник. Ваш скелет код должен выглядеть следующим образом:
using System;
namespace addsubs
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public class addsubs : MarshalByRefObject, IMultiplier //what you compiled from WSDL
{
public int product;
public int multiply(int a, int b)
{
product = a * b;
return product;
}
}
}
Оба приложения должны совместно использовать интерфейс IMultiplier (или любой другой), а затем , когда вы получаете ссылку на ваш каркасный объект (через локальный прокси *) 1039 *, который .NET должен создать для вас), приведите его к IMultiplier
Примечание для других пользователей
У меня нет прямого опыта работы с .NET Remoting, как я уже сказал. Пожалуйста, не отрицайте мой ответ, если то, что я только что сказал, неверно. Вместо этого, пожалуйста, помогите нашему другу достичь своей цели.
Спасибо