Для архитектуры приложения выставляются некоторые требования



Скачать 476.67 Kb.
страница1/5
Дата24.12.2016
Размер476.67 Kb.
Просмотров539
Скачиваний0
  1   2   3   4   5
Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин "архитектура программного обеспечения" является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями.

Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними.

Для архитектуры приложения выставляются некоторые требования.

Все требования к приложению можно разделить на функциональные и операционные.

Функциональные - различаются в зависимости от вида приложения. Формируются и контролируются заказчиком.

Операционные – Требования выставляемые к ПО, выполнение которых является обязательным независимо от вида.



  • Безопасности (защита от атак)

  • Надежности (защита от внутренних сбоев и ошибок)

  • Масштабируемости (Возможность наращивать эффективность без внесение изменения в код)

  • Управляемость (Возможность доступа и изменения без рестарта, и тем более перезагрузки сервера)

  • Доступность (работоспособность приложения без технических перерывов)

  • Отказоустойчивость (Возможность автоматически восстановиться и восстановить данные после сбоев).

  • Сопровождаемость

  • Быстродействие

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

Эластичность - Эластичность позволяет быстро усовершенствовать, либо приспособить программу при появлении изменений в логике процессов

Мультитенантность – максимального использования общих ресурсов для обслуживания различных приложений, разных пользователей

Есть много распространенных способов разработки программных модулей и их связей

Виды архитектур


  • Монолитная архитектура (Оконное приложение, подходит для малых задач)

  • Многозвенная архитектура (Очередной этап развития монолитных приложений, когда они начинают взаимодействовать между собой)

  • База-центрическая архитектура (database-centric architecture – многозвенная архитектура с центральным хранилищем)

  • Клиент серверная архитектура (Архитектура с центральным сервером приложений – и тонкими клиентами)

  • Трехзвенная архитектура (клиент-серверная архитектура, с выделенным сервером хранения и обработки данных, серверными и клиентскими приложениями)

  • Распределенная архитектура

  • Событийно – ориентированная архитектура (event-driven architecture)

  • Сервисно – ориентированная архитектура


Многозвенная архитектура

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

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

Для осуществления взаимодействия информационных систем используются различные технологии



  • Обмен с помощью Встроенных сервисов - Enterprise Application Integration (EAI), BizTalk Service Bus

  • Обмен с помощью сторонних сервисов (VPN tunnel Hamachi …)

  • Обмен на основании Socket соединения

  • Обмен на основании структурированных файлов XML файлы или базы данных

  • Обмен на основании неструктурированных или командных файлов

При взаимодействии многозвенных архитектур можно выделить различные виды соединений.

Удаленное взаимодействие – когда звенья находятся в физически разных подсетях, следовательно прямое взаимодействие не возможно и приходится взаимодействовать через различные сторонние механизмы

Локальное взаимодействие – когда звенья находятся в одной подсети или удаленно достижимы.

Соответственно существуют несколько типов соединения с сервером



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

Особенности:



  • Высокая скорость обработки запросов.

  • Поддержка синхронизации.

  • Низкий коэффициент использования канала.

  • Лимитированное количество клиентов.

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

Недостатки:



  • Увеличен лимит пользователей

  • Высокий коэффициент использования канала

  • Низкая скорость ответа сервера;

  • Невозможность диалога между клиентами в реальном времени.

  • Возможны продолжительные задержки сети.

Сети коммутации пакетов Обмен информацией происходит короткими пакетами фиксированной структуры. Пакет - это часть сообщения, удовлетворяющая некоторому стандарту. Небольшая длина пакета предотвращает блокировку сети, очередь уменьшается в узлах коммутации. Происходит более быстрое соединение, уменьшается уровень ошибок, увеличивается надежность и эффективность сети.

Достоинства и Недостатки

Возможность асинхронного процесса разработки, Надежность и независимость приложений друг от друга. Возможны проблемы во вешней безопасности и отказоустойчивости. Сложности в развертывании приложения. Проблематичная синхронность приложений.



Архитектуры, построенные вокруг базы данных (database-centric architecture)

Сервер базы данных представляет собой мультипользовательскую версию СУБД, параллельно обрабатывающую запросы, поступившие со всех рабочих станций. В его задачу входит реализация логики обработки транзакций с применением необходимой техники синхронизации - поддержки протоколов блокирования ресурсов, обеспечение, предотвращение и/или устранения тупиковых ситуаций.

В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front - end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме.

Достоинства и недостатки: Простота в развертывании.

Легкая масштабируемость. Централизация данных, позволяющая легко внедрять резервирование. Возможность построение распределенных систем. Сложности в реализации политик безопасности. Сложности при асинхронном режиме разработке. Повышенные требования к около серверному оборудованию.



Клиент серверная архитектура

Клиент-сервер (англ. Client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами.

Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.

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

Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

Соответственно клиенты являются лишь представлением данных, а все бизнес логика, сбор и обработка происходит на сервере. Также на сервере организована проверка безопасности и уровни доступа клиентов.



Достоинства

  • Обновления и поддержка не затрагивает клиентов.

  • Безопасность сервера, так как все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов. На сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.

  • Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

Недостатки

  • Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.

  • Высокая вычислительная нагрузка на сервер около серверное сетевое оборудование, что увеличивает стоимость оборудования.

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



Трёхуровневая архитектура

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

Клиент (1 уровень) – выполняет интерфейсную роль, обработку представлений, и предоставляет начальных уровень безопасности.

Приложение (2 уровень) – выполняет обработку запросов, с частичным выполнением бизнес логики (представление и конвертация данных). Повторную проверку пользователя.

База данных (3 уровень) – выполнение процедур изменения данных, их сбор и выдача с проверкой авторизации.

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

В «правильной» (с точки зрения безопасности, надёжности, масштабирования) конфигурации сервер базы данных находится на выделенном компьютере (или кластере), к которому по сети подключены один или несколько серверов приложений, к которым, в свою очередь, по сети подключаются терминалы.

Достоинства

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:



  • масштабируемость

  • конфигурируемость — изолированность уровней друг от друга позволяет (при правильном развертывании архитектуры) быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней

  • высокая безопасность

  • высокая надёжность

  • низкие требования к скорости канала (сети) между терминалами и сервером приложений

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

Недостатки

  • Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

  • более высокая сложность создания приложений;

  • сложнее в разворачивании и администрировании;

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

  • высокие требования к скорости канала (сети) между сервером базы данных и серверами приложений.

Пример архитектуры – Browser – IIS - MSSQL


Распределенная архитектура

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

Определение распределенной системы в техническом смысле тесно связано с передачей информации и организацией обработки данных.

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

Распределенная система с общим управителем и с децентрализацией

Событийно ориентированная архитектура

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




Сервис-ориентированная архитектура

Сервис-ориентированная архитектура (англ. SOA, service-oriented architecture) — модульный подход к разработке программного обеспечения (в дальнейшем ПО), основанный на использовании сервисов (служб) со стандартизированными интерфейсами.

В основе SOA лежат принципы многократного использования функциональных элементов информационных технологий (в дальнейшем ИТ), ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов,

Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)

Основная причина появления SOA — старозаветная мечта индустрии программирования о замене «кустарного» кодирования программ «от и до» на «промышленную» сборку приложений из «стандартных комплектующих», как в автомобильной, или других «традиционных» отраслях промышленности.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы Intel SOA Expressway, JBoss SOA Platform, IBM WebSphere, Software AG webMethods, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, TIBCO).

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

SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.



Где располагаются приложения?

Обсуждая облачные вычисления, следует обращать внимание на то, где располагаются приложения. В настоящее время существует три основных модели расположения приложений, которые мы рассмотрим ниже:



  • В инфраструктуре заказчика.

  • У компании-хостера.

  • В облаке.

Расположение в инфраструктуре заказчика (on premises). Это наиболее традиционная модель развертывания приложений, существующая уже десятки лет. Размещение приложений в локальной инфраструктуре предполагает существенные начальные инвестиции в аппаратные ресурсы, программное обеспечение, сетевую инфраструктуру и персонал. Такая модель — оплата, приобретение, владение — напрямую связана с высокими капитальными затратами, но, в тоже время, она обеспечивает полный контроль за инфраструктурой, аппаратным и программным обеспечением.

Расположение у компании-хостера (hosting). Такая модель развертывания приложений, называвшаяся ранее Application Services Prodiver (ASP), а затем — SaaS или просто «хостинг» получила свое развитие несколько лет назад и является одним из наиболее популярных способов снижения расходов на информационные технологии. Она основана на аренде аппаратной платформы, программного обеспечения, соответствующей инфраструктуры и персонала, выполняющего ее обслуживание. Такая модель отличается меньшим контролем за инфраструктурой, аппаратным и программным обеспечением и базируется на оплате фиксированного числа ресурсов, что обычно предполагает оплату даже в тех случаях, когда арендуемые ресурсы не используются.

Расположение в облаке (cloud). Данная модель появилась совсем недавно. Она предполагает оплату по факту использования арендуемых аппаратных и программных ресурсов, что приводит к существенному снижению начальных расходов и переходу от капитальных инвестиций к операционным расходам. Такая модель отличается практически отсутствием контроля за инфраструктурой и аппаратным обеспечением, а при аренде программного обеспечения — еще и отсутствием контроля за ним.
Сетевое программирование в C#
Среда .NET предоставляет два пространства имен: System.Net и System.Net.Sockets для работы с сетью. Эти пространства имен содержат классы и методы, которые позволяют легко создавать программы, которые могут взаимодействовать через сеть

Взаимодействие может осуществляться как с постоянным подключением по сети, так и без него. Также можно работать как с потокоориентированными данными так и с датаграммами. Наиболее распростанены протоколы TCP (использует потокоориентированное подключение) и UDP (приложения, ориентированные на датаграммы).

Класс System.Net.Sockets.Socket - это основной класс из пространства имен System.Net.Sockets. Экземпляр класса Socket имеет локальную и удаленную точку подключения, через которые он работает. Локальная точка подключения содержит информацию о подключении текущего состояния сокета.
Шагами для создания самых простых синхронных клиентов являются:

1. Определить объект класса Socket.

2. Подсоеденить созданный объект к точке подключения.

3. Отправить или принять информацию.

4. Завершить сокет.

5. Закрыть сокет.


Класс Socket предоставляет конструктор для создания объекта Socket.
public Socket (AddressFamily af, ProtocolType pt, SocketType st)
Где, AddressFamily, ProtocolType и SocketType это перечисляемые типы, которые определены внутри класса Socket.

Параметр AddressFamily определяет адресную схему, которую использует объект класса Socket, чтобы определить адрес. Например, AddressFamily.InterNetwork определяет, что для поключения сокета необходим протокол IP четверой версии.

Параметр SocketType указывает тип сокета текущего состояния. К примеру, SocketType.Stream указывает на поток с постоянным подключением, а SocketType.Dgram на поток без постоянного подключения.

Параметр ProtocolType определяет тип протокола, который будет использован для соединения. Например, ProtocolType.Tcp указывает, что используется протокол TCP, а ProtocolType.Udp – протокол UDP.


public Connect (EndPoint ep)

Этот метод используется локальным объектом для подключение к удаленной точке. И используется он только на клиентской стороне. В случае удачного установления сосединения методы Send() и Receive() могут быть использованы для оправки и получения данных по сети.


Свойство Connected определено внутри класса Socket и используется для проверки статуса соединения.
Методы Send() и Receive()

Оба этих метода возвращают количество переданных или полученных байт типа Int32. Существует по три перегруженных метода для каждой функции.

public int Send (byte[] buffer, SocketFlags flags)

public int Send (byte[] buffer)

public int Send (byte[] buffer, int offset, int size, SocketFlags flags)

где, buffer – массив байт, который необходимо передать, offset – сдвиг в массиве, с которого необходимо передавать данные, а size – количество данных, которые необходимо передать.

public int Receive (byte[] buffer, SocketFlags flags)

public int Receive (byte[] buffer)

public int Receive (byte[] buffer,int offset, int size, SocketFlags flags)

где, buffer – масив, которые принимает данные, offset – сдвиг в массиве, по которому необходимо сохранить данные, а size – размер сохраняемых данных.


public void ShutDown(SocketShutdown how)

После окончания передачи данных через сеть, соединение между сокетами может быть закрыто с помощью метода ShutDown(). Параметр how определяет причину окончания передачи данных. SoketShutdown.Send – указывает удаленному сокету, что локальный не будет передавать больше данных и SoketShutdown.Receive – указывает удаленному сокету, что локальный не будет больше принимать данных.


public void Close()

Этот метод закрывавает текущее состояние объекта и освобождает все управляемые и неуправляемые ресурсы выделенные этому состоянию объекта


Синхронное подключение работает в блочном режиме, в котором метод ожидает завершения операции перед возвратом значения. А вот асинхронное подключение работает в неблочном режиме, при котором значение возвращается сразу, даже если операция взаимодействия не окончена.

Также существует несколько вспомогательных классов, таких как IPEndPoint, IPAdress, SocketException и др., которые используют при создании сетевых программ. Среда .NET поддерживает синхронное и асинхронное подключения между клиентом и сервером. Для этих двух типов взаимодействия по сети используются различные методы.



IPHostEntry класс

Этот класс является контейнером для информации о адресах хостов Интернета. Он не содержит гарантий потокобезопасности. Ниже описаны наиболее интересные члены этого класса.


Свойство AddressList

Предоставляет массив IPAddress, содержащий IP адреса, которые соответствуют имени хоста.


Свойство Aliases

Предоставляет массив строк, который содержит DNS имена, соответствующие IP адресам в свойстве AddressList.


Программа ниже показывает использование обоих классов:
using System; using System.Net; using System.Net.Sockets; class MyClient { public static void Main() { IPHostEntry IPHost = Dns.Resolve("www.hotmail.com"); Console.WriteLine(IPHost.HostName); string []aliases = IPHost.Aliases; Console.WriteLine(aliases.Length); IPAddress[] addr = IPHost.AddressList; Console.WriteLine(addr.Length); for(int i= 0; i < addr.Length ; i++) { Console.WriteLine(addr[i]); } } }

Dns класс

Пространство имен System.Net предоставляет класс Dns, с помощью которого можно создавать и посылать запросы для получения информации о хосте сервера через Службу Доменных Имен Интернета (Internet Domain Name Service). Ну и соответственно, чтобы получить доступ к DNS, необходимо чтобы машина, выполняющая запрос, была подключена к сети. А вот если запрос выполнить на компьютере не имеющем доступа к серверу доменных имен, то возникнет исключительная ситуация System.Net.SocketException. Все члены этого класса являются статическими. Наиболее интересные будут описаны ниже.


public static IPHostEntry GetHostByAddress(string address)

Адрес необходимо задавать в формате “ХХХ.ХХХ.ХХХ.ХХХ”. Этот метод возвращает объект класса IPHostEntry, который содержит информацию о запрошеном хосте. Если сервер DNS не доступен, метод вернет исключение SocketException.


public static string GetHostName()

Этот метод возвращает DNS имя хоста локальной машины.


public static IPHostEntry Resolve(string hostname)

Метот преобразовывает DNS имя хоста или IP адрес в объект класса IPHostEntry. Имя хоста должно быть предоставлено форматах вида 127.0.0.1 или www.microsoft.com.


IPEndPoint класс
Этот класс реализует абстрактных класс EndPoint. IPEndPoint класс представляет собой сетевую точку как IP адрес и номер порта. Ниже показана небольшая конструкция, использующая этот класс:
IPEndPoint(long addresses, int port) IPEndPoint (IPAddress addr, int port) IPHostEntry IPHost = Dns.Resolve("managedcode.info"); Console.WriteLine(IPHost.HostName); string []aliases = IPHost.Aliases; IPAddress[] addr = IPHost.AddressList; Console.WriteLine(addr[0]); EndPoint ep = new IPEndPoint(addr[0],80);
using System;

using System.Text;

using System.IO;

using System.Net;

using System.Net.Sockets;
public class Sample

{

public static string DoSocketGet(string server)

{

//Set up variables and String to write to the server.

Encoding ASCII = Encoding.ASCII;

string Get = "GET / HTTP/1.1\r\nHost: " + server +

"\r\nConnection: Close\r\n\r\n";

Byte[] ByteGet = ASCII.GetBytes(Get);

Byte[] RecvBytes = new Byte[256];

String strRetPage = null;

// IPAddress and IPEndPoint represent the endpoint that will

// receive the request.

// Get first IPAddress in list return by DNS.

try

{

// Define those variables to be evaluated in the next for loop and

// then used to connect to the server. These variables are defined

// outside the for loop to make them accessible there after.

Socket s = null;

IPEndPoint hostEndPoint;

IPAddress hostAddress = null;

int conPort = 80;
// Get DNS host information.

IPHostEntry hostInfo = Dns.GetHostEntry(server);

// Get the DNS IP addresses associated with the host.

IPAddress[] IPaddresses = hostInfo.AddressList;
// Evaluate the socket and receiving host IPAddress and IPEndPoint.

for (int index=0; index

{

hostAddress = IPaddresses[index];

hostEndPoint = new IPEndPoint(hostAddress, conPort);

// Creates the Socket to send data over a TCP connection.

s = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp );

// Connect to the host using its IPEndPoint.

s.Connect(hostEndPoint);

if (!s.Connected)

{

// Connection failed, try next IPaddress.

strRetPage = "Unable to connect to host";

s = null;

continue;

}

// Sent the GET request to the host.

s.Send(ByteGet, ByteGet.Length, 0);

} // End of the for loop.

// Receive the host home page content and loop until all the data is received.

Int32 bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);

strRetPage = "Default HTML page on " + server + ":\r\n";

strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);
while (bytes > 0)

{

bytes = s.Receive(RecvBytes, RecvBytes.Length, 0);

strRetPage = strRetPage + ASCII.GetString(RecvBytes, 0, bytes);

}

} // End of the try block.
catch(SocketException e)

{

Console.WriteLine("SocketException caught!!!");

Console.WriteLine("Source : " + e.Source);

Console.WriteLine("Message : " + e.Message);

}

catch(ArgumentNullException e)

{

Console.WriteLine("ArgumentNullException caught!!!");

Console.WriteLine("Source : " + e.Source);

Console.WriteLine("Message : " + e.Message);

}

catch(NullReferenceException e)

{

Console.WriteLine("NullReferenceException caught!!!");

Console.WriteLine("Source : " + e.Source);

Console.WriteLine("Message : " + e.Message);

}

catch(Exception e)

{

Console.WriteLine("Exception caught!!!");

Console.WriteLine("Source : " + e.Source);

Console.WriteLine("Message : " + e.Message);

}

return strRetPage;

}

public static void Main()

{

Console.WriteLine(DoSocketGet("localhost"));

}

}

ВЕБ СЕРВИСЫ

Введение

Сегодня существует два фундаментально различных способа реализации Web сервисов, основанных на HTTP, в Microsoft® .NET. Первой и наиболее низкоуровневой техникой является написание специального класса IHttpHandler , который вставляется в цепочку .NET HTTP pipeline. Этот подход требует использования System.Web API для обработки входящих HTTP сообщений и System.Xml API для обработки конверта SOAP, находящегося в теле HTTP. При написании специального обработчика также требуется создать вручную документ WSDL, который точно описывает вашу реализацию. Чтобы сделать все это правильно, необходимо глубокое понимание спецификаций XML, XSD, SOAP и WSDL, что является для большинства устрашающим условием.

Более продуктивным способом реализовать Web сервисы является использование WebMethods оболочки Microsoft ASP.NET. С ASP.NET поставляется специальный класс IHttpHandler для .asmx (называемых WebServiceHandler ), который обеспечивает набор необходимых вам функциональных возможностей XML, XSD, SOAP и WSDL. И, поскольку WebMethods оболочка защищает вас от сложностей, лежащих в основе XML технологий, вы можете быстро сосредоточиться на существующих проблемах бизнес логики.

http://vladweb.narod.ru/help/unetaws1.gif

Рисунок 1. Соотношение выгод и потерь между гибкостью и продуктивностью

Выбор между техниками реализации приводит к общему сравнению выгод и потерь между гибкостью и продуктивностью, как показано на Рисунке 1. Создание специального IHttpHandler дает вам неограниченную гибкость, но также требует большего времени на написание, тестирование и отладку кода. Оболочка WebMethods облегчает организацию вашего Web сервиса и быстроту разработки, но вы явно ограничены рамками оболочки. Однако в случаях, когда оболочка WebMethods не обеспечивает именно того, что вам надо, есть возможность расширить ее, добавляя собственные дополнительные функциональные возможности.

В общем, пока вы не освоили XML, XSD, SOAP и WSDL и не хотите утруждаться, работая с ними напрямую, лучше продолжайте работать с оболочкой WebMethods. Она поставляет основные сервисы, которые необходимы большинству конечных Web сервисов, а также некоторые интересные возможности расширения, которые позволяют привести оболочку в соответствие вашим конкретным надобностям. Исходя из этого, далее в статье обсуждаются внутренние механизмы работы WebMethods. Если вы новичок в XML Schema и SOAP, перед тем как продолжить прочитайте Understanding XML Schema и Understanding SOAP.

вернуться к содержанию


Оболочка WebMethods

Оболочка WebMethods занимается преобразованиями SOAP сообщений в методы класса .NET. Это делается, прежде всего, путем аннотирования ваших методов атрибутом [WebMethod] , находящемся в пространстве имен System.Web.Services . Например, следующий класс .NET содержит четыре метода, два из которых аннотированы атрибутом [WebMethod] :

using System.Web.Services;
public class MathService

{

[WebMethod]



public double Add(double x, double y) {

return x + y;

}

[WebMethod]



public double Subtract(double x, double y) {

return x - y;

}

public double Multiply(double x, double y) {



return x * y;

}

public double Divide(double x, double y) {



return x / y;

}

}



Чтобы использовать этот класс с оболочкой WebMethods, вам надо компилировать его в сборку и скопировать в виртуальную директорию директории bin. В этом примере методы Add и Subtract затем могут быть раскрыты как операции Web сервиса, в то время как с методами Multiply и Divide этого сделать нельзя (т.к. они не были отмечены атрибутом [WebMethod] ).

Вы раскрываете Add и Subtract как операции Web сервиса через .asmx файл. Чтобы сделать это, создайте новый текстовый файл Math.asmx , содержащий следующее простое описание, и поместите его в ту же виртуальную директорию, которая содержит и сборку (обратите внимание: файл помещается в саму виртуальную директорию, а не в ее дочернюю директорию bin ):



<%@ WebService %>

Это описание указывает обработчику . asmx , какой класс использовать для WebMethods, а обработчик чудесным образом заботится обо всем остальном. Например, предположим, виртуальная директория называется 'math' и содержит Math.asmx наряду с тем, что дочерняя директория bin содержит сборку, вызов http://localhost/math/math.asmx приводит к тому, что обработчик . asmx генерирует страницу документации, показанную на Рисунке 2 (см. далее).

Это один из основных вариантов работы обработчика . asmx . Файл . asmx обычно содержит только описание WebService , которое ссылается на класс Web сервиса по имени (как в примере, показанном ниже). Следовательно, в этом случае, сборка должна уже быть скомпилирована и размещена в директории bin виртуальной директории. Обработчик . asmx также обеспечивает JIT компиляцию исходного кода, находящегося в файле . asmx . Например, следующий файл (названный Mathjit.asmx ) содержит описание WebService вместе с исходным кодом класса, на который ссылается.

<@% WebService language="C#"%>
using System.Web.Services;
public class MathServiceJit

{

[WebMethod]



public double Add(double x, double y) {

return x + y;

}

[WebMethod]



public double Subtract(double x, double y) {

return x - y;

}

public double Multiply(double x, double y) {



return x * y;

}

public double Divide(double x, double y) {



return x / y;

}

}



Когда к этому файлу доступаются через HTTP впервые, обработчик . asmx компилирует источник и правильно размещает сборку. Обратите внимание, что в описании WebService должен быть также указан и язык программирования, чтобы обработчик . asmx мог выбрать в среде выполнения правильный компилятор. Явным недостатком этого подхода является то, что вы не знаете об ошибках компиляции до тех пор, пока не обратитесь к файлу.

http://vladweb.narod.ru/help/unetaws2.gif

Рисунок 2. Документация MathService

При создании нового проекта Web сервиса в Visual Studio® .NET вы всегда используете технику “двух файлов”, когда исходный файл класса отделен от файла . asmx , который на него ссылается. Интегрированная среда разработки (IDE) хорошо скрывает это от вас, но если вы нажмете Show All Files на панели инструментов Solution Explorer, вы увидите в проекте по два файла для каждого класса Web сервиса. Кстати, Visual Studio .NET не поддерживает для файлов . asmx синтаксическое выделение или IntelliSense®, поэтому вы сами решаете, следовать ли в этом направлении. В Web проектах Visual Studio .NET также заботится о создании виртуальной директории и автоматическом компилировании сборки в директорию bin виртуальной директории.

Перед погружением в детали работы обработчика . asmx давайте коротко обсудим, как обрабатываются сообщения от Internet Information Server (IIS), прежде всего, в обработчике . asmx . Когда входящее HTTP сообщение достигает порта 80, для того, чтобы определить, какая ISAPI DLL должна использоваться для его обработки, IIS использует информацию метабазы IIS. Инсталляция .NET связывает расширения . asmx с Aspnet_isapi.dll , как показано на Рисунке 3.



http://vladweb.narod.ru/help/unetaws3.gif

Рисунок 3. Связываение IIS и .asmx



Aspnet_isapi.dll – это стандартное расширение ISAPI, поставляемое .NET Framework, которое просто направляет HTTP запросы в отдельный рабочий процесс, называемый Aspnet_wp.exe . Aspnet_wp.exe выполняет роль хоста для общеязыковой среды выполнения и .NET HTTP pipeline. Как только сообщение входит в .NET HTTP pipeline, pipeline просматривает в файле конфигурации, какой класс IHttpHandler надо использовать для данного расширения. Если вы посмотрите свой файл Machine.config , то увидите, что он содержит httpHandler , связанный с расширением . asmx , как показано здесь:







type="System.Web.Services.Protocols.WebServiceHandlerFactory,

System.Web.Services, Version=1.0.3300.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>

...

Итак, когда сообщение поступает в .NET HTTP pipeline, нацеливаясь на файл . asmx , pipeline заходит в класс WebServiceHandlerFactory , чтобы создать новый объект WebServiceHandler , который может использоваться для обработки запроса (с помощью метода IHttpHandlerProcessRequest ). Затем объект WebServiceHandler открывает физический файл . asmx , чтобы определить имя класса, содержащего ваш WebMethods. Более подробная информация о работе .NET HTTP pipeline представлена в HTTP Pipelines: Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET.



Сразу после того, как .NET HTTP pipeline вызывает обработчик . asmx , чудесным образом начинается обработка XML, XSD, SOAP и WSDL. Остальные функциональные возможности, предоставляемые обработчиком . asmx , могут быть разделены на три основные группы: 1) координирование сообщений, 2) преобразование XML в объекты и 3) автоматическое генерирование WSDL и документации. Давайте каждую из этих групп рассмотрим более детально.

вернуться к содержанию

ПАРАДИГМА «ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ»

Облачные вычисления – это новая специфичная клиент-серверная технология, в которой вычислительные мощности (процессорное время, оперативная память, дисковое пространство, сетевые каналы, специализированные контроллеры и программное обеспечение) предоставляется как сервис [30].

Облачный сервис позволяет использовать клиентом ресурсов группы серверов в сети, взаимодействующих таким образом, что клиент может легко менять объемы потребляемых ресурсов и в случае изменения своих потребностей. Например, увеличивать или уменьшать мощность сервера, тем самым увеличивая или уменьшая оплату за него[28].



Поделитесь с Вашими друзьями:
  1   2   3   4   5


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал