Архитектура

в «макаронном» стиле:

Джемелли

Две полоски, переплетенные между собой.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
										r
P						NOW!				o
					BUY
				to
w Click								Архитектурныеm			стили
w
	w									o
	.							.c
		p					g
			df			n		e
				-xcha

Архитектура клиент/сервер

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
355Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Будучи типичной сетевой архитектурой, модель клиент/сервер делит функцио% нальность на две главные части: клиент и сервер. Она отличается от прежнего сти% ля проектирования работы в сети с мэйн# фреймом тем, как делится работа между участниками. «Клиент» мэйнфрейма – это тупой терминал, возможности которого немногим шире, чем перехват и отправка

нажатий на клавиши, а также вывод некоторых данных на дисплей.

Клиенты в архитектуре клиент/сервер богаче функциями, более интел% лектуальны и обычно могут представлять данные в графическом и ин% терактивном стиле. Рассмотрим подробнее роли этих двух элементов:

Сервер

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

Сервер ждет запросы от клиентов и отвечает на них. Количество од% новременно обрабатываемых соединений с клиентами может быть произвольным или подчиняться некоторой ограничительной схеме.

Клиент

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

Услугами одного и того же сервера могут пользоваться клиенты раз% ных типов, посылая запросы из одного и того же набора, но разны% ми способами. Один клиент может иметь веб%интерфейс, другой – интерфейс GUI, а третий действовать из командной строки.

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

Есть разные способы разделения труда между этими двумя компонен% тами. Основная логика приложения (так называемая бизнес#логика)

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								356m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 14. Программная архитектураClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Типы интерфейсов

Основным принципом конструирования программного обеспече% ния является модульность – создание систем из заменяемых компонент. Это похоже на конструктор «Лего». При правильной организации ничто не должно помешать вам вынуть голубой брусок и заменить его более приятным красным. Если бруски одинаковой формы и размера, с одинаковым типом соединения, их можно вставить в одно и то же место, и они будут выполнять одинаковые функции.

Как это реализуется в программном обеспечении? Мы определяем интерфейсы; это наши точки соединения и границы компонент. Они устанавливают размер и форму каждой компоненты (по край% ней мере, как они видятся снаружи) и определяют, что нужно сде% лать для равноценной замены. Вот основные типы интерфейсов:

API

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

Иеарархии классов

Можно спроектировать абстрактный класс «интерфейса» (в Java и C# вы фактически определяете интерфейс). После этого можно создать сколько угодно производных классов, которые будут реализовывать этот интерфейс.

Компонентные технологии

Такие технологии, как COM и CORBA, позволяют программе определять нужную реализацию компоненты на этапе выпол% нения. Обычно интерфейсы определяются с помощью абст% рактного языка определения интерфейсов IDL (Interface De# finition Language). Прелесть такого метода в том, что компо% ненты можно написать на любом языке. Необходимы под% держка со стороны промежуточного ПО или ОС.

Архитектура

в «макаронном» стиле:

Ракушки

Отдельные кусочки, плавающие в связующем их соусе.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
										r
P						NOW!				o
					BUY
				to
w Click								Архитектурныеm			стили
w
	w									o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
357Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Форматы данных

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

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

Иногда встречается расширение данной двухуровневой схемы, когда вводится еще один (промежуточный) уровень. Этот уровень специаль% но создается для реализации бизнес%логики, отделяя ее как от клиент% ского приложения (которое теперь определенно ограничивается ин% терфейсом), так и от хранилища данных на сервере. Это трехуровне# вая архитектура.

Архитектура клиент/сервер отличается от одноранговой (peer#to#peer) архитектуры, в которой никакие сетевые узлы не обладают особыми возможностями или значением по сравнению с остальными. Одноран% говые архитектуры труднее развертывать, но они отличаются повы% шенной устойчивостью к отказам. Архитектура клиент/сервер оказы% вается парализованной, когда недоступен сервер (вследствие сбоя про% граммы или планового обслуживания): ни один клиент не сможет ра% ботать, пока сервер не задышит снова. По этой причине системы, организованные по принципу клиент/сервер, обычно требуют нали% чия администратора, который обеспечивает их бесперебойную работу.

Компонентная архитектура

В этой архитектуре управление децентра% лизовано, и вместо единой монолитной структуры она разбита на ряд отдельных взаимодействующих между собой компо# нент. Это объектно%ориентированный под% ход, который не требует обязательной реа% лизации на каком%либо из ОО%языков. От% крытые интерфейсы всех компонент обыч%

но определяются на языке определения интерфейсов (IDL) и отделены от какой%либо реализации, хотя в некоторых компонентных техноло% гиях (например, встроенной поддержке компонент .NET) могут опре% деляться в самом коде реализации.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								358m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 14. Программная архитектураClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Стержнем компонентной архитектуры является инфраструктура ком% муникаций, или промежуточное программное обеспечение, благодаря которому компоненты могут подключаться, оповещать о своем суще% ствовании и объявлять о предоставляемых ими услугах. Связи между компонентами не фиксируются жестко, а устанавливаются в результа% те поиска этой информации через механизм промежуточного слоя. В число обычных компонентных платформ входят CORBA, JavaBeans и COM; у каждой из них есть свои достоинства и слабые стороны.

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

Каждая компонента – это отдельный независимый блок кода. За види% мым интерфейсом находятся логика реализации (это может быть биз% нес%логика или функция пользовательского интерфейса и т. п.), а так% же некоторые данные, которые могут быть локальными или открыты% ми (например, если компонента хранит файлы или базу данных). Ком% поненты не должны слишком много знать друг о друге. Если они тесно связаны между собой, то такая архитектура представляет собой просто запутанную монолитную систему.

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

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

жалению, эти термины несут в себе несколько значений.