| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
Как не нужно писать веб сервисы Суммарий нашего опыта использования технологии .Net XML Web Services, представленный в виде "от противного". Как НЕ надо писать веб-сервисаИз всего богатого арсенала платформы .Net пока наиболее востребованными оказались технологии ASP.Net и Web Services, используемые для написания серверных приложений. До массового написания на .Net клиентских приложений дело еще не дошло, хотя сообщения об этом уже пояляются. С ASP.Net все понятно - ее можно рассматривать просто как удобную замену ASP. Что касается web-services - что же это на самом деле? Сразу оговорюсь, что в рамках этой статьи мы рассматриваем только "XML Web Services Created Using ASP.NET". Функционально, Web Service - это класс, со своим набором свойств и методов, которые доступны для вызова через удаленное соединение по протоколу HTTP. При каждом вызове как запрос, так и ответ представляется в виде XML. Более подробное описание вы найдете в статье [1]. Первые попытки серьезного применения новой технологии вместе с радостью новизны приносят и свой негативный опыт. Реклама (а часто и документация) расхваливает удобство и красоту, ничего не говоря об ограничениях и недостатках. Тем не менее такая информация важна - она наряду с набором возможностей очерчивает область применения технологии. Этот текст обобщает опыт использования веб-сервисов в наших проектах. Я не претендую на полноту или истину в последней инстанции. Не забывайте что нет правил без исключений. Мне лишь хотелось бы чтобы вы не повторили описанных здесь ошибок. Веб-сервис как класс В самом деле - веб-сервис представляется классом. Он порождается от класса System.Web.Services.WebService, имеет свои свойства и методы. А раз это класс, то можно создавать экземпляры объектов этого класса. Тогда можно делать и так: Dim ws As FooWS.Foo = New FooWS.Foo ws.Login(name, password) ws.GetData() ws.SaveData() ws.Logout() Вроде бы все прекрасно - за одним исключением. Переменная ws хранит ссылку на объект, но это - не экземпляр веб-сервиса - ведь тот объект может быть создан только на сервере. Вызовом New FooWS.Foo мы создаем proxy-класс, обращения к которому приводят к вызовам веб-методов. В общем случае, при КАЖДОМ вызове экземпляр (объект) класса FooWS.Foo создается на сервере заново. А значит, значения, хранящиеся в этом объекте, теряются. Тем самым, состояние этого объекта не хранится между вызовами (что и называется "stateless"). Поскольку класс является stateless, то и писать его нужно соответственно:
Наследование на веб-сервисах Как и для любых других полноценных классов, для веб-сервисов можно применять наследование. Вы даже можете составить целую иерархию таких классов. О преимуществах говорить не буду - скажу только о недостатках. Сколько бы ни было у вас веб-сервисов - 1 или 100, располагаются ли они в одном проекте или в нескольких - но чтобы использовать их где-то еще кроме вашего проекта вы должны на КАЖДЫЙ из них установить ссылку (web-reference). Это несколько ограничит ваши возможности как великого объектного архитектора. Каждая web-reference задает свой namespace (например, в приведенном выше примере ссылка будет называться FooWS и namespace будет иметь то же название). Если вы породите два класса (например, Foo1 и Foo2) от одного родительского класса (Foo, порожденного от WebService), то для их использования на клиенте вам придется завести две ссылки (FooWS1 и FooWS2), причем объекты, объявленные в проекте веб-сервиса глобально, будут доступны на клиенте под двумя именами (в нашем примере FooWS1.MyDataSet и FooWS2.MyDataSet). Это только усложняет программирование и ничего полезного в себе не несет. Итак. Наследование на веб-сервисах не дает нам фактически ничего, кроме новых проблем. Инкапсуляция данных в класс веб-сервиса бессмысленна - поскольку эти данные не сохраняются между вызовами. Получается, что от объектного подхода, применительно к веб-сервисам, практически ничего не остается. Скорее это библиотека статических методов, собранных в одном модуле под одним именем, причем вызовы этих методов довольно "тяжелы" (не в смысле трудности в реализации или использовании, а в смысле эффективности). Передача параметров: Упаковка параметров в строку или XML VB6, предшествующий своему насквозь объектному собрату VB.Net, накладывал определенные (и довольно суровые) ограничения на передачу структур данных в виде параметров методов и в качестве возвращаемых значений. Эти правила тем более суровы если речь идет о межкомпонентных вызовах. Поэтому для VB-программиста является привычным и естественным передавать сложные данные каким-либо другим способом - например, упаковав все параметры в строку. Более того, шумиха вокруг XML приводит к тому что многие считают естественным упаковывать и параметры, и результат, в формат XML. VB.Net лишен недостатка своего "младшего" собрата - вы можете как передавать, так и возвращать сложные структуры данных. Для веб-сервиса автоматически создается proxy-класс, решающий проблемы преобразования любых передаваемых типов и структур в/из XML. И запрос, порождаемый вызовом, и результат передаются в виде XML. Тем самым, ручная упаковка в/из строки или (тем более) XML только добавит лишний код - а возможно и лишние ошибки. [Тут надо заметить, что сложные объектные структуры (передаваемые web-сервисам или возвращаемые от них) могут создаваться на основе дополнительной библиотеки классов, либо использовать возможности DataSet. В любом случае, библиотека классов или схема данных DataSet должна присутствовать и на сервере, и на клиенте.] Использование веб-сервиса как компонента Предположим что архитектура нашей системы состоит (полностью или в основном) из веб-сервисов. Тогда каждый веб-сервис рассматривается в качестве отдельного компонента, выполняющего свою функцию. Эта функция четко определена, разные компоненты могут писать разные люди. В общем, получаем все достоинства компонентного подхода. В чем же недостатки этого пути?
Резюме - а как надо? Вопрос о том, целесообразно ли использование той или иной технологии, всегда можно решить только применительно к конкретной задаче. Но можно заранее сказать, что web-service будет хорошим решением в каком-либо из следующих условий:
|
|
| ||||||||||||||||
|