Москва 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"?><!--Пример XML-документа --> <Контрагенты> <Контрагент Код="Ю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 «ФЛ»
Окончание таблицы 2.7
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-документа,правиланаследованияэлементов,включаяпорядокиколичествопотомков,типсодержимогоэлементов,типыданныхэлементовиатрибутов,значенияэлементовиатрибутовидопол-нительные ограничения на значения. Кроме того, использова-
Окончание таблицы 2.9
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>
Продолжение таблицы 2.11
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>
Окончание таблицы 2.11
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>
Продолжение таблицы 2.13
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-документ выводится таблица, строки которой отсортированы по наименованию контрагента (сортировка по воз-растанию)
Продолжение таблицы 2.13
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 родительского узла// Любое количество промежуточных узлов
Окончание таблицы 2.13
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>
Окончание таблицы 2.14
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.6
Преимущества и недостатки интеграции процессов
Преимущества Недостатки
Возможность моделировать бизнес-про-цесс независимо от реализации бизнес-функций
Обеспечение соблюдения правил выполне-ния бизнес-процесса
Повторное использование функций, предо-ставляемых приложениями (существующие приложения не зависят от слоя управления бизнес-процессом)
Быстрая адаптация к любым бизнес-тре-бованиям
Получение данных для анализа выполне-ния и оптимизации бизнес-процессов (так как управление исполнением процесса осуществляется централизованно, легко собрать статистику о времени исполнения процесса и его отдельных этапов, типичных ошибках и т.п.).
Возможное падение производительности из-за слишком большого числа параллель-но выполняемых процессов
Сложность и, как следствие, высокая стоимость решения. Поскольку реализация компонента управления распределенным бизнес-процессом — достаточно сложная задача, оптимальным вариантом является использование промышленных интеграци-онных платформ
3.2.3. Интеграция, ориентированная на порталы
Цельпостроениякорпоративногопортала—предоставлениеполь-зователямединойточкидоступаковсейкорпоративнойинформации.
Длявыполнениямногихбизнес-задачпользователямтребуетсяполучатьинформациюизразныхисточников.Например,дляпроверкисостояниязаказасотрудникуможетпонадобитьсядоступксистеме
97
управлениязаказами,атакжексистемеобработкизаказов,принятыхчерезинтернет-магазин.Основнаязадачакорпоративныхпорталов—обеспечитьпредставлениеинформацииизнесколькихисточников.
Конечныепользователинемогутэффективновыполнятьзадачи,которыетребуютдоступакинформации,распределеннойпонесколь-кимсистемам,еслионипривыкливручнуюкопироватьинформациюизоднойсистемывдругую,пользуясьзачастуюразнымикомпьютерамидлядоступакнеобходимымсистемам.Такой«ручной»типинтеграцииоченьнеэффективенирискован(большоеколичествоошибокввода).
Корпоративныйпорталкакинтеграционноерешениецелесооб-разноиспользоватьвтомслучае,если:
� отсутствуетхорошеепониманиебизнес-процесса,позволяю-щеепостроитьегомодель.Модельбизнес-процессанеудаетсяпо-строитьивтехслучаях,когдапользователипринимаютрешения,основываясьнаинформации,которуюониполучают(интеграциябизнес-процессовнеможетбытьреализована);
� существуетнепреодолимыйсемантическийдиссонансмеждуотдельнымиприложениями(интеграцияданныхневозможнаилиэкономическинецелесообразна).
Построениепортала—сравнительнопростаяформаинтеграции,еедостаточнолегкореализовать,онаоказываетминимальноевли-яниенасвязываемыеприложения.Этотподходменееэффективен,чеминтеграциябизнес-процессов,нооноставляетбольшепросторадляинициативыпользователейиегоможнореализоватьбыстрее.
Врядеслучаевпостроениепорталаможетрассматриватьсякаквременное(переходное)решение,позволяющеелучшепонятьбиз-нес-процессыиподготовитьсякинтеграциипроцессов.
Движокпортала(рис.3.9)взаимодействуетсприложениями,используяразныеспособысоединения(подробнееоспособахсо-единенияприложенийсм.п.3.3).
Рис. 3.9. Портал-ориентированная интеграция
98
Портал-ориентированныеинтеграционныерешениямогутбытьоченьразнымипоуровнюсложности.Можновыделитьследующиетипыпорталов(перечисленывпорядкеотпростыхксложным):
� «толькодлячтения»—позволяютпользователютолькопро-сматриватьданныеразличныхприложений.Данныепокаждо-му приложению располагаются обычно в отдельных областяхэкрана;
� «простоеуправление»—пользователюпорталапредставляютнеданные,анаглядныекритерии,рассчитанныепоопределяемымбизнес-логикойправилам,чтопозволяетемубыстроприниматьрешения.Впоследнеевремяуразличныхвендоровпопулярнытак называемые «информационные панели», представляющиеиндикаторыпроцессавнагляднойиудобнойдляпользователяформе;
� «интерактивные»—поддерживаютограниченноевзаимодействиемеждуобластямиэкрана,относящимисякразнымприложениям.Например,выборэлементавспискеоднойобластиприводиткпред-ставлениюопределеннойинформациивдругой.Привыбореклиентавобласти1(поданнымCRM-системы)вобласти2отображаетсяегофинансовоедосье(поданнымфинансовойсистемы).
Взаключениеперечислимосновныепреимуществаинедостаткиданногостиляинтеграции(табл.3.7).
Таблица 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-интеграции—«сервис»и«процесс».Сервис—этофункция,являющаясячеткоопределенной,само-
достаточнойинезависящейотконтекстаилисостояниядругихсервисов.
Окончание таблицы 3.12
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. Интеграция по типу «точка-точка»
Многиеинтеграционныепроектыначинаютсясобъединениядвухприложений.Простейшимспособомсвязываниядвухсистемявляетсяинтеграциятипа«точка-точка».
Окончание таблицы 3.15
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)ИздательстваФинансовогоуниверситета
Для заметок
Для заметок