Univerzitet u Novom Sadu Fakultet tehničkih nauka Željko Vuković Modelom vođena semantička integracija poslovnih aplikacija Doktorska disertacija Mentor: prof. dr Gordana Milosavljević Novi Sad, 2019.
УНИВЕРЗИТЕТ У НОВОМ САДУ ФАКУЛТЕТ ТЕХНИЧКИХ НАУКА 21000 НОВИ САД, Трг Доситеја Обрадовића 6 КЉУЧНА ДОКУМЕНТАЦИЈСКА ИНФОРМАЦИЈА Редни број, РБР: Идентификациони број, ИБР: Тип документације, ТД: Тип записа, ТЗ: Врста рада, ВР: Аутор, АУ: Ментор, МН: Наслов рада, НР: Монографска публикација Текстуални штампани документ Докторска дисертација Жељко Вуковић Др Гордана Милосављевић Моделом вођена семантичка интеграција пословних апликација Језик публикације, ЈП: Језик извода, ЈИ: Земља публиковања, ЗП: Уже географско подручје, УГП: Српски Српски Република Србија Војводина Година, ГО: 2019. Издавач, ИЗ: Факултет техничких наука Место и адреса, МА: Нови Сад, Трг Доситеја Обрадовића 6 Физички опис рада, ФО: (поглавља/страна/ цитата/табела/слика/графика/прилога) Научна област, НО: Научна дисциплина, НД: Предметна одредница/кључне речи, ПО: УДК 9/114/140/6/27/0/0 Електротехничко и рачунарско инжењерство Примењене рачунарске науке и информатика Интеграција пословних апликација, моделом управљан развој софтвера, семантички веб, језици специфични за домен Чува се, ЧУ: Библиотека Факултета техничких наука, Трг Доситеја Обрадовића 6, 21000 Нови Сад Важна напомена, ВН: Извод, ИЗ: Датум прихватања теме, ДП: 28.2.2019. Датум одбране, ДО: У склопу докторске дисертације извршено је истраживање везано за аутоматизацију интеграције пословних апликација. Приказани приступ комбинује модел структуре интерфејса апликација које се интегришу са формалним описом њихове семантике, датим у виду онтологије. На основу ових извора, обавља се аутоматско мапирање међу елементима интерфејса који се интегришу, као и детекција и разрешавање семантичких конфликата. Развијена је практична имплементација предложеног приступа, која је коришћена за верификацију теоријских разматрања, а укључује адаптиван радни оквир и језик специфичан за домен. Предложени приступ је верификован на два реална интеграциона сценарија и једним експериментом. Чланови комисије, КО: Председник: Др Горан Сладић, ванредни професор Члан: Др Владимир Димитриески, доцент Члан: Др Владимир Вујовић, доцент Потпис ментора Члан: Др Игор Дејановић, ванредни професор Члан, ментор: Др Гордана Милосављевић, ванредни професор Образац Q2.НА.06-05- Издање 1
UNIVERSITY OF NOVI SAD FACULTY OF TECHNICAL SCIENCES 21000 NOVI SAD, Trg Dositeja Obradovića 6 KEY WORDS DOCUMENTATION Accession number, ANO: Identification number, INO: Document type, DT: Type of record, TR: Contents code, CC: Author, AU: Mentor, MN: Monographic publication Textual material PhD thesis Željko Vuković Gordana Milosavljević, PhD Title, TI: Model based semantic enterprise application integration Language of text, LT: Language of abstract, LA: Country of publication, CP: Locality of publication, LP: Serbian Serbian Republic of Serbia Vojvodina Publication year, PY: 2019. Publisher, PB: Faculty of Technical Sciences Publication place, PP: Novi Sad, Trg Dositeja Obradovića 6 Physical description, PD: (chapters/pages/ref./tables/pictures/graphs/appendixes) Scientific field, SF: Scientific discipline, SD: Subject/Key words, S/KW: UC 9/114/140/6/27/0/0 Electrical engineering and computing Applied computer science and informatics Enterprise application integration, model driven engineering, semantic web, domain specific languages Holding data, HD: Library of Faculty of Technical Sciences, Trg Dositeja Obradovića 6, 21000 Novi Sad Note, N: Abstract, AB: Accepted by the Scientific Board on, ASB: Defended on, DE: This thesis presents a research in the field of automation of enterprise application integration. The approach combines structural models of interfaces of the applications being integrated with a formal specification of their semantics, given in form of an ontology. Using information from these sources, automated interface mapping is performed, along with detection and resolution of semantic conflicts. A practical implementation of the presented approach was developed and used to verify theoretical considerations. The implementation includes an adaptive framework and a domain specific language. The proposed approach has been verified on two real-world integration scenarios and one experiment. Defended Board, DB: President: Goran Sladić, PhD, Associate professor Member: Vladimir Dimitrieski, PhD, Assistant professor Member: Vladimir Vujović, PhD, Assistant professor Mentor s signature Member: Igor Dejanović, PhD, Associate professor Member, Mentor: Gordana Milosavljević, PhD, Associate professor Obrazac Q2.НА.06-05- Izdanje 1
Mojoj Smiljani.
Zahvaljujem se: svojim roditeljima, na svim odricanjima, ljubavi i pažnji, svojoj dragoj Smiljani i njenoj porodici, svojim iskrenim prijateljima, svojim kolegama, PI Informatik GmbH iz Berlina na gostoprimstvu i pomoći, komisiji na pažljivom čitanju i korisnim komentarima i svim svojim profesorima, na svemu što su nas naučili i naveli nas da sami naučimo. Posebnu zahvalnost dugujem: dr Gordani Milosavljević, svojoj mentorki i dr Nikoli Milanoviću, pokretaču istraživačkog projekta iz kog je potekla ova disertacija, koji je, kao gostujući profesor, bio i moj savetnik na doktorskim studijama.
Predgovor Postepeno uvođenje računara u poslovanje, imalo je za posledicu da se softver koji je pokrivao određene aspekte poslovanja nabavljao ili razvijao u etapama. Neretko, pojedinačna softverska rešenja razvijana su bez uvida u ostala softverska rešenja koja su u tom trenutku bila u upotrebi u istoj kompaniji. Posledica ovoga je da su podaci, koji su bili neophodni za razne namene, morali biti uneti u više različitih aplikacija. Još važnije, ti podaci su morali biti i ažurirani na više mesta ukoliko bi došlo do promene. Na taj način dolazilo je do pojave onoga što će kasnije biti nazvano silosima informacija. Funkcionalno povezani podaci nalazili su se fizički na odvojenim sistemima. Baze podataka su viđene kao rešenje ovog problema. Umesto da svaka aplikacija skladištiti podatke na sebi svojstven način, sve aplikacije mogu koristiti jednu bazu podataka. Međutim, u praksi ponekad nije moguće menjati način na koji aplikacije čuvaju podatke. Jedno rešenje za ovaj problem je i takozvani reinženjering. Umesto postojećih pojedinačnih aplikacija, izrađuju se nove aplikacije, dizajnirane tako da budu međusobno interoperabilne, ili pak jedna aplikacija, koja predstavlja integralni informacioni sistem. Nove aplikacije preuzimaju funkcionalnost starih, kao i njihove podatke. Osnovni nedostatak reinženjeringa je što se od kompanija zahteva da se odreknu postojećih rešenja u koje su uložena sredstva za nabavku i održavanje, na koje su korisnici navikli i, što je najvažnije, koja su dokazana u praksi. Alternativa reinženjeringu je integracija poslovnih aplikacija. Cilj integracije je da se omogući da nezavisno razvijani programski paketi funkcionišu kao povezana celina. Integracija poslovnih aplikacija je zrela oblast, za koju postoje dostupni oprobani komercijalni alati i koja se intenzivno koristi u praksi. Izazove u oblasti integracije predstavljaju: heterogenost aplikacija, širina neophodnih znanja o raznim korišćenim tehnologijama za izradu aplikacija koje se integrišu, kao i o poslovnim domenima i procesima za koje se one koriste, dugotrajnost i visoka cena ovog procesa, kao i pojava tehničkih i semantičkih konflikata. Tehnički konflikti su posledica različitih načina na koje aplikacije skladište i razmenjuju podatke, dok su semantički konflikti posledica različitog značenja tih podataka u različitim aplikacijama. U [48] data je formalna karakterizacija i specifikacija radnog okvira za razmenu konteksta (Context Interchange Framework, COIN), koji predstavlja posredničku strategiju za pristup podacima, u kojoj se semantički konflikti između heterogenih sistema otkrivaju i rešavaju upotrebom kontekstnog posrednika. Svrha posrednika je da poredi kontekste bilo koja dva sistema koji učestvuju u razmeni podataka. Korišćenjem formalizama uvedenih kroz COIN radni okvir semantika pojedinačnog konteksta se može koristiti za rezonovanje i
ii o semantičkim razlikama heterogenog sistema u kom taj kontekst učestvuje. Pregled arhitektura i tehnologija za integraciju distribuiranih poslovnih aplikacija, uz prikaz njihovih prednosti i nedostataka dat je u [59]. U [80] dat je radni okvir, baziran na modelima, za analizu konflikata i kompoziciju na nivou komponenti. Jedna platforma i metodologija za integraciju bazirana na meta-modelima, definisana u okviru projekta Bizycle, predstavljena je u [76]. Ova platforma podržava usku saradnju inženjera koji razvijaju integraciono rešenje sa domenskim ekspertima. Podržana je poluautomatizovana analiza konflikata. Primer definisanja ontologija za komponente dostupne na mreži jezikom OWL prikazan je u [130]. Dodavanjem klasa postojećoj ontologiji integracija je implementirana u vremenskom opsegu od nekoliko sati. Pristup integraciji koji kombinuje korišćenje veb servisa i ontologija nazvan ODSOI (Ontology-Driven Service-Oriented Integration) dat je u [67]. Autori sugerišu pogodnu topologiju servisa i ontologija, uz viziju radnog okvira za integraciju. Još jedan pristup za integraciju poslovnih informacionih sistema, pod nazivom Highway, predstavljen je u [75]. U [5] razmatrana je detekcija semantičkih konflikata u veb servisima i servisno orijentisanim arhitekturama (SOA) uopšte, u slučajevima kada se razmenjuju heterogeni podaci. Metodologija integracije poslovnih aplikacija u [25] daje smernice uz isticanje raznih pogleda na interoperabilnost: poslovni, procesni, pogled u odnosu na ljudske resurse, tehnološki, pogled u odnosu na znanje i u odnosu na značenje. U [43] dat je predlog za integraciju informacija baziran na ontologijama, uz mapiranje lokalne ontologije na globalnu. Ontologije su korišćene za detekciju i rešavanje konflikata u [112], uz praktičnu implementaciju nazvanu CREAM (Conflict Resolution Environment for Autonomous Mediation). Doktorska teza [34] prikazuje radni okvir za integraciju heterogenih tehničkih prostora, zasnovan na principima razvoja softvera vođenog modelima (RSVM). Iako su razni pristupi imali viziju pokrivanja svih potreba vezanih za informacionu podršku poslovnih subjekata, u praksi se i dalje javlja potreba za korišćenjem različitih softverskih rešenja usko specijalizovanih za određeni domen primene. Kako bi se izbeglo redundantno unošenje i ažuriranje podataka neophodnih u više ovakvih aplikacija, moguće je izvršiti njihovu integraciju. Za ručni postupak izrade integracionog rešenja postoji više zrelih metodologija i alata. Ipak, ručna integracija ostaje kompleksan, skup i dugotrajan proces, koji zahteva ekspertizu kako iz oblasti same integracije, tako i poznavanje svih aplikacija i tehnologija koji se integrišu, kao i dobro shvatanje poslovnog domena koje integrisano rešenje treba da podrži. Automatizacija procesa integracije može dovesti do skraćenja vremena neophodnog za razvoj integracionog rešenja, kao i do smanjenja troškova. Kako u ručnom, tako i u automatizovanom procesu integracije, značajan izazov predstavljaju tehnički i semantički konflikti. Tehnički konflikti se odnose na različite načine predstavljanja, čuvanja i prenošenja podataka u različitim sistemima. Semantički konflikti su posledica različitog značenja koje ti podaci mogu imati za različite aplikacije. Automatsko razrešavanje tehničkih konflikata nije trivijalno, ali je u velikoj meri rešeno. Automatsko rešavanje semantičkih konflikata je polje za koje postoji značajan obim istraživanja i za koje postoji prostor za nova rešenja. Na polju detekcije i razrešavanja semantičkih konflikata izdvajaju se rešenja koja za opis semantike sistema koji učestvuju u integraciji koriste tehnike semantičkog veba. Izuzetna širina mogućih tehnologija i procesa koji se mogu javiti u praksi dovela je do toga da rešenja koja pokušavaju da u startu pokriju sve moguće scenarije budu izuzetno kompleksna, što za posledicu ima nedostatak zrelih alata za njihovu praktičnu primenu. Jedan način za prevazilaženje ovog problema je istraživanje mogućnosti izrade fleksibilne i proširive arhitek-
ture, koja bi omogućila da se specifične potrebe određenih integracionih scenarija podmire namenski izrađenim komponentama. Ukoliko bi ove komponente bile takve da se mogu ponovo koristiti, rezultat bi bila progresivno lakša izrada narednih integracionih rešenja. Cilj istraživanja je definisanje procesa i komponenti koje omogućuju delimičnu ili potpunu automatizaciju otkrivanja mapiranja između elemenata interfejsa aplikacija i podsistema koji su predmet integracije poslovnih aplikacija i delimičnu ili potpunu automatizaciju otkrivanja semantičkih konflikata nad uočenim mapiranjima. Rešenje omogućava mapiranje heterogenih i disparatnih oblika interfejsa, pri čemu u integraciji može učestvovati N [1..] interfejsa koji pripadaju M [1..] aplikacija (gde je M>1 N>1). iii Pregled sadržaja i strukture teze Uvodno poglavlje daje opšti pregled polja i predmeta istraživanja. U ovom poglavlju izložene su hipoteze istraživanja. Naredna poglavlja su organizovana na sledeći način. Poglavlje 2 daje teorijske osnove koje su neophodne za razumevanje oblasti integracije. U ovom poglavlju su definisane vrste integracije, uz pregled nekih mogućih kategorizacija po različitim osnovama: broju i tipu atomičkih delova koji se integrišu, sintaktičkom pristupu i semantičkom pristupu. S obzirom da rešenje predstavljeno u tezi koristi neke od principa modelom upravljanog razvoja softvera, dat je kratak opis i ove oblasti. Definiše se šta su modeli, kako se koriste u inženjerstvu uopšte i kako pomažu pri dizajnu i implementaciji softverskih rešenja. Opšti jezici za modelovanje osmišljeni su tako da se njima mogu opisati problemi iz bilo kog domena primene i rešenja koja koriste bilo koju tehnologiju ili arhitekturu. Jezici specifični za domen, sa druge strane, fokusiraju se samo na neku usku oblast i koriste koncepte i konstrukte te oblasti, bliske krajnjim korisnicima. Ovo poglavlje daje osnove i ove dve klase jezika, kao i obrazloženje kako se modeli na visokom nivou apstrakcije, dati bilo opštim, bilo jezikom za modelovanje specifičnim za domen, mogu koristiti za dobijanje izvornog koda za željenu tehnologiju. Na kraju, ovo poglavlje daje uvod u oblast semantičkog veba, prikaz pojma ontologije i ideje korišćenja semantičkog rezonovanja kako bi se iz specifikacije poznatih činjenica mašinski izvukli zaključci. Poglavlje 3 daje pregled naučne i stručne literature iz oblasti integracije i prikazuje postojeće pristupe njenoj automatizaciji, uz poseban osvrt na semantičke pristupe, odnosno one koji koriste tehnologije semantičkog veba i one koji koriste principe modelom upravljanog razvoja softvera. Poglavlje 4 uvodi pristup automatizaciji semantičke integracije poslovnih aplikacija dat u ovoj tezi. Predstavljen je proces mapiranja, koji sa jedne strane polazi od modela strukture interfejsa aplikacija koje se integrišu, a sa druge strane od formalnog opisa semantike tih sistema, datih objedinjenom ontologijom. Korisnik zatim anotira elemente srukturnog modela elementima ontologije. Ovaj, semantikom obogaćen model, radni okvir koristi za uspostavljanje mapiranja između elemenata ulaznih i izlaznih interfejsa, kao i za detekciju i razrešavanje semantičkih konflikata. U poglavlju su dati neki mogući kriterijumi koji se mogu koristiti za detekciju kandidata za ovakvo mapiranje, kao i kriterijumi za detekciju
iv konflikata. Ovi kriterijumi u radnom okviru predstavljaju nezavisne komponente, koje se po potrebi mogu uključivati ili modifikovati. Kako bi se radni okvir, čija je arhitektura opisana u poglavlju 4, mogao testirati i evaluirati, razvijena je njegova praktična implementacija. Ova implementacija je opisana u poglavlju 5. Kao bi se skratilo vreme neophodno za implementaciju, kao podloga je korišćen alat za integraciju otvorenog koda, Talend Open Studio. Ovaj alat sadrži sve neophodne mehanizme za opis strukture aplikacija koje se integrišu, konektore za razne vrste protokola, mehanizme za generisanje izvornog koda izvršivog integracionog rešenja, kao i podršku za ručno mapiranje elemenata interfejsa aplikacija koje se integrišu. Time je rad na implementaciji našeg rešenja sveden na ono što zaista jeste predmet ovog istraživanja, a to je automatizacija pomenutog mapiranja. Arhitektura radnog okvira definisanog u prethodna dva pomenuta poglavlja je takva da je moguće po potrebi naknadno razviti komponente koje su prilagođene problemu koji se javi prilikom nekog konkretnog integracionog scenarija. Način na koji se ove komponente implementiraju zahteva korišćenje jezika opšte namene, u ovom slučaju Jave i, pored poznavanja arhitekture ovog radnog okvira, poznavanje i arhitekture platforme na kojoj je on implementiran, a to su Eclipse Rich Client Platform i aplikacija Talend Open Studio. Kako bi se omogućilo opisivanje komponenti radnog okvira na način koji je nezavisan od platforme implementacije, razvijen je jezik specifičan za domen, nazvan SAIL - Semantic Application Integration Language. Dizajn, odnosno meta-model i implementacija ovog jezika opisani su u poglavlju 6. U poglavlju 7 prikazana je empirijska i eksperimentalna evaluacija radnog okvira za automatizovano mapiranje. Korišćena su dva praktična integraciona scenarija: (1) procedura prikupljanja medicinskih analiza klijenata doma za negu starih lica i njihovo prosleđivanje informacionom sistemu bolnice i (2) integracija portala za vođenje projekata sa SAP informacionim sistemom. Za oba scenarija je ranije postojala ručno izrađena implementacija, a zatim je integracija izvedena našim radnim okvirom, uz poređenje rezultata. Eksperimentalna evaluacija izvedena je kroz skup integracionih scenarija koje su učesnici u eksperimentu mapirali prvo ručno, a zatim automatski, pomoću našeg radnog okvira. Na osnovu prikupljenih rezultata izvedeni su zaključci.
Sadržaj 1 Uvod i motivacija 1 2 Teorijske osnove 5 2.1 Vrste integracije................................... 5 2.1.1 Klasifikacija semantičkih konflikata.................... 11 2.2 Modelom upravljan razvoj softvera........................ 12 2.3 Semantički veb.................................... 17 3 Pregled trenutnog stanja u oblasti 23 3.1 Pristupi integraciji.................................. 23 3.2 Alati za spajanje i mapiranje ontologija...................... 35 3.3 Alati za integraciju................................. 37 3.3.1 Apache Camel................................ 37 3.3.2 Talend Open Studio............................ 38 3.3.3 Microsoft BizTalk.............................. 39 3.3.4 Oracle Integration Cloud.......................... 41 3.3.5 Rezime pregleda alata za integraciju................... 42 4 Radni okvir za automatizaciju integracije 45 4.1 Proces mapiranja.................................. 46 4.2 Kriterijumi mapiranja................................ 48 v
vi SADRŽAJ 4.2.1 Jednako ime................................. 49 4.2.2 Jednaka XPath putanja.......................... 49 4.2.3 Specijalizacija................................ 49 4.2.4 Generalizacija................................ 51 4.2.5 Jednako anotiranje............................. 51 4.2.6 Agregacija.................................. 51 4.2.7 Tranzitivna agregacija........................... 52 4.2.8 Razdvajanje................................. 52 4.2.9 Zabrana mapiranja............................. 53 4.3 Detekcija i razrešavanje konflikata......................... 53 4.3.1 Višestruko mapiranje po istom osnovu.................. 53 4.3.2 Višeznačna specijalizacija ili generalizacija................ 54 4.3.3 Nekompatibilnost tipova.......................... 54 4.4 Konstrukcija izraza za mapiranje.......................... 54 5 Referentna implementacija radnog okvira 57 5.1 Podloga i podrška.................................. 59 5.2 Arhitektura radnog okvira............................. 60 6 SAIL jezik specifičan za domen 67 6.1 SAIL Meta-model.................................. 67 6.2 Implementacija jezika................................ 72 7 Evaluacija 81 7.1 Scenario 1: dom za negu starih.......................... 81 7.1.1 Scenario................................... 81 7.1.2 Formati i protokoli od interesa u scenariju................ 82
SADRŽAJ vii 7.1.3 Ručna implementacija........................... 84 7.1.4 Implementacija prikazanim radnim okvirom............... 86 7.2 Scenario 2: portal za vođenje projekata...................... 89 7.2.1 Scenario................................... 89 7.2.2 Formati i protokoli od interesa u scenariju................ 89 7.2.3 Implementacija............................... 91 7.3 Eksperimentalna evaluacija............................. 96 8 Zaključak 99
viii SADRŽAJ
Skraćenice AIAG Automotive Industry Action Group. 7 AIDX Aviation Information Data Exchange. 7, 8 AIRM ATM Information Reference Model. 7, 8 ANSI American National Standards Institute. 82 API Application programming interface. 9, 16, 22, 36, 37, 41, 60 ASCII American Standard Code for Information Interchange. 19 ATM Air Traffic Management. 7 BAPI Business Application Programming Interface. 90 92, 94 BOD Business Object Documents. 7 BPEL Business Process Execution Language. 28 BPM business process management. 6 BPML Business Process Modeling Language. 7 CDS Cell directory service. 9 CIM Computation Independent Model. 27 COIN Context Interchange Framework. i, 23 COM Component Object Model. 10 CORBA Common Object Request Broker Architecture. 10 CPS Cyber-Physical Systems. 32 CREAM Conflict Resolution Environment for Autonomous Mediation. ii, 31 CRM Customer relationship management. 38 CSV Comma-separated values. 36, 38, 81 84, 86, 89 ix
x Skraćenice DAML DARPA Agent Markup Language. 20 DCE Distributed computing environment. 9 DL Description Logic. 18, 20, 22, 31, 34, 35 DSL Domain-specific language. 14 DSM Domain-specific model. 14 DTD Document Type Definition. 7 EAI enterprise application integration. 6, 33 ECTL Extract, Cleanse, Transform and Load. 32 ELF Executable and Linkable Format. 60 ER Entity relationship (diagram). 35 ERP Enterprise Resource Planing. xvii, 35 ESB Enterprise Service Bus. 6, 28, 59 ETL Extract, Transform, Load. 10 FDR Failures-Divergences Refinement. 27 FTP File Transfer Protocol. 38, 39, 41 GUI graphical user interface. 60 HTTP Hypertext Transfer Protocol. 21, 24, 39, 83, 91 HTTPS Hypertext Transfer Protocol Secure. 91 IDE Integrated Development Environment. 60 IDL Interface Definition Language. 10 IEC International Electrotechnical Commission. xv, 25, 26 IIOP Internet InterORB Protocol. 10, 24 IMAP Internet Message Access Protocol. 38 IP Internet Protocol. 90, 93 IRI International Resource Identifier. 19 ISO International Organization for Standardization. 83 JDBC Java Database Connectivity. 9
Skraćenice xi JSD Domain Specific Language DSL. 14, 15, 27 29, 33, 37, 39, 51, 55, 84 JSON JavaScript Object Notation. 20 LDAP Lightweight Directory Access Protocol. 38 LSL Link Specification Language. 36 LTSA Labelled Transition System Analyser. 27 MDA Model-driven architecture. 27 MDE Model-driven engineering. 14 MIME Multipurpose Internet Mail Extensions. 83 MOF Meta Object Facility. 16 MOM Message-oriented middleware. 11 MSMQ Microsoft Message Queuing. 39 OAG Open Applications Group. 7 OBDA Ontology-Based Data Access. 34, 35 ODBC Open Database Connectivity. xv, 1, 9, 10 ODSOI Ontology-Driven Service-Oriented Integration. ii, 28 OIC Oracle Integration Cloud. 41 OIL Ontology Inference Layer. 20 OMG Object Management Group. 10 ORB Object request broker. 10 OSI Open Systems Interconnection. 83 OWL Web Ontology Language. ii, 17, 20, 22, 28, 31, 35, 36, 51, 60 PIM Platform Independent Model. 27 POJO Plain Old Java Object. 85 POP3 Post Office Protocol version 3. 38 PSM Platform Specific Model. 27 RCP (Eclipse) Rich Client Platform. 60, 67 RDF Resource Description Framework. 3, 17, 19 21, 36, 60
xii Skraćenice RDFS RDF Schema. 20, 22 REST Representational state transfer. 36, 38, 41 RMI Remote method invocation. 10 RPC Remote Procedure Call. 6, 9 RSVM Razvoja softvera vođen modelima. ii, 32 SAD National Institute of Standards and Technology. 41 SAIL Semantic Application Integration Language. iv, xvi, xix, 51, 67, 72, 73, 78, 80 SCROL Semantic Conflict Resolution Ontology. 31 SDK Software development kit. 33, 34 SMTP Simple Mail Transfer Protocol. 38, 39, 91 SOA Servisno orijentisane arhitekture. ii, 6, 29 SOAP Simple Object Access Protocol. 36, 38, 39, 41, 90, 91 SPARQL SPARQL Protocol and RDF Query Language. 21, 36, 72 SQL Structured Query Language. xvi, 1, 9, 32, 38, 84, 86, 87 SQS Amazon Simple Queue Service. 38 STAR Standards in Automotive Retail. 7 SUBP Sistem za upravljanje bazama podataka. 1, 2 SWRL Semantic Web Rule Language. 17 SWT Standard Windget Toolkit. 60 TCP Transmission Control Protocol. 90 TOS Talend Open Studio. xvi, 54, 55, 59 62, 86, 87, 92 94 TP Tehniki prostor. 32, 33 UML Unified Modeling Language. xvii, 7 9, 16, 35 URI Uniform Resource Identifier. 19, 37 URL Uniform Resource Locator. 19, 21 WCF Windows Communication Foundation. 39 WSDL Web Services Description Language. xvi, xix, 29, 39, 91 93
Skraćenice xiii XMI XML Model Interchange. xvii, 7, 8, 16 XML Extensible Markup Language. 3, 7, 16, 20, 22, 31 33, 36, 38, 48, 49, 61, 83, 90 92, 94 XSD XML Schema Definition. 31, 39 XSLT extensible Stylesheet Language Transformations. 31, 40
xiv Skraćenice
Slike 2.1 Tipologija sintaktičkih tehnika integracije.................... 6 2.2 Pristup aplikacije bazi podataka posredstvom ODBC.............. 10 2.3 Stek tehnologija semantičkog veba........................ 18 3.1 Podela vidova integracije u četiri dimenzije.................... 25 3.2 Nivoi interoperabilnosti po IEC 61804-1..................... 26 3.3 Specifikacija i generisanja integracionog rešenja na BIZYCLE platformi... 28 3.4 Faze izgradnje i mapiranja ontologija pri integraciji po [21].......... 30 3.5 Vizualizacija rute u alatu Hawtio......................... 38 3.6 Pregled BizTalk arhitekture............................ 39 3.7 Životni ciklus poruke u BizTalk okruženju.................... 40 3.8 Radno okruženje alata BizTalk Mapper...................... 40 3.9 Kreiranje orkestracije u Oracle Integration Cloud................ 42 3.10 Korisnički interfejs za mapiranje u Altova MapForce.............. 43 4.1 Dijagram komponenti radnog okvira....................... 46 4.2 Šematski prikaz procesa integracije........................ 47 4.3 Traženje potvrde od strane korisnika....................... 50 5.1 Proces integracije.................................. 58 5.2 Dijagram klasa Matcher komponenti....................... 61 xv
xvi SLIKE 6.1 Meta-model jezika SAIL.............................. 68 6.2 SAIL editor i outline alati.............................. 73 7.1 Integracioni scenario razmene rezultata krvi................... 82 7.2 TOS Job koji agregira XLS i SQL ulaze u HL7 izlaz.............. 87 7.3 Mapiranje koje je automatski dobijeno radnim okvirom............. 88 7.4 Grafički prikaz dela WSDL definicije servisa................... 92 7.5 Grafički prikaz TOS job-a koji povezuje veb servis i SAP............ 93 7.6 Tabela E_WBS_ELEMENT_TABLE....................... 94 7.7 Koraci potrebni za dobijanje automatskog mapiranja sa rezultatima..... 95
Tabele 2.1 Rezultati razmene modela korišćenjem iste verzije XMI............. 8 2.2 Prikaz kompatibilnosti unazad UML alata.................... 9 3.1 Problemi prilikom uvođenja ERP rešenja..................... 35 4.1 Pregled kriterijuma za mapiranje......................... 48 4.1 Pregled kriterijuma za mapiranje......................... 49 7.1 Rezultati eksperimenta............................... 97 xvii
xviii TABELE
Listinzi 2.1 Primer FreeMarker šablona............................. 16 4.1 Definicija specijalizacije u ontologiji........................ 49 4.2 Generalizacija u ontologiji............................. 51 4.3 Definicija agregacije u ontologiji.......................... 52 4.4 Ontologija koja definiše agregaciju ka nadklasi.................. 52 4.5 Ontologija koja definiše da su a i b različiti, pa ih ne treba mapirati..... 53 5.1 Algoritam za traženje mapiranja.......................... 63 5.2 Izvorni kod klase AbstractOntologyMatcher................... 65 5.3 Metoda klase OntologyGeneralisation koja implementira kriterijum 4.2.4... 66 6.1 Gramatika jezika SAIL............................... 73 6.2 Primer korišćenja SAIL jezika........................... 80 7.1 Primer razmene poruka u HL7 formatu...................... 82 7.2 Apache Camel ruta za čitanje datoteka i slanje na dalju obradu na osnovu tipa datoteke..................................... 84 7.3 Pronalazak vrednosti primarnog ključa u tabeli baze podataka na osnovu identifikacionih podataka pronađenih u rezultatima analize krvi........ 85 7.4 Agregacija i prosleđivanje ukoliko rezultati odstupaju od referentnih vrednosti 85 7.5 Deo WSDL definicije veb servisa koji učestvuje u scenariju 2.......... 90 xix
xx LISTINZI
1 Uvod i motivacija Poslovna informatika se rodila iz mogućnosti, koja se otvarala pred kompanijama, da upotrebom elektronskih računara određene poslove učine bržim, efikasnijim i manje podložnim greškama. Ovi poslovi su se do tada obavljali ručno, ili eventualno uz upotrebu mehaničkih pomagala. Međutim, kako su računari i sve što je bilo vezano za njihovu upotrebu bili skupi, poveravani su im samo pojedini zadaci. Kako su tehnologije postajale pristupačnije (a time, ključno, isplativije), sve više aspekata poslovanja dobijali su računarsku podršku. Od računovodstvenih zadataka, kojima su se bavili pioniri njihove upotrebe, računari su uvođeni u korespodenciju, lance nabavke, planiranje, projektovanje, proizvodnju. Ovakvo, postepeno uvođenje računara u poslovanje, imalo je za posledicu da se softver koji je pokrivao određene aspekte poslovanja nabavljao ili razvijao u etapama. Neretko, softverska rešenja koja su pokrivala određeni vid poslovanja, razvijana su bez uvida u ostala softverska rešenja koja su u tom trenutku bila u upotrebi u istoj kompaniji. Posledica ovoga je bila da su određeni podaci, koji su bili neophodni za razne namene, morali biti uneti u više različitih aplikacija. Još važnije, ti podaci su morali biti i ažurirani na više mesta ukoliko bi došlo do promene. Na taj način dolazilo je do pojave onoga što će kasnije biti nazvano silosima informacija. Funkcionalno povezani podaci nalazili su se na fizički odvojenim sistemima. Baze podataka su viđene kao rešenje ovog problema. Umesto da svaka aplikacija skladišti podatke na sebi svojstven način, sve aplikacije mogu koristiti jednu bazu podataka. Moguće je projektovati šemu baze podataka tako da obuhvati potrebe svih podstistema. Ukoliko su aplikacije već projektovane tako da koriste bazu podataka, moguće je izvršiti integraciju njihovih pojedinačnih šema u jedinstvenu [82]. Međutim, u praksi ponekad nije moguće menjati način na koji postojeće aplikacije čuvaju podatke. Proizvođači aplikacije mogu proceniti da im se takve promene ne isplate. U nekim slučajevima, kompanije koje su razvile softver više ne postoje. Tehničke ili pravne prepreke mogu sprečiti kompaniju koja je korisnik da ona načini izmene. Čak i kada sve aplikacije koriste baze podataka, one mogu koristiti sisteme za upravljanje bazama podataka (SUBP) različitih proizvođača. Iako postoje standardizovani načini za pristup SUBP, kao što su Open Database Connectivity (ODBC) i Structured Query Language (SQL), u praksi postoje značajne razlike, zbog kojih prepravka 1
2 1. UVOD I MOTIVACIJA aplikacije koja je projektovana da koristi određeni SUBP na korišćenje drugog (ili čak druge verzije istog) ne predstavlja trivijalan poduhvat. Na kraju, za projektovanje integrisane šeme baze podataka neophodno je poznavati detaljnu specifikaciju pojedinačnih šema na konceptualnom nivou, za šta je dokumentacija često nedostupna, a iz fizičke šeme se ne može u potpunosti sagledati (na primer, u nekim aplikacijama su ograničenja implementirana samo na nivou korisničkog interfejsa, što svakako nije preporučena praksa, ali, nažalost, ni redak slučaj). Jedno rešenje za ovaj problem je takozvani reinženjering. Umesto postojećih pojedinačnih aplikacija izrađuju se nove aplikacije, dizajnirane tako da budu međusobno interoperabilne, ili pak jedna aplikacija, koja predstavlja integralni informacioni sistem. Nove aplikacije preuzimaju funkcionalnost starih, kao i njihove podatke. Integracija je alternativa reinžinjeringu. Cilj integracije je povezivanje različitih funkcionalnosti gotovih aplikacija, bez potrebe za njihovom izmenom. Integraciono rešenje automatizuje usklađivanje uskladištenih podataka među ovim aplikacijama. Pored toga, omogućava izgradnju složenih poslovnih procesa, u kojima svaka aplikacija obavlja deo funkcionalnosti za koji je zadužena, dok se korisniku obezbeđuje jedinstven interfejs kroz koji može upravljati izvršavanjem procesa. Sam proces integracije može biti izuzetno složen i zahtevan. Inženjeri koji sprovode integraciju moraju imati znanja o širokom spektru tehnologija, protokola i formata. Neretko, u istom integracionom scenariju mogu učestvovati aplikacije koje koriste moderne, aktuelne tehnologije zajedno sa aplikacijama koje koriste zastarele tehnologije. Pored poznavanja tehnologija kojima su aplikacije razvijene, neophodno je i detaljno poznavanje funkcionalnosti samih aplikacija. Danas postoje alati koji delimično olakšavaju neke od aspekata integracije. Ovi alati obično imaju mnoštvo raspoloživih gotovih konektora - komponenti koje omogućavaju razmenu podataka ili pozivanje funkcionalnosti određenim formatom ili protokolom. Za mnoge od ovih formata moguća je i automatska ekstrakcija strukture, odnosno šeme koju koristi neka aplikacija. Dostupni alati olakšavaju i testiranje, izvršavanje i nadgledanje rada integracionog rešenja. Deo procesa integracije koji i dalje predstavlja prevashodno manuelni posao jeste uspostavljanje mapiranja između interfejsa različitih aplikacija. Automatizacija procesa mapiranja, kao i automatizacija detekcije grešaka koje se pri tom mogu javiti i njihovog rešavanja mogli bi pojednostaviti celokupan proces integracije, učiniti ga jeftinijim i pouzdanijim. Da bi se mapiranje moglo obaviti sa adekvatnim nivoom pouzdanosti, kao i da bi se mogli efikasno utvrditi konflikti koji postoje u načinu na koji različite aplikacije tumače podatke i funkcionalnosti kojima operišu, neophodno je pored strukture interfejsa poznavati i njihovu semantiku. Iz tog razloga, pristup prikazan u ovoj disertaciji baziramo na ideji da se strukturni model interfejsa na pogodan način obogati formalnom definicijom svoje semantike. *** Druga polovina devedesetih godina donosi usvajanje i ekspanziju veba (World Wide Web) kao opsežnog izvora informacija i medijuma za deljenje znanja i podataka. Arhitektura veba
polazila je od niza uslova [39], koji su doprineli kako njegovom usvajanju, tako i održanju kao aktuelne platforme u nastupajućim godinama: 3 lakoća korišćenja - kako pri konzumiranju, tako i pri kreiranju sadržaja, proširivost - moraju postojati načini kojima se prvobitna implementacija distribuiranog sistema može naknadno prilagoditi i unaprediti, skalabilnost, uniformnost interfejsa i podrška evoluciji zahteva. Iz pepela dot-com mehura 1 iznikao je Veb 2.0. Iako novi veb nije predstavljao i novi standard u tehničkom smislu, glavna novina u pogledu korišćenja veba, bilo je sveprisutno uključivanje korisnika u doprinos sadržaju. Korisnici su doprinosili na razne načine: od deljenja utisaka o pročitanim knjigama ili pogledanim filmovima, do pisanja enciklopedijskih članaka. Tagovanjem multimedijalnih sadržaja, ljudi pomažu u njihovoj klasifikaciji, a lajkovanjem izdvajaju sadržaje koji su im interesantni. Statičke stranice zamenjene su dinamičkim aplikacijama, indeksi su zamenjeni pretragama. Aplikacije mogu koristiti podatke koje prikupe od korisnika kako bi agregirale određene rezultate i pružile korisnicima povratnu informaciju koja je za njih od interesa. Međutim, iako interakcija korisnika i aplikacija može biti od uzajamne koristi, podaci koje ostavljaju korisnici dostupne su samo u okviru određene aplikacije. Iako raznim tehnikama druge aplikacije mogu dobiti podatke koje određena aplikacija pruža korisnicima, one nisu svesne značenja tih podataka. Problem silosa informacija, koji je ranije pomenut u kontekstu poslovne informatike javlja se i na vebu. Semantički veb [13] zamišljen je sa ciljem da se omogući aplikacijama da pored podataka mogu saznati i semantiku, odnosno - značenje, tih podataka. Načini za reprezentaciju znanja ranije su izučavani u oblasti računarske inteligencije. Uz XML, koji omogućava da se elementi dokumenta označe i struktuiraju, Resource Description Framework (RDF), omogućava da se iskaže njihovo značenje. Ontologija, u kontekstu semantičkog veba, predstavlja dokument koji formalno definiše odnose među pojmovima. Cilj ovog istraživanja je pronalaženje načina da se proces integracije poslovnih aplikacija, kao i detekcija i razrešavanje semantičkih konflikata koji se pri tome javljaju, u mogućoj meri automatizuju. Cilj automatizacije je povećanje efikasnosti samog procesa, radi bržeg i jeftinijeg postizanja integracije, kao i smanjenje mogućnosti za nastanak grešaka koje se javljaju pri ručnoj integraciji. Polazeći od ovih ciljeva, kao i od aktuelnog stanja oblasti, formiramo sledeće hipoteze, uz važenje jedne prethodne pretpostavke: Pretpostavka 1: Postoji jedinstvena ontologija, formalni zapis semantike, koja opisuje sve aspekte relevantne za integraciju svih sistema čija se integracija obavlja. 1 Takozvani Dot-com mehur predstavlja period na početku XX veka, kada je zabeležen ektreman rast vrednosti kompanija koje su svoje poslovanje bazirale na ponudi usluga putem Interneta, a zatim i naglog pada njihove vrednosti i gašenja većine ovih kompanija.
4 1. UVOD I MOTIVACIJA Hipoteza 0: Moguće je razviti radni okvir koji podržava mehanizme koji, uz pomoć opisa semantike datog u ontologiji, koja je definisana u pretpostavci 1, omogućavaju automatizovanu detekciju mapiranja između elemenata interfejsa koji učestvuju u integraciji na osnovu zadatih kriterijuma mapiranja, kao i automatizovano otkrivanje semantičkih konflikata između datih interfejsa, na osnovu zadatih kriterijuma konflikata. Hipoteza 1: Kriterijumi mapiranja i kriterijumi konflikata, pomenuti u Hipotezi 0, mogu biti razvijeni kao nezavisne komponente, čime se korisniku omogućava dodavanje, modifikacija i uklanjanje datih kriterijuma. Hipoteza 2: Moguće je kreirati jezik specifičan za domen, kojim se mogu opisati kriterijumi za mapiranje i kriterijumi za otkrivanje konflikata. Dakle, opseg ovog istraživanja ograničavamo na ispitivanje mogućnosti korišćenja formalnog zapisa semantike svih sistema koji učestvuju u integracionom scenariju, kako bi se automatizovalo uspostavljanje mapiranja među interfejsima aplikacija koje se integrišu. Za potpunu automatizaciju celog procesa integracije, neophodno bi bilo automatizovati i ekstrakciju, spajanje i poravnanje ontologija za svaki pojedinačan sistem, što je predmet istraživanja druge disertacije. Za potrebe stvaranja uslova za evaluaciju ovog istraživanja, ovi koraci su obavljani ručno.
2 Teorijske osnove U ovom poglavlju prikazane su oblasti integracije poslovnih aplikacija, kao i tehnika i tehnologija koje su služile kao polazna tačka za istraživanje prikazano u ovoj disertaciji. Najpre je u sekciji 2.1 dat pregled raznih mogućih vrsta integracije. Zatim je, u sekciji 2.2, predstavljen razvoj softvera upravljan modelom. Modeli se u pristupu integraciji prikazanom u poglavlju 4 koriste za specifikaciju strukture interfejsa aplikacija koje se integrišu. Na kraju, u sekciji 2.3, opisane su osnove semantičkog veba; tehnologije koja se u našem pristupu koristi kako bi se strukturalni model interfejsa obogatio semantikom, što pomaže u traženju kandidata za mapiranje i pri detekciji i rešavanju semantičkih konflikata. 2.1 Vrste integracije Kategorije po tipu i broju atomičkih delova Četiri kategorije metoda sistemske integracije mogu se klasifikovati po tipu i broju atomičkih delova sistema koji se integrišu [50, 96]: Vertikalna integracija. Metodi iz ove grupe integrišu delove sistema po osnovu njihove funkcionalnosti. Integrišu se samo neophodni delovi sistema, što u prvi mah rezultuje brzom i jeftinom integracijom. Mana ovakvih metoda je nemogućnost ponovnog korišćenja integrisanih entiteta, pa je kasnije dodavanje novih entiteta skupo i komplikovano. Zvezdasta integracija. Delovi sistema se integrišu svako sa svakim. Poznata i pod nazivima point-to-point i špageti integracija. Ovakve metode su fleksibilne i jednostavne za implementaciju u pogledu svakog para ponaosob, ali kompleksnost integracije raste eksponencijalno s brojem delova koji se integrišu. Dodatni izazov za ovakve metode predstavlja integracioni scenario gde je potrebno da više delova istovremeno sarađuje kako bi se agregirala određena funkcionalnost. 5
6 2. TEORIJSKE OSNOVE Sintaktičke tehnike integracije Ad-hoc Standardizacija Tradicionalni middleware EAI SOA BPM Pristup podacima Aplikativni server Standardni model Standardizovana razmena Udaljeni pozivi Middleware zasnovan na komponentama Praćenje transakcija Slika 2.1: Tipologija sintaktičkih tehnika integracije po [66] Horizontalna integracija. Metode horizontalne integracije se oslanjaju na postojanje komponente koja ima ulogu prosleđivanja poruka između delova sistema. Svaki deo sistema se time integriše samo jednom - sa posredničkom komponentom. Ulogu ove komponente može obavljati Enterprise Service Bus (ESB). U ovakvim načinima integracije moguće je zameniti neki od delova drugim koji pruža sličnu funkcionalnost, čak i kada novi deo ima drugačiji interfejs. U idealnom slučaju, ova zamena je transparentna za ostale delove sistema. Zajednički format podataka. U ovakvim metodama, usvaja se zajednički format podataka, nezavisan od formata pojedinačnih aplikacija koje se integrišu. Za svaki deo koji se integriše, kreira se adapter koji vrši mapiranje na zajednički format. Sintaktički pristupi integraciji U sintaktičke pristupe integraciji mogu se svrstati: ad-hoc tehnike, tehnike zasnovane na standardizaciji, tradicionalni middleware, pristupi zasnovani na alatima za integraciju poslovnih aplikacija (enterprise application integration, EAI), pristupi zasnovani na tehnikama za upravljanje poslovnim procesima (business process management, BPM) i pristupi zasnovani na tehnikama servisno orijentisanih arhitektura (service-oriented architectures, SOA) [66]. Pregled sintaktičkih tehnika integracije dat je na slici 2.1. Ad-hoc integracija. Ad-hoc tehnike se zasnivaju na implementaciji adaptera, pri čemu se za svaki interfejs koji učestvuje u integraciji piše adapter ka svim ostalim interfejsima sa kojima je neophodna komunikacija. Obično su adapteri pisani na programskim jezicima opšte namene [66], kada se za realizaciju koriste mehanizmi koji su na raspolaganju na jeziku i u bibliotekama koje se koriste za implementaciju adaptera, kao što je Remote Procedure
2.1. VRSTE INTEGRACIJE 7 Call (RPC), ali moguće je i korišćenje alata za integraciju [115]. U smislu podele date u sekciji 2.1, na ovaj način se implementiraju point-to-point, odnosno zvezdaste metode. Tehnike zasnovane na standardima. Tehnike zasnovane na standardima se baziraju na ideji da bi aplikacije koje treba integrisati trebalo da podrže određene standarde formata poruka koje se razmenjuju, formata podataka ili modela procesa koji se odvijaju. Ovakve tehnike primenljive su u slučajevima kada sve aplikacije koje se integrišu pripadaju određenom domenu (npr. zdravstvo, proizvodnja, avionika, obrazovanje), odnosno kada je moguće doneti pomenute standarde za datu oblast. Navodimo nekoliko primera takvih standarda. XML (extensible Markup Language) [18] namenjen je struktuiranom zapisivanju dokumenata i podataka u obliku stabla. Za specifikaciju modela dokumenta može se koristiti stariji jezik DTD (Document Type Definition) ili XML Schema [109, 110] koji ispravlja njegove nedostatke. U praksi se javljaju i dokumenti koji nemaju pridružen model. XML se koristi i kao način zapisivanja za druge standarde, poput ebxml (e-business XML), XMI (XML Metadata Interchange) formata za razmenu UML dokumenata [103], BPML i drugih. RosettaNet je standard namenjen razmeni informacija između poslovnih subjekata (Business-to-business, B2B). Omogućava usaglašavanje procesa među učesnicima u lancu nabavke na globalnom nivou [15]. Propisuje ga istoimeni konzorcijum. HL7 je standard za komunikaciju u oblasti zdravstva. Detaljnije je opisan u sekciji 7.1 IDEF3 namenjen je za opis sekvenci aktivnosti u poslovnim procesima [86]. BPML - Business Process Modeling Language [17] je još jedan jezik za opis poslovnih procesa. UML - Unified modelling language, jezik opšte namene za specifikaciju softverskih i drugih sistema [105], AIRM - ATM Information Reference Model [22] je UML model namenjen obezbeđivanju semantičke interoperabilnosti evropske mreže za upravljanje vazdušnim saobraćajem (Air Traffic Management, ATM) 1, inicijalno propisan od strane organizacije Eurocontrol. AIDX - Aviation Information Data Exchange (AIDX) [3] je standard za razmenu XML poruka o informacijama u vezi sa letovima među aerodromima, aviokompanijama i drugim pružaocima usluga iz oblasti vazdušnog saobraćaja, propisan od strane Međunarodne asocijacije za vazdušni prevoz (IATA) 2. Namena navedenih standarda je da omogućavaju razmenu podataka ili poruka između aplikacija različitih korisnika i proizvođača, ukoliko te aplikacije podržavaju dati standard. Jasno je da se problem javlja ukoliko aplikacije ne podržavaju neki zajednički standard. Na primer, STAR (Standards in Automotive Retail) i AIAG (Automotive Industry Action 1 http://airm.aero 2 https://www.iata.org/publications/pages/info-data-exchange.aspx
8 2. TEORIJSKE OSNOVE Group) su dva standarda iz oblasti automobilske industrije. Oba baziraju interfejse na istom horizontalnom standardu BOD (Business Object Documents), kog propisuje Open Applications Group (OAG) 3. Iako imaju istu bazu i sličan domen primene, za međusobnu komunikaciju po ova dva standarda potrebna je integracija (jedan primer semantičke integracije ova dva standarda dat je u [8]). Slična relacija može se uvideti između navedenih standarda AIRM i AIDX, koji služe istoj industriji, ali za različite namene i koriste različite formate. Tako, čak i kada neke dve aplikacije po specifikaciji podržavaju određeni standard, u praksi se mogu javiti problemi pri pokušaju razmene podataka. Na primer, [83] analizira mogućnost međusobne razmene modela između pet alata za UML modelovanje, koji podržavaju XML Model Interchange 2.0 (XMI) format za izvoz i uvoz modela: (1) Borland Together Architect 2006 for Eclipse, (2) EclipseUML Free Edition, (3) IBM Rational Software Architect 6.0, (4) MagicDraw Community Edition version 10.5 i (5) Altova UModel 2006. Rezultati razmene između svakog para ovih aplikacija (uključujući ponovni uvoz u istu) prikazani su u tabeli 2.1. Zbog različitog tumačenja standarda, razlika u implementaciji ili grešaka prilikom implementacije standarda, u 48% (12/25) pokušaja razmena modela među heterogenim alatima bila je neuspešna. Tabela 2.1: Rezultati razmene modela korišćenjem iste verzije XMI ( - uspešno, - neuspešno). Izvor: [83] Uvoz Izvoz Borland Eclipse Rational MagicDraw UModel Borland Eclipse Rational MagicDraw UModel Dodatni problem može predstavljati činjenica da se standardi vremenom menjaju. Iako alati podržavaju isti standard, verzije koje podržavaju se mogu razlikovati. Tabela 2.2 pokazuje, mahom bezuspešne, pokušaje da se u pet ranije navedenih UML alata uvezu modeli koji su izvezeni iz alata koji podržavaju stariju verziju XMI formata. U svega 4% (2/45) uvezen je nenarušen model, dok je u dodatnih 9% (4/45) zabeležen delimičan uspeh (neki od problema koji su se javljali su: gubitak veza, nepotpuni dijagrami, izmenjeni nazivi atributa, pojava dodatnih klasa). 3 https://oagi.org
2.1. VRSTE INTEGRACIJE 9 Tabela 2.2: Prikaz kompatibilnosti unazad pet UML alata. Izvor: [83] Uvoz Izvoz Borland Eclipse Rational MagicDraw UModel ArgoUML Fujaba Umbrello Artisan Poseidon Rhapsody Rose 1.0 Rose 1.1 Visio Middleware Middleware se uopšteno može definisati kao skup zajedničkih usluga, koje omogućavaju aplikacijama i krajnjim korisnicima da razmenjuju podatke i informacije, obično putem računarske mreže. Može se reći i da je middleware softver koji vrši medijaciju između aplikacije i mreže, upravljajući međusobnim vezama disparatnih aplikacija koje se nalaze na heterogenim računarskim platformama 4. Middleware se može klasifikovati u sledeće kategorije [66, 81]: mehanizmi pozivanja udaljenih procedura, middleware orijentisan ka podacima (data-oriented middleware), middleware orijentisan ka komponentama (component-oriented middleware), middleware orijentisan ka porukama (message-oriented middleware), middleware orijentisan ka servisima (service-oriented middleware) i aplikativni serveri i monitori transakcija. DCE-RPC Distributed computing environment (DCE) [124] je skup standarda i tehnologija koje razvija The Open Group 5 koji predstavljaju infrastrukturu za razvijanje distribuiranih sistema. DCE je zasnovan na pozivima udaljenih procedura (RPC). Koristi klijent-server arhitekturu i pruža servise niskog nivoa. Serveri implementiraju telo procedura, a interfejse izvoze u globalni hijerarhijski cell directory service (CDS). Klijenti pozivaju CDS tražeći određenu funkciju i, nakon autentifikacije i autorizacije dobijaju podatke neophodne za pozivanje procedure na serveru. Ova procedura je transparentna za korisnika. Middleware orijentisan ka podacima Jedan primer middleware-a orijentisanog ka podacima su ODBC (Open Database Connectivity) API, namenjen pristupu bazama podataka, kao i njegov ekvivalent za Javu, JDBC (Java Database Connectivity) [56]. Cilj ovih specifikacija je da omoguće radnje sa bazom podataka putem SQL jezika, nezavisno od konkretnog sistema za upravljanje bazama podataka, kao što je prikazano na slici 2.2.
10 2. TEORIJSKE OSNOVE Aplikacija ODBC API ODBC Driver manager ODBC Driver ODBC Driver ODBC Driver DB DB DB Slika 2.2: Pristup aplikacije bazi podataka posredstvom ODBC. Još jedan primer middleware-a orijentisanog ka podacima su ETL (Extract, Transform, Load) alati [134]. Ovi alati se koriste kako bi se podaci dobavili (ekstrahovali) iz raznih izvora, zatim validirali, transformisali (očistili, deduplicirali, agregirali, deagregirali, itd) i učitali u skladište podataka (data warehouse), nakon čega je moguće nad njima sprovesti analize [84]. Middleware orijentisan ka komponentama Ova vrsta middleware-a namenjena je povezivanju distribuiranih komponenti [66]. S obzirom da se najčešće implementira u objektnoorijentisanim okruženjima, naziva se i objektno-orijentisani middleware. Jedan primer ove klase middleware-a je CORBA (Common Object Request Broker Architecture). CORBA [28] je standard razvijen od strane Object Management Group (OMG). Broker (Object request broker, ORB) je mehanizam putem kog objekti upućuju zahteve i dobijaju odgovore, nezavisno od toga da li je drugi objekat na istom računaru ili na mreži [126]. Mehanizam je transparentan za klijenta. Interfejsi se definišu korišćenjem IDL (Interface Definition Language), deklarativnog jezika koji je nezavisan od programskog jezika koji se koristi za implementaciju. Brokeri komuniciraju međusobno koristeći Internet Inter-ORB Protocol (IIOP). Neki od jezika za koje postoji CORBA implementacija su C, C++, Smalltalk, Ada 95, Java, COBOL, Modula-3, Perl i Python [135]. Nepotpune implementacije i greške u implementacijama brokera dovele su do raznih problema u praktičnoj upotrebi ove tehnologije. U [61] konstatuje se da je CORBA prešla put od vrhunske tehnologije u svojim ranim danima, preko popularnog middleware-a, do relativne zastarelosti. Još neki primeri ove vrste middleware-a su Microsoft [D]COM ([Distributed] Component Object Model) i Sun (sada Oracle) Java RMI. 4 https://web.archive.org/web/20120629211518/http://www.middleware.org/whatis.html 5 http://www.opengroup.org/dce/
2.1. VRSTE INTEGRACIJE 11 Middleware orijentisan ka porukama Message-oriented middleware (MOM) namenjen je izgradnji slobodno spregnutih (loosley coupled) integracionih rešenja. Sistemi koriste poruke kako bi razmenjivali pakete podataka. Poruke se mogu razmenjivati sinhrono ili asinhrono, što je češće slučaj. Osnovni koncepti ove paradigme su [62]: Kanal - definisan put kojim se prenose poruke. Aplikacije šalju poruke u određeni kanal i primaju poruke iz određenog kanala. Poruka - atomični paket podataka koji se prenosi putem kanala. Dostava u više koraka (multi-step delivery) - nakon što jedna aplikacija pošalje poruku, pre nego što je neka druga aplikacija primi, nad porukom mogu biti preduzete određene radnje - validacija, transformacija, preusmeravanje, logovanje, itd. Rutiranje - pojedinačni koraci u obradi neke poruke mogu se učiniti nezavisnim jedni od drugih korišćenjem rutera, komponenti koje primaju poruku na jednom kanalu i vrše njeno ponovno slanje na nekom drugom kanalu, pri čemu se kanal u koji će poruka biti preusmerena bira na osnovu definisanih uslova. Transformacija - ukoliko aplikacije koje komuniciraju ne koriste isti oblik podataka, mogu se koristiti prevodioci (Message Translator), komponente koje prevode poruke iz jednog formata u drugi. Pristupne tačke (endpoints) - komponente koje predstavljaju most između ugrađenih interfejsa aplikacije i sistema za razmenu poruka. Po [66], postoje tri osnovna vida implementacije MOM: direktna razmena (message passing) [113] - je najjednostavnija organizacija, gde se poruke šalju u jednom smeru, bez uspostave konekcije (na primer, korišćenjem UNIX sistemskih funkcionalnosti kao što je pipeline za ulančavanje i povezivanje procesa ili sličnih funkcionalnosti u drugim operativnim sistemima), redovi čekanja (message queueing) [116] - proširuju direktnu razmenu, uvodeći perzistenciju poruka i automatsko ponovno slanje u slučaju da primalac nije odmah na raspolaganju i objava i pretplata (publish/subscribe) [85] - učesnici u komunikaciji mogu objaviti vrstu sadržaja koju proizvode, a drugi učesnici se mogu pretplatiti na takav sadržaj; omogućena je komunikacija više-ka-više, pri čemu učesnici postaju nezavisni jedni od drugih. 2.1.1 Klasifikacija semantičkih konflikata U [98] data je klasifikacija semantičkih konflikata u heterogenim sistemima. Klasifikacija je izvedena po tri dimenzije: imenovanje, apstrakcija i nivo heterogenosti. Naglašava se potreba za semantičkim usklađivanjem strana koje učestvuju u komunikaciji. Utvrđeno je da detekcija konflikata zavisi od raspoloživog podskupa celokupnog šematskog (strukturnog)
12 2. TEORIJSKE OSNOVE i semantičkog znanja o sistemima. Kao primeri klasa semantičih konflikata navode se: strukturalne i prezentacione razlike, neusklađeni domeni i konflikti imenovanja. Neki primeri ovih klasa konflikata su: Konflikti imenovanja: sinonimi - različiti pojmovi koji imaju isto značenje, homonimi - isti ili slični pojmovi koji nemaju isto značenje, nepovezani pojmovi - su pojmovi koji postoje u nekom od sistema koji se integriše, a nisu ni homonimi ni sinonimi sa pojmovima u ostalim sistemima, pa se njihova veza ne može utvrditi na osnovu imenovanja. Konflikti nivoa apstrakcije: generalizacija - konflikt se javlja kada jedan koncept učestvuje u dva sistema na različitom nivou apstrakcije (npr. klasa Kompanija iz jednog sistema je generalizacija klase Klijent iz drugog sistema), agregacija - konflikt se javlja kada se jedna instanca iz jednog sistema mapira na više instanci u drugom sistemu. Pet klasa heterogenosti definisane su u [71]: nekompatibilnost domena, nekompatibilnost definicije entiteta, nekompatibilnost vrednosti podataka, nekompatibilnost nivoa apstrakcije i semantičke nejednakosti. U [107, 24] data je podela na dve vrlo široke kategorije konflikata: konflikte (vrednosti) podataka i konflikte šeme. 2.2 Modelom upravljan razvoj softvera Kreiranje modela sistema koji se razvija, pre kreiranja krajnjeg proizvoda, često je u raznim inženjerskim disciplinama. Inženjerski model je selektivni prikaz nekog sistema, koji predstavlja, precizno i koncizno, suštinske odlike tog sistema sa određene tačke gledišta. Modeli se mogu koristiti kako bi se bolje razumelo određeno ponašanje sistema. Modeli se mogu upotrebljavati i u svrhu komunikacije i dokumentovanja. Model građevinskog objekta, bilo da je izrađen od čvrstog kartona ili renderovan na računaru, omogućava arhitektama da krajnjim korisnicima bolje predstave svoju zamisao, kao i da lakše objasne razloge koji stoje iza određenog aspekta rešenja. Fizički model prostornog rasporeda atoma u molekulu može omogućiti predavaču hemije da lakše objasni razloge zbog kojih se dato jedinjenje ponaša na određeni način. Modeli mogu poslužiti da se uz manje troškove i za kraće vreme proveri i predvidi ponašanje nekog sistema (vozila, letelice, građevinskog objekta) u širokom dijapazonu uslova u kojima se taj sistem može naći u toku korišćenja. Na primer, model novog tipa aviona prvo se testira u aerotunelima, laboratorijskim postrojenjima koja omogućavaju da se utvrdi kako se konstrukcija krila, tela i drugih elemenata aviona ponaša u raznim aerodinamičkim uslovima - pri raznim brzinama kretanja, raznim položajima aviona u odnosu na smer kretanja
2.2. MODELOM UPRAVLJAN RAZVOJ SOFTVERA 13 i slično. Ovakvi testovi na modelima omogućavaju da se utvrdi da li je konstrukcija aviona bezbedna za dalje ispitivanje u punoj veličini i sa ljudskom posadom. Isti testovi omogućavaju da se poredi ponašanje više različitih rešenja i da se njihovom postupnom modifikaciom dođe do optimuma u određenim kriterijumima, kao što je potrošnja goriva pri brzini krstarenja i bezbedan let pri brzini sletanja. Slično, model upravljačke kabine aviona u realnoj veličini, omogućava da se još u ranim fazama razvoja novog tipa aviona ispita kako položaj raznih upravljačkih komandi i instrumenata utiče na bezbednije i efikasnije obavljanje letačkih zadataka. Na kraju, ukoliko je model dovoljno detaljan, može poslužiti i kao specifikacija na osnovu koje se izrađuje krajnji proizvod [121]. Inženjerski modeli su deskriptivni modeli ukoliko služe za bolje razumevanje pojava, komunikaciju i predviđanje pojava i ponašanja. Modeli su preskriptivni ukoliko mogu služiti kao specifikacija za izgradnju krajnjeg sistema [118]. Jedan model može u isto vreme biti i deskriptivni i preskriptivni model. Jezici za modelovanje Jezici za modelovanje su računarski jezici namenjeni konstruisanju modela sistema i njihovog okruženja. Kada govorimo o jezicima namenjenim modelovanju softverskih sistema, prva generacija ovih jezika mahom je služila za kreiranje samo deskriptivnih modela. Ovi modeli služili su samo kao neformalne skice i kao deo tehničke dokumentacije, ali nisu bili formalno definisani, pa je tumačenje moglo biti dvosmisleno. Time ne samo da nisu bili dovoljan izvor za implementaciju modelovanih sistema, već su mogli biti i izvor pogrešne komunikacije. Njihova jednostavnost ujedno može da stvori i lažnu sliku o tome da i druga strana verovatno na isti način shvata značenje korišćenih elemenata jezika (simbola, veza). Time je i deskriptivna uloga neformalnih modela ugrožena. Ovu odliku neformalnih modela opisao je Bertrand Meyer: [...] the good thing about bubbles and arrows, as opposed to programs, is that they never crash [91]. Formalni jezici za modelovanje treba da imaju razumljive i precizne semantičke osnove, mogu se formalno, matematički, analizirati, nedvosmisleni su i sadrže dovoljno detalja da pored deskriptivne imaju i preskriptivnu ulogu. Jezik za modelovanje se sastoji od: apstraktne sintakse: koncepata jezika (npr. Sistem, Klasa, Paket, Veza, Račun) i pravila za kombinovanje jezičkih koncepata konkretne sintakse, koja služi za predstavu i zapisivanje: grafički simboli, ključne reči i mapiraju se na koncepte apstraktne sintakse
14 2. TEORIJSKE OSNOVE semantike, koja određuje značenje koncepata jezika: semantički domen i semantičko mapiranje domena na koncepte jezika. Jedan jezik može imati više konkretnih sintaksi. Za isti jezik moguće je razviti i tekstualnu i grafičku notaciju [33]. Model kao osnova za razvoj softvera Inženjerstvo upravljano modelima (Model-driven engineering, MDE) model tretira kao deo implementacije softverskog sistema. Postoje dva osnovna načina na koji se modeli na visokom nivou apstrakcije mogu koristiti kao direktna osnova za dobijanje krajnjeg proizvoda. Prvi način je da se model određenim automatizovanim postupkom, korišćenjem alata, prevede (transformiše) u kod pisan programskim jezikom opšte namene. Drugi način je da se sam model izvršava, odnosno interpretira. Pored transformacije u jezik opšte namene, modeli se mogu transformisati i u druge modele. Deskriptivni modeli, kreirani u svrhu dokumentovanja i komunikacije, neretko nastaju post festum. Čak i kada model prethodi implementaciji, često se dešava da, nakon što se implementacija izmeni (zbog uočenih nedostataka ili izmenjenih zahteva) model ne bude ažuriran. Takav model može postati i prepreka za razumevanje funkcionisanja sistema. Nasuprot tome, preskriptivni model u svetlu MDE je deo implementacije. Od modela se za kratko vreme dobija živa aplikacija koju je moguće probati i testirati. Ukoliko dođe do izmene zahteva ili se uoče nedostaci, sledeća iteracija kreće od izmene modela do njegove ponovne transformacije u izvršiv oblik ili direktnog izvršavanja modela. Ukoliko se uoči da nastali problem nije moguće opisati i realizovati raspoloživim jezikom za modelovanje, taj jezik se može izmeniti, ili se može za dati aspekt sistema odabrati drugi jezik. Jezici specifični za domen Jezici specifični za domen - JSD (Domain-specific language, DSL) umesto opštih pojmova, prilagođenih rešavanju širokog spektra programskih problema (klase, objekti, paketi, metode i sl.) koriste koncepte koji su bliski oblasti konkretnog problema (npr. radnik, račun, knjiga, uređaj). Sintaksa ovih jezika može biti tekstualna, tabelarna, grafička ili kombinovana [136]. Modelovanje specifično za domen (Domain-specific model, DSM) je metodologija zasnovana na MDE i JSD. Domen od interesa može biti tehnički (horizontalni), što se odnosi na određeni aspekt razvoja: korisnički interfejs, perzistencija, ponašanje, bezbednost, ili funkcionalni (vertikalni), što se odnosi na neku određenu oblast primene za koju se razvija rešenje: bankarstvo, medicina, robotika, proizvodna industrija. U [133, 136, 73] navode se neke od prednosti korišćenja JSD i DSM.
2.2. MODELOM UPRAVLJAN RAZVOJ SOFTVERA 15 Uključivanje domenskih eksperata. Ukoliko su koncepti jezika i način njihovog zapisivanja bliski načinu na koji se ti koncepti inače koriste u određenoj oblasti, olakšana je komunikacija i saradnja između onih koji razvijaju softver i onih koji poseduju znanje iz date oblasti. Povećana produktivnost. Kada se JSD jednom razvije, njegovo korišćenje ubrzava razvoj aplikacija iz datog domena. Istraživanja [73] pokazuju da se produktivnost može povećati i do 1000 %. Povećanje kvaliteta. S obzirom da je jezik vezan za domen, pravila koja važe u domenu mogu biti uključena u alate koji proveravaju validnost modela. Lakše učenje jezika. Povećana čitljivost modela. Isti izvori navode i izazove povezane sa korišćenjem JSD-ova. Cena razvoja. Korišćenju jezika prethodi proces dizajna i implementacije, kao i razvijanje propratnih alata. Balansiranje resursa neophodnih za razvoj jezika i dobiti koja proizlazi iz njegovog budućeg korišćenja treba da uključi analizu mogućnosti za ponovno korišćenje jezika. Ukoliko sam domen nije dobro dokumentovan, proces razvoja JSD-a će pored navedenih prednosti vezanih za softversko rešenje imati i pozitivan nusprodukt u vidu formalne dokumentacije domena od interesa. Neophodno znanje. Ljudi koji razvijaju jezik moraju biti upoznati sa oblastima dizajna jezika, alatima i formalizmima za specificiranje sintakse, kao i alatima za transformisanje ili interpretaciju jezika. Zavisnost od alata. U razvoju jezika se često koristi mnoštvo alata. Održavanje jezika može biti otežano ukoliko prestane održavanje nekog od korišćenih alata. Takva mogućnost je smanjena, ali i dalje prisutna ukoliko se koriste alati otvorenog koda. Na kraju, napomenimo činjenicu da će svaka greška ili nedostatak, koji je uveden kroz alat koji vrši transformaciju ili izvršavanje modela, biti propagiran na sve softverske sisteme za čije razvijanje je korišćena data verzija alata. Iz ovoga proističe da alati koji se koriste, ali i ciljni kod koji se generiše moraju biti podrobno pokriveni testovima. Time će i generisani sistemi biti takođe pokriveni testovima. Na kraju, ukoliko se neko neželjeno ponašanje zapazi na jednom od sistema za koje je generisan kod, ispravke se lakše mogu uvesti u sve sisteme u čijem razvoju je korišćen isti JSD i skup alata. Generisanje koda U ovoj sekciji opisani su uobičajeni načini za transformaciju modela u izvorni kod, bilo da se radi o modelu koji je definisan tekstualnim ili grafičkim jezikom. Prvi korak je čitanje modela. Ukoliko je za modelovanje razvijen poseban alat, čitanje modela se može obavljati direktno, iz radne memorije alata. Ukoliko je model zadat
16 2. TEORIJSKE OSNOVE tekstualnim jezikom, izvorni fajlovi se parsiraju. Ukoliko je u pitanju UML model, on se može čitati kreiranjem dodatka (plug-in) za alat kojim je model kreiran, ukoliko sam alat to podržava. Ovakvi alati uobičajeno poseduju API kojim je moguće pročitati i manipulisati elementima modela u radnoj memoriji, u internoj reprezentaciji tog alata. Ukoliko alat ne podržava ovaj način dobavljanja modela, model se može izvesti iz alata u XML Metadata Interchange (XMI) formatu [103]. XMI standard se može koristiti za perzistenciju i razmenu bilo kojih jezika koji su bazirani na Meta Object Facility (MOF) [104, 65]. Nakon čitanja, model se analizira. U ovom koraku moguće je sprovesti validaciju modela. Nakon sprovedene analize, model se može transformisati u oblik koji je bliži ciljnoj platformi. Ovime se olakšava dalja manipulacija i generisanje koda, a komponenta koja vrši samo generisanje se pojednostavljuje. Rezultat ove transformacije može biti interni za alat, a može biti i drugi model, kojim je moguće dalje nezavisno manipulisati. Sledeći korak je generisanje izvornog koda za odabrani ciljni jezik i platformu. U ovu svrhu se obično koriste obrađivači šablona (template engine). Šablon sadrži tekst koji će se naći u ciljnoj datoteci, kao i označena mesta na koja se upisuje tekst koji je rezultat konkretnih elemenata modela. Svaki konkretan obrađivač šablona (Free marker, Jinja, T4 Templates, itd.) ima definisan jezik kojim se pišu šabloni. Ovi jezici mogu pored iskaza za umetanje prostih podataka sadržati i petlje, grananja, a neki obrađivači šablona nude i napredne mogućnosti poput nasleđivanja šablona. Listing 2.1 sadrži FreeMarker šablon koji rezultuje Java klasom popunjenom poljima iz modela. 1 package ${ c l a s s. typepackage } ; 2 3 ${ c l a s s. v i s i b i l i t y } c l a s s ${ c l a s s. name} { 4 <# l i s t p r o p e r t i e s as p r o p e r t y> 5 <#i f p r o p e r t y. upper == 1 > 6 ${ p r o p e r t y. v i s i b i l i t y } ${ p r o p e r t y. type } ${ p r o p e r t y. name} ; 7 <#e l s e i f p r o p e r t y. upper == 1 > 8 ${ p r o p e r t y. v i s i b i l i t y } Set<${ p r o p e r t y. type }> ${ p r o p e r t y. name} 9 = new HashSet<${ p r o p e r t y. type }>( ) ; 10 <#e l s e> 11 <# l i s t 1.. p r o p e r t y. upper as i> 12 ${ p r o p e r t y. v i s i b i l i t y } ${ p r o p e r t y. type } ${ p r o p e r t y. name}${ i } ; 13 </# l i s t> 14 </# i f> 15 </# l i s t> 16 } Listing 2.1: Primer FreeMarker šablona U praksi se često javlja potreba da neki deo softverskog sistema bude ručno izmenjen u odnosu na generisani kod, na primer ukoliko je teško ili neisplativo određenu funkcionalnost realizovati u sklopu jezika za modelovanje i u pratećim alatima. Za ovakve slučajeve neophodno je osmisliti i primeniti mehanizam za kombinovanje ručno pisanog i generisanog koda. Osnovni cilj ovog mehanizma treba da bude očuvanje ručno implementiranih delova nakon ponovnog generisanja koda na osnovu (izmenjenog) modela. Uporedni prikaz raznih mehanizama ove vrste dat je u [52].
2.3. SEMANTIČKI VEB 17 2.3 Semantički veb Veb (svetska mreža, World Wide Web) sadrži veliku količinu dokumenata, mahom u obliku hiperteksta. Hipertekst, putem hiperlinkova, omogućava onome ko čita jedan takav dokument, da dođe do povezanog sadržaja koji se nalazi na drugom mestu u istom ili u drugom dokumentu. Većina podataka, sadržanih u ovim dokumentima, dostupna je u formatima koji su prilagođeni čitanju i korišćenju od strane ljudi, ali su teški za mašinsko čitanje i obradu. Motivacija za nastanak semantičkog 6 veba bila je uvođenje strukture i standardizovane reprezentacije značenja dostupnog sadržaja [12]. Na ovaj način, softverski agenti bi bili u mogućnosti da sakupe podatke iz raznih izvora i da na osnovu tih podataka obavljaju poslove za koji zahtevaju informacije dostupne na raznim mestima na vebu. Druga posledica raspoloživosti vezivanja semantike za mašinski čitljive podatke jeste da različiti agenti mogu da razmenjuju podatke međusobno, iako ni jedan od agenata koji učestvuju u ovoj razmeni nije dizajniran sa eksplicitnim znanjem o ostalim agentima. Iz ovoga se vidi jasna sličnost sa osnovnim problemom koji se javlja u integraciji aplikacija i motivacija da se mehanizmi prvobitno namenjeni primeni u semantičkom vebu iskoriste u oblasti integracije. U semantičkom vebu važe sledeće pretpostavke: nejedinstvenost imena - isti resurs može imati različita imena u različitim kontekstima i otvoreni svet - nove informacije mogu postati dostupne u bilo kom trenutku. Ontologija Termin ontologija pozajmljen je iz filozofije, gde označava disciplinu koja izučava prirodu bivstvovanja, postojanja, nastajanja, bitka, osnovne kategorije postojanja i odnose između tih kategorija [19]. U računarske nauke prvi put je uveden na polju računarske inteligencije u [53], gde Gruber definiše ontologije kao eksplicitne specifikacije konceptualizacije. Ontologija je definisana još, od strane Borsta, i kao formalna specifikacija deljene konceptualizacije [16]. Pod pojmom konceptualizacije podrazumeva se apstraktan pogled na svet koji se želi predstaviti. Eksplicitno u Gruberovoj definiciji znači da su svi elementi ontologije eksplicitno definisani. Formalna specifikacija podrazumeva postojanje jezika, sa formalno definisanom sintaksom i semantikom, koji se može koristiti za specifikaciju ontologije, čime se omogućava da ona bude mašinski čitljiva, da se može mašinski obrađivati, prevoditi, interpretirati i izvršavati. Jezici za definisanje ontologija, korišćeni u semantičkom vebu su: deskriptivna logika, F-logika, RDF, OWL i SWRL (Semantic Web Rule Language). Ontologije se mogu klasifikovati po nivou opštosti [54] na: ontologije višeg nivoa (Upper Ontologies) definišu opšte koncepte realnog sveta, nezavisno od domena (npr: prostor, vreme), 6 semantika - nauka o značenju
18 2. TEORIJSKE OSNOVE Slika 2.3: Stek tehnologija semantičkog veba. Izvor: wikimedia. domenske ontologije (Domain Ontologies) specijalizacijom koncepata datih u ontologijama višeg nivoa, definišu rečnik koncepata specifičnih za određenu oblast, ontologije zadatka (Task Ontologies) specijalizacijom koncepata datih u ontologijama višeg nivoa, definišu rečnik pojmova potrebnih za opisivanje generičkih zadataka ili aktivnosti i aplikativne ontologije (Application Ontologies) opisuju konkretne aplikacije, pri čemu koncepti ontologije odgovaraju ulogama entiteta iz domena te aplikacije. Deskriptivna logika (Description Logic, DL) je podskup logike prvog reda i predstavlja familiju formalizama namenjenih za predstavu znanja. DL definiše koncepte (unarne predikate) i uloge (binarne relacije). Konstruktori omogućavaju da se korišćenjem atomičkih koncepata i uloga izgrade kompleksni koncepti. Skup terminoloških aksioma naziva se TBox. Skup asertivnih formalizama naziva se ABox.
2.3. SEMANTIČKI VEB 19 F-logika (Frame Logic) je jezik za reprezentaciju znanja i formalizama za ontologije [74]. Zasniva se na kombinovanju konceptualnog modelovanja sa objektno-orijentisanim jezicima. Definiše kompaktnu, deklarativnu sintaksu. RDF čine: Osnovna jedinica zapisa podataka u RDF-u su uređene trojke ( triple). Svaku trojku subjekat - stvar na koju se tvrdnja odnosi, predikat - osobina subjekta i objekat - vrednost predikata. Za identifikovanje resursa koriste se internacionalni identifikatori resursa (International Resource Identifier, IRI). IRI je generalizacija uniformnog identifikatora resursa (Uniform Resource Identifier, URI) koja dozvoljava korišćenje karaktera van ASCII 7 standarda [35]. Jedna podvrsta URI-ja su uniformni lokatori resursa (Uniform Resource Locator, URL), koji pored identifikovanja resursa govore i gde se resurs nalazi [79]. IRI se u RDF može naći u svakom od članova trojke. Trojke je moguće predstaviti i korišćenjem usmerenih grafova. Čvorovi grafa predstavljaju subjekte i objekte, dok označene grane usmerene od čvora subjekta do čvora objekta predstavljaju predikate. Vizuelnu reprezentaciju čvorova takvog grafa i veza između čvorova moguće je raspoređivati na automatizovan način tako da bude pogodna za lako čitanje i razumevanje [132]. Identifikatori koji pripadaju prostoru imena RDF čine standardne identifikatore. Predikat rdf:type označava da objekat treba tretirati kao tip subjekta. Primer: mpi:ferrari rdf:type mpi:car Predikat rdf:property označava da prvi član trojke treba tretirati kao predikat. 7 American Standard Code for Information Interchange je nastao kako bi se olakšao prenos teksta teleprinterima, koji su do uvođenja ovog standarda koristili različite sisteme kodovanja u zavisnosti od proizvođača. Standard je izgrađen oko engleskog alfabeta. Za tekstove pisane ovim alfabetom, rešava mnoge praktične probleme, poput lakog pretvaranja malih u velika slova i obratno. Međutim, za pisanje i razmenu teksta koji sadrži simbole van engleskog alfabeta, neophodno je koristiti određenu kodnu stranu, odnosno šemu koja mapira neophodne dodatne karaktere na mesta manje korišćenih karaktera iz gornje polovine ASCII tabele. Ovakvo rešenje, međutim, zahteva da obe strane u komunikaciji znaju koja je kodna strana korišćena, jer se to ne može zaključiti iz samog prenetog teksta. Ove probleme rešava Unicode, koji uz to omogućava i korišćenje pisama i simbola koji ne mogu da se mapiraju na proširene ASCII karaktere, čija je dužina ograničena na 8 bita.
20 2. TEORIJSKE OSNOVE Primer: mpi:isfrontwheeldrive rdf:type rdf:property Jezik RDF Schema RDF Schema (RDFS) [20, 55] definiše kako treba interpretirati grafove koje definiše RDF, odnosno pruža rečnik za modelovanje podataka. Osnovni koncepti i apstraktna sintaksa definisani su u [29]. Semantika jezika je definisana u [58]. Neke od konkretnih sintaksi su Turtle [11], TriG [23] i JSON-LD [72]. RDFS je proširenje RDF i definisan je korišćenjem RDF sintakse. Definiše mehanizme za opisivanje grupa srodnih resursa i njihovih međusobnih odnosa. Način na koji RDFS definiše klase i osobine entiteta obrnut je u odnosu na uobičajeni pristupa objektno-orijentisane paradigme. Umesto definisanja klase putem osobina koje ona sadrži, RDFS definiše osobine po tome kojim klasama resursa mogu da pripadaju. Jedna posledica ovakvog pristupa je da definicija postojećeg resursa može biti proširena u bilo kom trenutku i od strane bilo koga, što se uklapa u pretpostavku o otvorenom svetu. OWL Web Ontology Language Web Ontology Language (OWL) [32] je jezik namenjen definisanju pojmova i njihove međusobne povezanosti. Ovakva reprezentacija rečnika pojmova i veza među njima naziva se ontologija. Jezik je nastao kao unapređenje jezika DAML+OIL (DARPA Agent Markup Language + Ontology Inference Layer) koji je imao istu namenu. OWL je deo steka koji sačinjavaju XML, XML-S, RDF i RDF-S. U odnosu na njih, OWL omogućuje definisanje disjunktnosti klasa, kardinaliteta, jednakosti, proširuje skup dostupnih tipova osobina klasa i omogućava dodatno opisivanje tih osobina. OWL nudi veliku ekspresivnost. Velika ekspresivnost jezika donosi sa sobom i neke poteškoće u pogledu obrade elemenata iskazanih jezikom [38]. Stoga, definisana su tri podskupa sa različitim nivoima restrikcije ekspresivnosti: OWL-Lite omogućava kreiranje hijerarhije klasifikacije i samo jednostavnih ograničenja, OWL-DL omogućava maksimalnu ekspresivnost do nivoa održane izračunljivosti, OWL Full pruža potpunu sintaktičku slobodu, ali ne garantuje izračunljivost. Navodimo neke osnovne koncepte OWL-Lite jezika [89]. Prefiksi ukazuju na to da su ovi koncepti preuzeti iz drugih jezika, poput RDF i RDF-S. Class. Klasa okuplja grupu individua koje imaju zajednički skup osobina Individual. Individue su instance klase. rdfs:subclassof. Omogućava kreiranje hijerarhije klasa. rdf:property. Osobina je binarna relacija, a u OWL-u su definisane dve podklase:
2.3. SEMANTIČKI VEB 21 owl:objectproperty. Osobina koja ukazuje na odnos dve individue. owl:datatypeproperty. Osobina koja ukazuje na odnos individue i tipa podataka rdfs:subpropertyof. Osobine, poput klasa, takođe mogu formirati hijerarhije. rdfs:domain. Domen ograničava na koje individue osobina može da se primeni. rdfs:range. Raspon ograničava koje individue mogu biti postavljene kao vrednost osobine. SPARQL (SPARQL Protocol and RDF Query Language) je jezik za zadavanje upita nad RDF ontologijama [57]. SPARQL protokol, koji služi za izvršavanje SPARQL operacija zasnovan je na HTTP protokolu. SPARQL Endpoint je URL putem kog se mogu zadavati SPARQL upiti. Upit se sastoji iz zaglavlja i tela. Telo se sastoji od kolekcije RDF izraza. Postoje sledeći tipovi upita: SELECT upiti se koriste za dobavljanje sirovih vrednosti u formi tabele, CONSTRUCT rezultuje RDF grafom nastalim od elemenata dostupnih endpoint-u za koje je tačan uslov upita, ASK upiti rezultuju odgovorom da li je tvrdnja upita tačna ili netačna (odnosno, da li postoji trojka koja ga zadovoljava), DESCRIBE upit rezultuje trojkom koja ispunjava uslov upita Postoje i CREATE, INSERT, UPDATE i DELETE upiti, namenjeni ažuriranju elemenata baze znanja dostupne endpoint-u. Semantičko rezonovanje Jedna od ključnih posledica formalne prirode definisanja semantike u semantičkom vebu je mogućnost semantičkog rezonovanja ili rasuđivanja (semantic reasoning). Rezonovanje podrazumeva izvođenje logičkih posledica iz skupa činjenica ili aksioma. Postoje brojni softverski alati i biblioteke koji omogućavaju automatizovan proces semantičkog rezonovanja. Pored izvođenja zaključaka, isti alati se obično mogu koristiti i za validaciju ontologija [106]. Postoje i alati koji za rasuđivanje koriste skup zadatih pravila. Ovakav alat naziva se rule engine. Moguće je i kombinovanje ova dva pristupa [49]. Iako manipulacija samim ontologijama izlazi van okvira ovog istraživanja, ukratko ćemo prikazati nekoliko implementacija ovih alata, kao osvrt na procese koji se mogu koristiti, kako bi se zadovoljila naša osnovna pretpostavka - postojanje ontologije koja opisuje aplikacije koje se integrišu.
22 2. TEORIJSKE OSNOVE Pellet Pellet [108, 127] je jedna implementacija semantic reasoner-a. Nastao je iz neophodnosti da se podrže neki osnovni principi semantičkog veba, ali i neke praktične potrebe koje se na njemu javljaju. Na primer, neki njegovi prethodnici, iako su implementirali efikasnije algoritme, nisu poštovali pretpostavku nejedinstvenosti imena, nisu omogućavali rad sa XML Schema tipovima podataka i slično. Pellet, između ostalih, podržava sledeće funkcionalnosti: analizu i oporavak ontologije - proverava da li ontologija zadovoljava ograničenja koja nameće OWL DL i pomoću niza heuristika pokušava da predloži načine na koji se OWL Full ontologija može svesti na DL restrikciju, rezonovanje nad tipovima podataka - omogućava validaciju tipova definisanih XML Schema mehanizmima, implikaciju i konjuktivne ABox upite. Jena Apache Jena je slobodan radni okvir otvorenog koda za rad sa ontologijama u programskom jeziku Java. Njegove osnovne funkcionalnosti opisane su kasnije, u 5.1. Jena uključuje nekoliko internih implementacija resoner-a 8 tranzitivni - omogućava skladištenje i iteraciju nad strukturama koje sadrže klase i njihove osobine, RDFS - implementira konfigurabilan skup RDFS implikacija, OWL, OWL Mini i OWL Micro - nepotpune implementacije rasuđivanja nad OWL-Lite i generički - rasuđivač koji operiše nad pravilima definisanim od strane korisnika. Pored ugrađenih, Jena poseduje i generički API za razvoj novih implementacija reasonera, kao i mogućnost uključivanja eksternih implementacija, poput Pelleta i drugih. 8 https://jena.apache.org/documentation/inference
3 Pregled trenutnog stanja u oblasti U prvom delu ovog poglavlja prikazani su klasični pristupi integraciji, pristupi koji koriste principe modelom vođenog inženjerstva, pristupi koji koriste principe semantičkog veba, kao i oni koji kombinuju više pristupa. Neka od navedenih rešenja su namenjena prevashodno za integraciju podataka, što je posebna oblast, ali se njihove ideje mogu koristiti i u integraciji aplikacija. U drugom delu poglavlja prikazani su alati za spajanje i mapiranje (poravnanje) ontologija. Kako je pretpostavka za upotrebu radnog okvira prikazanog u poglavlju 4 postojanje jedinstvene (objedinjene) ontologije, koja se odnosi na sve aplikacije koje se integrišu, ovi alati su od značaja u slučaju da postoje ontologije koje opisuju pojedinačne aplikacije. 3.1 Pristupi integraciji Formalna karakterizacija i specifikacija radnog okvira za razmenu konteksta - Context interchange framework, COIN [48] predstavlja posredničku strategiju za pristup podacima u kojoj se semantički konflikti između heterogenih sistema otkrivaju i rešavaju upotrebom kontekstnog posrednika. Svrha posrednika je da poredi kontekste bilo koja dva sistema koji učestvuju u razmeni podataka. Korišćenjem formalizama uvedenih kroz COIN radni okvir semantika pojedinačnog konteksta se može koristiti za rezonovanje o semantičkim razlikama heterogenog sistema u kom taj kontekst učestvuje. Pregled arhitektura i tehnologija za integraciju distribuiranih poslovnih aplikacija, uz prikaz njihovih mana i vrlina, dat je u [59]. Pod distribuiranom aplikacijom podrazumeva se aplikacija koja se nalazi na više od jednog računara u mreži. Naglašava se da, pored činjenice da su aplikacije koje komuniciraju mrežom heterogene i sama komunikaciona mreža je često heterogena i povezuje razne vrste uređaja različitim medijumima i protokolima. Navodi se da poslovni subjekti koji uspešno sprovedu integraciju svojih informacionih sistema imaju jasnu 23
24 3. PREGLED TRENUTNOG STANJA U OBLASTI prednost zbog bolje mogućnosti da se podaci kojima kompanija raspolaže iskoriste, čime se stvaraju šanse za veću efikasnost i profit. Ističe se i pojava da se tehnike za integraciju poslovnih aplikacija više ne koriste samo unutar jedne organizacije, već i za povezivanje aplikacija koje koriste različite organizacije. Tehnologije za integraciju autori dele na: Integraciju komunikacionog sloja - uspostavlja se razmena podataka između aplikacija korišćenjem protokola poput HTTP ili IIOP. Integraciju podataka - prenos ili povezivanje podataka koji se nalaze u heterogenim izvorima podataka - na različitim računarima, pod različitim operativnim sistemima i sistemima za upravljanje bazama podataka. Obično se prepoznaju izvorna šema, ciljna šema i mapiranje između njih. Izazov koji se pri tom javlja je neophodnost razumevanja velikih i komplikovanih šema, kao i potrebu za održavanjem mapiranja ukoliko se jedna od šema promeni. Itegraciju sloja poslovne logike - može se podeliti na osnovnu koordinaciju, funkcionalne interfejse, poslovne protokole i nefunkcionalne osobine. Obično se za olakšavanje ove vrste integracije koriste middleware rešenja, koja omogućavaju da se elementi visokog nivoa, apstrakcije izoluju od stalnih promena na hardverskom nivou, u operativnim sistemima, protokolima, itd. Integraciju prezentacionog sloja - glavni cilj ovakve integracije je kreiranje korisničkog interfejsa koji omogućava upotrebu različitih aplikacija sa jednog mesta, dajući utisak da, inače nezavisne, aplikacije čine jednu celinu. Još jedna podela vidova integracije data je u [66]. Autori daju pregled sintaktičkih i semantičkih pristupa integraciji. Klasifikacija integracionih stilova organizovana je u odnosu na četiri dimenzije, kao što je prikazano na slici 3.1. Po dimenziji nivoa integracija može biti hardverska, platformska, sintaktička i semantička. Integracija na nivou hardvera, na primer omogućava premošćavanje razlika u pogledu fizičkih veličina koje se koriste za predstavljanje signala za prenos ili skladištenje (struja, napon, intenzitet svetla ili radio talasi), vrste modulacije, brzine prenosa i slično. Platformska integracija razrešava način na koji različite platforme tumače ove signale - dužinu reči, redosled bita u reči, redosled reči u slogovima i drugo. Sintaktička integracija se bavi i organizacijom struktura podataka koje koriste sistemi koji se integrišu, dok sintaktička uzima u obzir i značenje, odnosno smisao tih struktura. Po dimenziji nivoa, integracija se može obavljati unutar neke organizacije ili između različitih organizacija. Po dimenziji sloja, mogu se razmatrati (1) samo podaci koji su ulaz ili izlaz neke aplikacije, (2) poruke koje aplikacija može da razmenjuje sa drugim aplikacijama ili samom sobom ili (3) čitavi procesi u kojima aplikacije učestvuju. Po nivou pogleda, integracija se može posmatrati sa aspekta onoga ko vidi rezultat integracije: programer, dizajner (arhitekta softvera) ili krajnji korisnik.
3.1. PRISTUPI INTEGRACIJI 25 Nivo Opseg Semantički Sintaktički Platformski Hardverski Unutar organizacije Između organizacija Integracija Podataka Poruka Procesa Programerski Dizajnerski Korisnički Sloj Pogled Slika 3.1: Podela vidova integracije u četiri dimenzije po [66] Standard IEC 61804-1 definiše nivoe interoperabilnosti među sistemima. Prikaz ovih nivoa dat je na slici 3.2. Sistemi se posmatraju u odnosu na komunikacione protokole koje koriste, komunikacione interfejse, način pristupa podacima, tipove podataka, semantiku parametara koji se razmenjuju, funkcionalnost aplikacije i dinamičko ponašanje aplikacije. Prva četiri uslova spadaju u komunikacioni deo, dok uslovi od trećeg do sedmog spadaju u aplikativni deo. Za sisteme koji nisu kompatibilni ni po jednom od ovih osnova se kaže da su u celini nekompatibilni, dok se za sisteme koji su kompatibilni po svim osnovima kaže da su međusobno zamenljivi. Za efikasnu integraciju minimalno je potrebno da sistemi budu povezivi, odnosno kompatibilni po protokolima, komunikacionim interfejsima i pristupu podacima. Pored rešenja koja imaju za cilj kreiranje univerzalnog pristupa za integraciju aplikacija, postoji i niz usko specijalizovanih. Na primer, alat Dashboard [87] namenjen je integraciji, validaciji i vizualizaciji različitih sistema za obradu prirodnih jezika (Natural Language Processing), koji su distribuirani i izvršavaju se na heterogenim platformama. Radni okvir NEGOSEIO [68] ima za cilj uspostavljanje operabilnosti na nivou servisa. Za integraciju koja uzima u obzir razumevanje semantike i poslovne logike koristi referentne ontologije. Predložena metodologija uključuje sledeće korake: (1) prikupljanje znanja, (2) kreiranje modela, (3) kreiranje servisa, (4) puštanje servisa u rad i (5) adaptaciju servisa. Ovi koraci se obavljaju u svakom poslovnom subjektu čiji se sistemi međusobno integrišu.
26 3. PREGLED TRENUTNOG STANJA U OBLASTI Međusobno zamenjivi Interoperabilni Mogu sarađivati Povezivi Koegzistentni Nekompatibilni Dinamičko ponašanje Funkcionalnost aplikacije Semantika parametara Tipovi podataka Pristup podacima Komunikacioni interfejs Komunikacioni protokol Nivo kompatibilnosti Aplikativni deo Komunikacioni deo Slika 3.2: Nivoi interoperabilnosti po IEC 61804-1 Reč je, dakle, o pristupu koji podrazumeva njihovu međusobnu kolaboraciju i kooperaciju. Interoperabilnost se postiže ugovaranjem neophodnih izmena u sklopu pete faze. Referentna ontologija pomaže da se ustanove ove neophodne izmene. Njeno formiranje obavlja se po MENTOR metodologiji, koja obuhvata sledeće faze: formiranje leksikona, prikupljanje pojmova, izgradnja pojmovnika (glossary), izgradnja leksikona sinonima (thesaurus), formiranje referentne ontologije, prikupljanje ontologija, harmonizacija ontologija i mapiranje ontologija. Iako se ne bavi direktno integracijom aplikacija, [80] proučava kompozicione konflikte koji se javljaju u sistemima baziranim na komponentama. Jedna od osnovnih ideja ovakvog načina izgradnje sistema jeste mogućnost ponovnog korišćenja komponenti. U praksi, tehničke neusaglašenosti i razlike u specifikacijama mogu dovesti do pojave nekompatibilnosti, koje se mogu svrstati u jednu od tri kategorije: (1) konflikte tipa, (2) konflikte ponašanja i (3) konflikte osobina. Pod osobinama autori podrazumevaju opis strukture i ponašanja na višem nivou apstrakcije, nezavisno od tehničkih detalja i mehanizama komunikacije. Opisan je radni okvir koji podržava: obradu komponenti specificiranih različitim standardima i tehnologijama, identifikaciju konflikata, prevođenje kanoničkih komponenti u konkretne tehnologije i ugrađivanje u proces razvoja softvera.
3.1. PRISTUPI INTEGRACIJI 27 Autori koriste Model-driven architecture (MDA) principe transformacije između modela nezavisnog od platforme (Platform Independent Model, PIM) i modela za konkretnu platformu (Platform Specific Model, PSM). Za provere nad modelima koristi se deduktivna baza znanja, modeli se proveravaju korišćenjem proširenja F-logike zvanog Triple, dok se konflikti tipa i ponašanja detektuju eksternim alatima Haskell, LTSA (Labelled Transition System Analyser) 1, FDR (Failures-Divergences Refinement) 2, fc2tools 3 i Aldebaran 4. Projekat BIZYCLE [76, 92] predstavlja platformu za interoperabilnost i integraciju softvera i podataka. Platforma je zasnovana na principima modelom upravljanog razvoja softvera. Osnovni pristup se zasniva na rešavanju integracionih problema na višim nivoima apstrakcije. U ovu svrhu koriste se modeli na Computation Independent Model (CIM), Platform Independent Model (PIM) i Platform Specific Model (PSM) nivoima. Značajno je napomenuti da se redosled transformacija ovih modela razlikuje u odnosu na standardni MDA pristup. Kako je MDA namenjen razvoju softvera, polazi se od modela na najvišem nivou apstrakcije - CIM, na osnovu kog se razvija PIM i na kraju PSM. Međutim, pošto je ova platforma namenjena integraciji, polazna osnova su konkretan softverski proizvod ili konkretni podaci, na konkretnoj platformi. Na osnovu njih se izrađuje PSM, od kog se kreiraju modeli na višim nivoima apstrakcije, a oni se zatim koriste za analizu scenarija i generisanje rešenja. Polaznu osnovu čini i poslovni proces u kom učestvuju komponente koje se integrišu i njegova definicija je sastavni deo integracionog scenarija. Celokupan tok razvoja integracionog rešenja dat je na slici 3.3. BIZYCLE platformu čine četiri osnovna dela: skup MDA alata, repozitorijum - služi za skladištenje modela, meta-modela, specifikacija, ograničenja, dokumentacije, šablona, pravila za transformaciju, konfiguracije i njihovih metapodataka, analizator konflikata i generator koda konektora. U [125] opisan je izvršiv JSD za integraciju sistema zasnovanu na razmeni poruka. Jezik omogućava definisanje strukture, tipova i podržanih vrsta poruka, kao i upotrebu integracionih šablona. Uključeni su obrađivači poruka (Aggregator, Content Enricher, Filter, Content-based Router, Splitter, Timer i Transformer), kanali za prenos poruka (Point-to- Point i Publish-Subscribe) i šabloni razmena poruka (Out-Only, Robust Out-Only, Out- In i Out-Optional-In). Omogućeno je i definisanje izraza koji opisuju ponašanje šablona. Integracioni scenario definisan ovim jezikom prolazi kroz niz transformacija: prvo se pretvara 1 https://www.doc.ic.ac.uk/ jnm/ltsdocumention/ltsa.html 2 http://www.cs.ox.ac.uk/projects/fdr/ 3 http://www-sop.inria.fr/meije/verification/ 4 https://cadp.inria.fr/
28 3. PREGLED TRENUTNOG STANJA U OBLASTI Slika 3.3: Tok specifikacije i generisanja integracionog rešenja na BIZYCLE platformi. Izvor: [76] u Business Process Execution Language (BPEL) proces, zatim se on transformiše u Java apstraktno sintaksno stablo, zatim se ono pretvara u Java izvorni kod koji se kompajlira i uvezuje sa ostalim komponentama i izvršava na Sun GlassFish ESB. Primer korišćenja ontologija za komponente dostupne na mreži u cilju njihove integracije prikazan je u [130]. U prikazanoj studiji slučaja integrisani su različiti izvori koji daju geoinformacione podatke od interesa jedinicama na terenu. Dodavanjem klasa postojećoj ontologiji, integracija je implementirana u vremenskom opsegu od nekoliko sati. U ovom primeru cilj nije bila automatizacija, niti je razvijan radni okvir, već su ontologije korišćene ručno. Ipak, i ovakav pristup pruža korisna saznanja u pogledu korišćenja OWL ontologija u cilju poboljšanja procesa integracije. Pristup integraciji koji kombinuje korišćenje veb servisa i ontologija nazvan ODSOI (Ontology-Driven Service-Oriented Integration) dat je u [67]. Autori sugerišu pogodnu topologiju servisa i ontologija, uz viziju radnog okvira za integraciju. Radni okvir omogućava i dinamičku integraciju, što znači da je spajanje servisa ciljnih poslovnih informacionih sistema moguće za vreme izvršavanja (runtime). Jezik specifičan za domen integracije poslovnih informacionih sistema, pod nazivom Highway, predstavljen je u [75]. U pitanju je interni JSD, baziran na jeziku Clojure. Highway
3.1. PRISTUPI INTEGRACIJI 29 suštinski predstavlja još jednu konkretnu sintaksu 5 za Apache Camel platformu, na koju se prevodi. Jezik olakšava razvoj korisnicima koji su navikli na funkcionalne jezike i omogućava korišćenje ove paradigme u kontekstu razvoja integracionih rešenja. Deseto poglavlje knjige [26] predstavlja prikaz arhitektonskih obrazaca za semantičku integraciju, zasnovanih na ontologijama. U [5] razmatrana je detekcija semantičkih konflikata u veb servisima i servisno orijentisanim arhitekturama (SOA) uopšte, u slučajevima kada se razmenjuju heterogeni podaci. Kao primer semantičkog konflikta, navodi se slučaj dva javna veb servisa za dobavljanje geodemografskih podataka, koji adrese (koje su za dati domen podatak od primarne važnosti) prezentuju na drugačiji način. Ističe se da, iako je za SAOP veb servise dostupna precizna WSDL definicija strukture poruka, ona nije dovoljna za uspostavljanje mapiranja i detekciju konflikata između servisa koji različito tumače podatke. Rešenje koje predlažu autori koristi dve komponente: (1) ontologiju, koja pruža semantičke interpretacije, reprezentacije i strukturu poruka i (2) klasifikaciju semantičkih konflikata, kao vodilju za identifikaciju vrste semantičkog konflikta. Koristi se modifikovana klasifikacija nivoa heterogenosti poruka (Message Level Heterogeneities) iz [97]. Rešenje je nezavisno od domena primene. Pristup integraciji podataka zasnovan na ontologijama razmatran je u [21]. Postupak obuhvata faze prikazane na slici 3.4: (1) izgradnju deljenog rečnika, (2) izgradnju lokalnih ontologija i (3) definisanje mapiranja među konceptima globalnih i lokalnih ontologija definisanih u prve dve faze. Prva faza dalje obuhvata sledeće korake: (1a) analizu izvora informacija, (1b) traženje pojmova, odnosno primitiva i (1c) izgradnju globalne ontologije. Druga faza obuhvata korake: (2a) analizu izvora informacija i (2b) definisanje lokalnih ontologija. Svaka od ovih faza ima za cilj otkrivanje heterogenosti među podacima i načina za njeno premošćavanje. 5 Sama Apache Camel platforma definiše nekoliko ugrađenih načina za specificiranje ruta: Camel JSD, Java JSD, Spring, Rest JSD, Scala JSD.
30 3. PREGLED TRENUTNOG STANJA U OBLASTI Analiza izvora informacija Izgradnja deljenog rečnika Traženje primitiva Definisanje globalne ontologije Definisanje mapiranja Globalna ontologija <-> lokalne ontologije Analiza izvora informacija Izgradnja lokalnih ontologija Definisanje lokalnih ontologija Slika 3.4: Faze izgradnje i mapiranja ontologija pri integraciji podataka po [21] Metodologija integracije poslovnih aplikacija IRIS data u [25] daje smernice za proces integracije u velikim poslovnim sistemima, uz isticanje raznih pogleda na interoperabilnost: poslovni, procesni, pogled u odnosu na ljudske resurse, tehnološki, pogled u odnosu na znanje i u odnosu na značenje (semantiku). Metodologija definiše faze, aktivnosti, zadatke, način njihovog izvršavanja i učesnike. Predviđene su sledeće faze uz pripadajuće aktivnosti: 1. konceptualna definicija (a) strateška definicija (b) definicija procesa kolaboracije 2. modelovanje kolaboracije (a) globalno modelovanje (b) semantičko poravnanje (c) modelovanje scenarija kolaboracije 3. dijagnostika i predlozi za unapređenje (a) merenje sposobnosti interoperabilnosti i definicije projekata za poboljšanje interoperabilnosti (b) modelovanje scenarija kolaboracije 4. razvoj
3.1. PRISTUPI INTEGRACIJI 31 (a) razvoj projekata interoperabilnosti 5. implantacija[sic] (a) zajedničke radne sesije sa korisnicima (b) implantacija tehnološke platforme 6. izvršavanje i monitoring (a) monitoring sistema Doktorska teza [43] izučava interoperabilnost velikih i kompleksnih skupova podataka iz domena zdravstva. Za integraciju se koristi pristup baziran na ontologijama. Lokalne ontologije pojedinih izvora podataka mapiraju se na globalnu ontologiju. Poseban akcenat se stavlja na podmirivanje potreba korisnika na radnim mestima gde je neophodna saradnja sa drugim organizacionim jedinicama ili ustanovama (boundary spanning roles). Ovo čini celokupan pristup pogodan i za primene u drugim domenima, osim zdravstvenog. U [112] data je ontologija za razrešavanje semantičkih konflikata (Semantic Conflict Resolution Ontology, SCROL). Ontologija je namenjena integraciji heterogenih baza podataka i rešavanju konflikata na nivou šeme. Razvijena je i praktična implementaciju alata koji koristi predloženi pristup. Alat je nazvan CREAM (Conflict Resolution Environment for Autonomous Mediation). Arhitektura za semantičke standarde poslovnih aplikacija predstavljena u [8] oslanja se na automatizovano prevođenje XML šema u ontologije na OWL-DL jeziku. Cilj pristupa je da se omogući automatska provera kompatibilnosti ograničenja i pravila različitih standarda. Ovi standardi su obično zadati kao XML šeme, uz eksterna sintaktička ograničenja i pravila data jezicima poput Schematron-a. Tradicionalni način za integraciju ovih standarda se sastoji od (1) ručne identifikacije sintaktičkih i semantičkih podudaranja i konflikata i njihovom rešavanju, (2) kreiranju extensible Stylesheet Language Transformations (XSLT) transformacije sa izvornog na ciljni format i obrnuto, (3) primene transformacije i (4) validacije testom ekvivalencije. Validacija i postupak nisu trivijalni, jer postoje slučajevi da su neki elementi standarda semantički jednaki, a sintaktički različiti (npr. različit redosled, različit način zapisa vremenskih odrednica itd). Pretpostavka za korišćenje automatizovanog pristupa jeste da postoje ontologije koje opisuju pojedine standarde, da standardi koriste istu terminologiju, te da je moguće načiniti objedinjenu ontologiju. Postupak primene metodologije se sastoji od 11 koraka, od kojih neki u određenim slučajevima zahtevaju ručne intervencije, a obuhvataju prevođenje XML Schema Definition (XSD) šeme u OWL ontologiju, validacije zasebnih ontologija svakog standarda, formiranje zajedničke ontologije i njene provere i korišćenja alata za rezonovanje. Autori zaključuju da je korišćenje tehnologija semantičkog veba
32 3. PREGLED TRENUTNOG STANJA U OBLASTI moguće u kontekstu integracije poslovnih aplikacija, da su te tehnologije zrele, ali da nedostaju dovoljno robusni alati koji podržavaju proširivanje dodacima specijalizovanim za konkretne kompleksne zahteve koji se tipično javljaju u industriji. Doktorska teza [34] prikazuje radni okvir za integraciju heterogenih tehničkih prostora, zasnovan na principima razvoja softvera vođenog modelima (RSVM). Tehnički prostor (TP, technical space) definisan je kao radni kontekst koji obuhvata skup pridruženih koncepata, znanja, resursa, potrebnih veština i alata. Cilj radnog okvira je automatizacija dela procesa integracije softvera vezanog za Industriju 4.0 i srodne oblasti, sajber-fizičke sisteme (Cyber- Physical Systems, CPS) i Internet stvari (Internet of Things, IoT). Prikazan je namenski jezik (jezik specifičan za domen) za modelovanje i pristup zasnovan na RSVM principima, čijom primenom je moguće rešiti probleme heterogenosti u integraciji tehničih prostora. Pokazano je da je moguće kreirati strukturu tipa grafa, pomoću koje se predstavljaju šeme podataka (meta-modeli) tronivovskih tehničkih prostora, koja sadrži veze sa originalnim elementima šema podataka. Teza sadrži analizu i pregled postojećih alata za integraciju. Alati su analizirani sa aspekta licenci za korišćenje, načina distribucije i aktuelnosti održavanja, domena primene, načina na koji se mapiranje obavlja i jezika kojim se formiraju izrazi za mapiranje, mogućnosti ponovnog korišćenja delova integracionih rešenja, mogućnosti i načina izvršavanja rešenja, kao i mogućnosti proširenja alata. Analizirani su alati: opšti alati za mapiranje: Altova MapForce, AnalytiX Mapping Manager, FME Desktop, OPC Router, Open Mapping Software, MetaDapper, MuleSoft Anypoint Studio i Vorto; alati za mapiranje XML-a: Liquid XML Studio i Stylus Studio; Extract, Cleanse, Transform and Load (ECTL) alati: Adeptia Integration Suite, CloverETL, Informatica PowerCenter, Karma, Microsoft SQL Server Integration Services, OpenRefine, Oracle Data Integrator i Talend Studio.
3.1. PRISTUPI INTEGRACIJI 33 U pogledu pristupa mapiranju, alati su podeljeni na direktne (67%) i indirektne (33%). Kod direktnih, korisnik vidi samo izvorni i ciljni tehnički prostor, dok je tehnički prostor samog alata sakriven. Kod indirektnog pristupa, uvodi se medijatorski tehnički prostor, pa korisnik prvo mora izvorni i ciljni tehnički prostor da mapira na medijatorski, a zatim se unutar njega kreiraju transformacije. U pogledu načina zadavanja mapiranja, identifikovane su četiri vrste sintakse: grafička, tekstualna, tabularna i zasnovana na konfiguraciji. Od analiziranih alata 72% podržava samo jednu vrstu sintakse. Najčešće je podržana grafička sintaksa (56%), dok sintaksu zasnovanu na konfiguraciji podržava 11% alata, a tekstualnu samo jedan alat (6%). Tabularna sintaksa ni u jednom alatu nije bila jedina podržana, već se koristi u kombinaciji sa nekom drugom vrstom. U pogledu ponovnog korišćenja, analizirane su mogućnosti vezane za tri vrste koncepata: ponovno korišćenje korisnički definisanih funkcija (što podržava 61% alata), ponovno korišćenje kreiranih mapiranja (28%) i ponovno korišćenje specifikacije (28%). Pristup izložen u doktorskoj tezi [34] je i praktično implementiran u alatu nazvanom AnyMap. Proces izrade integracionog rešenja ovim pristupom sastoji se od: (1) uvoza TP, (2) specifikacije mapiranja i (3) generisanja integracionih adaptera. Uvoz TP može biti obavljen ručno ili poluautomatski, ekstrakcijom šeme iz skupova podataka. Faza specifikacije mapiranja može biti obavljena ručno, poluautomatski ili potpuno automatski. Za automatizaciju ovog koraka na raspolaganju su dva algoritma: (1) ponovno korišćenje ranije kreiranih mapiranja, koja se čuvaju u repozitorijumu alata i (2) algoritam poravnanja. Algoritam poravnanja poredi parove ulaznih i izlaznih elemenata i za svaki par pronalazi verovatnoću u intervalu [0,1) da ti elementi treba da budu mapirani. Verovatnoća se računa kao prosečna vrednost verovatnoće koju daju više algoritama za računanje sličnosti među datim parom elemenata. Alat nema mogućnost zadavanja semantike interfejsa koji se mapiraju, pa time ni mogućnost detekcije semantičkih konflikata. U [128, 42] predstavljen je Guaraná JSD, grafički jezik specifičan za domen dizajniranja EAI rešenja. Osnovni koncepti jezika, delom inspirisani integracionim šablonima iz [62], su: (1) gradivni blok (building block), komponenta koja može da prima i šalje poruke, a sastoji se od zadataka, (2) zadatak, element koji čita poruku sa jednog slota, obrađuje je i šalje na sledeći slot, (3) slot, element koji se koristi unutar gradivnih blokova kako bi omogućio razmenu poruka između različitih zadataka, kao i između zadataka i portova, (4) port, apstrakcija komunikacije spoljne aplikacije i gradivnih blokova i (5) integraciona veza, koja se interno koristi za transport poruka između gradivnih blokova. Na osnovu specifikacije integracionog rešenja izrađenog ovim jezikom, moguće je generisati programski kod implementacije rešenja. Referentna implementacija generiše Microsoft Windows Workflow Foundation 6 radne tokove, XML konfiguracione datoteke i pomoćne C# klase. U [41] izložen je Guaraná SDK, koji se sastoji od radnog okvira i skupa pomoćnih alata. Cilj autora bio je da razviju okruženje koje predstavlja implementaciju integracionih šablona 6 https://msdn.microsoft.com/en-us/library/jj684582.aspx
34 3. PREGLED TRENUTNOG STANJA U OBLASTI iz [62], ali je lakše za održavanje u odnosu na postojeća, naročito u pogledu adaptivnog održavanja, odnosno mogućnosti prilagođavanja novim kontekstima. U tom pogledu, predloženi SDK su poredili sa postojećim alatima Apache Camel 7 i Spring Integration 8, koji takođe predstavljaju implementacije pomenutih šablona. Za procenu lakoće održavanja su korišćene statističke metrike: broj paketa, broj klasa, broj interfejsa, broj metoda u klasama i interfejsima, broj linija koda, broj linija koda po metodi, broj parametara u metodi, nivo kohezije klasa po Henderson-Sellers LCOM* metodi [60] i cirkularna složenost (cyclomatic complexity) [88]. Rezultati ovih metrika znatno su povoljniji u korist Guaraná alata. Bitno je istaći da se ova merenja odnose na same alate, a ne na integraciona rešenja izvedena pomoću njih. Još jedan dodatak Guaraná familije je alat koji omogućava simulaciju rada projektovanog integracionog rešenja [117]. Simulacija konceptualnog modela omogućena je korišćenjem Petrijevih mreža [95]. Prevođenje iz Guaraná konceptualnog modela u stohastičku Petrijevu mrežu predstavlja horizontalnu, egzogenu transformaciju [119, 90] (transformaciju na istom nivou apstrakcije, gde su polazni i ciljni jezik različiti). Simulacija omogućava identifikovanje karakteristika integracionog rešenja, bez neophodnosti za izvršavanjem na realnim sistemima ili replikama takvih sistema, čime se celokupan proces razvoja čini jeftinijim. Ovim je omogućeno poređenje različitih rešnja, kao i identifikacija mogućih problema ili grešaka u dizajnu pre izrade prototipa i konačne implementacije. Korišćenje ontologije za semantičku integraciju podataka prisutno je i u oblasti analize velike količine podataka (big data). U [31] autori definišu radni okvir za realizaciju pristupa zvanog Ontology-Based Data Access (OBDA), uvedenog u [111]. OBDA specfikacija J je definisana kao trojka O, S, M, (3.1) gde je: O - ontologija, obično definisana kao Description Logic TBox [10], S - šema relacija i M - mapiranje S na O, odnosno niz tvrdnji, gde svaka predstavlja relaciju između nekog upita nad šemom i nekog upita nad ontologijom. Za jezik ontologije u radnom okviru bira se DL-Lite A, kao najekspresivniji iz DL-Lite familije (pri čemu se ističe da je ekspresivnost ovog jezika načelno dovoljna da se obuhvate koncepti 7 http://camel.apache.org/ 8 https://spring.io/projects/spring-integration
3.2. ALATI ZA SPAJANJE I MAPIRANJE ONTOLOGIJA 35 Tabela 3.1: Problemi prilikom uvođenja ERP rešenja [131] Tip problema Udeo Troškovi projekta veći od planiranih 66% Kašnjenje projekta 58% Neusaglašenost sa poslovnim strategijama 42% Otpor zaposlenih ka promenama 42% Nesuglasice sa konsultantima 38% Unutrašnje nesuglasice 34% Nesuglasice sa dobavljačima 30% Entity relationship (ER) dijagrama i UML dijagrama klasa), ili DL-Lite R, koji je osnova i OWL 2 QL profila. Jezik mapiranja je definisan tvrdnjama oblika φ(x) A(f(x)) φ(x) P (f 1 (x 1 ), f 2 (x 2 )) (3.2) Radni okvir dalje definiše način na koji se formiraju korisnički upiti, mehanizam formiranja odgovora na upite, mehanizam prerade upita (query rewrite) u odnosu na ontologiju i mehanizam prerade upita u odnosu na mapiranje. Kao jednu od prepreka za trenutno korišćenje radnog okvira, autori navode nedostatak prikladnih alata i metodologija, naročito za definisanje mapiranja, navodeći da postojeći i predloženi alati za mapiranje šema nisu adekvatni za OBDA. Sistemi za planiranje poslovnih resursa (Enterprise Resource Planing, ERP) zamišljeni su kao integralno rešenje koje pokriva aspekte finansija, zaposlenih (ljudski resursi), nabavke, proizvodnje, distribucije i prodaje, čime bi zamenili ranije korišćene aplikacije, koje su bile zadužene za svaki od ovih aspekata poslovanja ponaosob. [46] Nakon desetak godina praktične primene raznih ERP aplikacija, autori su sakupili iskustva poslovnih korisnika u vezi sa ovim sistemima [131]. Poteškoće u vezi sa uvođenjem i eksploatacijom koje su navodili ispitanici sumirane su u tabeli 3.1. Takođe, navedeno je da 58% kompanija nije integrisalo ERP sa postojećim sistemima, od čega je 23% navelo da je pokušaj integracije bio neuspešan, a 71% nisu ni pokušali integraciju, ocenjujući je kao "kompleksan, skup i dugotrajan proces". 3.2 Alati za spajanje i mapiranje ontologija U [45] dat je pregled alata za spajanje i mapiranje ontologija. Od 97 pronađenih alata, izdvojeno je sedam, koje su autori okarakterisali kao pogodne za praktičnu upotrebu u svom projektu INTER-IoT. Kriterijumi odabira su sledeći: dostupnost veb sajta i datum
36 3. PREGLED TRENUTNOG STANJA U OBLASTI njegovog poslednjeg ažuriranja, broj publikacija i datum poslednje publikacije, dostupnost izvornog koda i dokumentacije, korišćene tehnologije i mogućnost korišćenja različih formata podataka, reference korišćenja alata u akademskim i komercijalnim projektima i skalabilnost. Iako to nije bio kriterijum, primećuje se da je većina alata razvijana na Javi. Izdvojeni su sledeći alati: LogMap [70] je razvijen na Oksfordskom univerzitetu. Alat omogućava da se iz komandne linije, ili putem Ajax veb interfejsa, za zadate ontologije u formatima koje podržava OWL API [63] dobije kao izlaz poravnanje između klasa, osobina i instanci. Omogućava proveru konzistentnosti primenom Daulin-Galijer (Dowling-Gallier) algoritma. [120] Alignment API [30] definiše format za zapisivanje poravnanja ontologija korišćenjem RDF, kako bi se omogućilo njihovo skladištenje, razmena i deljenje. Zamišljen je kao nezavisan od alata, što potvđuje lista od oko stotinu alata kompatibilnih sa ovim API-jem. API definiše funkcije za odabir algoritama za mapiranje, prevođenje upita, pretragu postojećih poravnanja, njihovu manipulaciju, prikaz u raznim jezicima itd. Referentna implementacija, Alignment Server, omogućava pozivanje ovih funkcija putem SOAP ili Representational state transfer (REST) veb servisa, kao i putem FIPA jezika za komunikaciju agenata. [40] Silk Framework [137] se razlikuje od ostalih alata, po tome što ne radi na nivou šema, već na nivou podataka i omogućava pronalaženje veza između njih. Korisnik definiše kriterijume veze kroz XML, CSV, RDF ili Silk-LSL, podaci se dobavljaju SPARQL upitom, a rezultati se mogu snimiti zasebno ili spojiti sa postojećim podacima. COMA [9] predstavlja fleksibilan radni okvir za mapiranje ontologija, potekao sa Univerziteta u Lajpcigu. Alat iterativno koristi raspoložive algoritme za određivanje mapiranja. Korisnik može po potrebi da uključuje i isključuje ove algoritme, da svakom rezultatu dodeljuje nivo pouzdanosti, kao i da obriše rezultujuće mapiranje ili ručno doda novo. AgreementMaker [37] je još jedan radni okvir u kom se kriterijumi mapiranja mogu proširivati, konfigurisati i dodavati. Neki od implementiranih mapera koriste i spoljašnje servise, poput leksičke baze WordNet [93]. Nije podržano mapiranje individua, već samo klasa i osobina. Ulazne ontologije mogu biti u OWL, OBO ili SKOS formatu, a rezultat u Alignment API formatu. S-Match [47] je radni okvir koji omogućava ekstrakciju ontologija iz kataloga, stabla, konceptualnih modela i drugih struktura, a zatim vrši semantičko poređenje i mapiranje ovih ontologija. Koristi se u više od deset projekata. OntoBuilder [44] je skup alata koji omogućavaju ekstrakciju ontologija na osnovu veb stranica i sukcesivno mapiranje na jedinstvenu ontologiju. Dostupan je grafički prikaz mapiranja, koja korisnik može da pregleda i odabere.
3.3. ALATI ZA INTEGRACIJU 37 3.3 Alati za integraciju U ovom delu biće prikazani neki alati za integraciju koji se često koriste u praksi. Rezime poglavlja daje pregled analiziranih alata uz fokus na proces mapiranja koji je prisutan kao sastavni deo celokupnog procesa integracije u svim alatima i čija automatizacija predstavlja predmet ovog istraživanja. 3.3.1 Apache Camel Apache Camel je radni okvir namenjen izradi integracionih rešenja. Može se reći da Camel velikim delom predstavlja implementaciju integracionih šablona opisanih u [62]. Ovaj radni okvir je modularan, može se proširiti dodacima (plugin), otvoren (pod Apache licencom), sa dobrom podrškom aktivnih korisnika i dobrim resursima za učenje, poput [64]. Može raditi samostalno, biti ugrađen u druge aplikacije ili radne okvire, izvršavati se u okviru aplikativnih servera ili koristiti njihove usluge (JBoss, Tomcat, Spring, MINA, itd). Camel nije zamišljen kao Enterprise Integration Bus. Razvoj integracionog rešenja u Camel-u sastoji se od izgradnje ruta koje povezuju različite Camel komponente: Endpoint, Processor, Producer, Consumer, Message Translator, itd. Rute se definišu u jednom od raspoloživih internih JSD-ova: Java, Spring, Blueprint, Groovy, Scala. Svaki od ovih JSD-ova ima konkretnu sintaksu koja je osmišljena tako da se najbolje uklopi u okruženje ili jezik u okviru kojih se koristi. Na primer, Camel Java JSD za specifikaciju ruta koristi ulančane pozive metoda (tzv. fluid API), Camel Spring JSD koristi isti format kojim se inače specificiraju Spring komponente. Camel koristi načelo konvencija umesto konfiguracije za svaku komponentu podrazumevana su podešavanja koja odgovaraju najvećem broju slučajeva korišćenja. Ukoliko je potrebno promeniti neke od parametara, to se može učiniti u okviru URI-ja kojim se komponenta i identifikuje. Za velik broj formata na raspolaganju su komponente koje vrše konverziju iz jednog formata u drugi. Za formate koji nisu podržani, kao i za implementiranje poslovne logike koja se ne može drugačije realizovati, moguće je razviti sopstvene komponente koje se zatim dalje povezuju rutama i koriste u okviru integracionog rešenja. Komponente mogu implementirati neki od Camel interfejsa ili biti realizovane kao bean-ovi, kako bi mogle biti korišćene i van Camel-a. Camel poseduje sopstveno okruženje za testiranje razvijenih rešenja, bazirano na JUnit radnom okviru. Ono uključuje i gotove mockup komponente, logere, kao i alate za praćenje i presretanje poruka. Na raspolaganju su i alati za upravljanje radom rešenja u eksploataciji. Apache Camel nudi široke mogućnosti za implementaciju integracionog rešenja. Koncepti internog JSD-a se dobro mapiraju na jezik integracionih šablona. Iako je kod pisan ovim jezikom lako čitljiv, mogu se javiti poteškoće u sagledavanju implementacija komplikovanijih scenarija. Ovo je svojstveno za sve tekstualne reprezentacije složenih struktura. Od pomoći mogu biti i alati poput JBoss Camel Developer Tools ili Hawtio 9 (prikazan na slici 3.5), koji omogućavaju vizuelizaciju Camel ruta u vidu grafičkih dijagrama. 9 https://hawt.io/
38 3. PREGLED TRENUTNOG STANJA U OBLASTI Slika 3.5: Vizualizacija rute u alatu Hawtio 3.3.2 Talend Open Studio Aplikacija Talend Open Studio je deo familije proizvoda namenjenih raznim vidovima integracije. Osnovne verzije ove aplikacije i pratećih alata dostupni su pod Apache slobodnom licencom i besplatne su za korišćenje. Postoje i dve edicije dostupne uz pretplatu: Entry Level i Platform Edition, koje uključuju podršku i dodatne alate za razvoj, administraciju, monitoring, pripremu podataka, merenje kvaliteta podataka, grupni rad i redundantno izvršavanje integracionog rešenja. Aplikacija je dobro dokumentovana i ima veliku bazu korisnika. Sve edicije, uključujući besplatnu, sadrže više od 900 predefinisanih konektora 10. Ovi konektori omogućavaju uvoz i izvoz podataka ka i od širokog spektra poslovnih paketa, SaaS (Software as a Service) rešenja, raznih protokola, sistema za upravljanje bazama podataka i formata datoteka, među kojima su: SAP Business Suite, Sage X3, Sugar CRM (Customer relationship management), CentronicCRM, Microsoft Dynamics; Marketo, Salesforce Wave, NetSuite; Amazon S3, Google Drive, Amazon SQS (Amazon Simple Queue Service), Elastic Search, JIRA; Microsoft SQL Server, PostgeSQL, Informix, MySQL; REST, SOAP; XML, CSV, XLS; E-mail (POP3/SMTP/IMAP), FTP, SFTP, LDAP. Jedan primer Big Data integracije korišćenjem paketa Talend Open Studio prikazan je u [94]. 10 Spisak predefinisanih konektora, kategorizovanih po verziji i ediciji: https://www.talendforge.org/components/index.php
3.3. ALATI ZA INTEGRACIJU 39 Slika 3.6: Pregled BizTalk arhitekture 3.3.3 Microsoft BizTalk Microsoft BizTalk je komercijalna platforma namenjena integraciji poslovnih aplikacija 11. Arhitektura BizTalk servera zasniva se na publish-subscribe obrascu [101]. Pregled arhitekture dat je na slici 3.6. BizTalk omogućava implementaciju poslovnih procesa orkestracijom, upravljanje definisanim procesima i njihovo praćenje, poseduje mehanizme za postizanje visoke dostupnosti, konzolu za upravljanje artefaktima, kao i alate za povezivanje sa drugim poslovnim entitetima (business-to-business). Podaci se primaju i šalju u vidu poruka. Samo povezivanje infrastrukture sa krajnjim aplikacijama koje se integrišu obavlja se putem adaptera. U BizTalk arhitekturi, adapter je komponenta koja implementira mehanizam isporuke poruka korišćenjem nekog komunikacionog standarda ili formata. Nativni adapteri, koji se isporučuju uz aktuelnu verziju BizTalk server-a su: FILE, FTP, HTTP, MQSeries, MSMQ, POP3, SMTP, SOAP, Windows Sharepoint Services, WCF-WSHttp, WCF-BasicHttp, WCF- NetTcp, WCF-NetMsmq, WCF-NetNamedPipe, WCF-Custom i WCF-CustomIsolated. Moguć je i razvoj drugih adaptera korišćenjem BizTalk Adapter radnog okvira 12. Životni ciklus poruke prikazan je na slici 3.7. Za razvoj integracionih rešenja koja se izvršavaju na BizTalk serveru kreiraju se projekti upotrebom integrisanog razvojnog okruženja Visual Studio. BizTalk projekat može sadržati sledeće delove 13. Orkestraciju Orkestracija je reprezentacija poslovnih procesa. Može biti opisana jezicima opšte namene iz.net familije, poput Visual C# ili Visual Basic.NET ili jezikom XLANG/s. XLANG/s je JSD namenjen opisu procesa. Koristi konstrukte standarda poput XSD, XSD i WSDL i poseduje podršku za direktno korišćčenje.net objekata i poruka. [102] Uvodi 11 https://www.microsoft.com/en-us/cloud-platform/biztalk 12 https://docs.microsoft.com/en-us/biztalk/core/what-is-the-adapter-framework 13 https://docs.microsoft.com/en-us/biztalk/core/adding-project-items
40 3. PREGLED TRENUTNOG STANJA U OBLASTI Slika 3.7: Životni ciklus poruke u BizTalk okruženju. Izvor: docs.microsoft.com Slika 3.8: Radno okruženje alata BizTalk Mapper. Izvor: social.technet.microsoft.com podršku i za konstrukte visokog nivoa, kao što su: poruka, port, korelacija ili veza servisa. Šeme Šema predstavlja definiciju strukture dokumenta ili poruke. Može imati kompozitnu strukturu, odnosno sadržati druge šeme. Mape Mapa daje relaciju između polja neke dve šeme. Mapiranje se obavlja XSLT jezikom. Za lakšu manipulaciju, na raspolaganju je alat BizTalk Mapper. Ovaj alat omogućava grafički prikaz i manipulaciju vezama između šema i njihovim međusobnim transformacijama. Korisnički interfejs alata prikazan je na slici 3.8. Protočne obrade Protočna obrada obuhvata infrastrukturu koja definiše i povezuje jednu ili više faza u obradi poruka koje šalje ili prima BizTalk server.
3.3. ALATI ZA INTEGRACIJU 41 3.3.4 Oracle Integration Cloud Oracle Integration Cloud (OIC) je platforma za integraciju aplikacija i automatizaciju procesa u oblaku. Pod ovime, podrazumevamo da se sama platforma izvršava u oblaku, da se njom upravlja u oblaku i da je namenjena integraciji prevashodno aplikacija koje su i same u oblaku, mada se može koristiti i za integraciju ovih aplikacija sa tradicionalnim rešenjima, koja se izvršavaju na lokalnoj infrastrukturi (on-premises). Izgled dela korisničkog interfejsa prikazan je na slici 3.9. OIC je deo šire familije platformi i radnih okvira za aplikacije u oblaku koje nudi Oracle [77]. Nacionalni institut za standarde i tehnologiju SAD (National Institute of Standards and Technology 14 ) definiše računarstvo u oblaku na sledeći način: Računarstvo u oblaku je model koji omogućava sveprisutan, praktičan mrežni pristup na zahtev zajedničkom skupu konfigurabilnih računarskih resursa (npr. mrežama, serverima, skladištima, aplikacijama i servisima) koji se mogu brzo obezbediti i objaviti uz minimalan napor i minimalnu interakciju sa pružaocem usluga. Brojna istraživanja govore o ekspanziji aplikacija u oblaku, kao i o sve širem prihvatanju ovakvih rešenja od strane kompanija. Skyhigh navodi da se broj aplikacija u oblaku utrostručio od 2013 do 2016. LogicMonitor i Forbes predviđaju da će se do 2020. godine 83% radnih zadataka koje kompanije obavljaju biti skladišteno u oblaku. Sa aspekta integracije, naročito je interesantna procena koju iznosi Skyhigh, a koja govori da prosečna kompanija koristi preko 1400 različitih servisa u oblaku, a da svaki zaposleni koristi prosečno 36 ovakvih servisa. Iz ovoga je jasno da je potreba za integracijom i kod ove vrste aplikacija i dalje izražena, a time i potreba za plaftormama poput OIC. Ka svakoj aplikaciji koja se integriše, u OIC se kreira konekcija. Komunikacija sa aplikacijom se odvija putem adaptera. Adapteri implementiraju protokole i formate za razmenu podataka i poruka. Postoji skup predefinisanih adaptera za standardne protokole, a dodatni adapteri se mogu razviti ili dobaviti iz baze dostupnih adaptera. Postoje četiri vrste adaptera: SaaS, tehnološki, društveni i on-premises [4]. SaaS (Software as a Service) adapteri služe za povezivanje sa aplikacijama koje se izvršavaju u oblaku i nude API. Tehnološki adapteri implementiraju protokole za industrijski standardne protokole poput SOAP, REST i (S)FTP. Društveni (social) adapteri omogućavaju komunikaciju sa društvenim mrežama poput Facebook-a, LinkedIn-a ili Twittera i ličnim aplikacijama poput GMail-a, Google kalendara, SurveyMonkey i drugim. On-premises adapteri omogućavaju komunikaciju sa tradicionalnim rešenjima koja se izvršavaju na lokalnoj infrastrukturi kompanije. Integracijom sa njima, kreiraju se rešenja koja predstavljaju hibridni oblak. Iz ove grupe dostupni su adapteri za razne standardne formate datoteka, konekcije na sisteme za upravljanje bazama podataka i rasprostranjena rešenja za poslovne aplikacije, poput Oracle E-Business Suite, SAP i slične. 14 https://www.nist.gov/
42 3. PREGLED TRENUTNOG STANJA U OBLASTI Slika 3.9: Kreiranje orkestracije u Oracle Integration Cloud 3.3.5 Rezime pregleda alata za integraciju U ovom poglavlju predstavljena su četiri alata koji predstavljaju primere dostupnih alata za integraciju. Prvi, Apache Camel je radni okvir koji implementira integracione šablone i može služiti za programiranje integracionih rešenja na visokom nivou apstrakcije, korišćenjem konstrukata ovog tehničkog domena. Ostali predstavljeni alati - Talend Open Studio, Microsoft BizTalk i Oracle Integration Cloud su primeri komercijalnih integracionih platformi, koje uključuju dodatne alate koji pomažu pri razvijanju i održavanju rešenja, kao i implementaciju okruženja kojima se data rešenja mogu izvršavati i pratiti. Ovi alati uključuju podršku za grafički prikaz i manipulaciju komponentama rešenja, testiranje, validaciju i drugo. Zajedničko svim platformama je i da nude velik broj gotovih konektora, odnosno komponenti koje omogućavaju jednostavnu razmenu podataka ili poruka sa poznatim formatima datoteka, protokolima i aplikacijama. Velik broj ovih konektora podržava i automatsku ekstrakciju strukture šeme datog ulaznog ili izlaznog interfejsa. Pored četiri prikazane platforme, slične suštinske funkcionalnosti nude i paketi poput: Altova MapForce, AquaLogic, AnalytiX Mapping Manager, BEA WebLogic Workshop, FME Desktop, IBM Rational Data Architect, OPC Router, Open Mapping Software, MetaDapper, MuleSoft Anypoint Studio i Vorto. Njihovi uporedni prikazi analizirani su u [34, 6, 14]. Zajednički korak u razvoju integracionog rešenja kod svih analiziranih alata jeste uspostavljanje mapiranja među elementima ulaznih i izlaznih intefejsa koji učestvuju u integracionom scenariju. Ovaj korak predstavlja manuelni zadatak, čije rešavanje zahteva detaljno poznavanje strukture, ali i načina rada i značenja svakog od ovih elemenata. Još jedan primer tipičnog izgleda korisničkih interfejsa za ručno mapiranje dat je na slici 3.10. Automatizacija mapiranja dovela bi do značajnog olakšanja celog procesa integracije i
3.3. ALATI ZA INTEGRACIJU 43 Slika 3.10: Korisnički interfejs za mapiranje u Altova MapForce. Izvor: www.altova.com doprinela njegovoj eventualnoj potpunoj automatizaciji. Automatizacija detekcije i razrešavanja semantičkih konflikata koji se mogu javiti prilikom mapiranja povećala bi valjanost i pouzdanost integracionog rešenja u celini. Arhitektura radnog okvira, koji predstavlja jedan pristup rešavanju ovog problema, data je u narednom poglavlju.
44 3. PREGLED TRENUTNOG STANJA U OBLASTI
4 Radni okvir za automatizaciju integracije Cilj radnog okvira je da obezbedi okruženje u kom je moguće ostvariti automatsko ili poluautomatsko mapiranje interfejsa aplikacija koje učestvuju u integracionom scenariju, detektovanje tehničkih i semantičkih konflikata i njihovo rešavanje [139]. Za proces automatizovanog mapiranja potrebni su: formalna specifikacija strukture interfejsa aplikacija koje učestvuju u scenariju i koja definiše: nazive elemenata interfejsa, tip podataka svakog elementa interfejsa i ograničenja elementa interfejsa (dužina, preciznost, da li je obavezan, itd.); formalna specifikacija semantike svih interfejsa i njihovih elemenata i formalna specifikacija integracionog scenarija. Komponente radnog okvira prikazane su na dijagramu 4.1. Komponenta Interface modeler zadužena je za kreiranje i čuvanje modela strukture svih interfejsa svih aplikacija koje se integrišu. Komponenta Semantic annotator služi da omogući korisniku da anotira elemente strukturnog modela interfejsa semantikom, odnosno elementima ontologije, čija definicija je uvezena komponentom Ontology import. Komponenta Interface mapper omogućava da se kreira, prikaže, ručno izmeni i sačuva specifikacija mapiranja među elementima interfejsa. Komponenta Auto mapper obavlja proces automatskog mapiranja, detekcije i razrešavanja konflikata. Implementacije komponente Mapping criterium definišu uslov koji određuje da li treba uspostaviti mapiranje među nekim parom ulaznih i izlaznih elemenata interfejsa. Neki od ovih kriterijuma prikazani su u sekciji 4.2. Komponenta Conflict detector definiše uslove tehničkih i semantičkih konflikata. Primeri ovih uslova prikazani su u sekciji 4.3. Na kraju, komponenta Expression builder određuje kako će biti sačinjen izraz koji definiše kako se obavlja mapiranje ukoliko u njemu učestvuje više ulaznih ili više izlaznih interfejsa (da li će njihove vrednosti biti spojene, sabrane ili na neki drugi način obrađene). 45
46 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE 4.1 Proces mapiranja Slika 4.1: Dijagram komponenti radnog okvira Preduslov za proces automatskog mapiranja interfejsa je postojanje ontologije koja opisuje elemente tih interfejsa. Korisnik učitava ovu ontologiju i anotira (označava) elemente interfejsa elementima ontologije, pri čemu svaki element interfejsa može biti označen jednim ili više elementa ontologije i na taj način semantički opisan. U mapiranju mogu istovremeno da učestvuju više ulaznih i više izlaznih interfejsa. Šematski prikaz celokupnog procesa dat je na slici 4.2. Sam proces automatskog mapiranja podeljen je u sledeće faze: traženje kandidata za mapiranje, detekcija i razrešavanje konflikata, formiranje izraza koji definišu mapiranje i generisanje integracionog koda. Tok ovih faza prikazan je na dijagramu 5.1.
Slika 4.2: Šematski prikaz procesa integracije. 4.1. PROCES MAPIRANJA 47
48 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE 4.2 Kriterijumi mapiranja Proces traženja kandidata za mapiranje odvija se iterativnim prolaskom kroz sve elemente svih ulaznih interfejsa i sve elemente svih izlaznih interfejsa, tj. njihovim poređenjem svakog sa svakim. Za svaki ovakav par jednog elementa ulaznog i jednog elementa izlaznog interfejsa proverava se da li zadovoljava neki od raspoloživih kriterijuma mapiranja. Svaki kriterijum za mapiranje je implementiran kao komponenta prikazanog radnog okvira za automatsko mapiranje. Ovime je omogućeno da se po potrebi uvode novi kriterijumi, proširuju ili isključuju postojeći. Navodimo neke kriterijume koji su implementirani i testirani u toku razvijanja praktičnog prototipa radnog okvira. U tabeli 4.1 navodimo pregled ovih kriterijuma, a zatim svaki opisujemo ponaosob. Tabela 4.1: Pregled kriterijuma za mapiranje Naziv Kratak opis Grafički prikaz Jednako ime Elementi interfejsa imaju isti naziv Item_tax Item_tax Jednak XPath Ulazni i izlazni elementi su XML čvorovi koji imaju isti XPath izraz Jednaka anotacija Elementi interfejsa su označeni istim elementom ontologije #tax Ar cle_tax #tax Item_tax Agregacija Dva ili više izlaznih elemenata su označeni elementima ontologije koji su definisani kao deo (part_of) elementa ontologije kojim je anotiran element izlaznog interfejsa First_name #First_Name #Last_Name Last_name part_of part_of Name #Full_name Generalizacija Specijalizacija Razdvajanje Element ulaznog interfejsa je anotiran elementom ontologije koji je potklasa elementa kojim je anotiran element izlaznog interfejsa Element izlaznog intefejsa je anotiran elementom ontologije koji je potklasa elementa ontologije kojim je anotiran element ulaznog interfejsa Dva ili više elementa izlaznog interfejsa su anotirani elem. ontologije koji se sastoji od elemenata ontologije kojim je anotiran jedan elem. ulaznog interfejsa #address Address #home_address Home_address Address part_of #address part_of #home_address Home_address #address Adress City #city #street Street
4.2. KRITERIJUMI MAPIRANJA 49 Tabela 4.1: Pregled kriterijuma za mapiranje Zabrana mapiranja Legenda Elem. ulaznog interfejsa i element izlaznog interfejsa su anotirani elementima ontologije koji su u njoj definisani kao različiti Interface element Ontology element Mapping Ontology predicate Annota on 4.2.1 Jednako ime Kandidat za mapiranje će biti formiran ukoliko element ulaznog i element izlaznog interfejsa imaju jednako ime. Pri tom se opciono uzimaju u obzir razlike u malim i velikim slovima, načinu predstavljanja razmaka (razmak, donja crta, kamilja notacija) i dijakritičkim znacima. 4.2.2 Jednaka XPath putanja Ukoliko su ulazni i izlazni interfejs deo XML šeme, elementi će postati kandidati za mapiranje ukoliko imaju jednaku XPath putanju. 4.2.3 Specijalizacija Neka je I1 element ulaznog interfejsa, a O1 element izlaznog interfejsa. U ontologiji su definisane klase A i B, pri čemu je B potklasa A, kao što je prikazano na Listingu 4.1. I1 je anotiran sa A, a O1 je anotiran sa B. Drugim rečima, element izlaznog interfejsa je anotiran elementom ontologije koji prestavlja specijalizaciju elementa ontologije kojim je anotiran element ulaznog interfejsa. U ovom slučaju, postoji semantička veza ovih elemenata interfejsa, ali nismo sigurni da li ona treba da rezultuje kandidatom za mapiranje, pa korisniku nudimo mogućnost da, putem dijaloga, odabere da li ovi elementi treba da budu mapirani. Dijalog za odabir prikazan je na slici 4.3. Ontology ( 2 C l a s s (A p a r t i a l ) C l a s s (B p a r t i a l ) 4 SubClassOf (B A) ) Listing 4.1: Definicija specijalizacije u ontologiji
50 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE Slika 4.3: Traženje potvrde od strane korisnika
4.2. KRITERIJUMI MAPIRANJA 51 Napominjemo da je ovo samo jedan način na koji se može tumačiti situacija kada smo prepoznali da postoji odnos specijalizacije između nekih elemenata ulaznog i izlaznog interfejsa. Može postojati, na primer, kontekst u kom ovakav odnos elemenata ulaza i izlaza uvek treba tretirati kao mapiranje. U sekciji 6 ćemo pokazati kako se, korišćenjem JSD SAIL, može definisati ponašanje alata u ovakvim i drugim situacijama. 4.2.4 Generalizacija Neka je I1 element ulaznog interfejsa, O1 element izlaznog interfejsa, a A i B klase ontologije, takve da je A potklasa B, kao što je definisano na listingu 4.2. Element interfejsa I1 je označen sa A, dok je O1 označen sa B. Dakle, element izlaznog interfejsa je označen elementom ontologije koji predstavlja generalizaciju elementa ontologije pridruženog elementu ulaznog interfejsa. Ukoliko je I1 jedini element izlaza anotiran kao potklasa B, mapiranje će biti uspostavljeno automatski između I1 i O1. Ukoliko na ulaznoj strani postoji više elemenata koji su potklasa B, nije moguće automatski odlučiti koji element će biti mapiran, pa se korisniku ostavlja mogućnost da odabere da li će I1 biti mapiran na O1. Ontology ( 2 C l a s s (A p a r t i a l ) C l a s s (B p a r t i a l ) 4 SubClassOf (A B) ) Listing 4.2: Generalizacija u ontologiji Primer: neka na ulazu postoji polje kućnaadresa, a na izlazu polje adresa. Adresa je generalizacija kućne adrese. Ukoliko na ulazu ne postoji ni jedana druga adresa, može se automatski uspostaviti mapiranje kućneadrese na adresu. Međutim, ukoliko na ulazu postoji i polje adresanaposlu, ne možemo znati koja od ovih adresa treba da bude mapirana na jedino polje izlaza koje nosi semantiku adrese, pa odluku ostavljamo korisniku. 4.2.5 Jednako anotiranje Neka je I1 element ulaznog interfejsa, a O1 element izlaznog interfejsa. Ako su oba ova elementa označena istim elementom ontologije A, biće uspostavljeno mapiranje I1 na O1. 4.2.6 Agregacija Neka su dati elementi ulaznog interfejsa I1 i I2 i element izlaznog interfejsa O1. Ulazni elementi I1 i I2 su anotirani elementima ontologije A i B, dok je O1 anotiran elementom ontologije C. U ontologiji je definisano da se C sastoji od A i B 1. Uspostavlja se mapiranje 1 Jezik OWL sam ne poseduje mehanizam kojim se mogu opisati veze celina-deo. Ukoliko je neophodno uključiti takvu vezu, može se uključiti neka mereološka ontologija koja je definiše. Za potrebe ovog
52 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE I1 na O1 i I2 na O1. Dakle, O1 je agregacija I1 i I2, što znači da dve ulazne vrednosti treba da se spoje u jednu izlaznu vrednost. Na koji način će to spajanje biti implementirano (konkateniranjem, sabiranjem,... ) razrešava se kasnije, u fazi konstrukcije izraza (4.4). Ontology ( 2 C l a s s (C p a r t i a l ) C l a s s (A p a r t i a l 4 r e s t r i c t i o n ( p a r t : p a r t O f _ d i r e c t l y somevaluesfrom (C) ) ) C l a s s (B p a r t i a l 6 r e s t r i c t i o n ( p a r t : p a r t O f _ d i r e c t l y somevaluesfrom (C) ) ) ) Listing 4.3: Definicija agregacije u ontologiji 4.2.7 Tranzitivna agregacija Neka su I1 i I2 elementi ulaznog interfejsa, a O1 element izlaznog interfejsa. Elementi I1 i I2 su anotirani elementima ontologije A i B, dok je O1 anotiran elementom ontologije C. C je označen kao potklasa D. A i B su u tranzitivnom odnosu agregacije sa C, pa će I1 i I2 biti mapirani na O1. Ontology ( 2 C l a s s (D p a r t i a l ) C l a s s (C p a r t i a l ) 4 SubClassOf (D C) 6 C l a s s (A p a r t i a l r e s t r i c t i o n ( p a r t : p a r t O f _ d i r e c t l y somevaluesfrom (D) ) ) 8 C l a s s (B p a r t i a l r e s t r i c t i o n ( p a r t : p a r t O f _ d i r e c t l y somevaluesfrom (D) ) ) 10 ) Listing 4.4: Ontologija koja definiše agregaciju ka nadklasi 4.2.8 Razdvajanje Neka je I1 element ulaznog interfejsa, a O1 i O2 elementi izlaznog interfejsa. I1 je anotiran sa A, O1 sa B, a O2 sa C. U ontologiji je definisano da su B i C delovi A. Uspostavlja se mapiranje I1 sa O1 i I2 sa O1. U fazi konstruisanja izraza sadržaj I1 će biti podeljen (npr. na razmacima ili zarezima, ukoliko je u pitanju tekstualni sadržaj), a delovi dodeljeni O1 i O2. Primer: ulazni interfejs sadrži polje adresa, dok izlazni interfejs sadrži polja grad, ulica i broj. primera i testiranja okruženja za automatsko mapiranje korišćena je jedna takva ontologija dostupna na http://www.w3.org/2001/sw/bestpractices/oep/simplepartwhole
4.3. DETEKCIJA I RAZREŠAVANJE KONFLIKATA 53 4.2.9 Zabrana mapiranja Može se javiti potreba da se određeni elementi interfejsa označe tako da ih ne treba mapirati, iako možda zadovoljavaju neki od aktivnih kriterijuma za mapiranje. Stoga uvodimo kriterijum za zabranu mapiranja. U listingu 4.5 data je ontologija koja definiše klase A i B i njihove individue a i b, za koje je definisano da su različite. Elementi a i b se mogu koristiti za anotiranje elemenata interfejsa koji ne treba da budu mapirani. Ontology ( 2 C l a s s (A) C l a s s (B) 4 C l a s s A s s e r t i o n (A a ) C l a s s A s s e r t i o n (B b ) 6 D i f f e r e n t I n d i v i d u a l s ( a b ) ) Listing 4.5: Ontologija koja definiše da su a i b različiti, pa ih ne treba mapirati 4.3 Detekcija i razrešavanje konflikata Nakon faze traženja kandidata za mapiranje, sledi faza detekcije i razrešavanja konflikata. Kao i u slučaju kriterijuma za mapiranje, i kriterijumi i načini za razrešavanje konflikata predstavljaju proširive komponente, pa se mogu definisati novi, kao i modifikovati ili isključiti postojeći. U nastavku navodimo neke primere konflikata. 4.3.1 Višestruko mapiranje po istom osnovu Ukoliko je u prethodnoj fazi element izlaznog interfejsa mapiran na više ulaznih interfejsa po istom osnovu, korisniku će biti prezentovan dijalog u kom može da odabere koja od tih mapiranja treba zadržati. Pod istim osnovom smatramo da su mapiranja rezultat istog kriterijuma i da su u okviru tog kriterijuma uslovi isti za sva mapiranja. Primer: Neka su I1 i I2 elementi ulaznog interfejsa, a O1 element izlaznog interfejsa i neka su svi anotirani istim elementom ontologije A. Na osnovu kriterijuma iste anotacije, biće uspostavljena dva mapiranja, I1 na O1 i I2 na O1. U ovom slučaju nismo sigurni da li I1 i I2 imaju istu semantiku, pa ih treba konkatenirati, ili su greškom dva ulazna elementa anotirana istim elementom ontologije, pa se korisniku ostavlja odluka šta učiniti u ovom slučaju. Ukoliko nije u pitanju greška, korisnik može anotirati elemente kao što je opisano u kriterijumu agregacije, kako ovaj konflikt ne bi bio ponovo prijavljen, a semantika bila jasnije izražena.
54 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE 4.3.2 Višeznačna specijalizacija ili generalizacija Kao što je navedeno u kriterijumu specijalizacije (4.2.3), kada je element izlaznog interfejsa anotiran elementom ontologije koji je opštiji od elementa ontologije kojim je anotorian element ulaznog interfejsa, ne može se sa sigurnošću zaključiti da li mapiranje treba da bude uspostavljeno, pa se odluka ostavlja korisniku. 4.3.3 Nekompatibilnost tipova Prilikom konstrukcije izraza za mapiranje, kao što će biti detaljnije izloženo u sekciji 4.4, uzimaju se u obzir tipovi podataka svakog od elemenata interfejsa koji učestvuju u mapiranju. Ukoliko se ulazni tip ne može direktno dodeliti izlaznom tipu u skladu sa pravilima ciljnog jezika na kom će se izvršavati integraciono rešenje, što je u našem slučaju Java, biće prijavljena greška porukom u konzoli i kao grafički simbol x pored Talend job komponente u kojoj je detektovan problem. Izvorna TOS aplikacija poseduje komponentu tconverttype, koja se može postaviti pre tmap komponente za mapiranje i koja služi za prevođenje podataka ulaznog interfejsa u format koji je kompatibilan sa formatom elementa izlaznog interfejsa. U slučaju da je detektovana nekompatibilnost tipova ulaznog i izlaznog interfejsa između kojih je utvrđeno da treba uspostaviti mapiranje, tautomap komponenta, koju smo uveli, automatizuje postopak uvođenja i povezivanja tconverttype komponente. 4.4 Konstrukcija izraza za mapiranje Nakon što su pronađeni kandidati za mapiranje i razrešeni eventualni konflikti među njima, neophodno je konstruisati izraze koji će služiti za dodelu vrednosti elemenata ulaznih interfejsa elementima izlaznog interfejsa. Ovi izrazi postaju deo izvornog koda integracionog rešenja, pa u slučaju TOS platforme treba da predstavljaju validne Java izraze. Na primer, ukoliko ulazni interfejs ima polja firstname i lastname, a izlazni interfejs ima polje fullname, u prethodnim fazama je utvrđeno da se firstname i lastname mapiraju na fullname. U izvornom kodu integracionog rešenja želimo liniju poput: output. fullname = i n p u t. f i r s t N a m e + " " + i n p u t. lastname ; Pri tom, generator koda ugrađen u TOS će za svaki element izlaznog interfejsa generisati po jednu dodelu, pa mi treba da obezbedimo samo desnu stranu dodele u okviru komponente za mapiranje. Za jednostavna mapiranja 1-na-1, konstrukcija ovog izraza je trivijalna i on će sačinjavati samo pun naziv elementa ulaznog interfejsa. Sa druge strane, ukoliko je u pitanju mapiranje više ulaznih na jednu izlaznu vrednost (više-na-1), te ulazne vrednosti treba na neki način agregirati, odnosno spojiti. Ukoliko su sve ulazne vrednosti tekstualne, može se izvršiti konkateniranje, kao u gornjem primeru. Ukoliko su sve ulazne vrednosti numeričke, može se konstruisati izraz koji ih sumira. Ovo su ujedno i podrazumevana ponašanja automatskog
4.4. KONSTRUKCIJA IZRAZA ZA MAPIRANJE 55 mapera u ovim slučajevima. Ukoliko korisnik želi drugačije ponašanje, može u dijalogu komponente za mapiranje da izmeni svaki od predloženih izraza. Takođe, podrazumevano ponašanje automatskog mapera se može izmeniti proširivanjem komponente za konstrukciju izraza, ili zadavanjem njene specifikacije putem JSD-a opisanog u 6. Kod mapiranja 1- na-više, u job se dodaje ugrađena TOS komponenta csplitter, čiji izlaz se dovodi na ulaz tautomap komponente. U okviru csplitter komponente je moguće zadati način na koji će ulazna vrednost biti podeljena na delove.
56 4. RADNI OKVIR ZA AUTOMATIZACIJU INTEGRACIJE
5 Referentna implementacija radnog okvira Kako bi se omogućilo praktično testiranje do sada navedenih teorijskih razmatranja, razvijena je referentna implementacija radnog okvira datog u poglavlju 4. Oslonac na postojeće aplikacije i alate omogućio je da ova implementacija bude izvedena u relativno ranoj fazi istraživanja, čime je omogućena kontinuirana evaluacija i poređenje novih ideja i pristupa. U ovom poglavlju opisano je kako je izvedena ova praktična implementacija alata za automatizovano mapiranje interfejsa koji učestvuju u integraciji i detekciji semantičkih konflikata među njima. Dijagram aktivnosti celokupnog procesa integracije dat je na slici 5.1. Radni okvir obavlja ulogu naznačenu kao System na ovom dijagramu, omogućava učitavanje ontologije koja je rezultat koraka koji obavlja uloga Semantic modeler i omogućava anotiranje strukturnog modela elementima semantike, kao i prikaz rezultata i prikupljanje ručnih izmena od strane Integratora. 57
58 5. REFERENTNA IMPLEMENTACIJA RADNOG OKVIRA Semantic modeler System Integrator Model systems ontology Model integration scenario Semantically annotate interfaces Find mapping candidates Detect & resolve conflicts Resolve ambiguities Build mapping expressions Generate ESB code Slika 5.1: Proces integracije. Uloge: Semantic modeller - osoba koja kreira semantički opis sistema; System - radni okvir za mapiranje; Integrator - osoba koja razvija integraciono rešenje.
5.1. PODLOGA I PODRŠKA 59 5.1 Podloga i podrška Radni okvir kao ulaz uzima strukturne modele interfejsa i ontologiju koja definiše semantiku tih intefejsa, radi mogućnosti detekcije elemenata koje treba mapirati i mogućnosti detekcije semantičkih konflikata. Kako bi korisnik na efikasan način definisao ove ulazne podatke, neophodno je razviti pogodne alate koji omogućavaju njihovo kreiranje i manipulaciju. Kako već postoji mnoštvo raspoloživih alata koji obavljaju ove funkcionalnosti, zarad bržeg dobijanja prototipa koji možemo koristiti za testiranje teorijskih razmatranja datih u prethodnim poglavljima, koristili smo date alate kao osnovu. Time je potreba za implementacijom svedena samo na one zadatke koji predstavljaju inovaciju i uži predmet ovog istraživanja. Ova sekcija daje osvrt na alate i radne okvire koji su korišćeni kao podloga i podrška implementaciji našeg radnog okvira. Talend Open Studio Za aplikaciju kojom će biti kreiran strukturni model interfejsa, korišćena je aplikacija TOS, već prikazana u sekciji 3.3.2. Osnovni razlog za odabir ovog alata je raspoloživost izvornog koda. Zahvaljujući tome, delovi alata su lako mogli biti po potrebi prilagođeni našim potrebama. Pored pomenute funkcionalnosti, TOS daje mogućnost definisanja i orkestracije procesa kojim se implementira rešenje integracionog scenarija, kao i generisanje izvornog koda rešenja, koji je izvršiv na Talend ESB Runtime platformi. TOS poseduje mogućnost zadavanja specifikacije elemenata za sve ulazne i izlazne interfejse. Ova aplikacija poseduje i komponente za obradu podataka i omogućava međusobno ulančavanje ovih komponenti i ulaznih i izlaznih konektora. Na taj način, aplikacija ispunjava i specificiranje celokupnog rešenja integracionog scenarija. Jedna od komponenti za obradu je i komponenta tmap, koja omogućava mapiranje više ulaznih interfejsa na više izlaznih interfejsa. Mapiranje se obavlja tako što se za svaki element izlaznog interfejsa unosi naziv elementa ulaznog interfejsa. Mapiranje je moguće zadati i prevlačenjem mišem elementa ulaznog interfejsa na element izlaznog interfejsa. Oba načina zadavanja mapiranja rezultuju i vizuelnom reprezentacijom mapiranja, što omogućava lakše snalaženje korisniku. Komponenta poseduje i Auto Map opciju, koja je namenjena automatskom mapiranju. Međutim, ova ugrađena funkcionalnost povezuje samo elemente ulaznih i izlaznih interfejsa koji se identično zovu (nije dozvoljena ni razlika u malim i velikim slovima). Iako je ugrađena funkcionalnost automatskog mapiranja u TOS aplikaciji prilično ograničena, sama aplikacija i njena komponenta tmap predstavljaju dobru osnovu za razvijanje prototipa radnog okvira koji koristi ovde izložene principe. Ono što nedostaje TOS aplikaciji, kako bi se mogli stvoriti preduslovi za automatsko mapiranje zasnovano na semantičkom opisu interfejsa jeste mogućnost zadavanja semantike, pa je i ovo predstavljalo neophodnu modifikaciju.
60 5. REFERENTNA IMPLEMENTACIJA RADNOG OKVIRA Eclipse Rich Client Platform Sam TOS je razvijen kao Eclipse Rich Client Platform aplikacija. S obzirom da se izvšava kao deo TOS-a, i naš radni okvir koristi elemente ove platforme. Eclipse Rich Client Platform (RCP) [87], između ostalog, uključuje: Standard Windget Toolkit (SWT), koji Java GUI (graphical user interface) aplikacijama omogućava korišćenje nativnih korisničkih kontrola [100], OSGi [7] radni okvir za razvoj softvera zasnovanog na komponentama, Equinox p2 [78], za upravljanje međuzavisnostima, distribuciju i instalaciju komponenti i jezgro platforme, koje omogućava definisanje raznih edicija aplikacije (Eclipse koristi termin branding), kao i da se krajnja Java aplikacija pokreće iz nativne izvršive datoteke za ciljni operativni sistem umesto java -jar komandom. Na primer, za Windows će biti kreirana datoteka u Portable Executable (PE) formatu sa.exe ekstenzijom, za Linux će biti kreirana datoteka u Executable and Linkable Format (ELF) formatu. Pored platforme, TOS koristi i Generic Workbench (paket org.eclipse.ui) Eclipse IDE (paket org.eclipse.ui.ide) komponente, čime se postiže da izgledom i funkcionalnošću podseća na Eclipse integrisano razvojno okruženje. Apache Jena Apache Jena je slobodan radni okvir otvorenog koda namenjen izradi aplikacija vezanih za semantički veb i Linked Data [69]. Jena se može koristiti za čitanje i pisanje RDF stabala u raznim formatima. Radni okvir poseduje i OWL API, koji može poslužiti za interakciju sa alatima za rezonovanje. U referentnoj implementaciji našeg radnog okvira, Apache Jena je korišćena za za učitavanje ontologije. 5.2 Arhitektura radnog okvira Slika 5.2 sadrži dijagram klasa dela radnog okvira zaduženog za pronalaženje kandidata za mapiranje. Prikazana je infrastruktura koja služi za definisanje modela interfejsa aplikacija koje se integrišu, klasa AutoMapper koja implementira mehanizam obilaska, klase koje omogućavaju da se strukturni model anotira elementima ontologije, interfejs koji omogućava da se definišu komponente koje predstavljaju implementaciju kriterijuma za mapiranje, kao i nekoliko njegovih konkretnih implementacija koje predstavljaju kriterijume date u 4.2. U daljem tekstu ovi delovi arhitekture će biti pobliže opisani.
5.2. ARHITEKTURA RADNOG OKVIRA 61 AutoMapper operations + map() 1 * InputTree -enabledmappers 1 TreeNode attributes -name : String 1 * jena.rdf.model.resource * OutputTree Matcher operations +match( TreeNode input, TreeNode output ) : List<MatchedEntryPair> +getname() : String -source isannotatedwith -destination -sourceannotation AbstractMatcher -destinationannotation disabledby -matchingrule MatchedEntryPair operations +disable( by : MatchedEntryPair ) +equalcause( other : MatchedEntryPair ) : boolean MatchedOntologyPair OntDifferentFrom OntGeneralisation OntSpecialisation SameXPath SameName OntSameElement OntPartOf OntSplitter Slika 5.2: Dijagram klasa Matcher komponenti Strukturni model interfejsa Za omogućavanje definisanja strukture elemenata ulaznih i izlasnih interfejsa koji se integrišu zadužene su klase InputTree, OutputTree i TreeNode. Pomoću ovih klasa definišu se strukture tipa stabla. Klase InputTree i OutputTree predstavljaju korene stabla i može ih biti više, čime je podržano da i po više od jednog ulaznog i izlaznog interfejsa učestvuju u integraciji. Svaka od ovih klasa poseduje kolekciju instanci klase TreeNode, kojom se modeluje jedan element interfejsa. Ova klasa sadrži sledeće atribute: naziv - koristi se izvorni naziv iz aplikacije koja se integriše, tip, dužinu i preciznost, komentar - sadrži verbalni opis uloge ovog elementa interfejsa i može se koristiti za generisanje dokumentacije, rekurzivnu vezu na drugu instancu klase TreeNode, čime su podržane kompozitne strukture i vezu na instancu klase Resource - ova klasa modeluje element ontologije, pa se upravo ovom vezom dodeljuje semantika strukturnom modelu.
62 5. REFERENTNA IMPLEMENTACIJA RADNOG OKVIRA Napominjemo da su ove tri klase izvorno deo TOS-a 1. Definisanje strukture interfejsa jeste jedna od funkcionalnosti koje preuzimamo iz ovog programskog paketa. Naša suštinska modifikacija se sastoji u dodavanju reference na resurse ontologije, čime se omogućava da se model semantički obogati. Interesantan je i pohvalan način na koji su ove, ali i druge modelske klase implementirane u TOS-u. Naime, prvo je sačinjen ECore meta-model, na osnovu kog se generiše Java izvorni kod modelskih klasa. Generisanje skeleta aplikacije svakako nije novina, ali dobra praksa koja je korišćena je da se ovaj ECore model nalazi na istom repozitorijumu i istoj lokaciji kao i izvorni kod. Time se omogućava i ohrabruje da i članovi zajednice, koji unose svoje modifikacije, to čine na samom ECore modelu, čime on ostaje ažuran sa izvornim kodom. Ovakav postupak ispraćen je i prilikom naših izmena. Klasa Resource Ova klasa je deo radnog okvira Jena, koji se koristi za čitanje i manipulaciju ontologijama. Ona i njene naslednice mogu predstavljati bilo koji deo ontologije: klasu, individuu, osobinu, itd. Klasa AutoMapper Klasa AutoMapper implementira osnovni algoritam koji obilazi stabla ulaznih i izlaznih interfejsa i za svaki par njihovih elemenata koristi raspoložive kriterijume za mapiranje, koji su implementacija interfejsa Matcher. Pseudo kod algoritma dat je u listingu 5.1. U proceduri Mapiraj, pretpostavlja se da svaki kandidat za mapiranje poseduje proceduru kandidati(u,i) koji za određeni par interfejsa daje odgovor da li oni predstavljaju kandidata za mapiranje ili ne. Takođe, pretpostavlja se i postojanje procedure proveri(u, i, K, U, I), koja po osnovu nekog kriterijuma za detekciju konflikata odlučuje da li dati kandidat za mapiranje ostaje na važnosti ili će biti ukinut. U implementaciji, rezultat rada prve iteracije kroz parove ulaznih i izlaznih elemenata su kandidati za mapiranje, predstavljeni instancama klase MatchedEntryPair. Ovi kandidati se dalje prosleđuju raspoloživim detektorima konflikata. Nakon razrešavanja eventualnih konflikata, ostaju samo oni kandidati koji zaista treba da se mapiraju. Na osnovu njih se konstruišu izrazi za mapiranje. 1 Unutar TOS-a postoje zasebne klase koje modeluju XML interfejse i druge tipove interfejsa. Za ovo postoje implementacioni razlozi, zbog drugačijeg tretmana u pogledu ostalih komponenti TOS-a. Kako u pogledu pronalaženja mapiranja ove dve vrste modela nema suštinskih razlika sa aspekta našeg radnog okvira, ovaj detalj je izostavljen iz opisa arhitekture.
5.2. ARHITEKTURA RADNOG OKVIRA 63 p r o c e d u r a M a p i r a j 2 u l a z : U s t a b l o u l a z n i h i n t e r f e j s a, I s t a b l o i z l a z n i h i n t e r f e j s a, 4 KMap skup r a s p o l o ž i v i h k r i t e r i j u m a mapiranja, KKonf skup r a s p o l o ž i v i h k r i t e r i j u m a k o n f l i k a t a 6 i z l a z : M skup m a p i r a n j a { 8 K skup k a n d i d a t a za m a p i r a n j e za s v a k i u i z U. e l e m e n t i { 10 za s v a k i i i z I. e l e m e n t i { za s v a k i km i z KMap{ 12 ako su km. k a n d i d a t i ( u, i ) { dodaj ( u, i ) u K 14 } } 16 } } 18 za s v a k i ( u, i ) i z K { za s v a k i kk i z KKonf { 20 r = kk. p r o v e r i ( u, i, K, U, I ) ako r { 22 dodaj ( u, i ) u M } 24 } } 26 } Listing 5.1: Algoritam za traženje mapiranja
64 5. REFERENTNA IMPLEMENTACIJA RADNOG OKVIRA Interfejs Matcher Interfejs Matcher implementiraju sve komponente koje predstavljaju implementaciju kriterijuma za mapiranje, poput onih datih u 4.2. Osnovna metoda interfejsa je metoda match, koja prima dve instance klase TreeNode, od kojih jedna predstavlja element ulaznog interfejsa, a druga element izlaznog interfejsa. Metoda vraća kolekciju instanci klase MatchedEntryPair, koje predstavljaju kandidate za mapiranje. Dakle, omogućeno je da jedan par ulaznih i izlaznih interfejsa po jednom kriterijumu proizvede više mapiranja. Svaki kriterijum treba da implementira i metodu getname, koja vraća deskriptivno ime kriterijuma, nemenjeno za prikazivanje korisniku. Klasa AbstractMatcher AbstractMatcher je apstraktna klasa koja implementira interfejs Matcher i sadrži pomoćne metode koje mogu biti od koristi konkretnim implementacijama. Između ostalog, implementira metodu getname tako da vrati naziv klase, čime se dobija njeno podrazumevano ponašanje. Ukoliko ime klase koja implementira kriterijum nije dovoljno deskriptivno, ovo ponašanje može da se redefiniše. Klasa MatchedEntryPair Klasa MatchedEntryPair predstavlja jednog kandidata za mapiranje. Koristi se kao povratna vrednost metode match interfejsa Matcher. Instanca ove klase ima dve veze na instance klase TreeNode, koje nose informaciju o tome koji ulazni i izlazni element interfejsa učestvuju u ovom mapiranju. Instanca nosi i informaciju o tome na osnovu kog kriterijuma je nastala. U fazi detekcije konflikata kandidati mogu biti u međusobnom konfliktu. Komponenta za razrešavanje konflikata tada može odlučiti da jedan ili oba kandidata poništi pozivom metode disable. Metoda equalcause određuje da li su dva kandidata za mapiranje nastala iz istog razloga, što se koristi u fazi detekcije konflikata. Klasa MatchedOntologyPair Klasa MatchedOntologyPair nasleđuje klasu MatchedEntryPair i predstavlja kandidata za mapiranje koji je nastao kao rezultat kriterijuma koji u obzir uzima i semantiku. Osnovnim atributima nasleđene klase dodaje i dve reference na klasu Resource, koje označavaju na osnovu kog elementa ontologije je detektovano mapiranje. Klasa AbstractOntologyMatcher AbstractOntologyMatcher je klasa koja pomaže pri implementaciji kriterijuma za mapiranje koji koriste semantičko anotiranje strukturalnog modela elementima ontologije. Svaki
5.2. ARHITEKTURA RADNOG OKVIRA 65 element interfejsa može biti anotiran nijednim, jednim ili sa više elemenata ontologije. Ova klasa implementira metodu match tako da za par ulaznih i izlaznih elemenata interfejsa koji se porede, uzima njihove semantičke anotacije i iterira ih svaku sa svakom. Za svaki par anotacija, zatim, poziva apstraktnu metodu matchontologyelements, u kojoj klase koje će naslediti AbstractOntologyMatcher testiraju da li je konkretan kriterijum koji implementiraju zadovoljen. Izvorni kod ove klase prikazan je na listingu 5.2. p u b l i c a b s t r a c t c l a s s A b s t r a c t O n t o l o g y M a t c h e r e x t e n d s 2 AbstractMatcher <MatchedOntologyPair > { p r o t e c t e d Model unionmodel = 4 O n t o l o g y S t o r e. g e t I n s t a n c e ( ). getontmodel ( ) ; 6 @ O v e r r i d e p u b l i c C o l l e c t i o n <MatchedOntologyPair > match ( TreeNode i n p u t, TreeNode o u t p u t ) { 8 L i s t <MatchedOntologyPair > r e t = new A r r a y L i s t <MatchedOntologyPair >() ; i f ( unionmodel!= n u l l ) { 10 f o r ( S t r i n g outontologyelement : o u t p u t. g e t O n t o l o g y E l e m e n t s ( ) ) { 12 f o r ( S t r i n g i n O n t o l o g y E l e m e n t : i n p u t. g e t O n t o l o g y E l e m e n t s ( ) ) { 14 R e s o u r c e i n R e s = unionmodel. g e t R e s o u r c e ( i n O n t o l o g y E l e m e n t ) ; 16 R e s o u r c e outres = unionmodel. g e t R e s o u r c e ( outontologyelement ) ; 18 matchontologyelements ( i n p u t, output, r e t, inres, outres ) ; 20 } } 22 } r e t u r n r e t ; 24 } 26 p r o t e c t e d a b s t r a c t v o i d matchontologyelements ( TreeNode i n p u t, TreeNode output, L i s t <MatchedOntologyPair > r e t, R e s o u r c e inres, 28 R e s o u r c e outres ) ; 30 } Listing 5.2: Izvorni kod klase AbstractOntologyMatcher Klasa OntologyGeneralisation Kao primer implementacije jednog konkretnog kriterijuma za mapiranje, navodimo klasu OntologyGeneralisation, koja se odnosi na kriterijum opisan u 4.2.4. Klasa nasleđuje klasu AbstractOntologyMatcher. U implementaciji metode matchontologyelements (listing 5.3), pristupa se resursima, odnosno elementima ontologije kojima su anotirani ulazni i izlazni element interfejsa koji su prosleđeni metodi. Ukoliko resurs kojim je anotiran ulazni element ima za nadklasu (superklasu) resurs kojim je anotiran izlazni element, tada ovaj par elemenata ispunjava uslove kriterijuma mapiranja koji se ispituje. U tom slučaju, u rezultate se dodaje kandidat za mapiranje koji sadrži ovaj par ulaznih i izlaznih elemenata.
66 5. REFERENTNA IMPLEMENTACIJA RADNOG OKVIRA @ O v e r r i d e 2 p r o t e c t e d v o i d matchontologyelements ( TreeNode i n p u t, TreeNode output, L i s t <MatchedOntologyPair > r e t, R e s o u r c e inres, R e s o u r c e outres ) { 4 i f ( outres. canas ( O n t C l a s s. c l a s s ) && i n R e s. canas ( O n t C l a s s. c l a s s ) ) { 6 O n t C l a s s clout = outres. as ( OntClass. c l a s s ) ; 8 O n t C l a s s c l I n = i n R e s. as ( O n t C l a s s. c l a s s ) ; 10 i f ( c l I n. h a s S u p e r C l a s s ( ( clout ) ) ) { 12 MatchedOntologyPair match = new MatchedOntologyPair ( i n p u t, output, t h i s, c l I n. geturi ( ), clout. geturi ( ) ) ; 14 r e t. add ( match ) ; System. out. p r i n t l n ( " Found o n t o l o g y G e n e r a l i s a t i o n : " 16 + match ) ; } 18 } } Listing 5.3: Metoda klase OntologyGeneralisation koja implementira kriterijum 4.2.4
6 SAIL jezik specifičan za domen Prikazani radni okvir za automatsko mapiranje, detekciju i rešavanje konflikata moguće je proširivati i prilagođavati potrebama konkretnog integracionog scenarija ukoliko je to potrebno. Detektovanje kandidata za mapiranje, detektovanje i razrešavanje konflikata i izgradnju izraza za mapiranje obavljaju zasebne potkomponente, od kojih se svaka može izmeniti, isključiti ili dodati nova. Međutim, za realizaciju izmena komponenti i razvoja novih, neophodno je poznavanje programskog jezika Java i Eclipse RCP ekosistema u kom su razvijeni aplikacija Talend Open Studio, kao i prototip prikazanog radnog okvira za mapiranje. Radni okvir za automatsko mapiranje mogao bi se implementirati i nezavisno od ove aplikacije (kao što je ranije pomenuto, ona je korišćena samo kako bi se ubrzao razvoj prototipa i izbeglo implementiranje neophodne infrastrukture), kao i na nekom drugom jeziku opšte namene (Python, C#, Pharo, itd). Međutim, i takva implementacija bi i dalje bila zavisna od konkretne izabrane tehnologije, odnosno i dalje bi za proširivanje komponenti za automatsko mapiranje bilo neophodno poznavanje njene arhitekture. Kako bi se omogućilo opisivanje komponenti radnog okvira za automatsku integraciju na način nezavisan od tehnologije njihove implementacije, dizajniran je i razvijen jezik specifičan za domen nazvan SAIL: Semantic-Aided Integration Language [138]. Za jezik je razvijen i propratni skup alata koji olakšava korišćenje jezika, kao i generator izvornog koda komponenti. U nastavku ovog poglavlja biće prikazan dizajn jezika, kao i primer njegovog korišćenja. 6.1 SAIL Meta-model Meta-model jezika SAIL na apstraktan način opisuje njegovu strukturu, nezavisno od konkretne sintakse i njene implementacije. Korišćen je ECore meta-meta-model. Kompletan meta-model dat je u obliku stabla na slici 6.1. 67
SparqlExp ConflictResolve Conflict [0**1]vsparqlexp [0**1]vresolve namev:vestring [0**1]vmatcher ConflictMatcher ConflictResolveDisable ConflictResolveOp ConflictResolveIgnore ResolveChoice [0**1]vop Op [0**1]vop vbodyv:vxexpression TripletProp [0**1]vprop OntologyExp Condition [0**1]vmatcher [0**1]vtarget URI uriv:vestring [0**1]vmodifier [0**1]vcondition [0**1]vcontinuation OntAccessor Element Matcher namev:vestring fullnamev:vestring priorityv:veint ContinuationExp Elem OntAnnot [0**0]velements Model vimportsv:vximportsection [0**1]vont ExpressionBuilder [0**1]vout OutputExp InternalOutExp Accessor ElemAnnot [0**1]velem [0**1]vont OntologyImport pathv:vestring FunctionOutExp [0**0]vparams FunctionParam literalv:vestring 68 6. SAIL JEZIK SPECIFIČAN ZA DOMEN Slika 6.1: Meta-model jezika SAIL
6.1. SAIL META-MODEL 69 Meta-klasa Model Model predstavlja korenski kontejner, koji sadrži druge elemente modela, kojima se opisuju komponente radnog okvira. Model sadrži kolekciju uvezenih ontologija, kao instance klasa OntologyImport. Meta-klasa OntologyImport Koristi se za uvoz ontologije koju mogu da koriste komponente za pronalaženje kandidata za mapiranje ili semantičkih konflikata. Poseduje atribut path, kojim se navodi putanja do datoteke u kojoj je definisana ontologija. Meta-klasa Element Element je apstraktna meta-klasa, koju nasleđuju klase koje mogu biti elementi specifikacije komponenti radnog okvira. Element može biti Matcher, Conflict ili ExpressionBuilder. Meta-klasa Matcher Koristi se za definiciju komponente za specifikaciju kriterijuma za pronalaženje kandidata za mapiranje. Poseduje sledeće atribute: name - identifikator, fullname - deskriptivni naziv (opciono), condition - uslov koji definiše da li će neki par elemenata biti kandidat za mapiranje; instanca je meta-klase Condition, continuation - veza sa instancom meta-klase ContinuationExp, kojom se određuje ponašanje nakon što se za neki par elemenata ustanovi da predstavlja kandidata za mapiranje po prethodno datom uslovu (opciono, podrazumevano: nastavlja se poređenje tog para po drugim uslovima) i priority - ceo broj kojim se može odrediti prioritet, odnosno redosled kojim će biti testirani kriterijumi mapiranja, pri čemu veći broj označava veći prioritet (opciono). Meta-klasa ContinuationExp Služi za definisanje ponašanja nakon što se za neki par elemenata ustanovi da predstavlja kandidat za mapiranje po određenom kriterijumu. Mogući su sledeći ishodi:
70 6. SAIL JEZIK SPECIFIČAN ZA DOMEN continue (looking) - nastavlja se poređenje ovog para elemenata korišćenjem ostalih raspoloživih kriterijuma, next (pair) - prelazi se na poređenje sledećeg para elemenata i do {... } - zadaje se operacija koja će biti izvršena korišćenjem ciljnog jezika opšte namene (podrazumevano Java), pri čemu su dostupni komponente i servisi radnog okvira. Meta-klasa Conflict Koristi se za definisanje uslova za detekciju konflikata, kao i načina za njegovo razrešavanje. Poseduje sledeće atribute: name - identifikator, matcher - pomoću ovog atributa moguće je specificirati da se ovaj kriterijum za detekciju konflikata primenjuje samo na kandidate koji su rezultat određenih kriterijuma za mapiranje (opciono, podrazumevano se konflikt primenjuje na sve kandidate), condition - uslov koji definiše kriterijum za detekciju ovog konflikta; instanca je metaklase Condition (opciono), causemultiplicity - koristi se da bi se specificiralo da li se konflikt odnosi na slučajeve kada je par elemenata postao kandidat po više kriterijuma za mapiranje (opciono) i resolve - veza sa instancom meta-klase ConflictResolve, kojom se specificira način na koji će konflikt biti razrešen. Za definiciju konflikta mora biti naveden ili atribut condition ili atribut causemultiplicity. Meta-klasa ConflictResolve Služi za specificiranje načina na koji će konflikt biti razrešen. Može biti jedno od sledećeg: ConflictResolveDisable - kandidat za mapiranje se ukida i neće se uzimati dalje u obzir, ConflictResolveIgnore - konflikt se ignoriše, ResolveChoice - korisniku će biti prepušteno da odluči da li će kandidat za mapiranje biti uzet u obzir i ConflictResolveOp - pokreće se procedura zadata iskazima ciljnog jezika opšte namene (podrazumevano Java), pri čemu su dostupni komponente i servisi radnog okvira.
6.1. SAIL META-MODEL 71 Meta-klasa ExpressionBuilder Koristi se za definisanje načina na koji će, od nekog kandidata za mapiranje, ili grupe kandidata za mapiranje, biti konstruisan izraz ciljnog jezika ili platforme, koji će postati deo integracionog rešenja. Moguće je navesti i uslov pod kojim će se ova definicija primenjivati. Poseduje sledeće atribute: matcher - pomoću ovog atributa moguće je odrediti da se ova specifikacija konstruisanja izraza za mapiranje primenjuje samo na kandidate koji su rezultat određenih kriterijuma za mapiranje (opciono, podrazumevano se konflikt primenjuje na sve kandidate), condition - uslov koji definiše kriterijum koji mora biti zadovoljen da bi se ova specifikacija izraza za mapiranje korisila za određeni par kandidata za mapiranje; instanca je meta-klase Condition (opciono) i out - sama specifikacija konstrukcije izraza, instanca je meta-klase OutputExp. Meta-klasa OutputExp Koristi se za definisanje izgradnje izraza za mapiranje. Način može biti jedan od sledećih: konkatenacija - vrednost izlaznog elementa se dobija konkatenacijom svih ulaznih elemenata, razdvajanje (split) - vrednost izlaznih elemenata se dobija podelom jedne ulazne tekstualne vrednosti ili specifikacija zadata izrazima ciljne platforme, pri čemu je moguće pristupati elementima parova koji se mapiraju. Meta-klasa Condition Koristi se u specifikacijama komponenti kako bi se definisao uslov pod kojim se ta komponenta koristi. Prva vrsta uslova su oni koji se sastoje od jednog iskaza, koji kao rezultat daje Bulovsku vrednost. Uslov je zadovoljen ukoliko je iskaz tačan. Iskaz može biti: literal - direktno navedena tekstualna ili brojevna vrednost, element modela, ili upit nad ontologijom zadat instancom klase SparqlExp. Druga vrsta uslova je poređenje. Poređenje se sastoji iz dve strane koje su iskazi i operatora poređenja. Na raspolaganju su sledeći operatori:
72 6. SAIL JEZIK SPECIFIČAN ZA DOMEN CO_LT - prva strana je manja od druge, CO_GT - prva strana je veća od druge, CO_EQ - strane su jedanke, CO_NE - strane nisu jednake, CO_SUBCLAS_OF - prva strana je potklasa druge, CO_SUPERCLASS_OF - prva strana je nadklasa druge, CO_PART_OF - prva strana je deo druge i CO_DIFFERENT_FROM - prva i druga strana ne predstavljaju istu instancu. Uslov može biti i konjunkcija ili disjunkcija više uslova. Meta-klasa SparqlExp Omogućava da se definiše korišćenje SPARQL upita nad uvezenim ontologijama. Poseduje sledeće atribute: query - tekst SPARQL upita, pri čemu je moguće koristiti vrednosti iz modela, tako što se identifikator elementa modela navodi u vitičastim zagradama i condition - uslov koji treba da bude zadovoljen da bi rezultat ovog upita bio smatran tačnim kada se koristi u definiciji instance meta-klase Condition. 6.2 Implementacija jezika Jezik SAIL je implementiran pomoću radnog okvira Xtext 1, koji je deo Eclipse ekosistema. Za zadatu gramatiku Xtext generiše editor koji podržava bojenje sintakse, dovršavanje izraza, sintaksnu proveru (uz mogućnost implementiranja semantičkih provera), kao i pregled strukture koda pisanog ciljnim jezikom (layout) [36], kao što je prikazano na slici 6.2. Transformaciju izvornog koda razvijenog jezika u iskaze nekog ciljnog jezika moguće je implementirati korišćenjem jezika Xtend 2 i obrađivača šablona Xpand 3 Gramatika jezika data je u listingu 6.1. Koncepti jezika zasnovani su na komponentama razvojnog okvira za automatsku integraciju i njihovim podešavanjima, kao i izrazima za pristup elementima interfejsa i elementima ontologije. 1 https://eclipse.org/xtext 2 https://www.eclipse.org/xtend/ 3 http://wiki.eclipse.org/xpand
6.2. IMPLEMENTACIJA JEZIKA 73 Slika 6.2: SAIL editor i outline alati grammar r s. ac. uns. f t n. i n f o r m a t i k a. S a i l 2 with org. e c l i p s e. x t e x t. xbase. Xbase 4 g e n e r a t e s a i l 6 Model : i m p o r t s=x I m p o r t S e c t i o n? 8 ( ont=ontologyimport )? e l e m e n t s+=element 10 ; 12 Element : Matcher 14 C o n f l i c t E x p r e s s i o n B u i l d e r 16 ; 18 OntologyImport : Ontology path=string 20 ; 22 / Matcher / Matcher : 24 Matcher name=id ( f u l l name fullname=string)? 26 c o n d i t i o n=c o n d i t i o n ( c o n t i n u a t i o n=c o n t i n u a t i o n E x p )? 28 ( p r i o r i t y p r i o r i t y=int )? ; 30 32 C o n t i n u a t i o n E x p : when found 34 ( c o n t=keeplookingenum op=op) ; 36 Op : 38 do body=x B l o c k E x p r e s s i o n ; 40
74 6. SAIL JEZIK SPECIFIČAN ZA DOMEN KeepLookingEnum : 42 CNT_KEEP_LOOKING= c o n t i n u e ( l o o k i n g )? CNT_NEXT_PAIR= next ( p a i r )? 44 ; 46 / C o n f l i c t d e t e c t i o n and r e s o l v i n g / C o n f l i c t : 48 C o n f l i c t name=id ( matcher=c o n f l i c t M a t c h e r )? 50 ( c o n d i t i o n=c o n d i t i o n )? ( c a u s e M u l t i p l i c i t y=c o n f l i c t C a u s e M u l t i p l i c i t y )? 52 r e s o l v e=c o n f l i c t R e s o l v e ; 54 C o n f l i c t M a t c h e r : 56 matcher k i n d=c o n f l i c t M a t c h e r K i n d 58 ; 60 C o n f l i c t M a t c h e r K i n d : C o n f l i c t M a t c h e r S p e c i f i c 62 C o n f l i c t M a t c h e r A n y ; 64 C o n f l i c t M a t c h e r S p e c i f i c r e t u r n s C o n f l i c t M a t c h e r K i n d : 66 matchers+=[matcher ] (, matchers+=[matcher ] )? 68 ; 70 C o n f l i c t M a t c h e r A n y r e t u r n s C o n f l i c t M a t c h e r K i n d : anymatcher?= any 72 ; 74 C o n f l i c t C a u s e M u l t i p l i c i t y : same r e a s o n 76 m u l t i p l i c i t y=c o n f l i c t C a u s e M u l t i p l i c i t y E n u m ; 78 C o n f l i c t C a u s e M u l t i p l i c i t y E n u m : 80 ML_MULTIPLE= m u l t i p l e ML_SINGLE= s i n g l e 82 ; 84 C o n f l i c t R e s o l v e : r e s o l v e ( 86 C o n f l i c t R e s o l v e D i s a b l e C o n f l i c t R e s o l v e I g n o r e 88 C o n f l i c t R e s o l v e O p R e s o l v e C h o i c e 90 ) ; 92 C o n f l i c t R e s o l v e D i s a b l e : 94 r e s o l v e= d i s a b l e ; 96
6.2. IMPLEMENTACIJA JEZIKA 75 98 C o n f l i c t R e s o l v e I g n o r e : r e s o l v e= i g n o r e 100 ; 102 C o n f l i c t R e s o l v e O p : op=op 104 ; 106 R e s o l v e C h o i c e : use use=usetypeenum 108 ; 110 UseTypeEnum : UT_FIRST= f i r s t 112 UT_LAST= l a s t UT_USER= u s e r c h o i c e 114 UT_PRIORITY= p r i o r i t y ; 116 C o n d i t i o n : c o n d i t i o n e x p r=compareexp 118 ; 120 / E x p r e s s i o n b u i l d e r / E x p r e s s i o n B u i l d e r : 122 O u t E x p r e s s i o n matcher=c o n f l i c t M a t c h e r 124 ( c o n d i t i o n=c o n d i t i o n )? out out=outputexp 126 ; 128 OutputExp : I n t e r n a l O u t E x p 130 FunctionOutExp ; 132 I n t e r n a l O u t E x p : 134 InternalExpTypeEnum elem=a c c e s s o r with 136 w i t h S t r=string ( n u l l ( s u b s t i t u t e )? n u l l S u b=string)? 138 ( o r d e r elems+=orderelem (, elems+=orderelem ) )? ; 140 OrderElem : 142 name=string ( i g n o r e?= i g n o r e )? ; 144 InternalExpTypeEnum : IE_CONCATENATE= c o n c a t e n a t e 146 IE_SPLIT= s p l i t ; 148 FunctionOutExp : 150 f u n c t i o n fname=functionnameenum 152 (
76 6. SAIL JEZIK SPECIFIČAN ZA DOMEN => ( params+=functionparam 154 (, params+=functionparam ) )? ) 156 ; 158 FunctionParam : elem=elem 160 l i t e r a l = (STRING Number ) ; 162 FunctionNameEnum : 164 FN_SUM= SUM FN_AVG= AVG 166 // e t c... ; 168 / Comparison / 170 CompareOr : l e f t=compareand 172 ( or r i g h t+=compareand ) ; 174 CompareAnd : 176 l e f t=compareexp ( and r i g h t+=compareexp ) 178 ; 180 CompareExp : l e f t=compareside 182 ( op=compareop r i g h t=compareside )? ; 184 CompareSide : 186 { CompareSide } ( ( q u a n t i f i e r=q u a n t i f i e r )? a c c e s s o r=a c c e s s o r ) 188 d i r e c t =(STRING Number ) s p a r q l=sparqlexp ; 190 CompareOp : 192 CO_LT= < CO_GT= > 194 CO_EQ= = CO_NE=!= 196 CO_SUBCLAS_OF= s u b c l a s s O f CO_SUPERCLASS_OF= s u p e r c l a s s O f 198 CO_PART_OF= partof CO_DIFFERENT_FROM= d i f f e r e n t F r o m 200 ; 202 Q u a n t i f i e r : EVERY= e v e r y EXISTS= e x i s t s 204 ; 206 / I n t e r f a c e a c c e s s o r s / A c c e s s o r : 208 Elem
6.2. IMPLEMENTACIJA JEZIKA 77 ElemAnnot 210 OntAccessor ; 212 Elem : 214 {Elem} ( s i d e=inputoutputenum )? 216 ( p a i r?= p a i r )? ( p a r t=elempartenum )? 218 ; 220 ElemPartEnum : EP_NAME= name 222 EP_TYPE= type EP_LEN= l e n 224 EP_XPATH= xpath EP_COUNT= count ; 226 ElemAnnot : 228 s i d e=inputoutputenum ont=ontannot 230 ( m o d i f i e r=ontologyexp )? ; 232 InputOutputEnum : IO_INPUT= i n p u t 234 IO_OUTPUT= output ; 236 / Ontology r e l a t e d / OntAccessor : 238 OntAnnot \ a c r s h o r t { u r i } ; 240 OntAnnot : {OntAnnot} a n n o t a t i o n ; 242 \ a c r s h o r t { u r i } : 244 onturi ( u r i=string ) ; 246 OntologyExp : k i n d=ontelemkindenum ( prop=t r i p l e t P r o p )? ; 248 OntElemKindEnum : 250 OE_CLASS= c l a s s OE_INDIVIDUAL= i n d i v i d u a l ; 252 T r i p l e t P r o p : has p a r t=tripletpartenum t a r g e t=ontaccessor ; 254 TripletPartEnum : 256 TP_SUBJECT= s u b j e c t TP_PREDICATE= p r e d i c a t e 258 TP_OBJECT= o b j e c t ; 260 / \ a c r s h o r t { s p a r q l } / SparqlExp : 262 SparqlQuery r e t u r n s c o n d i t i o n=s p a r q l R e t u r n ; 264 S p a r q l R e t u r n :
78 6. SAIL JEZIK SPECIFIČAN ZA DOMEN SparqlReturnAny 266 SparqlReturnRegEx S p a r q l B o o l e a n R e t u r n ; 268 S p a r q l B o o l e a n R e t u r n : 270 boolean=( t r u e f a l s e ) ; 272 SparqlReturnRegEx : regex=string ; 274 SparqlReturnAny : 276 { SparqlReturnAny } any ; 278 SparqlQuery : \ a c r s h o r t { s p a r q l } query=string ; Listing 6.1: Gramatika jezika SAIL Izrazi za pristup elementima okruženja Svaki izraz se podrazumevano odnosi na par ulaznih i izlaznih interfejsa koji se trenutno obrađuju. Ulazni interfejs se identifikuje ključnom reči input, a izlazni ključnom reči output. Ulazni i izlazni interfejsi imaju sledeća svojstva, kojima se može pristupiti navođenjem iza ključne reči koja se odnosi na interfejs, uz razdvajanje tačkom: name - naziv elementa interfejsa, type - tip podataka elementa interfejsa, length - dozvoljena dužina sadržaja, count - broj elemenata interfejsa i annotation - semantičke anotacije pridružene elementu. Uslovni izrazi Uslovni izraz počinje ključnom reči condition, iza koje se navodi izraz koji opisuje kada je uslov ispunjen, a sastoji se od kombinacije izraza za pristup elementima, literala, operatora za poređenje (=,<,>,<=,=>,<>) i konjunkcije, disjunkcije ili negacije (and, or, not). Kriterijum mapiranja Definicija kriterijuma mapiranja počinje ključnom reči Matcher, nakon koje se navodi identifikator kriterijuma. Moguće je, zatim, navesti i puno ime kriterijuma iza ključnih reči full name, unutar navodnika. Sledi uslovni izraz koji treba da bude zadovoljen da bi par elemenata ulaznog i izlaznog bili smatrani kandidatom za mapiranje. Ukoliko neki par
6.2. IMPLEMENTACIJA JEZIKA 79 zadovolji uslov za mapiranje po ovom kriterijumu, možemo hteti da se nastavi provera po ostalim kriterijumima za isti par ili da se pređe na sledeći par - u zavisnosti od semantike kriterijuma. Ovo se navodi pomoću konstrukcije when found continue [looking] ili when found next [pair]. Detektor konflikata Definicija komponente za detekciju konflikata počinje ključnom reči Conflict, nakon koje se navodi identifikator detektora. Možemo odabrati da detektor gleda kandidate za mapiranje koje su proizveli samo određeni kriterijumi za mapiranje. Ovo se postiže navođenjem ključne reči matcher, iza koje sledi spisak identifikatora kriterijuma mapiranja. Ukoliko detektor važi za bilo koji kriterijum mapiranja, navodimo matcher any. Zatim se navodi uslovni izraz konflikta. Način razrešavanja konflikta navodi se nakon ključne reči resolve. Načini razrešavanja su sledeći: ignore - konflikt se ignoriše, none - konflikt se prijavljuje, ali se ne razrešava automatski, disable ili drop - kandidat za mapiranje se odbacuje, use first - u slučaju više kandidata za mapiranje koristi se prvi, use last - u slučaju više kandidata za mapiranje koristi se poslednji, user choice - u slučaju više kandidata za mapiranje korisniku se prikazuje dijalog za izbor, do - navodi se blok Java koda koji će biti izvršen, ili call - poziva se eksterna komponenta. Konstruktori izraza za mapiranje (expression builder) Konstruktor izraza za mapiranje počinje ključnom reči OutExpression. Iza ključne reči matcher opciono se mogu navesti identifikatore kriterijuma za mapiranje za koje se primenjuje ovaj konstruktor. Zatim se navodi uslovni izraz koji odlučuje da li će ovaj konstruktor biti korišćen. Ukoliko više konstruktora izraza po ovim kriterijumima mogu biti korišćeni za određeno mapiranje, biće korišćen konstruktor koji je poslednji naveden. Način na koji će biti izgrađen izraz navodi se iza ključne reči out. Na raspolaganju su sledeći izrazi: concatenate [with "<delimiter> "] - vrednosti elemenata ulaznih interfejsa se konkateniraju, uz opciono navođenje stringa koji će biti korišćen za razdvajanje, split "<delimiter >" - ulazni string se razdvaja, a delovi dodeljuju elementima izlaznog interfejsa, function - korišćenje ugrađenih funkcija poput SUM() i AVG(), ignore - preskače određeni element interfejsa i
80 6. SAIL JEZIK SPECIFIČAN ZA DOMEN null substitute "<string> " - omogućava da se nedostajuće vrednosti zamene određenim stringom. Kao primer SAIL specifikacije navodimo listing 6.2 u kom su definisane neke od komponenti navedenih u 4.2. Ovakva definicija korišćena je za testiranje implementacije jezika, poređenjem ponašanja izvršivih komponenti, dobijenih njenom transformacijom, sa ranije ručno razvijenim komponentama. Matcher samename 2 f u l l name "Same name" c o n d i t i o n i n p u t name = output name 4 and i n p u t type = output type Matcher sameontologyannotation 6 c o n d i t i o n i n p u t a n n o t a t i o n = output a n n o t a t i o n Matcher a g g r e g a t i o n 8 c o n d i t i o n output a n n o t a t i o n partof i n p u t a n n o t a t i o n Matcher s p l i t t e r 10 c o n d i t i o n i n p u t a n n o t a t i o n partof output a n n o t a t i o n Matcher s p e c i a l i s a t i o n 12 c o n d i t i o n i n p u t a n n o t a t i o n s u p e r c l a s s O f output a n n o t a t i o n 14 Matcher g e n e r a l i s a t i o n c o n d i t i o n i n p u t a n n o t a t i o n s u b c l a s s O f output a n n o t a t i o n 16 Matcher r e j e c t i o n c o n d i t i o n i n p u t a n n o t a t i o n i n d i v i d u a l 18 d i f f e r e n t F r o m output a n n o t a t i o n i n d i v i d u a l C o n f l i c t m u l t i p l e M a p p i n g s 20 matcher any same r e a s o n m u l t i p l e 22 r e s o l v e use l a s t C o n f l i c t t y p e D i f f e r e n t 24 matcher any c o n d i t i o n i n p u t type!= output type 26 r e s o l v e do{ System. out. p r i n t l n ( " Java code h e r e " ) ; } 28 O u t E x p r e s s i o n matcher s p e c i a l i s a t i o n, r e j e c t i o n 30 c o n d i t i o n p a i r count > 1 and e v e r y p a i r type = " S t r i n g " 32 out c o n c a t e n a t e i n p u t name with " " O u t E x p r e s s i o n 34 matcher any c o n d i t i o n p a i r count > 1 36 and e v e r y p a i r type = "Number" out f u n c t i o n SUM( output name ) 38 O u t E x p r e s s i o n matcher a g g r e g a t i o n 40 c o n d i t i o n output name = " a d d r e s s " out c o n c a t e n a t e i n p u t name with " \n" 42 o r d e r " s t r e e t ", " number ", " z i p " i g n o r e, " c i t y " O u t E x p r e s s i o n 44 matcher s p l i t t e r out s p l i t with ", " n u l l s u b s t i t u t e " " Listing 6.2: Primer korišćenja SAIL jezika
7 Evaluacija Validnost prikazanog radnog okvira i mogućnost primene razvijene prototipske implementacije testirani su na dva realna integraciona scenarija, kao i jednim eksperimentom. Za oba scenarija je prethodno postojala ručna implementacija integracionog rešenja. U oba slučaja uspešno je postupkom prikazanim u poglavlju 4 i alatom prikazanom u 5 dobijeno rešenje koje funkcionalno ne odstupa od ranije ručno razvijenog. Sprovedeni eksperiment kroz nekoliko konstruisanih zadataka poredi vreme neophodno da se interfejsi mapiraju ručno i upotrebom alata za automatsko mapiranje. 7.1 Scenario 1: dom za negu starih Ova sekcija prikazuje prvi od dva razmatrana integraciona scenarija. Prvo je izložen sam scenario, a zatim su predstavljeni protokoli i formati podataka koji koriste aplikacije koje se integrišu. Slede opisi ručne implementacije i implementacije radnim okvirom predstavljenim u prethodna dva poglavlja. Na kraju, data je diskusija o izazovima uočeni u toku razvijanja rešenja ovog scenarija. 7.1.1 Scenario Dom za negu starih lica poseduje informacioni sistem zasnovan na komercijalno raspoloživom softverskom paketu. Klijenti ove ustanove upućuju se periodično u lokalnu bolnicu na redovan godišnji pregled. Za potrebe pregleda urađene su analize krvi u dve različite laboratorije. Jedna je rezultate poslala kao CSV, a druga kao XLS datoteke. Opšte podatke o svakoj osobi, koji se nalaze u bazi podataka aplikacije za evidenciju o korisnicima doma, potrebno je spojiti sa rezultatima analiza i poslati bolnici u obliku HL7 poruka, poput one koja je prikazana na listingu 7.1. Podaci se šalju bolnici samo ukoliko rezultati analiza sadrže vrednosti koje odstupaju od referentnih, pa je potrebna analiza specijaliste. Šema scenarija prikazana je na slici 7.1. 81
82 7. EVALUACIJA Slika 7.1: Integracioni scenario razmene rezultata krvi. Kako je broj korisnika velik, neophodno je automatizovati proces obrade rezultata i slanja na dodatnu analizu. 2 MSH ^~\& HCM SAP T e s t S i s Nexus 20130218080959 MFN^M05 0 1 1 6 6 4 2 2 P 2. 3 4 NP97I0 MFI LOC NE 6 MFE LOC Regal Eagle H o s p i t a l ^^ 8 0000010133 Thesis S t r.33 52^^ B l u f f o o n i a ^^14193^BF 030/8955 0~030/8955 5055 10 MFE 12 MSH ^~\& T e s t S i s Nexus HCM SAP 14 20130826233743.528+0200 ACK^M05 5 0 1 P 2. 3 16 MSA AA 0 1 1 6 6 4 2 2 Listing 7.1: Primer razmene poruka u HL7 formatu 7.1.2 Formati i protokoli od interesa u scenariju U prvom scenariju javljaju se poruke u HL7, CSV i XLS formatima. HL7 Standard HL7 primenjuje se u domenu informacionih sistema zdravstvene zaštite. Standardom rukovodi Health Level Seven International, neprofitna organizacija, akreditovana od strane ANSI (American National Standards Institute), koja se bavi donošenjem radnih okvira i pridruiženih standarda za razmenu, integraciju, deljenje i dobavljanje podataka iz oblasti zdravstva u elektronskoj formi. 1 Broj sedam u nazivu standarda i organizacije odnosi se na sedmi (aplikativni) nivo ISO/OSI (International Organization for Standardization Open Systems Interconnection) modela mrežne komunikacije. Komunikacija se odvija 1 http://www.hl7.org/about
7.1. SCENARIO 1: DOM ZA NEGU STARIH 83 razmenom poruka. Poruka može biti u XML formatu ili u tzv. pipe-and-hat formatu, svojstvenom za HL7. Struktura poruka je hijerarhijska i poruke se sastoje od segmenata, polja, komponenti i podkomponenti. U pipe-and-hat formatu, određeni karakteri se koriste za razdvajanje delova poruke. Svi karakteri za razdvajanje, osim karaktera za razdvajanje segmenta, koji je uvek heksadecimalna vrednost 0x0D, mogu se konfigurisati u sklopu MSH segmenta (Message Header, zaglavlje poruke). Najčešće se koriste sledeći karakteri 2 : 0x0D razdvajanje segmenta razdvajanje polja, pipe (cev) ^ razdvajanje komponenti, hat (šešir) & razdvajanje podkomponenti razdvajanje ponovljenog polja CSV Comma-Separated Values je format u kom se polja odvajaju određenim karakterom, najčešće zarezom. Formalni opis ovog formata dat je u dokumentu RFC4180 [122]. Kako je naznačeno i u samom dokumentu, on ne predstavlja propisani standard za ovaj format, već ga samo dokumentuje i pruža informacije o njegovom korišćenju Internet zajednici. Jednostavnost formata i činjenica da koristi tekstualni zapis čine ga lakim za obradu i lako prenosivim na razne sisteme i platforme. Istovremeno, s obzirom da ne postoji formalan standard koji ga definiše, podaci koji su zapisani ovim formatom mogu biti protumačeni na različite načine. Navodimo neke moguće uzroke ovakvih višeznačnosti: jedan zapis nalazi se u jednoj liniji, pri čemu način na koji se odvajaju linije zavisi od operativnog sistema (CR, CRLF, LFCR, LF), za odvajanje polja unutar jednog zapisa u upotrebi su razni karakteri: razmak, zarez, tačka-zarez, tab; unutar datoteke ili poruke ne postoji zaglavlje koje definiše koji karakter se koristi za odvajanje (ova informacija se može prenositi eksterno, npr. u okviru HTTP zaglavlja, kao deo MIME (Multipurpose Internet Mail Extensions)pojo oznake, ukoliko se CSV sadržaj prenosi ovim protokolom) prva linija u datoteci može, ali ne mora sadržati nazive polja, polja mogu, a ne moraju biti uokvirena navodnicima i ne postoji formalno definisan način za predstavljanje NULL vrednosti, npr. drugo polje u zapisu aaa bbb može se tumačiti i kao prazan string i kao NULL. XLS je format datoteke koji koristi aplikacija Microsoft Excel kao podrazumevani format do verzije 2007. Zapis u datoteci je binaran. U pitanju je vlasnički format, pa dostupnost i legalnost alata za programsko čitanje i upisivanje u ovakve datoteke zavisi od proizvođača. Postiji detaljna opisna specifikacija formata 3. 2 http://healthstandards.com/blog/2007/09/24/hl7-separator-characters/ 3 https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-xls
84 7. EVALUACIJA 7.1.3 Ručna implementacija Integraciono rešenje je implementirano radnim okvirom Apache Camel. Za specifikaciju ruta je korišćen Camel-ov Java JSD. Podaci dobijeni od laboratorija stižu kao datoteke CSV ili XLS formata i snimaju se u direktorijum nazvan RESULTS_INBOX. Čim neka datoteka pristigne u navedeni direktorijum, čita se i pretvara u Camel poruku. File komponenta potom premešta datoteku u drugi folder, čime je označava kao obrađenu. Zatim se poruka prosleđuje Content-based Router-u, koji na osnovu tipa datoteka, utvrđenog iz zaglavlja, poruku dalje šalje na rutu za obradu datog tipa. Deo Camel rute za čitanje datoteka i rutiranje na osnovu tipa prikazan je na listingu 7.2. from ( " f i l e : " + RESULTS_INBOX) 2. r o u t e I d ( " f i l e " ). c h o i c e ( ) 4. when ( header ( " CamelFileName " ). endswith ( ". x l s " ) ) 6. to ( " d i r e c t : XLSTestResults " ). when ( header ( " CamelFileName " ) 8. endswith ( ". c s v " ) ). to ( " d i r e c t : CSVTestResults " ) ; Listing 7.2: Apache Camel ruta za čitanje datoteka i slanje na dalju obradu na osnovu tipa datoteke Za čitanje iz baze podataka korišćena je SQL Camel komponenta, kao što je prikazano na listingu 7.3. Prilikom zadavanja upita za SQL komponentu, moguće je koristiti imenovane parametre. Naziv imenovanog parametra navodi se iza kombinacije znakova :#, a na to mesto biće umetnuta vrednost pronađena u polju zaglavlja poruke sa istim nazivom. Potrebno je prvo na osnovu imena, prezimena i datuma rođenja (što su podaci raspoloživi u laboratorijskim rezultatima) pronaći unos vezan za ovog korisnika u tabeli PFLEGEBED (nem. postelja za brigu). Vrednost primarnog ključa Z_PF za pronađeni unos postavlja se u zaglavlje poruke, što se postiže upotrebom procesora MapBodyToHeader. Svrha ovog procesora je da jedan red tabele dobijen od SQL komponente mapira u zaglavlje tako što će kreirati parametar zaglavlja sa nazivom jednakim nazivu kolone i vrednošću jednakoj vrednosti u bazi. Vrednost ključa Z_PF prosleđuje se uskladištenoj proceduri koja prikuplja podatke o pacijentu iz sedam tabela i smešta ih u jedan red privremene tabele Export. Ova uskladištena procedura je deo aplikacije za vođenje evidencije o klijentima.
7.1. SCENARIO 1: DOM ZA NEGU STARIH 85 from ( " d i r e c t : loaddb " ). r o u t e I d ( " Database " ) 2. p r o c e s s ( new P a t i e n t H e a d e r s ( ) ). to ( " s q l : " + makepatientquery ( ) ) 4. p r o c e s s ( new FirstItemToBody ( ) ). p r o c e s s ( new MapBodyToHeader ( ) ) 6. to ( " s q l : exec [ dbo ]. [ E x p o r t i e r e D e b i t o r _ E v e n t ] :#Z_PF " + "? datasource=db " ) 8. setbody ( s i m p l e ( " " ) ). to ( " s q l : s e l e c t top ( 1 ) " 10 + " from [ DemoDBVivAmbulant ]. [ dbo ]. [ Export ] " + " where Pflegebed_Z_PF = :#Z_PF? datasource=db " ) 12. p r o c e s s ( sqltobean ) ; Listing 7.3: Pronalazak vrednosti primarnog ključa u tabeli baze podataka na osnovu identifikacionih podataka pronađenih u rezultatima analize krvi Podaci iz laboratorije i opšti podaci o klijentu spajaju se primenom Aggregator-a, kao što je prikazano na listingu 7.4. Zatim se proverava da li u rezultatu postoje vrednosti koje su van referentnih opsega. Ukoliko postoje povišene ili povećane vrednosti neke analize, poruka se prosleđuje komponenti koja dobijene POJO klase pretvara u HL7 objektni model, a zatim, korišćenjem HAPI biblioteke, konstruiše string u HL7 pipe-and-hat formatu i šalje ga bolnici na analizu. Pored definisanja prikazanih ruta, koje rukovode procesom koji se odvija prilikom prispeća svake analize, bilo je neophodno razviti i nekoliko Camel procesora i pratećih komponenti. Ovi procesori, poput PatientBeanToHL7 zaduženi su za mapiranje i konverziju podataka iz jednog oblika u drugi. 2 from ( " d i r e c t : a g g r e g a t e " ). r o u t e I d ( " a g g r e g a t o r " ). to ( " l o g : t e s t? l e v e l=debug&showheaders=t r u e " ) 4. a g g r e g a t e ( header ( " i d S t r i n g " ), new E n r i c h P a t i e n t R e s u l t s ( ) ). c o m p l e t i o n S i z e ( 2 ) 6. p r o c e s s ( new R e s u l t s A l e r t T o H e a d e r ( ) ). c h o i c e ( ) 8. when ( header ( R e s u l t s A l e r t T o H e a d e r. HAS_ALERTS). isequalto ( t r u e ) ) 10. to (DIRECT_HOSPITAL) ; 12 from ( DIRECT_HOSPITAL). p r o c e s s ( new PatientBeanToHL7 ( ) ) 14. to ( " mina2 : tcp : / / l o c a l h o s t :333? sync=t r u e &codec=#h l 7 c o d e c " ) ; Listing 7.4: Agregacija i prosleđivanje ukoliko rezultati odstupaju od referentnih vrednosti
86 7. EVALUACIJA 7.1.4 Implementacija prikazanim radnim okvirom Nakon opisa ručne implementacije radnim okvirom Apache Camel, predstavljamo implementaciju koja je realizovana radnim okvirom za automatizovano mapiranje predstavljenim u poglavljima 4 i 5. Za potrebe opisa semantike sistema obuhvaćenih integracionim scenariom izrađena je ontologija. Za izradu ontologije korišćen je alat Protégé 4. Zatim je kreiran TOS projekat koji opisuje integracioni scenario. U okviru projekta kreiran je TOS Job, prikazan na slici 7.2, kojim se obavlja agregacija podataka iz XLS i SQL izvora. Sličan Job kreiran je i za slučaj da je ulaz datoteka u CSV formatu. Proces agregacije započinje komponentom koja čeka da se u određenom direktorijumu pojave nove XLS datoteke. Pojava datoteka okida događaj koji aktivira tfileinputexcel ulazni konektor. Konektor čita podatke iz prispelih datoteka. U okviru tfileinputexcel komponente definisana je i šema Excel tabele, odnosno lokacije redova i kolona odakle se podaci čitaju. Paralelno sa čitanjem datoteka iz prvog izvora, obavlja se i upit nad tabelom baze podataka u kojoj se nalazi rezultat uskladištene procedure koja sakuplja detalje o korisniku doma. Ovo obavlja ulazni konektor tmssqlinput, u okviru čijih podešavanja je definisana i šema date tabele. Definisanje šeme obavljeno je automatski, čitanjem metapodataka sa servera baze podataka. Izlazni konektor thl7output zadužen je za slanje objedinjenih rezultata serveru bolnice u HL7 formatu. U okviru ove komponente definisana je šema HL7 dokumenta. Samo mapiranje dva ulazna na jedan izlazni interfejs obavlja komponenta txmlmap, u okviru koje funkcioniše implementirani mehanizam za automatizovano mapiranje i detekciju konflikata. Izgled korisničkog interfejsa ove komponente, nakon završetka procesa mapiranja vidi se na slici 7.3. Grafički prikaz mapiranja vidljiv je u gornjem delu interfejsa. Ovaj prikaz omogućava korisniku kontrolu rezultata, kao i eventualne ručne intervencije nakon završetka automatskog procesiranja. U donjem delu komponente vidljiv je prikaz detalja selektovanog ulaznog i izlaznog interfejsa. U dijalogu za definisanje šeme korisnik može anotirati neki element interfejsa elementom ontologije, što se čini klikom na dugme u koloni Ontology Element. Isto se može učiniti na dijalozima svakog zasebnog konektora, uz definiciju strukture njegove šeme. Umesto u dijalogu svake od šema, anotiranje može biti obavljeno i u dijalogu komponente tmap, kojom se kontroliše mapiranje. 4 https://protege.stanford.edu - Protégé - besplatan alat i radni okvir otvorenog koda namenjen uređivanju ontologija i razvoju inteligentnih sistema
7.1. SCENARIO 1: DOM ZA NEGU STARIH 87 Slika 7.2: TOS Job koji agregira XLS i SQL ulaze u HL7 izlaz
Slika 7.3: Mapiranje koje je automatski dobijeno radnim okvirom 88 7. EVALUACIJA
7.2. SCENARIO 2: PORTAL ZA VOÐENJE PROJEKATA 89 7.2 Scenario 2: portal za vođenje projekata Ovaj integracioni scenario je deo softverskog rešenja za praćenje projekata, razvijenog u okviru kompanije PI Informatik GmbH iz Berlina. Za scenario je postojalo rešenje ručno implementirano u ovoj kompaniji. Razvili smo drugo rešenje, korišćenjem ovde prikazanog prototipa radnog okvira za automatsko mapiranje i funkcionalno ga uporedili sa prethodnim. 7.2.1 Scenario Portal za vođenje projekata nudi SOAP veb servis koji omogućava dobavljanje informacija o nekom projektu. Podaci o projektima jednog dela većeg poslovnog sistema se nalaze u starijoj verziji sistema, koja koristi SAP okruženje. Ovo starije rešenje se i dalje aktivno koristi, a podaci ažuriraju, pa prosti uvoz podataka iz starije u noviju verziju nije adekvatno rešenje. Neophodno je sprovesti integraciju. Kada SOAP servis primi zahtev, potrebno je pozvati BAPI funkciju starog sistema koja izvozi podatke o projektima, pretvoriti ih u XML oblik i kao takve vratiti SOAP odgovorom. 7.2.2 Formati i protokoli od interesa u scenariju Remote Function Call Remote Function Call (RFC) je protokol za komunikaciju između različitih SAP sistema, kao i za omogućavanje pozivanja funkcija SAP aplikacija od strane drugih aplikacija, kao što je opisano u [1]. Postoje tri verzije, odnosno tri načina korišćenja SAP RFC: synchronous RFC (srfc), koji koristi sinhronu komunikaciju, Transactional RFC (trfc), koji podrazumeva asinhronu komunikaciju i garantuje transakcioni integritet, Queued RFC (qrfc), koji radi poput trfc, ali vodi računa o redosledu operacija i Background RFC (bgrfc), koji omogućava i sinhroni i asinhroni način rada, kao i definisanje međuzavisnosti različitih redova čekanja operacija. U svim verzijama RFC za prenos mogu koristiti CPI-C 5 ili TCP/IP protokol stek. SAP BAPI BAPI (Business Application Programming Interface) je interfejs za integraciju SAP aplikacija sa drugim aplikacijama. Koriste ga i različite komponente SAP aplikacija za međusobnu saradnju i komunikaciju. Eksterne aplikacije mogu pozivati BAPI funkcije koristeći RFC (Remote Function Call) protokol. SAP business object (poslovni objekat) u 5 Common Programming Interface for Communications (CPI-C) je protokol za međusobnu komunikaciju programa koji se izvršavaju na različitim sistemima, razvijen od strane IBM-a [2]
90 7. EVALUACIJA SAP sistemima predstavlja reprezentaciju nekog poslovnog entiteta (npr. narudžbina, klijent, banka). U skladu sa osnovnim principima objektno-orijentisane paradigme [129], obuhvata podatke - u vidu atributa i ponašanje - u vidu metoda. Interakcija sa SAP poslovnim objektima od strane drugih aplikacija ostvaruje se putem BAPI-ja. [1] Uz BAPI funkcije koje dolaze uz aplikaciju moguće je definisati i nove. Kako bi se pozvao neki BAPI metod, neophodno je poznavati sledeće: naziv BAPI-ja i detalje BAPI interfejsa, koji obuhvataju: ulazne parametre, izlazne parametre i tabele. Tabele predstavljaju rezultat izvršavanja BAPI-ja i kroz njih se može dobaviti vrednost instanci poslovnih objekata koji su u obuhvaćeni BAPI pozivom, kao i ažurirati ove vrednosti. SOAP SOAP 6 je protokol namenjen razmeni struktuiranih informacija u decentralizovanom, distribuiranom okruženju. Oslanja se na XML i definiše radni okvir za razmenu poruka koji je nezavisan od jezika implementacije, kao i od transportnog protokola (može se koristiti npr. HTTP, HTTPS, SMTP, itd). [99] Najčešće je korišćen za implementaciju veb servisa. WSDL Web Services Description Language (WSDL) je jezik za formalnu specifikaciju mrežnih servisa [27]. Ovim jezikom se, u XML formatu, mogu zadati opisi pristupnih tačaka (endpoint) servisa, kao i poruka koji se njima razmenjuju. Jezik je nezavisan od formata poruka i mrežnih protokola koji se koriste za prenos, ali se najčešće koristi za opis SOAP servisa preko HTTP. Deo WSDL definicije servisa koji učestvuje u ovom integracionom scenariju prikazan je na listingu 7.5. <?xml v e r s i o n=" 1. 0 " e ncoding="utf 8"?> 2 <wsdl : d e f i n i t i o n s name=" SI_request_PSP_Portal " targetnamespace=" h t t p : / /www. pi i n f o r m a t i k. de / i o " 4 xmlns : r f c=" urn : sap com : document : sap : r f c : f u n c t i o n s " xmlns : p1=" h t t p : / /www. pi i n f o r m a t i k. de / i o " 6 xmlns : wsdl=" h t t p : / / schemas. xmlsoap. org / wsdl / "> <wsdl : documentation /> 8 <wsdl : types > <xsd : schema targetnamespace=" urn : sap com : document : sap : r f c : f u n c t i o n s " 10 xmlns=" urn : sap com : document : sap : r f c : f u n c t i o n s " xmlns : xsd=" h t t p : / /www. w3. org /2001/XMLSchema"> 12 <xsd : element name="bapi_project_getinfo"> <xsd : complextype> 6 U verziji 1.1 specifikacije, ime protokola je SOAP (Simple Object Access Protocol). U verziji 1.2, naziv protokola je SOAP i napominje se da više ne predstavlja skraćenicu.
7.2. SCENARIO 2: PORTAL ZA VOÐENJE PROJEKATA 91 14 <xsd : a l l > <xsd : element name="project_definition" minoccurs=" 0 "> 16 <xsd : simpletype> <xsd : r e s t r i c t i o n base=" xsd : s t r i n g "> 18 <xsd : maxlength v a l u e=" 24 " /> </xsd : r e s t r i c t i o n > 20 </xsd : simpletype> </xsd : element> 22 <xsd : element name="with_activities" minoccurs=" 0 "> <xsd : simpletype> 24 <xsd : r e s t r i c t i o n base=" xsd : s t r i n g "> <xsd : maxlength v a l u e=" 1 " /> 26 </xsd : r e s t r i c t i o n > </xsd : simpletype> 28 </xsd : element> <xsd : element name="with_milestones" minoccurs=" 0 "> 30 <xsd : simpletype> <xsd : r e s t r i c t i o n base=" xsd : s t r i n g "> 32 <xsd : maxlength v a l u e=" 1 " /> </xsd : r e s t r i c t i o n > 34 </xsd : simpletype> </xsd : element> 36 <xsd : element name="with_subtree" minoccurs=" 0 "> <xsd : simpletype> 38 <xsd : r e s t r i c t i o n base=" xsd : s t r i n g "> <xsd : maxlength v a l u e=" 1 " /> 40 </xsd : r e s t r i c t i o n > </xsd : simpletype> 42 </xsd : element> 44... 46 </xsd : a l l > </xsd : complextype> 48 </xsd : element>... Listing 7.5: Deo WSDL definicije veb servisa koji učestvuje u scenariju 2 7.2.3 Implementacija Implementacija integracionog rešenja za ovaj scenario počinje definisanjem servisa. Ovo je u TOS-u moguće učiniti uvozom WSDL datoteke ili ručno, kroz korisnički intefejs konektora. U oba slučaja, korisnik pored izvorne, tekstualne XML predstave, dobija grafičku predstavu pristupnih tačaka servisa, kao i formata poruka. Kako je WSDL datoteka bila na raspolaganju za ovaj scenario, ista je uvezena, a grafički prikaz formata zahteva BAPI_PROJECT_GETINFO prikazan je na slici 7.4. U okviru WSDL-a definiše se i adresa
92 7. EVALUACIJA i port na kojoj će servis očekivati zahteve.. Slika 7.4: Grafički prikaz dela WSDL definicije servisa Nakon definicije strukture veb servisa, prelazi se na definisanje procesa koji se odvija kada do ovog servisa dođe zahtev. U TOS, ovo se obavlja kreiranjem takozvanog job-a, koji može sadržati ulazne i izlazne komponente, kao i komponente procesore između njih. Proces ovog rešenja prikazan je na slici 7.5. Proces počinje komponentom tesbproviderrequest, koja služi za prijem zahteva ka veb servisu. Ukoliko servis primi ispravan zahtev, okida se događaj OnComponentOk. Ovaj događaj je doveden na komponentu tsapconnection, koja po prijemu događaja inicira konekciju ka SAP aplikaciji. Za konekciju se definiše: Server Type - Application Server ili Message Sever, Client - jedan SAP sistem može opsluživati više kompanija ili organizacionih jedinica koje na neki način predstavljaju zasebnu celinu (npr. teritorijalno), pa se svakoj dodeljuje trocifren Client kod; različitim kodovima mogu se odvojiti i razvojno, test i produkciono rešenje, koja se izvršavaju na istom sistemu, Userid - korisničko ime, Password - lozinka za pristup, Language - dvoznačni kod jezika sistema kom se pristupa (npr. EN za engleski), Host name - IP ili simbolička adresa za pristup sistemu i System number - broj instance u opsegu 00 do 99, koji se podešava prilikom instalacije SAP sistema.
7.2. SCENARIO 2: PORTAL ZA VOÐENJE PROJEKATA 93 Slika 7.5: Grafički prikaz TOS job-a koji povezuje veb servis i SAP Ukoliko tsapconnection komponenta uspešno ostvari konekciju sa SAP sistemom, okida događaj OnSubjobOk. Ovaj događaj je doveden na komponentu tsapinput, koja služi za dobavljanje podataka iz SAP sistema pozivanjem BAPI funkcije. Kada dobije signal da je konekcija uspešna, ova komponenta je podešena da poziva funkciju BAPI_PROJECT_GETINFO. Prilikom poziva, prosleđuje se parametar PROJECT_DEFINITION postavljen na vrednost I+O PROJEKTDEFINITION. Izlaz funkcije je SAP tabela pod nazivom E_WBS_ELEMENT_TABLE, koja sadrži podatke o projektima. U okviru komponente tsapinput definiše se struktura izlaznih parametara, uključujući strukturu ove tabele. Dijalog za zadavanje strukture tabele prikazan je na slici 7.6. Klikom na dugme u koloni Ontology Element ovog dijaloga, dobija se mogućnost anotiranja svake kolone tabele elementom ontologije. Moguće je pridružiti i više elemenata ontologije jednoj koloni tabele, koja u ranije uvedenoj terminologiji predstavlja jedan element ulaznog interfejsa. Komponenta tmap služi za rutiranje i transformaciju. U sklopu ove komponente može se definisati kako se proizvoljan broj ulaznih interfejsa mapira na proizvoljan broj izlaznih interfejsa. Ovo je komponenta koja je najviše modifikovana kako bi bio implementiran predstavljeni radni okvir. Dijalog ove komponente podeljen je na tri dela. U levom delu se zadaju ulazni interfejsi, u desnom izlazni, dok se u središnjem delu mogu definisati pomoćne promenljive i izrazi za transformaciju. Interfejsi mogu predstavljati i složene strukture i moguće je kroz njih iterirati. U slučaju scenarija koji trenutno obrađujemo, ulazni interfejs je tabela čiji svaki red predstavlja jedan projekat, a izlazni interfejs je XML struktura koja će biti prosleđena kao telo odgovora veb servisa i koja sadrži informacije o svim traženim projektima. Pregled svih koraka neophodnih za dobijanje automatskog mapiranja, kao i njegov rezultat u slučaju ovog scenarija, prikazani su na slici 7.7.
94 7. EVALUACIJA Slika 7.6: Definicija kolona tabele E_WBS_ELEMENT_TABLE i kontrola za anotiranje svake kolone ove tabele elementima ontologije
7.2. SCENARIO 2: PORTAL ZA VOÐENJE PROJEKATA 95 Slika 7.7: Koraci potrebni za dobijanje automatskog mapiranja sa rezultatima