Содержание к диссертации
Введение
1. Архитектура распределенных информационных систем (РИС) 10
1.1. Характеристики РИС 10
1.1.1. Отказоустойчивость 11
1.1.2. Открытость 14
1.1.3. Прозрачность 14
1.1.4. Масштабируемость 15
1.1.5. Безопасность 16
1.2. Архитектуры программного обеспечения распределённых
информационных систем 16
1.2.1. Базовая модель «клиент-сервер» 16
1.2.2. Сервис-ориентированная архитектура (SOA) 19
1.3. Web-сервис 22
Выводы по 1-й главе 25
2. Распределенные базы данных (РБД) 26
2.1. Основные принципы, правила построения и функционирования РБД 26
2.2. Проблемы при проектировании распределенных баз данных .29
2.3. Проектирования распределенных баз данных 31
2.3.1. Нисходящие проектирование 31
2.3.2. Восходящее проектирование з
2.4. Фрагментация данных 36
2.5. Репликация данных 43
2.6. Управление распределенными транзакциями 48
Выводы по 2-й главе 52
3. Проектирование информационных систем на основе SOA 53
3.1.Сервис-ориентированное моделирование и анализ 53
3.1.1. Идентификация сервиса 53
3.1.2. Классификация сервисов 54
3.1.3. Анализ подсистем 55
3.1.4. Спецификация компонентов 55
3.1.5. Размещение сервисов 56
3.1.6. Реализация сервиса 57
3.2. Слои SOA -приложений 57
3.4. Проектирование РИС «My eLibrary» на основе SOA 61
3.4.1. Разделение подсистем 62
3.4.2. Проектирование РБД 63
3.4.3. Проектирование сервисов 65
3.4.4. Реализация сервисов 69
3.4.5. Интеграция и обеспечение безопасности сервисов 78
Выводы по 3-й главе 81
4. Описание информационной системы «My eLibrary» 82
4.1. Использованные технологии 82
4.1.1. Asp.net MVC 3 82
4.1.2. ADO.NET Entity Framework 84
4.1.3. Windows Communication Foundation (WCF) 86
4.2. Структура информационной системы «My eLibrary» 88
4.2.1. Подсистема « Science category» 88
4.2.2. Подсистема «Social-Science category» 89
4.2.3. Подсистема «User Admin» 90
4.2.4. Подсистема «My eLibrary Web portal» 90
Модель информационного поиска 92
4.3. Реализация Web-сервисов 96
4.3.1. Создание контрактов 96
4.3.2. Выбор подходящей привязки 99
4.3.3. Определение конечных точек 100
4.3.4. Размещение сервисов 101
4.4. Реализация Web-приложение «My eLibrary portal» 104
4.4.1. Создание моделей 104
4.4.2. Создание котроллеров 105
4.4.3. Создание Представлений (Views) 107
4.4.4. Подготовка к взаимодействию с Web- сервисами 110
4.5. Преимущества РИС «My eLibrary» 112
Выводы по 4-й главе 113
Заключение 114
Список литературы 115
- Прозрачность
- Проблемы при проектировании распределенных баз данных
- Спецификация компонентов
- Подсистема « Science category»
Введение к работе
Актуальность темы исследований. Информационные системы играют сегодня все более важную роль в большинстве организаций. Во многих отраслях промышленности компании в значительной степени зависят от их информационных систем. В начале большинство информационных систем были разработаны для решения конкретных задач или поддержки определенных функций. Но сегодня типичное предприятие использует большое количество информационных систем. Эти системы, как правило, интегрированы таким образом, чтобы они могли работать вместе. В результате растет потребность в интеграции разнородных информационных систем. Проблемы разработки эффективных систем обработки информации актуальны уже несколько десятилетий. С самого начала создания подобных систем специалисты в области информационных технологий пытаются разработать, с одной стороны, эффективные средства интеграции функциональных и структурных компонентов, а, с другой, - простые способы управления каждым из них в отдельности.
Прослеживая историческое развитие систем обработки информации, можно видеть, что они прошли путь от монолитных систем мейнфреймового типа, к двух- и трехуровневым архитектурам "клиент-сервер". Далее приобретают популярность многослойные вертикальные структуры; т. е. налицо тенденция все более узкой специализации и распределения отдельных компонентов систем. В последнее время активно обсуждаются вопросы организации распределенных систем с использованием глобальных сетей и web- технологий, но лишь с появлением ряда стандартов в области организации управления сервисами стало возможным говорить о новом направлении - сервис-ориентированной архитектуре (SOA). Задача исследования подходов к построению распределенных информационных систем стала актуальной для разработчиков и архитекторов программного обеспечения.
Целью работы является исследование методов и программных средств построения распределенных информационных систем.
Для достижения данной цели в работе были поставлены следующие научные задачи:
изучение основных характеристик распределенных информационных систем;
анализ проблем построения распределенных информационных систем и предложение подходов и средств их решения;
выявление проблем распределенных баз данных (РБД) и предложение подходов и средств их решения;
разработка методики создания распределенных информационных систем и ее применение для построения системы поиска учебной литературы.
Объектом исследования являются распределенные информационные системы с распределенной базой данных.
Предметом исследования являются методы и процессы построения распределенных информационных систем на основе сервис-ориентированной архитектуры и РБД.
Достоверность научных результатов подтверждена теоретическими выкладками, данными по использованию разработанной системы поиска учебной литературы, а также сравнением полученных результатов с результатами, приведенными в научной литературе.
Научная новизна исследования состоит в следующем:
-
Предложена методика проектирования распределенных информационных систем, основанных на распределенных базах данных, что позволяет обеспечить своевременный и беспрепятственный доступ к информации.
-
Предложена технология реализации распределенных информационных систем с распределенной базой данных на основе сервис - ориентированной архитектуры.
-
На основе предложенной методики разработана и реализована информационная система поиска учебной литературы.
Методы исследования. В диссертационной работе использованы методы проектирования информационных систем на основе SOA, методы проектирования РБД, методы фрагментации и репликации данных.
Практическая значимость исследования определяется тем, что применение разработанного автором подхода к построению распределенных информационных систем позволяет уменьшить сложность интеграции разнородных информационных систем в организации, где необходимо повысить гибкость корпоративной инфраструктуры, снизить затраты на разработку приложений и увеличить скорость реагирования на меняющиеся требования бизнеса.
Материалы также могут быть использованы в учебном процессе вузов при изучении дисциплин: «Распределенные информационные системы», «Сервис-ориентированная архитектура».
Реализация результатов. Разработанные подход, методы и программные средства к построению распределенных информационных систем были реализованы в рамках тестовой системы поиска учебной литературы, обеспечивающей удобный доступ через Web-интерфейс к каталогу полнотекстовых документов и мультимедийных ресурсов, полнотекстовому поиску и поиску по атрибутам документов.
Апробация работы. Основные положения и результаты диссертации докладывались и обсуждались на 17-ой, 18-ой научных конференциях аспирантов и студентов «Радиотехника, электроника, энергетика» в МЭИ (ТУ) (г. Москва, 2000 – 2004 г.), на международной научно-методической конференции «Информатизация инженерного образования» ИНФОРИНО—2012 в НИУ «МЭИ».
Публикации. Основные результаты диссертационной работы, опубликованы в 5 печатных работах; в том числе 1 работа в издании, рекомендованном ВАК.
Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка использованной литературы и приложений. Диссертация содержит 121 страницу машинописного текста (без приложений).
Прозрачность
Характерной чертой распределенных информационных систем, которая отличает их от обычных, является возможность частичного отказа. Частичный отказ происходит при сбое в одном из компонентов распределенной системы. Этот отказ может нарушить нормальную работу некоторых компонентов, в то время как другие компоненты это никак не затронет. В противоположность отказу в распределенной системе отказ в нераспределенной системе всегда является глобальным, в том смысле, что он затрагивает все ее компоненты и легко может привести к неработоспособности всего приложения. Чтобы лучше понимать, насколько серьезен на самом деле конкретный отказ, были разработаны различные схемы классификации.
Поломка (crash failure) имеет место при внезапной остановке сервера, при этом до момента остановки он работал нормально. Важная особенность поломки состоит в том, что после остановки сервера никаких признаков его работы не наблюдается.
Пропуск данных (omission failure) возникает в том случае, когда сервер неправильно реагирует на запросы. Эту ошибку могут вызывать различные причины. В случае пропуска приема (receive omission) сервер может, например, не получать запросов. Отметим, что такая ошибка может произойти, в частности, и в том случае, когда соединение между клиентом и сервером установлено правильным образом, но на сервере не запущен процесс для приема приходящих запросов. Пропуск приема обычно не влияет на текущее состояние сервера, но сервер остается в неведении о посланных ему сообщениях.
Похожая ошибка — пропуск передачи (send omission) — происходит, когда сервер выполняет свою работу, но по каким-либо причинам не в состо 12
янии послать ответ. Подобная ошибка может произойти, например, при переполнении буфера передачи, если сервер не готов к подобной ситуации. Отметим, что в противоположность пропуску приема в данном случае сервер может перейти в состояние, соответствующее полному выполнению услуги для клиента. Впоследствии, если обнаружится, что имел место пропуск передачи, сервер, вероятно, должен быть готов к тому, что клиент повторно пошлет свой последний запрос.
Другие типы пропусков не имеют отношения к взаимодействию и могут быть вызваны ошибками в программе, такими как бесконечные циклы или некорректная работа с памятью, которые способны «подвесить» сервер.
Следующий класс ошибок связан с синхронизацией. Ошибки синхронизации (timing failures) возникают при ожидании ответа дольше определенного временного интервала. Слишком раннее предоставление данных легко может вызвать у принимающей стороны проблемы, связанные с отсутствием места в буфере для хранения получаемых данных. Чаще, однако, сервер отвечает слишком поздно, в этом случае говорят, что произошла ошибка производительности (performance failure).
Еще один важный тип ошибок — ошибки отклика (response failures), при которых ответы сервера просто неверны. Существует два типа ошибок отклика. В случае ошибки значения (value failure) сервер дает неверный ответ на запрос. Так, например, эту ошибку демонстрирует поисковая машина, систематически возвращающая адреса web-страниц, не связанных с запросом пользователя.
Другой тип ошибок отклика — ошибки передачи состояния (state transition failures). Этот тип ошибок характеризуется реакцией на запрос, не соответствующей ожиданиям. Так, например, если сервер получает сообщениє, которое он не в состоянии распознать, и никаких мер по обработке подобных сообщений не предусмотрено, возникает ошибка передачи состояния. В частности, сервер может неправомерно осуществить по умолчанию некие действия, производить которые в данном случае не следовало бы.
Весьма серьезны произвольные ошибки (arbitrary failures), известные также под названием византийских ошибок. Когда случается произвольная ошибка, клиент должен приготовиться к самому худшему. Например, может оказаться, что сервер генерирует сообщения, которые он в принципе не должен генерировать, но система не опознает их как некорректные. Хуже того, неправильно функционирующий сервер может, участвуя в работе группы серверов, приводить к появлению заведомо неверных ответов. Эта ситуация показывает, почему для надежных систем очень важна защита.
Произвольные ошибки похожи на поломки. Поломка — наиболее распространенная причина остановки сервера. Поломки известны также под названием ошибок аварийной остановки (fail-stop failures). В действительности аварийно остановленный сервер просто прекращает генерировать исходящие сообщения. По этому признаку его остановка обнаруживается другими процессами. Например, по настоящему дружественный сервер может предупредить нас о том, что находится на грани поломки.
Разумеется, в реальной жизни серверы, останавливаясь по причине пропуска данных или поломок, не настолько дружественны, чтобы оповестить нас о надвигающейся остановке. Другие процессы должны сами обнаружить «безвременную кончину» сервера. Однако в подобных системах остановки без уведомления (fail-silent systems) другие процессы могут сделать неверный вывод об остановке сервера. Сервер может просто медленно работать, то есть может иметь место ошибка производительности. И, наконец, возможно, что сервер производит случайные сообщения, которые другие процессы считают абсолютным мусором. В этом случае мы имеем дело с наиболее простым случаем произвольной ошибки. Подобные ошибки называют безопасными (fail-safe).
Другая важная характеристика РИС — это открытость. РИС, как правило, это открытые системы. Это означает, что они используют стандартные протоколы. В распределенных системах службы обычно определяются через интерфейсы (interfaces), которые часто описываются при помощи языка определения интерфейсов {Interface Definition Language, IDL)[\].
Проблемы при проектировании распределенных баз данных
Взаимодействие сервера указывает степень связи между серверами баз данных во время исполнения транзакции. Это определяет объем сетевого трафика, генерируемого алгоритмом репликации и обработки транзакций. Взаимодействие сервера зависит от количества сообщений, необходимых для обработки операций транзакций. Взаимодействие можно разделиться на постоянное взаимодействие и линейное взаимодействие. При постоянном взаимодействии для синхронизации серверов используется постоянное число сообщений, независимо от количества операций в транзакции.
Как правило, протоколы обмена одного сообщения за транзакцию выполняются путем группирования всех операций в одном сообщении. Постоянное взаимодействие обычно использует преимущества концепции транзакции. Так как транзакции могут содержать одну операцию или несколько операций, но идея заключается в создании одного сообщения для каждой транзакции, а не генерации сообщений на основе каждой операции. Линейное взаимодействие, которое обычно соответствует методам, где сервер баз данных распространяет каждой операции транзакции в расчете «per operation». Операции могут быть отправлены либо в виде SQL программы или записи журнала, содержащего результаты выполненной операции в конкретном сервере. Линейное взаимодействие работает в небольшой минимальной среде узлов, но когда он применяется в больших распределенных системах тысячи узлов, ограничена масштабируемость.
Здесь учитывается метод прекращения транзакций. Важно, чтобы координировать все реплики, когда транзакция была получена на сайте, для того, чтобы обеспечить атомарность при прекращении транзакции. Прекращение транзакции не так важно на производительность, как взаимодействие серверов, но оно может влиять на производительность репликации данных, доступность, и, самое главное целостности данных. Протокол прекращения транзакции - это процесс, посредством которого все серверы будут согласованы, чтобы либо прервать, либо совершить транзакции. Некоторые протоколы обеспечивают полную атомарность, но другие могут предложить лишь частичную атомарности. Кроме того, некоторые протоколы могут использовать один менеджер транзакций для управления прекращением транзакции, а некоторые протоколы могут использовать несколько менеджеров транзакций, это просто зависит от реализации. Прекращение транзакции может быть выполнено двумя разными способами: голосованное прекращение (Voting Termination) и прекращение без права голоса (Non-Voting Termination)[5]. Голосованное прекращение (Voting Termination) требует дополнительного раунда сообщения для координации различных реплик. Этот раунд может быть столь же сложным, как протокол атомной фиксации (например, протокол двухфазной фиксации (2ФФ)), или же простой, как одно сообщение с подтверждением. Прекращение без права голоса (Non-Voting Termination) предполагает, что сайты могут решить самостоятельно: зафиксировать или прервать транзакцию. Репликация без права голоса (Non-Voting Replication) часто называют ленивой репликацией. Её главным преимуществом является то, что она не блокирует сайты. Однако, репликация без права голоса не блокирует за счет согласованности данных.
Транзакция является единицей атомарности и согласованности, которая обеспечивает сохранение целостность данных в условиях параллельного доступа и сбоев системы. Транзакция - это логическая единица работы. Транзакции обладают четырьмя важными свойствами: атомарность, согласованность, изоляция и долговечность [4].
Согласованность. Транзакции защищают БД согласованно, т.е. транзакции переводят одно согласованное состояние БД в другое без обязательной поддержки согласованности в промежуточных точках.
Изоляция. Транзакции отделены друг от друга. Это означает, что при запуске множества конкурирующих друг с другом транзакций, любое обновление определенной транзакции будет скрыто от остальных до тех пор, пока эта транзакция выполняется.
Долговечность. Когда транзакция выполнена, ее обновления сохраняются, даже если в следующий момент произойдет сбой системы. Распределенная транзакция обращается к объектам, которые управляются несколькими распределенными серверами. Во многих СУБД были решения для транзакции целевой распределенной базы данных. Так как приложения становятся все более и более отделены от баз данных, требование поддержки транзакций на уровне приложений возрастает. Классическая модель для распределенных транзакций на уровне базы данных и на уровне приложений использует один координатор транзакций, а также несколько менеджеров ресурсов (участников). Несмотря на то, что однофазный протокол хорошо подходит для одной машины, он недостаточен для распределенных транзакций. Причина здесь в том, что однофазный протокол не может работать с подмножеством прерываний участников после решения о фиксации координатора. Чтобы удовлетворить требования атомарности, обработки транзакций распределенных систем используют протокол двухфазной фиксации для того, чтобы достичь соглашения на глобальный результат транзакции.
Протокол двухфазной фиксации
В протоколе двухфазной фиксации транзакция выполняется в два этапа: этап голосования и этап принятия решения. На этапе голосования координатор транзакции просит всех участников транзакции, готовы ли они зафиксировать результаты локальных субтранзакций. Если координатор транзакции получает подтверждение от каждой из участников, он приступает к этапу принятия решения. На этапе принятия решения координатор транзакции указывает участникам, совершить или откатить все изменения, которые были запрошены в качестве части транзакции. Определения для различных элементов 2ФФ приводятся ниже.
Приложения. Приложение может быть одна программа или группа программ, предназначенных для конечных пользователей. Менеджер ресурсов (MP). Менеджер ресурсов - это обычно система управления базами данных. Менеджер ресурсов несет ответственность за поддержание и восстановление собственных ресурсов.
Менеджер транзакций (МТ). Менеджер транзакций координирует действия менеджеров ресурсов, которые находятся на том же узле (местные менеджеры ресурсов) в качестве менеджера транзакций.
Координатор транзакций (КТ). Координатор транзакций является менеджером транзакций на узле, где приложение начинает транзакцию. Координатор организует распределенную транзакцию с помощью общения с менеджерами транзакций на других узлах (с удаленными менеджерами транзакций) и с менеджерами ресурсов на на тех же узлах (с местными менеджерами ресурсов).
Спецификация компонентов
Windows Communication Foundation (WCF) - это платформа корпорации Майкрософт нового поколения для построения распределенных систем. Она была выпущена как часть платформы .NET Framework 3.0 и предназначена для консолидации и расширения интерфейсов API предыдущих версий платформы (например, Web-сервисов ASP.NET, .NET Remoting, служб Enterprise Services (СОМ+) и очереди сообщений). WCF предоставляет единую инфраструктуру разработки, при умелом применении повышающую производительность и снижающую затраты на создание безопасных, надёжных и транзакционных Web-сервисов нового поколения.
WCF — это технология для построения сервис -ориентированной архитектуры приложений (SOA — Service-Oriented Architecture), что позволяет абстрагироваться от конкретной технологи, на которой этот сервис реализован и пользоваться им из других приложений, написанных на любой другой платформе, языке, технологии; главное, чтобы реализация клиента отвечала определенным правилам. Кроме того, логика самого сервиса и его реализация полностью отделена от коммуникационной составляющей, и мы можем декларативно изменять способ взаимодействия с сервисом путем изменения конфигурационного файла. В основе WCF лежит принцип связи с помощью обмена сообщениями, и любые объекты, моделируемые в виде сообщений (например, HTTP-запрос или сообщение очереди сообщений, MSMQ), можно представить единым образом в модели программирования. Это обеспечивает универсальный интерфейс АРІ для разных транспортных механизмов. Сообщения можно отправлять через интрасети или через Интернет с помощью общих транспортов, таких как HTTP и TCP. С помощью встроенных точек расширения WCF можно добавить дополнительные транспортные механизмы. Служба WCF поддерживает несколько шаблонов обмена сообщениями, включая запрос-ответ, одностороннюю и дуплексную связь. Разные транспорты поддерживают разные шаблоны обмена сообщениями и таким образом влияют на типы поддерживаемых взаимодействий. Интерфейсы API и среда выполнения WCF также помогают отправлять сообщения безопасно и быстро.
При создании приложений для .NET разработчики пользуются средой Visual Studio. В WCF и в Visual Studio есть инструменты для реализации служб. В WCF также встроена модель размещения, позволяющая размещать службы в IIS или в Managed Services на платформе Windows. WCF поддерживает развитую модель многопоточности и ограничения пропускной способности (throttling), которая позволяет управлять созданием экземпляров с минимальными усилиями. Вне зависимости от того, обрабатываются ли одновременно поступающие запросы в одном или в нескольких потоках, модель программирования остается одинаковой, так что разработчик может не вдаваться в детали (которые, однако, остаются ему доступными). WCF поддерживает различные способы обмена сообщениями, например: запрос-ответ, односторонний и дуплексный поток. Поддерживаются также пиринговые сети, в которых клиенты могут обнаруживать друг друга и обмениваться данными в отсутствие централизованного механизма управления. Короче говоря, технология WCF важна потому, что современные приложения немыслимы без служб, а именно это и составляет назначение и смысл WCF.
Система «My eLibrary» представляет собой распределенную информационную систему. Она состоит из взаимодействующих подсистем, распределенных в локальной сети. Каждая подсистема функционирует, как собственная информационная система. Например, у подсистемы есть своя СУБД и свои приложения. Подсистемами данной системы ( нарис. 4.1) являются:
Эта подсистема создана для выполнения действия с данными, включающими в себя все материалы по категории «Научный» в библиотеке. В ней функционирует одна СУБД Microsoft SQL Server 2008, в которой хранятся все необходимые данные по этой категории. В этой подсистеме ещё есть од 89 но Web- приложение, с помощью которого администраторы могут работать с данными удобно и безопасно. Кроме этого, для того чтобы взаимодействовать с другими подсистемами, в ней также размещен один WCF Web-сервис. Этот сервис поддерживает обмен данными и выполнение операций в формате сообщений SOAP. Структурные элементы данной системы показаны на рисунке 4.2.
Как показано на рисунке, для взаимодействия с данными СУБД использована платформа ADO.NET Entity Framework. Web-преложение разработано на основе технологии ASP.NET MVC Framework на языке С#. Оно сделано в среде Microsoft Visual Studio 2010. Это приложение поддерживает возможность управления данными по своей категории: например включение новых записей или удаление определенных. Для того, чтобы получить доступ к данным, сначала администраторы должны выполнить логин. Только после этого он получит доступ к данным.
Подсистема « Science category»
Методы действий. Поведение контроллера разделено на множество методов (вместо единственного метода Execute ()). Каждый метод действия виден внешнему миру через свой URL и вызывается с параметрами, извлекаемыми из входящего запроса. Результаты действий. Из метода можно вернуть объект, описывающий желаемый результат действия (например, визуализацию представления, переадресацию на другой URL или другой метод действия), который затем выполняется автоматически. Фильтры. Многократно используемое поведение (например, аутентификация или кэширование вывода) можно инкапсулировать в ви 107 де фильтров, после чего с помощью [Attribute] пометить каждый из них в одном или более контроллерах или методах действий.
Методы действий определены в контроллере. Методы действий обычно однозначно сопоставляются с различными формами взаимодействия с пользователем. URL каждого метода действия определяется конфигурацией маршрутизации. При конфигурации Метод действий для поиска (Search()) можно вызывать, запрашивая /Search. Большинство методов действий возвращают экземпляр класса-наследника ActionResult. Класс ActionResult является базовым для всех результатов действий. Метод View возвращает экземпляр класса ViewResult, который является наследником ActionResult. Метод View отображает представление в качестве Web-страницы. Значения параметров методов действий извлекаются из коллекции данных запроса. Коллекция данных включает пары "имя-значение", содержащее данные форм, значения из строки запросов. В нашем приложении создано 2 контроллера: HomeController и AccountController.
Представления служат для отображения пользовательского интерфейса приложения. Представление отображает необходимый пользовательский интерфейс с помощью данных, передаваемых из контроллера. Данные передаются в представление из метода действия контроллера с помощью метода View.
В нашем приложении использован механизм Razor представлений. Razor является синтаксисом разметки, который позволяет встраивать серверный код (Visual Basic и С #) в Web-страницу.
Синтаксис Razor основан на ASP.NET, и предназначен для создания Web-приложений. Он обладает возможностями традиционной ASP.NET разметки, но он проще в использовании, и легче для освоения.
Вспомогательные методы HTML. Для генерации одиночных HTML-дескрипторов или небольших коллекций HTML-дескрипторов на основе данных, извлекаемых из Model. ASP.NET MVC поставляется с широким диапазоном базовых вспомогательных методов HTML.
Частичные представления. Для совместного использования сегментов разметки в нескольких представлениях. Это легковесные многократно используемые элементы управления, которые могут содержать логику представления (т.е. встроенный код, вспомогательные методы HTML и ссылки на другие частичные представления), но никакой бизнес-логики. Они подобны вспомогательным методам HTML за исключением того, что создаются с помощью шаблонов Razor, а не в коде С#.
Графические элементы. Для создания многократно используемых элементов управления пользовательского интерфейса или графических элементов, которые могут включать логику приложения наряду с логикой презентации. Каждый раз при визуализации такого графического элемента это требует запуска отдельного процесса MVC, с методом действия, который выбирает и визуализирует собственный шаблон представления для включения в поток ответа.
В нашем приложении создано 3 представлении для методов действий HomeController: Search(); IndexQ и Details(). В приложении 1.7 приведен исходный код для представления поиска «Search».
Для вызова операций службы клиент должен сначала импортировать контракт службы в родное представление своей среды. Для клиента, обращающегося к службе, необходимо, во-первых, сгенерировать конфигурационный файл и посреднику, а, вовторых, написать код, который будет с помощью посредники обращаться к службе. Visual Studio 2010 позволяет импортировать метаданные службы и сгенерировать посреднику. Операция Add Service Reference (ASR) (Добавить ссылку на службу) в Visual Studio применяется для получения метаданных от WCFcлyжбы и генерации посредники и конфигурационного файла. Посредника позволяет клиенту обращаться к операциям службы так, будто она является методами локального класса. Посредника пользуется классами WCF для конструирования и интерпретации SOAP сообщений согласно контракту, определенному в конечной точке службы. В конфигурационном файле хранятся АПК службы. Использование ASR в Visual Studio показано на рис.4.10
