Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс "Обзор перспективных технологий Microsoft. Net"




Скачать 162.45 Kb.
НазваниеКурс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс "Обзор перспективных технологий Microsoft. Net"
Дата публикации23.05.2013
Размер162.45 Kb.
ТипЛекция
uchebilka.ru > История > Лекция

Курс «Обзор перспективных технологий Microsoft.NET»

Губанов Ю.А., математико-механический факультет СПбГУ

Курс "Обзор перспективных технологий Microsoft.NET"

Лекция 4. Архитектура SOA, веб-сервисы, WCF и стандарты WS-*


(2 лекции)

Распределенное исполнение


Как всегда, для начала мы обсудим историю и прагматику вопроса. Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна WCF. Мы рассмотрим предшествующие и существующие технологии, и поймем, а есть ли действительно нужда в новой технологии Microsoft, или же мы вполне обошлись бы существующими старыми.

Как уже отмечалось в предыдущих лекциях, кроме лени и стремления программистов к гармонии, развитием технологий в основном движет жажда наживы.  Более политкорректно – стремление к удешевлению разработки.

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

Второй, не менее естественной причиной для обоснования необходимости распределенного исполнения является необходимость передавать данные через интернет. Это может быть обмен данными между филиалами вашей компании в рамках одного приложения, может быть интерактивное общение вашего серверного приложения с заокеанским пользователем, а может быть общение с совершенно «левым» сервисом, который нашел ваш сервис с помощью загадочного механизма UDDI или еще более загадочных стандартов WS-*.
^

История распределенного исполнения


Итак, какие же вехи в истории распределенного исполнения мы знаем? В первой лекции мы обсуждали COM и DCOM, которые были первыми технологиями Microsoft для распределенного исполнения (DDE не в счет). В отличие от COM, рассчитанного на взаимодействие внутри одной машины, DCOM позволял приложениям общаться по сети, хоть и делать это с помощью этой технологии было весьма непросто. Чем неудобен DCOM?

    • Попробуйте управлять форматом и каналами передачи сообщений

    • Попробуйте трассировать и журналировать вызовы DCOM

    • Попробуйте использовать DCOM в Internet и с разными клиентами

    • Попробуйте быстро поменять конфигурацию приложения, например, используемые порты и каналы

У DCOM существовали (существуют) альтернативы, из мира не-Microsoft, среди них можно упомянуть CORBA (Common Object Request Broker Architecture консорциума Open Management Group), RMI (Java Remote Method Invocation от компании Sun Microsystems), EJB и DCE (Distributed Computing Environment, предложенная ассоциацией Open Group). У этих технологий есть свои достоинства и недостатки, которые мы обсуждать не будем.

В мире же Microsoft DCOM, плавно перешедший в COM+ и Enterprise Services, сменила технология Remoting, хорошо знакомая вам по первому релизу Microsoft.NET. Кроме того, что Remoting позволяет общаться между собой приложениям на managed коде (что уже является большим плюсом), он гораздо гибче в настройках каналов и протоколов, в том числе, что важно, в «post deployment», т.е. после развертывания. В стиле .NET это делается с помощью cfg-файлов. По умолчанию Remoting поддерживает http и tcp, и имеет различные форматтеры (упаковщики сообщения в поток) – по умолчанию бинарный и xml.

Недостатком технологии является то, что NET Remoting не стандартизирован, платформенно- и вендорно-зависим, кроме того, технология требует .NET Framework на клиенте (и, естественно, на сервере). У Remoting есть и другие недостатки, которые будут лучше видны в сравнении этой технологии с технологией веб-сервисов, к которым мы с вами плавно и перейдем.

SOA


Архитектура, ориентированная на сервисы (SOA), реализацией которой являются веб-сервисы, является модной темой уже не менее пяти лет. В последнее время моднее обсуждать AJAX, но SOA пока не совсем сдала позиции. 

В рамках этой архитектуры совершенно различные программы (сервисы) могут общаться между собой как на одном компьютере, так и в локальной сети, и даже в среде интернет, несмотря на имманентную гетерогенность последней. Эти сервисы могут быть реализованы на любом языке программирования и работать на любой платформе, что не препятствует возможности их общения, покуда они используют набор стандартизованных открытых механизмов. Такой набор для веб-сервисов – это «святая троица» WSDL, SOAP и UDDI, работающие поверх HTTP как транспортного протокола и XML как формата передачи данных.

  • В основе SOA лежит понятие сервисов, являющихся базовыми элементами для построения бизнес-приложений и обеспечения взаимодействия между ними

  • В архитектуре SOA приложение рассматривается как сервис, который можно найти, и далее получить доступ к нему через локальную сеть или интернет

  • Приложение может реализовать некую функцию или набор функций как самостоятельно, так и путем обращения к другим сервисам

  • Сервисы являются автономными, но для того, чтобы их можно было найти и использовать, они снабжены соответствующими интерфейсами


Основу SOA составляет взаимодействие трех участников:

  • Поставщика сервиса

  • Потребителя сервиса

  • Реестра сервисов
^

Где находится нофелет?


Вопросы:

  • Где находится реестр сервисов?

  • Как вы "связываетесь" с этим реестром?

  • Как вы поймете, что некий сервис выполняет то, что вам надо?

  • Как вызвать сервис?

  • Как передавать параметры и принимать возвращаемые значения?

  • Зависит ли формат общения от реализации сервиса? Вашей программы? Используемой ОС? Протоколов передачи данных? Фазы луны?


Для реализации SOA необходимы следующие соглашения:

  • Транспортное соглашение – о форматах и протоколах взаимодействия

  • Соглашение об описании функциональности сервиса в виде, пригодном для автоматической генерации кода, который определяет процесс взаимодействия между клиентом и поставщиком сервиса

  • Соглашение о способе обнаружения сервиса
^

Стандарты веб-сервисов (тезисно)


Основные стандарты – транспортный, SOAP; описание интерфейса, WSDL; обнаружение сервиса, UDDI.

Simple Object Access Protocol

  • Позволяет обмениваться структурированной информацией

  • Каждое сообщение помещается в «конверт» SOAP – единицу обмена сообщениями:

Web Services Description Language

  • Специфицирует интерфейс веб-сервиса:

    • Форматы сообщений

    • Типы данных

    • Протоколы

    • Точки подключения (endpoints)

  • WSDL-файл – контракт между сторонами

Universal Description, Discovery and Integration

  • Опубликование и обнаружение веб-сервисов

  • «register once, published everywhere» (напоминает DNS)

    • http://uddi.org

    • http://uddi.microsoft.org

    • Русский uddi - http://www.uddi-russia.org

  • Регистр: белые, желтые и зеленые страницы. Сервис: disco-файл

  • Альтернатива UDDI/SOAP – протокол ebXML


Что такое WSE

  • Web Services Enhancements – add-on (class library) к Visual Studio.NET, последняя версия – 3.0

  • Поддержка механизмов безопасности, надежной доставки, координации распределенного выполнения для веб-сервисов и т.д.

Мы обсудим с вами WS-* стандарты, часть из которых поддержана в WSE 3.0 и будет поддержана в WCF, на отдельной лекции.
^

Предпосылки появления WCF


Мы обсудили вкратце предыдущие технологии; в основном, все они всё еще широко применяются в сельском хозяйстве. Так зачем же нужна новая? Чем плохи предыдущие технологии?

Вместе с .NET Framework Microsoft предоставляет две конкурирующие технологии распределенного исполнения – Remoting и Web-services. Вообще говоря, сервис Remoting может быть представлен как веб-сервис, если его хостом является IIS, и выбраны соответствующие каналы (HTTP) и форматтеры (SOAP). Однако при этом Remoting не подпадает под WS-* стандарты, которые жизненно необходимы для реализации нетривиального взаимодействия сервисов. Remoting требует .NET Framework на клиенте. Веб-сервисы же плохи тем, что реализуют лишь один способ взаимодействия – через HTTP/SOAP и лишены гибкости Remoting в выборе средств коммуникации. Кроме того, хостом веб-сервиса может быть только IIS (или другой веб-сервер, поддерживающий ASP.NET).

Кроме отдельных недостатков этих технологий, у них есть как минимум один общий недостаток – то, что их две. Это соображение (а как мы говорили, соображения всеобщей унификации и интеграции являются сейчас очень модными) и привело к созданию единой технологии, объединяющей все лучшее из remoting и веб-сервисов, дающей вашим приложениям гибкость в выборе средств общения, оставляя в то же время возможности interoperability, проще говоря – взаимодействию, основанному на открытых стандартах WS-*.

Итак, технология WCF – это единый фреймворк и единое API для интероперабельных сервисов.
^

Составные части WCF


Технология Windows Communication Foundation (WCF), ранее носившая кодовое название Indigo, является одной из частей нового API будущих версий Windows. Это API носит название .NET Framework 3.0 (бывший WinFX).

WCF – это модель программирования и среда исполнения для создания, конфигурации и развертывания распределённых сервис-ориентированных приложений. WCF, аналогично WPF, состоит из фреймворка (рантайм-поддержки или среды времени исполнения), и соответствующего API для создания .NET приложения с использованием этой технологии.

Вот основные лозунги Microsoft относящиеся к WCF:

  • Унификация. WCF – универсальная технология, объединяющая в себе достоинства предыдущих подходов. Работает как на одной машине, так и в сетях – локальных или интернете

  • Ориентация на сервисы. Microsoft постаралась собрать лучшие приемы для создания распределенных решений

  • Интеграция. Возможность взаимодействия с приложениями на других платформах за счет поддержки открытых стандартов WS-*.
^

Действующие лица WCF


Здесь и в дальнейшем сервисы, реализованные с помощью WCF, мы будем называть WCF-сервисами или, короче, сервисами, чтобы не путать с «обычными» веб-сервисами. Под «обычными» веб-сервисами мы будем подразумевать ASP.NET веб-сервисы в интерпретации Microsoft. Все это не надо путать с сервисами Windows, которые мы так и будем называть.

Итак, основным действующим лицом в WCF является WCF-сервис, работающий на сервере. В отличие от веб-сервисов, хостом которых мог быть только IIS (и другие ASP.NET-совместимые веб-сервера), хостом WCF-сервиса может быть любое .NET приложение Windows – Windows Forms, консольное, ASP.NET-приложение, сервис Windows. Кроме того, в Vista появляется загадочный хост WAS (Windows Activation Services), который, по утверждению Microsoft, обеспечивает всю функциональность IIS без самого IIS (новый IIS 7 построен поверх WAS).

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

Для того чтобы определить WCF-сервис, нужно создать так называемую «точку доступа» (end-point). Точка доступа характеризуется тремя параметрами, которые в Microsoft называют «алфавитом» (ABC):

  • Адрес (Address) – где находится сервис. Адрес представляет из себя обычный URI

  • Связывание (Binding) – каким образом соединяться с сервисом. Аналогично Remoting, Microsoft предоставляет как стандартные реализации для связывания, так и custom binding

  • Контракт (Contract) – интерфейс сервиса и описание типов данных, с которыми он работает. Вспоминаем WSDL. 
^

Создание WCF-сервиса


Создание WCF-сервиса начинается с разметки класса, реализующего требуемую функциональность. Разметка класса специальными атрибутами поможет WCF создать за нас контракт сервиса. Итак, чтобы подсказать WCF, что некоему классу судьбой предназначено стать WCF-сервисом, мы используем атрибут ServiceContractAttribute:

[ServiceContract]

public class HelloWCF

{

}

Далее нам надо создать метод, реализующий некоторую функциональность будущего endpoint’а. Это мы делаем с помощью атрибута OperationContractAttribute:

[OperationContract]

public string GetPreved()

{

return “Preved, WCF!”

}

Заметим, что методы класса, у которых атрибут OperationContract отсутствует, «выставляться наружу» не будут. Важно также, что на видимость метода как метода сервиса не влияют атрибуты видимости (типа public/private).

Надо всем над этим надо не забыть написать using System.ServiceModel – главный namespace WCF.

Собственно, теперь у нас есть полная реализация контракта сервиса! Осталось только «захостить» его, выбрав любой один из возможных вариантов хост-приложения, которые перечислены выше. Таким образом, нам осталось A и B. Предлагается для начала создать консольное приложение:

static void Main(string[] args)

{

ServiceHost helloHost = new ServiceHost();
helloHost.AddEndpoint(

typeof(HelloWCF),

// стандартное связывание, поддерживающее Basic Profile,

// который мы обсудим на лекции про WS-* стандарты.

// Используйте это связывание для соединения по HTTP

// протоколу с использованием SOAP

new BasicProfileBinding(),

“http://localhost:8080/prevedService”);

// Запускаем прослушивание

helloHost.Open();
// Выводим подсказку и останавливаем основной поток

Console.WriteLine("ПРЕВЕД, нажми Enter, чтобы МЕДВЕД");

Console.ReadLine();
// Так надо

helloHost.Close();

}

Все, сервис готов! Компилятор, пользуясь нашими любезно предоставленными атрибутами, не менее любезно сгенерирует нам wsdl, который мы, аналогично wsdl веб-сервиса, уже можем потестировать через браузер без написания клиента сервиса. Как всегда, для этого надо набрать Uri сервиса с параметром wsdl: http://localhost:8080/?wsdl. Кроме того, аналогично веб-сервисам, с помощью специальной утилиты (svcutil.exe) можно сгенерировать прокси для работы с WCF-сервисом и все используемые в этой работе типы.

После того, как svcutil сгенерирует прокси-классы для работы с сервисом, создание клиента – дело двух строчек:

HelloWCFProxy prevedProxy = new HelloWCFProxy(

new EndpointAddress(http://localhost:8080/prevedService),

new BasicProfileBinding()

);

MessageBox.Show(prevedProxy.GetPreved());

prevedProxy.Close();

Наконец, отметим, что вы можете добавлять сколько угодно endpoints к вашему сервису (в отличие от веб-сервисов, где был только один аналог endpoint’а) – с разными Uri, связыванием и контрактами.
^

Конфигурирование WCF-сервисов


В примере выше мы указали параметры для создания endpoint’а и для соединения клиента с сервисом в самом коде. В духе Remoting мы можем аналогичным образом сконфигурировать наш сервис декларативным способом с помощью конфигурационных файлов (собственно, второй способ предпочтительней). Для этого надо заполнить секцию system.serviceModel в файле конфигурации приложения сервиса (прямой сын тэга ):








bindingSectionName=”basicPrevedBinding”

contractType=”HelloWCF”/>







Как видите, мы задали все три части endpoint’а. По счастливому совпадению, класс, реализующий контракт, совпал с типом контракта, но это необязательно так всегда. Класс, реализующий контракт, может наследоваться от интерфейса, который помечен соответствующим атрибутом. Не забывайте также, что у сервиса может быть много endpoint’ов, соответственно, в этом случае без интерфейсов не обойтись.

Несложно проверить в этом месте, не спит ли аудитория. Если она заметила связывание типа basicPrevedBinding, то с некоторой долей вероятности нет.

Аналогично конфигурируется и клиент:






bindingSectionName=”basicPrevedBinding”

contractType=”HelloWCF”/>





В обоих случаях (сервиса и клиента) указание их данных в конфигурационным файлах позволяет вам не писать эти данные в коде. Наверное, не стоит и обсуждать, насколько это удобно – уметь менять такие свойства после развертывания приложения, т.к. эти вопросы уже обсуждались с аудиторией на предыдущих курсах.

Заметьте, что, в отличие от контрактов, endpoint’ы не описываются с помощью атрибутов – только в коде или в конфигурационном файле.
^

Контракты данных


Прекрасно, мы уже умеем писать простые приложения с помощью WCF. В нашем сервисе единственный метод не принимал никаких параметров, и возвращал простой тип. Однако создатели более сложных сервисов обязательно столкнутся с ситуацией, когда требуется передать класс или структуру. Такие сложные типы надо описывать специальным образом с помощью атрибутов DataContract и DataMember:

[DataContract]

class Medved

{

[DataMember]

public string WomanName;

[DataMember]

private string ManName;

public string MedvedName;

private DateTime MeetingTime;

}

При передаче такого класса с помощью сервиса передадутся только те поля, которые помечены атрибутом DataMember. Заметьте, что видимость членов не имеет значения (private поле ManName будет сериализовано наравне с WomanName). Поля же, не помеченные как DataMember, не передадутся опять-таки вне зависимости от видимости.

Особо стоит подчеркнуть, что ни контракты сервисов, ни контракты данных не возникают ни в каких ситуациях автоматически, по умолчанию. Программист должен самостоятельно пометить все необходимые сущности, участвующие во взаимодействии. Это находится в согласии с принципом, гласящим, что сервисы должны иметь явные границы, когда должно быть понятно, где мы работаем с локальным объектом, а где – с объектом извне нашего домена приложения.
^

Стандартные виды связывания (bindings)


Связывание (binding) – одна из частей святой троицы ABC – определяет то, каким образом вы можете достучаться до endpoint’а: какой использовать транспортный протокол (HTTP, TCP, прочие) и каким образом происходит обмен сообщениями (обычный или бинарный SOAP, поддержка WS-*).

WCF предлагает программисту набор стандартных байндингов:

  • BasicProfileHttpBinding: связывание по умолчанию, которое удовлетворяет стандарту WS-I Basic Profile 1.0. Это связывание SOAP поверх HTTP

  • BasicProfileHttpsBinding: то же самое, только поверх HTTPS

  • WsHttpBinding: связывание, которое поддерживает надежный обмен сообщения с помощью стандарта WS-ReliableMessaging. Также поддерживает стандарт безопасности WS-Security и стандарт исполнения транзакций WS-AtomicTransaction. Это связывание стоит выбирать для создания сервиса, способного общаться с другими сервисами посредством открытых стандартов WS-*, в частности, с сервисами, созданными и работающими вне WCF

  • WsDualHttpBinding: аналог WsHttpBinding, поддерживающий дуплексное общение (когда и клиент и сервис могут получать и посылать сообщения)

  • NetTcpBinding: связывание только для сервисов внутри WCF (бинарный SOAP поверх TCP). Поддерживает надежную доставку, безопасность и транзакции

  • NetNamedPipeBinding: связывание только для сервисов внутри WCF, работающих на одной машине (бинарный SOAP поверх именованных каналов). Впрочем, для подобного взаимодействия рекомендуется по-прежнему использовать Remoting

  • NetMsmqBinding: для взаимодействия с помощью MSMQ, обсуждать не будем.
^

Другие возможности WCF-сервисов


Вкратце опишем другие возможности WCF-сервисов:

  • Возможность одностороннего (one-way) общения, когда вызов сервиса не должен возвращать какого-либо значения. Регулируется атрибутом OperationContract:



[OperationContract(IsOneWay = true)]
void helloWCF();


  • Возможность дуплексного (dual) общения, когда и клиент и сервис могут посылать и получать сообщения. Регулируется атрибутом ServiceContract:



[ServiceContract(CallbackContract = typeof(IHelloWCF)]


  • Возможность управлять поведением сервиса (аналогично Remoting’у – Singleton и SingleCall). Регулируется параметрами атрибута ServiceBehaviour:
    [ServiceContract]
    [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
    (один клиентский запрос к сервису в каждый момент времени, однопоточный сервис)
    [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
    (возможно, более одного запроса к сервису, каждый запрос в своем потоке)
    Другой параметр этого атрибута, InstanceContextMode, контролирует, каким образом создаются экземпляры сервиса: PerCall (каждый раз новый экземпляр для нового вызова, аналог SingleCall Remoting’а) и PrivateSession (один экземпляр для всех вызовов одного клиента, НЕ аналог Singleton, т.к. один клиент).

  • Выбор множества транспортных протоколов: кроме упомянутых HTTP и TCP, это еще и Peer2Peer, MSMQ и возможность подключения собственного протокола

  • Поддержка WSE (рассмотрим чуть позже)
^

Отличия от Web-сервисов


Если вы программировали веб-сервисы, WCF-сервисы во многом будут вам знакомы. Но, несмотря на их похожесть, есть и некоторые различия:

  • Много endpoints. Кроме задания некоторого Uri, мы добавили в сервису endpoint, чего раньше не было, т.к. веб-сервисы могли иметь только одну точку соединения. Точки соединения могут различаться любыми частями ABC как по отдельности, так и вместе.

  • Сессии на уровне сервиса, а не на уровне метода, как это в веб-сервисах. Сохранение сессии на уровне сервиса более соответствует духу SOA.

  • Хостинг – если веб-сервисы хостятся только в IIS, WCF-сервисы могут хоститься в гораздо большем количестве хостов, что мы обсуждали чуть раньше

  • Поддержка различных протоколов: HTTP, TCP, MSMQ, UDP, IPC, custom. Поддержка различных способов взаимодействия: client-server, Peer2Peer.

  • Расширенная поддержка WS-* стандартов
^

Отличия от Remoting-приложений


  • Не требуется .NET Framework на клиенте

  • Remoting не поддерживает WS-* стандарты

Текущая и будущая поддержка WCF


WCF войдет в будущую операционную систему Microsoft – Windows Vista, но по многочисленным просьбам телезрителей WCF был также поддержан на Windows XP SP2 и Windows 2003. То же самое касается и WPF (ex-Avalon).

Уже сейчас (на момент создания курса, лето 2006 года) можно скачать и посмотреть упомянутые технологии в их предварительных версиях на существующих версиях Windows (XP и 2003) и на бета-версии Vista.
^

Альтернативные технологии


Какими критериями надо пользоваться, чтобы выбрать правильную технологию для реализации пользовательского интерфейса в вашем приложении? Какие технологии надо рассматривать и как сделать выбор?

  • Remoting
    Эту технологию следует выбирать, если вы реализуете междоменное взаимодействие. Также стоит оставаться на технологии Remoting в случае, если вы реализовали custom протоколы или форматтеры (в этом случае для перехода на WCF потребуются значительные правки кода)

  • Web-services
    Все еще следует выбирать для создания бизнес-приложений, в рамках которых создаются интероперабельные веб-сервисы, поддерживающие WS-* стандарты. В конце концов, WCF еще пока не выпущен

  • DCOM
    Следует выбирать мазохистам, крутым парням, а также тем, кто до сих пор использует Windows 95.

  • Windows Communication Foundation
    Следует выбирать исследователям, студентам, а также тем, кто уже сейчас хочет создавать интероперабельные сервисы будущего и кого не пугает текущий статус беты этой технологии. После финального релиза эта технология – выбор для всех ситуаций, кроме, возможно, междоменного взаимодействия.

Ссылки


http://blogs.msdn.com/richardt/archive/2004/03/05/84771.aspx – Remoting не исчезнет

http://www.topxml.com/WSCF-WCF/re-4947_Serialization-vs--Encoding.aspx – Сериализация и encoding

http://en.wikipedia.org/wiki/Windows_Communication_Foundation – Википедия про WCF

http://windowscommunication.net/Default.aspx?tabindex=0&tabid=1 – Собственно, от автора (полезный раздел «самплы»)

http://msdn.microsoft.com/winfx/technologies/communication/default.aspx – MSDN про WCF

http://msdn.microsoft.com/windowsvista/support/faqs/communication/default.aspx – FAQ про WCF

http://blogs.msdn.com/drnick/default.aspx – блог одного из создателей WCF

http://staff.newtelligence.net/clemensv/PermaLink,guid,5df62c43-67fb-488e-a70e-c29b9055a984.aspx, http://staff.newtelligence.net/clemensv/PermaLink,guid,b2d3cfa1-f3c3-4aed-8ec7-503fe5c21f51.aspx и http://staff.newtelligence.net/clemensv/PermaLink,guid,41d6ef20-e3e1-4277-bd3e-2cf414d209bd.aspx – блог с интересными техническими деталями реализации сервисов WCF

http://mtaulty.com/blog/(bdneuwaxcrmiowrztkaxxeud)/default.aspx – еще один блог с интересностями о WCF (например, http://mtaulty.com/blog/(yyz4yxqla3jvur551ut2tkiu)/archive/2005/04/04/1761.aspx)



Курс создан при поддержке Microsoft и Belkasoft (http://belkasoft.com)

Добавить документ в свой блог или на сайт

Похожие:

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А.,...
Итак, на прошлой лекции мы упомянули то, что не все концепции окружающего мира хорошо укладываются в объектно-ориентированное представление....

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А.,...
«На сегодня о технологии ajax (Asynchronous JavaScript and xml) широкие массы пользователей интернета знают немного. Пока эта технология...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А.,...
Зачем нужно распределенное исполнение, какова его славная история и зачем вообще нужна wcf. Мы рассмотрим предшествующие и существующие...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А.,...
Надо сказать, задолго до появления Turbo Vision уже были и графические интерфейсы (Mac) со своим инструментарием. Turbo Vision же...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconИнструмент разработчика — ms visual Studio. Net
Поэтому, продвигая платформу. Net, компания Microsoft предлагает также инструментарий для программистов — Visual Studio. Net и систему...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Технологии Windows Communication Foundation и Windows Presentation...
Курс «Технологии Windows Communication Foundation и Windows Presentation Foundation»

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconКурс «Разработка компиляторов на платформе. Net» © Андрей А. Терехов, Наталья Вояковская
В качестве целевой платформы для компиляторов в данном курсе используется Microsoft. Net. Подразумевается, что к моменту окончания...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" icon3 5 Обзор управления конфигурациями 5
Поскольку Microsoft должна реагировать на изменяющиеся рыночные условия, ее не следует интерпретировать как обязательство со стороны...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" icon3 5 Обзор управления уровнем сервиса 5
Поскольку компания Microsoft должна отвечать на изменение рыночных условий, этот документ не должен интерпретироваться как обязательство...

Курс «Обзор перспективных технологий Microsoft. Net» Губанов Ю. А., математико-механический факультет спбгу курс \"Обзор перспективных технологий Microsoft. Net\" iconИспользование современных технологий для построения распределенных систем
Дан краткий обзор процессов разработки и шаблонов проектирования. Кратко описаны варианты построения уровня пользовательского интерфейса,...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
uchebilka.ru
Главная страница


<