Должен ли удаленный интерфейс быть реализован с использованием SOA? - PullRequest
2 голосов
/ 01 сентября 2009

Ранее у нас были настольные приложения, но учитывая тот факт, что доступ к серверу (физически или удаленно) был нежелателен для клиента, мы превратили их в службы Windows , которые будут работать (теоретически) 24/7 .

Теперь нам нужно предоставить удаленный пользовательский интерфейс для этих служб, чтобы сохранить старые функциональные возможности и старый интерфейс.

Для этого мы собираемся разработать несколько сервисов SOA с использованием WCF. У нас будет один сервис для конфигурации, другой для, например, сетевой информации, статистики и т. Д., Чтобы сумма всех сервисов обеспечивала те же функциональные возможности, что и старый интерфейс, но была разделена на различные области функциональности.

У меня нет большого опыта работы с SOA, так ли это правильно? SOA подходит для удаленного интерфейса? Должен ли быть только один сервис или должны быть логические группы?

Примечание: У нас есть несколько приложений, которые получают доступ к некоторой части информации об услуге, поэтому мы делаем это логическое разделение.

Редактировать: Стоит ли реализовывать какие-либо меры безопасности в отношении того, кто может подключаться и к чему может иметь доступ на раннем этапе? Я вижу это с большим предупреждением ЯГНИ, но, возможно, я ошибаюсь.

Меня интересуют всевозможные предложения о том, как реализовать удаленный пользовательский интерфейс, существующие платформы, лучшие подходы, преимущества и недостатки использования SOA и т. Д.

Ответы [ 3 ]

2 голосов
/ 08 сентября 2009

Когда вы говорите «Remote UI», я думаю, что вы на самом деле имеете в виду, что у вас есть некоторые операции, которые выполняются на удаленном сервере, но вызываются удаленно через API.

Удаленный пользовательский интерфейс будет означать, что пользовательский интерфейс работает на сервисном компьютере, а пользователи взаимодействуют с сервисом через спроектированный пользовательский интерфейс, например, что-то вроде терминальных служб.

Представление работы, выполняемой службой в API SOA, вероятно, является наилучшим путем, который вы хотите выбрать. Затем вы можете реализовать пользовательский интерфейс в Winforms, Silverlight, ASP.Net или любом другом в будущем. SOA - это очень много для многих людей, но мне нравится думать о нем как о граничной точке в системе, где каждая сторона не знает деталей реализации другой стороны.

Решение о гранулярности сервисов не всегда очевидно, но если вы попытаетесь задуматься о функциональности, которую вы предоставляете потребителям сервиса, а не только о приложении UI, которое вам поручено реализовать в настоящий момент. Эти вещи, конечно, не в камне, и вы можете рефакторинг по мере развития событий. Одно приложение может использовать несколько сервисов, поэтому проблем в этом нет.

В том месте, где я работаю, мы обычно сначала реализуем функциональность, а потом отвечаем на вопросы безопасности. Ваши требования безопасности, конечно, будут конкретными, но вам необходимо учитывать такие вещи, как чувствительность данных, к которым осуществляется доступ, или функции, которые пользователь может вызывать через службу. если служба используется внутри вашей сети или обнародована через Интернет, и вероятность того, что пользователи будут пытаться действовать злонамеренно. например, маловероятно, что бизнес-пользователь скачает копию Visual studio и создаст свой собственный клиент WCF, чтобы вызвать хаос, но все возможно.

1 голос
/ 01 сентября 2009

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

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

Если у вас нет книги Ювала Лоуи, Программирование служб WCF , я настоятельно рекомендую вам получить копию. Это отличный справочник WCF. Вы также можете посетить его сайт, IDesign.net , чтобы найти множество свободно доступных примеров кода WCF.

0 голосов
/ 10 сентября 2009

Мое мнение касается интерфейса пользователя переднего плана, веб-сервис на основе SOAP может быть тяжелым, а производительность может стать проблемой при увеличении нагрузки, вместо этого пользовательский сервис на основе REST для внешнего интерфейса и сервис на основе SOAP для вашей бизнес-логики и оркестровки, так что вы добиться масштабируемого приложения с хорошей производительностью.

Я думаю, что WCF поддерживает как SOAP, так и REST-сервисы, REST-сервисы легки и технологически нейтральны, так как основаны на простом HTTP.

...