Создание и использование WEB-сервисов

Содержание

Содержание

Недостатки предыдущих технологий и предпосылки перехода к СОА

Как решается задача интеграции приложений? Традиционный подход —  построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности — правда, с естественным ограничением гетерогенности — предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.

В то же время новые  потребности бизнеса диктуют  и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение  бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач — эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, «точечные» решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений — n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.

Рис. 1. Прямая интеграция приложений

Еще одна серьезная проблема — избыточность программных компонентов и сложность их многократного использования.

Все эти интеграционные проблемы и привели к появлению  идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.

Очень часто становление  того или иного подхода сопровождается появлением неверных или ошибочных трактовок:

SOA не является чем-то  новым: IT-отделы компаний успешно  создавали и развертывали приложения, поддерживающие сервис-ориентированную  архитектуру, уже много лет  - задолго до появления XML и  Web-сервисов.

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

Покупка самых новых  продуктов, реализующих XML и Web-сервисы, не означает построения приложений в  соответствии с принципами SOA.

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

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

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

Отметим некоторые из этих принципов.

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

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александер показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

Собственно Web-сервисы

Web-cервис это программный интерфейс, который описывает набор операций, которые могут быть вызваны удаленно по сети посредством стандартизированных XML сообщений. Для описания вызываемой операции или данных используются протоколы, базирующиеся на языке XML. Группа Web-сервисов взаимодействующая друг с другом подобным образом, определяет приложение Web-сервисов в рамках Серис-Ориентированной архитектуры (Service-Oriented Architecture - SOA).

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

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

• TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;
• HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;
• XML – универсальный язык для работы с любыми типами данных.

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

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

Подробнее остановимся на плюсах и  минусах.

К плюсам веб-сервисов можно  отнести следующее:

1. Веб-сервисы позволяют компании интеграцию собственных бизнес-процессов с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;
2. Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;
3. Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;
4. Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

Не менее подробно остановимся и на минусах веб-сервисов:

1. Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;
2. Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов “на лету”, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries));
3. Добавление к функциям сервера приложений функциональности провайдера веб-сервисов (в т. ч. SOAP-сервера) в силу новизны технологий может представлять определенную трудность;
4. Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

Стек технологий веб-сервисов

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

Рис. 1: Стек технологий веб-сервисов

Стек технологий веб-сервисов принципиально разбивается на следующие  две составляющие:

• технологии, обеспечивающие функциональность веб-сервисов (Functions);
• технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).

Эти составляющие в свою очередь образуются несколькими слоями (layers):

• технологии, обеспечивающие функциональность веб-сервисов:
• транспортный слой (transport layer);
• коммуникационный слой (service communication layer);
• слой описаний сервисов (service description layer);
• сервисный слой (service layer);
• слой бизнес-процессов (business process layer);
• слой реестров сервисов (service registry layer).
• технологии, обеспечивающие качество сервиса веб-сервисов:
• слой политик (policy layer);
• слой безопасности (security layer);
• слой транзакций (transaction layer);
• слой управления (management layer).

В целях понимания назначения слоев, дадим краткое описание каждого  из них.

Представленный выше стек технологий веб-сервисов вводит иерархию во множество технологий веб-сервисов в соответствии с их функциональным назначением. При этом в таблице  указаны лишь наиболее широко применяемые и устоявшиеся технологии. Стандартными названы технологии, получившие официальный статус стандартов международных консорциумов по разработке IT-стандартов (W3C, OASIS либо WS-I). В действительности, спектр технологий, описывающих те или иные аспекты использования веб-сервисов либо сервисно-ориентированных архитектур, крайне широк, в частности, потому, что процесс разработки данных технологий является открытым - любая компания, некоммерческое объединение специалистов или даже один специалист может разработать и опубликовать спецификацию разработанной им технологии. В настоящее время это даже стало серьезной проблемой рынка веб-сервисов - количество спецификаций стало столь велико, что при фактической нерегламентированности глобального (в рамках всей индустрии) процесса их разработки, ввода в действие и использования, появляется опасность ввергнуть индустрию в хаос и технологическую разобщенность. А технологическая разобщенность - как раз то, от чего хотели уйти прежде всего, разрабатывая веб-сервисы и закладывая в качестве их концептуальной и технологической основы открытые и наиболее широко применяемые IT-технологии.

Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной  архитектуры

В настоящее время  технологический фундамент веб-сервисов образуется следующими технологиями:

• eXtensible Markup Language (XML);
• Simple Object Access Protocol (SOAP);
• Universal Description, Discovery and Integration (UDDI);
• Web Services Description Language (WSDL).

Рис. 2: Взаимодействие между компонентами сервисно-ориентированной архитектуры

Различают следующие  три основных архитектурных компонента сервисно-ориентированной архитектуры:

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

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

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

В ходе взаимодействия друг с другом компоненты сервисно-ориентированной архитектуры выполняют следующие основные операции:

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

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

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

Свойства веб-сервисов

Чтобы архитектура стала ориентированной на сервисы, сами сервисы должны удовлетворять следующим критериям.

Сервисы слабо  связаны с бизнесом и между  собой. В контексте автоматизации мера связанности отражает зависимость в отношениях между предметом автоматизации и поддерживающей автоматизируемые процессы логикой. В жестко связанных простых технических системах автоматизации эта связь является абсолютной; так было с первого регулятора Уатта и до современных технических систем. В конечном итоге степень связанности определяется природой автоматизируемого объекта: чем он проще, тем проще регулятор. Бизнес с системной точки зрения сложен, его можно представить в виде сервисов и автоматизировать посредством отдельных сервисов, отношения с которыми выстраиваются на основе определенных контрактов. Архитектура бизнеса нестабильна, он подвержен непрерывному потоку событий. Поэтому полноценным средством для его автоматизации может быть архитектура, управляемая или «движимая событиями» (Event Driven Architecture, EDA), а полноценно реализовать EDA можно только с использованием SOA. Смежный смысл словосочетания loose coupling относится к определению отношений между системными компонентами. Сегодня этот термин широко используется в лексиконе ИТ-специалистов. В то же время нет ничего удивительного в том, что впервые термин loose coupling предложил известный специалист по менеджменту Карл Вейк в статье «Управление изменениями в среде слабо связанных элементов» (The Management of Change Among Loosely Coupled Elements) в 1982 году. На примере этого качества сервисов мы видим, насколько сервисная идея близка и ИТ, и бизнесу.

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

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

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

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

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

Сервисы являются самоуправляемыми. Для того чтобы сервисы могли существовать независимо друг от друга и от среды обитания, они должны быть автономными, то есть обладать свойствами самоуправления. Под «автономностью» понимается способность сервиса выполнить условия контракта самостоятельно, без внешнего управления. Абсолютная автономия предполагает полное распоряжение ресурсами; она не всегда возможна, особенно если приходится создавать сервисы, взаимодействующие с унаследованными приложениями. Полная автономность является условием для многократного использования, но это не единственное условие; не меньшее значение имеет отсутствие собственного состояния.

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

Сервисы должны быть обнаруживаемыми. Это свойство сервисов в массовом порядке — пожалуй, даже чрезмерно — обсуждалось, начиная с первых шагов SOA наряду с протоколами SOAP, UDDI, WSDL. Суть его в том, что приложение, ориентированное на сервисы, не должно быть перегружено реестрами сервисов, механизмами их обнаружения. Для этой цели должна быть предусмотрена специальная поддержка, а приложение должно быть сосредоточено на собственном функционале. Условия, зафиксированные в предложении для контракта, должны позволять потенциальному клиенту найти нужный ему сервис и подключить его вручную или автоматически.

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

WS-I Basic Profile 1.0

В заключение следует  сказать, что с целью выработки  и популяризации стандартов, описывающих  взаимодействие веб-сервисов в рамках сервисно-ориентированной архитектуры, создано международное объединение около 150 ведущих компаний, называющееся WS-I (Web Services Interoperability Organization). Важным результатом работы данного объединения стало создание и утверждение в 2003 году так называемого WS-I Basic Profile 1.0 - пакета базовых спецификаций веб-сервисов, взаимоувязанных с целью обеспечения широких возможностей взаимодействия веб-сервисов. В настоящее время в данный профиль входят следующие спецификации технологий:

• SOAP 1.1;
• WSDL 1.1;
• UDDI 2.0;
• XML 1.0;
• XML Schema Part 1: Structures;
• XML Schema Part 2: Datatypes;
• RFC2246: The Transport Layer Security Protocol 1.0;
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile;
• RFC2616: HyperText Transfer Protocol 1.1;
• RFC2818: HTTP over TLS;
• RFC2965: HTTP State Management Mechanism;
• Secure Sockets Layer Protocol 3.0.