О.А. Морозова ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ...

Москва 2014

Федеральное государственное образовательное бюджетное учреждение высшего профессионального образования

«ФИНАНСОВЫЙ УНИВЕРСИТЕТПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»

Кафедра бизнес-информатики

О.А. Морозова

ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Учебное пособие

УДК004(075.8)ББК 32.973я73 М80

Рецензенты:докторэкономическихнаук,профессор,

деканфакультетаэкономикиименеджментаЕ.Д. Коршунова(Московскийгосударственныйтехнологическийуниверситет«СТАНКИН»);

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

Морозова О.А. Интеграциякорпоративныхинформационныхсистем: М80 учебноепособие.—М.:Финансовыйуниверситет,2014.—140с.

ISBN978-5-7942-1135-1

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

Длястудентоввысшихучебныхзаведений,обучающихсяпонаправлениямподготовки080700.68«Бизнес-информатика»и230700.68«Прикладнаяин-форматика»,квалификация(степень)«магистр».

УДК004(075.8)ББК32.973я73

ISBN978-5-7942-1135-1 ©О.А.Морозова,2014 ©Финансовыйуниверситет,2014

Moscow 2014

Federal State-Funded Education Institution of Higher Professional Education

«FINANCIAL UNIVERSITY UNDER THE GOVERNMENT OF THE RUSSIIFN FEDERATION»

Department of Business Informatics

О.А. Morozova

ENTERPRISE INFORMATION SYSTEMS INTEGRATION

Manual

Reviewers: Korshunova E.D., PhD,Professor,HeadoftheFaculty«Economics

andManagement»,MoscowStateUniversityofTechnology«STANKIN»;Rubalsky G.B.,PhD,Professor,DepartmentofComputerScience

andProgramming,FinancialUniversityundertheGovernmentoftheRussianFederation

Morozova O.A. EnterpriseInformationSystemsIntegration:manual.—М.:FinancialUniversity,2014.—140p.

ISBN978-5-7942-1135-1

Modernapproachesofintegrationdecisionsimplementationareconsidered.Strategicvalueoflegacysystemsintegrationforbusinesstransformationisshown.Classificationofintegrationtasksiscarriedout,criteriaofintegrationdecisionchoiceareformulated.Containsthereviewofbasictechnologiesandthestandardsusedatdevelopmentofintegrationdecisions.Questionsofdesignofintegrationdecisionsareconsideredwithuseoflanguageofthetemplatescoveringallaspectsofinteraction.

Themanualcanberecommendedtostudentsofthehighereducationalinstitutionswhicharetraininginthedirectionsofpreparationofmastersof080700.68«Businessinformatics»and230700.68«Appliedinformatics».

ISBN978-5-7942-1135-1 ©О.А.Моrоzоvа,2014 ©FinancialUniversity,2014

Введение

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

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

Во-первых,повсеместноеиспользованиеинформационныхтех-нологийприводитклавинообразномуростуобъемовцифровойинформации.ПооценкамкомпанииIDC[5],ежегоднообъемданныхувеличиваетсяболеечемна60%.Этаинформацияраспределенапомногочисленнымгетерогеннымприложениям,системам,настоль-нымбазамданныхимобильнымустройствам.Дляэффективногоис-пользованияраспределенныхданныхдолжныбытьрешеныпроблемысбора,синхронизацииииспользованиярелевантнойинформациивмасштабахпредприятия.Речь,преждевсего,идетобобеспечении

6

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

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

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

Интеграционныепроектыдостаточнодорогостоящи.ПоподсчетамкомпанииGartnerGroup,80%ИТ-бюджетовкомпанийсоставляютрасходынасопровождениесистем,изних35%—затратынаин-теграциюприложений,60%стоимостивнедрениякорпоративнойинформационнойсистемысоставляютрасходынаинтеграцию.

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

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

Данноеучебноепособиекакразипосвященовопросаминтеграциикорпоративныхинформационныхсистем.

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

7

Вовторой главепроводитсяобзортехнологийистандартов,ис-пользуемыхприразработкеинтеграционныхрешений;даетсяопре-делениепромежуточнойсредыирассматриваютсябазовыемоделивзаимодействияудаленныхкомпонентов;проводитсясравнительныйанализстандартовобъектно-ориентированноговзаимодействия.Большоевниманиеуделенотехнологияминтеграции,базирующим-сянаXML,втомчислетехнологиямWeb-сервисов.Приводитсякраткий,проиллюстрированныйпримерами,обзорспецификацийXML,DTD,XML-Schema,XSLT,WSDL,WS-BPEL,WS-CDL.

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

Глава 1Интеграция корпоративных

информационных систем как средство развития бизнеса

1.1. Эволюция подходов к интеграции информационных систем

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

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

9

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

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

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

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

� вкомпанияхвсегдаостаетсянесколько«устаревших»приложе-ний,заменакоторыхмодулямикомплекснойсистемыможетзанятьмноговремени.Навремя«переходного»периодатакиеприложениядолжныбытьинтегрированы;

� слиянияипоглощениякомпанийявляютсяисточникоминтег-рационныхпроблем:частовкомпанияхиспользуютсяERP-системыотразличныхпоставщиков,вбанках—АБСотразныхпроизводи-телей;

� существуетпроблемавзаимодействиясвнешнимиконтраген-тамикомпании;

10

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

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

Рис. 1.1. Неупорядоченная ИТ-инфраструктура

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

ПринятопротивопоставлятьдвакрайнихподходакразвитиюИТ-инфраструктурыпредприятия—этомульти-имоновендорнаястратегии[32].Итаидругаястратегияимеетсвоидостоинстваинедостатки.

11

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

Мультивендорная стратегияосновананаподходе«best-of-bread»(лучшеговсвоемклассе)итребуетзначительнобóльшихзатратнавстраиваниеинородныхприложенийвсложившуюсяархитектуру.

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

1)уровнемпредставления(уровеньпользователя,решающегозадачиввода/выводаинформации);

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

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

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

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

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

12

Принципработы системmiddlewareпервогопоколенияиллюст-рируетрис.1.2.

Рис. 1.2. Принцип работы систем middleware первого поколения

Такая«одномерная»модельвзаимодействияприложенийсовре-менемустарела,инасменуейпришлатехнология,основаннаянаархитектуреESB(EnterpriseServiceBus),котораяобеспечи-ваетуправляемоевзаимодействиемеждувсемиприложениями,подключеннымикобщейшинепредприятия.

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

Основнымикомпонентамитакихсистемявляются:� интеграционный брокер,играющийрольсервиснойшины(вы-

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

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

Принципработысовременныхсистемmiddlewareиллюстрируетрис.1.3.

Обзорсовременныхпрограммныхпродуктовклассаmiddlewareбудетпроведенвовторойглаве.

13

Рис. 1.3. Принцип работы современных систем middleware

1.2. Методология открытых систем и проблема интеграции

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

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

14

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

�СовместнымтехническимкомитетомИСОиМЭК(ISO/IEC/JTC1)—ИСО/МЭК/СТК1«Информационныетехнологии»;

� Европейскойрабочейгруппойпооткрытымсистемам(EWOS);�НациональныминститутомстандартовитехнологийСША(NIST).

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

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

Основныминефункциональнымитребованиямикоткрытымси-стемамявляются:

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

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

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

Методологиюоткрытыхсистемопределяютследующиедокументы:� ТехническийотчетISO/IECTR10000Frameworkandtaxonomy

ofInternationalStandardizedProfiles(Основыитаксономиямежду-народныхстандартизованныхпрофилей);

�Эталонная модель окружения (среды) открытых систем(RM OSE) — ISO/IEC DTR 14252, Portable Operating System

15

InterfaceforComputerEnvironments—POSIX(IEEE,P1003.0,DraftGuidetothePOSIXOpenSystemEnvironment);

�Эталоннаямодельвзаимосвязиоткрытыхсистем(RMOSI)—ISO7498:1996, Informationprocessing systems—OpenSystemsInterconnection—BasicReferenceModel(ITU-TRec.X.200).

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

Выделяютдвегруппыстандартов:1)стандартыприкладныхпрограммныхинтерфейсов(Application

ProgramInterface(API)Standards),которыеопределяютвзаимо-действиеприкладногопрограммногообеспеченияскомпьютернойсистемой(прикладнойплатформой)ипредназначенывосновномдляобеспеченияпереносимостиприложений;

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

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

Интерфейсывзаимодействиякомпонентовсистемиллюстрируетрис.1.4.

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

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

Рис. 1.4. Интерфейсы взаимодействия компонентов

систем

16

1.3. Цели и задачи интеграции

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

� ведениебизнесаврежимереальноговременисиспользованиемсобытийно-управляемыхсценариев;

� владениедостоверной,полнойисвоевременнополученнойин-формацией.

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

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

Основнымидвижущимисиламиинтеграцииявляются:� электронныйбизнес—интеграцияунаследованныхинформа-

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

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

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

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

� электронноеправительство—интеграцияунаследованныхback-endсистемсfront-endWeb-приложениями,организацияобменаданнымимеждуправительственнымиучреждениями;

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

17

обслуживающегоперсонала,требуетинтеграциипользовательскихприложенийсback-end-системами;

� BusinessIntellegence—сборданныхизразличныхприложенийиисточниковвхранилищеданныхсцельюихобработкиианализа;

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

� облачныетехнологии—интеграциясуществующихбизнес-при-ложенийсоблачнымиприложениямиисервисами;

� аутсорсингбизнес-процессов—интеграциясинформационнымисистемамипартнеров.

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

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

1.4. Типы интеграционных решений: горизонтальная и вертикальная интеграция

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

� интеграциюкорпоративныхприложенийвпределахпредприятия(Application-to-ApplicationIntegration—A2A)—автоматическийсобытийно-управляемыйобменинформациеймеждуприложениямиисистемами,действующиминапредприятиииливорганизации;

� интеграциюприложениймеждупредприятиями(Business-to-BusinessApplicationIntegration—B2B)—автоматическийсобы-

18

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

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

Вданномконтекстесуществуетдвавариантапостроенияинтег-рационногорешения:

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

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

Типичнымпримеромгоризонтальной интеграцииявляетсяавто-матизацияуправленияцепямипоставок(различныеприложенияиликомпонентыобеспечиваютполныйцикллогистическихопе-раций)[12].

Нарис.1.5показанраспределенныйбизнес-процесс,поддержи-ваемыйнесколькимиприложениями.

Рис. 1.5. Пример горизонтальной интеграции

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

19

ворганизации.Процесс4выходитзапределыорганизацииивоз-вращаетсявнеепередзавершением.

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

Вхранилищеданныхконсо-лидируетсяоперативнаябизнес-информацияизразличныхавтоматизированныхмодулей,установ-ленныхвофисахифилиалахпредприятия,включаятерриториальноудаленныеподразделения.Данныепоступаютвхранилищеизразнооб-разныхтранзакционныхсистем,тоестьизсистем,ориентированныхнауправлениеотдельнымиоперациями(например,системклассаCRMилиERP),разрозненныхбазданных,электронныхтаблицидругихисточников.Информация,накопленнаявхранилищедан-ных,используетсяприложениями,обеспечивающимитехнологиибизнес-планирования,управленческогоучетаистратегическогопрогнозирования.АнализданныхвыполняетсясиспользованиемразличныхBI-инструментов(OLAP,Datamining).

1.5. Проблемы интеграции

Интеграцияприложений—сложнаязадача.Можновыделитьнесколькогрупппроблем,скоторымисталкиваютсяразработчикиинтеграционныхрешений[33]:

1)технические проблемы:� рискзадержкиипотериинформации,вызванныйненадежно-

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

Рис. 1.6. Пример вертикальной интеграции

20

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

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

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

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

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

2)методологические проблемы:� отсутствиекорректногоформатаилисемантическогослоядля

слияниядвухиболеенесопоставимыхнаборовданных.Устранениесемантическихразличиймеждуприложениями—однаизнаиболеесложныхинеформализуемыхзадачинтеграции.Действительно,однаитажесущность(например,«Клиент»)можетиметьнесколькоразличныхсемантик,ограниченийидопущенийвкаждойсистеме.Этапроблемаванглоязычнойлитературеполучиланазваниесе-мантического диссонанса;

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

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

3)организационные проблемы:� недостатокдоверияккорректностиинформации;� интеграцияприложенийвбольшинствеслучаеввлечетзасо-

бойпересмотркорпоративнойполитикикомпании.Объединение

21

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

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

1.6. Критерии выбора интеграционного решения

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

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

Нижеперечисленыосновныекритерии,влияющиенавыборспо-собаинтеграцииприложений:

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

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

22

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

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

Глава 2Технологии и стандарты интеграции

2.1. Понятие промежуточной среды

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

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

МодельOSI/ISOразделяетпроцессвзаимодействиядвухстороннасемьвзаимосвязанныхуровнейиопределяетфункциикаждогоизних.Каждыйуровеньподдерживаетинтерфейсысвыше-ини-жележащимиуровнями(табл.2.1).

Впростейшемслучаевзаимодействиемеждудвумяудаленны-миприложениямиможнообеспечитьсиспользованиемпрото-колаTCP/IP.Интерфейсктранспортномууровнюобеспечива-етоперационнаясистема,предоставляямеханизм,основанныйнасокетах1.

1Сокет—этопрограммныйинтерфейсдляобеспеченияобменаданнымимеждупроцессами;абстрактныйобъект,представляющийконечнуюточкусоединения.

24

Табл

иц

а 2

.1У

ро

вни

мо

дел

и O

SI/

ISO

и и

х ха

рак

тер

ист

ики

№

Наз

вани

еФ

ункц

ииП

рим

ер п

рото

кола

Реа

лиза

ция

1Ф

изич

ески

йП

еред

ача

бито

в по

физ

ичес

ким

лин

иям

свя

зи. О

пред

еляе

т мех

анич

е -ск

ие, э

лект

риче

ские

и о

птич

ески

е ха

ракт

ерис

тики

кабе

лей

и ра

зъем

ов

физ

ичес

кого

инт

ерф

ейса

сет

и

Спе

циф

икац

ия 1

0Bas

e-T

Кана

л св

язи

2Ка

наль

ный

Обе

спеч

ивае

т вз

аим

одей

стви

е м

ежду

дву

мя

ком

пью

тера

ми.

Фун

к -ци

и —

про

верк

а до

ступ

ност

и ср

еды

пер

едач

и, р

еали

заци

я м

еха-

низм

ов о

бнар

ужен

ия и

кор

рекц

ии о

шиб

ок. В

про

токо

лах

кана

льно

го

уров

ня, и

спол

ьзуе

мы

х в

лока

льны

х се

тях,

зал

ожен

ы о

пред

елен

ная

стру

ктур

а св

язей

меж

ду к

омпь

юте

рам

и и

спос

обы

их

адре

саци

и

Ethe

rnet

, Tok

en R

ing,

FD

DI,

100V

G-A

nyLA

N

Опе

раци

он-

ная

сист

ема

3С

етев

ойРе

ализ

ует

взаи

мод

ейст

вие

узло

в се

ти. Э

тот

уров

ень

служ

ит д

ля

обра

зова

ния

един

ой т

ранс

порт

ной

сист

емы

, объ

един

яющ

ей н

е-ск

ольк

о се

тей

с ра

злич

ным

и пр

инци

пам

и пе

реда

чи и

нфор

мац

ии

меж

ду к

онеч

ным

и уз

лам

и

Про

токо

л м

ежсе

тево

го в

заим

о -де

йств

ия IP

сте

ка T

CP/

IP и

про

-то

кол

меж

сете

вого

обм

ена

паке

там

и IP

X ст

ека

Nov

ell

4Тр

ансп

ортн

ый

Обе

спеч

ивае

т во

змож

ност

ь пе

реда

чи б

олее

дли

нны

х со

общ

ений

м

ежду

хос

там

иП

рото

колы

TC

P и

UD

P ст

ека

TCP/

IP и

про

токо

л SP

X ст

ека

Nov

ell

5С

еанс

овы

йУс

тана

влив

ает

и по

ддер

жив

ает

соед

инен

ие м

ежду

ком

поне

нтам

и ра

спре

деле

нной

сис

тем

ы. И

спол

ьзуе

т мех

аниз

м с

оеди

нени

й тр

анс -

порт

ного

уро

вня

Про

меж

уточ

-на

я ср

еда

6П

редс

тави

-те

льск

ийУс

тран

яет р

азли

чия

в пр

едст

авле

нии

данн

ых.

Это

т уро

вень

гара

нти-

рует

то, ч

то и

нфор

мац

ия, п

еред

авае

мая

при

клад

ным

уро

внем

, буд

ет

поня

тна

прик

ладн

ому

уров

ню в

дру

гой

сист

еме.

При

нео

бход

имос

ти

уров

ень

прео

браз

овы

вает

дан

ные

в не

кото

рый

общ

ий ф

орм

ат п

ред -

став

лени

я ил

и вы

полн

яет

обра

тное

пре

обра

зова

ние

Secu

re S

ocke

t Lay

er (S

SL)

7П

рикл

адно

йО

бесп

ечив

ает

фун

кцио

ниро

вани

е пр

илож

ения

. Наб

ор п

рото

коло

в,

с по

мощ

ью к

отор

ых

поль

зова

тели

сет

и по

луча

ют

дост

уп к

раз

де-

ляем

ым

рес

урса

м

Про

токо

л эл

ектр

онно

й по

чты

Ком

поне

нт

инф

орм

а -ци

онно

й си

стем

ы

25

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

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

Дляопределенностипредставим,чтонеобходимопередатьтолькоимяклиентаисуммуденежногоперевода.Приведенныйнижепри-меркода(С#)демонстрируетвариантреализацииконечнойточкиWeb-приложения,вкоторомсоздаетсясокетсадресомmy.bank.comипосетипересылаетсясуммаиимяклиента.

String hostName = "my.bank.com";

//Задание DNS-имени удаленного компьютера

int port = 80;

IPHostEntry hostInfo = Dns.GetHostByName (hostName);

//Преобразование имени удаленного компьютера в IP-адрес

IPAddress address = hostInfo.AddressList [0];

IPEndPoint endpoint = new IPEndPoint (address, port);

Socket socket = new Socket (address.AddressFamily, SocketType.

Stream, ProtocolType.Tcp);

socket.Connect (endpoint);

byte [] amount = BitConverter.GetBytes (1000);

//Преобразование данных в поток байтов

byte [] name = Encoding.ASCII.GetBytes ("Joe");

int bytesSent = socket.Send (amount);

bytesSent += socket.Send (name);

socket.Close ();

Напервыйвзглядпростойметодмежплатформеннойинтеграцииимеетрядограничений:

� связываемыесистемыдолжныиметьодинаковоевнутреннеепредставлениецелыхчисел(32или64бит)иодинаковыйпорядокследованиябайтов(прямойилиобратный).Впротивномслучаепередаваемыеданныебудутневерноинтерпретированыприложе-нием-получателем;

26

� компьютердолжениметьнеизменяемыйадрес.Перемещениеприложенияполучателянадругойкомпьютерпотребуетизмененияпрограммногокода;

� интегрируемыеприложениядолжныбытьдоступныводноитожевремя,посколькупротоколTCP/IPявляетсяпротоколомсустановкойсоединения.Еслиодноизвзаимодействующихприло-женийвмоментустановкисоединениянедоступно,тосоединениенебудетустановлено;

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

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

Всередине1990-хгг.появилосьпонятиепромежуточнойсреды[20,18]какнекоторойдополнительной,независящейотоперационнойсистемыиприложений«прослойки»,реализующейсервисывысо-когоуровнядляинкапсуляцииудаленноговзаимодействиямеждупрограммнымикомпонентами.Промежуточнаясреда(middleware—связующеепрограммноеобеспечение)выполняетфункциисеан-совогоипредставительскогоуровнеймоделиOSI/ISO.Наличиепромежуточнойсредыпозволяетсоздатьоткрытые,масштабируемыеиотказоустойчивыераспределенныесистемы.

Промежуточнаясредапредоставляет:� единый,независимыйотоперационнойсистемымеханизмис-

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

� безопасность—аутентификацияиавторизациявсехпользо-вателейсервисовкомпонентаизащитапередаваемоймеждуком-понентамиинформацииотискаженияичтениятретьейстороной;

� целостностьданных—управлениетранзакциями,распределен-нымимеждуудаленнымикомпонентамисистемы;

� балансировкунагрузкинасерверыспрограммнымикомпонен-тами;

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

27

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

� ориентированные на посылку сообщений—поддерживаютсвязьмеждукомпонентамираспределеннойсистемыпосредствомобменасообщениями(MicrosoftMessageQueuing,IBMMQSeries,SunJavaSystemMessageQueue);

� объектно-ориентированные—построенынамоделиудаленногообращениякметоду(J2EE,.NET,CORBA);

�транзакционно-ориентированные—ориентированынапод-держкутранзакцийвсистемахраспределенныхбазданных(монито-рытранзакций,всесовременныепромышленныеСУБД,напримерMSSQLSERVER).

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

2.2. Модели взаимодействия приложений

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

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

Схемасинхронноговзаимодействияпредставленанарис.2.1.Вслучаеасинхронного взаимодействияприложение-клиентпосле

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

28

Рис. 2.1. Синхронное взаимодействие

Рис. 2.2. Асинхронное взаимодействие

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

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

29

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

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

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

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

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

2.3. Стандарты объектно-ориентированного взаимодействия

Вданнуюгруппувходятстандарты,основанныенаконцепцииудаленноговызоваметодаилипроцедуры.КнимотносятстандартыCOM(DCOM,COM+),RMI,CORBA[2,22,29].

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

Вкачествепримерарассмотримтехнологииудаленноговызовапроцедуры(remoteprocedurecall,RPC)иудаленноговызоваметода(remotemethodinvocation,RMI).

Удаленный вызов процедурывпервыебылреализованвначале1980-хгг.компаниейSunMicrosystemsиявилсяпрообразомобъ-ектно-ориентированного промежуточного слоя применительнокструктурнойпарадигмепрограммирования.СутьтехнологииRPCзаключаетсявтом,чтовызовфункциинаудаленномкомпьютереосуществляетсяспомощьюпромежуточногопрограммногообес-печениятакже,какиналокальном[22].

30

Для того чтобы организовать удаленный вызов процедурынеобходимо:

� описатьинтерфейспроцедуры,котораябудетиспользоватьсядляудаленноговызоваприпомощиязыкаопределенияинтерфейсов(InterfaceDefinitionLanguage,IDL);

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

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

� клиентскийпереходниквыполняетпривязкуксерверу(опре-деляетфизическоеместонахождение(адрес)сервера);

� клиентскийпереходниквыполняетмаршалинг1(упаковываетвызовпроцедурыиееаргументывсообщениевнекоторомстан-дартномдляданнойсистемыформате);

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

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

� после получения ответа от сервера выполняется процедурадесериализации.

1Процесспреобразованияпараметровдляпередачиихмеждупроцессамиприудаленномвызовеназываетсямаршализацией(marshaling).

2Процесспреобразованияэкземпляракакого-либотипаданныхвнаборбайтназываетсясериализацией.

3Процедура,обратнаясериализации.4Процедура,обратнаямаршалингу.

31

Сущностьтехнологииудаленноговызовапроцедурыиллюстри-руетрис.2.3.

Рис. 2.3. Удаленный вызов процедуры

Удаленный вызов методаявляетсямодификациейметодаудаленно-говызовапроцедурыдляобъектнойпарадигмыпрограммирования.

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

Промежуточнаясреданасторонесерверадесериализуетпарамет-рыипередаетихзаглушке,называемойкаркасом,илискелетоном(skeleton),насторонесервера.

Втабл.2.2приводитсякраткаяхарактеристикастандартовобъ-ектно-ориентированноговзаимодействия.

32

Табл

иц

а 2

.2

Ста

ндар

ты о

бъ

ектн

о-о

ри

енти

ро

ванн

ого

вза

им

од

ейст

вия

Ста

ндар

тН

азна

чени

еД

осто

инст

ваО

гран

ичен

ия

Com

Сре

дств

о вз

аим

одей

стви

я пр

илож

ений

, фун

кцио

ниру

ю-

щих

на

одно

м к

омпь

юте

ре

Вы

соки

й ур

овен

ь аб

стра

кции

Про

стот

а ис

поль

зова

ния

Оче

нь в

ысо

кая

прои

звод

ител

ьнос

ть

СО

М-п

рило

жен

ия с

посо

бны

фун

кцио

ниро

вать

то

лько

под

упр

авле

нием

Win

dow

s (д

воич

ная

стру

ктур

а об

ъект

ов к

омпо

нент

ной

мод

ели

Mic

roso

ft)

Расп

реде

ленн

ые

реш

ения

пло

хо м

асш

таби

рую

т-ся

(жес

ткая

свя

зь м

ежду

кли

енто

м и

сер

веро

м)

Нев

ысо

кая

усто

йчив

ость

к с

боям

СО

М-с

исте

м

(жес

ткая

при

вязк

а се

рвер

а к

клие

нту,

дву

хуро

в-не

вая

архи

тект

ура)

Com

+П

ром

ежут

очна

я ср

еда

для

созд

ания

рас

пред

елен

ных

сист

ем, д

ейст

вую

щих

в

лока

льно

й се

ти

Под

держ

ка с

инхр

онно

го и

аси

нхро

нног

о вз

аим

одей

стви

й пр

огра

мм

ных

ком

по-

нент

ов

Дин

амич

еска

я ба

ланс

иров

ка н

агру

зки

Под

держ

ка л

огич

еско

й це

лост

ност

и да

нны

х за

сче

т ра

боты

с к

оорд

инат

ором

ра

спре

деле

нны

х тр

анза

кций

Воз

мож

ност

ь ог

рани

чени

я до

ступ

а к

ком

поне

нту

в ра

зрез

е ро

лей,

свя

занн

ых

с уч

етны

ми

запи

сям

и по

льзо

вате

лей

Исп

ольз

ован

ие о

гран

ичен

о вз

аим

одей

стви

ем

ком

поне

нтов

вну

три

лока

льно

й ил

и ви

ртуа

льно

й ча

стно

й се

ти, п

остр

оенн

ой н

а ба

зе M

icro

soft

Win

dow

s, в

пре

дела

х од

ного

пре

дпри

ятия

33

Ста

ндар

тН

азна

чени

еД

осто

инст

ваО

гран

ичен

ия

DC

OM

Про

меж

уточ

ная

сред

а дл

я со

здан

ия р

аспр

едел

ен-

ных

сист

ем, д

ейст

вую

щих

в

лока

льно

й се

ти и

сет

и И

нтер

нет

Нез

авис

имос

ть о

т яз

ыка

про

грам

мир

о -ва

ния

Про

стот

а

Под

держ

ка р

аспр

едел

енны

х тр

анза

кций

Исп

ольз

ован

ие о

гран

ичен

о пл

атф

орм

ами

Win

dow

s

CO

RB

AН

абор

спе

циф

икац

ий д

ля

пром

ежут

очно

го п

рогр

амм

-но

го о

бесп

ечен

ия о

бъек

т-но

го т

ипа.

Соз

дава

лась

ко

нсор

циум

ом O

MG

как

ун

ивер

саль

ная

мет

одол

огия

со

здан

ия р

аспр

едел

енны

х си

стем

в г

етер

оген

ных

сред

ах

Крос

спла

тфор

мен

ност

ь

Вы

соки

й ур

овен

ь ус

тойч

ивос

ти к

вну

трен

-ни

м с

боям

за

счет

бол

ьшей

изо

ляци

и кл

иент

ов и

сер

веро

в (т

реху

ровн

евая

ар

хите

ктур

а)

Пер

едач

а да

нны

х м

ежду

ком

поне

нтам

и пр

оисх

одит

при

пом

ощи

прот

окол

а U

DP

(обе

спеч

ивае

т эк

оном

ию с

исте

мны

х ре

сурс

ов)

Наб

ор с

ерви

сов

(упр

авле

ние

тран

закц

и-ям

и, б

езоп

асно

стью

, жиз

ненн

ым

цик

лом

об

ъект

ов, с

обы

тиям

и и

т.д.)

Сло

жно

сть

техн

олог

ии

RM

IАр

хите

ктур

а (R

emot

e M

etho

d In

voca

tion,

то

есть

вы

зов

удал

енно

го м

етод

а), к

отор

ая

инте

грир

ован

а с

JDК1

.1

и ре

ализ

ует

расп

реде

лен -

ную

мод

ель

вычи

слен

ий

Сам

ый

прос

той

и бы

стры

й сп

особ

со

здан

ия р

аспр

едел

енны

х си

стем

Расп

реде

ленн

ое а

втом

атич

еско

е уп

рав-

лени

е об

ъект

ами

Под

держ

ка о

дног

о яз

ыка

про

грам

мир

ован

ия

Java

Соб

стве

нны

й пр

оток

ол в

заим

одей

стви

я

Труд

ност

ь ин

тегр

иров

ания

с с

ущес

твую

щим

и пр

илож

ения

ми

Око

нчан

ие

таб

ли

цы

2.2

34

2.4. Технологии, базирующиеся на XML

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

XML—этоязыкразметкидокументов,предназначенныйдляхраненияструктурированныхданных,обменаинформациеймеждупрограммами,атакжедлясозданиянаегоосновеспециализиро-ванныхпроизводныхязыков[17,15,35].

Вначале2000-хгг.,когданапервыйпланвышлипроблемыин-теграцииразнородныхприложений,появиласьконцепцияWeb-службиоснованнаянанейпарадигмасервис-ориентированнойархитектуры,началиразвиватьсятехнологииуправлениябизнес-процессами(BPM).Крупнейшиепоставщикипрограммногообес-печенияактивноразрабатываливнутрикорпоративныестандартыописания,реализациииисполнениябизнес-процессовдлясвоихпрограммныхсистем.Появилисьмногочисленныеспецификацииязыковописаниябизнес-процессов(JPDL,XLang,WSFL,WSCL,BPSS,WSCI),опубликованныеконкурирующимивендорами[16].Насегодняшнийденьобщепризнаннымистандартамипроцессно-гоуправленияявляютсяоснованныенаXMLязыки:WSDL(WebService Definition Language), WS-BPEL (Web Services BusinessProseccExecutionLanguage)иWS-CDL(WebServicesChoreographyDiscriptionLanguage).

2.4.1. Целесообразность применения XML в интеграционных задачах

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

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

35

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

2) XML — самодокументируемый формат, предназначенныйнетолькодляописанияданных,ноидляопределенияметаданных,втомчиследляописаниядополнительныхправил,ограничивающихданныевсоответствиисинформационноймодельюпредметнойобласти.Например,XSD-схемапозволяетзадатьследующиетипыограничений:

� базовыеипроизводныетипыданных(строки,даты,логическийидр.);

� расширенныетипыданных(произвольныепользовательскиетипыданных);

�фасеты(дополнительныеограничения,такиекакдлина,дробныечислаит.д.);

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

данных);�шаблоны;

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

4)XML—расширяемыйязык.ЛюбуюXML-структуруможноразрабатыватьврасчетенаоперативноесокращениеилирасширение.Расширениевозможнокакзасчетвключениявструктуруновыхэлементови/илиатрибутов,такипутемиспользованиямеханизмовпространствимен;

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

� возможностьчитатьисоздаватьтекстовыефайлывкодировкеЮникод(UTF-8илиASCII);

� наличиесинтаксическогоанализаторадляобработкиXML-до-кументов;

6)безусловнымпреимуществомявляетсяналичиемеждународныхстандартов(поддерживаютсяконсорциумомW3C—www.w3.org).

36

Языкимеетстрогоопределенныесинтаксиситребованияканализу,чтопозволяетемуоставатьсяпростым,эффективныминепроти-воречивым.АктуальнымиспецификациямиявляютсяXML1.0,XMLInformationSet,NamespacesinXML,XMLSchema.Внастоя-щеевремяXMLширокоиспользуетсядляхраненияиобработкидокументовиподдерживаетсявсемиведущимипроизводителямипрограммногообеспечения;

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

2.4.2. Синтаксис XML

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

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

Логическая структура XML-документа

Логическаяструктурасостоитизследующихэлементов:� объявление;� определениятипадокумента;� элементы;� комментарии;� ссылки;� инструкциипообработкедокумента.

Втабл.2.3представленыосновныетребованияспецификацииXML1.0,предъявляемыексинтаксисуXML-документов.

37

ПриведемпримерXML-документа.

<?xml version="1.0" encoding="windows-1251"?> <Контрагенты> <Контрагент Код="Ю023"> <Наименование>Рога и копыта</Наименование> <ИНН>1232345678</ИНН> <КПП>775003657</КПП> <Адрес Индекс="118200" Город="Москва" Улица="Широкая" Дом="100"> </Адрес> <КонтактноеЛицо ФИО="Иванов Иван Иванович" > <Телефон> <СлужебныйТелефон>74952113477</СлужебныйТелефон> <МобильныйТелефон>79056784523</МобильныйТелефон> </Телефон> </КонтактноеЛицо> </Контрагент></Контрагенты>

Таблица 2.3

Синтаксис XML

Элемент логической структуры

Описание Пример

1 2 3

Объявление Размещается в начале документа.Ограничивается тегами <?xml и?>.Включает атрибуты:1) version — номер версии спецификации XML,

обязательный атрибут;2) еncoding — кодировка символов документа

(по умолчанию encoding="UTF-8"), необяза-тельный атрибут. Если имена тегов задаются на русском языке, необходимо установить encoding="windows-1251";

3) standalone — указание на наличие внешних описаний структуры документа, по умолчанию standalone="no", необязательный атрибут.

Атрибуты должны следовать в указанном выше порядке.Если атрибуты не определены, то им присваива-ется значение по умолчанию

<?xml version="1.0" encoding="UTF-8"?>

38

1 2 3

Определения типа доку-

мента

DTD (Document Type Declaration) заключается меж-ду символами <! DOCTYPE…> и может занимать несколько строк. В этой части объявляются теги, использованные в документе, или приводится ссылка на файл, в котором записаны такие объ-явления.Секция DTD должна располагаться перед кор-невым элементом

Пример см. в п. «Языки описания структуры»

Элементы Элементы являются основными составляющими XML-документа; бóльшая часть данных в XML-документах содержится в элементах. Элемент представляется в XML-документе с помощью открывающего (<>) и закрывающего (</>) тэ-гов. Открывающий тэг записывается в формате <ИмяЭлемента>, а закрывающий тэг — в формате </ИмяЭлемента>.Имя элемента не может содержать пробелов.Содержимым элемента могут быть символьные данные (текст), другие элементы (известные как дочерние элементы), а также оно может отсутст-вовать (пустой элемент).XML-документ должен содержать обязательный корневой элемент.Элемент может содержать любое число атрибу-тов, содержащих дополнительную информацию о данных, которые представляет элемент. Атри-буты указываются в виде пар «название-значе-ние» в открывающем тэге элемента. Значения атрибутов заключаются в кавычки.Названия атрибутов уникальны в рамках одного элемента (в одном элементе не может быть двух атрибутов с одинаковым именем)

<Книга></Книга>

<Книга isbn="978-5-9775-0778-3"> </Книга>

Комментарии Ограничиваются тегами <! и !>. Используются для документирования. Могут располагаться в любом месте документа



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

&# код_символа_в_Unicode

&#xШестнадцатерич-ный_код_символа

имя_сущности

Продолжение таблицы 2.3

39

1 2 3

Ссылки на сущности позволяют включать любые строковые константы в содержание элементов или значения атрибутов. Ссылки на сущности указывают программе-анализатору подставить вместо них строку символов, заранее заданную в определении типа документа.Для включения в XML-документ символьных дан-ных, которые не следует обрабатывать, исполь-зуется секция <! [CDATA [содержание секции]] >

Инструкции по обработке

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

<?xml version="1.0" encoding="windows- 1251"?>

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

Физическая структура XML-документа

ФизическаяструктураXML-документаописываетегокакнаборсущностей.Документдолженсодержатькакминимумоднусущ-ность—корневуюсущностьдокумента.СущностимогутвключатьсявXML-документтакжеспомощьюXML-ссылок.

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

2.4.3. Пространства имен

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

Окончание таблицы 2.3

40

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

Рассмотримправилаиспользованияпространствименнакон-кретномпримере.Пустьводномдокументенеобходимообъединитьданныеоклиентекомпании,поступающиеизразныхисточников.ИзCRM-системыпоступаетинформацияоперсональныхданныхклиента,изсистемыучетазаказов—данныеозаказе.

CRM

<Client> <Name>Mary</Name> <Phone>+7.602.555.9999</Phone> <Fax>+7.602.555.9999</Fax></Client>

Система учета заказов

<Client> <OrderNumber>2223</OderNumber> <OrderData>10.10.2012</OrderData></Client>

Пространствоименобъявляетсяспомощьюзарезервированногоимениxmlns.НижеприводитсяпримеробъявленияпространствименвXML-документе.

<Clients xmlns:ClientInfo="http://www.mycompany.com/ClientInformation" xmlns:ClientOrderData="http://www.mycompany.com/ClientOrderData">

ClientInfoиClientOrderDataявляютсяпрефиксамипространствименипредставляютсокращенныенаименованияидентификаторов.

41

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

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

<?xml version="1.0" encoding="utf-8"?><Clients xmlns:ClientInfo = "http://www.mycompany.com/ClientInformation" xmlns:ClientOderData="http://www.mycompany.com/ ClientOrderData" > <ClientInfo:Client> <ClientInfo:Name>Mary</ClientInfo: Name> <ClientInfo:Phone>+7.602.555.9999</ClientInfo:Phone> <ClientInfo:Fax>+7.602.555.9999</ClientInfo:Fax> </ClientInfo:Client> <ClientOrderData:Client> <ClientOderData:OrderNumber>2223</ClientOderData:OrderNumber> <ClientOderData:OrderData>10.10.2012</ClientOderData:OrderData> </ClientOderData:Client></Clients>

Имяэлементаилиатрибутаспрефиксомназываетсяуточненным именем(qualifiednameилиQName)ииспользуетсяанализаторамиXMLдляизвлеченияэлементов,принадлежащихсоответствующимпространствамименвпределахглобальногоXML-пространстваименhttp://www.w3.org/XML/1998/namespace.

Еслипространствоименобъявленобезпрефикса,тооноявляетсяпространствомименпоумолчаниюдлятехэлементовXML-доку-мента,которыенеиспользуютпрефикс.КаждоепространствоименимеетсвоюобластьдействияврамкахXML-документа.Объяв-лениепространстваименприменяетсякэлементу,содержащемуопределение,атакжековсемегодочернимэлементам,еслиононепереопределяетсядругимпространствомименвопределенииэлемента.Именаатрибутовтакжеможноуточнять,используяпре-фиксобъявленногопространстваимен.Дляатрибутовнельзяис-пользоватьпространстваименпоумолчанию.Еслидляатрибутанеуказанпрефикс,тооннепринадлежитниккакомупространствуимен.Атрибутыэлементовдлясвязыванияспространствамиименвсегданеобходимоуточнятьпрефиксами.

42

Приведемпримериспользованияпространстваименhttp://www.mycompany.com/ClientInformationкакпространстваименпоумолчанию:

<?xml version="1.0" encoding="utf-8"?><Clients xmlns="http://www.mycompany.com/ClientInformation" xmlns:ClientOrderData="http://www.mycompany.com/ ClientOrderData"> <Client> <Name>Mary</Name> <Phone>+7.602.555.9999</Phone> <Fax>+7.602.555.9999</Fax> </Client> <ClientOrderData:Client> <OrderNumber>2223</OrderNumber> <OrderData>10.10.2012</OrderData> </ClientOrderData:Client></Clients>

2.4.4. Описание структуры XML-документов

КаждыйXML-документнесетинформациюоданныхиихструк-туре(описаниеметаданных).

XML-документымогутбытьдвухтипов:1)документы,созданныесучетомлогическихиструктурныхправил;2)документы,неиспользующиеникакихправил,кромесинтак-

сическихправилоформленияXML-документов.Проверкудокументовпервоготипанасоответствиезаданным

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

Присозданиидокументапервоготипаописаниеегострукту-рыможетбытьвыполненосиспользованиемтакихязыков,какDocumentTypeDefinitions(DTD),XMLSchema,RELAXNG,XMLData-Reducedидр.[24,31].НаибольшеераспространениеполучилиязыкиDTDиXMLSchema.

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

43

Язык Document Type Definitions (DTD)

ЯзыкDocumentTypeDefinitions(DTD)небазируетсянаXML.Этотязыкимеетрядограниченийвописанииметаданных:неявля-етсярасширяемым,неподдерживаетстрогоетипизированиеданных,ограниченноподдерживаетпространстваимен.ОписаниеструктурынаязыкеDTDпостепенновытесняетсятехнологиейXMLSchema,однакодонастоящеговременипродолжаетиспользоваться(иногдасовместносXMLSchema).

ПриведемкраткоеизложениеправилиспользованияосновныхконструкцийDTD.

ОписаниеструктурынаязыкеDTDможетбытьвключеновXML-документ(внутреннееподмножество)илиразмещеновотдельномфайле,такжевозможенвариантсмешанногоописания.Вовсехслу-чаяхдляопределенияDTDнеобходимоиспользоватьобъявление<!DOCTYPE…>.Втабл.2.4приведеныправилавключенияDTD-описаниявXML-документ.

Таблица 2.4

Правила включения DTD-описания в XML-документ

Вариант описания структуры

Правила записи

Внутренне описание DTD

<! DOCTYPE ROOT [<!— ОБЪЯВЛЕНИЯ DTD —>] >где ROOT — имя корневого элемента;

<!— ОБЪЯВЛЕНИЯ DTD —> — описание структуры на языке DTD

Внешнее описание DTD

<! DOCTYPE ROOT SYSTEM "SYSTEM_ID">где ROOT — имя корневого элемента;

SYSTEM_ID — место расположения файла внешнего DTD.Например, <! DOCTYPE Clients SYSTEM "Clients.DTD">

<! DOCTYPE ROOT PUBLIC "PUBLIC_ID" "SYSTEM_ID">где SYSTEM_ID и PUBLIC_ID — место размещения файла

внешнего DTD; PUBLIC_ID не зависит от места размещения XML-файла (например, место в локальной сети);

"SYSTEM_ID" будет использовано только в том случае, если нет доступа к "PUBLIC_ID".

Например, <! DOCTYPE Clients PUBLIC"-//W3C//DTD Strict/RU" "Client.dtd">

44

ЯзыкDTDпозволяетописатьтребованиякэлементамиатрибутамдокумента.Приописанииэлементовуказываются:

� модельсодержимого,описывающаятакженаличиедочернихэлементов;

� ограничениянаколичествоповторенийэлементавдокументе.Дляописанияэлементаиспользуетсяконструкцияследующего

вида:

! ELEMENT Имя_элемента Модель_содержимого>.

Правилазаписимоделисодержимогопредставленывтабл.2.5.

Таблица 2.5

Правила записи модели содержимого

Модель содержимого


ANY Элемент может содержать любые дочерние элементы или текст

<! ELEMENT Client ANY>

EMPTY Элемент не может содер-жать дочерние элементы или текст, может иметь атрибуты

<! ELEMENT OrderID EMPTY>

(#PCDATA) Элемент может содержать только текст

<! ELEMENT Phone (#PCDATA) >

(NAME1, NAME2) Элемент содержит указан-ные дочерние элементы в указанном порядке, не мо-жет содержать текст

<! ELEMENT Client (Name, Phone) >

(NAME1|NAME2) Элемент содержит один из указанных взаимоисклю-чающих элементов, не мо-жет содержать текст

<! ELEMENT Client (Fax |Phone) >

Смешанная модель Элемент может содержать текст и дочерние элементы

<! ELEMENT Client (#PCDATA, Name, Phone) >

Ограничениянаколичестводочернихэлементовзадаетсяследу-ющимобразом(табл.2.6).

45

Таблица 2.6

Ограничения на количество дочерних элементов

Оператор количества элементов


Нет Допустимо использовать один экземпляр элемента

<! ELEMENT Client (INN) >

* Элемент может повторяться ноль и более раз

<! ELEMENT Clients (Client*) >

+ Элемент может повторяться один и более раз

<! ELEMENT Client (Phone+) >

? Элемент может повторяться ноль или один раз

<! ELEMENT Client (Address?) >

Атрибутыэлементовобъявляютсядлякаждогоэлемента,еслиэтонеобходимо,спомощьюобъявленияATTLIST.

Приописанииатрибутовуказываются:� типатрибута;� ограничениянаупотреблениеатрибута.

Дляописанияатрибутовэлементаиспользуетсяконструкцияследующеговида:

<! ATTLIST Имя_элемента Имя_атрибута1 Тип_атрибута (Значение_по_умолчанию | Ключевое_слово) Имя_атрибута2 Тип_атрибута (Значение_по_умолчанию |

Ключевое_слово) >

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

Таблица 2.7

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

Тип атрибута Описание

CDATA Строка символов

ID Уникальное в рамках документа значение (аналог первичного ключа в базе данных), элемент не может иметь больше одного атрибута типа ID

46

Тип атрибута Описание

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

IDREFS Последовательность ссылок IDREF, разделенных пробелами. Позволяет смоделировать отношение «один-ко-многим»

ENTITY Определяет имя внутренней или внешней сущности, предназначенной для повторного использования. В том числе используется для опреде-ления имени примитива, игнорируемого анализатором. Позволяет ссы-латься на данные, структура которых нарушает разметку по правилам XML (в частности, использовать в XML-документах ссылки на двоичные файлы)

ENTITIES Перечень значений ENTITY, разделенных пробелами

NMTOКEN Имя, содержащее только символы, применяемые в именах (строка, состо-ящая из букв, цифр и символов «.», «-», «_», «:»). Может содержать имена других элементов или атрибутов

NMTOКENS Перечень значений NMTOКEN, разделенных пробелами

Ограничениянаиспользованиеатрибутовзадаютсяспомощьюследующихключевыхслов(табл.2.8).

Таблица 2.8

Ограничения на использование атрибутов

Ключевое слово Описание Пример

#REQUIRED Обязательный атрибут ClientID ID #REQUIRED

#IMPLIED Необязательный атрибут Address Region #IMPLIED

«Значение по умолчанию»

Если атрибут отсутствует, то ана-лизатор принимает в качестве его значения значение, заданное по умол-чанию. Если атрибут имеется, то он может принимать любое значение

#FIXED «Значение» Атрибут является необязательным, но если значение указано, то оно задается по умолчанию

Клиент Тип #FIXED «ФЛ»


47

ВкачествепримерарассмотримXML-документисоответствую-щееемуDTD-описание.

<Clients> <Client ClientID="0001" ClientType="ФЛ" Class="VIP"

System="CRM"> <Name>Mary</Name> <Phone> <Home>+7.677.444.1111</Home> <Mobile>+7.555.444.3333</Mobile> <Mobile>+7.666.333.2222</Mobile> </Phone> <mail>[email protected]</mail> <Country>Russia</Country> </Client>

<! ELEMENT Clients (Client*) ><! ELEMENT Client (Name,Phone,Mail,Country) ><! ELEMENT Name (#PCDATA) ><! ELEMENT Phone (Home?,Mobile+) ><! ELEMENT Mail (#PCDATA) ><! ELEMENT Country (#PCDATA) ><! ELEMENT Home (#PCDATA) ><! ELEMENT Mobile (#PCDATA) ><! ATTLIST Client ClientID ID #REQUIRED ClientType CDATA #REQUIRED Class CDATA #IMPLIED System NMTOКEN #FIXED "CRM">

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

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

48

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

XML-документ,использующийнотации,играетрольунифици-рующегодокумента,объединяющегоразнородныеданные.

ФорматыописаниялогическихкомпонентовXMLприведенывтабл.2.9.

Таблица 2.9

Форматы описания логических компонентов XML

Тип логического компонента

Формат описания (пример)

Внутренний примитив

<! ENTITY Имя_примитива "Значение">

ПримерСтрока DTD<! ENTITY Система "1С:Предприятие">В DTD используется примитив Система, имеющий значение 1С:Предприятие.

Строка XML<Клиент ИсточникДанных="&Система;">В XML-документе атрибуту Источник данных тега Клиент будет присвоено значение 1С:Предприятие

Внешний примитив, обрабатываемый анализатором

<! ENTITY Имя_примитива SYSTEM "SYS_ID"> или <! ENTITY Имя_примитива PUBLIC "PUBL_ID" "SYS_ID">,где "SYS_ID" — ссылка на реально существующий внешний

файл (URL); "PUBL_ID" — идентификатор ресурса (URI), не обязательно реально существующий.

ПримерСтрока DTD<! ENTITY Описание SYSTEM "C:/Discription.xml">

В DTD используется внешний примитив Описание, который определяет внешний файл C:/Discription.xml, содержащий описание клиента.

Строка XML<Клиент>&Описание;</Клиент>

В тег Клиент будет вставлено содержимое файла C:/Discription.xml

49

Тип логического компонента

Формат описания (пример)

Внешний примитив, игнорируемый анализатором

<! ENTITY Имя_примитива SYSTEM "SYSTEM_ID" NDATA Имя нотации>,где "SYSTEM_ID" — ссылка на реально существующий внешний

файл (URL); Имя_нотации — имя нотации, содержащей информацию о программе-обработчике не-XML-данных.

Для описания нотации используется следующий формат:<! NOTATION Тип_данных SYSTEM "SYSTEM_ID">,где Тип_данных — имя формата данных;

SYSTEM_ID — внешняя программа-обработчик.

ПримерФрагмент DTD<! ELEMENT Book EMPTY><! ATTLIST Bookimage ENTITY #REQUIRED><! NOTATION gif SYSTEM "gif-viewer.exe"><! NOTATION jpg SYSTEM "jpg-viewer.exe"><! ENTITY news SYSTEM "images/news.gif" NDATA gif><! ENTITY products SYSTEM "images/products.jpg" NDATA jpg><! ENTITY support SYSTEM "images/support.gif" NDATA gif>

Фрагмент XML<Book image="news" /><Book image="products" />< Book image="support" />

В XML-документ будут вставлены соответствующие графические файлы

Язык XML Sсhema Definition (XSD)

ЯзыкXMLSchemaDefinition(XSD)основаннаXMLиобладаетболееширокимивозможностямиописанияструктурыдокумента,чемDTD.Онподдерживаеттипизациюданных,пространстваимен,регулярныевыражения.

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


50

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

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

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

XMLSchemaвсегдасоздаетсявотдельномфайле,имеющемрас-ширениеxsd.ФайлXMLсвязываетсяссоответствующейсхемойспомощьюатрибутаschemaLocationпространстваименсхемы.ДлятогочтобыиспользоватьатрибутschemaLocation,необходимоопре-делитьпространствоименсхемы.ВсеэтиопределенияуказываютсявкорневомэлементедокументаXML.

<КорневойЭлемент xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:schemaLocation="Схема.xsd">

РассмотримосновныеэлементыструктурыXMLSchema.Корневымэлементомвсегдаявляетсяэлемент<schema>.Описание

атрибутовэлемента<schema>приводитсявтабл.2.10.

51

Таблица 2.10

Описание атрибутов элемента <schema>

Атрибут Обязательный Описание

elementFormDefault Нет Принимает значения «qualified» и «unqualified» (по умолчанию).Значение «qualified» указывет на то, что элементы документа должны уточняться префиксом пространства имен

attributeFormDefault Нет Принимает значения «qualified» и «unqualified» (по умолчанию).Значение «qualified» указывет на то, что атрибуты элементов документа должны уточняться префиксом пространства имен

xmlns: xs Да Всегда принимает значениеxmlns: xs="http://www.w3.org/2001/XMLSchema"Указывает на пространство имен языка XMLSchema для элементов и типов данных схемы. При наличии префикса (в данном примере — xs) все элементы и типы данных схемы должны уточняться этим префиксом (xs: schema). Если префикс отсутствует, то атрибут xmlns указывает для схемы пространство имен по умолчанию.Элемент <schema> может содержать несколько атрибутов xmlns с разными префиксами, указывающими на используемые в документе пространства имен

targetNamespace Нет Пространство имен для элементов XML-документа, определенных данной схемой

version Нет Версия схемы

xml: lang Нет Язык для всех комментариев схемы

Корневойэлемент<schema>можетсодержатьследующиедочер-ниеэлементы:

� <element>—используетсядляопределенияэлементовXML-до-кумента;

� <attribute>—используетсядляопределенияатрибутовXML-до-кумента;

� <group> — необходим для определения группы элементов,предназначеннойдляповторногоиспользованияврамкахсхемыпоссылкенаимягруппы;

52

� <attributeGroup>—используетсядляопределенияатрибутовгруппыэлементов;

� <annotation>—позволяетвключатьвXML-документдоку-ментацию;

� <import>—позволяетиспользоватькомпонентыуказаннойвнешнейсхемывосновнойсхеме(обеспечиваетмодульностьсхем);

� <include>—добавляетвсекомпонентыуказаннойвнешнейсхемывосновнуюсхему(обеспечиваетмодульностьсхем);

� <notation>—содержитопределениенотации,описывающейформатне-XML-данныхвXML-документе;

� <redefine>—переопределяеткомпонентывнешнейсхемы,име-ющейтожепространствоимен,чтоиосновнаясхема;

� <simpleType>—объявляетпростойтипсодержимогоэлемента.Элементыспростымтипомданныхмогутсодержатьтолькосим-вольныеданныеинемогутвключатьатрибутыидочерниеэлементы;

� <complexType>—объявляетсложныйтипсодержимогоэлемента,которыйможетвключатьатрибутыидругиеэлементы.

XMLSchemaподдерживаеттриосновныекатегориитиповданных:1)предопределенные примитивные типы—фундаментальныетипы

данных,накоторыеможноссылатьсяиприменятьихкэлементамиатрибутам.ПримерамипримитивныхтиповданныхявляютсяString,Float,Double,Time,Date,Decimal,AnyURI;

2)предопределенные производные типы—встроенныетипы,полу-ченныенаоснованиипримитивныхтипов.ПримерамипроизводныхтиповданныхявляютсяInteger,Long,Byte,Short,nonPositiveInteger,nonNegativeInteger,IDидр.;

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

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

<xs:element name="ИмяЭлемента" type="ТипДанных" /><xs:attribute name="ИмяАтрибута" type="ТипДанных"/>

1Атакжезаранееопределенныенестандартныетипыданных(см.ниже).

53

Дополнительнодляэлементовиатрибутовможноуказатьатри-бутыfixedилиdefaultдлязаданияфиксированныхзначенийэле-ментов/атрибутовилизначенийпоумолчанию.

<xs:element name="Пример" type="xs:string" default="Пример описания элемента"/>

Еслинеобходимоописатьнестандартныйтипданныхдляэлементаилиатрибута,тоэтоследуетделатьспомощьютега<sympleType>,описаввнемновыйтипданных.

<xs:element name="ИмяЭлемента"> <xs:simpleType> Описание нестандартного типа данных </xs:simpleType></xs:element>

Новыенестандартныепростыетипыданныхполучаютпутем:� сужения(restriction) встроенного илиранееопределенного

простоготипаспомощьюзаданиядополнительныхограничений;� объединения(union)простыхтипов;� использованиясписка(list)простыхтипов.

Примериспользованияновогопростоготипаданных,полученно-гопутемсуженияпредопределенноготипа(набазовыйтипStringнакладываютсяограничениянамаксимальноиминимальнодопу-стимуюдлинустроки):

<xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="20"/> <xs:minLength value="10"/> </xs:restriction></xs:simpleType>

Примериспользованияновогопростоготипаданных,полученногопутемобъединениябазовыхтипов(элементилиатрибутмогутпри-ниматьнеотрицательныеилинеположительныецелыезначения):

<xs:simpleType><xs:union memberTypes="xs:nonNegativeInteger xs:nonPositiveInteger"/></xs:simpleType>

54

Примериспользованияспискапростыхтипов(атрибутshoeSizesобъявляетсявкачествесписка,содержащегодесятичныезначения10.5,9,8и11):

<xs:simpleType name="Sizes"> <xs:restriction base="xs:decimal"> <xs:enumeration value="10.5"/> <xs:enumeration value="9"/> <xs:enumeration value="8"/> <xs:enumeration value="11"/> </xs:restriction></xs:simpleType>

<xs:attribute name="shoeSizes"> <xs:simpleType> <xs:list itemType="Sizes"/> </xs:simpleType> </xs:attribute>

ЯзыкXMLSchemaиспользуетразличныетипыограниченийнаданные(см.табл.2.8):

� ограничениядлины(количествосимволов);� границызначений(наибольшееинаименьшеезначениякак

диапазонилипорог);� ограниченияколичествацифрдесятичногочисла(общееколи-

чествоцифриликоличествоцифрпослезапятой);� списокдопустимыхзначений;�шаблоны;� обработкасимволовпробела.

Примеры использования различных ограничений приведенывтабл.2.11.

Таблица 2.11

Примеры использования ограничений

Тип ограничения Теги, задающие ограничения

Ограничения длины <length> — фиксированное количество символов:<xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="4"/> </xs:restriction></xs:simpleType>

55


<maxLength> — наибольшая длина значений определяемого типа:<xs:simpleType> <xs:restriction base="xs:string"> <xs:mfxLength value="20"/> </xs:restriction></xs:simpleType>

<minLength> — наименьшая длина значений определяемого типа:<xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="2"/> </xs:restriction></xs:simpleType>

Границы значений <maxInclusive> — максимально допустимое значение,<minInclusive> — минимально допустимое значение(в примере допустимы целые значения в диапазоне от 5 до 10, включая 5 и 10):<xs:simpleType> <xs:restriction base="xs:integer"> <xs:maxInclusive value="10"/> <xs:minInclusive value="5"/> </xs:restriction></xs:simpleType>

<maxExclusive> — максимально допустимое значение,<minExclusive> — минимально допустимое значение(в примере допустимы целые значения в диапазоне от 5 до 10, исключая 5 и 10):<xs:simpleType> <xs:restriction base="xs:integer"> <xs:maxExclusive value="10"/> <xs:minExclusive value="5"/> </xs:restriction></xs:simpleType>

Ограничения количества и типа цифр

<totalDigits> — общее количество цифр в определяемом число-вом типе — сужении типа decimal,<fractionDigits> — количество цифр в дробной части числа:<xs:simpleType> <xs:restriction base="xs:decimal"> <xs:totalDigits value="8"/> <xs:fractionDigits value="3"/> </xs:restriction></xs:simpleType>


56


Список допустимых значений

<enumeration> — элемент списка допустимых значений:<xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="один"/> <xs:enumeration value="два"/> <xs:enumeration value="три"/> </xs:restriction></xs:simpleType>

Шаблоны <pattern> — регулярное выражение, используемое для ограни-чения внешнего вида или формы значений данных:<xs:simpleType> <xs:restriction base="xs:string" <xs:pattern value="[Ю|Ф][0–9]{3}"/> </xs:restriction></xs:simpleType

Обработка символов пробела

<whitespace> — применяется при сужении типа string и опре-деляет способ преобразования пробельных символов (пробел, табуляция, перевод строки).Используется в трех вариантах:

1) все пробельные символы сохраняются:

<xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> </xs:restriction></xs:simpleType>

2) XML-процессор заменяет все пробельные символы на пробелы:

<xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="replace"/> </xs:restriction></xs:simpleType>

3) XML-процессор заменяет пробельные символы пробелами, затем убирает начальные и конечные пробелы, а из несколь-ких подряд идущих пробелов оставляет только один:

<xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="collapse"/> </xs:restriction></xs:simpleType>


57

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

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

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

<xs:simpleType name="Код"> <xs:restriction base="xs:string"> <xs:length fixed="true" value="4"/> <xs:pattern value="[Ю|Ф][0–9]{3}"/> </xs:restriction></xs:simpleType><xs:element name="Код1" type="Код"/><xs:element name="Код2" type="Код"/>

Вданномпримереопределеннестандартныйтипданныхсиме-нем«Код»,базирующийсянатипе«string»:ониспользованкактипданныхдляэлементов«Код1»и«Код2».

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

<xs:element name="ИмяЭлемента"> <xs:complexType> Описание сложного типа данных </xs:complexType ></xs:element>

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

Атрибут minOccursопределяетминимальнуюстепенькарди-нальности,тоестьнаименьшеевозможноеколичествоповторений

58

дочернегоэлемента.ЗначениеminOccurs,равноенулю,указываетнанеобязательность(опциональность)элемента.

Атрибут maxOccurs определяет максимальную степень кар-динальности,илинаибольшееколичествоповторенийэлемента.Максимальнаяиминимальнаястепеникардинальностизадаютсяопределеннымизначениями.ДляmaxOccursможетбытьуказанозначениеunbounded(элементвстречаетсялюбоеколичествораз).

<xs:element name="Книга"> <xs:complexType> <xs:sequence> <xs:element name="Название" type="xs:string"/> <xs:element name="Автор" type="xs:string" maxOccurs="4"/> <xs:element name="Код" type="xs:string"/> <xs:element name="Цена" type="xs:string"/> </xs:sequence> </xs:complexType></xs:element>

Вданномпримереописансложныйтипданныхдляэлемента«Кни-га»,содержащегодочерниеэлементы«Название»,«Автор»,«Код»,«Цена».Тег<sequence>являетсяиндикаторомпорядкавхождениядочернихэлементов(табл.2.12),аатрибутmaxOccursпоказываетмаксимальнодопустимоеколичествоповторенийэлемента«Автор».

<xs:complexType name="Цена"> <xs:choice> <xs:element name="Рубли" type="xs:double"/> <xs:element name="Доллары" type="xs:double"/> </xs:choice></xs:complexType >

Таблица 2.12

Теги индикатора порядка

Тег индикатора порядка

Описание

sequence Дочерние элементы должны встречаться в указанном порядке. Степень кардинальности определяет, может ли дочерний элемент повторяться

all Все дочерние элементы должны присутствовать в XML-документе. Дочерние элементы могут появляться в любом порядке, но должны встречаться только один раз. Нельзя задать значение степени карди-нальности maxOccurs и minOccurs, отличное от единицы

choice Из всех указанных дочерних элементов должен встречаться только один

59

Индикаторпорядкаchoiceуказывает,чтоэлементэтоготипа«Цена» может содержать либо элемент «Рубли», либо элемент«Доллары»,нонеоба.

Язык RELAX NG

ЯзыкRELAXNGтакжеиспользуетXML-синтаксисиявляетсяупрощеннымвариантомXMLSchema,сочетаетвсебепростотуDTDивозможностиXMLSchema.RELAXNG,какиXMLSchema,под-держиваеттипизациюданных,регулярныевыражения,пространстваименивозможностьссылатьсянасложныеопределения.

2.4.5. Программная обработка XML-документов

Приложения,работающиесXML-документами,получаютдоступкихсодержимомуиструктурепутемиспользованияспециальногопрограммногокомпонента—XML-процессора(XML-анализатора).Следуетотметить,чтоприложенияработаютненепосредственносXML-документом,асегоинформационнымпространствомXMLInfoset,получаемымврезультатеразбораXML-документаXML-про-цессом.Такимобразом,XML-процессорпредназначендляанализаXML-документа,извлеченияданныхипередачиихнаобработкувприкладнуюпрограмму.XML-процессорыподдерживаютмеха-низмXMLNamespace(спецификацияW3CXMLNamespaces1.0)иобеспечиваютпроверкуструктурнойисинтаксическойкоррект-ностиXML-документов.

XML-процессоры

ОбрабатываяXML-документ,XML-процессорыпредставляютегоструктуруввидеупорядоченноймоделиданных,доступккоторойосуществляетсяспомощьюстандартныхинтерфейсовприкладногопрограммирования.СуществуютдваосновныхтипаXML-процес-соров—объектные(DOM)ипотоковые(SAX).

Объектный анализаторстроитвсобственномпространствепамятииерархическуюмодельразбираемогодокумента(DocumentObjectModel,DOM),доступкэлементамкоторойприкладнаяпрограммаполучаетспомощьюDOM-интерфейсов.Основнымпреимуществомобъектногоанализатораявляетсято,чтоонсразупредоставляетприкладнойпрограммевсюструктуруXML-документа,позволяяееанализироватьвпроизвольномпорядке.

60

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

Обобщенная схема работы XML-процессора представленанарис.2.4.

Рис. 2.4. Обобщенная схема работы XML-процессора

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

XSLT-процессоры соответствуют спецификациям W3CXSLTransformProposedRecommendation1.0иXpathProposedRecommendation1.0,поддерживаютразличныеязыковыеипро-граммныеплатформы.

2.4.6. Компонентные модели структуры XML-документов

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

61

Так,припостроениимоделиданныхSOA-проектов,какправило,создаетсянесколькоXML-схем,основанныхнаконцепцииповтор-ногоиспользования.Общаясхема(мастер-схема)собираетсяизмо-дульныхподсхем,которыеможноповторноиспользоватьвразныхконтекстахиразличныхприложениях.

Например,схемуPerson.xsdможноиспользоватьвконтекстахименисотрудника,именипокупателяилиименипредставителяпоставщика.Врезультатедостигаетсяснижениезатратнапроек-тированиеиразработку.

ПустьсхемаPerson.xsdимеетвид:

<?xml version="1.0"?><xsd:schema xmlns: xsd=http://www.w3.org/2001/XMLSchema targetNamespace="http://www.company.org"xmlns=http://www.person.org elementFormDefault="qualified"> <xsd:complexType name="PersonType"> <xsd:sequence> <xsd:element name="Name" type="xsd:string"/> <xsd:element name="SSN" type="xsd:string"/> </xsd:sequence> </xsd:complexType></xsd:schema>

Мастер-схемаCompany.xsdиспользуетмеханизмincludeдляссыл-кинамодульнуюподсхему:

<?xml version="1.0"?><xsd:schema xmlns: xsd="http://www.w3.org/2001/XMLSchema"targetNamespace="http://www.company.org" xmlns="http://www.company.org" elementFormDefault="qualified"><xsd:include schemaLocation="Person.xsd"/> <xsd:element name="Company"> <xsd:complexType> <xsd:sequence> <xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element></xsd:schema>

Синтаксиссхемыпозволяетопределитьвподсхемеэлементы,группы,сложныеипростыетипыданных,которыеможнопод-

62

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

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

� включение(include)—вэтомслучаевключаемаяподсхемаста-новитсячастьюпространстваименосновнойсхемы.Данныйвариантиспользуется,еслиосновнаясхемаимеетединыйконтекст;

� импорт(import)—используется,когдаосновнаясхемаотноситсякнесколькимконтекстам,иссылканаподсхемудолжнасохранитьуникальностьпространстваименподсхемы;

� переопределение(redefine)—включаетвмастер-схемуподсхемуипозволяетпереопределитьнекоторыеконструкции.

<?xml version="1.0"?><xsd:schema xmlns: xsd=http://www.w3.org/2001/XMLSchema targetNamespace=http://www.company.org xmlns=http://www.company.org elementFormDefault="unqualified" xmlns:per=http://www.person.org xmlns: pro="http://www.product.org"> <xsd:import namespace=http://www.person.org schemaLocation=

"Person.xsd"/> <xsd:import namespace=http://www.product.org

schemaLocation="Product.xsd"/> <xsd:element name="Company"> <xsd:complexType> <xsd:sequence> <xsd:element name="Person" type="per:PersonType"

maxOccurs="unbounded"/> <xsd:element name="Product" type="pro:ProductType"

maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element></xsd:schema>

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

63

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

2.4.7. Язык запросов XSLT

XSLT(ExtensibleStylesheetLanguageTransformations)—эторас-ширяемыйязыкстилевыхпреобразований,предназначенныйдляописанияспособапреобразованиядокументовXMLвдокумен-тыдругихформатов.СпомощьюXSLТможнотрансформироватьXML-документвлюбойформат(HTML,TXT,RTF,PDFит.п.),атакжевXML-документдругойструктуры.Последняявозможностьширокоиспользуетсяприпередачеинформациимеждуразнымиинформационнымисистемами,оперирующимисоднойитойжеинформациейвразличномпредставлении.

ЯзыкXSLTоснованнаXML.ВсеэлементыязыкаXSLTотносят-сякпространствуименhttp://www.w3.org/1999/XSL/Transform(обычноониимеютпрефиксxsl).НаязыкеXSLTзаписываетсяинструкцияпообработкеXML-документа,предназначеннаядляXSLT-процессора.Насегодняшнийденьизвестныдвеспецификацииязыка—XSLT1.0иXSLT2.0.

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

Приведемпримерссылки:

<?xml version="1.0" encoding="windows-1251"?><?xml-stylesheet type="text/xsl" href="simple.xslt"?><Корневой элемент> </КорневойЭлемент>

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

64

XSLT-процессорвыполняетпреобразование,заданноевуказан-номXSLТ-файле.XSLTсовместносвходнымXML-документоминтерпретируетсяпроцессором,инавыходеполучаетсядокументдругогоформата.

Обычно XSLT используется совместно с XPath (XML PathLanguage)—языкомзапросовкэлементамXML-документа.ЗапросыпредназначеныдляорганизациидоступакузламвXML-документе,осуществляютнавигациюпоDOMвXML.

XSLT-файлимеетследующуюструктуру:1)обязательныйкорневойэлементstylesheet:

<xsl:stylesheet version="1.0" xmlns:xsl=http://www.w3.org/1999/XSL/ Transform> <Описание преобразования></xsl:stylesheet>

2)элементышаблона,предназначенныедляпоискаипреобразо-ванияотдельныхэлементовдокумента;

3)конструкциидлясериализацииданныхввыходнойдокумент.Описание основных элементов языка XSLT представлено

втабл.2.13.

Таблица 2.13

Описание основных элементов языка XSLT

Элемент Описание

xsl:output Элемент, управляющий форматом преобразованных данных. Обыч-но этот элемент объявляется сразу после элемента xsl:stylesheet. Обязательный атрибут method определяет тип выходного значения для таблицы стилей XSLT и может принимать одно их трех значе-ний: xml, html или text.Пример преобразования XML в XML:

<xsl:output method="xml" indent="yes"/>

xsl:template Основной элемент языка. Используется для записи шаблонов преобразования.Корневой элемент xsl:stylesheet должен иметь хотя бы один дочерний элемент xsl:template.В содержимом элемента хsl:template задается конструктор последовательности преобразованных узлов XML-документа.xsl:template имеет следующие атрибуты:

65


� match — обязательный атрибут, задает последовательность исходных узлов, для преобразования которых предназначен шаблон. Представляет собой выражение XPath, выделяющее узлы документа XML. Шаблон выполняется, когда обнаруживает совпадение (match);

� name — необязательный атрибут, используется элементом xsl:call-template для ссылки на шаблон;

� priority –необязательный атрибут, указывает порядок выполнения шаблонов, соответствующих одному и тому же выражению XPath;

� mode — необязательный атрибут. С его помощью можно сопо-ставлять шаблоны на основе значения, указанного в атрибуте mode, и выражения, указанного в выражении match.

<xsl:template match="/book"> <Последовательность преобразованных узлов></xsl:template>

Шаблон выполняется для каждого узла <book> в документе XML

xsl:value-of Используется для вывода значения узла. Значение выводится в виде строки. xsl:value-of представляет собой пустой элемент и не имеет никаких дочерних элементов. Выходное значение задается в обяза-тельном атрибуте select этого элемента как выражение XPath:

<xsl:template match="name"> <xsl:value-of select="."/></xsl:template>

Шаблон выполняется для элемента name. В выходной документ выводится значение элемента name

xsl:apply-templates Задается чаще всего внутри элемента xsl:template, предписывает обработать рекурсивно узлы — потомки узлов, отобранных роди-тельским элементом xsl:template:

<xsl:template match="/"> <xsl:apply-templates/></xsl:template>

Пример рекурсивной обработки всех потомков корневого элемента XML-документа.Необязательный атрибут select ограничивает обработку только ука-занными в нем узлами. Значение атрибута задается как выражение ХPath:

<xsl:template match="product"><xsl:apply-templates select="name"/></xsl:template> <xsl:template match="name"> <xsl:value-of select="."/></xsl:template>


66


xsl:if Условный оператор, управляющий преобразованием.Конструктор преобразования задается внутри тега xsl:if и запу-скается только в том случае, если истинно выражение, указанное в атрибуте test:

<xsl:template match="name"> <xsl:if test="@country="Russia""> <xsl:value-of select="."/> </xsl:if></xsl:template>

В выходной документ выводится значение элемента name только в том случае, если значение атрибута country равно Russia

xsl:for-each Элемент используется для многократной обработки набора выбранных узлов. В атрибуте select задается выражение XPath, позволяющее отобрать необходимые узлы. После того как узлы выбраны, для каждого из них выполняются операторы, указанные в элементе xsl:for-each:

<xsl:for-each select="Контрагенты/Контрагент"> <tr> <td><xsl:value-of select="Код"/></td> <td><xsl:value-of select="Наименование"/> </td> </tr></xsl:for-each>

В выходной HTML-документ выводится таблица, содержащая столь-ко строк, сколько элементов <Контрагент> содержит родительский тег <Контрагенты>

xsl:sort Элемент используется для сортировки xml-тегов. Элемент должен размещаться внутри элементов xsl:apply-templates или xsl:for-each. Для задания атрибута или элемента, по которому выполняется сортировка, используется атрибут select. Для определения порядка сортировки используется атрибут order:

<xsl:for-each select="Контрагенты/Контрагент"><xsl:sort select="Наименование" order="ascending"/> <tr> <td><xsl:value-of select="Код"/></td> <td><xsl:value-of select="Наименование"/> </td> </tr></xsl:for-each>

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


67


xsl:import Позволяет повторно использовать шаблоны, определенные в других таблицах стилей. Записывается в корневом элементе xsl:stylesheet. Элементов xsl:import может быть несколько:

xsl:import href="URI Адрес Внешнего XSLT"/>

XSLT-процессор отыскивает внешнюю таблицу стилей и подставля-ет ее на место элемента xsl:import перед преобразованием.Если правила преобразования из внешних файлов XSLT конфликту-ют с правилами, определенными в самой таблице стилей, то при-меняются те правила, которые записаны последними, поэтому важен порядок записи элементов xsl:import в таблицу стилей

xsl:include Позволяет повторно использовать шаблоны, определенные в дру-гих таблицах стилей:

<xsl:include href="URI Адрес Внешнего XSLT"/>

Его можно записать не только в корневом элементе xsl:stylesheet, но и в любом месте таблицы стилей. Порядок записи элементов xsl:include в таблице стилей не имеет значения

Втабл.2.14представленывыраженияXPath,используемыевка-чествезначенийатрибутовmatchиselect.

Таблица 2.14

Выражения XPath, используемые в качестве значений атрибутов match и select

Выражение XPath Описание/ Корневой узел. Текущий узел. Может быть записано как self::node () .. Родительский узел текущего узла. Может быть записано

как parent::node () Products Узел ProductsProducts / Product1 Подузел Product1 узла ProductsProduct/* Все потомки узла Product/Product Узел Product, являющийся прямым потомком корневого

узла@name Атрибут name текущего узла@* Все атрибуты текущего узлаProduct @ Price Атрибут Price узла ProductProducts / Product @ Price Атрибут Price узла Product, являющегося подузлом узла

Products..@ Price Атрибут Price родительского узла// Любое количество промежуточных узлов


68

Выражение XPath ОписаниеProducts // Product Все узлы Product, имеющие предка Products| Знак разделения конкретных узловProduct | Product2 Узел Product1и узел Product2[] Предикатное выражениеProducts [Product] Узел Products, имеющий потомка ProductProducts [Products="qq"] Узел Products, имеющий потомка Product, значение

которого равно qqProduct [@Price] Узел Product, имеющий атрибут PriceProduct [@Price ="5"] Узел Product, имеющий атрибут Price, значение которо-

го равно 5count (Product/*) Количество потомков узла Productname () Имя текущего узла

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

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

<Order> <date>01/11/2013</date> <OrderNumber>4554654</OrderNumber> <Customer> <Id>123</Id> <Name>Smith</Name> </Customer> <OrderItems> <Item> <Quantity>10</Quantity> <ItemNo>444</ItemNo> <Discription>IPhone</Discription> </Item> <Item> <Quantity>20</Quantity> <ItemNo>555</ItemNo> <Discription>IPad</Discription> </Item> </OrderItems></Order>


69

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

<?xml version="1.0" encoding="utf-8"?><OrderItems> <OrderItem> <date>01/11/2013</date> <OrderNumber>4554654</OrderNumber> <CustomerID>123</CustomerID> <Quantity>10</Quantity> <ItemNo>444</ItemNo> <Discription>IPhone</Discription> </OrderItem> <OrderItem> <date>01/11/2013</date> <OrderNumber>4554654</OrderNumber> <CustomerID>123</CustomerID> <Quantity>20</Quantity> <ItemNo>555</ItemNo> <Discription>IPad</Discription> </OrderItem></OrderItems>

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

Рис. 2.5. Преобразование данных

70

Одним из способов подобного преобразования является ис-пользованиепреобразованияXSLT.СледующийXSLT-кодвы-полнитпреобразованиеисходногоXML-документавтребуемыйформат:

<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/ XSL/Transform" xmlns:msxsl="urn: schemas-microsoft-com:xslt" exclude-result-

prefixes="msxsl"> <xsl:output method="xml" indent="yes"/> <xsl:template match="Order"> <OrderItems> <xsl:apply-templates select="OrderItems/Item"/> </OrderItems> </xsl:template> <xsl:template match="Item"> <OrderItem> <date> <xsl:value-of select="parent::node()/

parent::node()/date"/> </date> <OrderNumber> <xsl:value-of select="parent::node()/

parent::node()/OrderNumber"/> </OrderNumber> <CustomerID> <xsl:value-of select="parent::node()/

parent::node()/Customer/Id"/> </CustomerID> <xsl:apply-templates select="*"/> </OrderItem> </xsl:template> <xsl:template match="*"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template></xsl:stylesheet>

Преобразованиенаходитвисходномдокументекорневойэле-ментOrder,послечегосоздаеткорневойэлемент<OrderItems>иначинаетобрабатыватьвсеэлементы<Item>,найденныевнутри

71

элемента<OrderItems>.Длякаждогоизэлементов<Item>созда-етсяновыйшаблон,которыйкопируетэлементыdate,OrderNumberиCustomerIDизэлементаOrderисходногодокумента,находящегосянадвауровнявыше,иприсоединяеткнимвсеостальныеэлементы,вложенныевItem.

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

2.4.8. Web-сервисы

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

Web-сервисымогутвыполнятьдвавидафункций:1)обменданнымимеждуразличнымикомпонентамираспреде-

леннойсистемыилинесколькимивзаимодействующимиприложе-ниями;

2)предоставлениеразнообразныхсервисов(выполнениеразлич-ныхбизнес-функций).

Понятие Web-сервиса и его характеристики

Web-сервисы—этопрограммныекомпоненты,взаимодействиескоторымиосуществляетсяпосетиИнтернетсиспользованиемоткрытыхпротоколов[14,13,25,34,23].

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

72

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

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

КроссплатформенностьтехнологииWeb-сервисовобеспечива-етсяXML-форматомихописанияиXML-форматомсообщений,отправляемыхиполучаемыхWeb-сервисами.

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

Такимобразом,Web-сервисобладаетследующимихарактери-стиками:

� поддерживаетединыеметодыобращениякнему;� интерфейсWeb-сервисанезависитотплатформы;� способывнутреннейреализацииWeb-сервисаобычнонеизвест-

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

�Web-сервисявляетсяповторноиспользуемымкомпонентом.Несмотрянаточтоназвание«Web-сервис»подразумеваетис-

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

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

73

Следуетпонимать,чтопостроениеинтеграционногорешениянаосновеWeb-сервисовневсегдаявляетсяоптимальнымреше-нием. Главными недостатками Web-сервисов являются мень-шая производительность и больший размер сетевого трафикапосравнениюстакимитехнологиями,какRMI,CORBA,DCOM,засчетиспользованиятекстовыхXML-сообщений.ТехнологиюWeb-сервисовцелесообразноприменятьдляобъединениякомпо-нентов,работающихвраспределеннойсреденаразличныхплат-формахиливтомслучае,еслипотребительWeb-сервисазаранеенеизвестен.

Классификация Web-сервисов

КлассификацияWeb-сервисовможетбытьвыполненанаосновеследующихкритериев[19]:

� потипувзаимодействиясклиентом;� потипуклиентаWeb-сервиса;� помоделиобработкизапросаWeb-сервисом.

Наосновемоделиобработкиклиентскогозапросавыделяютсле-дующиетипыWeb-сервисов:

� метод-ориентированные;� документ-ориентированные;� ресурс-ориентированные.

Метод-ориентированные Web-сервисы(илиRPC-Web-сервисы)—этоWeb-сервисы,взаимодействиескоторымипроизводитсяпопро-токолуSOAP(SimpleObjectAccessProtocol)сиспользованиемXML-сообщений.Интерфейсметод-ориентированныхWeb-сервисовописанвформатеWSDL.Такоеописаниеинтерфейсасервисаобес-печиваетавтоматическуюгенерациюкода,необходимогодлясвязиссервисом,насторонеклиента.SOAP-протоколможетиспользоватьразличныетранспортныепротоколы(HTTP,FTP,SMTP).SOAP-сообщения,участвующиевобменемеждуклиентомиWeb-сервисом,имеютстрогоопределеннуюструктуруипередаютимяипараметрыудаленновызываемойпроцедуры,атакжерезультатвызова.

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

74

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

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

Ресурс-ориентированные Web-сервисы—этоRESTful-Web-сер-висы,предоставляющиедоступкудаленнымресурсамспомощьюHTTP-запросов.СервисыданноготипаоснованынаархитектуреREST(RepresentationalStateTransfer)иобеспечиваютвзаимодейст-виесудаленнымиресурсами,передаваяклиентуихпредставление.RESTful-Web-сервисыподдерживаютчетыреоперации—GET,PUT,POSTиDELETE,спомощьюкоторыхпроизводятсязапрашиваемыеклиентомдействиясресурсами.ТехнологияRESTWeb-сервисовтакжеможетиспользоватьWSDL-описаниеиSOAP-протоколдляпередачисообщений,номожетобходитьсяибезних.

АрхитектураRESTупрощаетанализклиентскогозапроса,по-сколькуHTTP-методызапросанапрямуюсвязываютсясоперациямиWeb-сервиса.Недостатоктехнологиизаключаетсявнебольшомколичестведоступныхоперацийиограничении«одинресурс—одинURL-адрес».

Спецификация WSDL

СпецификацияWSDL(WebServiceDefinitionLanguage)опреде-ляетязыкописаниясервисаиобеспечиваетспособописаниятех-ническойинформацииоWeb-сервисеиегоинтерфейсе,включаяимяиадрессервиса,способипротоколвзаимодействияссервисом,форматысообщений,функциональностьсервиса.Внастоящиймо-ментсуществуютспецификацииWSDL1.1иWSDL2.0.Подробнееоспецификацияхсм.[14].

75

Протоколы передачи данных

Дляобеспечениякроссплатформенностисервисазапрос,посылае-мыйклиентомWeb-сервису,иответ,которыйсервисвозвращаетинициаторузапроса,представляетсобойсообщениеXML-формата.SOAP(SimpleObjectAccessProtocol)—этопротоколобменасооб-щениямивраспределеннойсреде,тоестьсоглашениеоструктуредокументов,участвующихвобменесообщениями.SOAP-протоколможетиспользоватьсяповерхразнообразныхтранспортныхпро-токоловдляпередачисимвольнойидвоичнойинформации.Вна-стоящиймоментсуществуютспецификацииSOAP1.1иSOAP1.2.Подробнееопротоколесм.[13].

Типы взаимодействия с клиентом

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

Врамкахсинхроннойиасинхронноймоделеймогутбытьреа-лизованыследующиесценариивзаимодействияклиентасWeb-сервисом[23]:

� однонаправленныйзапрос—клиентпосылаетсообщениеодномуили нескольким Web-сервисам, которые его обрабатывают, нонегенерируютответ;

� синхронныйзапрос-ответ—синхронныйобменсообщениямимеждуклиентомиWeb-сервисом;

� асинхронныйзапрос-ответ—асинхронныйобменсообщениямимеждуклиентомиWeb-сервисом;

�RPC-вызов—клиентвызываетпроцедуруинтерфейсаWeb-сервисапутемсериализациипараметровпроцедурывсообщениеиотправкиегоWeb-сервису;

� сообщениеобошибке—вслучае,есливыполнениепроцедурыинтерфейсаWeb-сервисазавершаетсясошибкой,клиентполучаетсообщениеобошибке;

76

� запроссподтверждением—клиентполучаетотWeb-сервисасообщениеобуспешнойилинеуспешнойдоставкезапроса;

� передачачерезпосредников—клиентскоесообщениепереда-етсяцелевомуWeb-сервисучерезпосредников(промежуточныеWeb-сервисы);

� кеширование—вслучаесхожегоклиентскогозапросаответемупосылаетсяизкеша;

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

Клиенты Web-сервисов

Клиентами,пользующимисяуслугамиWeb-сервисов,могутбытьприложениядвухтипов:

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

2)программныекомпоненты,автоматическисовершающиезапроскWeb-сервису(безучастияпользователя).

Репозитории Web-сервисов

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

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

Наиболеераспространеннымистандартамидлясозданиякорпо-ративныхреестровявляютсяUDDI,ebXMLиDISCO.

UDDI(UniversalDiscription,DiscoveryandIntegration)—стан-дартдлясозданияплатформонезависимого,основанногонаXMLреестраWeb-сервисов,позволяющегопубликоватьинаходитьихWSDL-описание.UDDI-реестрхранитинформациюопоставщиках,функциональностиидеталяхреализацииWeb-сервисов.

77

UDDI-реестрлогическиразделеннатритипакаталогов:1)белыестраницы—содержатинформациюопоставщикахWeb-

сервисов(имяпоставщика,описание,контактнаяинформация);2)желтыестраницы—классифицируютWeb-сервисыпосферам

применения;3)зеленыестраницы—содержатинформациюодеталяхреали-

зацииWeb-сервисов,необходимуюдлядоступакним.ДанныекаталоговхранятсяввидеXML-файлов,структурако-

торыхопределяетсямодельюданныхUDDI.КаждыйXML-файлсданнымиимеетуникальныйUDDI-идентификаториструктуру,определяемуюXML-схемами.АдминистрированиеUDDI-реестровосуществляетсяспомощьюспециальныхприложенийUDDI-сер-веров,которые,посути,представляютсобойнаборWeb-сервисовдляпоиска,публикации,храненияирепликацииданныхреестра.ПримеромUDDI-серверасоткрытымисходнымкодомявляетсяhttp://ws.apache.org/juddi.

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

ebXML-реестрможетбытьсозданкакдляотдельнойкорпорации,такидляпредприятийотдельнойотрасли.ПримерыреализациитехнологииebXMLможнонайтинаофициальномсайтепроектаhttp://www.ebxml.org.

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

Обобщеннаясхемавзаимодействияпоставщикасервиса,клиентасервисаирепозиториясервисовпредставленанарис.2.6.

78

2.4.9. Оркестровка и хореография Web-сервисов

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

Существуетдваподходакописаниюбизнес-процессовиинтег-рацииWeb-сервисов—этооркестровкаихореография.

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

Хореография Web-сервисов —этоописаниеглобальногобизнес-процесса,вкоторыйвовлеченынесколькоучастников(например,

Рис. 2.6. Взаимодействие поставщика и клиента Web-сервиса с репозиторием сервисов

79

разныекомпании),обменивающихсясообщениямисцельюдости-женияобщегобизнес-результата.Вданномслучаенетребуетсяцентральныйкоординатор,таккаккаждыйучастниквзаимодейст-вияобладаетинформациейотом,когдавыполнятьсвоиоперацииискакимвнешнимWeb-сервисомтребуетсявзаимодействовать.Хореографияпозволяетописатьбизнес-процесскаксовместноедействиенесколькихучастников,каждыйизкоторыхзнаетвнемсвоюроль.ХореографияWeb-сервисовможетбытьреализовананабороморкестровок.Различиямеждуоркестровкойихореогра-фиейиллюстрируютрис.2.7,2.8[27].

Рис. 2.7. Оркестровка сервисов

Рис. 2.8. Хореография сервисов

80

ДляпроектированияSOA-сценариявзаимодействияинформа-ционнойсистемынеобходимополучитьформальноеописаниебиз-нес-процессовиописаниеихсвязисWeb-сервисами.Описаниябизнес-процессоввконтекстетехнологииWeb-сервисоввыполня-етсясиспользованиемязыковWS-BPEL(WebServicesBusinessProcessExecutionLanguage)иWS-CDL(WebServicesChoreographyDiscriptionLanguage).

Язык WS-BPEL

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

XML-описаниебизнес-процесса,какправило,создаетсяспомощьюBPEL-визуальногоредактора,азатемисполняетсяBPEL-сервером.ЯзыкWS-BPELподдерживаетсяразличнымисерверамиисреда-миразработки(WebLogic,Eclipse,OracleBPELProcessManager,OracleApplicationServer,WebSphere,MicrosoftWindowsWorkflowFoundationидр.).

РазличаютабстрактноеиисполняемоеBPEL-описания.Абстракт-ноеBPEL-описаниеиспользуетсянапервоначальномэтаперазра-боткиBPEL-процессаиописываетбизнес-процессчастично,безизлишнейдетализации.ИсполняемоеBPEL-описаниеполностьюдекларируетпроцессипредназначенодлявыполненияBPEL-сер-вером.

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

Примеры структурных и базовых действий представленывтабл.2.15.

Сполнойспецификациейязыкаможноознакомитьсянасайтераз-работчикастандартаOrganizationfortheAdvancementofStructuredInformationStandards(OASIS)[10].

81

Таблица 2.15

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

BPEL-действия Описание

Структурные BPEL-действия

Sequence Содержит действия, выполняемые последовательно

If Задает условия, для которых выполняются вложенные действия

while Условие повторения вложенного действия

Pick Выполняет действие при получении сообщения, связанного с действием

Flow Обеспечивает параллельное и синхронизированное выполнение действий

For Each Циклически повторяет действия

Базовые BPEL-действия

Invoke Вызов Web-сервиса

Receive Получение сообщения от бизнес-партнера

Reply Посылает ответ после получения сообщения от партнера

wait Определяет задержку BPEL-процесса

exit Завершает экземпляр BPEL-процесса

Язык WS-CDL

WebServicesChoreographyDescriptionLanguage(WS-CDL)—этоXML-языкдляописаниявзаимодействияотдельныхсервисовмеждусобой(хореографиисервисов).Языкописываетнаборыпра-вилдляопределенияпорядкаобменасообщениямимеждубизнес-партнерами.

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

Полнуюспецификациюязыкаможнонайтинасайтеконсорциумаwww.w3.org[11].

Глава 3Проектирование

интеграционных решений

3.1. Подход, основанный на использовании шаблонов

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

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

Шаблонвыполняетрольреферентноймоделиипредставляетсобойабстрактноеописаниетиповойзадачииспособовеерешения.

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

83

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

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

Шаблоныинтеграциипомогаютсистематизироватьзнаниявоб-ластиинтеграцииинформационныхсистем.

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

� IntegrationPatternsоткомпанииMicrosoft[7];� Patterns:ImplementinganSOAUsinganEnterpriseServiceBus.

IBM[3].Единственный источник на русском языке — книга Г.Хопа

иБ.Вульфа«Шаблоныинтеграциикорпоративныхприложений»(2007);внейдетальнорассматриваютсявсеаспектытолькоодногостиляинтеграции—обменасообщениями[6,33].

Но,какправило,описаниешаблонастроитсяизследующихэле-ментов:

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

данногошаблона;� возможныепроблемы—описаниетиповыхпроблем,возникаю-

щихприреализацииданногостиляинтеграции;� примерреализациишаблона,описаниевариантатехнического

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

панииMicrosoft,которыепредставляютсянаиболееуниверсальнымииохватываюттакиеаспектыинтеграцииприложений,как:

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

84

Общаяклассификацияшаблоновинтеграциииихвзаимосвязьсосновнымихарактеристикамиинтеграционныхрешенийпред-ставленывтабл.3.1.

Таблица 3.1

Общая классификация шаблонов интеграции

Шаблоны интеграции

Цель интеграцииШаблоны архитектуры промежуточного слоя

Единое представление корпоратив-ных данных

Агрегация сущностей

Распределенный бизнес-процесс Интеграция процессов

Единая точка доступа к данным из не-скольких источников

Интеграция, ориентированная на портал

Уровень связывания приложений

Шаблоны связывания приложений

База данных Интеграция данных

Уровень бизнес-логики Функциональная интеграция

Уровень пользовательского интер-фейса

Презентационная интеграция

Способ взаимодействия приложений

Шаблоны топологии интеграционного решения

Взаимодействие «один-к-одному» Точка-точка

Взаимодействие через центральный «коммутатор»

Брокер сообщений

Открытое взаимодействие Шина сообщений

Взаимодействие «один-ко-многим» Публикация-подписка

Вдальнейшеммыболееподробнорассмотримшаблоныкаждойгруппы.

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

85

Рис. 3.1. Иерархия шаблонов

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

3.2. Архитектура промежуточного слоя

Сточкизренияархитектурыинтеграционногорешенияможновыделитьтрибазовыхшаблонапромежуточногослоя1[7]:

� агрегациясущностей(EntityAggregation);� интеграцияпроцессов(ProcessIntegration);� интеграция,ориентированнаянапортал(PortalIntegration).

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

86

Основные характеристики базовых шаблонов представленывтабл.3.2.

Таблица 3.2

Основные характеристики базовых шаблонов

Шаблон промежуточного слоя

Решаемая проблема

Агрегация сущностей Как приложениям эффективно использовать данные, рас-пределенные между несколькими репозиториями

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

Портал-ориентированная интеграция

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

3.2.1. Агрегация сущностей

Агрегациясущностей—наиболеедоступный,апоэтомуинаиболеераспространенныйвидинтеграции.

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

Задачаосложняетсятем,что:� корпоративныесистемы,какправило,используютразныеин-

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

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

� дажеприотсутствиисемантическихразличийвозможнонесов-падениеданныхдляодногоитогожеэкземплярасущности(напри-

87

мер,адресодногоитогожеклиентавсистемеоформлениязаказаиадресвCRM-системеразличаются);

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

репозиториямиможетбытьнарушенассылочнаяцелостность;� приложение-потребительможетзатребоватьданные,хранящиеся

вразныхрепозиториях.Решениемявляетсясозданиепромежуточногослоя,обеспечи-

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

Рис. 3.2. Агрегация сущностей

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

1)определениеединойврамкахпредприятиямоделиданных,котораяобеспечитунифицированноепредставлениесущностей;

2)установлениефизическихсвязеймеждукомпонентамиинтег-рационногорешения.

Вразныхрепозиторияхиспользуютсяразныесхемыданныхдляоднойитойжесущности.Задачапромежуточногослоя—гармо-низироватьразличиямеждуэтимисхемами.Промежуточныйслойдолжен:

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

используемыхнесколькимиприложениями;� поддерживатьтрансформациисхемкаждогоисточникаданных

вканоническуюсхемуданных.

88

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

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

Рис. 3.3. Каноническая схема данных

89

Существуютдвабазовыхархитектурныхподходакинтеграцииинформации:

1)репликацияданных;2)федерацияинформации.Рассмотримихболееподробно.

Репликация данных

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

Технологиярепликацииориентировананаобработкуоченьболь-шихобъемовданных.

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

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

� хорошаямасштабируемостьрешений;� наличиечеткойметодологииинтеграции;� асинхронныйобменданными;� отсутствиенеобходимостиизмененийвинтегрируемыхинфор-

мационныхсистемах;� эффективныйдоступкинтегрируемымданнымзасчетотделения

приемникаотисточника;� слабаясвязьмеждуинтегрируемымисистемами;� возможностьповторногоиспользованияобъектовипреобразо-

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

классаmiddleware).

Рис. 3.4. Репликация данных

90

Федерация информации

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

Рис. 3.5. Федерация информации

Достоинствамифедерацииинформацииявляются:� возможностьинтеграцииструктурированныхинеструктури-

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

менаинформацией;� наличиедоступныхинструментов(программногообеспечения

классаmiddleware).Втабл.3.3проводитсясравнениедвухподходовкинтеграции

данных.

91

1Таблица 3.3

Сравнительная характеристика подходов к интеграции данных

Критерий сравнения Репликация Федерация

Поток данных В одну сторону — от источника к приемнику

В обе стороны

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

В момент запроса; управляется запросом SQL

Задержка День-неделя-месяц Реальное время

Преобразование, очистка, использование метаданных в процессе

Лучшее; обычно высокая сте-пень повторного использования объектов и процессов

Среднее; преобразования встроены в представления и объекты базы данных

Транспорт FTP, прямое соединение с базой данных

Прямое соединение с базой данных

Объемы обрабатывае-мых данных

Очень большие (миллионы записей)

Средние (сотни тысяч удаленных записей)1

Сложность преобразо-ваний

Любая Преобразования, которые можно описать на SQL

Поддержка мониторинга событий

Ограниченная; можно улучшить с помощью технологии захвата изменений в источнике

Зависит от возможностей триггеров в источнике

Контроль потоков работ По расписанию; обработка ошибок

Нет

Взаключениеперечислимосновныепреимуществаинедостаткиданногостиляинтеграции(табл.3.4).

Таблица 3.4

Преимущества и недостатки агрегации сущностей

Преимущества Недостатки

Обеспечивает унифицированное представ-ление основных корпоративных (отрасле-вых) данных

Облегчает доступ к информации

Уменьшает семантический диссонанс между существующими приложениями

Создает дополнительный архитектурный слой

Требует консенсуса между подразделени-ями (организациями) по вопросу унифици-рованного представления данных

Требует подключения существующих приложений к промежуточному слою

1Различия,связанныесобъемамиданных,нивелируютсяпомереразвитиятехнологииBigdata.

92

3.2.2. Интеграция процессов

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

Вкачествепримерарассмотримпроцессобработкизаказаклиентагипотетическойторговойкомпанией.

Пустьобработказаказавключаетследующиедействия:� проверкафинансовогодосьеклиента(еслиуклиентаостались

неоплаченныесчета,тоновыйзаказотклоняется);� проверканаличиятоваранаскладе(еслитоваротсутствует,

тозаказотклоняется);� определениеадресадоставкиивыставлениесчета(выполняется,

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

ставленанарис.3.6.

Рис. 3.6. Обработка заказа

93

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

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

Говоряобинтеграциипроцессов,следуетиметьввидуследующее:� дляреализациираспределенногобизнес-процессаоднаинформа-

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

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

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

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

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

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

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

94

Рис. 3.7. Интеграция бизнес-процессов

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

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

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

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

Вобобщенномвиденазначениекомпонентовуправленияраспре-деленнымибизнес-процессамирассмотреновтабл.3.5.

Таблица 3.5

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

Компонент Назначение

Модель процесса Определяет последовательность шагов для выполнения бизнес-функции

Компонент управления рас-пределенным бизнес-про-цессом (Рrocess manager)

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

Приложение Выполняет определенную бизнес-функцию

95

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

Рис. 3.8. Иерархическая интеграция бизнес-процессов

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

� умениесоотноситьсообщения,получаемыеотвнешнихсистем/передаваемыевнешнимсистемамсэкземпляромбизнес-процесса,длякоторогоонипредназначены;

� поддержкараспределенныхвовременитранзакций;� обработкаошибок,возникающихнаразличныхэтапахвыпол-

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

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

96

Интеграциюбизнес-процессовцелесообразноиспользоватьдляускорениявыполненияпоследовательностизадач.Вфинансовойиндустрииширокуюпопулярностьполучилаконцепциясквозной не-прерывной обработки (STP,StraightThroughProcessing),означающаяпроцесснепрерывной,полностьюавтоматизированнойобработкиинформации.Концепциявозниклавконце1990-хгг.дляописанияоборотаценныхбумагисегодняявляетсястратегическимнаправ-лениемразвитияавтоматизированнойинформационнойсистемыучастникафинансовогорынка.


Таблица 3.6

Преимущества и недостатки интеграции процессов


Возможность моделировать бизнес-про-цесс независимо от реализации бизнес-функций

Обеспечение соблюдения правил выполне-ния бизнес-процесса

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

Быстрая адаптация к любым бизнес-тре-бованиям

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

Возможное падение производительности из-за слишком большого числа параллель-но выполняемых процессов

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

3.2.3. Интеграция, ориентированная на порталы

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

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

97

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

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

Корпоративныйпорталкакинтеграционноерешениецелесооб-разноиспользоватьвтомслучае,если:

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

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

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

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

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

Рис. 3.9. Портал-ориентированная интеграция

98

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

� «толькодлячтения»—позволяютпользователютолькопро-сматриватьданныеразличныхприложений.Данныепокаждо-му приложению располагаются обычно в отдельных областяхэкрана;

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

� «интерактивные»—поддерживаютограниченноевзаимодействиемеждуобластямиэкрана,относящимисякразнымприложениям.Например,выборэлементавспискеоднойобластиприводиткпред-ставлениюопределеннойинформациивдругой.Привыбореклиентавобласти1(поданнымCRM-системы)вобласти2отображаетсяегофинансовоедосье(поданнымфинансовойсистемы).


Таблица 3.7

Преимущества и недостатки интеграции, ориентированной на порталы


Оказывает минимальное влияние на интег-рируемые системы

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

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

Неэффективен (по сравнению с интеграций процессов), так как предполагает участие пользователя на этапе принятия решения

Существует риск совершения ошибки пользователем

99

3.3. Способы связывания приложений

Архитектурапрактическилюбогоприложенияможетбытьпред-ставленатремялогическимиуровнями:

1)уровнемпредставления—этоуровеньпользовательскогоин-терфейса,предназначенныйдляпросмотра,вводаикорректировкиданных,отправкинавыполнениезапросовконечнымипользовате-лямиприложения;

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

3)уровнемданных—уровень,отвечающийзаорганизациюдоступакданнымиработусбазойданных,этоуровеньсерверовбазданных.

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

1)интеграциянауровнеданных—впромежуточныйслойпосту-паютданныеизбазыданных;

2)функциональнаяинтеграция—промежуточныйслойинтег-рируетсясуровнембизнес-логикипосредствомAPI-интерфейсовисервисов,предоставляемыхприложением;

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

3.3.1. Интеграция данных

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

Интеграциюприложенийнауровнеданныхиллюстрируетрис.3.10.

100

Рис. 3.10. Интеграция приложений на уровне данных (базовый шаблон)

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

Перечислимосновныепроблемы,возникающиеприинтеграцииданных:

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

� неоднородностьисточниковданныхналогическомуровне—неоднородностьиспользуемыхмоделейданныхдляразличныхисточников;

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

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

101

передачиданных,форматами,структурамииобъемамистановитсявсеболеенетривиальной;

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

� возрастают проблемы с качеством данных. Бизнесу нужныдостоверныеданные,апотомунеобходимыинструментыаудита,мониторингаиочисткиданных.

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

Стехническойточкизренияинтеграциянауровнеданных—этосамыйпростойтипинтеграции,которыйможетбытьреализованс использованием FTP, командных файлов, различных утилитСУБД,ETL-инструментовиспециальныхсервисовинтеграцииданных.

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

Выделяюттрибазовыхшаблонасвязыванияприложенийнауров-неданных:

1)файловыйобмен;2)общаябазаданных;3)копированиеданных.

Файловый обмен

Файловыйобмен—этонаиболеепростойиисторическипервыйспособобменаданнымимеждуприложениями.

Технологияосновананатом,чтоодноприложениесохраняет(экспортирует)данныевфайл,адругое—читает(импортирует)

102

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

Схемафайловогообменапредставленанарис.3.11.

Рис. 3.11. Файловый обмен

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

� необходимовыработатьсоглашениеобобщемформатефайлов(xml,txt,xls,…).Задачапреобразованияданныхвнеобходимыйформатвозлагаетсянамодулиимпорта/экспорта;

� приложениядолжныиспользоватьобщеесоглашениеоправилахименованияирасположенияфайлов;

� приложение,создающеефайл,должнообеспечитьуникальностьегоимени;

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

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

� долженбытьиспользованмеханизмудаления/архивированиястарыхфайлов.

Преимущества и недостатки файлового обмена рассмотренывтабл.3.8.

103

Таблица 3.8

Преимущества и недостатки файлового обмена


Универсальный способ для всех операци-онных систем, поддерживается любыми языками программирования

Не нужны сведения о внутренней реализа-ции приложения; основная задача — прео-бразование форматов файлов

Обеспечивает слабое связывание прило-жений

Нет потребности в специализированном связующем дорогостоящем программном обеспечении

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

Нерациональное использование ресурсов при слишком частой работе с файлами

Общая база данных

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

Рис. 3.12. Общая база данных

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

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

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

104

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

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

Преимуществаинедостаткиобщейбазыданныхперечисленывтабл.3.9.

Таблица 3.9

Преимущества и недостатки общей базы данных


Решается проблема семантического диссонанса для нескольких прило-жений

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

Есть программы (коммерческое программное обеспечение), которые работают со встроенной базой данных (работает только со встроенной схемой данных)

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

Доступ к базе данных по медленным линиям связи

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

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

Низкий уровень абстракции; приложения работа-ют не с логическими объектами, а с конкретными полями и записями

105

Копирование данных

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

Рис. 3.13. Копирование данных

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

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

Возможнытриосновныхсценариякопированияданных[19]:1)одиниздатель,многоподписчиков—существуетцентральная

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

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

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

106

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

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

� допустимаязадержкавобновленииданных—время,втечениекоторогоподписчикможетобходитьсябезсвежейкопииданных;

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

Преимуществаинедостаткикопированияданныхрассмотренывтабл.3.10.

Таблица 3.10

Преимущества и недостатки копирования данных


Механизмы репликации поддерживаются встроенными функциями всех промышлен-ных СУБД

Достаточным условием для копирования данных между СУБД различных производи-телей (гетерогенная репликация) является совместимость с OLE DB

Задержка обновления данных

Доступ к базе данных по медленным лини-ям связи

Необходимость в разрешении конфлик-тов, возникающих при изменении одной и той же записи в разных копиях базы данных

3.3.2. Функциональная интеграция

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

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

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

107

граммирования(библиотекиС++,С#,Javaидр.).Программныеинтерфейсыобычнонезависимыотмоделиданныхприложенияиболеестабильны,чемпользовательскийинтерфейс.Еслимодельданныхможетпретерпеватьизмененияскаждойновойверсиейпрограммногообеспечения,тонаборAPIдляобеспеченияобратнойсовместимостиобычнопредоставляетсяразработчикамиинформа-ционнойсистемы.

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

Длясвязыванияприложенийнауровнебизнес-логикинеобходимовыполнениедвухусловий:

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

Рис. 3.14. Шаблон функциональной интеграции

108

2)возможенудаленныйдоступкпрограммномуинтерфейсу,ин-капсулирующемунужнуюбизнес-функцию.

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

1)использованиераспределенныхобъектов;2)интеграция,ориентированнаянасообщения;3)сервис-ориентированнаяинтеграция.

Использование распределенных объектов

Данныйтипинтеграцииоснованнастандартахобъектно-ориен-тированноговзаимодействия(см.п.1.3)ииспользуеттакиетех-нологии,как.NETremoting,COM+илиCORBA.Объектыодногоприложениявзаимодействуютсобъектамидругогоприложения,используямеханизмвиртуализации.Преимуществаинедостаткифункциональнойинтеграцииприведенывтабл.3.11.

Таблица 3.11

Преимущества и недостатки функциональной интеграции


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

Целесообразно использовать, если необхо-димо обеспечить интеграцию приложений в режиме реального времени

Сильное связывание приложений

Сложная модель взаимодействия прило-жений

Плохо масштабируемые решения

Не все технологии обеспечивают межплат-форменное взаимодействие

Сложности поддержки

Интеграция, ориентированная на сообщения

Данныйспособсвязыванияприложенийиспользуетпромежуточ-ноепрограммноеобеспечение(системуобменасообщениями),ориен-тированноенапосылкусообщений.Обменсообщениямипозволяетналадитьасинхронноевзаимодействиемеждуслабосвязаннымиприложениямиигарантируетдоставкусообщенийототправителякполучателю[9,24,28].

Основнымипонятиямитехнологииобменасообщениямиявляются:1)сообщение—наименьшаяединицаданных,котораяможетбыть

переданаототправителякполучателю;

109

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

Процессобменасообщениямимеждуприложениямивключаетследующиеэтапы:

1)создание—отправительсоздаетсообщение,содержащеепо-лезнуюинформацию;

2)отправка—отправительпомещаетсообщениевканал;3)доставка—системаобменасообщениямидоставляетсообщение

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

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

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

Примерамипромежуточногопрограммногообеспечения,реали-зующегосервисыобменасообщениями,являютсяMicrosoftMessageQueuing,IBMMQSeries,SunJavaSystemMessageQueue.Этисисте-мыпозволяютвыполнятьследующиеоперациипоиспользованиюочередей:

� добавитьсообщениевочередь;� взятьпервоесообщениеизочереди;

110

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

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

Рис. 3.15. Система обмена сообщениями

Преимуществаинедостаткитехнологииобменасообщениямипредставленывтабл.3.12.

Таблица 3.12

Преимущества и недостатки технологии обмена сообщениями


Время функционирования сервера может быть не связано со временем работы клиентов (не требуется одновременная доступность отправителя и получателя)

Гарантированная доставка сообщений от отправителя к получателю

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

111


Обеспечивается частный обмен неболь-шими порциями данных (синхронизация данных приложений)

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

Сообщения могут быть преобразованы во время передачи без уведомления отправителя и получателя (независимость промежуточной среды от средства разра-ботки компонентов и используемого языка программирования)

Слабое связывание соединяемых прило-жений

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

Возможны задержка при доставке инфор-мации, нарушение порядка сообщений

Не подходит для передачи больших объе-мов данных, снижает производительность

Сложность реализации синхронного обмена

Сервис-ориентированная интеграция

Внастоящеевремясервис-ориентированнаяинтеграция(SOA-ин-теграция)—наиболеепроработанныйсистемныйподходкрешениюпроблеминтеграцииприложений.Посути,SOA-интеграциястираетграньмеждуинтеграциейприложенийисозданиемраспределен-ногокомпонентногоприложения.ВстандартеReferenceModelforServiceOrientedArchitecture1.0консорциумаOASIS(OrganizationfortheAdvancementofStructuredInformationStandards)даноследую-щееопределениеSOA[8]:«SOA—этопарадигмадляорганизацииииспользованияраспределенныхвозможностей,которыемогутнаходитьсявразличныхобластяхсобственности».

ЦентральныепонятияSOA-интеграции—«сервис»и«процесс».Сервис—этофункция,являющаясячеткоопределенной,само-

достаточнойинезависящейотконтекстаилисостояниядругихсервисов.


112

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

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

Схемавзаимодействияпоставщикаипотребителясервисапред-ставленанарис.3.16.

Рис. 3.16. Взаимодействие поставщика и потребителя сервиса

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

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

113

Рис. 3.17. Взаимодействие потребителя сервиса с разными типами поставщиков

Выделяютследующиефункциональныетипысервисов:� сервисыданных—содержатлогикуобработкиданныхиобес-

печиваютдоступкбизнес-данным,могутвиртуальнообъединятьданныеизнесколькихисточников;

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

� сервисыпроцессов—используютсядляуправлениябизнес-процессом,оркестровкисервисов,используемыхбизнес-процессом,мониторингасостояниябизнес-процесса;

114

� сервисывзаимодействия—обеспечиваютвзаимодействиемеждуприложениямииконечнымипользователями;

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

Сервисыипроцессывысокогоуровнякомбинируютсяизсервисовипроцессовболеенизкихуровней.Сервисынизкихуровнейреали-зуютсявнутриприкладныхинформационныхсистеморганизациилибоявляютсярезультатомихработы.SOA-интеграциябазируетсянатакихоткрытыхстандартах,какSOAP,WSDL,UDDI,WS-BPEL,WS-CDL,BPMN.

Нарис.3.18представленареферентнаяархитектураSOA-решенияоткомпанииIBM.ДоступксервисамобеспечиваетсясостороныпотребителейчерезESB1.

Рис. 3.18. Референтная архитектура SOA-решения

SOA-сценарийинтеграцииприменимдля:� крупныхтерриториальнораспределенныхкомпаний,решающих

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

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

1ПодробнееоESBсм.п.3.4.3.

115

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

� управленияпроцессами,требующимиинтенсивнойобработ-кидокументов(задачиинтеграциисистемуправленияконтентом,сСАПР,системамиуправленияпроектами,отдельнымимодулямиERP).

Преимуществаинедостаткисервис-ориентированнойинтеграциипредставленывтабл.3.13.

Таблица 3.13

Преимущества и недостатки сервис-ориентированной интеграции


SOA основана на использование стандар-тов (WSDL, BPEL, UDDI), поддерживаемых большинством поставщиков информаци-онных технологий, что обеспечивает ее независимость от платформ интегрируе-мых приложений

Исключается дублирование бизнес-функ-ций приложений

Обеспечивается слабое связывание между приложениями

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

Создание хорошо масштабируемых интег-рационных решений

Полная автономность отдельных сервисов (сервисы независимо проектируются, вер-сионируются и поддерживаются)

Независимая масштабируемость отдельных сервисов. Резкий рост нагрузки на отдель-ный сервис не «тормозит» всю систему. В SOA-системе перегружается лишь отдельный сервис, и проблема решается увеличением его мощности

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

Не подходит для эффективной работы в режиме реального времени

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

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

Сложно добиться семантической согласо-ванности информации в интегрируемых решениях

116

3.3.3. Интеграция на уровне пользовательского интерфейса

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

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

Шаблонинтеграциинауровнепользовательскогоинтерфейсапредставленнарис.3.19.

Рис. 3.19. Шаблон интеграции на уровне пользовательского интерфейса

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

117

Таблица 3.14

Компоненты интеграционного решения

Компонент Функции

Презентационный слой приложения-источника

Визуальное представление данных

Обработка введенных пользователем данных и преобразо-вание их в команды, выполняемые на уровне бизнес-логики

Эмулятор терминала Моделирует сеанс работы пользователя с презентацион-ным слоем

Обеспечивает доступ к данным экрана через API

Обеспечивает передачу команд приложения презентацион-ному слою

Приложение Использует данные приложения-источника

Генерирует команды

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

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

Преимуществаинедостаткиинтеграциипользовательскогоин-терфейсапредставленывтабл.3.15.

Таблица 3.15

Преимущества и недостатки интеграции на уровне пользовательского интерфейса


Работает с монолитными приложениями

Практически исключает риск нарушения целостности данных приложения-источника (данные защищены бизнес-логикой прило-жения-источника)

Не требует никаких изменений в приложе-нии-источнике

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

Ограниченный доступ к данным (доступны только данные, отображаемые в пользова-тельском интерфейсе)

118


Отсутствие доступа к метаданным (теряет-ся информация о типах данных, ограниче-ниях, связях, логических элементах)

Невысокая скорость (может потребоваться сбор данных из нескольких пользователь-ских форм)

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

3.4. Топология интеграционных решений

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

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

Выделяютследующиебазовыешаблонысвязыванияприложений:� «точка-точка»;� брокер;�шинасообщений.

Помимонихрассматриваетсяшаблон«публикация/подписка»(см.п.3.4.4),позволяющийпоставлятьинформациюотпоставщикакнесколькимполучателям.

3.4.1. Интеграция по типу «точка-точка»

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


119

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

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

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

Преимуществаинедостаткиинтеграциитипа«точка-точка»пред-ставленывтабл.3.16.

Таблица 3.16

Преимущества и недостатки интеграции «точка-точка»


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

Высокая стоимость поддержки интеграци-онного решения

Плохая масштабируемость (добавление новой связи «точка-точка» требует добавле-ния нового программного модуля)

Сильная связь между приложениями

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

Сложный алгоритм синхронизации данных

120

3.4.2. Брокер

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

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

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

Основнымифункциямиброкераявляются:� маршрутизация—определениеместонахождениясистемы-при-

емника;� регистрацияконечныхточек—механизм,которыйиспользуют

системыдляобнаружениядругдруга;� трансформация—процесспреобразованияданныхизформата

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

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

ПримерамиреализациипрямогоброкераявляютсяMicrosoftDistributedCommonObjectModel(DCOM),CommonObjectRequestBrokerArchitecture(CORBA),UniversalDescriptionDiscoveryandIntegration(UDDI),.NETFrameworkremoting.

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

121

непосредственномеждуклиентскимисервернымпрокси-объетамисиспользованиемсоединениятипа«точка-точка».

Вслучаенепрямогоброкераприложениеотправляетсообщениепосредникувместеслогическимименемполучателя.Брокерна-ходитполучателяипередаетемусообщение.Принципдействиянепрямогоброкерапредставленнарис.3.21.

Рис. 3.21. Принцип действия непрямого брокера

Примеромнепрямогоброкераявляетсяброкерсообщений,кото-рыйможетбытьреализовансиспользованиемпрограммногообес-печенияпромежуточногослоя(MSBizTalkServer,TIBCOBusinessIntegration).

Рис. 3.20. Принцип действия прямого брокера

122

3.4.3. Шина сообщений

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

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

Шинасообщенийпредназначенадлярешенияследующихзадач:� распределениесообщениймеждуприложениями;� конвертированиетранспортныхпротоколовмеждуприложени-

ем-источникомиприложением-приемником;� конвертированиеформатовсообщениймеждуприложением-

источникомиприложением-приемником;� управлениебизнес-событиямиразличныхисточников.

Шинасообщенийвключаеттриосновныхэлемента:1)набор согласованных схем сообщений.Стандартомформата

сообщенийявляетсяXMLсописаниемметаданныхприпомощиXMLSchema.ШинаобеспечиваетпринеобходимоститрансляциюданныхприпомощиXSLTиXQuery;

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

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

«точка-точка»,тодлясвязываниядесятиприложенийпотребуется45связей.

123

междулюбымиприложениями,подключеннымикшине.Дляот-правкисообщенийобычноиспользуетсясистемаобменасообщени-ями,котораяможетвключатьфункциональностьмаршрутизаторасообщений или поддерживать модель «публикация/подписка»(см.п.3.4.4)длярассылкисообщенийвсемполучателям.Шинасообщенийиспользуетодинизтрехвариантовмодели«публика-ция/подписка»(рис.3.22).

Рис. 3.22. Шаблон шины сообщений

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

Наиболеечастоинтеграционнаяшинаиспользуетсядлярешенияследующихзадач:

� обменсообщениямимеждуприложениями;� синхронизациясправочнойинформациимеждуразличными

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

124

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

Таблица 3.17

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


Кроссплатформенность — обеспечение взаимодействия приложений, работающих на различных аппаратных и про-граммных платформах

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

Масштабирование — возможность строить решения любого размера и нагруженности

Гибкость и адаптивность — возможность реализовывать и изменять интеграционные сценарии по бизнес-запросу

Использование открытых стандартов

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

Централизация управления и контроля — использование единых механизмов мониторинга, администрирования, модификации интеграционных процессов

Сложность реализации

Высокая стоимость

3.4.4. Интеграция по типу «публикация/подписка»

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

125

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

Всхеме«публикация/подписка»задействованытриучастника(рис.3.23):

� поставщикинформации,которогопринятоназыватьиздателем(publisher);

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

щийуправлениеподпискамииуведомлениями.

Рис. 3.23. Взаимодействие «публикация/подписка»

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

Выделяюттримеханизмафильтрации:1)темо-ориентированный механизм.Издательпубликуетсо-

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

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

126

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

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

Преимуществаинедостаткиинтеграциипотипу«публикация/подписка»рассмотренывтабл.3.18.

Таблица 3.18

Преимущества и недостатки интеграции по типу «публикация/подписка»


Пространственное разделение — под-писчики и издатели обычно не обладают информацией друг о друге

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

Асинхронное взаимодействие издателя и подписчика

Хорошая масштабируемость решений за счет отсутствия явных зависимостей между взаимодействующими сторонами

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

Невозможность подписаться на часть темы в темо-ориентированных решениях

Заключение

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

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

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

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

Библиографический список

1.Alexander et al.APatternLanguage.—Oxford,1977.

2.CORBA:[Электронныйресурс].—URL:http://www.corba.org.Датаобращения:05.10.2013.

3. Enterprise Connectivity Patterns: Implementing integrationsolutions with IBM»s Enterprise Service Bus products: [Элек-тронныйресурс].—URL:http://www.ibm.com/developerworks/webservices/library/ws-enterpriseconnectivitypatterns/index.html?S_TACT=105AGX99&S_CMP=CP.Датаобращения:10.10.2013.

4.Gamma et al.DesignPattern—ElementsofReusableObject-OrientatedSoftware.—Addison-Wesley,1995.

5.IDC.TheDigitalUniverseDecade—AreYouReady?IDC,2010:[Электронныйресурс].—URL:http://www.emc.com/digital_universe.Датаобращения:21.06.2013.

6.IntegrationPatternsOverview:[Электронныйресурс].—URL:http://www.enterpriseintegrationpatterns.com/eaipatterns.html.Датаобращения:14.09.2013.

7.IntegrationPatterns.—Microsoft,2004.

8. MacКenzie,Laskey К.,McCabe F.,Brown P.F.,Metz R.ReferenceModelforServiceOrientedArchitecture1.0,OASISStandard:[Элек-тронныйресурс].—URL:http://docs.oasisopen.org/soa-rm/v1.0.Датаобращения:12.05.2013.

9.MicrosoftMessageQueuing(MSMQ)—промежуточнаясредаобменасообщениями:[Электронныйресурс]//Microsoft.Microsoft

129

MessageQueuing(MSMQ).—URL:http://www.intuit.ru/department/se/msfdev/6/1.html.Датаобращения:13.05.2013.

10. OASIS Web Services Business Process Execution Language(WSBPEL)TC:[Электронныйресурс].—URL:http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel.Датаобра-щения:15.06.2013.

11.Takashi Кobayashi,Masato Tamaki,Norihisa Кomoda.Businessprocessintegrationasasolutiontotheimplementationofsupplychainmanagementsystems//Information&Management.—2003.—No.40.—P.769–780.

12.WorldWideWebConsortium.SOAPCurrentstatus:[Электрон-ныйресурс].—URL:http://www.w3.org/standards/techs/soap#w3c_all.Датаобращения:17.06.2013.

13.WorldWideWebConsortium.WebServicesDiscriptionLanguage(WSDL)1.1:[Электронныйресурс].—URL:http://www.w3.org/TR/wsdl.Датаобращения:17.06.2013.

14.WorldWideWebConsortium.XMLTechnology:[Электронныйресурс].—URL:http://www.w3.org/standards/xml.Датаобращения:20.06.2013.

15.Артамонов И.Современныестандартыописанияиисполнениябизнес-процессов:[Электронныйресурс].—URL:http://ecm-journal.ru/post/Sovremennye-standarty-opisanija-i-ispolnenija-biznes-processov.aspx.Датаобращения:13.06.2013.

16.Бин Д.XMLдляпроектировщиков.Повторноеиспользованиеиинтеграция.—М.:КУДИНЦ-ОБРАЗ,2004.

17.Волкова И.А.,Головин И.Г.,Карпов Л.Е.Системыпрограмми-рования:учебноепособие.—М.:ИздательскийотделфакультетаВМКМГУ,2009.

18.Гандерлой М.,Джордан Д.,Чанц Д.ОсвоениеMicrosoftSQLServer2005:персангл.—М.:ИД«Вильямс»,2007.

19.Горин С.В.,Крищенко В.А.Поддержкаразработкираспреде-ленныхприложенийвMicrosoft .NETFramework.—М.:МГТУим.Баумана,2006.

130

20.Зайден М.XMLдляэлектроннойкоммерции.—М.:Бином:Лабораториязнаний,2003.

21.ИспользованиеочередисообщенийMSMQвплатформе.NET:Практическоеруководство:[Электронныйресурс].—URL:http://msdn.microsoft.com/ru-ru/library/ms172497.aspx.Датаобращения:22.05.2013.

22. Машнин Т.С.Web-сервисы Java. — СПб.: БХВ-Петербург,2012.

23.РазработкаWeb-сервисовXMLисерверныхкомпонентовнаVisualBasic.NETиVisualC#.NET:учебныйкурс.—М.:Рус-скаяРедакция,2004.

24.РуководствоMicrosoftпопроектированиюархитектурыприло-жений//Корпорация«Майкрософт»,2009:[Электронныйресурс].—URL:http://www.docme.ru/doc/6625/rukovodstvo-microsoft%C2%AE-po-proektirovaniyu-arhitektury-pril…Датаобращения:29.08.2013.

25.Самуйлов К.Е.,Чукарин А.В.,Яркина Н.В.Бизнес-процессыиинформационныетехнологиивуправлениителекоммуникаци-оннымикомпаниями.—М.:АльпинаПаблишерз,2009.

26.Системыочередейсообщений:[Электронныйресурс].—URL:http://www.intuit.ru/department/network/webspheremq/1/1.html.Датаобращения:29.06.2013.

27.ТехническийобзорDCOM:[Электронныйресурс].—URL:http://www.interface.ru/magazine/tcs/Archive/198/DCOM/dcom.htm.Датаобращения:17.09.2013.

28.Унифицированныеформатыэлектронныхбанковскихсооб-щений:[Электронныйресурс].—URL:http://cbr.ru/analytics/?Prtid=Formats.Датаобращения:10.09.2013.

29.Хабибулин И.Ш.СамоучительXML.—СПб.:БХВ-Петербург,2003.

30.Хайрук С.Омульти-имоновендорнойстратегии:[Электронныйресурс].—URL:http://www.computerra.ru/cio/old/blog/index.php?page=post&blog=discussions&post_id=20.Датаобращения:15.10.2013.

31.Хоп Г.,Вульф Б.Шаблоныинтеграциикорпоративныхпри-ложений:персангл.—М.:ИД«Вильямс»,2007.

131

32.Хохгуртль Б.C#иJava:межплатформенныеWeb-сервисы.—М.:КУДИНЦ-ОБРАЗ,2004.

33.ШколыконсорциумаW3C/XML:[Электронныйресурс].—URL: http://xml.nsu.ru/xml/xml_home.xml. Дата обращения:15.05.2013.

34.Эммерих В.Конструированиераспределенныхобъектов.Ме-тодыисредствапрограммированияинтерпортабельныхобъектоввархитектурахOMG/CORBA,Microsoft/COMиJava/RMI:пер.сангл.—М.:Мир,2002.

Оглавление

Введение.........................................................................................................5

Глава 1. Интеграция корпоративных информационных систем как средство развития бизнеса.............................8

1.1.Эволюцияподходовкинтеграцииинформационныхсистем.................................................8

1.2.Методологияоткрытыхсистемипроблемаинтеграции.................................................. 13

1.3.Целиизадачиинтеграции............................................ 16

1.4.Типыинтеграционныхрешений:горизонтальнаяивертикальнаяинтеграция......... 17

1.5.Проблемыинтеграции................................................... 19

1.6.Критериивыбораинтеграционногорешения........ 21

Глава 2. Технологии и стандарты интеграции............................... 23

2.1.Понятиепромежуточнойсреды.................................. 23

2.2.Моделивзаимодействияприложений..................... 27

2.3.Стандартыобъектно-ориентированноговзаимодействия................................................................ 29

2.4.Технологии,базирующиесянаXML......................... 34

2.4.1. ЦелесообразностьпримененияXMLвинтеграционныхзадачах................................ 34

133

2.4.2.СинтаксисXML..................................................... 36ЛогическаяструктураXML-документа....... 36ФизическаяструктураXML-документа..... 39

2.4.3.Пространстваимен............................................... 39

2.4.4.ОписаниеструктурыXML-документов....... 42ЯзыкDocumentTypeDefinitions(DTD)..... 43ЯзыкXMLSchemaDefinition(XSD)............ 49ЯзыкRELAXNG.................................................. 59

2.4.5.ПрограммнаяобработкаXML-документов... 59XML-процессоры................................................. 59

2.4.6.КомпонентныемоделиструктурыXML-документов.................................................. 60

2.4.7.ЯзыкзапросовXSLT............................................ 63

2.4.8.Web-сервисы........................................................... 71ПонятиеWeb-сервисаиегохарактеристики.......................................... 71КлассификацияWeb-сервиса.......................... 73СпецификацияWSDL....................................... 74Протоколыпередачиданных........................... 75Типывзаимодействиясклиентом................. 75КлиентыWeb-сервисов...................................... 76РепозиторииWeb-сервисов.............................. 76

2.4.9.ОркестровкаихореографияWeb-сервисов... 78ЯзыкWS-BPEL.................................................... 80ЯзыкWS-CDL...................................................... 81

Глава 3. Проектирование интеграционных решений................. 82

3.1.Подход,основанныйнаиспользованиишаблонов............................................................................. 82

3.2.Архитектурапромежуточногослоя........................... 85

3.2.1.Агрегациясущностей.......................................... 86Репликацияданных............................................. 89Федерацияинформации.................................... 90

134

3.2.2.Интеграцияпроцессов........................................ 92

3.2.3.Интеграция,ориентированнаянапорталы............................................................... 96

3.3.Способысвязыванияприложений............................ 99

3.3.1.Интеграцияданных.............................................. 99Файловыйобмен................................................ 101Общаябазаданных............................................ 103Копированиеданных........................................ 105

3.3.2.Функциональнаяинтеграция......................... 106Использованиераспределенныхобъектов................................................................. 108Интеграция,ориентированнаянасообщения....................................................... 108Сервис-ориентированнаяинтеграция........ 111

3.3.3.Интеграциянауровнепользовательскогоинтерфейса............................................................ 116

3.4.Топологияинтеграционныхрешений.................... 118

3.4.1.Интеграцияпотипу«точка-точка».............. 118

3.4.2.Брокер..................................................................... 120

3.4.3.Шинасообщений................................................ 122

3.4.4.Интеграцияпотипу«публикация/подписка».................................. 124

Заключение.............................................................................................. 127

Библиографический список.............................................................. 128

Table of Contents

Introduction...................................................................................................5

Chapter 1. Enterprise Information Systems Integration as a Tool of Business Development.......................................8

1.1.EvolutionofApproachestoEnterpriseInformationSystemsIntegration.....................................8

1.2.OpenSystemsMethodologyandProblemofIntegration...................................................................... 13

1.3.PurposesandTascksofIntegration.............................. 16

1.4.TypesofIntegrationDecisions:HorizontalandVerticalIntegration................................................... 17

1.5.ProblemsofIntegration................................................... 19

1.6.CriteriaofTheIntegrationDecisionChoice................................................................................... 21

Chapter 2. Technologies And Standards Of Integration.............. 23

2.1.MiddlewareConception................................................... 23

2.2.ApplicationInteractionModels..................................... 27

2.3.StandardsofObject-OrientedInteraction................. 29

2.4.XMLTechnologies............................................................ 34

2.4.1.ExpediencyofUseXMLinIntegrationTasks................................................ 34

136

2.4.2.XMLSyntax............................................................. 36LogicalStructureofXMLDocument.............. 36PhysicalStructureofXMLDocument............ 39

2.4.3.Namespaces............................................................... 39

2.4.4.DescriptionofStructureofXMLDocuments................................................................ 42DocumentTypeDefinitions(DTD)Language.................................................................. 43XMLSсhemeDifinition(XSD)Language..... 49RELAXNGLanguage.......................................... 59

2.4.5.ProgramProcessingofXMLDocuments........ 59XMLProcessors..................................................... 59

2.4.6.ComponentModelsofXMLDocumentsStructure................................................................... 60

2.4.7.XSLTLanguage....................................................... 63

2.4.8.WebServicesDefinitionandcharacteristics.................................................. 71ClassificationofWebServices............................ 73WSDLSpecification............................................. 74ProtocolsofDataTransmission......................... 75InteractionTypeswiththeClient..................... 75ClientsofWS.......................................................... 76RepositoriesofWebServices.............................. 76

2.4.9.OrchestrationandChoreographyofWebServices....................................................... 78WS-BPELLanguage............................................. 80WS-CDLLanguage............................................... 81

Chapter 3. Integration Decisions Design.......................................... 82

3.1.TheApproachBasedonUseofTemplates.................. 82

3.2.ArchitectureoftheIntermediateLayer....................... 85

3.2.1.EntityAggregation................................................. 86DataReplication.................................................... 89FederationofInformation................................... 90

137

3.2.2.ProcessIntegration................................................ 92

3.2.3.Portals-OrientedIntegration.............................. 96

3.3.SystemConnections.......................................................... 99

3.3.1.DataIntegration..................................................... 99FileExchange........................................................ 101SharedDatabase................................................... 103DataCopies........................................................... 105

3.3.2.FunctionalIntegration........................................ 106UseDistributedObjects.................................... 108Message-OrientedIntegration......................... 108TheService-OrientedIntegration................... 111

3.3.3.PresentationIntegration..................................... 116

3.4.TopologyofIntegrationDecisions.............................. 118

3.4.1.IntegrationPoint-to-Point................................ 118

3.4.2.Broker...................................................................... 120

3.4.3.MessageBus........................................................... 122

3.4.4.PublishandSubscribe......................................... 124

Conclusion................................................................................................ 127

Bibliography.............................................................................................. 128

Учебное издание

Ольга Анатольевна Морозова

ИНТЕГРАЦИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Учебноепособие

РедакторТ.А.БалашоваОформлениеобложкиикомпьютернаяверстка

Т.В.Иванниковой

Подписановпечать02.12.13.Формат60×90 1/16.Бумагаофсетная.ГарнитураPetersburg.

Усл.-печ.л.8,75.Уч.-изд.л.8,00.Тираж40экз.Заказ№880.

ФинансовыйуниверситетЛенинградскийпроспект,49,Москва,ГСП-3,125993

ОтпечатановООП(ул.ОлекоДундича,23)ИздательстваФинансовогоуниверситета

Для заметок