Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Виртуализация сервиса(Service Mediation).

Разделение сервиса происходит с помощью механизма виртуализации. Виртуальный

сервис является прокси-объектом для реального сервиса. Прокси-сервис представляет

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

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

 

29. Типовые функции виртуального сервиса.

Типовые функции виртуального сервиса

Виртуальный сервис – наилучшее место реализации некоторых технических условий

или обеспечения качества сервиса (QualityOfService):

1. Проверка XML сообщений на корректность формата и соответствие интерфейсу сервиса.

2. Аутентификация и авторизация: идентификация потребителя сервиса и проверканаличия у него прав для вызова сервиса.

3. Расшифровка сообщений и проверка подписи.

4. Балансировка нагрузки и гарантии наличия ресурсов для работы сервиса.

5. Маршрутизация сообщений. Передача сообщений различным реализациям сервиса в зависимости от содержимого сообщений или внешних условий.

6. Мониторинг работы сервиса, производительности, а также проверка предоставления поставщикам требуемых услуг (SLA).

 

30. Роль технологии XML в SOA. Стандарты, основанные на XML и используемые в SOA.

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

XML является фундаментом практически всех стандартов Web-сервисов, в том числе XML Schema, SOAP, WSDL (Web Services Description Language) и UDDI (Universal Description, Discovery, and Integration). Эти стандарты опираются на основополагающую концепцию основанных на XML представлений - поддерживаемый во всем мире формат обмена информацией между провайдерами сервисов и инициаторами запросов в SOA.

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

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

 

Примеры стандартов, основанных на XML и используемых в SOA:

SOAP. Этот простой основанный на XML протокол позволяет приложениям обмениваться информацией по транспортным протоколам, таким как HTTP. Благодаря использованию XML протокол SOAP является:

Платформенно-независимым.

Пригодным для использования в Интернете.

Читабельным, структурированным и текстовым.

 

Благодаря всем этим преимуществам SOAP является рекомендованным и самым широко используемым коммуникационным протоколом для Web-сервисов. А так как Web-сервисы являются краеугольным камнем архитектуры SOA, этот протокол является также основным коммуникационным протоколом для основанных на SOA решениях.

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

Сервисы, доступные через интерфейс Web-сервиса, такие как список имен методов и сообщений-атрибутов.

Тип данных сообщений.

Информация о связывании для транспортного протокола, такого как HTTP и JMS.

Адрес сервиса, используемый для его вызова.

Electronic Business using eXtensible Markup Language (ebXML). Язык ebXML является стандартным способом определения бизнес-транзакций, которые могут выполняться между различными бизнес-субъектами. ebXML определяет стандартные методы для обмена сообщениями, устанавливая торговые связи и регистрируя бизнес-процессы между компаниями.

 

31. Реестры сервисов, их роль.

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

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

Реестр сервисов является хорошо масштабируемым; он развивается в соответствии с развитием системы, которую обслуживает.

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

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

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

Реестры сервисов помогают уменьшить время, затрачиваемое на обнаружение информации о сервисе.

Без реестра, следящего за сервисами и их взаимоотношениями, SOA-среда не только утрачивает согласованность и контроль, но и приходит в состояние хаоса.

 

32. Понятие бизнес-процесса, элементы бизнес-процесса.

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

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

 

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

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

 

Элементы бизнес-процесса

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

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

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

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

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

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

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

 

33. Базовый сценарий для использования архитектуры SOA. Каталог сервисов, потребитель сервисов, провайдеры сервисов.

Базовая архитектура SOA состоит из провайдера сервисов, сервиса и (необязательного) каталога сервисов. Для обмена информацией используется механизм обмена сообщениями типа "приложение к приложению". Сходство между этой моделью и чистыми web-сервисами совершенно очевидно, поскольку в обоих случаях применяется WSDL-документ, являющийся контрактом по активизации, хранящимся в каталоге сервисов, из которого этот сервис может быть запрошен и извлечен посредством механизма UDDI. web-сервисы в действительности являются реализацией архитектуры SOA на самом базовом уровне. В этой модели базовый сценарий таков. Сначала провайдер сервиса создает сервис, принимает решение открыть этот сервис и публикует его. Публикация выполняется путем отправки информации о сервисе в каталог сервисов. С другой стороны, инициатор запросов сервиса (service requester), нуждаясь в определенном сервисе, просматривает каталог сервисов в поисках того из них, который удовлетворяет необходимому критерию. После обнаружения такого сервиса и использования доступной в каталоге сервисов информации инициатор запросов сервиса может напрямую обратиться к провайдеру сервисов надлежащим способом для удовлетворения бизнес-потребности.

Ниже приведены определения некоторых понятий, используемых в данном разделе:

 Провайдер сервиса. Предоставляет сервисы, контракт по активизации которых и

месторасположение опубликованы.

 Потребитель сервиса. Потребляет сервисы, соответствующие его бизнес-потребностям и обнаруженные в каталоге сервисов.

 Каталог сервисов. Служит для публикации и ведения списка сервисов, доступных

для потребителей.

 

34. Документ описания требований к ИС. Основные части.

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

36. Язык моделирования UML. Характеристика, основные направления использования.

 

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

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

 

37. Понятие класса в ООП, члены класса, наследование классов, иерархия классов. Создание диаграммы классов.

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

Член класса – это именно полей (свойств) и методов/функций/процедур.

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

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

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

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

Последнее изменение этой страницы: 2016-08-29

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...