Эталонная модель. Эталонная моДель OSI

Привет, посетитель сайта сайт! Продолжаем рубрику Сервера и протоколы. Сегодня мы поговорим о том, как происходит взаимодействие в сети Интернет, да вообще в любой компьютерной сети, разобравшись с тем, что такое модель OSI, для чего нужна семиуровневая модель OSI и кто и когда разработал эталонную модель сетевого взаимодействия OSI. Итак, данная статья посвящена семиуровневой модели взаимодействия OSI. Естественно, разбираться с принципами работы модели OSI мы будем на простых примерах, буквально на пальцах . А в тех местах, где будут сложные моменты, я буду стараться давать ссылки на материалы, в которых вы найдете простое объяснение этих моментов.

В данной публикации мы поговорим о том, что такое семиуровневая модель взаимодействия OSI что собой она представляет. Разберемся с тем для чего нужна эталонная сетевая модель OSI и кто и когда ее разработал. Рассмотрим архитектуру семиуровневой модели OSI и поговорим про каждый ее уровень в отдельности. Посмотрим на простые примеры, описывающие принципы работы модели OSI: один пример будет очень простым, а второй пример объясняет принцип работы модели OSI буквально на пальцах. И в завершении публикации мы погорим про недостатки эталонной модели OSI и узнаем почему протоколы модели OSI , в отличии от самой модели, не получили такого широкого распространения .

Что такое эталонная модель OSI?

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

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

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

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

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

Для чего нужна модель OSI и кто разработал данную модель?

Ответим на вторую часть вопроса данного раздела: кто разработал эталонную модель взаимодействия OSI ? Модель OSI разработала международная организация стандартизации ISO. Отчасти теперь становится понятно, почему модель OSI называют эталонной. Теперь поговорим о том, для чего нужна модель взаимодействия OSI.

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

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

Соответственно, они должны выбрать оборудование, которое будет установлено, определить точку, от которой будет подключено новое оборудование (выбрать ее на самом деле нужно оптимально) и определить маршрут, по которому будут проложены коммуникации. Другими словами – разработать проект. Мы видим уже, что эти люди должны обладать несколько другим и даже несколько более широким спектром знаний, нежели монтажники.

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

Мы лишь поверхностно коснулись структуры ШПД провайдера, но уже заметили, что есть три группы специалистов с разным набором знаний и разными функциями, теперь нам будет несколько проще разобраться с тем, для чего нужна модель сетевого взаимодействия OSI .

Итак, семиуровневая модель OSI делит процесс передачи данных на несколько уровней. Это деление обусловлено тем, что ни один человек в мире не может знать всего и сразу. Таким образом модель OSI делит зоны ответственности между людьми и, как ни странно, между сетевым оборудованием и приложениями. Например, заметим, что если у вас не работает какой-то сайт в Интернете, то в 99 случаях из 100 – это не повод звонить в тех. поддержку вашего провайдера. Провайдер не виноват в том, что какой-то сайт не работает, он лишь предоставляет вам доступ в общую компьютерную сеть Интернет, но не отвечает за работоспособность того или иного ресурса.

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

Для начала поговорим про мифологию, а именно – про Вавилонскую башню. Ее строительство закончилось плачевно, так как в один момент, неожиданно, люди перестали понимать друг друга и не смогли слаженно взаимодействовать, чтобы успешно завершить строительство. Примерно такая же ситуация произошла в 70-ых годах XX века: к этому моменту в мире накопилось очень много различных фирменных сетевых протоколов, и очень остро встал вопрос взаимодействия между машинами в сети.

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

И, как вы уже догадались, в качестве выхода из сложившейся ситуации была разработка эталонной модели сетевого взаимодействия OSI . Естественно, модель OSI – это академический подход и ее разработка заняла около 7 лети. Заметим, что модель OSI лишь описывает принципы взаимодействия устройств в сети, но не говорит о том, как это должно быть реализовано физически.

Ранее мы уже упоминали о том, что HTTP протокол находится на самом верхнем (седьмом) уровне эталонной модели взаимодействия OSI, из чего можно сделать вывод о том, что всего насчитывается семь уровней модели OSI, поэтому иногда модель OSI называют семиуровневой моделью . Заметим, что самый нижний уровень модели взаимодействия OSI называется физический или, как его еще называют, первый уровень модели OSI, самый верхний уровень называют прикладной уровень модели OSI или седьмой уровень.

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

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

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

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

Первый уровень модели OSI. Физический уровень эталонной модели взаимодействия

Физический уровень модели OSI – это самый нижний уровень эталонной модели сетевого взаимодействия, который определяет способ передачи и представления информации между устройствами. Разработкой методов передачи данных в различных средах занимаются различные институты стандартизации и телекоммуникационные институты.

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

оптимальный уровень сигнала (минимальный и максимальный);
какой уровень сигнала считать нулем;
какой уровень сигнала считать единицей;
какую модуляцию сигнала использовать;
и прочее.

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

Как ни странно, но на физическом уровне уже происходит деление на клиент и сервер. Также на физическом уровне есть свои собственные протоколы: различные протоколы Wi-Fi, GSM, Bluetooth и другие.

Второй уровень модели OSI. Канальный уровень эталонной модели взаимодействия

Канальный уровень модели OSI является вторым по счету . На канальном уровне происходит две важных вещи:

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

Как мы уже видели, единицей измерения информации на втором уровне модели OSI является кадр, который состоит из нескольких бит полезной информации и служебной информации. Канальный уровень модели OSI делится на два подуровня:

Подуровень MAC. На этом подуровне определяется доступ к физической среде, за счет данного подуровня канальный уровень может взаимодействовать с несколькими физическими уровнями.
Подуровень LLC. Данный подуровень обеспечивает взаимодействие с сетевым уровнем модели OSI.

Самым широко распространённым устройством второго уровня модели OSI является коммутатор доступа , который устанавливается практически в каждом доме провайдером, именно к коммутатору подключаются роутеры, которые стоят в наших квартирах. Если говорить про наши компьютеры, то второй уровень модели OSI представлен в виде драйверов для сетевой платы.

В качестве примера протоколов канального уровня можно привести: wireless LAN, PPPoE, Ethernet.

Третий уровень модели OSI. Сетевой уровень эталонной модели взаимодействия

Сетевой уровень модели OSI является третьим по счету уровнем эталонной модели сетевого взаимодействия . На третьем уровне модели OSI происходит формирование маршрутов и путей передачи данных между устройствами, находящимися в сети. Естественно, маршрут определяется оптимально и при этом учитывается дальность маршрута и нагрузка на узлы сети.

Также на третьем уровне эталонной модели происходит преобразование логических сетевых адресов в физические и наоборот, этот процесс получил название – трансляция. Роутеры, установленные в ваших квартирах – это хороший пример устройств сетевого уровня модели OSI . Самым популярным протоколом третьего уровня модели OSI является протокол IP, на данный момент поддерживается две версии протокола IP: IPv4 и IPv6.

Четвертый уровень модели OSI. Транспортный уровень эталонной модели взаимодействия

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

Четвертый уровень модели OSI насчитывает множество различных протокол передачи данных: есть протоколы, которые только лишь обеспечивают транспортные функции, а есть протоколы, которые гарантируют правильную передачу данных по сети. В зависимости от потребностей и технических условий выбирается тот или иной протокол. Например, потоковое видео в Интернете никто не будет предавать по протоколу, гарантирующему 100% правильность передачи данных, в качестве примера такого протокола можно привести UPD.

Если же говорить о протоколе, который гарантирует правильность передачи данных то в качестве примера можно привести TCP. Протокол TCP является протоколом транспортного уровня модели OSI и гарантирует надёжность и правильность передачи данных по сети , также он исключает потерю данных в процессе их передачи и обеспечивает не нарушения порядка поступления данных, то есть данные по протоколу TCP придут на приемное устройство в том порядке, в котором они передавались.

Пятый уровень модели OSI. Сеансовый уровень эталонной модели взаимодействия

Пятый уровень модели взаимодействия OSI или сеансовый уровень предназначен для управления сеансом связи. Сеансовый уровень позволяет взаимодействовать сетевым приложениям длительное время. Пятый уровень модели сетевого взаимодействия OSI призван решать следующие проблемы:

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

На самом деле, задачи сеансового уровня модели OSI несколько шире, чем описаны выше. В качестве примера протоколов сеансового уровня можно привести: ADSP, PPTP, H.245.

Шестой уровень модели OSI. Уровень представления эталонной модели взаимодействия

Уровень представления или представительский уровень модели OSI является шестым уровнем эталонной модели сетевого взаимодействия. Шестой уровень модели OSI определяет способы представления данных, а также способы шифрования передачи данных. Например, протокол HTTP никак не шифрует данные при передаче, поэтому эти функции на себя берут протоколы SSL и TLS, которые относятся к шестому уровню модели OSI.

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

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

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

Седьмой уровень модели OSI. Прикладной уровень эталонной модели взаимодействия

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

В качестве примера рассмотрим , например, ( нам в данном случае не очень подходит), во-первых, указывая TCP порт, а как вы помните, протокол TCP работает на четвертом уровне модели взаимодействия, то есть мы можем сделать вывод, что в клиентской части MySQL есть механизмы, позволяющие взаимодействовать с четвертым уровнем модели OSI.

Эталонная модель OSI

Это описательная схема сети; ее стандарты гарантируют высокую совместимость и способность к взаимодействию различных типов сетевых технологий. Кроме того, она иллюстрирует процесс перемещения информации по сетям. Модель OSI описывает, каким образом информация проделывает путь через сетевую среду (например, провода) от одной прикладной программы (например, программы обработки таблиц) к другой прикладной программе, находящейся в другом подключенном к сети компьютере.

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

Поскольку нижние уровни (с 1 по 3) модели OSI управляют физической доставкой сообщений по сети, их часто называют уровнями среды передачи данных (media layers). Верхние уровни (с 4 по 7) модели OSI обеспечивают точную доставку данных между компьютерами в сети, поэтому их часто называют уровнями хост-машины (host layers).

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

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

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

К числу наиболее распространенных протоколов верхних уровней относятся:

FTP - протокол переноса файлов

TFTP - упрощенный протокол переноса файлов

X.400 - электронная почта

SMTP - простой протокол почтового обмена

CMIP - общий протокол управления информацией

SNMP - простой протокол управления сетью

NFS - сетевая файловая система

FTAM - метод доступа для переноса файлов

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

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

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

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

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

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

Проще говоря транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень.

Наиболее распространенные протоколы транспортного уровня включают:

TCP - протокол управления передачей

NCP - Netware Core Protocol

SPX - упорядоченный обмен пакетами

TP4 - протокол передачи класса 4

Сетевой уровень (уровень 3) - это комплексный уровень, который обеспечивает возможность соединения и выбор маршрута между двумя конечными системами.

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

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

Наиболее часто на сетевом уровне используются протоколы:

IP - протокол Internet

IPX - протокол межсетевого обмена

X.25 (частично этот протокол реализован на уровне 2)

CLNP - сетевой протокол без организации соединений

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

Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде. (Он же IEEE 802.1 - задает стандарты управления сетью на MAC-уровне, включая алгоритм Spanning Tree. Этот алгоритм используется для обеспечения единственности пути (отсутствия петель) в многосвязных сетях на основе мостов и коммутаторов с возможностью его замены альтернативным путем в случае выхода из строя.)

Наиболее часто используемые на уровне 2 протоколы включают:

HDLC для последовательных соединений

IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x

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

Этот уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включаютя:

Тип кабелей и разъемов

Разводку контактов в разъемах

Схему кодирования сигналов для значений 0 и 1

К числу наиболее распространенных спецификаций физического уровня относятся:

EIA-RS-232-C, CCITT V.24/V.28 - механические/электрические характеристики несбалансированного последовательного интерфейса.

EIA-RS-422/449, CCITT V.10 - механические, электрические и оптические характеристики сбалансированного последовательного интерфейса.

IEEE 802.3 -- Ethernet

IEEE 802.5 -- Token ring

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

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

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

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

Например..пять этапов преобразования:

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

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

Эталонная модель OSI являет собой 7-уровневую сетевую иерархию созданную международной организацией по стандартам (ISO). Представленная модель на рис.1 имеет 2 различных модели:

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

В вертикальной — соседние уровни меняются информацией с помощью интерфейсов API. Горизонтальная модель требует общий протокол для обмена информацией на одном уровне.

Рисунок — 1

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

Физический уровень

На физическом уровне данные представлены в виде электрических или оптических сигналов, соответствующие 1 и 0 бинарного потока. Параметры среды передачи определяются на физическом уровне:

тип разъемов и кабелей
разводка контактов в разъемах
схема кодирования сигналов 0 и 1

Самые распространенные виды спецификаций на этом уровне:

— параметры несбалансированного последовательного интерфейса
— параметры сбалансированного последовательного интерфейса
IEEE 802.3 —
IEEE 802.5 —

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

Канальный уровень

На этом канале реализована транспортировка и прием кадров данных. Уровень реализует запросы сетевого уровня и использует физический уровень для приема и передачи. Спецификации IEEE 802.x делят этот уровень на два подуровня управление логическим каналом (LLC) и управление доступом к среде (MAC). Самые распространенные протоколы на этом уровне:

IEEE 802.2 LLC и MAC
Ethernet
Token Ring

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

Сетевой уровень

На этом уровне происходит деление пользователей сети на группы. Здесь реализуется маршрутизация пакетов на основе MAC-адресов. Сетевой уровень реализует прозрачную передачу пакетов на транспортный уровень. На этом уровне стираются границы сетей разных технологий. работают на этом уровне. Пример работы сетевого уровня показан на рис.2 Самые частые протоколы:

Рисунок — 2

Транспортный уровень

На этом уровне потоки информации делятся на пакеты для передачи их на сетевом уровне. Самые распространенные протоколы этого уровня:

TCP — протокол управления передачей

Сеансовый уровень

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

Уровень представления

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

Прикладной уровень

Прикладной уровень реализует доступ приложения в сеть. Уровень управляет переносом файлов и управление сетью. Используемые протоколы:

FTP/TFTP — протокол передачи файлов
X 400 — электронная почта
Telnet
CMIP — управление информацией
SNMP — управление сетью
NFS — сетевая файловая система
FTAM — метод доступа для переноса файлов

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

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

С таким разделением и обеспечением взаимосвязи тесно связаны две группы вопросов стандартизации:

стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface - API);
стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI).

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

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

Совокупность таких описаний составляет эталонную модель взаимосвязи открытых систем (Open Systems Interconnection - OSI) . Эта модель используется более 30 лет, она "выросла" из сетевой архитектуры SNA (System Network Architecture), предложенной компанией IBM. Модель взаимосвязи открытых систем используется в качестве основы для разработки многих стандартов ISO в области ИТ. Публикация этого стандарта подвела итог многолетней работы многих известных стандартизующих организаций и производителей телекоммуникационных средств.

В 1984 году модель получила статус международного стандарта ISO 7498, а в 1993 году вышло расширенное и дополненное издание ISO 7498-1-93. Стандарт имеет составной заголовок "Информационно-вычислительные системы - Взаимосвязь (взаимодействие) открытых систем - Эталонная модель". Краткое название - "Эталонная модель взаимосвязи (взаимодействия) открытых систем" (Open Systems Interconnection / Basic Reference Model - OSI/BRM).

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

Рис. 2.6.

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

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

В стандарте ISO 7498 выделено семь уровней (слоев) информационного взаимодействия, которые отделены друг от друга стандартными интерфейсами:

уровень приложения (прикладной уровень)
уровень представления
сеансовый (уровень сессии)
транспортный
сетевой
канальный
физический.

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

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

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

Инкапсуляция - это процесс помещения фрагментированных блоков данных одного уровня в блоки данных другого уровня.

При разбиении среды на уровни соблюдались следующие общие принципы:

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

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

Уровень 1 - уровень приложения или прикладной уровень (Application Layer). Этот уровень связан с прикладными процессами. Протоколы уровня предназначены для обеспечения доступа к ресурсам сети и программам-приложениям пользователя. На данном уровне определяется интерфейс с коммуникационной частью приложений. В качестве примера протоколов прикладного уровня можно привести протокол Telnet, который обеспечивает доступ пользователя к "хосту" (главному вычислительному устройству, одному из основных элементов в многомашинной системе или любому устройству, подключенному к сети и использующему протоколы TCP/IP) в режиме удаленного терминала.

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

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

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

Уровень 2 - уровень представления (Presentation Layer). На этом уровне информация преобразуется к такому виду, в каком это требуется для выполнения прикладных процессов. Уровень представления обеспечивает кодирование данных, выдаваемых прикладными процессами, и интерпретацию передаваемых данных. Например, выполняются алгоритмы преобразования формата представления данных для печати - ASCII или КОИ-8. Или, если для визуализации данных используется дисплей, то эти данные по заданному алгоритму формируются в виде страницы, которая выводится на экран.

Представительный уровень выполняет следующие основные функции:

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

Уровень 3 - сеансовый уровень или уровень сессии (Session Layer). На данном уровне устанавливаются, обслуживаются и прекращаются сессии между представительными объектами приложений (прикладными процессами). В качестве примера протокола сеансового уровня можно рассмотреть протокол RPC (Remote Procedure Call). Как следует из названия, данный протокол предназначен для отображения результатов выполнения процедуры на удаленном хосте. В процессе выполнения этой процедуры между приложениями устанавливается сеансовое соединение. Назначением данного соединения является обслуживание запросов, которые возникают, например, при взаимодействии приложения-сервера с приложением-клиентом.

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

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

Уровень 4 - транспортный уровень (Transport Layer). Транспортный уровень предназначен для управления потоками сообщений и сигналов. Управление потоком является важной функцией транспортных протоколов, поскольку этот механизм позволяет надёжно обеспечивать передачу данных по сетям с разнородной структурой, при этом в описание маршрута включаются все компоненты коммуникационной системы, обеспечивающие передачу данных на всем пути от устройств отправителя до приемных устройств получателя. Управление потоком заключается в обязательном ожидании передатчиком подтверждения приема обусловленного числа сегментов приемником. Количество сегментов, которое передатчик может отправить без подтверждения их получения от приемника, называется окном.

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

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

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

Кроме этого, транспортный уровень может восстанавливать блоки данных, потерянные на нижних уровнях.

Уровень 5 - сетевой уровень (Network Layer). Основной задачей протоколов сетевого уровня является определение пути, который будет использован для доставки пакетов данных при работе протоколов верхних уровней (маршрутизация). Для того чтобы пакет был доставлен до какого-либо заданного хоста, этому хосту должен быть поставлен в соответствие известный передатчику сетевой адрес. Группы хостов, объединенные по территориальному принципу, образуют сети. Для упрощения задачи маршрутизации сетевой адрес хоста составляется из двух частей: адреса сети и адреса хоста. Таким образом, задача маршрутизации распадается на две - поиск сети и поиск хоста в этой сети. На сетевом уровне могут выполняться следующие функции:

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

Уровень 6 - канальный уровень или уровень звена данных (Data Link Layer). Назначением протоколов канального уровня является обеспечение передачи данных в среде передачи по физическому носителю. В канале формируется стартовый сигнал передачи данных, организуется начало передачи, производится сама передача, проводится проверка правильности процесса, производится отключение канала при сбоях и восстановление после ликвидации неисправности, формирование сигнала на окончание передачи и перевода канала в ждущий режим.

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

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

На канальном уровне данные передаются в виде блоков, которые называются кадрами. Тип используемой среды передачи и её топология во многом определяют вид кадра протокола транспортного уровня, который должен быть использован. При использовании топологии "общая шина" (Common Bus) и "один-ко-многим" (Point-to-Multipoint) средства протокола канального уровня задают физические адреса, с помощью которых будет производиться обмен данными в среде передачи и процедура доступа к этой среде. Примерами таких протоколов являются протоколы Ethernet (в соответствующей части) и HDLC. Протоколы транспортного уровня, которые предназначены для работы в среде типа "один-к-одному" (Point-to-Point), не определяют физических адресов и имеют упрощенную процедуру доступа. Примером протокола такого типа является протокол PPP.

Уровень 7 - физический уровень (Physical Layer). Протоколы физического уровня обеспечивают непосредственный доступ к среде передачи данных для протоколов канального и последующих уровней. Данные передаются с помощью протоколов данного уровня в виде последовательностей битов (для последовательных протоколов) или групп битов (для параллельных протоколов). На этом уровне определяются набор сигналов, которыми обмениваются системы, параметры этих сигналов (временные и электрические) и последовательность формирования сигналов при выполнении процедуры передачи данных.

Физический уровень выполняет следующие функции:

устанавливает и разъединяет физические соединения;
передает последовательность сигналов;
"прослушивает" в нужных случаях каналы;
выполняет идентификацию каналов;
оповещает о появлении неисправностей и отказов.

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

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

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

Рис. 2.9.

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

Предлагаемая эталонная модель BPM (Business Process Management) основывается на цепочке следующих предпосылок:

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

BPM (как дисциплина) предлагает системный подход к реализации процессного управления;

На каждом процессно-управляемом предприятии есть своя BPM-система - портфолио всех бизнес-процессов, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио;

Гибкость BPM-системы предприятия является основным фактором ее успеха;

Специализированная программная платформа (BPM suite) для реализации BPM-системы предприятия необходима, но недостаточна, так как BPM занимает особое место в архитектуре предприятия.

Цель: повышение производительности предприятия

Для управления своей производительностью большинство предприятий используют принцип обратной связи (рис. 1), позволяющий адаптироваться к внешней бизнес-экосистеме путем выполнения определенной последовательности действий:

Измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или индикаторов, например, процент возвращающихся клиентов);

Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);

Определение стратегии развития бизнеса предприятия;

Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).

В соответствии с классической рекомендацией Эдварда Деминга, автора многочисленных работ в области управления качеством, в том числе известной книги «Выход из кризиса», все усовершенствования должны проводиться циклично, непрерывно и с проверкой на каждом цикле. Степень и частота этих усовершенствований зависят от конкретной ситуации, но рекомендуется делать такие циклы достаточно компактными. Различные усовершенствования могут затрагивать различные аспекты работы предприятия. Вопрос в том, как предприятие может достигнуть наилучших результатов в каждом конкретном случае? Существуют две объективные предпосылки для оптимизации деятельности предприятия как единого целого:

Обеспечение руководства надлежащей информацией и инструментами для принятия решения;

Гарантия того, что бизнес-система предприятия способна к осуществлению необходимых изменений в необходимом темпе.

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

Процессное управление

Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, и др.), что службы и процессы - это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, как портфолио бизнес-процессов и методов управления ими.

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

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

Кроме процессов и служб, бизнес-системы предприятий работают с событиями, правилами, данными, индикаторами работы, ролями, документами и т.д.

Для реализации процессного управления предприятия используют три популярные дисциплины постоянного усовершенствования бизнес-процессов: ISO 9000, Six Sigma и «бережливое», или «экономное», производство (Lean production). Они воздействуют на различные области бизнес-системы предприятия, однако всегда предусматривается сбор данных о фактически проделанной работе и использование некой модели бизнес-процессов для принятия решений (хотя иногда эта модель находится только в чьей-то голове). В то же самое время они предлагают различные и взаимодополняющие методы для того, чтобы определить, какие именно изменения необходимы для улучшения функционирования бизнес-системы предприятия.

Что моделируете, то и выполняете

На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.

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

Такое описание - основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).

На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation , графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language , формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.

Ситуация усугубляется тем, что за различными форматами стоят различные производители и каждый старается «протолкнуть» на рынок свое решение. Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание - сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML , успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов. Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик - более подробную и т.п.).

Все это не означает, что BPEL или XPDL станут ненужными - их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.

Дисциплина BPM в культуре предприятия

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

события (events) - явления, происшедшие в пределах и вне границ предприятия, на которые возможна некая реакция бизнес-системы, например, при получении заказа от клиента необходимо начать бизнес-процесс обслуживания;

объекты (data and documents objects) - формальные информационные описания реальных вещей и людей, образующих бизнес; это информация на входе и выходе бизнес-процесса, например, бизнес-процесс обслуживания заказа получает на входе собственно формуляр заказа и информацию о клиенте, а на выходе формирует отчет о выполнении заказа;

деятельности (activities) - мелкие работы, преобразующие объекты, например автоматические деятельности типа проверки кредитной карты клиента или деятельности, осуществляемые человеком, такие как визирование документа руководством;

правила (rules) - ограничения и условия, при которых функционирует предприятие, например, выдача кредита на определенную сумму должна утверждаться генеральным директором банка;

роли (roles) - понятия, представляющие соответствующие навыки или обязанности, требуемые для выполнения определенных действий, например, только менеджер высшего звена может подписать конкретный документ;

аудиторские следы (audit trails) - информация о выполнении конкретного бизнес-процесса, например, кто сделал, что и с каким результатом;

основные индикаторы производительности (Key Performance Indicator, KPI) - ограниченное число показателей, измеряющих степень достижения поставленных целей.

Рис. 4 иллюстрирует распределение артефактов между различными частями бизнес-системы предприятия. Выражение «процессы (как шаблоны)» означает абстрактные описания (модели или планы) процессов;

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

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

BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы.

Улучшение BPM-системы предприятия, помимо чисто технических аспектов, должно учитывать социо-технические вопросы. У BPM-системы предприятия есть много заинтересованных лиц, каждое из которых решает свои задачи, воспринимает BPM-дисциплину своим образом и работает со своими артефактами. Для успешного развития BPM-системы предприятия необходимо обратить особое внимание на проблемы всех заинтересованных лиц и заранее объяснить им, как улучшение BPM-системы предприятия изменит их работу к лучшему. Крайне важно достигнуть единого понимания всех артефактов среди всех заинтересованных лиц.

Специализированное ПО для реализации BPM-систем

Растущая популярность и большой потенциал BPM вызвали появление нового класса корпоративного ПО - BPM suite, или BPMS, содержащего следующие типичные компоненты (рис. 5):

Инструмент моделирования (Process modelling tool) - графическая программа для манипулирования такими артефактами, как события, правила, процессы, активности, службы и т.д.;

Инструмент тестирования (Process testing tool) - среда функционального тестирования, которое позволяет «исполнять» процесс по различным сценариям;

Хранилище шаблонов (Process template repository) - база данных шаблонов бизнес-процессов с поддержкой различных версий одного и того же шаблона;

Исполнитель процессов (Process execution engine);

Хранилище экземпляров (Process instance repository) - база данных для выполняемых и уже выполненных экземпляров бизнес-процессов;

Список работ (Work list) - интерфейс между BPM suite и пользователем, выполняющим некоторые активности в рамках одного или нескольких бизнес-процессов;

Приборная панель (Dashboard) - интерфейс оперативного контроля за исполнением бизнес-процессов;

Инструмент анализа (Process analysis tool) - среда для изучения тенденции исполнения бизнес-процессов;

Инструмент имитационного моделирования (Process simulation tool) - среда для тестирования производительности бизнес-процессов.

Необходимость взаимодействия между BPM suite и корпоративным ПО, которое поддерживает другие артефакты, вызвала появление нового класса корпоративного ПО - Business Process Platform (BPP). Типичные технологии BPP (рис. 6):

Business Event Management (BEM) - анализ бизнес-событий в режиме реального времени и запуск соответствующих бизнес-процессов (BEM связан с Complex Event Processing (CEP) и Event Driven Architecture (EDA));

Business Rules Management (BRM) - явное и формальное кодирование бизнес-правил, которые могут модифицироваться пользователями;

Master Data Management (MDM) - упрощение работы со структурированными данными за счет устранения хаоса при использовании одних и тех же данных;

Enterprise Content Management (ECM) - управление корпоративной информацией, предназначенной для человека (обобщение понятия документ);

Configuration Management Data Base (CMDB) - централизованное описание всей информационно-вычислительной среды предприятия, используемое для привязки BPM к информационно-вычислительным ресурсам предприятия;

Role-Based Access Control (RBAC) - управления доступом к информации с целью эффективного разделения контрольных и исполнительских полномочий (separation of duty);

Business Activity Monitoring (BAM) - оперативный контроль функционирования предприятия;

Business Intelligence (BI) - анализ характеристик и тенденций работы предприятия;

Service-Oriented Architecture (SOA) - архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб, который используется для реализации, выполнения и управления службами;

Enterprise Service Bus (ESB) - среда коммуникаций между службами в рамках SOA.

Таким образом, дисциплина BPM способна обеспечить единое, формальное и выполнимое описание бизнес-процессов, которое может использоваться в различных инструментах BPM suite, причем реальные данные собираются во время выполнения бизнес-процессов. Вместе с тем высокая гибкость BPM-системы предприятия не гарантируется автоматически после покупки BPM suite или BPP - способность конкретной BPM-системы развиться в необходимом темпе должна проектироваться, реализовываться и постоянно контролироваться. Как и здоровье человека, все это нельзя купить.

BPM в архитектуре предприятия

Необходимость вовлечения практически всего корпоративного ПО в единую логику улучшения BPM-системы предприятия поднимает вопрос о роли и месте BPM в архитектуре предприятия (Enterprise Architecture, EA). EA является на сегодня устоявшейся практикой ИТ-департаментов по упорядочению информационно-вычислительной среды предприятия. В основе EA лежат следующие правила:

Текущая ситуация с информационно-вычислительной средой предприятия тщательно документируется как исходная точка as-is;

Желаемая ситуация документируется как конечная точка to-be;

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

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

Дисциплина BPM может решить основную проблему EA - дать объективную оценку производственно-хозяйственных возможностей (а не только информационно-вычислительных) того, что будет в точке to-be. Несмотря на то что EA описывает полную номенклатуру артефактов предприятия (его генотип), она не может достоверно сказать, какие изменения в этом генотипе влияют на конкретные производственно-хозяйственные характеристики предприятия, то есть на фенотип предприятия (cовокупность характеристик, присущих индивиду на определенной стадии развития).

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

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

В некотором смысле комбинация EA+BPM может стать своего рода навигатором, который обеспечивает руководство и практическую помощь в развитии бизнеса и ИТ при реализации генеральной линии предприятия.

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

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

Александр Самарин ([email protected]) - корпоративный архитектор ИТ-департамента правительства кантона Женева (Швейцария).

Process Frameworks для BPM

Подход к реализации технологий управления бизнес-процессами, упрощающий внедрение BPM-систем, подразумевает четкое определение бизнес-задачи и соответствующих ей бизнес-процессов; реализацию этих процессов за срок не более трех месяцев с целью демонстрации ценности данного подхода; дальнейшее расширение реализации на основные бизнес-задачи. Однако главная трудность на этом пути - недопонимание и отсутствие согласованности между бизнес- и ИТ-подразделениями. Значительно упростить проект внедрения и сократить затраты позволяют специализированные референсные модели (Process Frameworks).

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

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

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

Однако, как отмечают аналитики AMR Research, «технологии и методы сами по себе не способны обеспечить каких-либо преимуществ - «больше» не всегда значит «лучше». Некоторые компании применяют множество различных решений, однако эффективность от этого только падает. Важна грамотность применения таких технологий». В референсных моделях в качестве основы используются принятые в отрасли стандарты и опыт компании Software AG по созданию эталонной модели для определения требований клиентов. На практике эта модель становится отправной точкой, с помощью которой клиенты могут создать нужную модель.

Process Framework, например, для бизнес-процесса обработки заказов, включает в себя базовую модель процесса со схемами действий для различных пользователей и ролей, избранные KPI из модели SCOR (The Supply-Chain Operations Reference-model) для процесса в целом и отдельных этапов, правила поддержки разных последовательностей обработки, например с учетом сегмента клиентов, целевые показатели для различных сегментов клиентов, типов продукции и регионов, а также панели индикации, помогающие контролировать особые ситуации.

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

Владимир Аленцев ([email protected]) - консультант по BPM и SOA , представительство Software AG в России и СНГ (Москва).