Сергей Зыков - Основы проектирования корпоративных систем

Итак, перейдем к процедуре построения корпоративных распределенных приложений на основе технологии Remoting и других технологий, связанных с веб-сервисами и клиент-серверной архитектурой. Общий принцип построения подобных систем заключается в следующем: объекты или модули распределенного приложения в случае компонентного подхода к проектированию (компоненты или сборки) располагаются физически на нескольких компьютерах и логически – в нескольких процессорах ОС. За счет специализации выделяется слой бизнес-логики, который реализуется на клиентской части и на сервере. За счет этого оптимизируется производительность клиента и сервера и осуществляется взаимодействие элементов распределенного приложения в наиболее выгодном режиме для пользователей, по сути, оптимизируется производительность программной системы, время реакции, производительность пользователей.

Какие основные понятия характеризует веб-сервисы и технологии Remoting? Технология Remoting является достаточно жесткой по сравнению с общей методологией веб-сервисов. Microsoft продвигает принцип предоставления ПО как сервиса, поэтому понятие веб-сервиса не только не чуждо методологии. NET, но и является одним из ее основных компонентов. Веб-сервисы представляют собой слабосвязанную модель взаимодействия объектов на основе общедоступных мировых стандартов. Это в первую очередь протоколы взаимодействия HTTP, SMTP. Веб-сервисы независимы от языка программирования, в отличие от Remoting. Еще очень важно, что веб-сервисы поддерживают модель работы с объектами без сохранения внутреннего состояния. То есть объекты, по сути, не имеют памяти о своей истории. Подход. NET Remoting является более строгим, более жестким, нацеленным исключительно на среду. NET, т. е. прежде всего на ОС Windows. Конечно, NET поддерживается и для узкого круга Unix-систем, в рамках проекта mono, но в целом ориентация преимущественно на. NET и Windows. Кроме того, модель нацелена на более эффективное и безопасное выполнение объектов в. NET, так как содержит встроенную систему безопасности, она поддерживает сборки и подписи, алгоритмы шифрования, поддерживаемые средой. NET. Таким образом, реализуется сильно связанная модель, которая поддерживает память, т. е. состояние объектов, и обеспечивается более эффективное взаимодействие объектов в среде. NET. При этом объекты располагаются на разных компьютерах и в разных процессорах.

При исследовании слабо и сильно связанных (Loosely Coupled и Tightly Coupled) моделей распределенных приложений нужно отметить, что модель Loosely Coupled, также как и Tightly Coupled, предназначена для распределенных приложений. Различие состоит в более свободном выборе протоколов и отношении к сохранению состояния, которое используется в последнем подходе. Loosely Coupled модель подразумевает построение распределенных приложений на основе минимального набора приложений и взаимодействий. Tightly Coupled подход подразумевает более жесткую связь, более строгую однородность частей приложения и в отличие от Loosely Coupled основан на заранее согласованных более строгих протоколах и наборах данных. Loosely Coupled подход использует стандартные протоколы XML и HTTP. Что касается модели взаимодействия объектов, то здесь распределенные объекты взаимодействуют без сохранения памяти о своей истории. Таким образом, с точки зрения ООП можно конкретизировать подход взаимодействия клиента и сервера без сохранения состояния тем, что каждый вызов метода обрабатывает новый экземпляр объекта, который создается заново. В отличие от похода, связанного с наличием состояния, не меняется состояние объекта со старого на новое, а просто создается новый экземпляр объекта.

Что касается работы с сетью, позднее мы увидим, каким образом это связано с пространством имен Remoting. Напомним, что существует пространство имен System, внутри которого находится пространство. NET, а потом —.Sockets (рис. 9.7). Первое подпространство определяет основные параметры источников взаимодействия, т. е. таких точек взаимодействия на клиенте и сервере, как пространство доменных имен, характеристики точек взаимодействия и т. д. И пространство имен Sockets определяет более детально характеристики клиента и сервера, которые связаны с конкретным протоколом, скажем TCP/IP, и построением потока данных для обмена сетевой информацией.

Рис. 9.7.Иерархия пространств имен

Рассмотрим эволюцию технологий сетевого взаимодействия распределенных приложений и построение такого рода приложений. Одной из наиболее ранних технологий является удаленный вызов процедур – Remote Procedure Call. Во многом эта технология реализуется в Remoting при маршеринге, который будет рассмотрен несколько позднее. Еще одним подходом была передача сообщений, т. е. взаимодействие между распределенным приложением, между объектами. В одном из первых вариантов она называлась DCE – Distributed Computing Environment. Если рассматривать взаимодействие клиента и сервера, концепция открытых систем предполагает явное распределение ролей на клиент и сервер. При этом клиент – это компьютер, который осуществляет преимущественно запрос информации, в данном случае это вызов функции, которая на самом деле обращается к серверу, хотя это очевидно только из ее названия. Сервер осуществляет поиск, получение и предоставление отчетной информации для клиента в соответствии с его запросом. Кроме того, вспоминая главу об архитектуре, заметим, что помимо двух слоев клиент-серверной архитектуры (клиента и сервера), существует еще промежуточный слой, который предназначен для локализации взаимодействия. Но пока рассмотрим уровни клиента и уровни сервера.

Идея взаимодействия состоит в том, что функция, которая в данном случае называется Server Func, формально при чтении кода не должна вызывать ассоциации с сервером. С точки зрения клиента, осуществляется как бы выполнение этой функции. Функция имеет два параметра – символьный Hello и целочисленный 123. И результат должен быть присвоен некоему объекту J. На самом деле на клиенте функционирует специальный слой, который называется промежуточным и транслирует при переводе этой программы в промежуточный код из так называемого верхнего слоя (Top Layer), представляющего собой исходный текст на том или ином языке программирования (в данном случае это язык С), который транслирует этот вызов в некий внутренний вызов и упаковывает его нужным образом. Этот специализированный механизм называется Proxy-клиент. Он осуществляет трансляцию и упаковку этого вызова процедуры в обращение к другому компьютеру (серверу) с нужными параметрами, которые переупаковываются, меняют свои имена. Происходит передача некоего указателя на область памяти (*str) и некоего целочисленного значения v, с кодом, который у нас имеется на клиенте, осуществляется передача его после соответствующей упаковки серверу, Stub серверу, т. е. специальный функциональный компонент сервера осуществляет преобразование этого запроса во внутренний запрос сервера, организацию процедуры, заданной клиентом, и активизацию этой процедуры на сервере с заданными параметрами. Вычисление значений с переданными аргументами происходит путем подстановки вместо параметров их значений. Вычисление связано с работой процедуры на сервере. После этого осуществляется обратная упаковка и передача клиенту в ответ на его запрос. На нижнем уровне (Bottom Layer) осуществляется передача данных по сети на соответствующем уровне. Ниже находятся все последующие протоколы сетевого стека.