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

 

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

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

в) Отказоустойчивость и способность к восстановлению после ошибок. Необходимо тщательное проектирование систем во избежание зависимости работоспособности системы от ее отдельных компонентов.  Еще важнее для систем  уметь восстанавливаться после сбоев. Уровни этого восстановления могут быть различными. Так, обычно, данные одного сеанса работы считается возможным не восстанавливать, поскольку такие данные часто малозначимы или легко восстанавливаются, но так называемые постоянно хранимые (persistent) данные обычно требуется восстанавливать до последнего непротиворечивого их состояния.

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

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

 

Таблица 1 -  Анализ систем, построенных на основе различных архитектур

	Монолитные системы	Компонентные системы	Системы, разработанные  на базе SOA
Автоматизация разработки программного обеспечения	- существует возможность моделирования монолитных приложений на языке UML; - генерация кода на основе  моделей UML; - при изменении монолитного   приложения генерация кода практически  не используется из-за жестких  связей внутри приложения. Замена  одного участка кода, может повлечь  за собой замену других. Сгенерированный  код представляет собой каркас и требует дальнейшей доработки. Таким образом, изменение приложения с помощью генерации кода влечет за собой двойные трудозатраты.	- генерация  кода на основе IDL (для CORBA); - генерация  кода на основе моделей UML; - использование генерации кода при изменении отдельных компонентов системы;	- трансформация моделей различного  уровня (высокоуровневые модели  бизнес-процессов и требований, модели  UML, сервисные модели ); - генерация программного кода  для конкретных платформ на  основе моделей UML; -  применение промышленного  стандарта разработки, управляемой  моделями (MDD, Model Driven development);
Открытость и повторное использование	- понятие повторного использования  не применимо к монолитному  приложению, за исключением лишь  повторного использования кода внутри самого приложения; - монолитные приложения отвечают  требованиям открытости, т.к. они  могут работать с открытыми  стандартами и протоколами;	- возможность быстро и эффективно  создавать многофункциональные  приложения, используя уже существующие компоненты, что заметно снижает стоимость построения новой системы; - в то время, когда создавались  технологии DСОМ и CORBA, стандарта для совместного использования структурированных данных не существовало. И лишь позднее появились такие стандарты, как SGML, XML и SOAP, предназначенные непосредственно для представления типов данных.	- повторное использование моделей,  путем их трансформации и доработки; - строго стандартизованные интерфейсы  и контракты сервисов, обеспечивают  их открытость и повторное использование;
Масштабируемость	- повышение производительности  монолитного приложение достигается  за счет постоянного увеличения  аппаратных мощностей. С постоянным  ростом пользователей и требований  к функционалу, монолитные системы  перестают оправдывать вложение в свое развитие;	- стандарт DСОМ тесно связан с платформой Windows. Не существует простого способа создать и разместить СОМ-компонент в другой операционной системе, такой как UNIX; - модель CORBA сложно использовать  в языках, отличных от Java; - с помощью DСОМ и CORBA можно спроектировать компоненты, способные взаимодействовать с сотнями клиентов так же легко, как и с десятками. Однако это требует от программистов огромного опыта. Выгода от использования такого компонента, может не оправдать время и денежные затраты на его разработку [4];	- высокая масштабируемость системы.  Поскольку в SOA сервисы являются  слабо-связанными, то приложения, которые  используют эти сервисы, имеют  тенденцию к более легкому  масштабированию, чем в среде  с более жесткими связями. Вызов сервисов в различной последовательности обеспечивает выполнение различных процессов. - для увеличения производительности  системы, достаточно развернуть сервис на другом  физическом сервере;
Разработка с перспективой интеграции	- Достаточно низкий уровень  интеграции. Только использование  открытых стандартов может обеспечить  интеграцию в монолитном приложении, при условии, если интегрируемая  с ним система разработана  с использование  того же  стандарта;	- DCOM применим лишь в качестве решения для систем, ориентированных исключительно на продукты Microsoft; - высокая способность систем  на основе CORBA к интеграции за счет платформенной независимости CORBA[5]; - брокеры объектных запросов ORB (Object Request Broker), являющиеся посредниками, промежуточными звеньями системы и скрывающие в себе всю сложную логику взаимодействия клиентского приложения с серверными объектами от различных производителей,  оказались не совместимыми (или не полностью совместимыми), что не позволило строить на основе CORBA распределенные системы, действительно независимые от платформы и поставщика программного обеспечения для промежуточного слоя[6].	- высокий уровень интеграции  за счет использования открытых  международных стандартов; - сервис функционирует по принципу черного ящика и имеет интерфейс со строго определенными входами и выходами. Это обеспечивает высокий уровень интеграции; - возможность интеграции унаследованных  систем; - использование корпоративной  интеграционной шины (ESB);
Связность приложений	- приложение реализуется как  монолит, в нем отсутствуют  компоненты, требующие связности;	- жесткое связывание (tight coupling). Для связи взаимодействующих компонентов вырабатывается некий специальный формат данных, а возможно даже, и протокол связи; на обеих сторонах создаются программы, умеющие этот формат обрабатывать. Подключение новых компонентов к такой системе требует больших финансовых и временных затрат[6].	- слабо-связанные сервисы являются  более гибкими, чем жестко связанные  системы. При архитектуре с жесткой связью различные компоненты приложения привязаны друг к другу общей семантикой, библиотеками и т.д. Слабосвязанная, асинхронная сущность сервисов в сервисно-ориентированной архитектуре позволяет приложениям быть гибкими и легко меняться в соответствии с меняющимися требованиями бизнеса.
Безопасность	- монолитное приложение обеспечивает  высокий уровень безопасности;	- для решения задач безопасности  в CORBA разработан специальный  "Сервис безопасности" (CORBA Security Service)[7], который позволяет обеспечить в распределенных средах безопасность уровня , близкого к высшему уровню защиты, используемому в государственных учреждениях[8]; - DCOM использует framework повышенной безопасности, предлагаемый Windows NT. Windows NT предусматривает  набор встроенных провайдеров безопасности, поддерживающий многочисленные механизмы идентификации и аутентификации, от традиционных моделей доменов доверия (trusted-domain) до нецентрализованно управляемых, хорошо масштабируемых механизмов безопасности[9].	- безопасность в SOA-архитектуре  описывается довольно большим  набором спецификаций. Данный набор  является неотъемлемой частью  пула стандартов SOA и разрабатывается  одновременно с ним, поэтому  приложения в составе сервисной  архитектуры могут создаваться  безопасными уже на стадии проектирования. - базовые стандарты (SOAP Foundation) включают  в себя спецификации XML Signature и  XML Encryption, которые определяют соответственно  форматы ЭЦП и шифрования SOAP-транзакций; - WS-Security определяет базовые механизмы и форматы использования security-token в составе SOAP-запросов. Основной целью WS-Security является абстрагирование реализации политик безопасности Web-сервисов от конкретных методов (например, протоколов аутентификации и авторизации). - WS-Policy определяет шаблоны и правила описания политики бeзопасности для Web-сервисов. - WS-Trust описывает правила организации  доверенных отношений между участниками  Web-взаимодействия. - WS-Privacy определяет форматы политики  конфиденциальности при обмене SOAP-сообщениями. - WS-SecureConversation регламентирует правила  безопасного обмена сообщениями  в SOA-архитектуре. - WS-Federation является спецификацией,  определяющей установление доверенных  отношений между различными доменами  безопасности. - WS-Authorization описывает форматы описания правил разграничения доступа к Web-сервисам[10].
Соответствие быстроменяющимся требованиям  бизнеса	- при использовании монолитных  систем бизнес находится в  жестких рамках, созданных предоставляемой  функциональностью монолитного  приложения. В таком случае бизнес подстраивает свои процессы под возможности программного продукта, в определенный  момент программный продукт полностью перестает удовлетворять требованиям бизнеса.	- компонентные системы направлены  на поддержку меняющимся условиям бизнеса. Это должно обеспечиваться высоким уровнем интеграции. Но, как отмечено выше, реализации от различных поставщиков оказываются трудно совместимыми, что влечет за собой высокие затраты, а также увеличивает время изменения системы, когда для бизнеса время изменения системы является критическим параметром.	- SOA решение соответствует быстроменяющимся требованиям бизнеса за счет повторного использования, использования открытых стандартов, высокой интеграционной способности. Все это позволяет быстро перестраивать существующие системы, а также внедрять новые сервисы.

 

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

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

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

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

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

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

Резюмируя вышесказанное, можно отметить следующие преимущества от внедрения SOA-решения в страховой компании[11]:

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

1.2 Выбор инструментальных средств проектирования и разработки

1.2.1 Обоснование выбора средств моделирования бизнес процессов

 

Моделирование бизнес-процесса является одним из этапов жизненного цикла SOA. В концепции SOA модели бизнес-процессов строятся в нотации BPMN (Business Process Modeling Notation) - спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах, называемых BPD (Business Process Diagram, что дословно переводится как "диаграмма бизнес-процессов"). Модели, построенные с использованием спецификации BPMN, можно трансформировать в BPEL, который на языке XML формально описывает бизнес-процессы и протоколы их взаимодействия между собой и который активно используется в области интеграции и SOA.

Спецификация  BPMN разработана  организацией Business Process Management Initiative (BPMI) в 2001-2004 годах с учётом множества  ранее существовавших диаграмм (таких  как диаграммы стандарта IDEF0, IDEF3, DFD (Data Flow Diagramming). Процессы, описанные в нотации BPMN легко воспринимаются пользователями: от бизнес-аналитика, создающего первые наброски описаний процессов, к техническим специалистам, отвечающим за реализацию этих процессов в Системе, и, наконец, до людей бизнеса, которые управляют этими процессами и контролируют их работу.

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

• Бизнес-инженер (БИТЕК),
• ИНТАЛЕВ: Корпоративный навигатор (ИНТАЛЕВ),
• ОРГ-Мастер Про (Бизнес Инжиниринг Групп).

Из наиболее популярных зарубежных программных продуктов  необходимо отметить:

• ARIS Business Performance Edition (IDS Scheer AG),
• CA ERWin Process Modeler, ранее BPWin (CA),
• Hyperion Performance Scorecard (Oracle),
• IBM WebSphere Business Modeler (IBM),
• SAP Strategic Enterprise Management (SAP).

Только два продукта позволяют описать бизнес-процессы в нотации BPMN. Это продукты ARIS Business Performance Edition (IDS Scheer AG) и IBM WebSphere Business Modeler (IBM).

В таблице 2 представлена сравнительная характеристика двух указанных продуктов. Продукты рассматривается в следующих направлениях[12]:

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

 

 

 

 

 

Таблица 2 - Сравнение ПО для моделирования бизнеса

	Возможность	IBM WEBSPHERE BUSINESS MODELER	ARIS BUSINESS PERFORMANCE EDITION
Моделируемые  предметные области
1	Процессное управление	Да	Да
Способы представления  данных
2	Справочники	Да	Да
3	Проекции (механизм установки взаимосвязи  между данными справочников в отношении «многие ко многим»)	Да	Да
4	Диаграммы, в том числе, диаграммы  нотации:	Да	Да
5	Basic Flowchart	Нет	Да
6	Cross Functional Flowchart	Нет	Да
7	EPC (Event-Driven Process Chain)	Нет	Да
8	Организационная диаграмма	Да	Да
9	BPMN	Да	Да
Возможности получения регламентной отчетности
10	Возможность разработки регламентных отчетов.	Да	Да
11	Параметризация отчетов	Да	Да
12	Создание набора шаблонов отчетов  для любого справочника	Да	Да
13	Экспорт отчетов во внешние файлы	MS Word, PDF , XML, в другие  отчеты системы	MS Word, MS Excel, TXT, HTML, PDF, XML, в другие отчеты системы
Возможности анализа бизнес-процессов
14	Имитационное моделирование бизнес-процессов	Да	Да
15	Стоимостной анализ	Да	Да
16	Анализ загрузки ресурсов при выполнении процессов	Да	Да
17	Расчет среднего времени выполнения процессов	Да	Нет
Инфраструктура
18	Наличие GUI — интерфейса	Да	Да
19	Наличие web-интерфейса	Да	Да
20	Поиск по данным моделей	Да	Да
21	Требования к наличию сторонних программных продуктов	Нет	MS Office# Базы данных Oracle и/или SQL
22	Настройка доступа к объектам модели	Да	Да

 

Для выполнения бизнес моделирования  была выбрана спецификация BPMN и программный продукт IBM WebSphere Business Modeler (далее WBM), реализующий данную спецификацию.

Выбор был сделан в пользу упомянутого  продукта исходя из ряда условий. Во-первых, стояла задача построения бизнес-процессов  «как есть» и «как должно быть», анализа  этих процессов. То есть, необходимо было сконцентрироваться именно на протекающих процессах в компании. Необходимо было проанализировать ресурсы, используемые в процессе, стоимость и продолжительность процессов, выполняемых в различных условиях и с различными входными данными. Продукт WBM позволяет получить требуемые данные. Продукт Aris безусловно предоставляет мощный инструментарий для моделирования процессов, но не дает возможности исследовать среднее время выполнения процессов.  Во-вторых, наличие лицензии. IBM WBM доступен нашему ВУЗу в полном объёме по академической лицензии, в то время как продукт ARIS BUSINESS PERFORMANCE EDITION доступен в ограниченной версии, не позволяющей в полной мере исследовать процессы.

1.2.2 Обоснование выбора CASE средств проектирования

 

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

• IBM Rational Software Architect (IBM RSA) – обеспечивает интегрированную поддержку проектирования и разработки ПО с использованием моделей на основе UML;
• IBM Rational Data Architect (IBM RDA) – средство моделирования и разработки баз данных.

Альтернативными вариантами являются ERWin, использующийся для моделирования баз данных, и IBM Rational Rose, использующийся для визуального моделирования систем на языке UML.

Так как в дипломном  проекте используется метод разработки управляемой моделями, в состав которого входят такие понятие как трансформации, выбор был сделан в пользу  IBM RSA и IBM RDA. Выбранные средства проектирования имеют тесную интеграцию между собой и поддерживают процедуру трансформаций. ERWin в отличие от IBM RDA не имеет интеграции с IBM RSA. IBM Rational Rose дает возможность построить только лишь UML модели системы, в то время как IBM RDA позволяет получать сервисные модели, в том числе с помощью процедуры трансформации.

1.2.3 Обоснование выбора СУБД

 

Применяя метод разработки управляемой моделями, построить  решение можно практически на любой СУБД.  В данном проекте  в качестве СУБД была выбрана IBM DB2 Express-C версии 8.2. В таблице 3 представлено сравнение с такими системами как SQL Server 2005 Express и Oracle 10g Express Edition.

Таблица 3 - Сравнение  СУБД

Характеристика	IBM DB2 Express-C	SQL Server 2005 Express	Oracle 10g Express Edition
Процессор	В пределах одного процессора (поддержка двухядерного процессора)	В пределах одного процессора	В пределах одного процессора
Оперативная память	2 Гб	1 Гб	1 Гб
Ограничение на размер базы данных	Нет ограничений	4 Гб	4 Гб
Поддержка 32/64 битных систем	32/64 bit	32 bit	32 bit