УНИВЕРЗИТЕТ У БЕОГРАДУ ФАКУЛТЕТ ОРГАНИЗАЦИОНИХ НАУКА Слађана Р. Јанковић МОДЕЛ B2B ИНТЕГРАЦИЈЕ САОБРАЋАЈНИХ ПОСЛОВНИХ СИСТЕМА докторска дисертација Београд, 2012 UNIVERSITY OF BELGRADE FACULTY OF ORGANIZATIONAL SCIENCES Slađana R. Janković A MODEL FOR B2B INTEGRATION OF TRAFFIC SYSTEMS Doctoral Dissertation Belgrade, 2012. Ментор: Проф. др Божидар Раденковић Универзитет у Београду Факултет организационих наука Чланови комисије: Проф. др Маријана Деспотовић-Зракић Универзитет у Београду Факултет организационих наука Проф. др Милорад Станојевић Универзитет у Београду Саобраћајни факултет Датум одбране: ____________________ Модел B2B интеграције саобраћајних пословних система МОДЕЛ B2B ИНТЕГРАЦИЈЕ САОБРАЋАЈНИХ ПОСЛОВНИХ СИСТЕМА АПСТРАКТ Предмет ове дисертације је дефинисање методологије и модела интероперабилног електронског пословања саобраћајних пословних система базираног на њиховој B2B (Business to Business) интеграцији унутар cloud computing технолошког окружења. Истраживањe jе прилагођенo за примену код саобраћајних пословних субјеката у Србији. Саобраћајни и транспортни системи су хетерогени системи који у свом пословању деле информације. Неки од узрока неинтероперабилног електронског пословања налазе се у томе што саобраћајни пословни системи развијају, одржавају и ажурирају базе података за које су надлежни други саобраћајни пословни системи; у базама података које користе моделирају исте ентитете из реалног система, користећи различите методологије и алате; ажурирају сопствене базе података преузимањем података из база других саобраћајних пословних система; услед немогућности размене података на нивоу информационих система, преузимају податке ручно, што проузрокује кашњење у ажурирању података; одржавају и ажурирају читаве базе података за које нису надлежни, како би над њима повремено генерисали статистичке извештаје; доносе пословне одлуке о заједничким питањима на основу синтаксно и семантички некомпатибилних извештаја. У литератури се најчешће наводе четири типа B2B интеграције: интеграција информација, интеграција заснована на корисничком интерфејсу - порталу, интеграција пословних процеса и интеграција сервиса. У оквиру ове дисертације анализирају се постојећи и развијају нови модели B2B интеграције саобраћајних пословних система засновани на комбиновању сва четири набројана типа интеграције. Сервисно-оријентисана архитектура (СОА) саобраћајно- транспортних информационих система омогућава интероперабилност на нивоу апликација и на нивоу пословних процеса, док је интероперабилност на семантичком нивоу обезбеђена креирањем заједничке доменске онтологије и развојем заједничког модела података над доменском онтологијом. СОА и интеграција саобраћајно-транспортних апликација реализује се развојем и коришћењем WCF Data сервиса (Windows Communication Foundation Data Services) хостованих на cloud computing платформи. Модел размене информација и сервиса који је дат у овој дисертацији, заснован је на комбиновању три модела испоруке сервиса из облака: инфраструктура као сервис, платформа као сервис и софтвер као сервис. Развојем и хостовањем заједничке базе података у облаку користе се инфраструктура и платформа као сервиси, а развојем и хостовањем апликација у облаку користe се платформа и софтвер као сервиси. Имплементација предложеног модела састоји се од развоја Web портала и SQL Azure базе података у облаку. Портал корисницима нуди сродне саобраћајно-транспортне апликације као и информације из SQL Azure базе Модел B2B интеграције саобраћајних пословних система података. Постојеће апликације у саобраћајно-транспортним организацијама позивају WCF Data сервисе из облака. Применом предложеног решења нестала би потреба за ажурирањем и одржавањем сличних база података на серверима различитих организација. Самим тим смањила би се редунданса, а обезбедио интегритет података. Студија случаја која је развијена у оквиру ове дисертације има за циљ да демонстрира предложену методологију и примени предложени модел B2B интеграције на примеру организација из области безбедности у саобраћају. Организације које раде на подизању нивоа безбедности у саобраћају, морају да располажу подацима о саобраћајној и путној инфраструктури. Најкомплетнију базу података о путној инфраструктури поседује Јавно предузеће „Путеви Србије” (ЈППС). Министарство унутрашњих послова, да би имало увид у просторну расподелу саобраћајних незгода, мора да користи базу података о путној инфраструктури. „Железнице Србије” имају потребу за подацима о путној инфраструктури, како би подигле ниво безбедности саобраћаја на путно-пружним прелазима. Развојем и применом решења B2B интеграције према предложеном моделу поменутим организацијама омогућено је да деле и размењују податке и сервисе. Студија случаја реализована је на Windows Azure платформи, што омогућава коришћење ресурса по потреби и плаћање по употреби. Главна хипотеза која је развијена и доказана у оквиру докторске дисертације је да се применом предложеног модела B2B интеграције саобраћајних пословних система у cloud computing окружењу може реализовати семантички интероперабилно електронско пословање саобраћајних пословних система. Пројектовањем и имплементацијом решења B2B интеграције саобраћајних пословних система у домену безбедности у саобраћају, верификован је предложени модел B2B интеграције. Доказано је да креирање доменске онтологије и развој заједничког модела података над доменском онтологијом, обезбеђује семантичку интероперабилност. Експеримент спроведен на cloud computing платформи показао је да је предложени модел B2B интеграције информација и апликација у cloud computing окружењу ефикаснији у поређењу са познатим моделима B2B интеграције ван cloud computing окружења. Поређењем комплексности постојећих и предложеног решења и узимајући у обзир модел плаћања „према употреби” који нуди cloud computing технологија, закључено је да имплементација предложеног модела B2B интеграције саобраћајних пословних система у cloud computing окружењу може да смањи трошкове и повећа поузданост њиховог електронског пословања. Кључне речи: B2B интеграција, интероперабилност саобраћајних пословних система, технологија облака, СОА. Научна област: Информациони системи и технологије. Ужа научна област: Електронско пословање. Модел B2B интеграције саобраћајних пословних система A MODEL FOR B2B INTEGRATION OF TRAFFIC SYSTEMS ABSTRAKT The subject of this dissertation is to define a methodology and a model of interoperable e-business of the traffic business systems based on their B2B (Business to Business) integration in the cloud computing technology environment. The survey was adapted for use in transportation businesses in Serbia. Traffic and transportation systems are heterogeneous systems that share information in their operation. Some of the causes of non-interoperable e-business can be found in the fact that transportation business systems develop, maintain and update databases that are relevant for other traffic systems; in the databases that they use, the same entities are modeled from the real system, using different methodologies and tools; update own database by downloading information from the databases of other transportation business systems; due to the inability to exchange data at the level of information systems, they download the data manually, which causes a delay in updating the data; maintain and update the entire databases that are not relevant to them in order to occasionally generate statistical reports; making business decisions about common issues based on syntactically and semantically incompatible reports. The literature often describes four types of B2B integration: information integration, user interface-based integration – portal integration, business process integration and integration of services. In this dissertation we perform the analyzes the existing and development of the new models of B2B integration of traffic business systems based on combining the four listed types of integration. Service-oriented architecture (SOA) of the traffic and transport information systems provides interoperability at the application level and the level of business processes, while at the semantic level interoperability is provided by creating a common domain ontology and development of a common data model based on the domain ontology. SOA and integration of the traffic and transportation applications is implemented by development and use of WCF Data Services (Windows Communication Foundation Data Services) hosted on the cloud computing platform. Model for exchange of information and services that are proposed in this dissertation is based on combining the three models of service delivery from the cloud: Infrastructure- as-a-Service, Platform-as-a-service and Software-as-a-service. Development and hosting of a shared database in the cloud, the infrastructure and platform are using as a service, and developing and hosting applications in the cloud are using the platform and software as a service. Implementation of the proposed model consists of development of a Web portal and SQL Azure database in the cloud. The portal provides users with traffic and transportation related applications and informations from the SQL Azure database. Existing applications in the traffic and transportation organizations are addressing WCF Data services from the cloud. By applying the proposed solution, there will be no need for updating and maintaining related databases on the servers of different organizations. Consequently that would reduce the redundancy and ensure the data integrity. Модел B2B интеграције саобраћајних пословних система A case study that was developed in this thesis aims to demonstrate the proposed methodology and application of the proposed model of B2B integration on the example of organizations in the field of traffic safety. Organizations that work to raise traffic safety, must have data on traffic and road infrastructure. The most complete database on road infrastructure is owned by Public Enterprise "Roads of Serbia" (PERS). Ministry of Interior, to have insight into the spatial distribution of accidents, must use a database on road infrastructure. "Serbian Railways" have a need for information on road infrastructure, in order to raise the level of traffic safety on the railroad crossing. Development and implementation of B2B integration solutions to the model to above proposed organizations, enables them to share and exchange data and services. The case study was carried out on the Windows Azure platform, which enables the use of resources as needed and pay per use. The main hypothesis that was developed and proven in doctoral dissertation was that use of the proposed model of B2B integration of transport business systems in the cloud computing environment can be realize semantically interoperable e-business of traffic business systems. By the design and implementation of solutions of B2B integration of business transportation systems in the field of traffic safety, the proposed model of B2B integration is verified. It has been proven that creation of domain ontology and development of a common data model of the domain ontology provides semantic interoperability. The experiment conducted on the cloud computing platform showed that the proposed model of B2B information and application integration of cloud computing environment is more efficient compared with the known models of B2B integration outside the cloud computing environment. Comparing the complexity of existing and proposed solutions and taking into account the model of payment "per use" that is offered by the cloud computing technology, it was concluded that the implementation of the proposed model of B2B integration of transport systems in the commercial cloud computing environments can reduce costs and increase reliability of their e-business. Key words: B2B Integration, Interoperability of Traffic Systems, Cloud Computing, SOA. Scientific field: Information systems and technology. Narrow scientific field: Е-Business. Модел B2B интеграције саобраћајних пословних система Садражај 1. Увод ...................................................................................................... 1 1.1. Дефинисање предметa истраживања ................................................ 1 1.2. Циљеви истраживања ......................................................................... 2 1.3. Полазне хипотезе ................................................................................. 3 1.4. Методологија истраживања ............................................................... 3 1.5. Структура и организација рада......................................................... 4 2. Анализа постојећег стања и досадашњих истраживања на пољу интероперабилности .......................................................................... 5 2.1. Улога информационих технологија у саобраћају и транспорту ... 5 2.1.1. Информационо-комуникациона инфраструктура транспортних услуга ..................................................................................................... 6 2.1.2. Логистички информационо-комуникациони системи ......................... 7 2.1.3. Примери примене ИКТ у саобраћају и транспорту ............................. 9 2.2. Интероперабилност као истраживачки концепт .......................... 14 2.2.1. Појам и дефиниције............................................................................. 14 2.2.2. Нивои интероперабилности пословних система................................ 15 2.2.3. Тродимензионални радни оквир интероперабилности...................... 15 2.3. Анализа постојећих референтних модела и радних оквира интероперабилности .......................................................................... 17 2.3.1. LISI референтни модел интероперабилности ..................................... 18 2.3.2. ATHENA радни оквир интероперабилности ....................................... 19 2.3.3. INTEROP радни оквир интероперабилности...................................... 23 2.3.4. EIF радни оквир интероперабилности................................................ 24 2.4. Анализа постојећих стандарда, модела и решења на пољу B2B интеграције ......................................................................................... 25 2.4.1. Интеграција апликација - појам и дефиниције................................... 25 2.4.2. B2B интеграција - појам и дефиниције ............................................... 27 2.4.3. Типови B2B интеграције ..................................................................... 27 2.4.3.1. Интеграција информација................................................................... 28 2.4.3.2. Интеграција преко корисничког интерфејса ..................................... 29 2.4.3.3. Интеграција на бази сервиса............................................................... 30 2.4.3.4. Интеграција пословних процеса ........................................................ 33 2.4.4. Изазови код B2B интеграције.............................................................. 36 2.4.5. Најзначајнији XML стандарди у области B2B интеграције................ 37 2.4.6. ebXML................................................................................................... 39 2.4.7. RosettaNet ............................................................................................. 41 2.4.8. BizTalk Server ....................................................................................... 41 2.4.9. Windows Communication Foundation Framework ................................ 42 2.5. Семантичка интероперабилност ..................................................... 45 2.5.1. Појам и дефиниције............................................................................. 46 2.5.2. Семантичко моделирање ..................................................................... 47 Модел B2B интеграције саобраћајних пословних система 2.5.3. Онтологије ........................................................................................... 48 2.5.3.1. Појам и дефиниције............................................................................. 49 2.5.3.2. Улоге онтологија ................................................................................. 50 2.5.3.3. Врсте онтологија.................................................................................. 51 2.5.3.4. Постојеће методе креирања онтологија............................................. 52 2.5.3.5. Стандарди, језици и алати за креирање онтологија ......................... 53 2.5.4. Приступи семантичкој интероперабилности базирани на онтологијама ........................................................................................ 54 2.5.5. Модели семантичке интероперабилности .......................................... 58 2.6. Интероперабилност у саобраћају и транспорту ............................ 62 2.6.1. Задаци и циљеви интероперабилности саобраћајно-транспортних пословних система ............................................................................... 62 2.6.2. Законска регулатива Европске Уније која се односи на интероперабилност у саобраћају и транспорту .................................. 64 2.6.3. Структурна поставка интероперабилности у саобраћају................... 72 2.6.4. Интероперабилност логистичких информационо-комуникационих система ................................................................................................. 74 2.7. Преглед најзначајнијих стандарда и решења за реализацију интероперабилности у саобраћају и транспорту ........................... 75 3. Развој методологије и модела B2B интеграције саобраћајних пословних система ........................................................................... 83 3.1. Развој методологије B2B интеграције саобраћајних пословних система................................................................................................. 83 3.1.1. Идентификација категорија пословних субјеката који ће бити укључени у B2B интеграције ............................................................... 83 3.1.2. Анализа пословних релација у саобраћају и транспорту за које треба обезбедити B2B интеграцију ............................................................... 83 3.1.3. Дефинисање фаза развоја решења ...................................................... 85 3.1.4. Дефинисање захтева решења B2B интеграције .................................. 91 3.1.4.1. Оквири B2B интеграције саобраћајних пословних субјеката.......... 91 3.1.4.2. Хардвер и софтвер ............................................................................... 93 3.1.5. Инфраструктура решења..................................................................... 93 3.2. Развој модела B2B интеграције саобраћајних пословних система .............................................................................................................. 95 3.2.1. Анализа постојећих модела................................................................. 95 3.2.2. Структура предложеног модела B2B интеграције ............................. 96 3.2.3. Архитектура предложеног система B2B интеграције ........................ 98 3.2.4. Активности развоја система B2B интеграције ................................. 100 3.2.4.1. Анализа постојећих информационих система ................................ 100 3.2.4.2. Креирање локалних онтологија и доменске онтологије ................ 102 3.2.4.3. Развој сценарија B2B интеграције .................................................... 104 3.2.4.4. Развој механизама B2B интеграције ................................................ 106 3.2.4.5. Реализација система B2B интеграције ............................................. 109 3.2.5. Методе B2B интеграције саобраћајних пословних система ............ 110 3.2.5.1. Дељење информација ........................................................................ 111 3.2.5.2. Преузимање информација................................................................. 112 3.2.5.3. Интеграција информација................................................................. 114 Модел B2B интеграције саобраћајних пословних система 3.2.5.4. Интеграција апликација .................................................................... 116 3.2.5.5. Портална интеграција........................................................................ 117 3.3. Технолошко окружење за реализацију развијеног модела........ 118 3.3.1. Cloud computing технологија............................................................. 118 3.3.1.1. Софтвер као сервис ........................................................................... 119 3.3.1.2. Инфраструктура као сервис.............................................................. 120 3.3.1.3. Платформа као сервис....................................................................... 121 3.3.1.4. Недостаци cloud computing технологије .......................................... 122 3.3.1.5. Предности cloud computing технологије.......................................... 123 3.3.1.6. Врсте cloud computing технологије .................................................. 125 3.3.2. Microsoft Windows Azure платформа ................................................. 126 3.3.3. Интегрисано развојно окружење за развој cloud апликација........... 133 4. Реализација и примена предложеног модела ............................. 135 4.1. Спецификација и анализа захтева ................................................ 135 4.2. Постојећа решења............................................................................ 137 4.3. Развој и примена решења B2B интеграције према предложеном моделу ................................................................................................ 141 4.3.1. Развој онтологија ............................................................................... 143 4.3.2. Креирање заједничке базе података на cloud computing платформи154 4.3.3. Креирање Web портала на cloud computing платформи ................... 159 4.3.4. Развој WCF Data сервиса .................................................................. 163 4.3.5. Интеграција апликација .................................................................... 166 4.4. Анализа постигнутих резултата .................................................... 175 4.4.1. Аналитичка анализа .......................................................................... 176 4.4.2. Симулациона анализа........................................................................ 179 4.4.3. Имплементациона анализа ................................................................ 180 4.4.4. Евалуација предложеног модела B2B интеграције саобраћајних пословних система ............................................................................. 181 5. Научни и стручни доприноси ...................................................... 183 6. Будућа истраживања .................................................................... 185 7. Закључак ........................................................................................ 186 8. Литература ..................................................................................... 188 9. Списак слика.................................................................................. 201 10. Списак табела .............................................................................. 205 11. Прилози......................................................................................... 206 12. Биографија аутора ...................................................................... 210 Модел B2B интеграције саобраћајних пословних система 1 1. Увод Појам интероперабилности, у општем случају, односи се на способност два система да међусобно размењују информације, али и да користе размењене информације. Интероперабилност није производ, то је својство система. Интероперабилност у контексту пословних система и пословних апликација дефинише се као способност система или производа да ради неометано са другим системом или производом без потребе за специјалним напорима купца или корисника. Апликације које су изграђене независно (у различито време, од различитих тимова, коришћењем различитих технологија), чак унутар истог предузећа, имају проблеме у размени података. Проблем је исте природе, али значајно увећан, ако се очекује интероперабилност активности које заједнички реализује неколико различитих организација. 1.1. Дефинисање предметa истраживања Предмет ове дисертације је дефинисање методологије интероперабилног електронског пословања саобраћајних пословних система базиране на њиховој Business-to-business (B2B) интеграцији унутар cloud computing технолошког окружења. Истраживања ће бити прилагођена за примену код саобраћајних пословних субјеката у Србији. Саобраћајни и транспортни системи су хетерогени системи који у свом пословању деле информације. Стога је неопходно постићи интероперабилност њихових информационих система. Неки од узрока неинтероперабилног електронског пословања налазе се у томе што саобраћајни пословни системи: • развијају, одржавају и ажурирају базе података за које су надлежни други саобраћајни пословни системи; • у базама података које користе моделирају исте ентитете из реалног система, користећи различите методологије и алате; • ажурирају сопствене базе података преузимањем података из база других саобраћајних пословних система. То проузрокује потребу за додатном обрадом преузетих података; • услед немогућности размене података на нивоу информационих система, преузимају податке ручно, што проузрокује кашњење у ажурирању података; • одржавају и ажурирају читаве базе података за које нису надлежни, како би над њима само повремено генерисали потребне статистичке извештаје; • над сличним базама података развијају апликације у којима је имплементирана различита пословна логика. Доносе пословне одлуке о заједничким питањима на основу синтаксно и семантички некомпатибилних извештаја. У литератури се најчешће наводе четири типа B2B интеграције: интеграција информација, интеграција заснована на корисничком интерфејсу - порталу, интеграција пословних процеса и интеграција сервиса. У оквиру ове дисертације анализираће се модели B2B интеграције саобраћајних пословних система Модел B2B интеграције саобраћајних пословних система 2 засновани на комбиновању сва четири набројана типа интеграције. Сервисно оријентисана архитектура (СОА) саобраћајно-транспортних информационих система требало би да омогући интероперабилност на нивоу апликација и на нивоу пословних процеса. Развој и коришћење доменске онтологије у развоју заједничког информационог модела, омогућиће интероперабилност и на семантичком нивоу. Изучаваће се могућности примене WCF Data сервиса (Windows Communication Foundation Data Services) у реализацији интеграције саобраћајно-транспортних апликација. Модел интеграције информација и сервиса, који ће бити предложен у овој дисертацији, заснован је на комбиновању три модела испоруке сервиса из облака: инфраструктура као сервис, платформа као сервис и софтвер као сервис. Развојем и хостовањем заједничке базе података у облаку користиће се инфраструктура и платформа као сервиси, а развојем и хостовањем апликација у облаку користиће се платформа и софтвер као сервиси. Имплементација предложеног модела биће базирана на Web порталу и SQL Azure бази података, хостованим унутар облакa. Портал ће корисницима са правом приступа обезбедити сродне саобраћајно- транспортне апликације као и информације из SQL Azure базе података. Постојеће апликације у саобраћајно-транспортним организацијама са правом приступа такође ће позивати појединачне WCF Data сервисе из облака. Плаћање услуга биће сразмерно њиховом коришћењу. Нестаће потреба за ажурирањем и одржавањем сличних база података на серверима различитих организација. Самим тим смањиће се редунданса, а обезбедиће се интегритет података. Саобраћајни пословни системи плаћаће само за оне ресурсе из облака које користе и колико користе. Студија случаја у оквиру ове дисертације има за циљ да демонстрира предложену методологију и модел B2B интеграције, на примеру организација из области безбедности у саобраћају. Материја која ће се обрађивати у овој дисертацији обухвата: • дефинисање модела B2B интеграције саобраћајних пословних система заснованог на комбиновању: интеграције информација, интеграције на бази портала и интеграције пословних процеса, унутар cloud computing технолошког окружења; • истраживање могућности примене предложеног модела интеграције за реализацију семантички интероперабилног електронског пословања саобраћајних пословних система; • дефинисање метода за имплементацију предложеног модела B2B интеграције; • реализација B2B интеграције саобраћајних пословних система на основу предложених метода и евалуација постигнутих резултата. 1.2. Циљеви истраживања Примарни циљ овог истраживања је дефинисање методологије интероперабилног електронског пословања саобраћајних пословних система. Овај циљ остварује се Модел B2B интеграције саобраћајних пословних система 3 развојем модела B2B интеграцијe саобраћајних пословних система у cloud computing технолошком окружењу. У том смислу, циљ овог рада обухвата: • дефинисање узрока неинтероперабилног е-пословања саобраћајних пословних система; • дефинисање методологије за постизање интероперабилног електронског пословања саобраћајних пословних система базиране на B2B интеграцији саобраћајних пословних система у cloud computing технолошком окружењу; • дефинисање модела интеграције информација и апликација саобраћајних пословних система у cloud computing технолошком окружењу; • развој модела B2B интеграције саобраћајних пословних система базираног на предложеним моделима интеграције информација и апликација у cloud computing окружењу; • имплементацију предложеног модела B2B интеграције саобраћајних пословних система у cloud computing технолошком окружењу; • евалуацију креираног модела кроз реализацију и тестирање заједничке базе података, саобраћајно-транспортних сервиса и процеса хостованих у облаку; • реализовање семантички интероперабилног електронског пословања саобраћајних пословних система применом предложеног модела B2B интеграције. 1.3. Полазне хипотезе Х1: Применом предложеног модела B2B интеграције саобраћајних пословних система у cloud computing окружењу може да се реализује семантички интероперабилно електронско пословање саобраћајних пословних система. Х2: Модел B2B интеграције саобраћајних пословних система који је заснован на интеграцији информација и апликација у cloud computing окружењу ефикаснији је у поређењу са познатим моделима B2B интеграције ван cloud computing окружења. Х3: Имплементација предложеног модела B2B интеграције саобраћајних пословних система у cloud computing окружењу може да смањи трошкове и повећа поузданост њиховог електронског пословања. 1.4. Методологија истраживања Током израде овог рада, од опште научних метода користиће се: моделирање, аналитичко-дедуктивна метода, компаративна метода, метода емпиријског истраживања, мерење и метод научног посматрања и експеримента. Моделирање ће се користи приликом израде модела сервисно-оријентисане ИТ инфраструктуре, као и модела семантичке B2B интеграције саобраћајних пословних система. Аналитичко-дедуктивна, компаративна и метода емпиријског Модел B2B интеграције саобраћајних пословних система 4 истраживања користиће се приликом анализе постојећих решења B2B интеграције саобраћајних пословних система, као и саобраћајних сервиса током експеримента. У експерименталном делу посматраће се перформансе B2B интеграције саобраћајних пословних система када се она одвија помоћу ИТ инфраструктуре засноване на cloud computing платформи. Добијени резултати експеримента треба да потврде генералну хипотезу о остваривању интероперабилности саобраћајних пословних система применом предложеног модела B2B интеграције. Резултати истраживања биће презентовани текстуално, табеларно и графички. Истраживање ће бити интердисциплинарно, јер укључује научне дисциплине методологију, информатику, статистику и друге. Методе логичког објашњења које ће се користити: метода анализе и синтезе, индуктивно и дедуктивно закључивање. 1.5. Структура и организација рада Рад је организован према фазама истраживања у следеће целине: • анализа постојећег стања и досадашњих истраживања на пољу интероперабилности; • развој методологије B2B интеграције саобраћајних пословних система; • развој модела B2B интеграције саобраћајних пословних система; • анализа могућности cloud computing технолошког окружења за реализацију развијеног модела B2B интеграције саобраћајних пословних система; • пројектовање и имплементација примера решења B2B интеграције саобраћајних пословних система на бази примене предложеног модела; • анализа и евалуација предложеног модела B2B интеграције саобраћајних пословних система. Модел B2B интеграције саобраћајних пословних система 5 2. Анализа постојећег стања и досадашњих истраживања на пољу интероперабилности Организације заступљене у саобраћају и транспорту заснивају своје пословање на брзом одлучивању, ефикасном спровођењу одлука са беспрекорном координацијом, ефикасној комуникацији и дељењу информација. Информације се деле у бројним службама и секторима, као што су: регулисање саобраћаја, контрола, безбедност, одржавање, управљање, итд. Интероперабилност саобраћајних система пружа могућност саобраћајним пословним субјектима да међусобно размењују информације и користе софтверске сервисе другог саобраћајног субјекта, у дистрибуираном и хетерогеном окружењу. Управљање транспортним системима (енгл. Transportation Systems Management, TSM) обухвата стратегије дизајниране да повећају проток саобраћаја, а повећају ефикасност, безбедност и капацитет постојећих транспортних система [120]. Многе TSM стратегије спадају у широку категорију решења базираних на технологији интелигентних транспортних система (енгл. Intelligent Transportation Systems, ITS). У оквиру ITS врши се прикупљање, обрада и пренос података у транспортној мрежи - за оператере и кориснике. Транспортни системи су сложени системи који захтевају значајан обим података за потребе праћења, надгледања, управљања, одржавања и унапређења сопственог функционисања. Они захтевају и развој модела кооперације који би требало да олакшају сарадњу различитих агенција које управљају овим системима [183]. Ефикасност кооперације транспортних система зависи од степена интероперабилности њихових информационих система. Због тога се велики број истраживања у области саобраћаја и транспорта бави развијањем модела интероперабилности саобраћајно-транспортних информационих система. 2.1. Улога информационих технологија у саобраћају и транспорту Најзначајнија промена која се догодила у области саобраћаја и транспорта је то што су некада комуникације зависиле од транспорта, а данас транспорт зависи од комуникационих и информационих технологија [104]. Истраживања примене информационо-комуникационих технологија на пољу саобраћаја и транспорта обухватају: управљање саобраћајем, информисање и пријем захтева од корисника транспортних услуга и управљање транспортним системима [69]. Апликације које се користе у путничком и теретном саобраћају могу се поделити на две категорије. Прву категорију чине Web апликације, које корисницима транспортних система омогућавају комфоран приступ сервисима (претраживање понуда, резервисање и куповина карата, наручивање теретног превоза). Другу категорију чини скроман број Web и Windows транспортних управљачких система који су обично део појединачних логистичких решења [98]. За обе категорије апликација карактеристично је да не користе информације којима располажу други транспортни системи. Модел B2B интеграције саобраћајних пословних система 6 2.1.1. Информационо-комуникациона инфраструктура транспортних услуга Под транспортним услугама, у општем случају, подразумевају се активности које су у вези са премештањем људи и робе, као и пратеће делатности: паковање, маркирање, кодирање, формирање јединичних транспортних садржаја, контејнеризација, итд [49]. Транспортне садржаје које је потребно преместити са једне локације на другу можемо поделити на: материјалне и енергетске садржаје, знање и информационе садржаје, вредносне и финансијске садржаје. Традиционални провајдери транспортних услуга преносе материјални (физички опипљив) транспортни садржај и могу се сврстати у три главне категорије: провајдери услуга експресне испоруке и/или поштанских услуга, провајдери урбаних транспортних услуга или урбаних курирских услуга, и провајдери транспортних услуга великог обима, сложеног портфолиа и великог реона покривања. Инфраструктура провајдера транспортних услуга може се посматрати као систем елемената који су у директној вези у процесу реализације транспортне услуге и оних који олакшавају реализацију ових услуга, односно који утичу на повећање квалитета транспортне услуге и нивоа испуњења очекивања корисника. Заједно са развојним тенденцијама у другим пословним областима и у сектору транспортних услуга долази до повећања броја и комплексности захтева корисника. Инфраструктура информационо-комуникационих технологија (ИКТ) дефинисана је као резултат динамичке интеракције технологије и људи, а састоји се од међусобно повезаних хардверских и софтверских компонената које омогућавају њено управљање, одржавање и контролу. Повезивањем ових компоненти ствара се одговарајућа мрежна структура која омогућава интрапровајдерску комуникацију и размену информација. Ова инфраструктура користи заједничке стандарде за отворено повезивање са појединачним специјализованим решењима. Она подржава употребу у различите сврхе и користи се у различитим модалитетима и од стране различитих корисника, уколико је то потребно. Коришћењем ИКТ провајдери транспортних услуга могу да смање притисак повремених захтева од корисника, али и прекомерно резервисање ресурса које је повезано са лошим предвиђањем потражње за транспортним услугама. Да би унапредили процес реализације транспортне услуге провајдери морају сврсисходно да примене одговарајуће ИКТ са циљем унапређивања процесних и организационих перформанси, смањења застоја и негативних утицаја окружења, повећања сигурности транспортног садржаја, као и повећања продуктивности својих ресурса. Портфолио транспортних услуга представља колекцију услуга које су дефинисане од стране реализатора, а често се представља и као мени у којем корисници бирају услуге и/или ресурсе реализатора које желе да користе. С обзиром на количину доступних транспортних услуга, а у циљу тачног одређивања трошкова повезаних са употребом ресурса, захтева се обимније управљање захтевима корисника и интензивније ажурирање релевантних информација. Активности управљања процесима портфолиа услуга захтевају да информационо-комуникациона инфраструктура (ИКИ) буде интероперабилна са просторно-информационом инфраструктуром (ПИИ) и интегрисана у системе електронског пословања (енгл. Модел B2B интеграције саобраћајних пословних система 7 e-business) и системе електронског пословања у јавној управи (енгл. e- government). Зато је потребно повезати све укљученe субјекте и процесе у јединствену виртуелну заједницу, и тако повећати степен развијености ИКИ и ПИИ у посматраној географској области. Усавршавањем ИКИ и ПИИ успоставља се квалитетна и перманентна комуникација између свих елемената портфолиа услуга, као и праћење свих ангажованих ресурса у реалном времену. На тај начин повећава се интегрисаност свих транспортних функција и свих реализатора услуга у одређеној географској области, што доводи и до потпунијег испуњавања жеља корисника. Истовремено, то омогућава и персонализацију услуга, која је неопходна за испуњавање индивидуалних захтева корисника. У идеалном случају, портфолио је уско повезан са управљањем процесом реализације услуге. Проблеми који се јављају у дизајну и управљању портфолиом транспортних услуга су: • мали степен симетричне комуникације између заинтересованих страна што се огледа у недостатку конверзације и консултација; • велики нагласак на алатима, уместо на способностима провајдера или пословним потребама (више „шта” него „зашто”); • слаб дизајн појединачних услуга – недовољно коришћење детаља и мали степен задовољења потреба за новим услугама; • често задржавање на идејама – што производи недостатак практичне имплементације нових технологија и методологија; • велики број различитих услуга код сваког реализатора – што доводи до „прекомерног” управљања реализацијом услуга. Портфолио транспортних услуга детерминише кључне сегменте тржишта за пословне операције реализатора услуга. Он упућује на спектар потенцијалних корисника и њихових захтева, а његов обим одређује типове услуга које су понуђене од стране реализатора. Један од највећих проблема је детерминисање начина на који захтеви портфолиа треба да се развијају током времена. 2.1.2. Логистички информационо-комуникациони системи Код саобраћајно-транспортних система, информационо-комуникационе технологије осигуравају да се различите планско-оперативне процедуре и логистичке перформансе интегришу у парадигму целине човек – организација – технологија – окружење, а у контексту максимизирања могућности за размену и вишеструку употребу одговарајућих добара и информација, и других пословних ресурса на брз, ефикасан и безбедан начин. Ради тога се интероперабилност комуникационих, логистичких и информационих система мора осигурати на три равни - техничкој (норме и стандарди за повезивање појединих комуникационих, логистичких и информационих система), семантичкој (једнозначност података, порука, одлука, налога и задатака) и процесној равни (дефинисање заједничких циљева, моделирање комуникационих, информационих и логистичких процеса и остваривање сарадње између различитих учесника) [85]. Саобраћајни и Модел B2B интеграције саобраћајних пословних система 8 транспортни системи могу се посматрати у функцији логистичких система, тј. морају да задовоље ригорозне захтеве у погледу квалитета, флексибилности, брзине и поузданости у достави робе, транспотру људи и преносу информација у захтеваном времену. Због тога је неопходан интероперабилни процес, који би објединио хетерогене техничке системе (саобраћајни, транспортни, комуникациони, информациони и логистички) у један целовити систем. Свака саобраћајно-транспортна (СТ) компанија, у интервенцијама које захтевају свакодневни непредвидиви догађаји и пратеће активности, доминантно се ослања на сопствене, најчешће и самосталне комуникационе системе. Самостални логистички информационо-комуникациони системи (ЛИКС) су често некомпатибилни са ЛИКС других служби унутар истог „подручија деловања”, док су већим делом ефективни за појединачне службе (компаније). Истовремено, у многим СТ компанијама, је опрема која се користи за размену информација, логистичких услуга, као и радио-комуникациона инфраструктура веома застарела, од 20 па и до 40 година. Такође, у различитим СТ службама (у оквиру исте компаније, па и у различитим СТ компанијама) у употреби су различити технички системи за пренос информација, који онемогућавају успешну комуникацију међу њима. Недостатак интероперабилности постојећих техничких система доводи до појављивања значајних проблема у интра и интер-комуникацији СТ компанија. Код неких СТ компанија су уочени различити оперативни системи (Windows, Linux, Macintoch, Unix) који не могу да се интегришу у кооперативне процесе СТ служби. Често је и проблем код комуникационих система, нпр., пријем FM сигнала у AM пријемнику. С друге стране, ако се сагледа информационо- комуникациони систем саобраћаја и транспорта, новији дигитални радио- комуникациони системи неће комуницирати, чак ни на истим радио фреквенцијама због различитих пратећих софтвера. Постојећа ограничења се једино могу отклонити увођењем јединствених стандарда за технологију и опрему код ЛИКС-а, а развој тих стандарда мора укључити кориснички input и подржати развој интероперабилних техничких система. Унапређење застареле опреме применљиве у СТ системима захтева знатна финансијска улагања. На том пољу јављају се проблеми проузроковани различитим финансијским приоритетима и различитим потребама транспортних заједница и органа власти. Један од проблема је и ограничено и раздвојено планирање, а без адекватног планирања, време и новац могу бити погрешно инвестирани, а крајњи резултат може бити разочаравајући. Компаније, институције и остали нивои деловања у саобраћају и транспорту штедљиво располажу финансијским средствима, што за последицу има одбијање партнерства и лидерства у развоју њихове интероперабилности. СТ компаније по природи својих искустава, нерадо препуштају контролу и управљање својим ЛИКС-ом, па људски фактор има пресудан утицај на успостављање интероперабилности ЛИКС-а. Међутим, интероперабилност захтева координацију, кооперацију и наглашавање важности подељеног управљања, контроле, стратегије и процедура. Модел B2B интеграције саобраћајних пословних система 9 Сви логистички процеси који су аутоматизовани и оснажени информационо- комуникационом инфраструктуром налазе се у домену е-логистике. Е-логистику можемо описати као отворену, неутралну, сигурну и поуздану електронску инфраструктуру која кроз додавање и дељење вредности повезује учеснике у логистичким процесима помоћу стандардизованих електронских пословних порука, а у циљу остваривања ефикаснијих услуга трговине и логистике у СТ компанијама. Субјекти ЛИКС-а заинтересовани су само за приступ, па интерфејс који они виде треба да буде концизан и логичан. Њима није битно које компаније или организације су укључене, него коју функционалност они додају услугама (и за коју цену). „Ко” и „Где” је потпуно небитно, све док је логичка структура у траженим усугама недирнута. У ствари, структура је фактор који одређује како е- логистика мора да буде организована. У најбољем случају, то би требало да буде виртуелна организација. Нови процесни ланац требало би да буде формиран за готово сваку нову тражену услугу, уз могућност измене када је то потребно. Ланац би требало да буде потпун. Правилна реализација је децентрализованог типа, а сарадња са учесницима, који су мање или више независни, дистрибуирана широм света, путем логистичке мреже, и доступна путем Интернета. Дигитално повезивање из области логистике прошириће се и на базе података јавног сектора, као што су: управљање транспортом, државна безбедност, итд. [78]. 2.1.3. Примери примене ИКТ у саобраћају и транспорту Компјутерска технологија доживела је готово несхватљиву трансформацију, аналогну еволуцији Морзеове азбуке у e-mail. Иако се циљеви и предмет интересовања саобраћајне заједнице нису значајно променили, технолошки изазови у сфери саобраћаја и транспорта већи су него икада раније. Могућности које нуди управљање подацима знатно су побољшале управљање свим другим ресурсима [175]. Међутим, поред позитивних ефеката, постоје изазови у имплементацији, подршци и финансирању нових технологија у свету саобраћаја и транспорта. Области у којима се данас највише ради на проналажењу одговора на технолошке изазове су: • примена информационих система и технологија у транспорту; • примена система корисничких интерфејса за управљање и дељење података; • коришћење Web технологија (интернет, интранет и екстранет); • постављање приоритета на програме истраживања и развоја; • подстицање коришћења заједничких информационих система, стандарда и семантике у области транспорта; • омогућавање трансфера технологије између транспортних организација и продаваца; Модел B2B интеграције саобраћајних пословних система 10 • процена утицаја компјутерских технологија на транспортне организације, укључујући и добитке у продуктивности; • транспортне апликације; • размена података и интероперабилност. Када су у питању Web технологије у транспорту, акценат је на примени real time технологија, као што су „zero-latency” и „push” технологије. Термин „push” описује стил комуникације базиран на Интернету, где је захтев за дату трансакцију инициран од стране онога ко је објавио сервис или централног сервера. Она је у супротности у односу на „pull” технологију, где захтев за пренос информација иницира пријемник или клијент. У [165] аутори су развили Web апликацију за подршку испоруке робе друмом. Апликација користи „push” стил комуникације, тако што путем e-maila-a, у реалном времену, обавештава корисника о предвиђеном времену испоруке робе. Транспортна заједница требало би што више да примењује интернет, интранет и екстранет у пројектовању, изградњи и раду саобраћајних субјеката, посебно у следећим областима: • размена података и комуникација преко Интернета или екстранета; • интеграција транспортних извора информација кроз платформе; • динамичко генерисање и презентација транспортних информација на Интернету; • ширење информација и управљање коришћењем корпоративног интранета; • интеграција транспортних база података уз помоћ Интернета, интранета и екстранета. Остале области примене информационих технологија у транспортним заједницама укључују: • сигурност софтвера и хардвера, • мобилне комуникације, • аутоматска идентификација опреме, • електронска размена података, • глобални позициони системи (енгл. Global Positioning Systems, GPS), • географски информациони системи (ГИС), • визуализација и анимација, • електронски пренос средстава, • препознавање гласа, • софистицирано бар-кодирање, • земаљско праћење авиона, Модел B2B интеграције саобраћајних пословних система 11 • земаљски надзор и праћење сателита, • рачунарство великих димензија (енгл. large-scale computing), • дистрибуиране и клијент-сервер архитектуре и • напредна анализа и моделирање рачунарства. Важно је да се развију стандардизоване методе за cost-benefit анализу имплементације информационих технологија у транспортним агенцијама. Како софтвер постаје интегрални део транспортних система, намеће се питање безбедности софтвера. Треба имати на уму да је безбедност софтвера шири појам од сигурности. Поставља се питање: да ли је софтвер безбедан уколико се пређу сигурносне границе? Чак ако и не дође до нарушавања сигурности софтвера, софтвер може да откаже због грешке у програмском коду, или отказа хардвера или неког другог интерног проблема. Важно је бити сигуран да и у случају отказа софтвера у транспортном систему неће доћи до повређивања људи или губитака људских живота. Управљање, складиштење и испоручивање транспортних података требало би да се врши на јединствен начин, без обзира на врсту података. Размена идеја и искустава важна је за унапређење рада транспортних субјеката. Добре идеје и искуства могу се разменити публиковањем на конференцијама и у часописима. Већина идеја и предлога решења настаје као последица анализе реалних транспортних података. Ти транспортни подаци ретко су доступни, а потребно је уложити велике напоре у прикупљању истих. Чак и када би истраживачи одлучили да своје податке учине доступним другим истраживачима, или ширем аудиторијуму, тренутно не постоји неки стандардизован или устаљени начин за објављивање транспортних података. Прикупљање података је скуп процес и ако би подаци били доступни, тај посао не би морали да понављају различити истраживачки тимови. Преузимањем готових података уштедели би и новац и време. Саобраћајна заједница треба да подстиче своје чланове на активности које се тичу размене и дељења информација, као што су: • дефинисање података који су корисни са аспекта: планирања, пројектовања, реализације, организације, управљања и безбедности саобраћаја и транспорта; • дефинисање формата и стандарда за објављивање података; • дефинисање стандарда за дељење и размену података. Неке од најзначајнијих области примене информационих технологија у саобраћају и транспорту су: • интелигентна возила; • системи интелигентних аутопутева (енгл. Inteligent Vechile Highway System, IVHS) • аутоматизација возила и аутопутева; • системи за упозоравање и избегавање судара; Модел B2B интеграције саобраћајних пословних система 12 • дистрибуирање информација. Доношење одлука у транспортној индустрији захтева приступ поузданим информацијама и статистичким подацима о транспортном систему, као и подацима о животној средини и главним утицајним факторима [8]. Према [50] реализација on-line система за подршку одлучивању захтева развој иновативне Web портал инфраструктуре са уграђеним интелигентним компонентама. Један од најзначајнијих задатака урбаних транспортних система је проблем рутирања улица (енгл. Street Routing Problem). На решавање овог задатка утиче постојање великог броја логистичких ланаца. Да би се планирање рута различитих логистичких ланаца обављало синхронизовано, мора постојати размена информација између њихових информационих система. Размена информација ручно, путем телефонске комуникације или е-mail-а, није довољно ефикасан начин када су у питању логистички ланци [114]. Они се динамички морају прилагођавати честим променама у окружењу, а свака промена мора се регистровати аутоматски. Интероперабилни информациони системи ових сложених пословних система омогућиће ажурирање информације на једном месту и добијање актуелних, ажурних информација тамо где су потребне. Интероперабилни информациони системи представљаће на тај начин ефикасне системе за подршку одлучивању. Истраживања у области безбедности саобраћаја указују на то да се виши ниво безбедности у саобраћају не може постићи без кооперације аутономних саобраћајно-транспортних система. Као методе кооперације наводе се: дистрибуирани информациони системи, Web кориснички интерфејс, интегрисане базе података доступне на Интернету, ефикасно извештавање, администрирање и заштита података, скалабилност ресурса, комуникација између корисника и стварање виртуелних професионалних удружења [135]. Сарадња саобраћајних и транспортних система мора бити заснована на аутоматској размени података [102]. У циљу подизања квалитета сарадње саобраћајних и транспортних система дошло се до решења познатог под називом кооперативни транспортни системи (енгл. Cooperative Transport Systems, CTS). У [156] дефинисани су услови које морају испуњавати кооперативни транспортни системи. Један од услова је компатибилност и конзистентност информација које се испоручују крајњим корисницима путем различитих медија. Сваки крајњи корисник мора бити у могућности да прими исту информацију путем различитих медија. Овај услов може се испунити једино ако кооперативни транспортни системи користе интероперабилне информационе системе. Примена напредних информатичких технологија кључна је у терминалима где се сусреће више видова транспорта (мултимодални транспорт). У [9] истиче се да је у таквим терминалима неопходно успостављање једног центра за дистрибуцију информација. Окосница таквог центра мора бити информациони систем који је интероперабилан са информационим системима свих видова транспорта. Да би се реализовали ефикасни интермодални транспортни ланци мора се остварити висок степен координације транспортних система (ТС). Координација ТС условљена је интелигентном разменом и коришћењем информација [160]. Модел B2B интеграције саобраћајних пословних система 13 Функционисање саобраћаја у значајној мери зависи од одржавања и управљања саобраћајном инфраструктуром. Да би одржавање инфраструктуре било сврсисходно и ефикасно, предлаже се коришћење система за подршку одлучивању [47]. С обзиром на то да је одржавање саобраћајне инфраструктуре увек у надлежности више организација, рад система за подршку одлучивању мора бити базиран на интероперабилним информационим системима тих организација. Значајан број истраживања у области саобраћаја и транспорта заснован је на развоју симулационих модела и анализи резултата симулације. У [111] предложена је и разрађена идеја о третирању радника извршних служби железница као елемената техничких система и коришћењу теорије обнављања за прогнозирање броја ванредних догађаја изазваних људским фактором. Приказан је аналитички модел и наведена ограничења за његову примену. Развијен је симулациони модел и дати су услови за његову примену. Симулације су веома значајна област примене ИКТ у саобраћају и транспорту. Једно од најважнијих питања савремене технологије у железничком саобраћају је оптимизација превозног процеса, чији је основни задатак оптимизација организације колских токова, односно план формирања теретних возова. Железнички теретни саобраћај карактеришу изразите промене интензитета токова кола, превозних путева и мреже ранжирног система. Поред избора оптималне варијанте плана формирања теретних возова (ОВПФТВ) при изради реда вожње, треба свакодневно бирати ОВПФТВ при оперативном управљању, јер се токови кола дневно мењају. У [169, 170] дефинисан је модел и развијен софтвер за избор ОВПФТВ, који се може користити при изради новог реда вожње и свакодневном оперативном управљању. Резултати примене овог софтвера су: минимизирање задржавања теретних кола у ранжирном систему, а посебно страних кола на мрежи, краће време превоза робе и већи квалитет превозне услуге. Windows апликација која се користи као подршка у избору оптималне варијанте плана формирања теретних возова, представља још један пример примене ИКТ у саобраћају и транспорту. Географски информациони системи (енгл. Geographical Information Systems, GIS) у саобраћају и транспорту морају да обезбеде: систем за управљање подацима, интероперабилност података, рад у реалном времену, рад са великим скуповима података, дистрибуирану обраду података (уз помоћ Web сервиса) [17]. У [33] аутори истичу да ГИС нису компатибилни са постојећим транспортним системима. Недостатак компатибилности пре свега је проузрокован недостатком интероперабилности између поменутих система. Истраживања примене cloud computing технологије у саобраћају и транспорту још увек су у зачетку. У [63] анализирају се могућности примене cloud computing технологије у друмском саобраћају. У [103, 106] приказани су примери cloud computing решења у друмском саобраћају, а у [181] пример cloud computing решења у железничком саобраћају. Модел B2B интеграције саобраћајних пословних система 14 2.2. Интероперабилност као истраживачки концепт Развој интероперабилности односи се на развијање знања и решења за отклањање некомпатибилности [26]. Многи истраживачи сматрају да је интероперабилност данас једна од највећих брига пословних система [119]. Три главне теме истраживања на пољу интероперабилности су: Enterprise modelling (ЕМ), архитектуре и платформе, онтологије [28]. Пројекат Unified Enterprise Modelling Language (UEML, IST-2001-34229) предлаже јединствен приступ који се састоји у размени модела пословних система између ЕМ алата. 2.2.1. Појам и дефиниције Стандардни компјутерски речник IEEE (Institute of Electrical and Electronics Engineers) дефинише интероперабилност као „способност два или више система или компоненти да размене информације и да користе размењене информације” [81]. Интероперабилност аутоматски омогућава неопходну сарадњу између привреде, компанија и производа [55]. Интероперабилност није производ, то је карактеристика система. Интероперабилност у контексту пословних система и пословних апликација дефинише се као способност система или производа да ради неометано са другим системом или производом без потребе за специјалним напорима купца или корисника. Могућност интеракције и размене информација интерно, као и са спољним организацијама, кључна је претпоставка у савременим пословним системима. То је кључна претпоставка за ефикаснију и економичнију производњу роба и пружање услуга. Интероперабилност система је интересна свера која расте, због тога што континуирано расте потреба за интеграцијом нових система који су у развоју, посебно у контексту мрежног пословања и електронског пословања у јавној управи. Пословне апликације и софтверски системи имају потребу да буду интероперабилни како би неометано пословали преко граница организација. Многа истраживања анализирају захтеве који морају бити испуњени да би била остварена интероперабилност [31]. Интероперабилност пословних система мора бити постигнута на техничком, семантичком и организационом нивоу [166]. Технички аспекти интероперабилности предузећа обезбеђују комуникацију и размену у смислу протокола комуникације, размене података и слања порука између апликација. Семантичка интероперабилност се може дефинисати као способност дељења, агрегирања или синхронизовања података/информација између хетерогених информационих система. Другим речима, семантичка интероперабилност обезбеђује да два система која комуницирају, интерпретирају заједничке или дељене податке на конзистентан начин. Циљ организационе интероперабилности је да одговори на захтеве заједнице корисника чинећи сервисе доступним, лако препознатљивим, приступачним и кориснички оријентисаним. Другим речима, то је способност пословних организација да пружају услуге једне другима, као и корисницима, клијентима или широј јавности, у случају јавних предузећа. Важно је нагласити да системи који сарађују морају након преузимања података да их користе и тумаче на исти начин, што Модел B2B интеграције саобраћајних пословних система 15 обезбеђује прагматичну интероперабилност (енгл. pragmatic interoperability) [6]. Истраживања истичу потребу за усклађивањем пословне стратегије и технологије имплементације [128]. 2.2.2. Нивои интероперабилности пословних система Повећање сарадње између предузећа током читавог животног века производа је глобални тренд. Организације се трансформишу у умрежене организације. Пословни системи и апликације морају бити интероперабилни да би постигли „глатку” пословну интеракцију изван граница организација. Данас се предузећа срећу са мноштвом проблема проузрокованих недостатком интероперабилности. Интероперабилност предузећа мора бити постигнута на следећим нивоима : • пословни ниво (енгл. Business Layer): пословно окружење и пословни процеси; • ниво знања (енгл. Knowledge Layer): вештине и компетенције у смислу искоришћења знања; • апликативни ниво (енгл. Application Layer): апликације, подаци и комуникационе компоненте; • семантички ниво (енгл. Semantic Layer): подршка међусобном разумевању свих нивоа (слика 1). Слика 1. Интероперабилност предузећа на четири основна нивоа 2.2.3. Тродимензионални радни оквир интероперабилности Радни оквир интероперабилности користи се да би се показали концептуални нивои интеграције између два предузећа. На слици 2 приказан је тродимензионални радни оквир интероперабилности, кога чине следеће три димензије: • нивои (предмет) интероперабилности, • препреке у постизању интероперабилности, • приступи проблему постизања интероперабилности. Пословање Знање ИКТ системи С е м а н т и к а Пословање Знање ИКТ системи С е м а н т и к а Предузеће A Предузеће Б Модел B2B интеграције саобраћајних пословних система 16 Слика 2. Радни оквир интероперабилности Интероперабилност се мора постићи на нивоу: података, сервиса, процеса и пословања [72]. Интероперабилност података односи се на то да различити модели података и упитни језици раде заједно. Интероперабилност података остварује се проналажењем и дељењем информација из хетерогених извора података, складиштених на различитим машинама, под различитим оперативним системима и у различитим системима за управљање базама података. Интероперабилност сервиса односи се на идентификовање и компоновање различитих апликативних функција да раде заједно, иако су пројектоване и имплементиране независно. Интероперабилност пословних процеса има за циљ да обједини различите пословне процесе, да раде заједно. Процес представља секвенцу сервиса (функција) обједињених у циљу реализације неке пословне активности. Осим повезивања интерних процеса унутар једног пословног система, постоји и потреба за повезивањем процеса из различитих организација, како би се креирао заједнички процес. Интероперабилност пословања односи се на хармонизовано пословање организација без обзира на разлике у начину доношења Модел B2B интеграције саобраћајних пословних система 17 одлука, методама рада, правним актима на основу којих функционишу, организационој култури или комерцијалним приступима. Према [164] постоје три категорије препрека интероперабилности пословних система: концептуалне, технолошке и организационе баријере (слика 2). Концептуалнe баријере односе се на синтаксне и семантичке разлике информација које се размењују. Ови проблеми односе се на моделирање на високом нивоу апстракције (као што је на пример пословни модел предузећа), као и на нивоу програмирања (на пример XML модел). Технолошке баријере односе се на неспојивости информационих технологија (архитектуре и платформе, инфраструктура, итд.) Ови проблеми односе се на стандарде за представљање, складиштење, размену, обраду података и комуникацију коришћењем рачунара. Организационе баријере односе се на дефинисање одговорности и надлежности, као и неспојивост организационих структура. Истраживања на пољу интероперабилности не састоје се само у уклањању препрека интероперабилности, већ се у значајној мери баве начинима отклањања баријера за постизање интероперабилности. Према [131] и [84] постоје три основна начина успостављања сарадње међу ентитетима (системима) да би се постигла интероперабилност (слика 2): • интегрисани приступ: постоји заједнички формат за све моделе. Овај формат не мора нужно бити стандард, али око њега се морају сложити све стране које развијају моделе и креирају системе; • јединствени приступ: постоји заједнички приступ, али само на мета-нивоу. Овај мета-модел није извршни ентитет, као што је случај у интегрисаном приступу, али обезбеђује средство за постизање семантичке еквивалентности, што је неопходно за мапирање модела; • федерални приступ: не постоји заједнички формат. Да би се успоставила интероперабилност, заинтересоване стране морају да се прилагођавају једна другој „у лету”. Коришћење федералног приступа подразумева да ниједан партнер не намеће своје моделе, језике и методе рада. То значи да партнери морају да деле једну онтологију приликом мапирања својих концепата на семантичком нивоу. 2.3. Анализа постојећих референтних модела и радних оквира интероперабилности У области интероперабилности информационих система развијено је неколико референтних модела, архитектура и радних оквира [29]. За потребе Министарства одбране САД спроведено је истраживање LISI (Levels of Information Systems Interoperability) које дефинише интероперабилност на нивоу: процедура, апликација, инфраструктуре и података. IDEAS (Interoperability Development for Enterprise Application and Software - Roadmaps) пројекат дефинише радни оквир интероперабилности на нивоу: координације предузећа, интеграције пословних процеса, синтаксне и семантичке интеграције апликација, физичке интеграције. Модел B2B интеграције саобраћајних пословних система 18 ATHENA (Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications) радни оквир омогућава интероперабилност на концептуалном, апликативном и техничком нивоу [14]. EIF (European Interoperability Framework) дефинисан је као скуп прописа, стандарда и препорука на бази којих би организације требало да се споразумеју да би заједно пословале. INTEROP (Interoperability Research for Networked Enterprises Applications and Software) дефинише препреке, нивое и приступе интероперабилности. COIN (Collaboration and Interoperability for Networked Enterprises) Consortium развио је Enterprise Collaboration Maturity Model (ECMM). ECMM има за циљ да организацијама омогући да створе слику о томе где се тренутно налазе на пољу сарадње и интероперабилности, и где могу бити уколико примене ECMM [2]. 2.3.1. LISI референтни модел интероперабилности На пољу интероперабилности пословних система прва значајна иницијатива је The Levels of Information Systems Interoperability (LISI) референтни модел развијен од стране C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) Architecture Working Group (AWG) током 1997. године [22]. Намена LISI модела била је да за Министарство одбране Сједињених Америчких Држава обезбеди логичку структуру и дисциплину, односно „зрео” модел за постепено унапређење степена интероперабилности између њихових информационих система. Као такав, LISI јача способност ефикасног управљања информационим системима у контексту мисије ефикасности. LISI референтни модел: • олакшава заједничко разумевање интероперабилности и онога што је обезбеђује, на свим нивоима детаљности интеракције система; • преводи нивое интероперабилности у захтеване способности система (процедуре, апликације, инфраструктуру, податке) што представља основу за прављење компарације хетерогених система; • изграђен је са циљем да обезбеди методологију, „зрео” модел и процес за постепено побољшање степена интероперабилности, у контексту анализе захтева, развоја система, аквизиције и увођења технологија; • обезбеђује процену доприноса информационих технологија на пољу интероперабилности. LISI референтни модел је оријентисан према нивоима, који представљају степене софистицираности потребне за остваривање интеракције између информационих система. Коришћење нивоа обезбеђује дисциплину за описивање природе интеракције информација између оперативних чворова, преводећи природу у пакет могућности информационог система – рачунарског окружења – неопходан да подржи интеракцију информација у контексту оперативних потреба (нпр. благовременост, тачност) и утврђивање правила за имплементацију система. Сваки ниво мора да покрије сва четири атрибута који омогућавају интероперабилност: процедуре, апликације, инфраструктура и подаци (енгл. Procedures, Applications, Infrastructure, Data – PAID), што је приказано у табели 1. Модел B2B интеграције саобраћајних пословних система 19 Табела 1. LISI референтни модел Опис Рачунарско окружење Ниво P A I D Предузеће Универзално 4 Ниво предузећа Интерактивне Мулти- димензи- оналне топологије Пословни модел Домен Интегрисано 3 Ниво домена Груписане World-wide мреже Доменски модел Функцио- налан Дистрибуирано 2 Програ- мски ниво Десктоп аутоматиза- ција Локалне мреже Програ- мски модел Повезан Peer-to-Peer 1 Локални ниво Стандардни системски управљачи Једноста- вна конекција Локални Изолован Ручно 0 Контрола приступа Није предвиђено Независне Приватни 2.3.2. ATHENA радни оквир интероперабилности ATHENA – Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications је интегрисани пројекат финансиран од стране Европске Комисије (енгл. European Commission) као подршка стратешком циљу: умрежено пословање и влада. Њен циљ је да буде најобухватније и најсистематичније европско истраживање на пољу интеграције пословних система и пословних апликација, на бази укидања баријера у размени информација унутар и између организација. ATHENA је научноистраживачки пројекат који предлаже интегралан, свеобухватан приступ интероперабилности. Оригиналност ATHENA пројекта је у томе што има мултидисциплинарни приступ кроз обједињавање три области истраживања, које подржавају развој интероперабилности пословних апликација и софтвера (слика 3). Циљ ATHENA пројекта је да помогне предузећима да остваре интероперабилност на такав начин да се границе између предузећа тешко уочавају. Слика 3. Интеграција знања ATHENA пројекта Моделирање предузећа Архитектуре и платформе Онтологије ATHENA Модел B2B интеграције саобраћајних пословних система 20 ATHENA радни оквир интероперабилности (енгл. ATHENA Interoperability Framework, AIF) изграђен је на бази визије: „Предузећа су способна да флексибилно развијају и извршавају интероперабилне апликације базиране на приступу вођеном моделима, развоју сервисно-оријентисаних и адаптивних софтверских решења” [7]. Питања која се тичу интероперабилности система са информационо- комуникационог аспекта, детаљно су истражена и елаборирана у оквиру Interoperability Development for Enterprise Application and Software (IDEAS) пројекта [79]. Резултат истраживања је IDEAS IF (IDEAS Interoperability Framewok) који је развијен на бази ECMA/NIST Toaster модела, ISO 19101 и ISO 19119 стандарда [80]. AIF је резултат рада на побољшању и унапређењу IDEAS радног оквира. Док се IDEAS радни оквир примарно фокусира на структурирање проблема интероперабилности, основни циљ AIF-а је синтеза резултата истраживања на ATHENA пројекту како би се омогућило проналажење адекватних решења у складу са пословним потребама и техничким захтевима. ATHENA и IDEAS развојни оквири могу се сматрати комплементарним. На сваком нивоу ATHENA развојног оквира могуће је применити IDEAS принцип структуирања интероперабилних проблема у три слоја (пословни ниво, ниво знања и ниво информационо-комуникационих технологија) узимајући у обзир семантичку димензију [167]. ATHENA радни оквир обједињује принципе развоја вођеног моделима, сервисно-оријентисане архитектуре и адаптивне архитектуре [72]. Структуиран је у три главне области интеграције, приказане на слици 4. Слика 4. ATHENA радни оквир интероперабилности ATHENA радни оквир интероперабилности Интегрише резултате истраживања Интегрише прототипове пројеката у циљу добијања профила Користи се за технолошка тестирања базирана на профилима Користи се за трансфер знања у погледу примене интеграционих технологија Концептуална интеграција − Референтна архитектура − Концепти − Модели и метамодели − Језици Апликативна интеграција − Методологије − Случајеви коришћења − Референтни примери Техничка интеграција − Алати за моделовање − Извршна окружења Користи се за унапређење идентификације потреба истраживања Интегрише искуства тестирања прототипова и технологија Модел B2B интеграције саобраћајних пословних система 21 Три главне области интеграције ATHENA радног оквира интероперабилности су: • концептуална интеграција, која се фокусира на концепте, метамоделе, језике и везе између модела. Она нам пружа основ за систематизацију различитих аспеката интероперабилности на нивоу софтверских модела; • техничка интеграција, која се фокусира на софтверска развојна и извршна окружења. Она нам омогућава развојне алате за развој софтверских модела и извршне платформе за извршавање софтверских модела; • апликативна интеграција, која се фокусира на методологије, стандарде и домене модела. Она нам пружа препоруке, принципе и патерне, који се могу користити за решавање питања софтверске интероперабилности. За сваку од три области специфициран је референтни модел за описивање и подршку примене развоја софтверских система вођеног моделима. Референтни модел за концептуалну интеграцију развијен је из угла MDD (Model Driven Development) и фокусиран је на пословне апликације и софтверске системе. Модел независан од рачунара (енгл. Computation Independent Model, CIM), одговара становишту дефинисаном из тачке гледишта независности од рачунара. Он описује пословни контекст и пословне захтеве који се постављају пред софтверске системе. Модел независан од платформе (енгл. Platform Independent Model, PIM), одговара становишту дефинисаном из тачке гледишта независности од платформе. Он описује спецификацију софтвера независног од извршне платформе. Модел одређене платформе (енгл. Platform Specific Model, PSM), одговара становишту дефинисаном из тачке гледишта одређене платформе. Он описује реалну ситуацију у којој се налазе софтверски системи. Модели на различитим нивоима могу бити семантички тумачени коришћењем референтних онтологија које помажу да се постигне заједничко разумевање на свим нивоима. Користе се патерни интероперабилности за хоризонталну и вертикалну интеграцију. Идентификоване су четири категорије аспеката система, у којима се специфична питања интероперабилности софтвера тичу концептуалне интеграције: • сервисни аспекти: сервиси представљају апстракцију и енкапсулацију функционалности обезбеђених од неког независног ентитета; • информациони аспекти: информациони аспекти односе се на поруке или структуре размене, процесиране и складиштене помоћу софтверских система или софтверских компоненти. • процесни аспекти: процеси описују секвенце активности у терминима акција, токова управљања, токова информација, интеракција, протокола итд. • нефункционални аспекти: екстра-функционални квалитети који могу бити примењени на сервисе, информације и процесе. Сва четири аспекта могу се односити на сва три нивоа: CIM, PIM и PSM. Референтни модел користи се и за поглед на интероперабилност модела, где ће се мета-модели и онтологије користити за дефинисање трансформација модела и Модел B2B интеграције саобраћајних пословних система 22 мапирање модела између различитих погледа на један пословни систем. Следеће димензије система могу се користити за анализу софтверских система, или као помоћ у структуирању процеса моделирања система и препознавању пројектантских одлука: • апстракција система: ова димензија пројектовања система рефлектује апстракцију у терминима имплементације независности и она је апострофирана у MDD; • генералност: применљивост пројектовања система има утицај на адаптивност и вишеструку употребљивост компоненти система; • тачка гледишта: модели система представљају сложену и чврсту мрежу међусобно повезаних ентитета модела. У циљу постављања различитих предмета дебате и смањења комплексности, користе се различите тачке гледишта у моделу. Та тачка гледишта такође се може тицати интероперабилности; • композиција: системи су итеративно компоновани хијерархијски од индивидуалних објеката до система у пословном контексту. На сваком од ових агрергационих нивоа ентитети морају да буду интероперабилни; • време: систем се модификује у статусу, конфигурацији и дизајну; • апстракција модела: мета-модели помажу у описивању и анализи коришћених модела. Свака од ових димензија може подржати постизање интероперабилности или може репрезентовати изазове интероперабилности. Референтни модел техничке интеграције развијен је из угла оријентисаности ка сервисима где софтверски систем обезбеђује низ сервиса захтеваних од пословних система и њихових корисника. Референтни модел апликативне интеграције развијен је на бази послова обављених у оквиру радног оквира архитектуре предузећа и радног оквира архитектуре софтвера. Пословни и софтверски модели могу бити доведени у везу у потпуности, без обзира на формализме језика за моделирање, коришћењем метамодела. То је важно да би се схватиле зависности између различитих модела и погледа како би се остварила интероперабилност. Реализација радног оквира фокусирана је на обезбеђење препорука и делова модела за креирање или наручивање сопствене развојне и интеграционе методологије базиране на тим принципима и препорукама као и постојећим могућностима за креирање или наручивање сопственог скупа MDI (Model Driven Interoperability) алата. MDI радни оквир има за циљ да обезбеди препоруке за следеће области: • метамоделирање, • трансформације модела, Модел B2B интеграције саобраћајних пословних система 23 • UML (Unified Modeling Language) профили и језици специфичних домена (енгл. Domain-Specific Languages, DSLs) • архитектура вођена моделима (енгл. Model-Driven Architecture, MDA) и интероперабилност вођена моделима (енгл. Model-Driven Interoperability, MDI) приказани на слици 5, • инжењерске методе. Слика 5. ATHENA референтна архитектура интероперабилности 2.3.3. INTEROP радни оквир интероперабилности Сврха овог оквира је да се дефинише домен истраживања на пољу интероперабилности пословних система и помогне да се идентификује и структуира знање домена [27]. Код овог приступа полази се од становишта да пословни системи нису интероперабилни јер постоје препреке за интероперабилност. Препреке су разне врсте некомпатибилности, на различитим нивоима предузећа. Некомпатибилност омета размену информација и спречава размену сервиса. Идентификоване су уобичајене препреке за сва предузећа, без обзира на њихов сектор делатности и величину. Овај приступ састоји се од следећих препорука: • дефинисати домен пословне интероперабилности кроз израду оквира интероперабилности, коришћењем приступа вођеног препрекама интероперабилности; • идентификовати и структуирати знање (решења) домена помоћу оквира. Предложени радни оквир интероперабилности разрађен је на основу концепата развијених у неким другим оквирима и моделима интероперабилности, фокусирајући се на оне концепте који су најрелевантнији да дефинишу домен Модел B2B интеграције саобраћајних пословних система 24 истраживања о интероперабилности пословних система. У оквиру INTEROP NoE отпочео је развој Model Driven Interoperability (MDI) архитектуре која је базирана на принципима Model-Driven Architecture (MDA) и интероперабилности пословних система [129]. Циљ овог приступа је да се омогући аутоматска трансформација модела између Computational Independent Model (CIM), Platform Independent Model (PIM) i Platform Specific Model (PSM) нивоа MDA структуре [83]. Истраживања на овом пољу настављена су у оквиру ATHENA пројекта. 2.3.4. EIF радни оквир интероперабилности Европски радни оквир интероперабилности (енгл. European Interoperability Framework, EIF) има за циљ да подржи стратегију Европске Уније која настоји да обезбеди кориснички оријентисане сервисе е-government-а, олакшавајући на пан- европском нивоу интероперабилност услуга и система између јавних администрација, као и између администрација и јавности (грађана, пословања) [157]. Европски оквир интероперабилности дефинисан је скупом законских аката, стандарда и препорука, који описују начин на који су се организације договориле или начин на који би требало да се договоре, да би пословале заједно. Оквир интероперабилности, дакле, није непроменљив документ, већ се може временом прилагођавати, како се буду мењале технологије, стандарди и административни захтеви. EIF даје препоруке и дефинише генеричке стандарде узимајући у обзир организационе, семантичке и техничке аспекте интероперабилности. EIF даје препоруке које се односе на три основна нивоа комуникација и размена информација: администрација – администрација (А-А), администрација – грађани (А-Г) и администрација – пословање (А-П), као што се види на слици 6 [52]. Слика 6. Европски радни оквир интероперабилности Модел B2B интеграције саобраћајних пословних система 25 2.4. Анализа постојећих стандарда, модела и решења на пољу B2B интеграције Данас свака организација мора да шаље информације и дели знање изван својих функционалних и организационих граница. Подразумева се да је интеграција предуслов за пословање сваке организације, а не њен избор [92]. Кретање у правцу потпуне интеграције идентификовано је у различитим индустријама, као што су: здравство, е-government, индустрија нафте и гаса, итд. Неки аутори описују интеграцију као „сложену друштвено-техничку мрежу која укључује много хетерогених глумаца, који морају да ’играју заједно’, у договору, како би се испунили предвиђени циљеви интеграције” [54]. 2.4.1. Интеграција апликација - појам и дефиниције Интеграција апликација представља сигурно и оркестрирано дељење процеса и/или података између апликација у оквиру једног или више предузећа. Данас, повезивање апликација представља ИТ неизбежност. Процес није нимало лак ни једноставан, без обзира на постојање различитих стандарда и технологија направљених да међу собом лако сарађују. Интеграција апликација представља стратешки приступ повезивању више информационих система заједно, како на нивоу сервиса тако и на нивоу информација, подржавајући њихову способност да размењују информације и повезују процесе у реалном времену. Проток информација између интерних и екстерних система представља очигледну вредност за предузећа - обезбеђује да се посао обавља у реалном времену и са најмањим могућим кашњењем у односу на моменат иницирања. Приликом интеграције апликација веома је важно да се обрати пажња на: • ниво аутоматизације: аутоматизација подиже ниво ефикасности и може помоћи да се елиминишу недоследности које постоје у пословној пракси. Међутим, потпуна аутоматизација може захтевати велике напоре, а учинак веома често није брзо видљив. Помоћу једноставнијег решења се можда достиже само део пословне користи, али брже и уз много мање ризика. На пример, приказивање информација из више различитих система на једном екрану може повећати продуктивност, а да при томе не морају да се реше све различитости између постојећих система; • ниво апстракције: апстракција система дозвољава промену једног система без утицаја на неки други систем. Апстракција се може достићи на више начина. На пример, испоруком самосталног документа између система. Пребацивање документа не обавезује други систем да изврши одређену функцију, али оставља ту могућност. Према томе, ако циљна апликација обрађује документ на другачији начин, та обрада не утиче на оригинални систем; • очување стања: већина интеграционих решења захтева да се чува стање. На пример, да би се обавило неко плаћање, прво треба да се креира поруџбина, да се провери њена исправност, затим да се провере залихе за робу која се Модел B2B интеграције саобраћајних пословних система 26 налази на поруџбеници, да се на вредност робе зарачунају порези и да се тек онда креира фактура. Да би се обавили сви кораци неопходни за извршавање овог посла, потребно је чувати међу податке, односно формирати механизам за чување стања. Стање се може чувати на више начина: − ручно (запослени га може запамтити или чувати податке у облику белешки, што је свакако мање ефикасно и мање поуздано него аутоматско чување стања), − унутар постојеће апликације (на пример, када се провери постојање залиха, може се проследити порука финансијском систему да прорачуна вредност пореза - овај приступ је ефикаснији него ручни, али су апликације повезане чвршће међу собом, што би требало избегавати), − у оквиру интеграционе апликације (може се убацити нови слој који би омогућио оркестрацију активности између више апликација преко чувања стања); • повезаност: слабо или лабаво повезивање апликација је постало стандард код дистрибуираних апликација. Слабо повезане апликације мање су зависне једна од друге, што им дозвољава да се развијају независно. Међутим, слабо повезивање апликација није решење за све могуће проблеме који могу настати; • семантичка неусаглашеност (дисонанца): представља једну од кључних тешкоћа код креирања решења за интеграцију апликација. Термин описује ситуацију у којој то што изгледа да су подаци исти не мора да значи да они то и јесу. На пример, један систем подразумева да вредност робе укључује и вредност пореза, док други систем у вредност робе не укључује порез. Интеграција апликација може бити: • интерна - када се повезују апликације у оквиру једног предузећа, што се у литератури назива Enterprise Application Integration (EAI), или • екстерна - када се повезују апликације различитих предузећа, што се у литератури назива Business to Business (B2B) Application Integration. Оба облика интеграције апликација веома су слична: скоро увек је потребно трансформисати податке у неки други облик, обезбедити њихов пренос на тачно одредиште и креирати правила обраде која дефинишу интеграционо понашање. Ефикасна интеграција апликација може обезбедити следеће пословне користи предузећу: • смањење трошкова, • повећану оперативну ефикасност - на догађајима заснована комуникација унутар предузећа и предузећа са партнерима, • еластичност и прилагодљивост - кроз слабо повезане (loose coupling) системе, што обезбеђује брзе промене без накнадних негативних ефеката, • подршку за различите рачунарске платформе и базе података, Модел B2B интеграције саобраћајних пословних система 27 • повећани повраћаји постојећих инвестиција - кроз продужење њиховог животног века, • лако прихватање и прилагођавање нових технологија - које ће обезбедити проширење пословања, • повећану тачност информација и на основу тога брже доношење бољих пословних одлука - због смањења или укидања кашњења у ажурирању, • смањивање претходно захтеване мануелне интервенције за повезивање пословних процеса кроз увођење аутоматских корака, • прилагођавање пословних процеса потребама предузећа. Интеграција апликација захтева повезивање апликација и извора података тако да они могу једноставно делити пословне процесе и податке. Интеграција апликација и извора података мора бити постигнута без значајних промена код постојећих апликација и података. 2.4.2. B2B интеграција - појам и дефиниције Интеграција апликација је ефикасна и оркестрирана размена ресурса и/или података између апликација које се користе у оквиру једне или више компанија. Business to business (B2B) апликације фокусирају се на развој пословних партнерстава и трансформацију односа између организација [163]. B2B интеграција у основи представља безбедну координацију информација између предузећа и њихових информационих система [142]. B2B интеграција је на XML-у (eXtensible Markup Language) заснована интеграција која омогућава сигурну размену, пословних информација преко Интернета, у реалном времену. 2.4.3. Типови B2B интеграције Постоје различити приступи у дефинисању појма B2B интеграцијe, као и његовој категоризацији. Најчешће цитирани аутор у овој области, сврстава типове B2B интеграције у неколико општих категорија [109]: • интеграција информација, • интеграција преко корисничког интерфејса, • интеграција на бази сервиса, • интеграција пословних процеса. Тренд у интеграцији апликација представља кретање од интеграције информација према интеграцији помоћу сервиса. Пошто интеграција апликација представља сложен проблем, у реалности примењена решења најчешче представљају комбинацију примене различитих типова интеграције апликација и неколико врста технологија. Немогуће је пронаћи једно технолошко решење, које ће бити универзално применљиво, јер свако појединачно предузеће захтева различит приступ. Модел B2B интеграције саобраћајних пословних система 28 2.4.3.1. Интеграција информација Интеграцијом информација корисницима се омогућава јединствен поглед на податке који су физички складиштени на различитим серверима [23]. Извори података су независни, а корисници или апликације им приступају кроз локалну или јавну мрежу. Интеграција информација представља најчешћи и најстарији начин за интеграцију апликација, јер обезбеђује јефтин и једноставан механизам за интеграцију преко размене података између два или више система. Предности: • само се манипулише информацијама, обично није потребно да се мењају постојећи системи. Већина апликација, а поготово базе података, већ знају како да креирају и користе информације; • није неопходно управљање стањем, логиком или редоследом извршавања; • овај приступ је једноставан за разумевање и често је коришћен. Недостаци: • не треба изгубити из вида да овај тип интеграције не представља само пребацивање информација између складишта са подацима, већ и управљање разликама које постоје код шема података, као и код садржаја података. Размена података између система може се обављати коришћењем следећих метода: • репликација података: представља пребацивање података између две или више база података, које могу, али не морају, бити исте врсте или од истог испоручиоца. Решења за репликацију података углавном представљају слој између две или више база података. Подаци се узимају из једне или више база, да би били смештени у другу базу или базе података. Већина решења за репликацију обезбеђује и неки облик трансформације података. Предност овог начина интеграције је у једноставности примене и ниским трошковима; • федерација података: представља интеграцију више база података и модела база података у виртуелну базу. Виртуелна база се креира помоћу јединственог, обједињеног погледа на физичке базе. Апликације користе ову виртуелну базу да би преко ње приступиле потребним информацијама. Уколико је потребно, федерација података може да обезбеди сакупљање и дистрибуцију података у физичке базе. Предност коришћења федерације података се огледа у могућности повезивања различитих типова података у јединствени модел, који подржава размену информација. Федерација података дозвољава приступ било којој конектованој бази у предузећу кроз један, добро креиран интерфејс, што представља најелегантније решење до којег се може доћи коришћењем интеграције информација. Модел B2B интеграције саобраћајних пословних система 29 2.4.3.2. Интеграција преко корисничког интерфејса Овај начин интеграције апликација односи се на употребу интерфејса, који постоје у апликацијама креираним у предузећу или купљеним од неког испоручиоца апликација. Творци користе те интерфејсе да би приступили пословним процесима и информацијама. Коришћењем интерфејса, програмери могу повезати више апликација, дозвољавајући им да деле пословну логику и информације. Ограничења са колима се могу срести они који се баве овом врстом интеграције се односи на специфичне особине и функције апликационих интерфејса. Процесирање интерфејса је веома чест начин интеграције апликација као што су SAP, PeopleSoft и Oracle. Да би интегрисали те системе са другима у предузећу, програмери морају да користе њихове интерфејсе да би приступили и процесима и подацима, извукли информације, пребацили их у формат разумљив циљној апликацији, а на крају и пребацили потребне информације. Овај тип интеграције апликација дозвољава нам да имамо увид у мноштво система, и екстерних и интерних, преко заједничког корисничког интерфејса, најчешће приказаног помоћу Web читача. На тај начин се повећава продуктивност, јер није више потребно да корисник приступа различитим системима независно. Решење за овај тип интеграције често се назива и портал. Интеграција апликација преко портала је веома коришћена, што је свакако последица и пораста популарности Web-а. Интеграцију преко портала често је једноставније имплементирати него друге типове интеграција, које захтевају виши ниво аутоматизације. Ова врста интеграције представља веома добар први корак према интеграцији система. Док су други типови интеграције апликација фокусирани на размену података у реалном времену између система и компанија, портал се бави приказивањем информација које потичу из различитих система. Напредније верзије портала дозвољавају корисницима да креирају промене код појединачних система или чак да креирају промене код више система симултано. Предности: • пошто је примарна функција приказивање информација, интеграција преко портала може бити додата на постојеће системе без нарушавања њихове постојеће функционалности; • креирање портала над постојећим апликацијама може бити обављено веома брзо, чак за неколико дана или недеља, уколико се користе алати који постоје на тржишту; • интеграција преко портала обезбеђује одређени ниво флексибилности. Зато што корисници доносе одлуке, интеграција помоћу портала може бити коришћена у ситуацијама где пословна правила нису добро дефинисана или усаглашена. Модел B2B интеграције саобраћајних пословних система 30 Недостаци: • неефикасност. Захтева ручну интервенцију од стране корисника, који види информације из више апликација, али у једном тренутку има интеракцију само са једном апликацијом; • могућност појављивања грешака. Корисник доноси пословне одлуке и одређује редослед извршавања појединачних послова. 2.4.3.3. Интеграција на бази сервиса Два система користе Web сервисе да комуницирају међусобно када апликација креира XML документ у облику поруке и пошаље га преко мреже до Web сервиса [56]. Опционо, Web сервис шаље одговор на захтев у форми XML документа. Web сервиси представљају позивање операција преко Web-а уз коришћење HTTP-а као основног протокола и XML-а као начина за дефиницију позване операције, њених аргумената и повратних резултата [89]. Web сервис је софтверски систем дизајниран да подржи интероперабилну интеракцију рачунара кроз мрежу [159]. Ово тврђење изведено је на основу следећих особина Web сервиса: операције Web сервиса се позивају и њихови резултати враћају у XML формату; сви користе заједничке стандарде и комуникационе протоколе; не зависе од технологије у којој су развијене апликације које их позивају [140]. Основни задатак сваке озбиљније софтверске архитектуре је да омогући максималну флексибилност и проширивост. Флексибилност и проширивост знатно поједностављују животни циклус пословних апликативних система свим заинтересованим странама (енгл. stakeholders) које у њему учествују (крајњи корисници, наручиоци, софтверске архитекте, развојни инжењери, тестери и др). Поједностављење животног циклуса огледа се у могућности брзе реакције на промене у пословним захтевима, модуларности, конфигуративности, робусности и др. Сервисно-оријентисана архитектура - СОА (енгл. Service-Oriented Architecture, SOA) представља резултат еволуције софтверске индустрије на подручју постизања максималне флексибилности и проширивости [124]. Постоје различите дефиниције СОА концепта, мада се већина слаже да сервисно- оријентисана архитектура представља архитектурални стил који промовише примену лабаво повезаних сервиса у циљу осигурања максималне пословне флексибилности на интероперабилан и технолошки независан начин. СОА представља архитектуралну парадигму примарно везану за софтверски дизајн, а не за технологију. Прихватање СОА концепта води ка промени приступа у писању апликација. Појам апликације еволуира у концепт композиције и груписања лабаво повезаних, уско дефинисаних и на стандардима утемељених сервиса у веће и сложеније целине. СОА се темељи на сервисима као основним градивним јединицама, а сервиси су пословна категорија (нпр. обрада платног налога, ауторизација плаћања кредитном картицом, генерисање фактуре итд). Сервисно-оријентисана архитектура је архитектурални стил и принцип пројектовања код развоја и интеграције апликација. СОА укључује: • архитектуру која подстиче отворене стандарде и приказ софтверских елемената као сервиса; Модел B2B интеграције саобраћајних пословних система 31 • нагласак је на компоновању (енгл. assembly) апликације пре него на детаљима имплементације; • објектно-оријентисане, процедуралне, data-centric приступе за имплементацију решења (сервиси су обично имплементирани коришћењем неке од ових технологија); • сет архитектуралних принципа и патерна као што су модуларност, енкапсулација, лабава спрегнутост, поновна употребљивост, композитна имплементација итд. СОА је стандардизовани приступ дизајнирању и креирању ИТ инфраструктуре са циљем да омогући: • једноставну интеграцију система на различитим платформама, независно од технологије, • размену података међу различитим системима, • јединствени и систематизовани приступ подацима у целокупном систему, без обзира на канале приступа (Web, PC, SMS, CallCentar), • брзо увођење нових система и функционалности. Применом СОА добија се флексибилнији систем који промовише употребу већ постојећег ИТ система и олакшава његову даљу еволуцију. СОА ће ИТ систем учинити: • флексибилнијим – независним од технологије, • скалабилнијим – ресурси потребни за увођење нових услуга/система не зависе од комплексности система, • робустнијим – отпорним на отказе појединих делова система. Сервиси су кључна градивна компонента СОА. Сервис је у суштини добро- дефинисан интерфејс ка једном аутономном сегменту функционалности, који често кореспондира са одређеним пословним процесом. Аутори у [138] дефинишу сервис као засебну јединицу пословне функционалности, коју омогућава уговор сервиса. Неки аутори сматрају да архитектура заснована на сервисима подразумева грубо подељене интерфејсе према пословним функционалностима [95]. Обе групе аутора слажу се око тога да је сервис намењен да обезбеди одређене пословне функционалности. Уобичајени сегменти, који чине сервис и омогућавају његово коришћење, су [10]: • уговор (енгл. Contract): описује операције које сервис излаже, типове порука, и патерне размене порука подржане од стране сервиса; • поруке (енгл. Messages): подаци који се размењују између онога ко обезбеђује сервис и онога који га користи; Модел B2B интеграције саобраћајних пословних система 32 • имплементација (енгл. Implementation): део сервиса који актуелно обрађује захтеве, извршава одговарајућу пословну логику и опционално враћа одговор; • снабдевач сервиса (енгл. Service provider): домаћин сервиса који објављује интерфејс и управља веком трајања сервиса; • корисник сервиса (енгл. Service consumer): свестан операција које нуди сервис, зна како да пронађе снабдевача и одреди тип поруке коју ће да прими; • фасада (енгл. Facade): опционално, фасада може бити намењена одређеном типу корисника сервиса. Овај тип интеграције дозвољава предузећима да деле заједничке апликационе сервисе као информације. Предузећа постижу ово дељење или преко дељивих апликационих сервиса, или обезбеђујући инфраструктуру за такве дељиве апликационе сервисе. Апликациони сервиси могу бити дељиви тако што се хостују на једном централном серверу, или тако што им се приступа преко дистрибуираних објеката или Web сервиса. Најзначајнију примену интеграције апликација помоћу сервиса обезбеђују Web сервиси. Web сервис представља стандард за креирање интероперабилних дистрибуираних апликација. Web сервиси у основи граде неку врсту пословне логике и функционализам доступан у апликацијама или модулима који је преко сервисног интефејса доступан клијентским апликацијама [10]. Корисник Web сервиса не мора знати детаље имплементације Web сервиса - клијент је способан да приступи или позове Web сервис са информацијама које су садржане у сервисном интерфејсу. Ова архтитектура у основи обезбеђује лабаво спојен модел (енгл. loosely coupled model) у коме корисник не мора бити свестан технологије и инфраструктурних детаља. World Wide Web Consortium даје следећу дефиницију Web сервиса: „Web сервис је софтверски систем у ужем смислу, пројектован да подржи интероперабилне интеракције између рачунара кроз мрежу. Представља интерфејс описан у формату погодном за рачунарску обраду”. Други системи ступају у интеракцију са wеб сервисима користећи SOAP поруке, које се обично преводе коришћењем HTTP-а са XML сериализацијом у сарадњи са осталим, повезаним, Web стандардима. До појаве Web сервиса, најчешћи облик интеграције помоћу процеса се обављао коришћењем RPC (Remote Procedure Call) или МОМ (Message Oriented Middleware) интеграције. Web сервиси су омогућили комбиновање предности МОМ и RPC технологија. Web сервиси подржавају слабо повезане конекције и једноставно их је употребљавати. Алати за креирање Web сервиса могу генерисати сав код за комуникацију а истовремено и даље обезбеђивати висок ниво апстракције између апликационог кода и формата поруке. Вероватно најбитнија особина Web сервиса је њихова способност да обезбеде заједнички начин да било која апликација, писана коришћењем било ког програмског језика, која се извршава на било којој платформи, може да Модел B2B интеграције саобраћајних пословних система 33 комуницира са неком другом апликацијом. На тај начин, Web сервиси решавају проблем комуникације између хетерогених система [110]. Велику погодност за коришћење Web сервиса представља њихово ослањање на стандардне Интернет протоколе, који су саставни део сваког система повезаног на Интернет. Сви велики испоручиоци софтвера дају велику подршку коришћењу Web сервиса кроз прилагођавање својих производа. Ова подршка обезбеђује и ниску цену коришћења Web сервиса као начина за интеграцију апликација. Web сервисе је лакше користити него традиционалне технологије за интеграцију помоћу процеса, што смањује трошкове развоја. Веома је тешко пронаћи програмере са великим искуством у коришћењу CORBA, RMI, DCOM или МОМ технологија, што условљава високу цену за њихово ангажовање. Супротно, Web сервисе је много лакше користити, тако да све већи број дивелопера поседује вештине везане за развој Web сервиса. Дакле, Web сервиси су: јефтини, лаки за коришћење, раде на било којој платформи, могу бити написани било којим програмских језиком, могу се користити са интеграцију и интерних и екстерних апликација. 2.4.3.4. Интеграција пословних процеса Пословни процеси могу се дефинисати као низ активности које трансформишу одређене инпуте у аутпуте који имају одређену вредност за купца. У овом контексту, моделирање пословних процеса сматра се саставним делом моделирања предузећа. Постојећа разноликост језика за моделирање пословних процеса (engl. Busиness Process Modelиng Languages, BPML) увећала се са појавом Unиfиed Modelиng Language (UML) и одређеног броја иницијатива у области стандардизације моделирања пословних процеса, укључујући Busиness Process Modelиng Notatиon (BPMN). Busиness Process Management Inиtиatиve (BPMI) развио је стандард BPMN. BPMN 1.0 спецификација објављена је у мају 2004. године. Примарни циљ BPMN је омогућавање нотације која ће бити радо и лако прихваћена од свих пословних корисника, почев од пословних аналитичара који креирају иницијални нацрт процеса до техничких извођача одговорних за имплементацију технологије која ће реализовати те процесе, и коначно, пословних људи који ће управљати тим процесима и пратити их. BPMN ће такође бити подржан од једног интерног модела који ће обезбедити генерисање извршног BPEL4WS (Business Process Execution Language for Web Services). На овај начин BPMN креира стандардизовани мост за премошћавање јаза између пројектовања пословних процеса и њихове имплементације. BPMN дефинише Business Process Diagram (BPD), који је заснован на блок нотацији прилагођеној за креирање графичких модела операција које чине пословне процесе. Модел B2B интеграције саобраћајних пословних система 34 Термин „business process” широко се користи у различитим конотацијама. Пословни менаџери и аналитичари заинтересовани су за концептуални дизајн пословних процеса. Они користе моделе пословних процеса као базу за документацију, комуникацију, као и оптимизацију процеса. Када се дође до имплементације пословних процеса аналитичари информационих система дефинишу процесе техничким представљањем. Да би разликовали концептуални модел пословних процеса од њихове техничке репрезентације у информационим системима, посматрамо техничку имплементацију пословних процеса као workflow. Карактеристике једног пословног процеса између организација могу се дефинисати на следећи начин: две или више самосталних организација заједнички извршавају процес са циљем да креирају један известан, сигуран „output” (резултујући производ или услугу). Пословни процеси спољних организација често се посматрају као „црна кутија”, пошто активности које чине процесе и њихове међузависности са интерним процесима, нису познате интерном особљу. Да би омогућили основну комуникацију између пословних партнера и разјаснили њихове узајамне зависности, будућа архитектура пословних процеса требало би да одражава интеграцију екстерних процеса. Овај тип интеграције заснива се на креирању нове апликације, односно логичког слоја, са циљем координације извршавања већ постојећих апликација и сервиса. Интеграција пословних процеса представља нови ниво над постојећим решењима интеграције апликација, који укључују интеграционе сервере, апликационе сервере, као и дистрибуиране објекте. Интеграција пословних процеса (слика 7) обезбеђује механизам повезивања различитих процеса, кроз креирање решења за аутоматизацију послова који су се раније извршавали ручно. Слика 7. Графички приказ интеграције апликација помоћу интеграције пословних процеса Модел интеграције процеса Предузеће А Предузеће Б Предузеће Ц Модел B2B интеграције саобраћајних пословних система 35 Интеграција пословних процеса представља и стратегију и технологију, која повећава снагу предузећа кроз могућност интеракције са различитим апликацијама како у оквиру, тако и ван предузећа. Интеграција пословних процеса обезбеђује интеграцију апликација користећи различите мета податке, платформе и процесе. Зато, технологија за овај тип интеграције мора бити флексибилна, да би могла да обезбеди повезујући слој између изворног и циљног система. Интеграцију пословних процеса најбоље је дефинисати примењујући одговарајућа правила, поређаних у логичку секвенцу, у редоследу неопходном за пренос информација између система, као и помоћу визуелизације и дељења апликационих процеса, укључујући креирање заједничког апстрактног процеса који повезује интерне и екстерне системе. Интеграција пословних процеса може се урадити коришћењем неких од постојећих стандарда и алата, који обезбеђују заједничке механизме и семантику за ову врсту интеграције. Комуникација код интеграције апликација преко слоја пословне логике може се обавити или позивањем функција или слањем порука: • Distributed Object - Remote Procedure Call (RPC) интеграција. Објекти из једне апликације комуницирају са објектима друге, удаљене апликације, као да комуницирају локално једни са другима. Веома познати примери технологија који обезбеђују овај тип интеграције су: − Common Object Request Broker Architecture (CORBA), − Open Network Computing (ONC) RPC, − Microsoft RPC, − Microsoft Distributed Component Object Model (DCOM), − Java Remote Method Invocation (RMI) и − .NET Framework Remoting. • Message-Oriented Middleware (MOM) интеграција. Системи се повезују користећи асинхроне низове порука кроз захтев/одговор (енгл. request/response) функционалност, која се обезбеђује тако што један систем креира request message и шаље је у ред порука систему, који има могућност да прихвати и обради такву поруку, као и да креира response message. Познати примери су: − IBM WebSphereMQ и − Microsoft MSMQ (Microsoft Message Queuing). Предности: • оптимизација, или способност редефинисања процеса у било ком тренутку, да би се обезбедила пословна подршка и процес учинио ефикаснијим; • апстракција, или способност сакривања комлексности појединачних апликација од пословног корисника; • MOM системи користе слабо повезане конекције, што значи да постоји велики ниво апстракције између програмског кôда и формата поруке. Две апликације које међусобно комуницирају се морају сагласити око формата Модел B2B интеграције саобраћајних пословних система 36 поруке коју размењују, при чему апликације поседују одговарајућу самосталност око обраде поруке. Такође, уколико се модификује апликација, то не мора да значи и промену корисничког интерфејса; • релативно је једноставно креирати интеграциони слој који користи RPC технологију. Недостаци: • да би две апликације могле међу собом да комуницирају слањем порука, морају да користе исти MOM производ; • да би две апликације могле међу собом да комуницирају позивањем функција, морају да користе исти тип система са обе стране (и клијентске и серверске) конекције; • уколико две апликације међу собом комуницирају позивањем функција, а са клијентске стране користе један тип протокола (на пример COM), а са серверске стране користе други тип протокола (на пример CORBA), морају да користе специјално направљене мрежне пролазе (енгл. gateway), као нпр. COM/CORBA мост, који приликом преноса преводе један протокол у други; • велики проблем може да представља проналажење једног RPC система који подржава све програмске језике на свим платформана, а да при томе има и пристојну цену: − Java платформа обезбеђује уграђену подршку за RMI и CORBA, али подржава искључиво Java програмски језик; − Microsoft Windows платформе имају уграђену подршку за Microsoft RPC и DCOM, као и подршку за било који програмски језик, међутим ти програмски језици се обично могу извршавати само на Windows платформама; − већина UNIX и Linux система обезбеђују уграђену подршку за ONC, али се ONC веома ретко може наћи на Windows плаформама, и углавном има подршку само за C, C++ и Java програмске језике; − CORBA се може извршавати на било којој платформи и подржава скоро све програмске језике, али велики недостатак код CORBE представља обавеза лиценцирања. Такође, Microsoft развојни алати немају уграђену подршку за CORBA, због чега многи програмери сматрају да ју је веома тешко користити. 2.4.4. Изазови код B2B интеграције Највећи изазови B2B интеграције су: • интеграција интерних апликација. Један од највећих изазова са којима се суочавају компаније приликом B2B интеграције јесте да интегришу информације уз помоћ постојећих интерних апликација; • различити формати интерних података у оквиру компаније; Модел B2B интеграције саобраћајних пословних система 37 • хетерогеност система. Овде се мисли и на интерне системе унутар компаније, и на екстерне системе; • сигурност података; • интегритет трансакција. Интегритет трансакције дефинише се као степен до кога трансакција тече кроз мрежу достижући своју крајњу дестинацију, без промене њене функције, садржаја или значења; • управљање интерним пословним процесима. Мисли се на недостатак интеграције интерних пословних процеса тамо где то постојећа технолошка решења дозвољавају; • управљање пословним процесима између организација. Да би се то омогућило потребно је формирати тим од пословних и ИТ професионалаца свих партнера, који ће редизајнирати основне пословне процесе, из перспективе Business to Business интеграције; • интерни отпор променама. Да би B2B интеграција заиста успела, цела организација мора бити мобилисана. Сви сектори, свих учествујућих организација морају бити укључени у рад са технолошким сектором, који има задатак да имплементира интеграцију; • индустријски стандарди. Недовољно развијени индустријски стандарди за извршавање B2B трансакција путем Интернета су главна препрека за имплементацију B2B интеграције у многим компанијама. Главни изазов код коришћења XML-а није у структури и синтакси докумената, већ у семантици документа који представља пословни процес; • дистрибуирана контрола. B2B подразумева усклађену интеракцију више ИТ група, више удружења корисника и више доносиоца одлука. Свака од тих група има независтан скуп циљева и захтева. Сваки посао који укључује слагање на више нивоа, у најмању руку је неизвестан; • перформансе и скалабилност. B2B подразумева агрегацију или дистрибуцију информација у реалном времену кроз десетине или стотине компанија. Тако, ако тип дистрибуиране архитектуре није добро дизајниран, перформансе апликација могу бити значајно погоршане; • висока цена. B2B интеграција је скуп процес; • 24/7 доступност система. Доступност података у реалном времену 24 часа дневно и седам дана у недељи, је истовремено једна од највећих предности, али и највећих изазова B2B интеграције. 2.4.5. Најзначајнији XML стандарди у области B2B интеграције cXML Commerce XML (cXML) представља стандард који садржи спецификацију структуре података, потребну за размену информација о производима и каталозима производа било које врсте [35]. За сада, cXML стандард користе и Модел B2B интеграције саобраћајних пословних система 38 подржава више од 50 водећих компанија из различитих области (телекомуникације, хардвер, софтвер, аутомобилска и прехрамбена индустрија, превозници, издавачи, итд). Међутим, овај стандард још увек не садржи описе процедура (функционалних позива) које би омогућавале различите типове претрага. Другим речима, постоји мноштво спецификација, користе се савремене технологије, али нема јединствено прихваћених протокола и формата података за потребе претраживања тржишта. eBIS-XML Business Application Software Developers Association (BASDA), представља заједницу од преко 300 водећих светских софтверских инжењера, признату од стране Уједињених нација, Европске комисије и владе Уједињеног краљевства. eBIS-XML је BASDA стандард за размену података у електронском пословању, у XML формату. Стандард је први пут развијен 1999. године и до данас је широко распрострањен. eBIS-XML је само стандард који треба да демонстрира и примени интероперабилну електронску трговину између стандардних софтверских пакета. BASDA је успешно развила интерфејс користећи XML технологију. Поруке које дефинише стандард дизајниране су као шеме које подржавају велике рачуноводствене системе, као што је SAP у комуникацији са малим пословним системима, као што је TAS Books. Уколико поруку прими систем који не подржава eBIS-XML стандард, или уколико његова организација нема рачуноводствени софтвер, оне се могу једноставно приказати и одштампати као докуманта. То значи да компанија не мора бити упозната са тим да њен добављач или клијент користи eBIS-XML стандард, пре него што од њега прими eBIS-XML наруџбеницу или рачун. UBL Universal Business Language (UBL) је назив за библиотеку стандардних XML докумената. Документа је развио технички комитет OASIS (Organization for the Advancement of Structured Information Standards) са групом организација које се баве стандардима података. UBL садржи 31 пословни документ који покривају договарање пре продаје, наручивање, испоруку, фактурисање и наплату. UBL омогућава реализацију пословања, ревизију, правне процедуре, управљање подацима и непосредну интеграцију података у информационе системе корисника. Корени докумената налазе се у EDI (Electronic Data Interchange) стандардима. Од 2006. UBL верзија 2.0 документа садрже процедуре валидације и ауторизације података. XBRL XBRL потиче од eXtensible Business Reporting Language. XBRL је језик за електронску комуникацију пословних и финансијских институција, који доноси револуционарне промене у области пословног извештавања широм света. Његови главни доприноси су у припремању, анализи и размени пословних информација. Он обезбеђује смањење трошкова и већу ефикасност, унапређује Модел B2B интеграције саобраћајних пословних система 39 тачност и поузданост информација, свих субјеката који обезбеђују или користе финансијске податке. Ово је још један из фамилије „XML” jezika, који постаје стандард у смислу размене информација између пословних система на Интернету. XBRL је развијен од стране једног међународног непрофитног конзорцијума, кога чини више од 600 најзначајнијих компанија, организација и агенција из владиног сектора. То је један отворени, бесплатни стандард који је већ ушао у практичну употребу у великом броју земаља, чије се имплементације рапидно увећавају широм света. xCBL XML Common Business Library (xCBL) развила је компанија Veo Systems 1997. Он дефинише структуру пословних докумената коју подржавају Microsoft, SAP, Compaq, HP, SunMicrosystems и CommerceOne. xCBL представља скуп XML градивних блокова и оквира докумената који омогућава изградњу XML докумената. Карактерише га могућност пуне интеграције са ERP апликацијама и компатибилност са RosettaNet-ом и EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) стандардом. Обухвата 44 пословна документа. 2.4.6. ebXML ebXML је скраћеница од Electronic Business Extensible Markup Language. То је стандард креиран са идејом да замени EDI стандарде. ebXML није производ, већ скуп упутстава за аутоматизацију електронског пословања [94]. Резултат је заједничког рада United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) и Advancing open standards for the information society (OASIS). Визија ebXML радног окружења је јединствено, глобално елекронско тржиште, на коме се пословни парнетри могу препознати, договорити о међсобној сарадњи и релизовати тај договор. Све ове операције морају бити аутоматизоване разменом одговарајућих XML докумената. У циљу подршке малих и средњих предузећа софтверска индустрија је развила комерцијална решења за различите B2B сценарије. ebXML специфицира једно ново радно окружење, које даје један алтернативни поглед на пословну сарадњу, као што је приказано на слици 8. Овај циркуларни начин посматрања електронске пословне сарадње (енгл. Electronic Business Collaboration) истиче чињеницу да се ради о вишестепеном процесу. Приликом електронске пословне сарадње компаније морају да прођу кроз све фазе овог циклуса: • дефинисање процеса (енгл. Proces Definition). Представља дефинисање неопходних процеса у току пословне сарадње, коришћењем метода за управљање пословним процесима (енгл. Business Process Management, BPM) и анализе пословних докумената (енгл. Business Document Analysis, BDA). Овај корак подразумева и моделирање препознатих процеса (коришћењем опште прихваћених методологија, нпр. UML) и њихово документовање у стандаризованој форми. Иако се ради о једном цикличном процесу, без почетка и краја, дефинисање процеса је кључна карика у ланцу; Модел B2B интеграције саобраћајних пословних система 40 Слика 8. Електронска пословна сарадња • откривање партнера (енгл. Partner Discovery). Подразумева проналажење потенцијалних партнера и испитивање сервиса које нуде, тј. описа њиховог профила (енгл. Profile Description); • договор партнера (енгл. Partner Sing-up). Након проналажења пословног партнера неопходно је договорити пословне и техничке детаље сарадње. Сваки од партнера гарантује извршавање своје улоге; • електронско подешавање (енгл. Electronic Plug-in). Након усаглашавања и његовог формалног дефинисања, из претходне фазе, партнери подешавају своје апликације за жељени тип интероперабилне комуникације; • извршавање процеса (енгл. Process Execution). Ово представља стартовање система партнера у сагласности са конфигурацијама дефинисаним у претходном степену. То подразмева размену електронских докумената, у цуљу реализације дефинисаног пословног процеса; • управљање процесом (енгл. Proces Management). За сво време валидности договора међу пословним пртнерима врши се надгледање (енгл. Monitoring) да ли се извршење задатака обавља у складу са договором; • еволуција процеса (енгл. Process Evolution). Карактер интеракција међу партерима обично се договара за одређени временски период или за одређени број трансакција. Након тога процеси моги бити редефинисани, па самим тим и договор мора бити поновно успоствљен. На овај начин пословни партнери могу да се прилагоде диманичним условима пословања, где прилагођавање променама представља услов опстанка. Модел B2B интеграције саобраћајних пословних система 41 2.4.7. RosettaNet RosettaNet представља непрофитабилни конзорцијум основан 1998. године са више од 400 водећих светских компанија, произвођача и потрошача, који су дефинисали стандардне поруке у XML формату за размену података и процеса у оквиру електронског пословања. Конзорцијум RosettaNet дефинисао је пословни протокол помоћу којег његови учесници превазилазе језичке и друге баријере и активно учествују у B2B е-пословању. Стандарди намењени трансакцијама у глобалном ланцу снабдевања према принципима колаборативног пословања доступни су свим потенцијалним корисницима. Садржаји RosettaNet-а су: • Partner Interface Processes (PIPs) садржи пословне документе, речник и пословни процес дат описом кореографије дијалога. Највећа вредност RosettaNet је општа сагласност око тога „који процеси шта и где раде”; • RosettaNet Implementation Framework (RNIF) садржи протоколе преноса намењене брзој примени RosettaNet стандарда; • Business and Technical Dictionaries састоје се из јединствених термина за све појмове који се појављују у порукама; • RosettaNet Business Message је основна јединица преноса. 2.4.8. BizTalk Server BizTalk Server је скуп алата који омогућава размену података између рачунарских система. То је колекција компонената која омогућава да се изврши један посао - интеграција. Microsoft је креирао скуп различитих адаптера, који представљају специфичне интерфејсе апликација из једне или више различитих организација према BizTalk messaging engine (слика 9). Слика 9. BizTalk Server адаптери Модел B2B интеграције саобраћајних пословних система 42 Уз помоћ BizTalk Server-а организације могу да комуницирају са широким спектром различитих платформи и апликација. Microsoft BizTalk Server користи технологију адаптера за конектовање на разнородне ентитете као и за интегрисање података, догађаја, процеса и сервиса. Ентитет може бити апликација, сектор, чак и друга организација, са којом је потребно разменити податке. 2.4.9. Windows Communication Foundation Framework Windows Communication Foundation Framework (WCF Framework) је моћан радни оквир за дизајнирање, развој, хостовање (смештање) и коришћење сервиса. Будући да су развијени на Microsoft-овој платформи, WCF сервиси могу да користе стандардне технологије да би обезбедили широк спектар способности које се тичу: сигурности, трансакција и комуникације [145]. Пре него што су се појавили WCF сервиси .NET програмери, који су развијали дистрибуиране апликације, морали су да бирају између комуникационих шема као што су: ASP.NET Web сервиси, .NET remoting и MSMQ (Microsoft Message Queuing). Тај избор имплицирао је избор начина на који су компоненте биле пројектоване, изграђене, развијене и коришћене. Ако је изабрао ASP.NET Web сервисе, програмер се истовремено определио и за XML формат порука и помирио са ограничењима HTTP транспортног протокола. Ако је избор пао на .NET remoting, програмер може да рачуна на ефикасно процесуирање порука, али истовремено мора да се помири са чињеницом да клијенти сервиса могу бити искључиво .NET клијенти. MSMQ је чудесан, када су у питању дисконектоване апликације, али његовим избором елиминише се било каква могућност успостављања синхроне, захтев-одговор (енгл. request-response) конверзације са клијентском апликацијом. У основи, WCF је радни оквир за слање порука између система. То није дистрибуирани, на компонентана заснован радни оквир, попут remoting-а или DCOM-а (Distributed Component Object Model). Када се користе WCF сервиси размењују се поруке захтева (енгл. request message) и (ако је применљиво) поруке одговора (енгл. response message). Циљ WCF радног оквира је да обједини ових неколико технологија и обезбеди јединствену, у односу на транспорт неутралну, развојну парадигму са заједничким погледом на питања сигурности, трансакција и обраде изузетака [148]. Сервиси се имплементирају независно од стратегије везане за комуникациони протокол. Ово је заиста револуционаран концепт који дизајнерима сервиса обезбеђује велику флексибилност. Уместо изградње сервиса са чврсто повезаним и крутим endpoint-има, код којих промене нису добродошле, омогућено је пројектовање флексибилних сервиса, оспособљених да подрже широк спектар садашњих и будућих корисника. Endpoint-и у WCF дефинисани су на бази ABC акронима, који се лако памти. Слово A односи се на адресирање (енгл. addressing), које упућује на актуелну URL (Uniform Resource Locator) адресу сервиса. Слово B односи се на повезивање (енгл. binding), које описује како се комуницира са сервисом. Слово C односи се на уговор (енгл. contract), који дефинише операције и податке које сервис излаже. Модел B2B интеграције саобраћајних пословних система 43 WCF је кључни део BizTalk Server 2009 платформе, на коме је базирана Microsoft- ова сервисно-оријентисана стратегија. Циљ WCF радног оквира је да обезбеди јединствену, у односу на транспорт неутралну, развојну парадигму са заједничким погледом на питања сигурности, трансакција и обраде изузетака. WCF радни оквир омогућава креирање, хостовање и коришћење WCF сервиса. Користећи технологију адаптера, WCF сервиси могу да остваре комуникацију са различитим платформама, изворима и форматима података. Важно питање је: како WCF сервисе учинити доступним корисницима? Сервиси се могу хостовати на различитим местима, укључујући [30]: • Self-hosting: може се креирати .NET апликација као нпр. Windows Form или Console application која ће играти улогу домаћина за сервис. Овако хостовани сервиси могу користити било које од доступних WCF везивања. Међутим self-hosted сервисима понуђена је најсиромашнија инфраструктура за хостовање; • Windows Service: може се направити Windows Service који ће хостовати WCF сервис на много успешнији начин. Овај начин хостовања сервиса такође подржава читав комплет WCF везивања. Ово је бољи начин од ручног креирања домаћина сервиса, због тога што се путем Windows Service окружења добија виши степен управљања, подршка за опорављање у случају неуспешног извршења, аутоматско стартовање, и специфичан Windows идентитет; • IIS (Internet Information Services): у Windows Server 2003 окружењу, могу се сервисирати WCF сервиси који имају HTTP и HTTP/S endpoint-е; • Главно окружење за хостовање WCF сервиса је IIS 7.0, поред Windows Process Activation Service (WAS), које нуди Windows Server 2008 и Windows Vista. Уз помоћ IIS 7.0 могу се хостовати не само сервиси који се ослањају на HTTP комуникацију, већ и сервиси који се ослањају на остале WCF протоколе (TCP, MSMQ, Pipes). На тај начин стиче се утисак о интегрисаном IIS окружењу без обзира на транспортни протокол. Ово је одличан начин да се дође до бенефита које пружа Web сервер (рециклажа процеса, праћење рада, итд.) за сервисе који нису ослоњени на HTTP протокол; • Microsoft је реализовао сет IIS сервер проширења, названих Dublin, што представља „IIS+WAS”. То би требало да буде идеално окружење за хостовање WCF сервиса у будућности. Патерн размене порука (енгл. Message Exchange Pattern) дефинише правац и тајминг размене података између клијента и сервиса. Стандардни патерни размене порука које подржавају WCF сервиси су: • захтев/одговор (енгл. Request/Response) патерн размене порука. Ово је вероватно најчешће коришћен патерн. Када сервис користи овај патерн, корисник сервиса у ствари извршава позив удаљене процедуре (енгл. Remote Procedure Call), приступа функционалностима удаљеног сервиса, и блокиран је до истека одређеног времена, или док сервис не пошаље захтевани одговор (слика 10). Модел B2B интеграције саобраћајних пословних система 44 Слика 10. Request/Response патерн размене порука између сервиса и клијента • једносмерни (енгл. One-way) патерн размене порука. Ово је патерн код којег се поруке шаљу у једном смеру и асинхроно, у односу на примаоца који их очекује. Ова врста комуникације сервиса је најмоћнији начин да се изграде апликације вођене догађајима (енгл. Event-driven Applications). Осим тога, овај патерн не подразумева блокирање клијента, након позива сервиса (слика 11). Интерфејс one-way сервиса може да пошаље поруку на једну дестинацију (point-to-point решење), на дефинисану листу примаоца (multi- cast решење), а може да буде и broadcast (publish/subscribe) решење. Једносмерни патерн одличан је начин за остваривање комуникације у сценаријима где пошиљаоц и примаоц не морају истовремено бити on-line или активни. Сви BizTalk WCF адаптери подржавају one-way патерн, једино је за WCF-NetMsmq адаптер овај патерн обавезан. Слика 11. One-way патерн размене порука између сервиса и клијента • захтев/одзив (енгл. Request/Callback) патерн размене порука. Постоје случајеви у којима корисник сервиса жели бенефите неблокирајућег асинхроног позивања сервиса, али такође жели актуелне податке у одговору сервиса (слика 12). У таквим случајевима callback патерн најбоље ће задовољити потребе корисника сервиса. У тој ситуацији позиваоц сервиса понаша се истовремено и као понуђач и као корисник сервиса. Позиваоц мора бити способан да шаље поруке, али и да хостује један endpoint на коме Модел B2B интеграције саобраћајних пословних система 45 ће примати одговоре које шаље сервис. Може се констатовати да је ово у ствари један асинхрони request/response патерн. Слика 12. Request/Callback патерн размене порука између сервиса и клијента • објављивање/претплата (енгл. Publish/Subscribe) патерн размене порука. Овај патерн размене порука је специјална врста one-way патерна. Између онога ко објављује податке и онога ко се претплатио на податке је веза типа један према више. Подаци се објављују за сервис на асинхрони начин, без очекивања директног одговора (слика 13). Слика 13. Publish/Subscribe патерн размене порука између сервиса и клијента 2.5. Семантичка интероперабилност Концепт семантичког Web-а увео је Tim Berners-Lee – креатор садашњег Web-а [13]. Да би се машинама омогућило да могу семантички да интерпретирају податке, потребно је одвојити приказ од садржаја [96]. У том циљу предлаже се коришћење неких од техника вештачке интелигенције за представљање знања, као и широк спектар стандарда на којима се базира Семантички Web [12]. У првој фази свог развоја Web је био заснован на коришћењу HTML-а кога су чиниле искључиво статички креиране странице. Међутим, да би се повећало искоришћење Web-а као би се, на пример, могле директно користити базе података или динамички генерисати Web садржаји, на Web-у су почели да се Модел B2B интеграције саобраћајних пословних система 46 користе различити скрипт језици који су Web проширили са овим могућностима. Примери таквих језика су: Common Gateway Interface (CGI), Active Server Pages (ASP), Java Server Pages (JSP) итд. Визија семантичког Web-а претпоставља да ће подаци лоцирани било где на Web-у бити доступни и разумљиви, како људима, тако и машинама [64]. Семантички Web представља еволутивни информационо дефинисани концепт [4]. Семантички Web је будућа фаза развоја Web-а која треба да омогући превазилажење проблема који су идентификовани на данашњем Web-у [150]. Да би се постигла семантичка интероперабилност електронског пословања, обе стране морају да поштују референтни модел за размену информација. Потребно је недвосмислено дефинисати захтевани садржај размењених информација. Скуп послатих информација, у погледу садржаја, мора бити једнозначно пресликан у скуп примљених информација. 2.5.1. Појам и дефиниције За два система каже се да су семантички интероперабилни ако један другом могу да прослеђују упите, потенцијално кроз серију мапирања шема података [42]. Семантичка интероперабилност омогућава да два или више рачунарских система, размењују информације и да аутоматски, смисаоно и прецизно, тумаче и препознају размењене информације, а са циљем да испуне захтеве, дефинисане од стране крајњих корисника [62]. Да би омогућили семантичку интероперабилност агенти, сервиси, апликације имају потребу да деле једно исто, заједничко, разумевање речника или да креирају кореспонденцију или мапирања између њихових различитих речника [45]. Један од пројектантских циљева RDF-a (Resource Description Framework, RDF) и OWL-a (Web Ontology Language, OWL) је да омогући начин да се специфицирају та мапирања. Крупни кораци направљени су у последњим деценијама на пољу унапређења интероперабилности на физичком и синтаксном нивоу. Токови података успешно се предају из једног система другом систему, међутим не постоји значење повезано са подацима. Ова ситуација аналогна је успешној достави шифроване поруке, која је шифрована непознатим скриптом. Циљ семантичке интероперабилности је да омогући сарадњу две апликације које нису иницијално развијене за ту намену [133]. При том треба омогућити сарадњу без захтева да се мењају апликације или постојећа организација података. Семантичка интероперабилност, у ширем смислу, тиче се интероперабилности процеса и информација [174]. Интероперабилност информација је сигурно предуслов за интероперабилност процеса. Главна могућност састоји се у способности импортовања, дељења и вишеструке употребе јавних онтологија (у целости или делимично) и способности изражавања логичке еквивалентности и других веза између концепата, својстава и индивидуа у различитим онтологијама. Најважнија слабост је недостатак подршке за процедуралне функције (нпр. аритметичке, знаковне), које су потребне за мапирање између више онтологија из реалног света. Модел B2B интеграције саобраћајних пословних система 47 2.5.2. Семантичко моделирање Модел података је интелектуални алат за дефинисање модела система, за приказивање објеката система, њихових атрибута и дозвољених вредности, међусобних веза објеката и динамике система [123]. Семантички модел података је концептуални модел података који укључује семантичке информације [74]. То значи да модел описује значење његових инстанци (примерака). Семантички модел података је апстракција која дефинише на који начин су складиштени симболи (инстанце података) у вези са реалним светом. Он омогућава кориснику да одговори на питање шта се дешава у моделираном систему, на најприроднији начин. Семантичко моделирање је представљање значења података моделом података. Основни појмови семантичког моделирања: • концепти: − ентитет, − својство (атрибут), − односи међу ентитетима/поступци: → асоцијација/агрегација, → подтип/специјализација, → надтип/генерализација, • операције и правила интегритета, • оквир за логичко пројектовање. У процесу пројектовања информационих система, до данашњих дана, користио се велики број модела података. Најширу употребу доживели су: релациони, хијерархијски и графовски модел података (слика 14). а) релациони модел б) хијерархијски модел ц) графовски модел Слика 14. Најзаступљенији модели података Модел B2B интеграције саобраћајних пословних система 48 Од свих модела података једино графовски модел подржава семантику, тј. значење података (табела 2). Стога, избор модела података значајно може утицати на каснији избор модела за остваривање семантичке интероперабилности информационих система. Табела 2. Компарација најзаступљенијих модела података Модел Пример формата Подаци Метаподаци Идентифи- кација Синтакса упита Семантика Објектни .NET CLR Object Seriali- zation Вредно- сти својстава објеката Имена објеката и својстава нпр. име датотеке LINQ Није подржана Релациони MS SQL, Oracle, MySQL Вредно- сти ћелија табела Дефиниције колона табеле Вредност поља које представља примарни кључ SQL Није подржана Хијера- рхијски XML Таг/ атрибут вредно- сти XSD/DTD Вредост јединстве- ног атрибута који има улогу кључа XPath Није подржана Графовски RDF/XML Turtle RDF RDFS/OWL URI SPARQL Подржана, RDFS и OWL 2.5.3. Онтологије Суштинска природа онтологије је да препознаје и описује оно што постоји у реалном свету. Генерално, онтологије се дефинишу за поједине домене (отуда „онтологије домена”), пошто је онтологија корисна и подесна ако је фокусирана на специфичан сектор реалности. Онтологије истакнуто фигуришу у појављивању семантичког Web-а, као начин представљања семантике докумената и омогућавања да семантика буде коришћена од стране Web апликација и интелигентних агената. Онтологије служе да стандардизују и обезбеде интерпретације садржаја Web-а. Да би настао садржај разумљив машинама, Web стране морају имати семантичко тумачење, тј. описе који користе терминологију коју дефинише једна или више онтологија. Модел B2B интеграције саобраћајних пословних система 49 2.5.3.1. Појам и дефиниције Онтологија је „формална, експлицитна спецификација дељене концептуализације” [71]. „Концептуализација” се односи на апстрактни модел неког феномена у свету који идентификује релевантне концепте тог феномена. „Експлицитна” значи да су типови концепата који се користе и ограничења њихове употребе експлицитно дефинисани. „Формална” се односи на чињеницу да онтологија мора бити разумљива за рачунаре. „Дељена” одражава мишљење да онтологија обухвата знање око кога постоји општа сагласност, које није ограничено на неког појединца, већ је прихваћено од групе. Класичне дефиниције онтологије: • спецификација неке концептуализације, • експлицитна спецификација неке предметне области, • формална и декларативна репрезентација неке предметне области, • базна структура или арматура око које се може изградити темељ знања. Појам онтологије у инжењерству односи се на представљање знања [152]. Онтологија одређује термине који се користе да опишу и представе једну област знања. Онтологије користе људи, базе података и апликације које имају потребу да деле информације из једног домена. Домен је специфична предметна област или научна област, као медицина, производни алати, непокретна имовина, поправка аутомобила, финансијски менаџмент, итд.) Онтологије укључују дефиниције основних концепата домена и њихових међусобних веза, које могу користити рачунари. Оне шифрују знање једног домена и такође знање које обухвата домене. На тај начин оне знање чине вишеструко корисним. Реч онтологија користи се да опише појмове са различитим степеном структуре. Тај радијус је од једноставних таксономија (као што је Yahoo хијерархија), до шема метаподатака (као што је Dublin Core) и логичких теорија. Семантички Web има потребу за онтологијама са значајним степеном структуираности. Он има потребу за спецификацијом описа следећих типова концепата: • класе (генерални појмови) у многим областима интересовања, • везе које могу постојати између појмова, • својства (или атрибути) које ти појмови могу имати. Онтологије се обично изражавају на језику базираном на логици, тако да детаљне, прецизне, садржајне, звучне, значајне особености, могу бити изграђене на бази класа, својстава и веза. Неки онтолошки алати могу вршити аутоматско резоновање коришћењем онтологија, па овако обезбеђују напредне сервисе за интелигентне апликације, као што су: концептуално/семантичко претраживање и враћање, софтверски агенти, подршка одлучивању, разумевање говорног и природног језика, управљање знањем, интелигентне базе података, и електронска трговина. Модел B2B интеграције саобраћајних пословних система 50 Онтологија треба да обезбеди: • Речник (или називе) који се односи на термине из те предметне области; • Логичке изразе који описују: − шта термини представљају, − како су међусобно повезани, − како се могу или не могу међусобно повезати, − правила комбиновања термина и веза за дефинисање проширења речника, − семантичку независност од читаоца и контекста, − заједничко разумевање тема које може бити веза између корисника и апликација. 2.5.3.2. Улоге онтологија Онтологије имају доминантну улогу на различитим пољима, чији број расте. Најзначајније примене онтологија су у следећим сферама [41, 48]: • представљање знања израженог природним језицима, • аутоматско проналажење знања у научним текстовима, • лексичке онтологије, међу којима је најпопуларнијa и највећа WordNet, • враћање семантичких информација из складишта података [66, 67], • дељење и вишеструка употреба знања [46, 117], • интегрисање информација из хетерогених извора [19], • опис концепата и веза који могу постојати у једној Интернет апликацији. Под описом се подразумева формална спецификација налик програму. Улога онтологија у архитектури семантичког Web-a: • да омогуће интелигентне сервисе: − посреднике информација (енгл. information brokers) [146], − претраживачке агенте (енгл. search agents) [20, 73], − филтере информација (енгл. information filters), − интелигентну интеграцију информација (енгл. intelligent information integration) [40, 172], − управљање знањем (енгл. knowledge management); • да успоставе напредне нивое интероперабилности на Web-u: − синтаксну интероперабилност, тј. вишеструку употребљивост добијену рашчлањавањем података, − семантичку интероперабилност, тј. мапирање између термина унутар података које захтева анализу садржаја [127, 97, 126]; • да додају напредан слој репрезентације и закључка на врх садашњих Web слојева; Модел B2B интеграције саобраћајних пословних система 51 • да омогуће обраду, дељење и вишеструку употребу знања између апликација, засновану на Web-у [99]. Случајеви коришћења онтологија: • интегрисање постојећих OWL онтологија. Рецимо да инжењер има две посебне онтологије које би требало интегрисати. Он у великој мери интуитивно разуме значење речника обе онтологије, зато што су обе онтологије аксиоматизоване, или просто зато што је фамилијаран са речником специфичног домена, обе онтологије. Његов главни посао је да омогући експлицитно мапирање између две онтологије; • интероперабилност апликација - превођење података изражених коришћењем две или више различитих онтологија. Један пројектант софтвера има потребу да пошаље податке из једне апликације (изражене речником једне онтологије) у другу апликацију. Подаци морају бити конвертовани како би се користио речник апликације која прима податке [68]. Ово је слично првом случају коришћења, у ком се претпоставља да постоји добро разумевање значења обе онтологије, и главни посао је специфицирање мапирања [154, 176]; • изградња нове OWL онтологије поновним коришћењем постојећих онтологија [75]. Рецимо да инжењер жели да изгради нову онтологију која би послужила као позадина за управљање неким аспектима удруженог знања (нпр. производни процес његове компаније). Постоје различити онтолошки ресурси који се могу искористити, и он жели да их користи највише што је могуће; • дељење постојећих онтологија на Web-у. Инжењер има складиште легалних онтологија написаних у различитим језицима за представљање, као што су Classic, Ontolingua, KIF, FLogic или други језици за представљање знања. Он жели да буде у могућности да дели онтологије на Web-у. 2.5.3.3. Врсте онтологија Постоје две главне класе онтологија. Прву класу чине онтологије које служе за експлицитно снимање „статичког знања” о домену. Другу класу онтологија чине онтологије које пружају могућност резоновања (закључивања) о доменском знању (знање које се тиче решавања одређеног проблема). Унутар прве класе онтологија, према степену општости, разликујемо три типа онтологија: • доменске онтологије - представљају знање релевантно за одређени домен, нпр. медицински, механички, саобраћајни, итд; • генеричке онтологије - могу се примењивати у више домена. Нпр. онтологија која представља знање у вези са мерењима може се примењивати у разним техничким доменима. Ова врста онтологија назива се joш и „super theory” или „core technology”; • репрезентативне онтологије - формулишу опште ентитете репрезентације, не дефинишући шта треба да буде представљено. Веома познат пример ове врсте онтологија је Frame Ontology. Модел B2B интеграције саобраћајних пословних система 52 Унутар класе онтологија које представњају знање у вези са решавањем одређеног проблема, издвајају се два типа онтологија: • онтологије задатака - обезбеђују термине карактеристичне за појединачне, специфичне задатке; • онтологије метода - обезбеђују термине карактеристичне за појединачне, специфичне методе решавања проблема. Постоји још једна класа онтологија - онтологије апликација. Онтологија апликације је комбинација доменске онтологије и онтологије метода. Она садржи сво знање - статичко и знање у вези са решењем одређеног проблема, које је неопходно за моделирање одређеног домена. 2.5.3.4. Постојеће методе креирања онтологија Постоје два основна начина за креирање онтологија. Први, и најочигледнији начин, је креирање онтологије од почетка, тј. креирање класа, релација, инстанци, итд. Интересантни су примери полу-аутоматског креирања онтологија. Код таквог приступа онтологије се креирају на основу софтверске документације и шема података доменских база података [100, 141, 162]. Други начин креирања онтологија састоји се у комбиновању доступних, постојећих онтологија. Комбиновање постојећих онтологија може се вршити на неколико начина: • инклузија (укључивање) једне онтологије у другу. Резултат је да се класе, релације и аксиоми обе онтологије налазе у једној онтологији. Појавиће се, вероватно, конфликти имена, и тај проблем се мора решавати, било ручно или употребом неког алата; • рестрикција - једна онтологија се примењује на подскупу оригинално предвиђеног скупа; • прецизирање - опште онтологије понекада захтевају прецизирање, да би биле примењиве за специфичне сврхе. Без обзира на начин на који се креира онтологија неколико принципа пројектовања би требало поштовати, како би се оптимизовала њихова употреба: • модуларност – мале јединице олакшавају разумевање и вишеструку употребљивост; • интерна кохерентност – сопствена конзистентност концептуалне структуре система; • проширивост – онтологије се често обогаћују додавањем нових концепата или класа, што представља неопходну еволуцију. Олакшавање овог процеса требало би да буде један од циљева приликом пројектовања онтологија; • дефиниције ослоњене на природне категорије – олакшава разумевање и чини их прихватљивијим за кориснике; • минималне будуће обавезе према онтологијама. Модел B2B интеграције саобраћајних пословних система 53 2.5.3.5. Стандарди, језици и алати за креирање онтологија RDF (Resource Description Framework) је стандардан начин за спецификацију података о неком Web ресурсу. Намена RDFS (Resource Description Framework Schema) је: • да обезбеди XML речник за: − изражавање класа, подкласа и њихових веза, − дефинисање својстава и повезивање истих са класама; • да омогући креирање таксономија. RDFS олакшава закључивање на основу података и омогућава повећање претраживања. Међутим, изражајност RDF и RDF Schema веома је ограничена: RDF је грубо лимитиран на бинарно засноване предикате, а RDF Schema је лимитирана на хијерархију подкласа и хијерархију својстава, са областима вредности и доменима за то својство. Међутим, Web Ontology Working Group конзорцијума W3C, идентификовала је више карактеристика случајева употребе онтологија на Web-у, које захтевају много више изражајности него што је RDF и RDF Schema имају. Мноштво истраживачких група у Америци и у Европи већ је идентификовало потребу за много моћнијим језиком за моделовање онтологија. Из те потребе настао је језик који има намеру да буде стандардизован и широко прихваћен језик онтологија семантичког Web-a - Web Ontology Language. Web Ontology Language (OWL) је стандардни језик онтологија чији је творац W3C (World Wide Web Consortium). OWL је изграђен на бази RDF Schema, тј. проширује RDFS. Сврха OWL-а идентична је сврси RDF Schema, а састоји се у томе да обезбеди речник за дефинисање класа, својстава и њихових узајамних веза. Корист од OWL-а је да омогући много виши степен закључивања од оног који нам је дала RDF Schema. RDF Schema омогућава изражавање веома рудиментираних веза и ограничена је у способности закључивања. OWL и RDF Schema омогућавају рачунарски обрадиву семантику (machine-processable semantics). Кључни проблем у постизању интероперабилности је способност препознавања два податка који говоре о истој ствари, чак иако је коришћена различита терминологија. OWL се може користити за премошћавање терминолошког јаза. OWL обезбеђује својство (енгл. property) owl:sameIndividualAs које указује на то да су два ресурса у ствари исто. Генерално својство OWL-а је да један ресурс - субјекат има тачно једну вредност за одређено својство (слика 15). OWL класе тумаче се као скупови који садрже индивидуе. Оне су описане коришћењем формалних описа који прецизно формулишу услове за чланство у класи. Слика 15. OWL ресурс има тачно једну вредност одређеног својства Property Resource (value) Resource (subject) 1 Модел B2B интеграције саобраћајних пословних система 54 У RDF Schema rdf:Property користи се за: • повезивање ресурса (Resource) са другим ресурсом, нпр. својство Mesto rođenja повезује Osobu са Lokacijom. • повезивање ресурса са rdfs:Literal или типом податка, нпр. својство Žižna daljina повезује Objektiv са xsd:string. OWL установљава две врсте својстава, која према томе морају бити дефинисана одвојено: • OWL:ObjectProperty користи се за повезивање једног ресурса са другим ресурсом (слика16), Слика 16. OWL ObjectProperty повезује један ресурс са другим ресурсом • OWL:DatatypeProperty користи се за повезивање ресурса са rdfs:Literal или неким XML Schema уграђеним типом података (слика 17). Слика 17. OWL DatatypeProperty повезује ресурс са rdfs:Literal или неким XML Schema уграђеним типом података. RDF Schema обезбеђује три начина да се окарактерише својство: • range: користи се да одреди опсег вредности које може имати својство. • domain: користи се да се повеже својство са класом. • subPropertyOf: користи се да се специјализује својство. OWL користи: rdfs:range, rdfs:domain и rdfs:subPropertyOf, али обезбеђује и додатне начине да окарактерише својство. 2.5.4. Приступи семантичкој интероперабилности базирани на онтологијама Процес кооперације и усаглашавања базиран је на идеји да постоји заједнички поглед на свет (домен пословања), који може бити коришћен као референтна тачка [24]. Ако заједничко разумевање недостаје у комуникацији људи, реализација интероперабилности неминовно неће успети, без обзира на то која технологија ће се користити. Тај заједнички поглед представља се доменском онтологијом. Приступ семантичкој интероперабилности заснован на коришћењу онтологија подразумева да се семантичка интероперабилност остварује унутар заједничког хармонизованог простора сарадње (слика 18), доступног кроз један Resource ObjectProperty Resource DatatypeProperty Resource Value Модел B2B интеграције саобраћајних пословних система 55 Специфичан Семантички Пролаз – ССП (енгл. Custom Semantic Gateway, CSG) за сваког партнера. ССП развија се почевши од Локалне Концептуалне Шеме – ЛКШ (енгл. Local Conceptual Schema, LCS) и заједничке, дељене онтологије. Слика 18. Хармонизација простора сарадње Примарни циљ онтологије је да обезбеди јединствену семантичку референцу за сваку апликацију која пожели да изложи интерфејс (који упућује на ЛКШ), за експортовање и импортовање информација. У суштини, сваки део информације у ЛКШ биће протумачен коришћењем онтолошког садржаја и језика семантичког посредовања и интероперабилности апликација (Semantic Mediation and Application Interoperability Language, SMAIL). За дати ентитет апликације (представљен као структура података у ЛКШ), процес тумачења састоји се из идентификовања елемената представљених у референтној онтологији; онда се значење структуре података ЛКШ дефинише компоновањем SMAIL израза, који користе те елементе онтологије. Ти изрази користе се за генерисање правила помирења, на проширеном нивоу, која суштински представљају мапирање између локлних концептуалних структура и репрезентације међусобне размене. Дакле, имамо један одређени скуп правила помирења за сваку апликацију укључену у простор хармонизације. Семантичко тумачење добија се писањем скупа израза, који имају заглавље са леве стране, представљено лабелом (име или путања) ставке локалне информације из ЛКШ-а, тело са десне стране, које представља значење изражено у терминима онтолошких концепата. Решење хармонизације базирано је на три истраживачке области: • онтологија, која представља заједнички, дељив поглед на домен апликације; • анализа неслагања на плану интероперабилности, проузрокованих разликама у концептуалним шемама, које се могу пронаћи у две апликације које сарађују; Простор хармонизације ЛКШ А1 ЛКШ А2 Онтологија ЛКШ А3 ССП ССП ССП Модел B2B интеграције саобраћајних пословних система 56 • семантичко тумачење, постигнуто како би представило значење локалне концептуалне шеме, изражене коришћењем концепата доступних у горе поменутој онтологији. Први кључни елемент предложеног приступа је заједничка онтологија. Онтологија се користи да дâ значење информационим структурама које једна апликација жели да размени са другом апликацијом [43]. Онтологија је базирана на дефиницији ентитета и веза. Концепти у онтологији домена могу бити организовани у складу с комплексном хијерархијском структуром, где су најопштији концепти лоцирани на врх, крећући се низбрдо срећемо специфичније али структурно сложеније концепте. На најнижем нивоу налазимо елементарне концепте, који не могу бити даље декомпоновани ни пречишћени. Ова организација даје повод да њен облик буде налик кестену (слика 19). У највишем делу (Upper Domain Ontology, UDO) имамо генеричке концепте као што су: процес, актер, догађај, циљ. У најнижем делу (Lower Domain Ontology, LDO) имамо елементарне концепте као што су: цена, адреса, трошкови, интернет адреса. Генерално, релативно је лако постићи консензус ова два дела. Сложена деоница је средњи део - онтологија апликације (енгл. Application Ontology). Овде концепти и дефиниције снажно зависе од специфичне апликације. Концепти у средњем делу (онтологија апликације) типично су конструисани компоновањем неелементарних концепата, почевши са оним дефинисаним у LDO. Онда су концепти специфични за апликацију класификовани у складу са много општијим концептима који су лоцирни у UDO. Слика 19. Онтолошки „кестен” Постоји неколико приступа у коришћењу онтологија за постизање семантичке интероперабилности: • приступ заснован на коришћењу једне онтологије - глобална дељена онтологија обезбеђује јединствено семантичко тумачење локалних шема извора података (слика 20). Глобална онтологија може бити комбинација више модуларних онтологија; Модел B2B интеграције саобраћајних пословних система 57 Слика 20. Приступ семантичкој интероперабилности заснован на коришћењу једне онтологије • приступ заснован на коришћењу више онтологија - сваки извор информација има своју локалну онтологију, које не морају обавезно да користе заједнички речник. Свака онтологија може се креирати независно од осталих, јер између онтологија постоји лабава веза. Да би се остварила интероперабилност, онтологије се морају окупити креирањем и коришћењем правила мапирања између градивних блокова онтологија (слика 21); Слика 21. Приступ семантичкој интероперабилности заснован на коришћењу више локалних онтологија • хибридни приступ - комбинује основне карактеристике претходна два приступа. Сваки извор података има сопствену онтологију, али су локалне онтологије креиране на основу глобалног дељеног речника (слика 22). На тај начин олакшано је мапирање између онтологија. Дељени речник дефинише основне термине домена, а они се користе да опишу комплексну семантику унутар локалних онтологија. Модел B2B интеграције саобраћајних пословних система 58 Слика 22. Хибридни приступ семантичкој интероперабилности заснован на коришћењу више локалних онтологија и глобалног дељеног речника Приступ заснован на коришћењу једне онтологије сувише је крут и ригидан јер су системи међусобно круто повезани унутар једне заједничке онтологије. Додавање новог извора података захтева значајне интервенције на постојећој онтологији. Приступи засновани на коришћењу више онтологија значајно су флексибилнији, поготову у ситуацијама када се додаје нови извор података. Код ових приступа неопходно је извршити мапирање између две онтологије [51]. Сценарио Web портала је карактеристичан пример код кога је пожењно користити хибридни приступ, и вршити мапирања између онтологија. У [3] демонстриран је један пример креирања онтологије трансформацијом XML шеме извора података. Посебно значајну улогу онтологије имају у семантичком означавању Web сервиса. У [115] дати су бројни модели и патерни семантичке интеграције система који имају сервисно-оријентисану архитектуру. 2.5.5. Модели семантичке интероперабилности СОА технологије и стандарди обезбеђују пројектантима и програмерима широк спектар могућности и приступа, када је у питању постизање семантичке интероперабилностги. Избор одређеног приступа зависи од пословног окружења у коме се имплементира СОА. Модели семантичке интероперабилности класификују се према следећим критеријумима [171]: • начин мапирања шема података: − свака шема се мапира у све друге шеме, − све шеме се мапирају у јединствену шему; • окружење у коме ће се извршавати интеграциона логика: Модел B2B интеграције саобраћајних пословних система 59 − централизовано, у јединственом чвору – интегратору, − дистрибуирано (децентрализовано), у свим међусобно равноправним чворовима. Комбиновањем свих могућих избора, према два наведена критеријума, добијамо четири могућа модела семантичке интероперабилности: Централизовани „свако-према-сваком” модел Код централизованог моделa „свако-према-сваком”, сервиси се интерпретирају и мапирају у друге сервисе, без коришћења онтологија. Функцију семантичке интеграције обезбеђује посебна компонента, која се назива интегратор (слика 23). Интегратор креира модел, за сваки од укључених сервиса, на основу сопствене интерпретације описа сервиса. Интегрисани сервиси, у овом случају инстанце, најчешће су атомични, независни и самостални. Да би се омогућила међусобна комуникација између интегрисаних сервиса, предуслов је да постоји међусобна усаглашеност. У супротном, могуће семантичке грешке откривају се тек у фази извршавања. Модел интегрисаних сервиса погодан је за примену у затвореном окружењу. Онтологије нису укључене у модел. У односу на друге моделе за семантичку интероперабилност, модел „свако-према-сваком” је скупљи и непоузданији. Слика 23. Централизовани „свако-према-сваком” модел семантичке интероперабилности Централизовани „сви-према-једном” модел Централизовани модел сервиса „сви-према-једном”, мапира улазно/излазне податке у једну јединствену онтологију, којом управља специјализована апликација, или сервис (компонента интегратор на слици 24). Интегратор креира Модел B2B интеграције саобраћајних пословних система 60 модел за сваки сервис посебно, на основу своје интерпретације расположивих описа сервиса, на исти начин, као и у случају модела „свако-према-сваком”. Мапирање обавља интегратор на основу јединствене онтологије. Дизајнери интегратора задужени су за постављање семантичког слоја, па конзистентност интегратора зависи од њиховог познавања система. Провајдери, кроз имплементацију сервиса, обезбеђују своје сопствене моделе и нису укључени у развој интегратора. Централизовани модел „сви-према-једном” погодан је за примену у динамичким окружењима, на пример, у случају позивања Web сервиса у B2B сценаријима. Примена модела није једноставна, јер захтева пажљиво проучавање односа између: изражајности језика за онтологије, шема за мапирање и интеграционих алгоритама. Значајна особина модела „сви-према-једном” је могућност да се, укључењем нових компоненти и извршењем њиховог мапирања, прошири пословни модел. Слика 24. Централизовани „сви-према-једном” модел семантичке интероперабилности Децентрализовани „свако-према-сваком” модел Интеграциона логика децентрализованог модела „свако-према-сваком” је дистрибуирана и не заснива се на заједничким онтологијама (слика 25). Модел је карактеристичан за слабо повезана окружења. Сврстава се у „peer-to-peer” системе. Семантике у систему су дистрибуиране и стриктно међусобно изоловане. Одговорност сваког од учесника је да изврши мапирање према осталим учесницима, које жели да укључи. Услед непостојања централног модела, у циљу постизања интероперабилности, потребно је да се у сваком чвору обезбеди мапирање укључених сервиса. Модел B2B интеграције саобраћајних пословних система 61 Слика 25. Децентрализовани „свако-према-сваком” модел семантичке интероперабилности Децентрализовани „сви-према-једном” модел Правила мапирања учесника, у случају децентрализованог „сви-према-једном” модела, обезбеђују се на основу модела онтологије (слика 26). Слика 26. Децентрализовани „сви-према-једном” модел семантичке интероперабилности Модел B2B интеграције саобраћајних пословних система 62 Модел онтологије укључује семантику и концепте свих укључених компоненти, а интеграциона логика се извршава дистрибуирано. У овом моделу компоненте су дистрибуиране, а развој и проширење онтологија мора се, на неки начин, обавити централизовано. 2.6. Интероперабилност у саобраћају и транспорту У општем случају интероперабилност је способност неких производа, система или процеса да могу заједнички да функционишу у реализацији одређеног заједничког задатка. У саобраћају и транспорту неопходна је интероперабилност процеса информационо-комуникационих система са процесима кретања физичких добара у простору и времену, за које су иманентни логистички процеси. У области пројектовања информационих система (ИС) заснованих на Web-у интероперабилност ИС избила је у први план, како би хетерогеним системима омогућила дељење података и сервиса [122]. Web сервиси, који су на располагању пословним системима, могу да буду коришћени од стране било кога, са било које локације, у било које време и на било ком типу платформе [107]. Саобраћајни и транспортни системи су хетерогени системи који морају међусобно да деле информације. Стога је неопходно да се постигне интероперабилност њихових ИС. 2.6.1. Задаци и циљеви интероперабилности саобраћајно-транспортних пословних система У данашње време, честа је појава немогућности остваривања комуникације између шпедитера, транспортера, царинске службе, наручиоца транспорта и других коминтената. Узрок овакве немогућности треба тражити у неразвијености интероперабилних комуникационих система, као и неспособности да комуницирају и размењују податке, информације, робу, новац и остале ресурсе било кад и било где и у било ком облику. У реализацији непредвиђених догађаја, често се саобраћајно-транспортне организације ослањају на сопствене комуникационе системе. Док су самостални ЛИКС-ови (Логистички Информационо-Комуникационог Системи) ефикасни и ефективни за сопствене службе, они су често некомпатибилни са ЛИКС-овима других организација истог „подручја деловања”. Често је опрема у организацијама (која је у служби саобраћаја и транспорта) за размену информација, логистичких услуга, као и радио-комуникациона инфраструктура веома застарела (од 20 па и до 40 година). Такође, није редак случај да у саобраћајно-транспортним организацијама буде заступљена различита врста опреме за размену информација и успостављање комуникација међу њима. Одређене компаније у свом саставу имају и различите рачунарске оперативне системе (Windows, Linux, Macintoch, Unix), па се ствара немогућност интероперабилног електронског пословања међу њима. Није редак случај да информационо-комуникациони системи не могу да раде чак ни на истим фреквенцијама због различитих пратећих софтвера. Овакве потешкоће се једино могу отклонити увођењем јединствених стандарда за технологију и опрему код Модел B2B интеграције саобраћајних пословних система 63 ЛИКС-а, а развој ових стандарда мора укључити кориснички инпут и подржати развој компатибилне опреме. Организације, институције и остали нивои деловања у саобраћају и транспорту штедљиво располажу финансијским средствима за унапређење застареле опреме или куповину нове, што за последицу има одбијање партнерства и лидерства у развоју интероперабилности ових компанија и институција. Ипак, пресудан утицај на успостављање интероперабилности ЛИКС-а представља људски фактор, јер саобраћајно-транспортне организације по природи својих искустава, нерадо препуштају контролу и управљање својим ЛИКС-ом. Међутим, интероперабилност захтева координацију, кооперацију и наглашавање важности подељеног управљања, контроле, стратегије и процедура. Web странице морају омогућавати доступност садржаја свим особама присутним у процесима заступљеним у саобраћају и транспорту, јер је овим особама потребно омогућити коришћење услуге које им пружају компаније уобичајеним комуникационим каналима. Стога се захтева од саобраћајно-транспортних организација да своје интернетске странице перманентно усклађују с могућношћу коришћења. Ради поузданог рада ЛИКС-а заступљеног у секторима саобраћаја и транспорта, неопходно је да он функционише у оперативној готовости, подобности и операбилности у сваком моменту. Дизајнирањем интероперабилног система у саобраћају и транспорту мора се избегавати коришћење пуних технолошких капацитета. У непредвиђеним ситуацијама, интероперабилни систем мора располагати са довољном капацитативном резервом. Да би остварио потпуну, ефективну и ефикасну комуникацију са свим другим интерактивним корисницима комуникације, ЛИКС мора тежити ка интероперабилности јединственог система. Развојем интероперабилног система на нивоу компанија омогућава се корисницима, појединцима, органима и другим службама интензивно деловање у актуелним проблемима што у крајњој линији омогућава једноставну ефективну координацију свих других ресурса у тоталном одзиву на инцидентне ситуације и непредвидиве догађаје. Укратко, циљ интероперабилности у саобраћају и транспорту је стварање јединственог ЛИКС-а који омогућава интеграцију активности у јединствени мулти саобраћајно-транспортни систем. У овај систем се укључују мултидисциплинарне институције и остварују мултинадлежности у одзиву на критичне мултидогађаје и инциденте. Организације у саобраћају и транспорту ће своју сарадњу базирати на компактном формирању виртуелних интеракција у услугама и процесима пословања. Виртуалне интеракције ће представљати тржиште на којем ће се у будућности „окретати” изузетно велики капитал. За што лакше сналажење на њему биће нам потребна јединствена on-line приступница. Интероперабилност примењена у било ком виду саобраћаја и транспорта се уређује одговарајућим директивама и одлукама, кроз прописивање мера за техничко усклађивање система. Директиве о интероперабилности уводе опште процедуре за припрему и усвајање техничких спецификација за интероперабилност и опште прописе за процену усаглашености са информационо-комуникационим системима. Процедуре се користе у циљу Модел B2B интеграције саобраћајних пословних система 64 поједностављења интеграције саобраћајних и транспортних система, што представља предуслов за побољшање интероперабилности. Да би се интероперабилност применила у постојећим условима, неопходно је да државе (регије) које теже да постану, или су чланице Европске Уније (ЕУ), буду усаглашене око следећих ставова: • саобраћајно-транспортни системи домаћих компанија, могу успоставити јасну везу са европским стандардима или спецификацијама где је то неопходно у циљу остварења циљева из директива о интероперабилности; • државе чланице ЕУ треба да обезбеде пласман на тржиште за компоненте интероперабилности само ако дозвољавају да интероперабилност буде остварена унутар европског транспортног и саобраћајног система, уз истовремено задовољавање основних захтева; • свака држава чланица треба да дозволи пуштање у експлоатацију таквих структурних подсистема на њеној територији под условом да су пројектовани, изграђени, и инсталирани тако да задовољавају основне захтеве при интегрисању у јединствени европски систем; • државе чланице морају да обавесте надлежне органе да су одговорни за спровођење процедуре за процену усаглашености или подесности за употребу, као и за процедуру верификације прописане у директивама о интероперабилности. Потреба за хармонизацијом наших закона о интероперабилности састоји се у потреби за имплементацијом садржаја и процеса, и то посебно са становишта општег захтева, у потреби да компоненте које се уграђују у саобраћајно-транспортни систем морају да задовоље основне одлике интероперабилности стандарда и норми. 2.6.2. Законска регулатива Европске Уније која се односи на интероперабилност у саобраћају и транспорту Саобраћајну политику Европске уније (ЕУ), од последње деценије прошлог века па до данашњих дана, чине три основна дела: • део који се односи на период 1991-2000. дефинисан у Белој књизи ЕУ (енгл. White Paper on Common Transport Policy) у којој су дефинисани елементи- атрибути „новог” транспортног система ЕУ на основама „Три И” принципа (енгл. „Three I” - Interconnectivity, Intermodality, Interoperability), са циљем превазилажења непожељног „modal split”-а са доминацијом друмског саобраћаја и отварањем могућности развоја транспортног система у духу одрживог развоја, • део који се односи на период 2001-2010. дефинисан у Белој књизи: „White paper European transport policy for 2010: time to decide” [36]. • део који се односи на период од 2011. године дефинисан у Белој књизи: „White Paper: Roadmap to a Single European Transport Area – Towards a competitive and resource efficient transport system” [37]. Модел B2B интеграције саобраћајних пословних система 65 Основне тежње усмерене су ка постизању веће уравнотежености појединих начина транспорта (регулисана конкуренција, повезивање саобраћајних грана), затим ка уклањању уских грла у оквиру система (растерећење главних праваца и тешкоће финансирања) и ка постављању корисника у средиште саобраћајне политике (безбедни путеви, истина о трошковима корисника и саобраћај по мери човека). Основни циљ саобраћајне политике ЕУ је остао у основи исти у виду „гарантовања континуитета”: повећање укупне транспортне ефикасности, смањење трошкова, виша еколошка прихватљивост транспортног система. Принцип подразумева стављање услуге одређених атрибута квалитета на највиши ниво, тј. концепт система би требало да произилази из концепта услуга. Дакле, разумевање принципа не сме се сводити на само техничко-технолошки ниво, већ је достизање одређеног техничко-технолошког нивоа предуслов за понуду услуга жељеног састава и квалитета. Значење „Три И”: • Interconnectivity - повезивост мрежа, • Intermodality - међугранска повезивост, • Interoperability - унутаргранска и међугранска повезивост услуга. Процес генерисања тражње за превозом (раст друштвеног производа), праћен процесом задовољења тражње (раст транспортног рада и његова расподела) у условима класичног планирања развоја саобраћајних капацитета према начелу кретања по спирали „потребе-капацитет-потребе...”, неизбежно доводи до пораста укупног капацитета транспортног система уз пораст и укупног неискоришћеног капацитета са крајњим резултатом још неповољнијег „modal split”-а. Већ постојећи, велики еколошки проблеми би се заоштрили до недопустивих граница. Очигледно, поменути приступ, са приказаним „резултатима” не може бити основа даљег развоја. Ово су основне констатације у вези са резултатима политике развоја последњих деценија прошлог века. Саобраћајна политика ЕУ за период до 2000. није се могла темељити на „екстраполацији” уочених трендова, већ на захтевима за променама постојећих тенденција и редефинисању како циљева развоја, тако и саме филозофије развоја. Средњeрочно и дугорочно је дефинисано планско уређење инфраструктуре (систем Пан-европских интермодалних коридора) као елемента интегралног превозног пута, увођење принципа слободног приступа до ње под истим условима за све учеснике, увођење начела плаћања свих трошкова за све учеснике, унификација опреме и средстава, стандардизација квалитета услуге уз убрзано увођење телематских подсистема за подршку. То је требало да доведе до: • рационалне употребе капацитета грана и чворова саобраћајних мрежа и возних средстава, • повећања укупне ефикасности транспортног система, • исказивања и повезивања најбољих особина појединих видова превоза, • смањења негативног деловања на животну средину. Модел B2B интеграције саобраћајних пословних система 66 У Европској Унији теку два паралелна просеса: • процес стратешке композиције транспортног система (развој инфраструктуре Пан-европске мреже према наведеном „Три И” принципу) и • просес развоја стратегија употребе Пан-европског система - развој предузетништва. На основу свега претходно изреченог, може се рећи да је главна тенденција на подручју ЕУ, када је у питању дефинисање развојног концепта будућег транспортног система, стварање услова за убрзани развој интермодализма, где се под тим појмом, суштински, без обзира на „званичну” дефиницију, подразумева систематична, осмишљена употреба два или више начина превоза, са циљем повећања укупне ефикасности транспортног система те тако, утичући на промену постојећег неповољног „modal split”-а ка жељеним вредностима, умањити негативно деловање саобраћаја на животну средину. Највећа слабост садашњег транспортног система ЕУ је недостатак веза између поморског, копнено-водног и железничког транспорта. Водни транспорт је и поред благих позитивних помака још увек запостављен и поред економске и еколошке повољности (нарочито у односу на друмски превоз). Ударне тачке на путу трансформисања железнице су на подручју интероперабилности, квалитета услуга и високог стандарда безбедности. Посебан задатак који се поставља пред железницу (и друге видове саобраћаја) је развој интермодалног пружања услуга превоза у путничком и теретном превозу, чиме би се железница укључила у пројекат „Саобраћај по мери човека”. Не ради се ни о чему новом - захтева се лакоћа коришћења система превоза. Захтева се јединствена информација везана за превозни пут (а не само за вид превоза), усклађеност редова вожње у тачкама измене начина превоза, јединствена возна карта са транспарентношћу тарифа, брига - одговорност, окренутост ка кориснику... Циљеви ЕУ су: стављање корисника у средиште саобраћајне политике, смањење броја удеса и несрећа, хармонизовање казнених мера и развој безбедних и чистих технологија. Безбедност на друмовима је најзначајнији интерес корисника. Корисници морају имати право да знају шта и зашто плаћају. Систем накнада за употребу саобраћајне инфраструктуре није у потпуности дефинисан (због проблема дефинисања укупних трошкова: трошкови градње + трошкови одржавања + трошкови експлоатације + екстерни трошкови). Нехармонизоване цене горива (степен опорезивања) је такође једна од препрека у уједначавању услова функционисања унутрашњег тржишта. На подручју безбедности друмског саобраћаја Комисија је предложила: • програм активности на подручју безбедности друмског саобраћаја за период 2002-2010. године са циљем редуковања броја настрадалих за 50% на друмовима, • хармонизовање казни, путне сигнализације, степена алкохола у крви возача, Модел B2B интеграције саобраћајних пословних система 67 • развој нових технологија (електронске возачке дозволе, ограничавање брзине возила, интелигентни транспортни системи - део програма e-Europe) у контексту чега се очекује повећање безбедности свих учесника у саобраћају (путника у аутомобилима, пешака и бициклиста). Директива 80/1177/EEC - о статистичким извештајима који се односе на превоз робе железницом. Комисија мора имати на располагању доследне, временски усклађене и редовне статистичке податке о степену и развоју превоза робе железницом у земљама чланицама. Ови подаци морају бити упоредиви како између земаља тако и са подацима других врста превоза, те се морају односити на унутрашњи, међународни и транзитни саобраћај. Потребно је прикупити следеће информације с аспекта превоза робе на главним железничким мрежама: тежина робе у тонама; главне саобраћајне везе: домаћи саобраћај, међународни саобраћај, транзитни саобраћај; врста пошиљке; удаљеност у главној националој железничкој мрежи. Пропис 98/1172 EEC - о статистичким извештајима који се односе на превоз робе друмом. Комисија мора имати на располагању упоредиве, поуздане, временски усклађене, редовне и разумљиве статистичке податке о степену и развоју превоза робе друмом, превозним средствима регистрованим у Унији и степену искоришћења возила која обављају превоз. Потребно је прикупити: а) податке који се односе на возила: могућност коришћења возила за комбиновани превоз, конфигурација осовине, старост друмског превозног средства (камиона или тегљача) у годинама (од његове прве регистрације), максимална допуштена тежина, у стотинама кг, дозвољена носивост, врста превоза (јавни саобраћај или сопствене потребе), укупни пређени километри током периода посматрања: укрцани и празни, тежина возила; б) податке који се односе на путовање: врста путовања, тежина робе превезена током путовања или током сваке етапе путовања, бруто тежина у стотинама килограма, место укрцаја, место искрцаја, пређена удаљеност, тоне-километри остварени током путовања, земље пређене у транзиту, место укрцаја, ако постоји, друмског превозног средства на неку другу врсту превозног средства, место искрцаја, ако постоји, друмског превозног средства с неке друге врсте превозног средства; в) податке који се односе на робу: врста робе, тежина робе: бруто тежина у стотинама килограма, врста терета, место укрцаја робе, место искрцаја робе, пређена удаљеност. Модел B2B интеграције саобраћајних пословних система 68 Директива 80/1119/EEC - о статистичким извештајима који се односе на превоз робе унутрашњим пловним путевима Комисија мора имати на располагању доследне, временски усклађене и редовне статистичке податке о степену и развоју превоза робе унутрашњим пловним путевима у земљама чланицама. Потребно је прикупити следеће информације: тежина робе у тонама, главне саобраћајне везе: домаћи саобраћај, међународни саобраћај, транзитни саобраћај, врста робе према групама робе, националност, врста пловила према следећој номенклатури: моторни теретњак, моторни танкер, остали моторни теретњаци, тегљеница, танк-тегљеница, остале тегљенице, потискивач, танк- потискивач, остали потискивачи, остала пловила за превоз робе, за домаћи саобраћај: регионална подручја искрцаја и укрцаја у складу с географском локацијом, за међународни и транзитни саобраћај: земље искрцаја и укрцаја, удаљеност у километрима на домаћим пловним путевима. Директива 95/64/EC - о статисичким извештајима који се односе на превоз робе и путника морем: Комисија мора да има на располагању упоредиве, поуздане, временски усклађене и редовне статистичке податке о величини и развоју превоза робе и путника морем у и из Уније, између земаља чланица као и за домаћи поморски саобраћај. Потребно је прикупити следеће информације: а) информације о терету и путницима: бруто тежина робе у тонама, врста терета, опис робе, извештајна лука, смер кретања - улаз или излаз, за улаз терета - лука укрцаја, за излаз терета - лука искрцаја, број путника у поласку и одласку; б) За робу која се превози у контејнерима или Ro-Ro јединицама, треба обезбедити следеће појединости - број контејнера с теретом, број контејнера без терета, број покретних (Ro-Ro) јединица с теретом, број покретних (Ro-Ro) јединица без терета, информације о броду - број бродова, DWT или бруто волумен, земља или територија где је регистрован брод, врсте бродова, величина брода. Пропис (EC) 437/2003 - о статистичким извештајима који се односе на превоз путника, терета и поште ваздушним саобраћајем: Комисија мора имати на располагању упоредиве, доследне, временски усклађене и редовне статистичке податке о величини и развоју превоза путника, терета и поште ваздушним саобраћајем унутар ЕУ или изван ЕУ. Уредба треба да обухвати: превоз путника, терета и поште на свим комерцијалним ваздушним услугама у и из ваздушних лука ЕУ, укупна кретања авиона у ваздушним пристаништима ЕУ. Модел B2B интеграције саобраћајних пословних система 69 Директива 2001/16/EC - о интероперабилности класичног европског железничког система Интероперабилност као један од основних атрибута новог транспортног система ЕУ подразумева међугранску и унутаргранску повезивост услуга. За европске железнице интероперабилност је предуслов да се кроз непрекинуте транспортне услуге на целокупном европском простору оствари знатно већи ефекат пословања и повећа учешће железнице у подели рада на транспортном тржишту. Повећање конкурентности железнице у складу је са политиком одрживог развоја и заштите животне средине, па се интероперабилности железница у ЕУ посвећује посебна пажња стварањем неопходног правног оквира и спровођењем у пракси. Да би железнице повећале своје учешће у подели рада на транспортном тржишту, неопходни су виши ниво квалитета превозне услуге и већа економичност рада, на шта су усмерене и актуелне реформе, техничко-технолошка модернизаеија и хармонизација железница ЕУ. Изузетно значајна мера за повећање конкурентности железница јесте интероперабилност којој се у ЕУ посвећује посебна пажња, стварањем неопходног правног оквира и спровођењем у пракси. Кроз интероперабилност европских железница наставља се процес обједињавања железничких мрежа, који се почетком XX века одвијао у многим европским земљама. Интероперабилност представља наредни корак, од националних мрежа ка стварању јединствене европске железничке мреже, без техничких или оперативних ограничења. У складу са начелом хијерархије у ЕУ, интероперабилност спада у надлежност Уније. Активности које би на том плану самостално предузимале државе чланице не би могле имати ефекте као интегралан приступ проблему на нивоу ЕУ. У том контексту и директиве Европског парламента и Савета дају неопходан правни оквир, док ће специфични пројекти дати конкретнија решења одређених проблема. Међу најзначајнијим директивама ЕУ је Директива 2001/16/EC о интероперабилности класичног европског железничког система. Комерцијална експлоатација возова преко читаве трансевропске железничке мреже захтева високу компатибилност карактеристика инфраструктуре и возних средстава, као и ефективну међусобну повезаност информационих и комуникационих система различитих оператора и менаџмента инфраструктуре. Учинак, безбедност, квалитет услуге и цена зависе од те компатибилности и повезаности, која у ствари и чини интероперабилност трансевропског класичног железничког система. Директивама и осталим конкретним активностима везаним за интероперабилност за сада су обухваћене само железнице ЕУ, али и остале земље којима је у интересу да буду део европског транспортног система, требало би да их прате и постепено им прилагођавају своје системе. Директива 2001/16/EC поставља базне услове који морају бити испуњени ради постизања интероперабилности система класичне железнице за дефинисану трансевропску мрежу. Према овој директиви интероперабилност представља Модел B2B интеграције саобраћајних пословних система 70 способност трансевропског класичног железничког система да омогући безбедно и несметано кретање возова, уз остварење захтеваних перформанси пруга. Ова способност заснива се на одговарајућој регулативи, техничким и оперативним условима који морају бити испуњени ради остварења основних захтева. Према Директиви 2001/16 систем класичне железнице обухвата: структуралне подсистеме и оперативне подсистеме. Конституенти интероперабилности су елементарне компоненте или групе компонената, подскупови или цели скупови уређаја, који већ јесу или ће бити уграђени у подсистем, од којих директно или индиректно зависи интероперабилност трансевропског класичног железничког система. Концептом конституената обухваћене су и материјалне и нематеријалне компоненте (као што је нпр. софтвер). Без коначног прејудицирања конституената интероперабилности, који ће бити дефинисани кроз техничке спецификације за интероперабилност, Директивом 2001/16 издвојене су следеће основне компоненте, које ће бити релевантне за интероперабилност: инфраструктура, енергија, командно-контролни и сигнални систем, експлоатација и управљање саобраћајем, мобилна средства, одржавање, телематске апликације за путнички и теретни саобраћај. Апликације за путнички саобраћај су: • системи за информисање путника пре и током путовања, • систем резервације и куповине карата, • управљање пртљагом и везама са другим видовима саобраћаја, • израда одговарајућих електронских докумената. Апликације за теретни саобраћај су: • информациони системи за праћење пошиљака и возова у реалном времену, • ранжирање, • системи алокације, • резервације, наруџбе и плаћања, • управљање везама са другим видовима саобраћаја, • израда одговарајућих електронских докумената. Ово је само основни оквир, док је задатак тима Европске организације за интероперабилност железница да дâ детаљне спецификације о интероперабилности, рашчлањавањем сваког подсистема до потребног нивоа за утврђивање услова интероперабилности. Услови интероперабилности за дефинисане подсистеме, дати кроз техничке спецификације за интероперабилност, односиће се на: • сам подсистем и његове интерфејсе са другим подсистемима, Модел B2B интеграције саобраћајних пословних система 71 • конституенте интероперабилности, као делове подсистема и њихове интерфејсе. За све подсистеме и елементе директивом уводи се и декларација о интероперабилности. Декларацију ће добити елемент система који испуњава услове дефинисане техничким спецификацијама за интероперабилност, дефинисаним поступком верификације који обављају релевантна овлашћена тела (прилози V-VIII Директиве 2001/16). Европска организација за интероперабилност железница Европска организација за интероперабилност железница (фран. Association Européenne pour l’ Interoperabilité Ferroviaire, AEIF) има функцију Заједничког представничког тела. AEIF је од 1996. до 2001. године радила на предлогу техничких спецификација за интероперабилност система за велике брзине, које су државе чланице усвојиле 2001. године. Ову организацију 1995. године заједнички су основали: • Међународна железничка унија (енгл. International Union of Railways, UIC), • Унија европске железничке индустрије (енгл. Association of the European Rail Industry, UNIFE), • Међународна унија за јавни превоз (енгл. International Association of Public Transport, UITP). Мандат јој је поверила Европска комисија да: • изради нацрте техничких спецификација за интероперабилност (енгл. Technical Specifications for Interoperability, TSIs), • руководи поступцима ревизије и ажурирања TSIs, • спроводи потребна истраживања за израду нацрта или ревизије TSIs. Очекивани ефекти интероперабилности железница Основни циљ Директиве 2001/16/EC јесте ревитализација европског железничког система кроз техничко-технолошку интеграцију националних железница. Од бројних потенцијалних ефеката интероперабилности претпоставља се да су најважнији следеће: • повећање учешћа железнице у подели рада на транспортном тржишту захваљујући непрекинутим железничким везама на целокупном европском простору и скраћењу времена путовања; • ефикасније тржишно пословање железничких предузећа јер се стварају могућности за једноставније управљање системом и пружање савремених логистичких услуга; Модел B2B интеграције саобраћајних пословних система 72 • снижавање трошкова кроз оптимизацију возног парка, заједничку експлоатацију и концепт одржавања возила, што ће олакшати и укључивање нових оператора; • виши ниво безбедности услед харрнонизације командно-контролних и сигналних система; • већа стандардизација и модуларност железничких средстава и опреме, која проширује могућности набавке средстава и с друге стране даје и шире могућности произвођачима опреме; • повећава ставку „остатак вредности” код вредновања пројеката (веће могућности продаје средстава); • отварање могућности за спровођење заједничких истраживачких пројеката у области техничко-технолошких иновација и маркетинга; • проширивање могућности за запошљавање на железници, као и у производњи железничких средстава и опреме, јер ће и тржиште радне снаге у овим областима прерасти националне оквире; • побољшање услова рада особља ангажованог непосредно у саобраћајној служби, захваљујући усаглашавању саобраћајних прописа, комуникационих и сигнално-сигурносних система; • повећање учешћа железничког саобраћаја имаће позитиван ефекат на животну средину. Увођењем интероперабилности отварају се, дакле, огромне могућности за цео железнички сектор. Уместо фрагментисаних, креираће се нове врсте „непрекинутих” тзв, „бешавних” услуга на европском простору и побољшати њихов квалитет уз већу економичност рада. То ће знатно допринети конкурентности железнице, придобијању корисника превоза и формирању модалне расподеле прихватљиве из аспекта одрживог развоја, на шта је и усмерена саобраћајна политика ЕУ. То се поготову односи на земље као што је наша, кроз које пролазе међународни коридори, на којима ће интероперабилност бити цондитио сине qуа нон (услов без којег се не може). На садашњој фрагментисаној европској мрежи и железничке превозне услуге су фрагментисане, скупе и ниског квалитета. Без увођења интероперабилности, с постојећим квалитетом услуге железница не може да испуни захтеве које поставља тражња, што води даљем опадању њеног учешћа у модалној расподели, са свим последицама које такав тренд носи. 2.6.3. Структурна поставка интероперабилности у саобраћају Модел који омогућује интероперабилно деловање у саобраћају и транспорту поседује хијерархијску структуру која је компатибилна са интеграцијом функција ЛИКС-а са саобраћајним и транспортним системима (СТ системима). На слици 27 приказана је архитектура модела интероперабилног деловања. Разлике постоје у имплементирању од компаније до компаније, али општа структурна хијерархија Модел B2B интеграције саобраћајних пословних система 73 и архитектура су сличне, чак и када модел не интегрише све компоненте. Модел интероперабилног деловања могуће је дати у три равни. Свака од ових равни, представља посебну целину. Очигледно да се у равни А (систему А) налазе захтеви и потребе, док се у равни Б (систему Б) налазе системи који обезбеђују реализацију таквих захтева и потреба. Интеракција између њиховог деловања (корисника и даваоца услуга) представљена је интероперабилношћу, и неопходна је за било који процес у саобраћају и транспорту. Идеална ситуација је да су интероперабилни системи усаглашени са стандардима. Међутим, у пракси је то углавном тешко остварити због брзине технолошких промена, недостатка универзално прихваћених стандарда, или једноставно због постојања аутономије сваког од система. Захтевана интероперабилност се може остварити коришћењем апстракција којима ће се сакрити комплексност и имплементациони детаљи. При томе се за формирање структуре интероперабилности може поћи од публиковања формата и интерфејса, као што то налаже методологија за развој отворених система. Слика 27. Архитектура интероперабилности Интероперабилни систем мора да садржи једну архитектуру и скуп стандарда за ЛИКС. Међутим, прилично је тешко тврдити да ће се на глобалном нивоу у оквиру ЛИКС заједнице усвојити једна архитектура, структура и стандард за податке. Логичан закључак и последица тога је да покушаји стандардизације сами по себи не резултирају интероперабилношћу. Интероперабилност ће захтевати конзистентност кроз широк опсег техничких, семантичких и инситуционалних параметара, наведених у табели 3. Два најнижа нивоа у табели: размена података и мреже, последица су већ усвојених стандарда информационих технологија у СТ компанијама и употребних стандарда. Међутим, ови напори и покушаји њихове примене једино обезбеђују инфраструктуру за размену података, и не гарантују да су подаци познати или доступни и да ли ће СТ компаније прихватити односно усвојити те технологије. Модел B2B интеграције саобраћајних пословних система 74 Табела 3. Конзистентност интероперабилности Ниво интероперабилности Предуслови за реализацију интероперабилности Тренутни статус Институционални Спремност за интероперабилност Углавном различит и прећутан Модели информација Формализација и дескриптори за податке Ране фазе развоја Шема података Прихватање стандарда за базе података Врло зависно од сектора саобраћаја и транспорта Размена података Употребни стандарди Доступни и у експанзији Мреже Стандардни мрежни протоколи Усвојени и широко прихваћени 2.6.4. Интероперабилност логистичких информационо-комуникационих система По правилу свака бежична технологија дизајнирана је за одређену примену или одређени кориснички контекст и ниједна није довољно моћна да у реалном времену прати све постојеће токове, као и догађаје који се одвијају у склопу њих. Управо се због тога реализација решења види у интероперабилности хетерогених бежичних технологија које су неопходне за будуће свеприсутне бежичне комуникације, као и њихову коегзистенцију са новим бежичним технологијама. Дакле, пред бежичне мреже сензора, као незаменљив део савремених логистичких процеса, се поставља захтев за повезивање великог броја мониторинг-објеката и успостављањем сигурне комуникације унутар ЛИKС-а. Да би се испунили захтеви у погледу проактивности у контроли поруџбина и прикупљању података, функционалности и институционалности примењених процедура, флексибилности повећања процеса у динамичком окружењу, мора се назначити значај и неопходност постојања интероперабилности између свих чинилаца глобалног оптимизационог модела. Оцена степена интероперабилности примењених технологија у ЛИКС-у се мери као степен способности система (или јединице система) да обезбеде сервис (информације) за друге системе и да прихвате сервис (информације) од других система или јединица система и да тако размењене информације искористе у сврху оспособљавања за заједничко функционисање у циљу мониторинга логистичких процеса. Применом предложеног модела повезују се ресурси који се користе у логистичким токовима са окружењем кроз дистрибуиране информационе јединице у процесу доношења пословних одлука у реалном времену. Управо компоненте тог модела конструишу инфраструктуру ЛИKС-а, која са локалним информационим јединицама и бежичним мрежама, постиже целовитост и глобалну кохезивност дистрибуираних локалних догађаја у постојећим логистичким токовима. На слици 28 приказане су техничка и процесна раван интероперабилности у ЛИKС-у. Модел B2B интеграције саобраћајних пословних система 75 Слика 28. Равни интероперабилности у логистичком информационо- комуникационом систему 2.7. Преглед најзначајнијих стандарда и решења за реализацију интероперабилности у саобраћају и транспорту Динамичан и често непредвидив пословни амбијент захтева од ИТ система саобраћајно-транспортних организација да могу лако, јефтино и брзо да се мењају. Индустријски стандарди и готова решења у овој области, као што су RosettaNet и ebXML не могу да одговоре сложеним захтевима интероперабилности саобраћајних пословних система. СОА представља одговор на променљиво окружење и променљиве пословне потребе [139]. Као најважнија предност СОА наводи се то што она експлицитно подржава интероперабилност на нивоу апликација, на нивоу пословних процеса и на семантичком нивоу [147]. У [18] предлаже се једно решење за размену података за генерисање реда вожње, засновано на СОА. Ово решење требало би да омогући размену података у формату који користе железничке управе у земљама Европске Уније. Истраживања у области B2B интеграције најчешће предлажу моделе засноване на XML стандардима размене података и Web сервисима [101]. Неки аутори предлажу модел интероперабилности заснован на интеграцији Web портала и семантичких Web сервиса [1]. XML стандарди за размену података у саобраћају и транспорту У области транспорта идентификоване су бројне примене технологија заснованих на XML-у. У транспортној заједници, области као што су планирање, пројектовање, конструисање, одржавање и оперативни сектор, су потенцијални корисници XML-а за потребе размене великих количина података. Узмимо, на пример, транспортне симулације. Саобраћајни аналитичари сочавају се са недостатком универзалне методологије за размену података између симулационих Модел B2B интеграције саобраћајних пословних система 76 модела различитих произвођача. У [121] представљена су два језика базирана на XML-у: TrafficXML - за представљање података који се користе у саобраћајним симулацијама; TranXML - као стандард у логистичкој индустрији, за трансакције у електронској трговини између шпедитера и превозника. Traffic Model Markup Language (TMML) развијен је на Универзитету у Флориди као заједнички језик за представљање и размену података у саобраћајном моделирању. У [38] представљена је спецификација овог формата за коришћење у области саобраћајног моделирања. У истом раду дато је и неколико примера коришћења овог формата. Последњих година путничке информације динамички се шире путем World Wide Web сајтова. Постоји велики број сајтова који користе HTML, са сликама и цртежима који се тичу: временских прилика, стања на путевима, одржавања путева. Проблем се састоји у томе што је информације представљене у HTML-у тешко користити за аутоматизацију обраде, због тога што HTML не обезбеђује значење већ само формат података. Насупрот томе, XML може да се користи да обезбеди стандардан начин дефинисања тагова за специфичан домен, који преносе значење података. Неколико језика, развијених на бази XML-а, предложено је за представљање података о путовањима и транспорту: Road Web Markup Language (RWML), LandXML for Land Development and Transportation Professionals, Geography Markup Language (GML), Traveler Information Markup Language (TIML) [179]. Постоји неколико система који обезбеђују путничке информације, а базирани су на XML-у. Један такав пример је: прототип фирме Mitretek System назван TripInfo који се примењује за пружање информација базираних на RWML-у. TripInfo је на рутама базиран информациони систем за путнике, који дозвољава путницима да му приступе помоћу стандардног Web претраживача и концепта Web сервиса. InteGRail - Intelligent Integration of Railway Systems У периоду 2005-2008. једанаест земаља реализовало је интегрисани пројекат InteGRail (Intelligent Integration of Railway Systems) [82]. InteGRail интегрише железничке информационе системе и обезбеђује: • заједничку платформу за управљање интегрисаним информацијама, • праву информацију на правом месту, у право време, • омогућава железницама да раде као један систем, • интегрисање наслеђених система, • имплементирање интероперабилности информационих система. Платформа је заснована на сервисно-оријентисаној архитектури и моделу података базираном на онтологијама. Преко гетвеја названог Flexible Communication Adapter, InteGRail омогућава интегрисање постојећих апликација за управљање: • возним средствима, Модел B2B интеграције саобраћајних пословних система 77 • инфраструктром, • саобраћајем, • операцијама. У InteGRail систему онтологије се користе за: • комплексно моделирање података, • дефинисање интерфејса (статички аспект), • обрада података и информација (динамички аспект). Десет најважнијих користи од система InteGRail: 1. дефинисање података без двосмислености, 2. олакшава размену података, 3. смањује трошкове интерфејсних система, 4. унапређује размењивање и праћење порука, 5. брзо проналази праву информацију, где год да се она налази, 6. аутоматски, интелигентно, обрађује информације и екстрахује скривене (имплицитне) информације, 7. подржава апликације у свим сферама, 8. чува и обогаћује базу знања система, 9. подржава одлучивање у циљу идентификовања оптималних решења, 10. омогућава еволуцију информационих система, у смислу праћења промена које се дешавају у реалном свету железница и примене нових технологија, али логички концепти се задржавају. NTCIP - National Transportation Communications for ITS Protocol Аутори у [177, 178] предлажу Center-To-Center (C2C) размену података између интелигентних транспортних система, комбиновањем Traffic Management Data Directory (TMDD) и Message Set for External Traffic Management Centers Communication (MS-ETMCC) стандарда са технологијом Web сервиса. Предности ове опције укључују ниску цену, добру развојну компатибилност са постојећом Common Object Request Broker Architecture (CORBA) технологијом и њен флексибилан размештај и миграцију (нпр. не захтева значајне измене постојећег софтверског система). Она може да обезбеди исплативо софтверско решење за средња и мала предузећа са ограниченим финансијским средствима и информатичком инфраструктуром. CORBA је спецификација архитектуре за технологије средњег слоја (енгл. middleware technology), која обезбеђује интероперабилност између клијената и сервера дистрибуираних унутар хетерогеног окружења [125]. CORBA се користи у многим државама у управљању њиховим саобраћајним центрима [180]. Модел B2B интеграције саобраћајних пословних система 78 PREDIM - Research and Experimental Platform for the Development of Multi-modal travel Information Користећи искуства истраживача у области саобраћаја и транспорта, у области мулти-модалних информација PREDIT - French National Program of Research, Experimentation and Innovation in land Transport креирао је PREDIM - Research and Experimental Platform for the Development of Multi-modal travel Information [158]. У другим европским земљама питање интеграције путничких информација је такође актуелно [161]. TRIDENT - TRansport Intermodality Data sharing and Exchange NeTworks Треба споменути и европски пројекат интеграције: TRansport Intermodality Data sharing and Exchange NeTworks – TRIDENT [59]. Циљ овог пројекта је да подржи сервисе интелигентних транспортних система за мултимодална путовања, обезбеђујући заједничке механизме за дељење и размену података између транспортних оператора различитих видова саобраћаја. TRANSASIST - Citizens Information Mobile Integrated Services, Support for Access to the Urban Transport Networks Assistance Technologies in a Knowledge Based Society На овом пољу развијен је и пројекат: Citizens Information Mobile Integrated Services, Support for Access to the Urban Transport Networks Assistance Technologies иn a Knowledge Based Society – TRANSASIST [77]. Он је базиран на савременим информационим технологијама и помаже корисницима да путују кроз урбане зоне на нивоу европског стандарда, проналазећи најбоље руте између две тачке, укључујући јавни и комерцијални транспорт, као и кретање пешака. Transit Trip Planner - дистрибуирани, интегрисани систем за планирање транзитних путовања У [130] развијен је радни оквир за дистрибуирани, интегрисани систем планирања транзитних путовања. Он има за циљ да помогне путницима да приступају различитим системима за планирање путовања са истог места или Web сајта. Овај систем омогућава различитим транзитним путничким агенцијама да користе сопствене системе за планирање путовања и одржавају своје податке, али и интегрише ове различите системе, тако да они постају интероперабилни. Крајњи корисник не примећује границе појединачних система унутар овог интегрисаног дистрибуираног система. Интегрисани систем за планирање путовања комуницира са различитим системима које користе агенције за планирање путовања и обезбеђује кориснику оптималну маршруту путовања. Аутори у [60] сугеришу једну агентно-оријентисану архитектуру за кооперативне информационе системе у области подршке путницима код планирања мултимодалног транспорта. Овај приступ подразумева сарадњу информационих система постојећих оператора, како би се корисницима обезбедила оптимална рута на бази података прикупљених од више оператора. У [173] предложен је Модел B2B интеграције саобраћајних пословних система 79 модел интероперабилних апликација које се користе у ланцима снабдевања, заснован на размени порука. Интероперабилност саобраћајно-транспортних система на бази бежичних сензорских мрежа Прогрес у технологији бежичних комуникација довео је до развоја интегрисаних кола високог нивоа ефикасности и мале потрошње енергије. Побољшања у напајањима и смањење цене производа омогућиле су остваривање нове технолошке визије - бежичних сензорских мрежа. Бежичне сензорске мреже (енгл. Wirelles Sensors Networks, WSN) настале су груписањем већег броја сензорских чворова који чине интегрални део система у коме се налазе. Оне преузимају податке из околине која их окружује и даље их дистрибуирају и/или процесирају. Сваки од чворова има способност прикупљања и рутирања података до главног чвора. Подаци до главног чвора пристижу вишеструким скоковима, односно слањем од чвора до чвора. WSN је бежична сензорска мрежа која представља колекцију међусобно повезаних димензионо малих, вишефункционалних, јефтиних сензорских чворова. За разлику од мобилних ad-hoc мрежа, сензорске мреже се не фокусирају на интеракцију са људима већ на интеракцију са окружењем. Чворови ових сензорских мрежа се налазе у одређеном окружењу ради праћења неког феномена, и да би у одређеним случајевима деловали на основу измерених вредности. WSN комбинује једноставну бежичну комуникацију - минималне рачунарске капацитете и одређену врсту ослушкивања физичке околине у нови облик мрежа које могу бити дубоко интегрисане у физичку околину, активиране јефтиним и бежичним комуникационим уређајима. Сензорска мрежа (енгл. Sensor Network, SNet) је дистрибуирани систем кога чини поље сензора различитог типа међусобно повезаних комуникационом мрежом. Подаци са излаза сензора су дељиви, а доводе се на улаз дистрибуираних система ради њихове процене (естимације). Задатак дистрибуираних система је да на основу доступних података са сензора издвоји највероватнију информацију о феномену који се надгледа. Основне оперативно-економске карактеристике сензорских мрежа су: висока поузданост у раду, релативно висока тачност, флексибилност, ниска цена, лако распоређивање сензора у простору. SNet се формира од индивидуалних мултифункционалних сензорских чворова (енгл. Sensor Nod, SNod). У највећем броју случајева SNod-ови се бежичним путем повезују у комуникациону мрежу формирајући на тај начин бежичну сензорску мрежу. WSN се састоји од батеријско напајаних модула који су у суштини SNod- ови. Градивни блокови ових модула су: • сензор - генератор података; • радио примо-предајник - предаје или прослеђује кроз мрежу податке које је примио од својих суседа (рутира податке); • један или више процесора - контролишу рад сензора и примо-предајника, процесирају податке и имплементирају мрежне и протоколе за рутирање; Модел B2B интеграције саобраћајних пословних система 80 Основне карактеристике бежичних сензорских мрежа подразумевају бројност и густину распореда сензорских чворова, самостално функционисање, способност сакупљања, складиштења, дистрибуције података, поузданост и флексибилност рада сензорских чворова. Дизајн сензорских мрежа зависи од толеранције грешака, скалабилности, производних трошкова елемената мреже, топологије, хардверских ограничења, преносних медијума и енергетске потрошње. Према критеријуму структурираности, сензорске мреже могу се поделити на: структуриране и неструктуриране сензорске мреже. Неструктуирана WSN састоји се од густог скупа, ad-hoc распоређених сензорских чворова и самостално извршава функције мониторинга и извештавања. У структурној WSN се, сви или неки од сензорских чворова, распоређују на унапред планиран начин, а њену најважнију предност чине нижи трошкови управљања и мрежног одржавања. У зависности од локације на којој су постављене, сензорске мреже деле се на: површинске, подземне и подводне сензорске мреже. Чворови површинских WSN се често непосредно распоређују бацањем из авиона. Поред претходно поменутог насумичног смештања у циљну област, у унапред испланираном распоређивању, постоји решеткасто, оптимално постављање и поштују се одговарајући модели позиционирања. Највећи део чворова подземних WSN се поставља испод површине земље, у пећинама и рудницима, док се главни чворови смештају изнад површине земље са циљем преношења информација до базне станице. Карактерише их висока цена пошто се одговарајући делови опреме бирају тако да могу осигурати поуздану комуникацију кроз воду, стене и друге минералне садржине. Сензорске чворове подводне WSN карактерише висока цена, мања бројност и знатно мања густина у поређењу са површинским бежичним сензорским мрежама. Највеће проблеме подводне комуникације чине ограничен опсег (енгл. Bandwidth), велико пропагационо кашњење и проблем слабљења сигнала. Према критеријуму мобилности, сензорске мреже се могу поделити на статичне и мобилне. Сензорски чворови мобилне WSN могу током времена променити позицију, мењајући на тај начин и сам изглед мреже. Још једна кључна разлика између статичних и мобилних WSN је дистрибуција података. Подаци се у случају статичних, дистрибуирају коришћењем фиксног усмеравања, док се код мобилних WSN користе динамична усмеравања. Сензорске мреже континуално надгледају окружење, а могу бити са: • периодичним извештавањем (енгл. periodical reporting) и • извештавањем изазваним догађајем (енгл. event-based reporting). Примена RFID-а у циљу постизања интероперабилности саобраћајно- транспортних процеса Идентификација путем радио фреквенције (енгл. Radio Frequency Identification, RFID) представља технологију аутоматског прикупљања података која омогућава Модел B2B интеграције саобраћајних пословних система 81 прихватање и пренос података у оквиру пословних процеса бежичним путем, коришћењем радио таласа. Сензорски системи имају велику примену у управљању модерним ланцима снабдевања. Процес контроле ланаца снабдевања ће све више бити аутоматизован. RFID има боље перформансе од оптичких кодова, као што је добро познати бар код. RFID транспондери или тагови садрже јединствени број који идентификује робу. Они се могу прочитати помоћу електромагнетног поља и то на дистанцама до неколико метара. Чипови транспондера добијају енергију из магнетног поља. Њихов животни век није ограничен батеријама. RFID тагови се скенирају при сваком претовару. У комбинацији са GPS системом у превозном средству могуће је пратити сваку палету, одредити њену актуелну позицију и проверити да ли је на одговарајућем транспортном путу. До сада је у употреби био велики број „приватних” решења у индустрији и логистици. Моћ RFID микрочипова је у способности преношења јединствене идентификационе информације - електронског кода производа (енгл. Electronic Product Code, EPC), слично комерцијалној употреби бар кода. Велика је потреба за успостављањем глобалног стандарда као што је EPC. EPC је 128-битни код који садржи серијски број, врсту робе и назив произвођача. Количина кварљиве робе коју је потребно надгледати помоћу сензора стално расте. Такође, постоји потреба за детаљном, локалном сензорском информацијом. Температура унутар контејнера-хладњаче може превазићи критичну вредност услед погрешног паковања. Процеси труљења хране услед неадекватне температуре не могу се детектовати уколико се надгледа само температура ваздуха. До сада је већина система у примени била ограничена data logger-ом који су пратили температуру. Они се користе за потврђивање квалитета производа и за разграничење одговорности у случају оштећења робе. Сензори који мере влажност и вибрације би такође требали да дају вредне додатне информације. Пошто Just-In-Time стратегија у логистици захтева брзе реакције, неопходно је интервенисати пре него што роба стигне на погрешно место или у оштећеном стању. Проблеми, као што су смањење квалитета производа или једноставно појављивање грешака треба да буду моментално пријављени. Грешке се могу препознати помоћу RFID читача инсталираних на сваком месту отпреме робе. Због тога транспортно средство мора бити опремљено сензорима и помоћу бежичне мреже пријављивати грешке превознику. RFID-ови у комбинацији са сензорима се користе дужи низ година. Они представљају техничко решење које се може користити и у логистици. Сензор и RFID се на нивоу хардвера комбинују у микросистем. Захваљујући чињеници да сензор може сакупити податке чак и у одсуству RFID читача он не може користити енергију магнетног поља. Стога они користе енергију батерија. Изводе се у форми logger података који се могу пратити помоћу RFID читача када се роба утовари. Они испуњавају потребе модерне логистике. По доласку, прималац може контролисати вредности максималне темературе помоћу специјалног RFID читача. Информације о производу такође могу бити ускладиштене на налепници. Модел B2B интеграције саобраћајних пословних система 82 Из економских разлога није изводљиво комбиновати RFID-сензор налепнице и бежичну комуникацију у истом микросистему. RFID-сензор налепнице већ повећавају трошкове стандардних RFID тагова до десет пута. Додавањем бежичне комуникације трошкови ће се повећати за око 100 пута. Да бисмо омогућили on- line приступ условима окружења робе, уз разумне трошкове, развијено је ново решење. Његова карактеристика је подељени хардвер за RFID и сензор. Веза је изведена путем софтвера специјалног борд компјутера. Систем се састоји из следећих елемената: • RFID налепница - користе се стандардни RFID тагови. Поред идентификационог броја ускладиштене су и информације о врсти робе и специфична ограничења када су у питању услови окружења; • RFID читач - врата превозног средства су опремљена са RFID читачем широког опсега. Као алтернатива користе се читачи инсталирани на утоварним платформама; • бежични сензори - није неопходно опремити сваку транспортну јединицу сетом сензора. Дистрибуирана сензорска мрежа је неопходна за добијање поузданих података за сваку робу, али ће број сензора бити много мањи од броја јединица робе смештених унтар транспортног превозног средства. Бежични сензорски чворови са батеријским напајањем који имају могућност активне комуникације омогућавају приступ чак и у натовареном контејнеру; • борд компјутер - софтверски агент или борд компјутер покренут на главном чвору извршава повезивање RFID-а и сензора. Агент је иницијализован параметрима мониторинга који су детектовани током утовара помоћу RFID тагова. Бежичне сензорске мреже захтевају сензорске вредности током транспорта. Током транспорта није неопходан приступ RFID таговима. Сензорски протокол или специјална ознака се поставља само на истовареној роби, уколико су пређене граничне вредности; • спољашње мреже - борд компјутер посредује између унутрашње комуникације слабе снаге и уског опсега и спољашње глобалне комуникације. У нашем прототипу услови окружења сваке робе су доступни путем Web интерфејса. Модел B2B интеграције саобраћајних пословних система 83 3. Развој методологије и модела B2B интеграције саобраћајних пословних система Развој методологије и модела B2B интеграције саобраћајних пословних система пре свега подразумева упознавање са пословним системима чије електронско пословање и сарадњу треба унапредити. Под саобраћајним пословним системима овде се не подразумевају само предузећа која врше транспортне услуге, већ и сви несаобраћајни субјекти који на неки начин омогућавају и обезбеђују реализацију транспортне услуге. 3.1. Развој методологије B2B интеграције саобраћајних пословних система Будући да овде под саобраћајним пословним системима подразумевамо разнородне пословне субјекте, као и субјекте из Владиног сектора, у развоју методологије њихових B2B интеграција морају се узети у обзир различитости законских и институционалних оквира њихове сарадње и међусобних обавеза. 3.1.1. Идентификација категорија пословних субјеката који ће бити укључени у B2B интеграције Потреба за сарадњом и B2B интеграцијом пословних субјеката у саобраћају и транспорту најизраженија је на пољу безбедности саобраћаја. Аутори у [16] показали су да је принцип „Safety in Numbers” заиста актуелан принцип у области безбедности саобраћаја. Међутим, да би се овај принцип спроводио у реалним условима, „Numbers” морају бити производ интероперабилних информационих система, а не ручног израчунавања које врше истраживачи. Стога ће предмет проучавања бити потребе и могућности сарадње свих субјеката који на неки начин узимају учешће у управљању безбедношћу саобраћаја. Сви субјекти који имају потребе за B2B интеграцијом на пољу безбедности саобраћаја могу се поделити у следеће категорије: • саобраћајно-транспортна предузећа, • јавна предузећа која управљају саобраћајном инфраструктуром, • надлежна министарства и друге релевантне Владине организације за вођење послова државне управе у области саобраћаја и транспорта. 3.1.2. Анализа пословних релација у саобраћају и транспорту за које треба обезбедити B2B интеграцију С обзиром на то да је потребно остварити сарадњу јавних предузећа, као и организација из Владиног сектора, важно је имати на уму законске и институционалне оквире у којима послују ови субјекти. Законски акти који одређују обавезе посматраног субјекта значајно дефинишу и неопходну Модел B2B интеграције саобраћајних пословних система 84 информациону инфраструктуру те организације. Некада се, нпр. законским актима једној организацији прописује обавеза администрирања одређених база података. Други пример је да је законом дефинисана обавеза једне организације према другој организацији, у смислу обезбеђивања и достављања података. Ово су само два примера која јасно указују на то да прва фаза у развоју методологије B2B интеграције субјеката у области саобраћаја, мора бити анализа законских обавеза и оквира институционалне сарадње посматраних субјеката. B2B интеграција субјеката у области саобраћаја треба да се оствари на следећим врстама релација: • комерцијални сектор – комерцијални сектор (К-К), • комерцијални сектор – јавни сектор (К-Ј), • комерцијални сектор – Владин сектор (К-В), • јавни сектор – јавни сектор (Ј-Ј), • јавни сектор – Владин сектор (Ј-В), • Владин сектор – Владин сектор (В-В). На слици 29 приказан је оквир интероперабилности у саобраћајно- транспортном сектору. Слика 29. Оквир интероперабилности у саобраћајно-транспортном сектору Модел B2B интеграције саобраћајних пословних система 85 3.1.3. Дефинисање фаза развоја решења Решења B2B интеграције, на свим врстама релација субјеката у саобраћајно- транспортном сектору, имаће сервисно-оријентисану архитектуру. Сва решења B2B интеграције саобраћајно-транспортних пословних субјеката могу се поделити у три велике класе: • решења заснована на интегрисању постојећих информација и апликација, • решења заснована на развоју нових база података и апликација, • решења заснована на интегрисању постојећих и нових апликација. За три категорије решења разликују се приступи у решавању и фазе развоја. „Одоздо-нагоре” приступ За решења заснована на интегрисању постојећих информација и апликација, одговарајући је „одоздо-нагоре” (енгл. bottom-up) приступ [57]. Интегрисање постојећих апликација захтева развој Web сервиса по потреби. Стога развој ове категорије решења започиње анализом апликационих сервиса, што је у литератури познато као „одоздо-нагоре” приступ. На слици 30 приказане су фазе развоја сервисно-оријентисаног решења, код „одоздо-нагоре” приступа. Слика 30. „Одоздо-нагоре” приступ у развоју сервисно-оријентисаног решења B2B интеграције Као што се може приметити на слици 30 овај процес подразумева да су раније дефинисани захтеви решења. Моделирање апликационих сервиса требало би да резултује дефинисањем захтева апликација, који могу бити испуњени коришћењем Web сервиса. Типични захтеви укључују остваривање point-to-point Модел B2B интеграције саобраћајних пословних система 86 интеграције постојећих система. Апликациони сервиси се моделирају тако да укључују специфичну пословну логику и правила. „Одозго-надоле” приступ За решења заснована на развоју нових база података и апликација одговарајући је „одозго-надоле” (енгл. top-down) приступ. Код овог приступа на првом месту је анализа захтева и пословних модела субјеката B2B интеграције. Он промовише не само сервисно-оријентисани развој пословних процеса, већ и креирање (или усаглашавање) свеукупног пословног модела организације. Овај процес је изведен из постојеће пословне логике организације, а резултује креирањем великог броја пословних и апликационих сервиса. На слици 31 приказане су фазе развоја сервисно-оријентисаног решења, код „одозго-надоле” приступа. Слика 31. „Одозго-надоле” приступ у развоју сервисно-оријентисаног решења B2B интеграције Дефинисање релевантне онтологије Као што се може приметити на слици 31 овај процес подразумева да су раније дефинисани захтеви решења. Део процеса који за последицу има формирање онтологије, представља класификацију скупова информација које једна организација обрађује. То резултује креирањем заједничког речника, као и дефинисањем односа у којима се поједине групе података налазе. Веће Модел B2B интеграције саобраћајних пословних система 87 организације, које имају неколико сфера пословања, креирају више онтологија, где свака онтологија покрива један сегмент пословања. Међутим, све те онтологије морају се међусобно ускладити, како би подржале најопштију онтологију која се односи на читаву организацију. Ова фаза захтева пословну анализу од највишег до најнижих нивоа пословних процеса. Усклађивање пословних модела са новом или модификованом онтологијом Након што је успостављена онтологија, постојећи пословни модели морају бити прилагођени и усклађени са онтологијом, а у многим случајевима морају се креирати потпуно нови пословни модели, како би речник дефинисан онтологијом ваљано представљали терминима пословног моделирања. Модели ентитета посебно су значајни, јер касније могу бити основа за entity-centric poslovne servise. Прва два корака произилазе из детаљне анализе пословног система, али су намерно издвојена као предуслов за спровођење сервисно-оријентисане анализе. Сервисно-оријентисана анализа На слици 32 приказане су фазе од којих се састоји сервисно-оријентисана анализа. Слика 32. Фаза сервисно-оријентисане анализе у развоју решења B2B интеграције Модел B2B интеграције саобраћајних пословних система 88 Последња фаза сервисно оријентисане анализе је моделирање сервиса кандидата. Она претходи сервисно-оријентисаном дизајну. На слици 33 приказане су активности од којих се састоји фаза моделирања сервиса кандидата. Слика 33. Фаза моделирања сервиса кандидата у развоју решења B2B интеграције Сервисно-оријентисани дизајн На слици 34 приказане су фазе од којих се састоји сервисно-оријентисани дизајн. Модел B2B интеграције саобраћајних пословних система 89 Слика 34. Фаза сервисно-оријентисаног дизајна у развоју решења B2B интеграције Аgile стратегија Решења B2B интеграције заснована на интеграцији постојећих и нових апликација су најкомпликованија. Аgile стратегија (енгл. the agile strategy) заснива се на паралелној анализи пословних процеса и развоју сервиса (слика 35). Модел B2B интеграције саобраћајних пословних система 90 Слика 35. Аgile стратегија у развоју сервисно-оријентисаног решења B2B интеграције Највећи изазов је да се пронађе равнотежа у имплементацији принципа сервисно- оријентисаног дизајна у окружењу пословне анализе [58]. Ова стратегија назива се још и „налажење на средини” приступ. За решења заснована на интегрисању постојећих и нових апликација одговарајућа је agile стратегија. У поређењу са Модел B2B интеграције саобраћајних пословних система 91 претходна два приступа, овај приступ је најкомплекснији јер има задатак да испуни два скупа супротстваљених захтева. Без обзира на то која стратегија развоја решења се изабере, обавезна фаза у развоју решења је сервисно-оријентисана анализа. На слици 32 приказане су активности од којих се састоји ова фаза развоја решења. 3.1.4. Дефинисање захтева решења B2B интеграције На пољу саобраћаја и транспорта сусрећу се и сарађују различите врсте организација: комерцијалне, Владине, јавна предузећа. Поменуте врсте организација имају различиту организациону структуру, систем доношења одлука, законске обавезе у свом пословању, итд. Стога су и захтеви решења њихове B2B интеграције комплексни. Захтеви решења различити су за свих шест раније наведених типова релација, како у погледу оквира B2B интеграције, тако и у погледу захтеваног хардвера и софтвера. 3.1.4.1. Оквири B2B интеграције саобраћајних пословних субјеката Оквири сарадње субјеката у домену саобраћаја морају се дефинисати уговорима, а у случају сарадње са организацијама из Владиног сектора, законским актима. Уговори, односно закони, морају садржати прецизно дефинисане процедуре спровођења B2B интеграција. Приликом дефинисања законских и институционалних оквира интеграције, разликујемо два основна типа B2B интеграција: • хоризонталне B2B интеграције - интеграције ентитета који сагледавају заједнички домен са приближно једнаким степеном апстракције, • вертикалне B2B интеграције - интеграције ентитета који сагледавају заједнички домен са значајно различитим степеном апстракције, У пракси се приликом B2B интеграције две организације најчешће комбинују хоризонтална и вертикална интеграција. То је тако због тога што организације најчешће у једном сегменту свога пословања сагледавају заједнички домен са приближно једнаким нивоом апстракције, док се у другим сегментима њиховог пословања поглед на реални систем значајно разликује. У зависности од тога да ли је у питању чиста хоризонтална интеграција, чиста вертикална интеграција, или комбинована – хибридна интеграција, разликују се и оквири B2B интеграције. Хоризонтална B2B интеграција погодна је код: • интеграције организација које припадају истом нивоу унутар истог сектора (комерцијални, јавни или Владин сектор); • интеграције организација које припадају истом нивоу, унутар различитих сектора; Модел B2B интеграције саобраћајних пословних система 92 Вертикална B2B интеграција погодна је код: • интеграције организација које припадају различитим нивоима унутар истог сектора. Хибридна B2B интеграција погодна је код: • интеграције организација које припадају различитим нивоима унутар различитих сектора. Хоризонталне интеграције по правилу су једноставније, јер субјекти имају исти поглед на оно што је предмет њиховог интересовања. Код вертикалних интеграција, организације на вишим нивоима „виде” домен на вишем степену апстракције, док је „поглед” организација са нижих нивоа, на домен, много ближи реалном систему. Стога се и оквири сарадње код вертикалне и хоризонталне B2B интеграције морају разликовати. Оквири B2B интеграција субјеката у саобраћају и транспорту: • уговором дефинисана процедура којом једна организација преузима податке од друге организације. У уговору је дефинисана структура, обим, формат и значење података који се преузимају, као и начин и периодичност преузимања. Овај оквир сарадње погодан је код хоризонталних B2B интеграција; • уговором дефинисана процедура којом једна организација дели податке са другом организацијом. У уговору је дефинисана структура, обим, формат и значење података који се деле, начин дељења података, одговорности у вези са ажурирањем података и администрацијом базе података. Овај оквир сарадње погодан је и код хоризонталних и код вертикалних B2B интеграција; • уговором дефинисана процедура којом једна организација интегрише податке са подацима друге организације на бази заједничког корисничког интерфејса за постављање упита. У уговору је дефинисана структура, обим, формат и значење података који се интегришу, начин интегрисања података, упити који се могу постављати над интегрисаним подацима. Овај оквир сарадње погодан је и код вертикалних и код хибридних B2B интеграција; • уговором дефинисана процедура којом једна организација интегрише своју апликацију са апликацијом друге организације. У уговору је дефинисан начин интегрисања апликација као и списак софтверских сервиса једне организације које може користити друга организација. Овај оквир сарадње погодан је и код свих видова B2B интеграција; • уговором дефинисана процедура креирања и одржавања доменског портала. У уговору су дефинисане апликације и информације које свака организација треба да учини доступним путем портала, као и овлашћења организација у коришћењу апликација и информација на порталу. Овај оквир сарадње истовремено омогућава све видове B2B интеграција, а нарочито је погодан код хибридних B2B интеграција. Модел B2B интеграције саобраћајних пословних система 93 3.1.4.2. Хардвер и софтвер Хардверски и софтверски захтеви решења B2B интеграције делимично су диктирани хардвером и софтвером којим располажу организације које треба интегрисати. Будуће решење B2B интеграције треба да се ослања на постојеће базе података и апликације. То значи да решење треба да се ослања и на постојећи хардвер и постојећа софтверска развојна окружења. Предвиђено решење B2B интеграције значајно ће бити ослоњено на инфраструктуру из облака, тако да не захтева никакве додатне хардверске ресурсе. За потребе B2B интеграције саобраћајних пословних система биће развијене нове базе података. Све нове базе биће релационе и све ће бити креиране у Microsoft- овим релационим системима за управљање базама података (РСУБП). Базе које ће саобраћајне организације постављати на својим серверима биће развијене у РСУБП Microsoft SQL Server 2008. Базе података које треба да омогуће дељење информација развијаће се у Microsoft-овом РСУБП SQL Azure. SQL Azure је део Microsoft-ове Windows Azure платформе, којој се приступа путем Интернет конекције и било ког Web browser-a. SQL Azure база може се креирати директно у SQL Azure платформи, или миграцијом базе из SQL Server 2008 окружења. Закључак је да је једини софтверски захтев, у погледу креирања база података, Microsoft SQL Server 2008. B2B интеграција саобраћајних пословних система обухватиће интеграцију постојећих апликација, али и креирање и интегрисање нових апликација. Нове апликације и сервиси биће креирани у интегрисаном развојном окружењу Microsoft Visual Studio 2010. Ово окружење омогућиће креирање: Windows апликација, ASP.NET Web апликација, WCF Data сервиса i cloud апликација. За развој UML дијаграма користиће се развојно окружење Visual Paradigm for UML 9.0. Радни оквири и модели интероперабилности графички ће бити презентовани унутар развојног окружења Microsoft Office Visio 2003. За развој доменске онтологије користиће се алат Protégé 4.2.0 укључујући његов OntoGraf Plug-in. 3.1.5. Инфраструктура решења Решење B2B интеграције ослањаће се на инфраструктуру постојећих база података и апликација које треба интегрисати, али ће подразумевати и развој нових база података и апликација у cloud computing технолошком окружењу. Инфраструктура решења B2B интеграције зависиће од механизама интеграције које ће да користи то решење. Сваки механизам интеграције подржава другачија архитектура инфраструктуре. Комбиновање механизама интеграције у конкретном решењу B2B интеграције, значи и комбиновање потребних инфраструктурних елемената. Предвиђено је да се предложено решење B2B интеграције реализује у cloud computing технолошком окружењу. Cloud computing окружење омогућава коришћење различитих врста сервиса из облака [108]. У зависности од изабраног Модел B2B интеграције саобраћајних пословних система 94 механизма интеграције користиће се одређена комбинација понуђених сервиса (слика 36): • складиште као сервис (енгл. Storage-as-a-service), • база података као сервис (енгл. Database-as-a-service), • информација као сервис (енгл. Information-as-a-service), • процес као сервис (енгл. Process-as-a-service), • апликација као сервис (енгл. Application-as-a-service), • платформа као сервис (енгл. Platform-as-a-service), • интеграција као сервис (енгл. Integration-as-a-service), • сигурност као сервис (енгл. Security-as-a-service), • управљање као сервис (енгл. Management/governance-as-a-service), • тестирање као сервис (енгл. Testing-as-a-service), • инфраструктура као сервис (енгл. Infrastructure-as-a-service). Слика 36. Компоненте cloud computing технологије Модел B2B интеграције саобраћајних пословних система 95 3.2. Развој модела B2B интеграције саобраћајних пословних система 3.2.1. Анализа постојећих модела Многа истраживања у области саобраћаја и транспорта показују да је размена података неопходна између релевантних саобраћајних и транспортних система. B2B интеграција ових система ће омогућити ефикасну размену неопходних података. У [34] аутори препознају два фактора која проузрокују погрешно доношење одлука у оквиру сектора саобраћаја и транспорта, а то су: knowledge gap i communications gap. У [86] предложен је модел B2B интеграције саобраћајних пословних система заснован на: коришћењу постојећих база података, изменама постојећих Windows апликација развијених у интегрисаном развојном окружењу Microsoft Visual Studio.NET, изменама постојећих Web апликација развијених у интегрисаном развојном окружењу Microsoft Visual Studio.NET, сервисно оријентисаној архитектури, развијању Windows Communication Foundation (WCF) сервиса, хостовању WCF сервиса на IIS, и коришћењу Microsoft технологије адаптера. Cloud computing технолошко окружење пружа разнолике могућности, када је у питању електронско пословање саобраћајних и транспортних организација. Cloud computing одговара потребама у електронском пословању железница у свим сферама које подразумевају дељење података и/или сервиса [91], као што су: • дељење информација и сервиса од јавног значаја, као што су: ред вожње, резервисање места, праћење теретних кола, е-ticketing, јавне набавке; • одржавање и управљање саобраћајном инфраструктуром. Да би одржавање инфраструктуре било ефикасно, предлаже се коришћење система за подршку одлучивању. С обзиром на то да је одржавање саобраћајне инфраструктуре увек у надлежности више организација, рад система за подршку одлучивању мора бити базиран на интероперабилним информационим системима тих организација. Cloud computing омогућава постизање интероперабилности дељењем података и/или сервиса; • повезивање железнице и туризма. Туристичке организације подићиће ниво квалитета својих услуга, уколико су спремне да понуде ажурне информације које се тичу железничког саобраћаја; • подизање нивоа квалитета електронског пословања са владиним сектором; • подизање нивоа квалитета електронског пословања између јавних предузећа која су у свом раду упућена једна на друге; • унапређење система за подршку односа са корисницима; • интегрисање аутономних саобраћајних и несаобраћајних субјеката надлежних у области безбедности саобраћаја, ради подизања нивоа безбедности у саобраћају. У [88] предлажена је интеграција информационих система који се користе на железници у cloud computing технолошком окружењу. Предложени модел интеграције заснован је на сервисно оријентисаној архитектури и комбинацији Модел B2B интеграције саобраћајних пословних система 96 интеграције информација и порталне интеграције. Интеграциона платформа као сервис (енгл. Integration Platform-as-a-Service, iPaaS) је пакет услуга из облака креиран у циљу решавања широког спектра сценарија интеграције: апликација у облацима, B2B интеграција, као и интеграција унутар једног пословног система. У [87, 90, 116] развијена је методологија за примену iPaaS у области саобраћаја и демонстрирана на практичном примеру у области безбедности саобраћаја. Модел B2B интеграције који је предложен у [88] и на практичном примеру демонстриран у [87, 88, 90, 116] не обезбеђује семантичку интероперабилност, што представља значајан недостатак овог решења. У [168] аутори предлажу један модел интеграције ИС у домену железничког саобраћаја, заснован на онтологијама. Овакав модел осим синтаксне, обезбеђује и семантичку интероперабилност железничких ИС. Решење B2B интеграције саобраћајних пословних система, које ће бити предложено у овом раду, подржава семантичку интероперабилност, а реализује се у cloud computing окружењу. 3.2.2. Структура предложеног модела B2B интеграције Предложени модел B2B интеграције саобраћајних пословних система састоји се од следећих компоненти: • К1 – архитектура система B2B интеграције саобраћајних пословних система: − постојећи информациони системи саобраћајних пословних система између којих треба остварити B2B интеграцију; − локалне онтологије саобраћајних пословних система; − доменска онтологија за домен саобраћаја; − механизми B2B интеграције саобраћајних пословних система; − cloud computing платформа B2B интеграције саобраћајних пословних система; • К2 – активности развоја система B2B интеграције саобраћајних пословних система: − анализа саобраћајних пословних система између којих треба остварити B2B интеграцију; − креирање локалне онтологије за сваки саобраћајни пословни систем; − креирање доменске онтологије за домен саобраћаја; − развој сценарија B2B интеграције саобраћајних пословних система; − развој механизама B2B интеграције саобраћајних пословних система; − реализација B2B интеграције саобраћајних пословних система; • К3 – софтверска архитектура система B2B интеграције саобраћајних пословних система: − постојеће Windows и Web апликације које користе саобраћајни пословни системи; − постојеће базе података које саобраћајни пословни системи хостују на својим серверима; − заједничка база података у облаку, хостована на SQL Azure платформи, − Web портал у облаку, хостован на Windows Azure платформи, − WCF Data сервиси у облаку, хостовани на Windows Azure платформи; Модел B2B интеграције саобраћајних пословних система 97 • К4 – сценарији B2B интеграције саобраћајних пословних система: − локална апликација једног саобраћајног пословног система преузима податке из локалне базе другог саобраћајног пословног система позивањем сервиса из облака; − локална апликација једног саобраћајног пословног система преузима податке из заједничке базе података из облака позивањем сервиса из облака; − корисник приступа подацима из заједничке базе података из облака путем корисничког интерфејса локалне апликације која се користи у његовом саобраћајном пословном систему; − корисник путем заједничког корисничког интерфејса – Web портала у облаку, приступа подацима из локалне базе података; − корисник путем заједничког корисничког интерфејса – Web портала у облаку, приступа подацима из заједничке базе података у облаку; − корисник путем заједничког корисничког интерфејса – Web портала у облаку, креира упите који се извршавају над интегрисаним подацима који потичу из више локалних база података. Резултати упита приказују се унутар истог корисничког интерфејса. • К5 – методе B2B интеграције саобраћајних пословних система: − дељење информација; − размена информација; − интеграција информација; − интеграција апликација; − портална интеграција. • К6 – временско планирање реализације модела. На слици 37 приказане су компоненте од којих се састоји модел B2B интеграције саобраћајних пословних система. Слика 37. Компоненте предложеног модела B2B интеграције саобраћајних пословних система На слици 38 представљена је детаљна структура сваке од компоненти модела B2B интеграције, као и међусобне везе између компоненти модела. Модел B2B интеграције саобраћајних пословних система 98 Слика 38. Детаљна структура предложеног модела B2B интеграције саобраћајних пословних система 3.2.3. Архитектура предложеног система B2B интеграције Архитектуру cloud computing платформе за B2B интеграцију саобраћајних пословних система чине следеће компоненте: Модел B2B интеграције саобраћајних пословних система 99 • заједничка база података хостована на SQL Azure платформи, • Web портал хостован на Windows Azure платформи: − кориснички интерфејс за приступ заједничкој бази података; − кориснички интерфејс за приступ локалним базама података; − кориснички интерфејс за генерисање упита над интегрисаним подацима из више локалних база података и приказивање резултата упита; • WCF Data сервиси за преузимање података из заједничке базе података, хостовани на Windows Azure платформи; • WCF Data сервиси за преузимање података из локалних база података, хостовани на Windows Azure платформи; • WCF Data сервиси за трансформацију упита хостовани на Windows Azure. Архитектура система B2B интеграције саоб. посл. сис. приказана је на слици 39. Слика 39. Архитектура система B2B интеграције саобраћајних пословних система Модел B2B интеграције саобраћајних пословних система 100 3.2.4. Активности развоја система B2B интеграције 3.2.4.1. Анализа постојећих информационих система Анализа постојећег информационог система који користи неки саобраћајни пословни систем, састоји се од следећих активности (слика 40): • анализа хардверске инфраструктуре, • анализа софтверске инфраструктуре, • анализа реалног система који је моделиран базом података, • анализа релација посматраног пословног система са осталим субјектима из домена, • дефинисање захтева у погледу B2B интеграције. Слика 40. Дијаграм активности: Анализа постојећег информационог система Анализа постојећих информационих система први је корак у развоју новог, заједничког информационог модела. Процес стварања информационог модела започиње упознавањем са подацима, јер су подаци основа за већину информационих система. Упознавање са подацима је и добар начин да се дефинише шта ови системи раде, пре него што их потенцијално преселимо у облак. Циљ је да се разуме постојеће стање података, да се дефинишу подаци на детаљном нивоу, а затим коначна будућа архитектура података, која нам Модел B2B интеграције саобраћајних пословних система 101 омогућава да схватимо које податке треба сместити на локалне сервере, а које на cloud computing платформе. Целокупна анализа спроводи се из угла примене СОА са новим архитектонским опцијама cloud рачунарства. То значи да треба да се одреди: где се подаци тренутно налазе, структура података, логички модел, физички модел, да се реше безбедносна питања, дефиниције података, итд. Како се крећемо кроз овај процес, идемо од специфичних система и/или примена специфичних података, ка формалном информационом моделу који обухвата домен проблема (слика 41). На крају овог процеса, добијамо ниво метаподатака и заједнички информациони модел. Први корак у идентификовању и лоцирању информација о подацима је да се направи листа система у домену проблема. Ова листа омогућава да се утврди какве базе података постоје у оквиру тих система. Следећи корак захтева утврђивање власника база података, њихових физичких локација, релевантних информација, дизајна и основних информација као што су: бренд, модел и последња ревизија технологије базе података. Неопходно је креирати речник саобраћајних података, који ће бити база свих метаподатака и других споменутих информација о подацима. То се мора урадити за сваки систем појединачно, јер су у многим случајевима ови системи толико различити да је тешко наћи заједнички скуп особина за праћење података у речнику. Информације које се обично прате обухватају: разлог за постојање одређених елемената података, власништво, формат, безбедносни параметри, њихова улога у логичкој и физичкој структури података. Када се анализира база података која је кандидат за cloud computing, стално се намећу питања интегритета података. Да би се одговорило на ова питања, важно је разумети правила и логику која је примењена у изградњи базе података. Кашњење података, као карактеристика података која дефинише колико тренутна информација треба да буде ажурна, је још једна од карактеристика података која се мора утврдити пре преношења на cloud computing. Таква информација омогућава архитекти да утврди када би информације требало да се копирају или преместе из облака на локални сервер предузећа, или са локалног сервера у облак, и колико брзо. Иако постоји велики број различитих категорија кашњења података, за cloud computing архитектуру релевантне су само три: у реалном времену, у приближно реалном времену, на неко време. Каталогизација саобраћајних података представља формализовање информација прикупљених у претходна два корака, укључујући и речник података. Разлика је у томе што су речници података типично локалног карактера, тј. односе се на један систем или апликацију, док каталог података обухвата све системе у домену. Пре изградње саобраћајног информационог модела, морамо направити каталог од свих података претходно дефинисаних у речницима података. Добар каталог података треба да садржи све елементе података о свим системима, као што су: опис, власништво, систем, формат, безбедносни параметри, параметри интегритета, зависности. Резултујући каталог постаје језгро будућег информационог модела. Када се све информације о свим подацима у предузећу налазе у каталогу података, време је да се фокусирамо на модел метаподатака предузећа, или оно што зовемо саобраћајни информациони модел. Разлика између ова два понекад је Модел B2B интеграције саобраћајних пословних система 102 незнатна. Најлакше их је разликовати ако под каталогом података подразумевамо списак потенцијалних решења посматраног архитектонског проблема, а да под информационим моделом подразумевамо коначно решење архитектуре података. E x te rn a l T ra ff ic S a fe ty M e ta d a ta (B 2 B ) Сопствени мета подаци Друмски саобраћај Железнички саобраћај Водни саобраћај Ваздушни саобраћај Министарство унутрашњих послова Јавни здравствени информациони систем B2B Разумевање саобраћајних података Креирање каталога саобраћајних података Речник саобраћајних података и метаподаци Каталог саобраћајних података Изградња саобраћајног информационог модела Саобраћајни информациони модел Владина Агенција за безбедност саобраћаја Е кс те р н и с а о б р а ћ а јн и м е та п о д а ц и (B 2 B ) Сопствени мета подаци Сопствени мета подаци Сопствени мета подаци Сопствени мета подаци Сопствени мета подаци Сопствени мета подаци Слика 41. Креирање саобраћајног информационог модела 3.2.4.2. Креирање локалних онтологија и доменске онтологије Локална онтологија има за циљ да опише знање релевантно за домен пословања посматраног саобраћајног пословног система. Фаза креирања локалних онтологија еквивалентна је фази креирања речника и каталога саобраћајних података. Стога је ове две фазе најбоље реализовати паралелно. Један од начина који омогућава ефикасно креирање локалне онтологије је на основу шеме локалне базе података. Уколико одређени систем користи више база података, оне морају бити обједињене унутар локалне онтологије. Активности од којих се састоји креирање онтологије приказане су на слици 42. Модел B2B интеграције саобраћајних пословних система 103 Слика 42. Дијаграм активности: Креирање онтологије Креирање локалне/доменске онтологије подразумева следеће активности: • избор начина креирања онтологије: − креирање од почетка („од нуле”), − креирање од постојећих онтологија: инклузија, рестрикција, прецизирање, − креирање мапирањем шеме релационе базе података, • дефинисање класа, • дефинисање релација између класа, • дефинисање својстава која могу имати примерци класа, Модел B2B интеграције саобраћајних пословних система 104 • дефинисање примерака класа, • дефинисање вредности својстава примерака класа. 3.2.4.3. Развој сценарија B2B интеграције Сценарио 1: локална апликација једног саобраћајног пословног система преузима податке из локалне базе другог саобраћајног пословног система позивањем сервиса из облака (слика 43). Слика 43. Дијаграм секвенци: Сценарио 1 B2B интеграције саобраћајних пословних система Сценарио 2: локална апликација једног саобраћајног пословног система преузима податке из заједничке базе података из облака позивањем сервиса из облака (слика 44). Слика 44. Дијаграм секвенци: Сценарио 2 B2B интеграције саобраћајних пословних система Сценарио 3: корисник приступа подацима из заједничке базе података из облака путем корисничког интерфејса локалне апликације која се користи у његовом саобраћајном пословном систему (слика 45). Модел B2B интеграције саобраћајних пословних система 105 Слика 45. Дијаграм секвенци: Сценарио 3 B2B интеграције саобраћајних пословних система Цсенарио 4: корисник путем заједничког корисничког интерфејса – Web портала у облаку, приступа подацима из локалне базе података (слика 46). Слика 46. Дијаграм секвенци: Сценарио 4 B2B интеграције саобраћајних пословних система Цсенарио 5: корисник путем заједничког корисничког интерфејса – Web портала у облаку, приступа подацима из заједничке базе података у облаку (слика 47). Слика 47. Дијаграм секвенци: Сценарио 5 B2B интеграције саобраћајних пословних система Модел B2B интеграције саобраћајних пословних система 106 Цсенарио 6: корисник путем заједничког корисничког интерфејса – Web портала у облаку, креира упите који се извршавају над интегрисаним подацима који потичу из више локалних база података. Резултати упита приказују се унутар истог корисничког интерфејса (слика 48). Слика 48. Дијаграм секвенци: Сценарио 6 B2B интеграције саобраћајних пословних система Доменска онтологија креира се са циљем да представи знање релевантно за посматрани домен. Активности од којих се састоји креирање доменске онтологије идентичне су активностима од којих се састоји креирање локалних онтологија. Једина разлика је у избору начина креирања онтологије. Најефикаснији начин креирања локалних онтологија је мапирање шема база података. Најефикаснији начин креирања доменске онтологије је креирање од постојећих локалних онтологија. Приликом креирања доменске онтологије морају се узети у обзир класе из свих локалних онтологија, везе између њих и сва својства класа. Доменска онтологија треба да репрезентује и релације које у реалном свету постоје између концепата локалних онтологија. Два саобраћајна пословна система могу изабрати и више сценарија B2B интеграције. Избор сценарија интеграције зависи од природе пословних односа и узајамне зависности два саобраћајна пословна субјекта, односно од дефинисаних захтева B2B интеграције. Уколико постоји више захтева B2B интеграције између два саобраћајна пословна субјекта, за сваки захтев изабраће се најпогоднији сценарио интеграције. 3.2.4.4. Развој механизама B2B интеграције Сви предвиђени сценарији B2B интеграције могу се декомпоновати тако да се реализују уз помоћ следећих механизама B2B интеграције: • локална апликација приступа локалним подацима (слика 49), Модел B2B интеграције саобраћајних пословних система 107 • локална апликација приступа подацима у облаку (слика 50), • локална апликација позива сервис из облака (слика 51), • сервис из облака приступа локалним подацима (слика 52), • сервис из облака приступа подацима из облака (слика 53), • сервис из облака позива сервис из облака (слика 54). Локална апликација приступа локалним подацима База података ` PC Десктоп апликација Сервер базе података Web сервис Web сервер Firewall Firewall Слика 49. Локална апликација приступа локалним подацима Локална апликација приступа подацима у облаку Слика 50. Локална апликација приступа подацима у облаку Модел B2B интеграције саобраћајних пословних система 108 Локална апликација позива сервис из облака Слика 51. Локална апликација позива сервис из облака Сервис из облака приступа локалним подацима Слика 52. Сервис из облака приступа локалним подацима Модел B2B интеграције саобраћајних пословних система 109 Сервис из облака приступа подацима из облака и позива сервис из облака 3.2.4.5. Реализација система B2B интеграције На слици 55 приказане су активности од којих се може састојати реализација система B2B интеграције саобраћајних пословних система. Реализација система B2B интеграције за сваки појединачни пар саобраћајних пословних система зависи пре свега од изабраног сценарија интеграције. Избор једног или више сценарија B2B интеграције одређује скуп активности у току процеса реализације система B2B интеграције. Модел B2B интеграције саобраћајних пословних система 110 Креирање локалних онтологија Креирање доменске онтологије Креирање правила мапирања између локалних и доменске онтологије Избор сценарија B2B интеграције Анализа захтева B2B интеграције два саобраћајна пословна субјекта Реализација механизама B2B интеграције Креирање заједничке базе података „у облаку“ Развој сервиса „у облаку“ за преузимање података из локалних база Развој сервиса „у облаку“ за преузимање података из заједничке базе података „у облаку“ Развој сервиса „у облаку“ за трансформацију упита из језика доменске онтологије у језик локалне онтологије Развој Web портала „у облаку“ Повезивање локалних апликација са сервисима „у облаку“ Повезивање локалних апликација са сервисима „у облаку“ Развој корисничког интерфејса за генерисање упита језиком доменске онтологије Развој корисничког интерфејса за приступање заједничкој бази „у облаку“ Развој корисничког интерфејса за приступање локалним базама Повезивање сервиса за трансформацију упита и сервиса за преузимање података из локалних база Слика 55. Дијаграм активности: Реализација система B2B интеграције саобраћајних пословних система 3.2.5. Методе B2B интеграције саобраћајних пословних система С обзиром на природу пословних односа између саобраћајних пословних система и чињеницу да је посматрани саобраћајни домен затвореног типа, изабране су Модел B2B интеграције саобраћајних пословних система 111 следеће методе B2B интеграције: дељење информација, преузимање информација, интеграција информација, интеграција апликација и портална интеграција. 3.2.5.1. Дељење информација Дељење информација је метода B2B интеграције код које два пословна субјекта користе заједничке изворе података. Ова метода B2B интеграције може се реализовати на више начина: • развојем заједничке јединствене базе података: − база података хостована на серверу једне од организација укључених у B2B интеграцију; − база података хостована на cloud computing платформи (слика 56). • заједничким коришћењем постојеће базе података коју је развио и администрира један од пословних система: − приступ бази помоћу заједничког корисничког интерфејса; − приступ бази помоћу сопственог корисничког интерфејса. Data Data Data Data Data Data SQL Azure база података Слика 56. Интегрисање информација о безбедности саобраћаја у заједничкој бази података у облаку Модел B2B интеграције саобраћајних пословних система 112 У заједничкој бази података биле би обједињене следеће категорије података: • подаци о саобраћајној инфраструктури, • подаци о саобраћајним незгодама, • подаци о возилима учесницима незгода, • подаци о лицима учесницима незгода, • подаци о последицама незгода по здравље учесника, • подаци о томе ко је одговоран за саобраћајну незгоду, • подаци о одлучујућим факторима, узрочницима, висини материјалне штете; Кориснички интерфејс за приступ заједничким изворима података може бити: Web апликација и Windows апликација. Дељење информација има следеће димензије (табела 4): • место складиштења извора података, • власништво над извором података који користи више пословних субјеката, • власништво над апликацијом уз помоћ које се приступа заједничком извору података, • врста апликације уз помоћ које се приступа заједничком извору података, • корисничка овлашћења над дељеним информацијама. Табела 4. Димензије дељења информација као методе B2B интеграције Димензија методе B2B интеграције Вредности димензије Место складиштења извора података Локални сервер једног од субјеката B2B интеграције Сервер база података на cloud computing платформи Власништво над извором података Власништво једног субјекта B2B интеграције Заједничко власништво Власништво над апликацијом за приступ подацима Власништво једног субјекта B2B интеграције Заједничко власништво Врста апликације за приступ подацима Windows апликација Web апликација Корисничка овлашћења над дељеним информацијама Прегледање података без могућности ажурирања Потпуно или делимично овлашћење за ажурирање података 3.2.5.2. Преузимање информација Преузимање информација је метода B2B интеграције код које апликација једног субјекта преузима податке из базе података другог субјекта. Разлика између дељења и преузимања информација састоји се у томе што код дељења података Модел B2B интеграције саобраћајних пословних система 113 сви субјекти користе податке у изворној структури и формату, док код преузимања података, може по потреби да дође и до трансформације и обраде података. Преузимање информација је сложенија метода B2B интеграције, јер обавезно укључује коришћење додатног софтвера за преузимање података. Тај додатни софтвер може бити Web апликација или Web сервис, а може се хостовати на локалном Web серверу или на cloud computing платформи. Софтвер за преузимање података може бити у власништву оног пословног субјекта који обезбеђује податке, или у власништву субјекта који преузима податке, или у заједничком власништву. Сложеност методе преузимања података зависи од тога да ли се подаци преузимају у изворном облику, или се преузети подаци трансформишу пре коришћења. Сложеност методе огледа се и у начину коришћења преузетих података. Постоје два приступа у коришћењу преузетих података. Један приступ подразумева да се преузети подаци складиште у сопственој бази података, без икакве обраде. Други приступ подразумева да се преузети подаци на неки начин обрађују, или да се над њима генеришу одређени извештаји, без складиштења у базу података. Метода преузимања информација има следеће димензије: • врста софтверске компоненте која се користи за преузимање података: − Web апликација; − Web сервис; • место хостовања софтвера за преузимање података: − локални Web сервер; − cloud computing платформа; • начин коришћења преузетих података: − складиштење у сопствену базу података; − обрада, израчунавања, генерисање извештаја над подацима, без складиштења у сопствену базу података; • постојање мапирања података: − преузети подаци се не мапирају; − преузети подаци се мапирају, коришћењем дефинисаних правила мапирања између две онтологије; • место на коме се врши мапирање података, уколико за њим постоји потреба: − у изворном чвору, тј. у информационом систему од кога се преузимају подаци; − у одредишном чвору, тј. унутар софтвера који преузима податке; • власништво над софтвером за преузимање података: − власништво оног субјекта B2B интеграције који обезбеђује податке; − власништво оног субјекта B2B интеграције који преузима податке; − заједничко власништво више заинтересованих субјеката; • периодичност преузимања података: − унапред дефинисана учесталост и време преузимања података; Модел B2B интеграције саобраћајних пословних система 114 − подаци се преузимају „ad hoc”, тј. у произвољном временском тренутку и према потреби. Преузимање информација, као метода B2B интеграције има димензије дате у табели 5. Табела 5. Димензије преузимања информација као методе B2B интеграције Димензија методе B2B интеграције Вредности димензије Врста софтверске компоненте која се користи за преузимање података Web апликација Web сервис Место хостовања софтвера за преузимање података Локални Web сервер Cloud computing платформа Начин коришћења преузетих података Складиштење у сопствену базу података Обрада података без складиштења у сопствену базу података Постојање мапирања података Преузети подаци се не мапирају Преузети подаци се мапирају, коришћењем дефинисаних правила мапирања између две онтологије Место на коме се врши мапирање података У изворном чвору, тј. у информационом систему од кога се преузимају подаци У одредишном чвору, тј. унутар софтвера који преузима податке Власништво над софтвером за преузимање података Власништво оног субјекта B2B интеграције који обезбеђује податке Власништво оног субјекта B2B интеграције који преузима податке Заједничко власништво више заинтересованих субјеката Периодичност преузимања података Унапред дефинисана учесталост и време преузимања података Подаци се преузимају у произвољном временском тренутку и према потреби 3.2.5.3. Интеграција информација Интеграција информација је метода B2B интеграције код које се из различитих извора података обједињују информације различите према концептуалном, контекстуалном и типографском представљању. Ова метода B2B интеграције сложенија је од метода дељења и преузимања информација. Сложеност методе огледа се у различитим равнима: • раван типа извора података, • раван формата података, • раван модела података, • раван значења (семантике) података. Модел B2B интеграције саобраћајних пословних система 115 Често је потребно интегрисати податке из потпуно различитих типова извора података: релационих база података, Microsoft Office Excel датотека, текстуалних датотека... Међу изворима који се сврставају у релационе базе података постоји мноштво подтипова: Microsoft SQL Server, Microsoft Office Access, PostgreSQL, MySQL, Oracle... Сваки од наведених релационих система за управљање базама података доживео је много верзија, што посао интеграције чини још сложенијим. Подаци који се интегришу често су некомпатибилни према формату, тј. типу података. Нпр. један податак је у једном извору података нумеричког типа, а у другом извору текстуалног типа. Или, исти податак у једном извору података је цео број, а у другом извору реалан број. Чест проблем је различита дозвољена дужина (број карактера) код текстуалних података. Сваки извор података креира се према сопственом моделу података. То за последицу има да је један податак у једном моделу ентитет, а у другом моделу атрибут. Релације између ентитета и референцијални интегритет су најсложенији проблеми које треба решити приликом интеграције информација. Подаци који се интегришу морају бити компатибилни и према значењу. На нивоу семантике података постоје следеће карактеристичне ситуације: • два концепта у два модела података имају идентичне називе, али различито значење, • два концепта у два модела података имају исто значење, а различите називе, • два податка у два модела података имају идентичне вредности, али се односе на различите појмове из реалног света, • два податка у два модела података имају различите вредности, али се односе на идентичне појмове из реалног света, различито моделиране. Приликом интеграције информација, осим синтаксне и концептуалне, потребно је остварити и семантичку интероперабилност. На пољу интероперабилности најкомплекснији су проблеми семантичке интероперабилности. У овом моделу B2B интеграције предложен је метод постизања семантичке интероперабилности заснован на коришћењу заједничког корисничког интерфејса за постављање упита над више обједињених извора података. Овај метод интеграције информација познат је под називом интеграција вођена упитима. На слици 57 приказана је архитектура система који омогућава интеграцију вођену упитима. Овај метод семантичке интеграције састоји се од следећих фаза: • креирање локалних онтологија на основу шема података локалних извора података, • креирање доменске онтологије, обједињавањем локалних онтологија, • дефинисањем правила мапирања између доменске и локалних онтологија, • развој заједничког корисничког интерфејса за генерисање упита над више обједињених извора података, Модел B2B интеграције саобраћајних пословних система 116 • развој софтверских компоненти за декомпозицију и превођење упита дефинисаног речником доменске онтологије на упите дефинисане речником локалних онтологија, • развој софтверских компоненти за компоновање резултата упита. Слика 57. Интеграција информација вођена упитима 3.2.5.4. Интеграција апликација Интеграција апликација је размена информација и/или сервиса између апликација. Овај метод B2B интеграције најчешће обједињује неке од претходно описаних метода B2B интеграције. Интеграција апликација истовремено може да обезбеди: дељење информација, размену информација и интеграцију информација. Метода интеграције апликација има следеће димензије: • врсте апликација које се интегришу: Windows апликације и Web апликације, • место хостовања апликација које се интегришу: локални Web сервер и cloud computing платформа, Модел B2B интеграције саобраћајних пословних система 117 • начин реализације интеграције апликација: − сервисно-оријентисана архитектура и Web сервиси, − позивање удаљених процедура (енгл. Remote Procedure Call, RPC), − средњи слој заснован на порукама (енгл. Message Oriented Middleware, МОМ). 3.2.5.5. Портална интеграција Портална интеграција може да обједини све претходно набројане методе B2B интеграције. То је најфлексибилнији метод B2B интеграције због тога што је најмање осетљив на промене на апликацијама и изворима података који се интегришу. Важна питања, тј. димензије порталне интеграције су: • функционалности које обезбеђује портал: − дељење информација, − преузимање информација, − интеграција информација, − дељење сервиса, − персонализација, − креирање дискусионих група, − креирање виртуелних удружења, − креирање фото-галерија. • место хостовања портала: локални Web сервер и cloud computing платформа, • тип Web портала: − хоризонтални портал: пружа информације и сервисе из разних области, − вертикални портал: пружа информације и сервисе из једне области, разврстане по секцијама и нивоима, • врста Web портала према намени: − информативни портали, − портали за претраживање, − персонални, − регионални, − владини, − корпоративни. Предложени модел B2B интеграције подразумева развој Web портала следећих карактеристика: • вертикални Web портал, • хостован на cloud computing платформи, • регионални – намењен удружењу организација (Community Cloud), • обезбеђује: дељење информација, преузимање информација, интеграција информација, дељење сервиса, интеграција апликација. Модел B2B интеграције саобраћајних пословних система 118 3.3. Технолошко окружење за реализацију развијеног модела 3.3.1. Cloud computing технологија Предложени модел B2B интеграције саобраћајних пословних система реализоваће се у cloud computing технолошком окружењу. Технологија облака или рачунарство облака (енгл. Cloud Computing) је назив који је настао као метафора за нешто што се дешава на Интернету – облаку. То може бити нека услуга у виду софтвера (пословна апликација) или хардвера (складиштење података, процесорска снага ) чија физичка локација није позната, број сервера који се користе за ту услугу није познат, њихова инфраструктура такође није позната, могу бити у истој згради или на различитим континентима [118]. Поставља се питање ште је поента у том знању или још боље речено – незнању. Поента је да то знање није ни потребно. О томе се брине облак. Једина брига корисника облакa је да мора бити повезан на Интернет и да мора имати Web browser на свом рачунару да би могао да користи облак [21]. Облак се налази свугде око нас, а већина људи вероватно ни не зна да скоро свакодновно користи облак. Када желимо да проверимо пошту користимо Gmail, када желимо да се забавимо користимо Facebook, када желимо да одгледамо неки видео и слушамо музику користимо Youtube, када желимо да се едукујемо користимо Википедију… Ако би наставили са набрајањем листа би постала веома дуга. Све набројане Web апликације и сервиси су разноврсне и другачије, али једна ствар их повезује, то је облак. На блогу James Governor-а, познатог аналитичара софтверске индустрије, налази се занимљива дефиниција шта је то технологија облака, односно шта није технологија облака [70]. Оригинално, аутор James Governor издвојио је 15 ставова који описују шта је то што није технологија облака. Неки од њих су: • Ако не можете да се повежете са вашим рачунаром... то није облак. • Ако морате да инсталирате неки софтвер… то није облак. • Ако покушају да Вам продају неки хардвер… то није облак. • Ако не постоји API (Аpplication Programming Interface)... то није облак. • Ако је потребно више од 10 минута за испоручивање… то није облак. • Ако Ви поседујете комплетан хардвер… то није облак. • Ако је ограничено на један оперативни систем… то није облак. Тржиште информационих технологија сигурно је најдинамичније тржиште од свих осталих. Разлог за то је константан раст, развој и налажење нових примена информационих технологија. Технологија облакa је настала као прирадан процес прилагођавања потребама таквог динамичног тржишта [144]. Већина тих потреба и проблема је постојала и раније, и идеја технологије облакa такође није нова, међутим растом Интернета и појавом концепта Web 2.0 створили су се услови за реализацију те идеје [5]. Модел B2B интеграције саобраћајних пословних система 119 Идеја технологије је једноставна. Она доноси нешто што је у информационим технологијама одувек било потребно: повећање капацитета или додавање нових могућности „у лету”, без додатних улагања у инфраструктуру и запошљавања и обучавања нових кадрова. Из корисничког угла ствари су такође једноставне. Једини захтеви су Web browser, Интернет веза и пријава на облак [143]. То је све што је кориснику потребно да било када и са било које локације користи све услуге и могућности које се испоручују из облака. Корисник не мора да брине да ли поседује најновију верзију софтвера. Иако је још увек у својој почетној фази, технологија облакa заснива се на већ провереним трендовима и све више и више компанија се одлучујују да своје услуге пребаце на облак [113]. То не значи да алтернативе технологији облакa неће опстати на тржишту. Заправно само онај део тржишта који решење својих проблема види у облаку ће прећи или је већ прешао на технологију облакa, док ће онај други део тржишта остати на ономе што је и до сада користио. 3.3.1.1. Софтвер као сервис Технологија облакa обухвата и софтверске и хардверске услуге. Софвер као сервис (енгл. Software as a Service, SaaS) је назив који се односи на софтерске услуге у облаку. Треба напоменути да SaaS представља општи назив за модел испоручивања софтвера сао сервиса и не користи се само у технологији облакa, већ се може срести и код других технологија. Карактеристике SaaS-а су [65]: • испорука преко Web-а, • плаћање по употреби, • централизована подршка. Испорука преко Web-а Софвер као сервис – SaaS, је на Web-у базирани модел испоручивања софтвера који омогућује да софтвер буде потпуно доступан коришћењем само Web browser- а [137]. Корисник SaaS софтвера не мора да инсталира никакав додатни софтвер на својој машини, не мора да зна где је софтвер физички лоциран, који оперативни систем користи и на ком је програмском језику написан [182]. Корисник треба да буде повезан на Интернет и да има инсталиран Web browser. Обично се пре коришћења сервиса у облаку захтева регистрација корисника, а уколико је корисник већ регистрован онда се захтева само његово пријављивање. Плаћање по употреби Главна разлика у односу на друге моделе испоручивања софтвера је у начину наплате. Концепт наплате у SaaS моделу је наплата по коришћењу. То значи да укупна цена није фиксна већ се мења, у зависности од утрошене процесорске снаге, простора, меморије и протока. Унапред је одређена цена по квантуму услуге и плаћа се само онолико колико се потроши [153]. На тај начин може се доћи до значајних уштеда. Модел B2B интеграције саобраћајних пословних система 120 Централизована подршка Подршка код SaaS модела је централизована што представља велику предност. То значи да сви корисници раде на истој апликацији и уколико се уоче проблеми или недостаци, они се решавају на нивоу целог система а не на нивоу поједначног корисника [61]. Најједноставнији SaaS пример је Gmail. Gmail је програм за електронску пошту коме приступамо помоћу Web browser-а. Исту функционалност омогућује као и Outlook или Apple mail програм, с тим што за разлику од Gmail-а они захтевају инсталацију посебног софтвера на рачунару. SaleseForce.com је пример комерцијалне варијанте софтвера као сервиса. Mark Benioff, један од бивших руководиоца Oracle-а, је 1999. године основао компанију SaleseForce чији је основни мото „Успех на захтев” (енгл. „Success on Demand”). SaleseForce.com је софтвер намењен великим предузећима и служи за одржавање односа са купцима познатији под називом CRM (Customer Relationship Managment Software). За коришћење овог софтвера је као и за Gmail поребан само Web browser, једина разлика је што SaleseForce није бесплатан. Клијент Клијент представља лагани алат помоћу кога се корисници повезују на облак [185]. Клијент обично представља Web browser као на пример Mozilla Firefox или Internet Explorer. Не треба заборавити и новајлију у свету Web browser-а, Google Chrome, чије су амбиције много веће. Компанија Google планира да лансира нови опертивни систем заснован на технологији „облакa” коме ће се приступати помоћу Chrome-а. Клијент не мора бити само Web browser, клијенти могу бити и widget-и на мобилним уређајима. Apple iPhone и Google Androide платформе у себи имају апликације које се користе из облакa помоћу widget-а. Поред widget-а клијенти могу бити чак и други сајтови. Класичан пример коришћења сајта као клијента су Facebook апликације. Постоји доста апликација које нису направљене у оквиру самог сајта Facebook-а, међутим корсник помоћу Facebook-а може приступити жељеној апликацији. 3.3.1.2. Инфраструктура као сервис Инфрастриктура као сервис (енгл. Infrastructure as a service, IaaS) је назив који се односи на испоручивање инфраструктуре као сервиса. У то спадају: сервери, процесорска снага, меморија, простор на диску, мрежна опрема и остали ресурси рачунарских центара. Главне карактеристике IaaS-а су: • хардвер, • виртуелизација, • плаћање по употреби, • мрежна опрема, • излаз на интернет. Модел B2B интеграције саобраћајних пословних система 121 Хардвер Физичка компонента инфраструктуре облакa је хардвер. Под хардвером се подразумевају сервери, који се данас масовно производе и чија појединачна цена не мора бити велика. Виртуелизација Кључна реч код инфраструктуре облакa је виртуелизација. Сви сервери у облаку су виртуелизовани и понашају се као једна машина [136]. Тачан број сервера унутар фарме сервера је неважан. Више има смисла посматрати окружење као целину у коме се различите апликације боре за ресурсе, а да не морају да воде рачуна о томе да ли ће имати довољно ресурса. Што се више ресурса потроши компаније које пружају услуге из облакa више зарађују, па им је самим тим у интересу да обезбеде што је више могуће ресурса. Помоћу виртуелизације постиже се максимална хоризонтална скалабилност ресурса. Плаћање по употреби Уместо да купују сопствене сервере, софтвер, мрежну опрему и остале компоненте информационог система, корисници то препуштају некој другој компанији чији је то посао. Корисници плаћају оно што користе али само онолико колико користе. Мрежна опрема Под мрежном опремом подразумевају се firewall-ови, load balancer-и, router-и, switch-еви и остале мрежне компоненте које су неопходне за функционисање облака. Излаз на интернет Облак не може бити облак ако нема излаз на Интернет. Дакле, излаз на Интернет представља неопходну компоненту инстраструктуре облака. 3.3.1.3. Платформа као сервис Платформа као сервис (енгл. Platform as a Service, PaaS) је назив који означава модел испоручивања оперативних система као сервиса заједно са осталим сервисима, путем интернета, без скидања и инсталације [132]. PaaS је познат и под називом cloudware. PaaS нуди различите комбинације сервиса у облаку за подршку свих фаза развојног циклуса апликације. Ти сервиси могу бити: интегрисано развојно окружење, контрола изворног кода, контрола верзија, праћење измена кода, интерактивни тестови за више корисника, подршка за развој апликација са богатим корисничким интерфејсом (енгл. Rich Internet Application, RIA), подршка за сарадњу и управљање развојног тима. PaaS је посебно згодан када се развојни Модел B2B интеграције саобраћајних пословних система 122 тим састоји од чланова који се налазе на различитим географским локацијама. PaaS решења су развојне платформе у којима су развојни алати смештени у облаку и којима се приступа помоћу Web browser-а. Са PaaS-ом, пројектанти могу да граде апликације без инсталирања било каквих алата на својим рачунарима и могу испоручивати апликације без специјализованих вештина за администрацију система. На слици 58 приказане су надлежности понуђача сервиса из облака и клијента, у зависности од изабране врсте услуге cloud computing платформе. Слика 58. Надлежности понуђача и клијента у зависности од услуге платформе 3.3.1.4. Недостаци cloud computing технологије Како ниједан концепт није савршен, тако и технологија облака има своје мане. Према [112] главне мане технологије облака су: • зависност, • сигурност и Оперативни систем Оперативни систем Оперативни систем Оперативни систем Апликација Апликација Апликација Апликација Подаци Подаци Подаци Подаци Извршавање Извршавање Извршавање Извршавање Развојно окружење Развојно окружење Развојно окружење Развојно окружење Сервер Сервер Сервер Сервер Диск Диск Диск Диск Мрежна инфраструктура Мрежна инфраструктура Мрежна инфраструктура Мрежна инфраструктура Решења ван облака Инфраструктура као сервис Платформа као сервис Софтвер као сервис Модел B2B интеграције саобраћајних пословних система 123 • недостатак референци. Зависност Компаније које користе технологију јавног облака ослањају се на компаније које пружају те услуге, и то је можда најкритичнија тачка технологије облака. Компаније су потпуно зависне од дистрибутера или продавца технологије облака. Једино решење у случају пада дистрибутера облака је правовремени прелазак на стабилнијег дистрибутера. С обзором на централизовану архитектуру апликација у облаку, план опоравка који подразумева транзицију на другог дистрибутера не би требао буде скуп и компликован али ипак захтева одређено време. Компанија која пружа услуге технологије облака мора бити веома поуздана и мора гарантовати да интерни проблеми у компанији не смеју утицати на рад клијената. То је јако тешко остварити у пракси и јако је мали број компанија које то стварно могу гарантовати. Сигурност Безбедно чување битних података одувек је било важно питање у информационим технологијама. У технологији облака у којој је подацима могуће приступити изван виртуелних сигурносних зидова система, доводи се у питање безбедност тих података [184]. Коришћење Web browser-а у случају немарних кориника облака може бити лака мета за крађу података. Степен сигурности и заштите дистрибутера облака је веома битан елеменат. Продавац облака мора гарантовати приватност података. Продавац облака мора гарантовати да подаци не смеју бити изгубљени. У било ком случају сигурносног пропуста може се десити да се ситуација више никада не може поправити, а тако нешто се не сме дозволити [155]. Недостатак референци Баш због питања очувања приватности и сигуности, продавци облака или не желе, или нису у стању да износе детаље о компанијама које користе њихове услуге. Заправо, јако мали број великих компанија уопште објављује било какве извештаје на високом нивоу о употреби технологије облака. Ово је довело до тога да се створи осећај стидљивог коришћења технологије облака иако је сам назив технологије облака постао веома популаран и познат у модерној техничкој терминологији у свету. Дакле, због проблема сигурности, транзитивно се долази и до проблема недостатка референци о употреби технологије облака. 3.3.1.5. Предности cloud computing технологије Као и свака друга технологија, концепт технологије облака је настао из потребе за решавањем одређених проблема, па самим тим засигурно има и својих значајних предности. Технологија облака конципирана је на ефикасности, изнад свега. Главне предности технологије облака су: флексибилност, скалабилност, уштеда и портабилност [151]. Модел B2B интеграције саобраћајних пословних система 124 Флексибилност Изнајмљивање сервера у облаку уместо куповине сервера може значајно допринети флексибилности у техничком смислу. Компаније помоћу технологије облака добијају додатне могућности које не могу имати са инфраструктуром коју поседују. Могу тачно да одреде колико снаге и колико простора ће им бити потребно и тако цео систем да прилагоде тренутним потребама, без великих напора. Процес ажурирања софтвера такође се може заначајно убрзати и подспешити коришћењем технологије облака. Администратори могу у реалном времену да ажурирају софтвер на нивоу комплетног система, без обиласка свих рачунара појединачно како би инсталирали последњу верзију софтвера. На тај начин се долази до вишеструких уштеда како са стране функционалности комплетног система, тако и са стране времена потребног администраторима да инсталирају најновију верзију софтвера. Скалабилност Ова особина је у свакој технологији, одувек била јако битна. Апликације у технологји облака имају могућност да се јако брзо прилагођавају скали оптерећења тако да ниво услуга и перформансе остану непромењене. Добар пример су истраживачке организације које могу вршити неке специфичне операције са великом количином података и великом процесорском снагом у неком одређеном временском периоду а затим се вратити у нормалне радне услове [53]. Још један елеменат у оквиру скалабилности је и паралелизација. За разлику од других технологија паралелизацију у облаку је много лакше извести. Уштеда Ово је једна од најважнијих особина технологије облака. Технологија облака омогућава: уштеду времена, уштеду новца и уштеду у кадровима. То су типови уштеде којима тежи свака компанија на свету, без обзира на величину и делатност. Компанијама које су тек на почетку и своје пословање постепено повећавају, у облаку имају минимална почетна улагања. Оног тренутка када прошире своје пословање или пређу у ранг већих компанија једноставно скалирају захтеве на облаку и нема додатног оптерећења буџета улагањем у инфраструктуру, већ се и даље плаћа онолико колико се и потроши. Овакав концепт наплате компанијама олакшава планирање буџета и процену трошкова, па самим тим и бољу организацију. Раст пословања компаније не мора нужно довести и до потребе за запошљавањем додатних техничких кадрова. Постојећи администратори ће и даље радити исту количину посла само са увећаним капацитетима којима располажу. Током ажурирања софтвера, остатак система не мора чекати да добије нову верзију да би могао да настави са радом. Оног тренутка када се избаци нова верзија софтвера у облаку комплетан систем је може користити истровремено и само ажурарање траје далеко краће. Ако систем поседује n корисника, уштеда у времену потребном за ажурирање је n пута. Модел B2B интеграције саобраћајних пословних система 125 Портабилност У зависности од типа услуга које пружају неке компаније могу имати запослене који су на терену, далеко од седишта компаније. Многе компаније послују у више земаља, па чак и на више континената. Руководећи кадрови су често на пословним путовањима и имају потребу да могу да управљају својом компанијом и да прате њен рад а да не морају бити физички присутни у њој. Сви ти захтеви су задовољени коришћењем технологије облака. Корисницима облака потребни су Web browser и приступ Интернету и могу имати потпуну функционалност где год да се налазе. 3.3.1.6. Врсте cloud computing технологије Постоје три врсте облака: јавни, приватни и хибридни. Свака од ових врста облака има своје предности и мане. Менаџери ИТ компанија одлучују да ли ће користити јавни, приватни или хибридни облак. Та одлука зависи од проблема које компанија жели да реши. Јавни и приватни облаци су комплементарне врсте облака. Јавни За јавни облак сматра се да се налази „негде тамо” на Интернету и обично је препуштен компанији која нуди услуге технологије облака. То је иначе најчешће коришћена врста облака. Предности јавног облака у односу на приватни облак јако су велике. Сматра се да су ресурси у јавном облаку буквално неограничени. Трошкови су значајно умањени, пошто нема улагања у инфраструктуру. Одржавање је препуштено дистрибутерима облака. Приватни Приватни облак креира се за екслузивно коришћење само једног клијента, омогућавајући максималну контролу над подацима, сигурности и квалитетом услуга. Компанија поседује комплетну инфраструктуру, и има контролу над апликацијама које се испоручују у приватном облаку. Приватни облак може се налазити у просторијама предузећа које га користи, а може се налазити и на некој посебној локацији – рачунарском центру задуженом за тај приватни облак. Хибридни Компаније се увек могу одлучити да користе и јавни и приватни облак истровремено. На пример, могу постојати строго повериљиви подаци који не смеју напустити просторије компаније и не смеју се изложити могућности да неко други дође до њих. За такве податке се користи приватни облак. Исто тако, компанија може имати велику количину података који служе за разна израчунавања и који нису толико поверљиви, а опет захтевају много рачунарских ресурса, па је за њих згоднији јавни облак како би се уштедело на додатним улагањима у инфраструктуру. Комбинацијом јавног и приватног облака добијамо хибридни облак. Модел B2B интеграције саобраћајних пословних система 126 3.3.2. Microsoft Windows Azure платформа Као cloud computing платформа за реализацију система B2B интеграције изабрана је Microsoft Windows Azure платформа. Windows Azure платформа представља скуп технологија у облаку од којих свака нуди одређени сет функционалности. На слици 59 представљене су четири саставне компоненте Windows Azure платформе [25]: • Windows Azure – Microsoft окружење за извршавање апликација и складиштење података на рачунарима у Microsoft центрима; • SQL Azure – релациони систем за управљање базама података у облаку; • Windows Azure AppFabric – слој који нуди разноврсне сервисе за апликације које се извршавају било у облаку или локално на некој машини; • Windows Azure Marketplace – сервис на Интернету који служи за куповину података и апликација у облаку. Слика 59. Компоненте Microsoft Windows Azure платформе [25] Предложени систем B2B интеграције састојаће се од заједничке базе података хостоване на Microsoft SQL Azure платформи, Web портала и WCF сервисa хостованих на Microsoft Windows Azure AppFabric платформи. Windows Azure AppFabric Windows Azure AppFabric компонента представља средишњи слој (енг. middleware) у Windows Azure платформи који нуди неколико веома битних сервиса за рад у облаку. Нуди сервисе како за апликације које се извршавају у облаку, тако и за апликације које се извршавају негде локално. Већина ових сервиса је доступна преко HTTP – REST програмске спреге и због тога може да им се приступа из апликација које се извршавају у облаку, као и ван Microsoft Модел B2B интеграције саобраћајних пословних система 127 центара. Основни сервиси које нуди ова компонента су представљени на слици 60. Три основна сервиса које нуди ова компонента су [93]: • магистрала сервиса (енг. Service Bus) – омогућава безбедну везу између апликација у облаку. Апликацијама које се извршавају у облаку обично је потребно приступити преко Интернета, што некада није баш једноставан задатак. Овај сервис омогућава апликацијама да одреде приступне тачке у облаку преко којих ће им се моћи приступати. Када се те тачке одреде, свакој се додељује јединствена ознака (енг. Uniform Resource Identifier - URI) која представља дату апликацију на Интернету. Када корисник покуша да приступи апликацији путем Интернета преко њене ознаке, овај сервис прихвата тај захтев и омогућава успоставу заштићене везе између корисника и апликације у облаку, скривајући од корисника сам механизам комуникације и протокол по којем се она обавља. Овај сервис игра битну улогу у комуникацији између апликација које се налазе изван неких приватних или корпоративних мрежа (на пример, које се извршавају у облаку) и неких апликација које леже унутар тих мрежа иза заштитне баријере (енг. Firewall). Оваква два типа апликација немају начин да успоставе директну комуникацију и размењују податке и поруке, али захваљујући овом сервису који постоји као посредник између њих, то је могуће. Магистрала сервиса нуди безбедне механизме размене порука и успостављања везе између апликација које се налазе у облаку или ван њега; • контрола приступа (енг. Access Control) – овај сервис је задужен за препознавање корисника и за давање појединих права одређеним корисницима над апликацијом и сервисима. Начини за идентификацију на Интернету могу бити различити (начин који се користи за приступање Windows Azure апликацијама су акредитиве корисника на Windows Live сервису), а овај сервис омогућава да се аутентикацијом уз помоћ одговарајућих акредитива оствари одређени ниво приступа апликацији и сервисима у облаку; • баферовање (енг. Caching) – овај сервис има за циљ да препозна и похрани информације којима корисник често приступа током коришћења апликације у облаку и да на сваки наредни захтев достави кориснику те податке из свог складишта, а не да на сваки нови захтев шаље упит у базу података и ради пренос података из базе. Овај сервис доприноси побољшању учинка током извршавања апликације у облаку. Модел B2B интеграције саобраћајних пословних система 128 Слика 60. Windows Azure AppFabric платформа [25] SQL Azure релациони систем за управљање базама података SQL Azure представља један од начина похрањивања података у облаку у виду релационе базе података. Три основне компоненте SQL Azure [15]: • SQL Azure Database – ова компонента нуди систем за управљање базом података базиран на облаку. Ова технологија омогућава апликацијама које се извршавају у облаку, као и апликацијама које нису развијане за облак, да складиште релационе податке у Microsoft складиштима података; • SQL Azure Reporting – ова компонента поставља верзију већ постојећег извештача који постоји у Micorosft SQL Server-у, с тим што је ова верзија намењена за рад у облаку. Омогућава да се добију извештаји о раду са подацима у облаку; • SQL Azure Data Sync – ова компонента нуди метод за синхронизацију података између података у SQL Azure бази података и Microsoft SQL Server база података које се не налазе у облаку, као и синхронизацију података између две или више SQL Azure база података које се не налазе у истим Microsoft складиштима података. Компонента SQL Azure направљена је ослањајући се у потпуности на Microsoft SQL Server [100]. Ова чињеница је од велике важности за кориснике који планирају да своје апликације оспособе за рад у облаку, а раније су користили Microsoft SQL Server базе података. Да би апликација успешно користила SQL Azure базу података уместо Microsoft SQL Server базе података потребно је учини минималне измене у самој апликацији, ма колико она била велика. Основна структура SQL Azure компоненте представљена је на слици 61. Модел B2B интеграције саобраћајних пословних система 129 Слика 61. SQL Azure компонента [25] Windows Azure Најбитнија компонента Microsoft-ове cloud computing платформе је Windows Azure. Она је задужена за извршавање апликација у облаку и складиштење података. Често ће се чути дефиниција за Windows Azure да он у суштини представља оперативни систем за облак који нуди низ сервиса који омогућавају развој, уређивање, постављање и складиштење апликација у облаку. Windows Azure компонента састављена је од пет основних делова приказаних на слици 62 [32]: • Compute – овај сервис задужен је за извршавање апликација у облаку. Апликације које се праве за облак могу бити прављене користећи .NET окружење у програмским језицима попут C# или Visual Basic, или могу да буду прављење без коришћења .NET окружења у другим програмским језицима попут Java, C++ и други; • Storage – овај сервис служи за складиштење различитих типова података у Microsoft складиштима. Омогућава складиште за масовне бинарне податке, затим за поруке које се размењују између компоненти у апликацији или између апликације и спољашњег света, као и складиште за податке који су погодни за табеларну представу (што је доста слично са представљањем података у релационој SQL Azure бази података, па корисник може да бира који му метод више одговара). Апликације које се извршавају у облаку, као Модел B2B интеграције саобраћајних пословних система 130 и оне које се тамо не извршавају могу да комуницирају са складиштем података и читају или складиште податке. Ово се остварује користећи REST (енгл. Representational State Transfer) приступ у комуникацији апликације са сервисом за складиштење података; • Fabric Controller – ова компонента извршава се над великим бројем машина. Пошто ресурси, који се намењују за одређеног корисника и његове апликације, нису везани за строго једну машину или чак машине на истом географском положају, задатак ове компоненте је да додељене корисничке ресурсе повеже у једну логичку целину на коју ће се ослонити сервиси за извршавање апликација и складиштење података; • Content Delivery Network – ова компонента нуди механизам за баферовање бинарних података са складишта којима апликација често приступа током свог рада и тиме убрзава приступ траженим подацима; • Connect – ова компонента дозвољава да се са апликацијама у облаку комуницира на другачије начине од подразумеваних. Наиме, апликације у облаку могу да комуницирају са спољним светом искључиво преко HTTP (енгл. Hypertext Transfer Protocol), HTTPS (енгл. Hypertext Transfer Protocol Secure) и TCP (енгл. Transmission Control Protocol) протокола. Претпоставимо да, из неког разлога, корисник има захтев да се са својом апликацијом у облаку повеже из апликације ван облака на IP (Internet Protocol) нивоу. Ово није подразумевани начин повезивања и комуникације између апликација у облаку са спољашњим светом, али је остварљив уз коришћење ове компоненте. Слика 62. Windows Azure компонента [25] Модел B2B интеграције саобраћајних пословних система 131 Сервис за извршавање апликација (Compute) Сервис који је задужен за извршавање апликација у облаку је састављен из једне или више улога (енгл. Roles). Свака улога је засебан процес који се извршава на виртуелним машинама које су створене за потребе њиховог извршавања. Како ово изгледа, приказано је на слици 63. Windows Azure апликација може да буде састављена од три типа улога [105]: • Web улога (енг. Web Role) намењена је за извршавање апликација за Web. Свака инстанца ове улоге има унапред подешен IIS7 (енгл. Internet Information Services) који се извршава у оквиру ње, тако да је дозвољено коришћење било које технике за прављење оваквих апликација (ASP.NET, WCF, PHP, Java) и апликација ће се успешно извршавати по постављању на облак; • радна улога (енгл. Worker Role) намењена је за извршавање апликација које имају улогу позадинских процеса. Уколико се прави нека апликација која има први тип улоге у себи, та апликација ће бити доступна кориснику преко интернет претраживача и он ће преко њега да комуницира са апликацијом у облаку. Уколико апликација нуди неке сервисе који подразумевају неку једноставну или сложену обраду неких података или обављање неких прорачуна и послова, то је тип посла који се обично намени делу апликације која ће бити представљена овом улогом. Ток извршавања послова за које је она задужена неће бити видљив кориснику, а она ће путевима за комуникацију да обавести апликацију представљену као интернет улогу о завршеном послу и да јој проследи резултате које ће она да прикаже кориснику. Ово је веома честа пракса, да интернет и радна улога иду у пару приликом израде апликације за Windows Azure платформу, и да током извршавања и међусобно комуницирају у циљу извршавања задатака; • улога виртуелне машине (енгл. Virtual Machine Role, VMrole) намењена је за кориснике који желе да у облак поставе неке Windows Server апликације. Приликом развоја апликације за облак, корисник има могућност да лично зада број инстанци сваке улоге који ће бити покренут у облаку. Омогућавајући ово, кориснику је дат веома једноставан начин да се избори са проблемом скалабилности. Претпоставимо да је корисник у облак поставио своју Web презентацију која се састоји од једне Web улоге. Приликом постављања апликације у облак, у датотеци са подешавањима своје апликације корисник има могућност да зада колико инстанци његове Web улоге жели да буде покренуто по постављању апликације у облак. Претпоставимо да се не очекује велика посета поменуте Web презентације у почетном периоду. Кориснику је довољно у том случају да покрене само једну инстанцу своје Web улоге. Међутим, уколико би број посетилаца Web презентације кроз време растао и претио да тренутно додељени ресурси не буду довољни да се опслуже сви захтеви посетилаца, корисник може да направи измену у датотеци са подешавањима и да затражи да му од неког одређеног момента буду покренуте две инстанце његове Web улоге. Након очитавања нове конфигурационе датотеке, створиће се нова инстанца Web улоге и сада ће две идентичне инстанце да опслужују захтеве посетилаца. Да Модел B2B интеграције саобраћајних пословних система 132 захтеви буду што равномерније распоређени брине компонента за уравнотежење оптерећења. Слика 63. Windows Azure Compute сервис [25] Сервис за складиштење података (Storage) Свакако један од кључних делова Windows Azure платформе јесте механизам складиштења корисничких података. Раније је описан један од начина за чување података у виду релационе SQL Azure базе података. Поред тога, корисницима су на располагању још три типа складишта за податке. Слика 64 приказује могућности за складиштење података у облаку поред SQL Azure базе података. У понуди су следећа три типа складишта: • Blob – овај тип складишта служи за складиштење бинарних података. Хијерархија овог типа складишта се може видети и на слици 63. Сваки налог за складиште може да има више контејнера (правоугаоници) који у себи могу да садрже један или више blob-ова (квадрати). Ти подаци могу бити максималне величине од 1TB. Уколико су подаци који се складиште велики, они се интерно представљају подељени у блокове да би се олакшао њихов пренос и предупредиле евентуалне грешке или прекиди у преносу података; • Tables – овај тип складишта у многоме подсећа на SQL Azure базу података, пошто су подаци сачувани у њему организовани у табеле, баш као и подаци у бази података. Да би се размео принцип смештања података у табеле, може се замислити да корисник жели да сачува у овај тип складишта објекат који поседује десет поља у себи. Смештањем тог објекта у овај тип Модел B2B интеграције саобраћајних пословних система 133 складишта, он ће бити представљен као један ред, а табела у коју се смешта ће имати десет колона и свако поље објекта ће бити уписано у једну колону; • Queues – овај тип складишта је намењен за комуникацију између појединачних улога у самој апликацији или између апликације у облаку и апликација које се извршавају ван облака. Интернет и радна улога у апликацији комуницирају размењују поруке преко овог типа складишта. Ово складиште представља један FIFO (енг. First In First Out) ред који служи за складиштење и преузимање порука између две стране које обављају комуникацију. Слика 64. Windows Azure Storage сервис [25] 3.3.3. Интегрисано развојно окружење за развој cloud апликација Будући да је као cloud computing платформа изабрана Microsoft Windows Azure платформа, за развој cloud апликација користиће се интегрисано развојно окружење Microsoft Visual Studio 2010 заједно са Windows Azure SDK (Software Development Kit) и Windows Azure Tools for Microsoft Visual Studio 2010. Апликација за облак биће креирана као Windows Azure Project у развојном окружењу Microsoft Visual Studio 2010 (слика 65). У развојном окружењу Microsoft Visual Studio 2010 могуће је креирати неколико врста апликација (слика 66). ASP.NET Web Role омогућава креирање ASP.NET Web сајтова који ће бити испоручени у облаку [149]. Пре него што буде испоручена у облаку апликација се може извршавати и тестирати локално, у развојном окружењу које симулира облак. Када је спремна за испоручивање у облаку, апликација се објављује из истог развојног окружења, аплоадовањем .cspkg и .cscfg датотека. Све софтверске компоненте биће имплементиране у програмском језику Visual Basic. Модел B2B интеграције саобраћајних пословних система 134 Слика 65. Microsoft Visual Studio 2010 Windows Azure Project Слика 66. Microsoft Visual Studio 2010 ASP.NET Web Role Модел B2B интеграције саобраћајних пословних система 135 4. Реализација и примена предложеног модела Подизање нивоа безбедности у саобраћају је циљ коме тежи друштво у целини. Одређени државни органи извршавају законом дефинисане задатке што представља окосницу борбе за безбедан саобраћај. Осим државних органа, значајан удео у борби за безбедан саобраћај имају и јавна предузећа. У овом примеру посматра се појединачно и заједничко деловање три субјекта на пољу подизања нивоа безбедности у друмском и железничком саобраћају: • Министарство унутрашњих послова Републике Србије, • Јавно предузеће „Путеви Србије”, • Акционарско друштво „Железнице Србије”. Најзначајнију улогу у области подизања нивоа безбедности у саобраћају свакако има Министарство унутрашњих послова Републике Србије. Међутим, и преостала два субјекта дају значајан допринос, када је у питању безбедност у саобраћају. Сваки од три горе наведена субјекта надлежан је за вођење евиденције о одређеним подацима који су у тесној вези са безбедношћу у саобраћају. Сваки субјекат има потребу да неке податке преузима од преостала два субјекта, а неке друге податке обезбеђује осталим субјектима. Дакле, неопходна је двосмерна, перманентна комуникација између ова три субјекта. Предложени модел B2B интеграције примењен је за потребе међусобних B2B интеграција три наведена субјекта из домена безбедности саобраћаја. 4.1. Спецификација и анализа захтева Управа Саобраћајне полиције, Министарства унутрашњих послова Републике Србије, адекватним регулисањем саобраћаја, настоји да подигне општи ниво безбедности у саобраћају. Осим тога МУП РС једино је надлежно за вођење података о саобраћајним незгодама. Међу подацима о саобраћајним незгодама, са аспекта безбедности у саобраћају, најважнији су подаци о узроцима саобраћајних незгода. Статистички подаци о последицама саобраћајних незгода, такође су значајан аргумент приликом доношења важних одлука које се тичу подизања нивоа безбедности у саобраћају. Један део података о саобраћајној незгоди мора се евидентирати по извршеном увиђају. То су следећи подаци: • место саобраћајне незгоде, • време саобраћајне незгоде, • подаци о лицима - учесницима саобраћајне незгоде, • подаци о возилима која су учествовала у саобраћајној незгоди, • околности саобраћајне незгоде, • метеоролошки услови у време настанка саобраћајне незгоде. Модел B2B интеграције саобраћајних пословних система 136 Други део података о саобраћајној незгоди евидентира се касније, након утврђивања одговорности, узрока и последица саобраћајне незгоде. То су следећи подаци: • одлучујуће околности са аспекта возача, • одлучујуће околности са аспекта пешака, • одлучујуће околности са аспекта пута, • одлучујуће околности са аспекта возила, • број погинулих лица, • број теже повређених лица, • број лакше повређених лица, • висина материјалне штете, • одговорност. Будући да се саобраћајне незгоде дешавају на територији целе државе, није практично да се подаци о саобраћајним незгодама ажурирају на једном месту, централизовано. Стога МУП РС има циљ да поједностави начин ажурирања података о саобраћајним незгодама. Осим тога, подаци се морају чувати у форми која омогућава претраживања, филтрирања, сортирања по различитим критеријумима. МУП РС такође мора водити рачуна о томе да неке од података о саобраћајним незгодама мора учинити доступним и неким другим субјектима. Дакле, унапред се мора размишљати о технологији која ће омогућити једноставну и поуздану размену података о саобраћајним незгодама са другим субјектима. МУП РС има потребу за подацима о обиму саобраћаја на магистралним и регионалним путевима Републике србије. Бројање саобраћаја врши ЈППС, тако да оно располаже подацима о просечном годишњем дневном саобраћају на деоницама путева (ПГДС). Дакле, МУП РС има потребу да од ЈППС преузме податке о ПГДС-у у форми погодној за претраживање. Осим тога, МУП РС има потребу да податке о ПГДС-у, преузете од ЈППС, учини доступним свим људима запосленим у МУП-у, којима су ти подаци свакодневно потребни. Јавно предузеће „Путеви Србије” је предузеће које је надлежно за изградњу и одржавање магистралних и регионалних путева на читавој територији Републике Србије. Та чињеница говори о улози ЈППС у подизању нивоа безбедности на путевима Србије. Међутим, да би ЈППС препознало најопаснија места на мрежи магистралних и регионалних путева, и евентуално интервенисало на таквим местима, потребно је да располаже одређеним статистичким подацима о саобраћајним незгодама које су се дешавале на путевима. Као што је већ речено, подацима о саобраћајним незгодама располаже једино МУП РС. Дакле, ЈППС има перманентну потребу да комуницира са МУП РС и од њега преузима податке о саобраћајним незгодама. Потреба за разменом ових података је перманентна јер се саобраћајне незгоде, на жалост, дешавају свакодневно. Модел B2B интеграције саобраћајних пословних система 137 Јавно предузеће „Путеви Србије” врши бројања саобраћаја на магистралним и регионалним путевима Републике Србије. Подаци о обиму саобраћаја на путевима потребни су многим јавним предузећима, привредним субјектима, спортским организацијама, школама, високошколским установама, јавности у целини. Као информације од јавног значаја, подаци о просечном годишњем дневном саобраћају на деоницама магистралних и регионалних путева, доступни су на wеб презентацији ЈППС. Међутим, ови подаци могу се преузети само у целини, за све деонице путева. Обим саобраћаја на конкретној деоници, у конкретној години, мора се ручно пронаћи. За некога коме је у свакодневном оперативном раду потребно да располаже овим подацима ручно претраживање није довољно добро решење. Дакле, ЈППС има циљ да податке о ПГДС-у учини доступним другим корисницима, али на начин који омогућава једноставан приступ и претраживање података. Познато је да се највећи број саобраћајних незгода, у железничком саобраћају, дешава на местима укрштања друмских и железничких саобраћајница, у истом нивоу. Та места укрштања називају се путно-пружним прелазима. Један од најзначајнијих задатака „Железница Србије”, када је у питању подизање нивоа безбедности у железничком саобраћају, је да смањи број саобраћајних незгода на путно-пружним прелазима. Да би то постигле „Железнице Србије” пре свега морају поседовати све неопходне податке о путно-пружним прелазима. Ти подаци обухватају: локацију прелаза, податке о путу, о прузи, о начину осигурања прелаза, о сигнализацији, о саобраћају на месту прелаза, итд. У овом тренутку „Железнице Србије” не поседују базу података о путно-пружним прелазима, која би садржала све податке који су им неопходни. Међутим, ЈППС је за своје потребе развило једну такву базу у којој је основни ентитет: путно-пружни прелаз. Осим базе, у ЈППС постоји и Windows апликација која омогућава управљање подацима из те базе. Дакле, „Железницама Србије” потребан је приступ подацима о путно-пружним прелазима, који постоје у ЈППС. Да би поједноставило ажурирање своје базе података о путно-пружним прелазима, ЈППС требало би перманентно да преузима неке податке од „Железница Србије”. То су нпр. подаци о пругама, секцијама и деоницама за одржавање пруга итд. „Железнице Србије” имају потребу да располажу подацима о обиму саобраћаја на деоницама путева које се укрштају са пругама, у истом нивоу. Њима су ти подаци потребни када разматрају постојеће начине осигурања путно-пружних прелаза. Да би се донела одлука код којих путно-пружних прелаза је потребно повећати степен осигурања, потребно је располагати подацима о обиму друмског саобраћаја на тим путно-пружним прелазима. И „Железницама Србије” је, наравно, битно да те податке добију у форми која омогућава претраживање, сортирање и сл. 4.2. Постојећа решења У ЈППС тренутно постоји SQL Server база података Putno-pruzni prelazi. Структура ове базе приказана је на слици 67. Као што се може видети са слике, ова база садржи табелу Saobraćajna nezgoda намењену за ажурирање података о Модел B2B интеграције саобраћајних пословних система 138 саобраћајним незгодама које су се догодиле на путно-пружним прелазима. ЈППС не располаже подацима о саобраћајним незгодама, већ их мора преузимати од МУП-а. Затим, ова база садржи табелу Bezbednosni parametri putno-pruznih prelaza. Ови параметри су величине изведене из података о последицама саобраћајних незгода. Дакле, ЈППС не може самостално ажурирати ову табелу, без помоћи МУП-а. База Putno-pruzni prelazi садржи табеле Sekcija za odrzavanje pruga i Deonica za odrzavanje pruge. Обе ове табеле попуњавају се подацима који у изворном облику постоје у „Железницама Србије” и који се од њих морају преузети. Табела Saobracajno opterecenje putno-pruznog prelaza намењена је за ажурирање података о обиму друмског и железничког саобраћаја на путно- пружним прелазима, на годишњем нивоу. Као што је већ речено, ЈППС врши бројање друмског саобраћаја и тим подацима располаже. Међутим, податке о броју возова, по категоријама возова, ЈППС мора да преузме од „Железница Србије”. Табела Pruga, требало би да садржи податке о пругама на мрежи пруга Републике Србије. Ни ову табелу ЈППС не може ажурирати самостално. Подаци о пругама су подаци којима располажу „Железнице Србије” и ЈППС их мора преузети од њих. Слика 67. Структура постојеће базе података Putno-pruzni prelazi у ЈППС Очигледно је да овако пројектовану базу података Putno-pruzni prelazi ЈППС не може самостално да ажурира. Да би ова база података заиста била ажурна ЈППС Модел B2B интеграције саобраћајних пословних система 139 би од МУП РС требало на дневном нивоу да преузима податке о саобраћајним незгодама. Такође, ЈППС требало би од „Железница Србије” на дневном нивоу, да преузима податке о обиму железничког саобраћаја на путно-пружним прелазима. Та потреба проистиче из тога што теретни и разни специјални возови не саобраћају по унапред утврђеном реду вожње, већ саобраћају када се за њима укаже потреба. ЈППС користи Windows апликацију Putno-pruzni prelazi намењену за управљање подацима из базе података Putno-pruzni prelazi. У ЈППС тренутно постоји SQL Server база података Crne tacke. Структура ове базе приказана је на слици 68. Слика 68. Структура постојеће базе података Crne tacke у ЈППС Модел B2B интеграције саобраћајних пословних система 140 Као што се може видети са слике 68, база података Crne tacke садржи табеле Saobraćajna nezgoda - put, Saobraćajna nezgoda - ukrstanje, Saobraćajna nezgoda – ulica. Ове три табеле намењене су за ажурирање података о саобраћајним незгодама које су се догодиле на путевима, у укрштањима и на улицама. Подаци о саобраћајним незгодама ЈППС неопходни су да би на основу статистичких показатеља о последицама саобраћајних незгода препознали потенцијална опасна мета, идентификовали црне тачке и предузели одређене активности у циљу укидања опасних места. Те активности ће се у неким случајевима односити на комплетну реконструкцију опасног места. Код других опасних места промениће се начин регулисања саобраћаја. Код трећих ће се нпр. увести осветљење, уколико га није било, итд. И на овом месту мора се нагласити да ЈППС не располаже подацима о саобраћајним незгодама, већ их мора преузимати од МУП-а. На слици 69 приказан је падајући мени Izveštaji из апликације OPASNA MESTA која се користи у ЈППС. Овај мени омогућава генерисање великог броја извештаја, углавном над табелама које садрже податке о саобраћајним незгодама. Слика 69. Падајући мени Izveštaji из постојеће апликације OPASNA MESTA у ЈППС На слици 70 приказан је подмени STATISTIKA O SAOBRAĆAJNIM NEZGODAMA који омогућава генерисање извештаја на основу података о последицама саобраћајних незгода. Са слике 70 може се видети који су подаци значајни за ЈППС, за потребе идентификовања опасних места на мрежи магистралних и регионалних путева Републике Србије. Слика 70. Подмени STATISTIKA O SAOBRAĆAJNIM NEZGODAMA падајућег менија Izveštaji из постојеће апликације OPASNA MESTA у ЈППС Модел B2B интеграције саобраћајних пословних система 141 4.3. Развој и примена решења B2B интеграције према предложеном моделу Предложено решење нуди неколико сценарија B2B интеграције саобраћајних пословних система. Могући сценарији B2B интеграције приказани су на слици 71. Слика 71. Сценарији интеграције уз помоћ интеграционе платформе као сервиса Модел B2B интеграције саобраћајних пословних система 142 Суштина предложеног решења састоји се у томе да сваки пар пословних система треба да изабере онај сценарио, или оне сценарије B2B интеграције, који најбоље задовољавају њихове потребе, а који се реализују на бази следећих принципа: • постојеће базе података које користе посматрани пословни системи, а које имају сличну структуру и намену, интегрисаће се у једну заједничку базу смештену на cloud computing платформи; • на cloud computing платформи биће постављен Web портал који ће садржати кориснички интерфејс за ажурирање заједничке базе и постављање упита над њом. Послови ажурирања базе биће подељени између посматраних пословних система, у складу са њиховим надлежностима и компетенцијом. За сваки пословни систем биће дефинисана овлашћења у погледу генерисања упита над заједничком базом; • постојеће апликације које користе посматрани пословни системи, тренутно раде над локалним базама података постављеним на њиховим серверима и генеришу разноврсне извештаје који представљају подршку у одлучивању. Предложено решење предвиђа да неке од тих апликација у будуће преузимају неопходне податке из заједничке базе података из облака; • постојеће локалне апликације преузимаће податке из заједничке базе података која се налази у облаку, уз помоћ WCF Data сервиса хостованих у облаку; • локалним базама података које нису интегрисане у заједничку базу, а чије податке пословни системи желе да деле, приступаће се уз помоћ Web портала хостованог на cloud computing платформи; • локална апликација једног пословног система користиће податке из локалне базе података другог пословног система, позивањем WCF Data сервиса хостованих у облаку; • локалне апликације биће унапређене развојем корисничког интерфејса за приступ заједничкој бази података у облаку. Фазе у развоју решења B2B интеграције саобраћајних пословних система: • идентификација пословних субјеката који треба да буду укључени у B2B интеграције; • анализа институционалних и пословних релација између изабраних субјеката; • дефинисање захтева решења B2B интеграције за сваки пар саобраћајних пословних система који треба да реализује B2B интеграцију; • развој локалних онтологија које представљају пословни домен сваке појединачне организације; • развој заједничке доменске онтологије; • дефинисање једног или више сценарија B2B интеграције за сваки пар саобраћајних пословних система који треба да реализује B2B интеграцију; Модел B2B интеграције саобраћајних пословних система 143 • дефинисање механизама за реализацију изабраних сценарија B2B интеграције за сваки пар саобраћајних пословних система који треба да реализује B2B интеграцију; • имплементација компоненти које омогућавају реализацију изабраних механизама B2B интеграције за сваки пар саобраћајних пословних система који треба да реализује B2B интеграцију; • анализа ефеката реализације B2B интеграције, према предложеном моделу, за сваки појединачни саобраћајни пословни систем; • анализа ефеката реализације B2B интеграције, према предложеном моделу, на читав домен безбедности у саобраћају. Локалне онтологије представљају знање одговарајућих организација у домену безбедности саобраћаја. Оне одсликавају приступ појединих организација овом проблему, њихове надлежности, законске обавезе, потребе. Локалне онтологије креиране су на основу шема локалних база података, које се користе у појединим организацијама. Основни разлози који су иницирали креирање локалних онтологија су: • локалне онтологије одражавају знање посматране организације, у датом домену; • локалне онтологије одражавају надлежности, законске и друге обавезе посматране организације, у датом домену; • локалне онтологије одражавају потребе организација за дељењем и/или преузимањем података од других организација из домена; • локалне онтологије треба да иницирају избор одговарајућих метода B2B интеграције; • локалне онтологије треба да послуже као основа за креирање заједничке, доменске онтологије; • локалне онтологије треба да иницирају избор одговарајућих сценарија B2B интеграције. 4.3.1. Развој онтологија Развој решења започео је развојем локалних онтологија. С обзиром на то да пример реализације B2B интеграције саобраћајних система укључује три организације, прво су развијене три локалне онтологије, по једна за сваки пословни систем. Након детаљне анализе локалних онтологија развијена је и доменска онтологија за домен безбедности у саобраћају. Локална онтологија Министарства унутрашњих послова За развој локалних и доменске онтологије коришћено је развојно окружење Protégé version 4.2.0 [76]. За реализацију онтологија изабран је OWL стандард. На слици 72 приказан је први прозор из развојног окружења за креирање онтологија Модел B2B интеграције саобраћајних пословних система 144 са онтологијом која представља модел података који користи МУП Републике Србије за област безбедности у саобраћају. Из тог разлога ова онтологија названа је Bezbednost_saobracaja_u_Srbiji. На слици 73 представљена је хијерархија класа онтологије МУП. Слика 72. Креирање локалне онтологије МУП Слика 73. Хијерархија класа локалне онтологије МУП Све класе су подкласе основне класе Thing. Централна класа је Saobracajna_nezgoda, са којом су на непосредан или посредан начин повезане све остале класе. Остале класе моделирају реални систем у којем се догодила Модел B2B интеграције саобраћајних пословних система 145 саобраћајна незгода, као и учеснике у незгоди. Сви графовски прикази онтологија урађени су у OntoGraf алату развојног окружења Protégé. Слика 74. Граф основних класа локалне онтологије МУП На слици 74 приказан је граф основних класа локалне онтологије МУП, а на слици 75 граф свих класа локалне онтологије МУП. На графу приказаном на слици 75 виде се само класе и релације између класа, али се не виде својства класа као ни врсте приказаних релација. Постоје две могуће врсте релација између OWL класа. Прву групу релација представљају релације типа: класа – подкласа, односно класа – надређена класа. Ова врста релација омогућава изградњу хијерархије класа, каква је приказана на слици 73. Другу групу релација између класа чине својства класа типа Object Properties. Код OWL стандарда својства ентитета изражавају се кроз однос: субјекат – предикат – објекат. Субјекти су класе, предикати су релације, а објекти су својства класа. Осим својстава типа Object Properties, OWL подржава и својства типа Data Properties. Ова врста својстава одговара атрибутима у релационим моделима података. Она се изражавају неким од уграђених типова података које подржава OWL стандард. На слици 76 приказано је као пример својство osobinePovrsineKolovoza класе Saobracajna_nezgoda. Protégé алат омогућава семантичко означавање свих градивних елемената онтологије. Семантичко означавање омогућава тумачење значења нумеричких вредности атрибута. Модел B2B интеграције саобраћајних пословних система 146 Слика 75. Граф свих класа локалне онтологије МУП Слика 76. Атрибут osobinePovrsineKolovoza класе Saobracajna_nezgoda локалне онтологије МУП На слици 77 приказана су сва својства и вредности својстава једне инстанце класе Saobracajna_nezgoda. Ту су приказана сва својства типа Object Properties и сва својства типа Data Properties, заједно са њиховим типовима и вредностима. Модел B2B интеграције саобраћајних пословних система 147 Слика 77. Атрибути и вредности атрибута једне инстанце класе Saobracajna_nezgoda На слици 78 приказано је семантичко означавање вредности атрибута osobinePovrsineKolovoza, класе Saobracajna_nezgoda. Слика 78. Семантичко означавање вредности атрибута osobinePovrsineKolovoza класе Saobracajna_nezgoda локалне онтологије МУП Модел B2B интеграције саобраћајних пословних система 148 На слици 79 приказане су све релације класе Saobracajna_nezgoda. Релације типа has individual повезују класе и њихове инстанце. Релације типа has subclass повезују класе и њихове подкласе. Остале релације које су приказане на слици 79 представљају својства класе Saobracajna_nezgoda типа Object Properties. Слика 79. Релације класе Saobracajna_nezgoda локалне онтологије МУП Локална онтологија Јавног предузећа „Путеви Србије” На слици 80 приказана је хијерархија класа локалне онтологије која представља знање ЈППС о домен у безбедности у саобраћају. Централна класа ове онтологије је Opasano_mesto. Све друге класе из ове онтологије су на непосредан или посредан начин повезане са овом класом. ЈППС је управљач путева а безбедношћу друмског саобраћаја бави се са аспекта карактеристика пута. Класе: Deonica_puta, Putni_pravac и Ukrstanje креиране су према моделу података референтног система државних путева Републике Србије. Класа PGDS креирана је према моделу података који ЈППС користи за бројање саобраћаја. Класа Saobracajna_nezgoda има одређени број својстава која постоје и код истоимене класе МУП-а, али се ипак доста разликује од ње. Класе које представљају лица учеснике саобраћајних незгода и возила учеснике саобраћајних незгода, имају нека заједничка својства са истоименим класама МУП-а, али се те класе ипак значајно разликују. У онтологији ЈППС све класе су „у служби” класе Opasano_mesto. Опасно место може да буде потез на некој деоници пута, или потез на улици, или укрштање. Класа Lokacija_saobracajne_nezgode представља Модел B2B интеграције саобраћајних пословних система 149 микро-локацију у дужини од неколико десетина метара, која припада неком опасном месту. Она означава места на којима су се догађале саобраћајне незгоде. За управљача путева класе: Opasano_mesto и Lokacija_saobracajne_nezgode су најважније, јер моделирају пут и његове карактеристике, на местима саобраћајних незгода. Класе Horizontalna_signalizacija и Vertikalna_signalizacija такође су веома значајне за управљача пута јер он одржава и саобраћајну сигнализацију. Слика 80. Хијерархија класа локалне онтологије ЈППС На слици 81 приказан је граф основних класа локалне онтологије ЈППС. Модел B2B интеграције саобраћајних пословних система 150 Слика 81. Граф основних класа локалне онтологије ЈППС На слици 82 приказан је граф свих класа и подкласа локалне онтологије ЈППС. Слика 82. Граф свих класа и подкласа локалне онтологије ЈППС Модел B2B интеграције саобраћајних пословних система 151 Локална онтологија ЈППС садржи мноштво класа, подкласа и релација између њих, које имају за циљ да представе знање о локацији на путу на којој се догодила саобраћајна незгода. Онтологија моделира три могуће врсте локација саобраћајних незгода: деоница пута, укрштање и улица. Свакој од врста локације саобраћајних незгода одговара по једна подкласа следећих класа: Lokacija_saobracajne_nezgode, Vertikalna_signalizacija, Horizontalna_signalizacija, Saobracajna_nezgoda, Vozilo_ucesnik_saobracajne_nezgode, Lice_ucesnik_ saobracajne_nezgode. Подкласе ових класа имају за циљ да поделе знање о саобраћајним незгодама према врсти локације на којој су се догодиле. На слици 83 приказан је граф релација (Object Properties) између класа локалне онтологије ЈППС. Централна класа ове онтологије – Opasano_mesto, има за циљ да опише знање о потезима на деоницама путева, потезима улица или укрштањима, која представљају потенцијалне „црне тачке”. Централна класа повезана је са четири групе класа: • класе које описују знање о положају опасног места у референтном систему: − Putni_pravac, − Deonica_puta, − Ukrstanje, − Ulica, − Opstina; • класе које описују знање о саобраћајним незгодама која су се догодиле у зони опасног места: − Lokacija_saobracajne_nezgode, − Horizontalna_signalizacija_na_putu, − Vertikalna_signalizacija_na_putu, − Saobracajna_nezgoda_na_putu, − Vozilo_ucesnik_saobracajne_nezgode_na_putu, − Lice_ucesnik_saobracajne_nezgode_na_putu. • класе које описују знање о карактеристикама микро-локације на путу у време када се догодила саобраћајна незгода на њој: − Zastoji_u_zoni_opasnog_mesta, − Radovi_na_putu_u_zoni_opasnog_mesta, • класе које описују знање о карактеристикама и обиму саобраћаја у зони опасног места: − Snimanje_saobracaja, − Snimanje_brzina_u_zoni_opasnog_mesta, − Saobracajni_konflikti_u_zoni_opasnog_mesta. Из хијерархије класа и графова релација класа локалних онтологија МУП и ЈППС, јасно се виде концептуалне разлике у моделирању приближно истог реалног система. Реални систем су саобраћајне незгоде које се дешавају на државним путевима Републике Србије. Централни ентитет модела података МУП је саобраћајна незгода. Централни ентитет модела података ЈППС је опасно место на путу. При том треба имати у виду, да МУП у свом моделирању саобраћајних Модел B2B интеграције саобраћајних пословних система 152 незгода користи референтни систем ЈППС. С друге стране, ЈППС у свом моделирању опасних места користе податке о саобраћајним незгодама које добијају од МУП. Ипак, сисеми користе концептуално потпуно различите моделе података. Разлике су још многобројније на нивоу формата, вредности и значења података. Слика 83. Граф релација између класа локалне онтологије ЈППС Локална онтологија „Железница Србије” На слици 84 приказан је граф релација између класа локалне онтологије која представља знање ЖС о домену безбедности саобраћаја на путно-пружним прелазима. Централна класа ове онтологије је Putno_pruzni_prelaz, пошто је онтологија ограничена на безбедност путно-пружних прелаза. Домен интересовања одређен је са аспекта потреба за B2B интеграцијама између управљача путева и управљача пруга. Путно-пружни прелази су тачке у којима се додирују интересне сфере три изабрана пословна субјекта. На слици 81 види се да су све друге класе из локалне онтологије ЖС на непосредан или посредан начин повезане са овом класом. ЖС су управљач пруга, па се безбедношћу друмског саобраћаја баве са аспекта безбедности путно-пружних прелаза. Класе локалне онтологије ЖС могу се поделити на следеће групе класа: • класе које описују знање о положају путно-пружног прелаза у референтном систему и на мрежи пруга: − Put, − Putni_potez, Модел B2B интеграције саобраћајних пословних система 153 − Deonica_puta, − Okrug, − Opstina, − Katastarska_opstina, • класе које описују знање о саобраћајним незгодама и безбедносним параметрима путно-пружног прелаза: − Saobracajna_nezgoda, − Bezbednosni_parametri_ppp, • класе које описују знање о одржавању путно-пружних прелаза: − Preduzece_za_odrzavanje_puteva, − Sekcija_za_odrzavanje_pruga, − Deonica_za_odrzavanje_pruga, • класе које описују знање о обиму и структури саобраћаја на путно-пружним прелазима: − Saobracajno_opterecenje_ppp. Слика 84. Граф релација између класа локалне онтологије ЖС Доменска онтологија за домен безбедности у саобраћају На основу креираних локалних онтологија за сваки од посматраних пословних система, креирана је заједничка доменска онтологија (слика 85). Доменска онтологија има за циљ да представи обједињено знање три пословна субјекта у домену безбедности у саобраћају. Она укључује већи део класа из локалних Модел B2B интеграције саобраћајних пословних система 154 онтологија, али не све класе. Класе за које је процењено да не представљају неко знање које би требало да деле три посматрана субјекта, нису укључене у доменску онтологију. Неке класе локалних онтологија замењене су адекватним класама заједничке доменске онтологије. Неким класама је само промењено име и списак својстава, док су остале у истим релацијама са другим класама, итд. Доменска онтологија обједињује знања из области безбедности у саобраћаја, чинећи унију неопходних знања за три посматрана субјекта. Слика 85. Граф релација између класа доменске онтологије 4.3.2. Креирање заједничке базе података на cloud computing платформи На основу доменске онтологије креирана је заједничка база података на Microsoft SQL Azure платформи. Заједничка база података названа је Bezbednost u saobracaju, а развијена је и постављена на Microsoft SQL Azure серверу чија адреса је: fs2g47rb11.database.windows.net (слика 86). База има за циљ да одговори на разноврсне потребе три субјекта на пољу безбедности у саобраћају. Основна намена базе је да омогући централизовано ажурирање података о саобраћајним незгодама, који се могу поделити на следеће категорије: • подаци о референтном систему који одређује локацију саобраћајне незгоде (путни правци, деонице путева, укрштања), • основни подаци о саобраћајној незгоди (време, место, тип, узрок, последице, одлучујући фактори...) • подаци о лицима учесницима у саобраћајној незгоди, • подаци о возилима учесницима у саобраћајној незгоди, Модел B2B интеграције саобраћајних пословних система 155 • подаци о микро-локацији на којој се догодила незгода (карактеристике пута, околина, вертикална и хоризонтална сигнализација). Слика 86. Microsoft SQL Azure сервер Шема базе података креирана је на основу: • модела референтног система државних путева Републике Србије који тренутно користи ЈППС, • модела података о опасним местима, који користи ЈППС у њиховој постојећој бази података Crne tacke, • модела података о путно-пружним прелазима који користи ЈППС у њиховој постојећој бази података Putno-pruzni prelazi, • структуре слога о саобраћајним незгодама, лицима учесницима и возилима уцесницима незгода, које тренутно користи МУП Републике Србије. Структура базе података Bezbednost u saobracaju приказана је на слици 87. На слици 88 приказан је граф зависности табеле Putni pravac од осталих табела базе података Bezbednost u saobracaju. Модел B2B интеграције саобраћајних пословних система 156 Слика 87. Структура заједничке базе података Bezbednost u saobracaju Слика 88. Граф зависности табеле Putni pravac базе Bezbednost u saobracaju Модел B2B интеграције саобраћајних пословних система 157 У Прилогу су дате као пример неке од табела из заједничке базе, у Design View и Data View. На слици 89 приказан је списак погледа који су креирани над заједничком базом података. Критеријуми за дефинисање упита над којима су креирани погледи, засновани су на потребама управљача путева и управљача безбедношћу саобраћаја. Број упита може се повећавати, према потребама субјеката укључених у B2B интеграције, што не утиче на базу података. Слика 89. Упити креирани над заједничком базом података Bezbednost u saobracaju Упити се према резултатима могу поделити на три категорије: • упити који омогућавају приказивање података о саобраћајним незгодама, груписаним према опасним местима, • упити који генеришу информације о броју саобраћајних незгода, према врстама незгода и врстама опасних места, • упити који генеришу информације о броју настрадалих (погинули, теже повређени или лакше повређени) према врстама опасних места, • упити који омогућавају приказивање података о опасним местима, груписаним према положају у референтном систему. Модел B2B интеграције саобраћајних пословних система 158 Упити у SQL Azure базама података веома су моћан алат, јер се над њима могу креирати WCF Data сервиси, на исти начин као и над табелама. Уз помоћ упита и WCF Data сервиса могу се добити неопходни подаци из заједничке базе, било у Web или Windows апликацији. За учеснике B2B интеграције који немају право приступа комплетној заједничкој бази података, идеалан начин за преузимање података су упити и WCF Data сервиси генерисани над њима. На тај начин сваки субјекат може да добије из базе података тачно оне информације које су му потребне, без потребе за додатном обрадом. Један пример упита назван Ukupan broj poginulih lica po opasnim mestima, приказан је на слици 90. Резултат овог упита дат је на слици 91. Остали упити налазе се у Прилогу. Слика 90. Упит Ukupan broj poginulih lica po opasnim mestima Слика 91. Резултат упита Ukupan broj poginulih lica po opasnim mestima Модел B2B интеграције саобраћајних пословних система 159 4.3.3. Креирање Web портала на cloud computing платформи На Windows Azure платформи хостован је Web портал Serbian Railroad Crossings намењен за заједничко, униформисано ажурирање и коришћење података о безбедности саобраћаја на путно-пружним прелазима у Републици Србији. Web портал Serbian Railroad Crossings развијен је у интегрисаном развојном окружењу Visual Studio 2010, као WindowsAzureProject. Објављивањем WindowsAzureProject- а, креиран је сервис намењен за хостовање на WindowsAzure платформи. Основне намене Serbian Railroad Crossings Web портала су да омогући: • централизовано ажурирање података о путно-пружним прелазима, • централизовано ажурирање података о обиму и структури саобраћаја на путно-пружним прелазима, • израчунавање безбедносних параметара путно-пружних прелаза. На слици 92 приказан је прозор из Windows Azure платформе у којем је креиран сервис serbian railroad crossings од .cspkg и .cscfg датотека WindowsAzureProject- а: WindowsAzureProject3. Слика 92. Креирање сервиса serbian railroad crossings који ће бити хостован на Windows Azure платформи Модел B2B интеграције саобраћајних пословних система 160 Сервис serbian railroad crossings хостован је на cloud computing платформи, као сервис типа WebRole (слика 93). Слика 93. Web портал Serbian Railroad Crossings хостован као сервис на Windows Azure платформи У складу са наменама, Web портал садржи заједнички кориснички интерфејс за ажурирање података о путно-пружним прелазима као и за генерисање упита о безбедносним параметрима путно-пружних прелаза. У Прилогу је дат ADO.Net Entity Data Model креиран над базом података о путно-пружним прелазима. На слици 94 приказан је кориснички интерфејс из Web портала Serbian Railroad Crossings који омогућава ажурирање података о саобраћајним незгодама које су се догодиле на путно-пружним прелазима. На слици 95 приказан је кориснички интерфејс за преглед података о саобраћајним незгодама на путно-пружним прелазима (ппп). Кориснички интерфејс Web портала Serbian Railroad Crossings који је приказан на слици 94 и слици 95, омогућава корисницима приступ локалној бази података Putno-pruzni prelazi коју поседује ЈППС. ЈППС не може самостално да ажурира ову базу података, већ мора повремено да преузима податке о путно-пружним прелазима од „Железница Србије”. Да би се избегло преузимање и редунданса података, а обезбедио интегритет података, портал Serbian Railroad Crossings омогућава запосленим из „Железница Србије” да приступају бази података на серверу ЈППС и да у складу са овлашћењима ажурирају базу Putno-pruzni prelazi. На тај начин свака организација ажурира оне податке о путно-пружним прелазима за које је надлежна, без потребе за међусобном разменом података. Web портал Serbian Railroad Crossings омогућава и другим заинтересованим субјектима да приступе подацима о путно-пружним прелазима, да генеришу безбедносне параметре путно-пружних прелаза. Модел B2B интеграције саобраћајних пословних система 161 Слика 94. Кориснички интерфејс за ажурирање података о саоб. незгодама Слика 95. Кориснички интерфејс за приказ података о саоб. незгодама на ппп Модел B2B интеграције саобраћајних пословних система 162 На слици 96 приказан је кориснички интерфејс из Web портала за генерисање безбедносних параметара путно-пружних прелаза. Безбедносни параметри генеришу се над подацима о саобраћајним незгодама из заједничке базе података из облака. На слици 97 приказан је обим и структура саобраћаја на прелазима. Слика 96. Кориснички интерфејс за генерисање безбедносних параметара ппп Слика 97. Кориснички интерфејс за приказ обима и структуре саобраћаја на ппп Модел B2B интеграције саобраћајних пословних система 163 4.3.4. Развој WCF Data сервиса WCF Data сервиси су елегантна Microsoft-ова технологија за објављивање података, било из база података са локалних сервера или из база података из облака. Могу се хостовати на локалним Web серверима или на серверима из облака. WCF Data сервисе могу користити како Windows тако и Web апликације. Апликација која користи WCF Data сервис може бити Desktop апликација, Web апликација хостована на локалном Web серверу, или Web апликација хостована као сервис у облаку. Начин коришћења WCF Data сервиса не зависи од врсте апликације која ће да га позива, већ од тога каква му је намена. Microsoft је обезбедио више модела података, који се могу изложити као WCF Data сервиси: • ADO.Net Entity Data Model, • LINQ to SQL Classes, • Custom Data Model (Object, XML, итд). За потребе преузимања података из заједничке базе података Bezbednost u saobracaju креирано је неколико ADO.Net Entity Data модела података који су изложени као WCF Data сервиси. За потребе хостовања WCF Data сервиса и манипулисање подацима које добављају WCF Data сервиси, развијена је ASP.Net Web апликација Preuzimanje podataka iz eksternih izvora (слика 98). Слика 98. Структура Web апликације Preuzimanje podataka iz eksternih izvora Модел B2B интеграције саобраћајних пословних система 164 На слици 99 приказани су стрингови конекције са заједничком базом података из облака, из чега се види да су на располагању четири начина приступа бази. У предложеном решењу користиће се ADO.Net модел приступа подацима. На слици 100 приказан је прозор у којем се креира конекција ка SQL Azure бази података уз помоћ које ће бити креиран ADO.Net Entity Data модел. Слика 99. Могући стрингови конекције са базом података из облака Слика 100. Креирање ADO.Net Entity Data модела над SQL Azure базом података Модел B2B интеграције саобраћајних пословних система 165 Локалне апликације и корисници имају потребу за преузимањем неколико категорија података, како из заједничке базе података из облака, тако и из локалних база. Методологија преузимања података је идентична, без обзира на врсту базе из које се преузимају подаци. За сваку категорију података развијен је ADO.Net Entity Data модел података који је изложен као WCF Data сервис. Намена модела података PutnaInfrastrukturaEntities је да омогући преузимање података о путној инфраструктури, из заједничке базе података. Ovaj модел података изложен је као сервис WCFDataServicePutnaInfrastruktura.svc. На слици 101 приказан је из моделa података PutnaInfrastrukturaEntities у XML формату, ентитет Putni_pravac и његова друга инстанца. За потребе преузимање података из заједничке базе података у облаку развијено је још неколико WCF Data сервиса који су хостовани на Web апликацији Preuzimanje podataka iz eksternih izvora. Слика 101. Ентитет Putni_pravac сервиса WCFDataServicePutnaInfrastruktura Модел B2B интеграције саобраћајних пословних система 166 Web апликација Preuzimanje podataka iz eksternih izvora омогућава и преузимање података из локалне SQL Server базе Crne tacke ЈППС. Подаци са локалних сервера преузимају се на исти начин као и подаци са сервера из облака. За ту сврху креирано је неколико ADO.Net Entity Data модела података и њима одговарајућих WCF Data сервиса хостованих на истој Web апликацији. На слици 102 приказан је из модела PGDSEntities, ентитет PGDS и једна његова инстанца. Слика 102. Ентитет PGDS(100) сервиса WCFDataServicePGDS 4.3.5. Интеграција апликација Интеграција апликација обавља се додавањем референце на одговарајући WCF Data сервис и иницијализовањем WCF Data сервиса. На слици 103 приказана је процедура за иницијализовање сервиса WCFDataServiceSaobracajneNezgode. Након иницијализовања WCF Data сервиса, Data објекти апликације повезују се Модел B2B интеграције саобраћајних пословних система 167 са ADO.Net Entity Data моделом података и приказују преузете податке. На слици 104 приказана је страница Web апликације Preuzimanje podataka iz eksternih izvora која приказује податке о саобраћајним незгодама, који су преузети из базе података из облака уз помоћ сервиса WCFDataServiceSaobracajneNezgode. Слика 103. Иницијализовање сервиса WCFDataServiceSaobracajneNezgode Слика 104. Страница Web апликације која приказује податке из облака добијене од сервиса WCFDataServiceSaobracajneNezgode Модел B2B интеграције саобраћајних пословних система 168 На слици 105 приказана је процедура за иницијализовање сервиса WCFDataServicePGDS. На слици 106 приказана је страница Web апликације Preuzimanje podataka iz eksternih izvora која приказује податке о ПГДС-у, који су преузети из локалне SQL Server базе података ЈППС уз помоћ сервиса WCFDataServicePGDS. Слика 105. Иницијализовање сервиса WCFDataServicePGDS Слика 106. Страница Web апликације која приказује податке из локалне SQL Server базе података ЈППС добијене од сервиса WCFDataServicePGDS Модел B2B интеграције саобраћајних пословних система 169 Приступ подацима из заједничке базе података из облака може се остварити и директно, путем корисничког интерфејса локалне апликације. При томе је свеједно да ли је локална апликација Windows или Web. За потребе генерисања статистичких података о саобраћајним незгодама и опасним местима на државним путевима Републике Србије, за потребе ЈППС развијена је Windows апликација Statistika o opasnim mestima. Она преузима податке из базе података Bezbednost u saobracaju, из облака. Да би се преузели подаци из базе са cloud computing платформе потребно је креирати конекцију ка SQL Azure бази, као што је приказано на слици 107. Слика 107. Креирање конекције ка SQL Azure бази Bezbednost u saobracaju Модел B2B интеграције саобраћајних пословних система 170 На слици 108 приказан је један од прозора из Windows апликације Statistika o opasnim mestima, који приказује податке генерисане извршавањем упита над SQL Azure базом података Bezbednost u saobracaju. Пример који је приказан на слици 108 приказује резултат извршавања упита: Broj SN sa poginulim licima po opasnim mestima na putevima. Овај упит израчунава укупан број саобраћајних незгода са погинулим лицима које су се догодиле на појединим опасним местима на путевима. Резултат упита може се сортирати према свим колонама табеле. На слици 108 приказан је резултат упита сортиран према укупном броју саобраћајних незгода са погинулим лицима. На тај начин опасна места су сортирана од најопаснијих ка најмање опасним. Слика 108. Windows апликација која извршава упите над SQL Azure базом података Bezbednost u saobracaju Један од предложених сценарија B2B интеграције је и коришћење заједничког корисничког интерфејса хостованог на cloud computing платформи за потребе генерисања и извршавања упита над локалним базама података. Такав пример је Web апликација хостована у облаку која корисницима омогућава да генеришу упите над базом података о реду вожње „Железница Србије”. На слици 109 приказана је структура табеле Red voznje po stanicama, из базе података Zeleznice хостоване на Windows Azure платформи. На слици 110 приказан је део података из табеле Red voznje po stanicama. Модел B2B интеграције саобраћајних пословних система 171 Слика 109. Структура табеле Red voznje po stanicama SQL Azure базе података Zeleznice Слика 110. Подаци у табели Red voznje po stanicama SQL Azure базе података Zeleznice Модел B2B интеграције саобраћајних пословних система 172 Слика 111 приказује креирање, а слика 112 хостовање сервиса ZelezniceSrbijeRedVoznje.cloudapp.net на Windows Azure платформи. Слика 111. Креирање сервиса ZelezniceSrbijeRedVoznje на Windows Azure платформи Слика 112. Хостовање сервиса ZelezniceSrbijeRedVoznje на Windows Azure платформи Модел B2B интеграције саобраћајних пословних система 173 Слика 113 приказује Web форму за генерисање реда вожње за изабране станице поласка и доласка и датум путовања. Слика 114 приказује Web форму за генерисање реда вожње за изабрану станицу поласка или доласка и датум путовања. Приказана Web апликација имплементира пример генерисања упита на cloud computing платформи, над локалном базом података. На овај начин омогућено је дељење информација између једне саобраћајно-транспортне организације и свих потенцијалних корисника њених информација. Као што се може видети на сликама 113 и 114, Web апликација у облаку омогућава приступ различитим категоријама података које генеришу, ажурирају и користе „Железнице Србије”. Неке од тих категорија података су: подаци о путничком саобраћају – цене превоза, општи услови, повластице и посебне понуде, превоз праћених аутомобила, колски капацитети, резервисање места, продајна места и агенције. На сличан начин приказана апликација могла би да обједини саобраћајно-транспортне информације свих видова саобраћаја и прерасте у саобраћајни портал. Слика 113. Web страница апликације хостоване у облаку која над локалном базом података генерише ред вожње за изабране станице поласка и доласка Модел B2B интеграције саобраћајних пословних система 174 Слика 114. Web страница апликације хостоване у облаку која над локалном базом података генерише ред вожње за изабрану станицу поласка или доласка Један од могућих сценарија B2B интеграције је преузимање података из заједничке базе података у облаку од стране локалне Windows апликације. Windows апликација „Rangiranje putne mreze” развијена је са циљем да омогући рангирање и класификацију деоница путева и километарских деоница на мрежи државних путева Републике Србије. Рангирање и класификација путне мреже врши се на основу вредности одређених критеријума – ризика, који се израчунавају за сваку деоницу. У формулама на основу којих се израчунавају ризици за деонице путева фигуришу: укупан број саобраћајних незгода које су се догодиле на посматраној деоници пута у посматраном временском периоду, број саобраћајних незгода са повређеним лицима, број саобраћајних незгода са погинулим лицима, број саобраћајних незгода са материјалном штетом, број лакше повређених, теже повређених и погинулих учесника саобраћајних незгода, просечан годишњи дневни саобраћај на деоницама путева, дужина деонице пута. Сви набројани подаци налазе се у изворном облику у заједничкој бази података у облаку, или се могу израчунати на основу података из базе у облаку. Апликација „Rangiranje putne mreze” преузима потребне податке из базе података „Bezbednost u saobracaju”, израчунава показатеље и врши рангирање и Модел B2B интеграције саобраћајних пословних система 175 класификацију деоница путева на основу израчунатих ризика. На слици 115 приказан је део програмског кôда помоћу кога се у апликацији „Rangiranje putne mreze” израчунавају вредности ризика. На слици 116 приказан је прозор из исте апликације који омогућава класификацију деоница путева у пет категорија и вишекритеријумско рангирање деоница на основу вредности осам критеријума. Слика 115. Прозор апликације „Rangiranje putne mreze” за израчунавање вредности ризика деоница путева Слика 116. Прозор апликације „Rangiranje putne mreze” за класификацију и вишекритеријумско рангирање деоница путева Модел B2B интеграције саобраћајних пословних система 176 4.4. Анализа постигнутих резултата Након што је реализовано решење B2B интеграције саобраћајних пословних система према предложеном моделу, извршена је анализа решења, и то: аналитичка, симулациона и имплементациона анализа. 4.4.1. Аналитичка анализа Аналитичка анализа реализованог решења B2B интеграције саобраћајних пословних система обухвата следеће аспекте анализе: • анализа могућности развоја институционалних и законских оквира унутар којих би се реализовало предложено решење; • анализа потенцијалних кандидата из домена безбедности саобраћаја у Републици Србији, за реализацију B2B интеграције уз помоћ предложеног решења; • анализа ефеката примене предложеног решења B2B интеграције на електронско пословање учесника B2B интеграције; • анализа захтева решења у погледу хардверске и софтверске инфраструктуре; • анализа степена флексибилности предложеног решења и могућности прилагођавања новим захтевима; • анализа могућности примене предложеног решења за потребе B2B интеграције Владиних организација и организација из јавног сектора надлежних у области саобраћаја; • анализа могућности примене предложеног решења за потребе B2B интеграције малих и средњих предузећа у области саобраћаја и транспорта; • анализа могућности примене предложеног решења за потребе прикупљања информација у научно-стручним истраживањима; • анализа модела плаћања сервиса на којима је базирано предложено решење B2B интеграције; Неки од субјеката надлежних у области безбедности у саобраћају у Србији, већ су законским и институционалним оквирима упућени на сарадњу, кооперативно електронско пословање, дељење и размену информација. Пример за то је законски уређен однос следећих субјеката: Министарство унутрашњих послова, Агенција за безбедност саобраћаја, органи локалне самоуправе. Актуелни Закон о безбедности у саобраћају прописао је нпр. обавезе које органи локалне самоуправе имају према Агенцији за безбедност саобраћаја, у погледу периодичног достављања информација о саобраћајним незгодама. Према моделу примењеном у области безбедности друмског саобраћаја, могли би да се уреде институционални односи, права и обавезе надлежних организација у домену безбедности осталих видова саобраћаја. Закључак је да није превише компликована процедура да се законским актима регулишу права и обавезе Модел B2B интеграције саобраћајних пословних система 177 организација у области безбедности у саобраћају, у смислу њиховог међусобног електронског пословања. У том смислу, могуће је створити институционални и законски оквир који би омогућио примену предложеног решења B2B интеграције субјеката у области безбедности саобраћаја у Републици Србији. Потенцијални кандидати који би применили предложено решење B2B интеграције су: Министарство унутрашњих послова Републике Србије, Агенција за безбедност у саобраћају, органи локалне самоуправе (општинске управе, градске управе, итд), Јавно предузеће „Путеви Србије”, „Железнице Србије”. Предложено решење могле би да користе и све друге организације које су на неки начин укључене у послове који се тичу подизања нивоа безбедности у саобраћају у Републици Србији. Најзначајнији ефекат примене предложеног решења B2B интеграције на електронско пословање учесника B2B интеграције је ефикасније, поузданије и семантички интероперабилно електронско пословање. Примена предложеног модела B2B интеграције унапредиће ефикасност електронског пословања на тај начин што ће ручна размена информација бити замењена аутоматизованом разменом информација, на нивоу информационих система. Смањење редундансе података је основни ефекат примене предложеног решења B2B интеграције, што као последицу има и пропратне ефекте. Најзначајнији ефекти смањења редундансе података су: смањење потребних складишних, тј. меморијских капацитета сервера, смањење броја сати ангажовања запослених на пословима размене и ажурирања података. Важна особина предложеног модела B2B интеграције саобраћајних пословних система је поузданост и скоро потпуна елиминација људског фактора у настајању грешака током ажурирања података. Предложени модел подразумева да једна категорија софтверских сервиса преузима податке из заједничке базе, као и локалних база података, а да друга категорија сервиса обрађује преузете податке. Друга значајна особина предложеног решења је централизовано ажурирање и дељење података уз помоћ заједничког корисничког интерфејса, што у многоме смањује потребу за разменом података. Предложено решење омогућава семантички интероперабилно електронско пословање, јер је базирано на заједничком информационом моделу [39, 134]. Заједнички информациони модел заснован је на заједничком моделу података [11]. Заједнички модел података развијен је на бази заједничког дељеног речника и доменске онтологије. Доменска онтологија је основ за конзистентно тумачење значења метаподатака и вредности података. У погледу хардверске и софтверске инфраструктуре, предложено решење подразумева коришћење информационе инфраструктуре из облака. То значи да корисници предложеног решења нису у обавези да набављају никакав додатни хардвер, као ни да купују софтверске лиценце. Сервисно-оријентисана архитектура, на којој је базирано решење, омогућава интегрисање апликација развијених на различитим платформама. Заједничкој бази података у облаку могуће је приступити уз помоћ следећих технологија: ADO.Net, ODBC, PHP, Модел B2B интеграције саобраћајних пословних система 178 JDBC. Закључак је да предложено решење не захтева развој нових локалних апликација и база података, већ напротив – омогућава коришћење постојећих информационих система. Интегрисање апликација захтева иницијализовање и позивање WCF сервиса из облака, што не захтева значајне интервенције у кôду постојећих апликација. Предложено решење поседује висок степен флексибилности јер није унапред детерминисано бројем учесника у B2B интеграцијама. Флексибилност је основна карактеристика сервисно-оријентисане архитектуре на којој је ово решење засновано. Како постојеће, тако и нове локалне апликације могу користити ово решење, додавањем референце на одговарајући сервис, иницијализовањем и коришћењем сервиса из облака. Нове апликације, такође могу приступати заједничкој бази података у облаку. Додавање нових апликација - корисника базе података, на SQL Azure платформи врши се тако што се додају нови опсези IP адреса са којих развијаоци апликација могу приступити бази података. Предложено решење може се искористити и за потребе B2B интеграције Владиних организација и организација из јавног сектора. Ова категорија организација послује у специфичним условима, дефинисаним законским актима. Владине организације и јавна предузећа имају законску обавезу да прикупљају, ажурирају и на одређени начин обрађују неке податке. Предложено решење не пренебрегава ту чињеницу, већ омогућава другим заинтересованим организацијама да деле податке које складиште поменуте организације. Пример за то је Јавно предузеће „Путеви Србије” које је у обавези да јавности учини доступним одређене податке који су од јавног значаја. Једна категорија података од јавног значаја су подаци о ПГДС-у (просечном годишњем дневном саобраћају) на државним путевима Републике Србије. Јавно предузеће „Путеви Србије” поседује бројаче саобраћаја и серверску апликацију која преузима податке са бројача. Серверска апликација смешта преузете податке у базу података постављену на серверу ЈППС. Предложени модел не захтева никакве измене у постојећој методологији бројања саобраћаја, прикупљања и складиштења података о ПГДС-у. Предложено решење нуди свим заинтересованим организацијама механизам преузимања података о ПГДС-у од ЈППС. Развој и примена механизма преузимања података претходно би била дефинисана уговорима између ЈППС и сваке заинтересоване организације појединачно. Многа мала и средња предузећа која су део транспортних ланаца, нису у могућности да инвестирају у готова комерцијална решења која омогућавају ефикасну размену података. С друге стране, њихова потреба за разменом података није мања од потребе коју имају велике компаније [44]. Модел B2B интеграције који је предложен у овој дисертацији не захтева велика почетна финансијска улагања, тако да га могу применити и мала и средња предузећа. Свако научно-стручно истраживање захтева располагање великим количинама података, најчешће из хетерогених извора. Пример за то је студија „Израда базе података о опасним местима на државним путевима Републике Србије” коју је реализовала Криминалистичко-полицијска академија у Београду. У оквиру ове студије прво је развијена методологија за идентификацију опасних места, па тек Модел B2B интеграције саобраћајних пословних система 179 онда је креирана база података о опасним местима. За развој једне такве методологије било је неопходно упознати се са: моделом података референтног система државних путева Републике Србије, структуром слога о саобраћајним незгодама који користи МУП, структуром расположивих података о ПГДС-у, итд. Научно-истраживачки тим који је реализовао ову студију морао је да уложи огромне напоре да би прикупио довољну количину података за развој методологије за идентификацију опасних места и базе података о опасним местима. Када је формирана база о опасним местима реализован је нови пројекат чији је циљ био прикупљање података о опасним местима и ажурирање базе. На тим пословима ангажован је велики број људи, утрошен је велики број сати теренског и канцеларијског рада. Применом предложеног решења у сфери научно-стручних истраживања у области саобраћаја, значајно би се побољшала ефикасност истраживачких тимова. Предложено решење базирано је на коришћењу три врсте сервиса из облака: инфраструктуре као сервиса, платформе као сервиса и софтвера као сервиса. За све врсте сервиса који се могу користити унутар cloud computing технолошког окружења, заједничко је то да се плаћају „по употреби” и да се плаћа само за оно што се користи и колико се користи. Cloud computing провајдери користе термин „квантум услуге” као синоним за термин најмања јединица услуге. Цена коштања коришћења услуга из облака обрачунава се на основу броја искоришћених „квантума услуге” и цене јединице услуге. Количина искоришћених „квантума услуге” у функцији је од: времена коришћења процесорке снаге, количине употребљених меморијских капацитета, броја хостованих инстанци сервиса, итд. Закључак је да начин обрачунавања количине искоришћених „квантума услуге” није транспарентан, тако да се процене цене коришћења услуга из облака могу дати на основу искустава других корисника и сопствених искустава. 4.4.2. Симулациона анализа На основу предложеног модела B2B интеграције саобраћајних пословних система реализовано је решење B2B интеграције субјеката у области безбедности у саобраћају. Решење које је реализовано као пример примене предложеног модела B2B интеграције омогућава интероперабилно електронско пословање следећих субјеката: Министарство унутрашњих послова, Јавно предузеће „Путеви Србије” и „Железнице Србије”. Аутор је учествовао у развоју две постојеће базе података и апликације које се данас користе у ЈППС. С обзиром на то да је на свом рачунару имао постављене две SQL Server базе података које се користе у ЈППС, као и две Windows апликације које раде над тим базама, а да су заједничка база података и Web портал креирани за потребе B2B интеграције хостовани на Microsoft-овом јавном облаку, аутор је могао да спроведе експерименте. За сваки предложени сценарио B2B интеграције спроведен је експеримент. Прва група експеримената састојала се у тестирању функционалности Web портала. Web портал, према предложеном моделу, има неколико намена. Тестиран је приступ заједничким подацима интегрисаним у SQL Azure бази података, путем заједничког корисничког интерфејса интегрисаног у Web портал. У питању су SQL Azure база података Bezbednost u saobracaju и SERBIAN RAILROAD Модел B2B интеграције саобраћајних пословних система 180 CROSSINGS Web портал, који су детаљно описани у одељцима 4.3.2. и 4.3.3, респективно. Показало се да је портал поуздан а да се подацима смештеним у облаку приступа тренутно. Кориснички субјективни осећај током коришћења портала у облаку не разликује се од осећаја приликом коришћења Web апликација хостованих на апликационим серверима ван облака. Разлог за то је и чињеница да је портал развијен у развојном окружењу које има дугу традицију и генерише препознатљив визуелни амбијент. Доступност базе података из облака такође није била проблематична током читавог времена развоја и тестирања портала. Тестиран је и приступ локалним SQL Server базама података, директно из Web портала у облаку, путем заједничког корисничког интерфејса. За потребе тестирања овог сценарија B2B интеграције развијен је Web портал под називом „Железнице Србије”. У одељку 4.3.5. описане су две Web странице из тог портала. Оне омогућавају кориснику да изабере врсту упита и зада параметре упита за генерисање реда вожње „Железница Србије”. ASP.Net апликација генерише SQL упит, приступа локалној SQL Server бази података и над њом извршава упит. Подаци који представљају резултат упита приказују се унутар истог корисничког интерфејса. Временска дужина трајања одзива локалне базе на постављене упите не разликује се од временске дужине трајања одзива базе података из облака. Тестирано је интегрисање апликације из облака и стандардне Web апликације уз помоћ WCF Data сервиса. ASP.Net Web апликацијa под називом „APLIKACIJA ZA PREUZIMANJE PODATAKA IZ EKSTERNIH IZVORA” описана је у одељку 4.3.5. Тестиран је одзив WCF Data сервиса на захтев из поменуте апликације. Ни код овог сценарија B2B интеграције нису уочени проблеми. Апликација приказује податке које WCF Data сервиси преузимају из локалне базе, као и из базе података из облака, унутар јединственог корисничког интерфејса. Уочено је да се подаци из облака појављују мало брже него подаци из локалне базе. Резултати експерименталне анализе су позитивни. Све компоненте информационе инфраструктре из облака показале су се поузданим. Брзина којом заједнича база података из облака генерише резултате упита, такође је задовољавајућа. Међутим, ипак су уочена два недостатка. Један се састоји у томе да се коришћење Windows Azure платформе, чак и за потребе тестирања наплаћује. Други проблем тиче се хостовања сервиса у облаку. Тај поступак може да траје и по неколико сати, а исход је неизвестан. Брзина постављања сервиса на cloud computing платформу зависи од тренутне заузетости хардвера у облаку. Искуство стечено током експеримента указује на то да хостовање сервиса у облаку треба вршити ван радног времена према америчким и западноевропским временским зонама. 4.4.3. Имплементациона анализа Предложено решење имплементирано је на Microsoft-овој развојној платформи. Web портал и сви Web сервиси развијени су у интегрисаном развојном окружењу (ИРО) Microsoft Visual Studio 2010. Постојеће апликације, које су интегрисане са новим апликацијама, развијене су у развојном окружењу Microsoft Visual Studio 2008. Постојеће локалне базе података креиране су у релационом систему за управљање базама података (РСУБП) Microsoft SQL Server 2008. Заједничка база Модел B2B интеграције саобраћајних пословних система 181 података развијена је на Microsoft SQL Azure платформи, која представља релациони систем за управљање базама података у облаку. Закључак је да сви Microsoft-ови алати и развојна окружења омогућавају развој софтверских компоненти које међусобно одлично сарађују. Одлична сарадња ИРО Visual Studio 2008 и РСУБП SQL Server 2008 није новост. Међутим, охрабрујућа је лакоћа са којом се имплементира конекција било Windows или Web апликације са SQL Azure базом података. Конекција се креира на исти начин на који се креира конекција ка локалним SQL Server базама података. Са аспекта имплементације посебно корисна је чињеница да SQL Azure базе података могу бити креиране миграцијом постојећих SQL Server база података. Потребно је само креирати скрипт базе података и извршити га на SQL Azure платформи. Неке од клаузула из SQL-Transact упитног језика нису подржане на SQL Azure платформи, али оне нису пресудне у процесу креирања база података. Друга важна особина предложеног решења са аспекта имплементације, јесте да приликом развоја апликација типа WindowsAzureProject, које се хостују у облаку Visual Studio 2010 нуди подршку за тестирање апликација локално. Та подршка реализована је кроз Windows Azure SDK. Инсталирањем овог алата Visual Studio 2010 добија подршку у виду компоненти: Compute Emulator и Storage Emulator. Ове две компоненте симулирају истоимене компоненте на Windows Azure платформи. То програмеру омогућава тестирање апликације у интегрисаном развојном окружењу, на исти начин као у случају било које друге врсте апликације, без додатних напора. Током истраживања у оквиру ове тезе коришћени су разноврсни Microsoft-ови алати, а заједничка особина свих њих је да пројектанту пружају разноврсне могућности да их комбинује у реализацији сложених сценарија B2B интеграције. Сви алати подржавају заједничке технологије и омогућавају јединствене приступе унутар комфорног корисничког интерфејса. 4.4.4. Евалуација предложеног модела B2B интеграције саобраћајних пословних система Евалуација предложеног модела B2B интеграције саобраћајних пословних система састоји се у: • оцени нивоâ интероперабилности које омогућава примена предложеног решења, • оцени степена у којем предложени модел превазилази: концептуалне, технолошке и организационе баријере интероперабилности, • оцени степена: ефективности, ефикасности и економичности предложеног модела. Примена предложеног решења B2B интеграције омогућава интероперабилност саобраћајних пословних система на нивоу: података, сервиса, пословних процеса и пословања. Модел B2B интеграције саобраћајних пословних система 182 Интероперабилност података остварена је дељењем информација из хетерогених извора података, складиштених на различитим машинама, под различитим оперативним системима и у различитим системима за управљање базама података. Интероперабилност сервиса омогућена је компоновањем различитих апликативних функција да раде заједно, иако су пројектоване и имплементиране независно. Интероперабилност пословних процеса постигнута је обједињавањем секвенци сервиса (функција) у циљу реализације неке пословне активности. Интероперабилност пословања омогућена је хармонизацијом сарадње организација у домену саобраћаја, без обзира на разлике у: начину доношења одлука, методама рада, правним актима на основу којих функционишу. Предложено решење превазилази све три категорије препрека интероперабилности пословних система: • концептуалне, • технолошке и • организационе баријере. Концептуалнe баријере односе се на синтаксне и семантичке разлике информација које се размењују. Ови проблеми решени су обједињавањем различитих модела података, које користе посматрани саобраћајни пословни системи, у јединствени доменски модел података. Технолошке баријере односе се на неспојивости информационих технологија (архитектуре и платформе, инфраструктура, итд.) Ови проблеми решени су коришћењем заједничких стандарда за представљање, складиштење, размену, обраду података и комуникацију коришћењем рачунара. Организационе баријере односе се на дефинисање одговорности и надлежности, а решавају се дефинисањем законског и уговорног оквира. Заједничка база података и сервиси у облаку користе се у складу са унапред утврђеним корисничким овлашћењима. Када говоримо о ефективности, као карактеристици неке активности или модела, онда покушавамо да дамо одговор на питање „шта се постиже” реализовањем те активности, или применом тог модела. Ефективност се односи на меру у којој радимо „праву ствар”. Ефективност предложеног модела B2B интеграције огледа се у степену интероперабилности коју предложени модел обезбеђује. Како је већ речено да предложени модел обезбеђује интероперабилност на свим нивоима, онда се може закључити да модел нуди висок степен ефективности. Ефикасност је карактеристика модела која описује колико је добро изабран начин да се постигне неки циљ. Раније је речено да је предложени модел флексибилан, једноставан, прилагодљив динамичким променама захтева и применљив у различитим сценаријима B2B интеграције саобраћајних пословних система. На основу тога може се констатовати да је дефинисани метод B2B интеграције применљив у области саобраћаја и транспорта, а да је предложени модел ефикасан. Економичност ставља у релацију уложена средства и добит за уложена средства. Коришћење услуга које нуде cloud computing провајдери не захтева велика почетна улагања, а плаћа се само оно што се користи и колико се користи. Економичност је једна од највећих предности које истичу cloud computing провајдери, што и овај модел B2B интеграције чини економичним. Модел B2B интеграције саобраћајних пословних система 183 5. Научни и стручни доприноси Најзначајнији допринос ове дисертације састоји се у развоју модела B2B интеграције саобраћајних пословних система у cloud computing окружењу. Научни допринос рада огледа се у: • систематизацији и анализи постојећих модела B2B интеграције саобраћајних пословних система; • дефинисању оригиналне методологије семантички интероперабилног електронског пословања саобраћајних пословних система; • развоју оригиналног модела B2B интеграције саобраћајних пословних система у cloud computing технолошком окружењу; • развоју, систематизацији и детаљној анализи имплементације Web сервиса које користе саобраћајни пословни системи. Рад на овој дисертацији резултовао је и низом стручних доприноса од којих су најважнији: • дефинисање најважнијих проблема који онемогућавају интероперабилно е- пословање саобраћајних пословних система у Републици Србији; • преглед и анализа хардверске и софтверске инфраструктуре неопходне за имплементацију B2B интеграције саобраћајних пословних система у cloud computing окружењу; • имплементација предложеног модела B2B интеграције саобраћајних пословних система; • пројектовање семантички интероперабилног електронског пословања саобраћајних пословних система; • развоју локалних и доменске онтологије, за домен безбедности у саобраћају; • реализација сервисно оријентисаних Windows и Web апликација, као и WCF сервиса који омогућавају интероперабилно пословање три система: „Железнице Србије”, Јавно Предузеће „Путеви Србије” и МУП Републике Србије. Интеграцијом апликација пословним системима омогућено је да на квалитетнији начин решавају проблем безбедности саобраћаја на путевима, пругама, као и на местима укрштања пруга и путева у истом нивоу. Најважнији резултат истраживања у оквиру ове докторске дисертације је развој и имплементација оригиналног модела B2B интеграције саобраћајних пословних система у cloud computing окружењу. Примена предложеног модела омогућава семантички интероперабилно електронско пословање саобраћајних пословних субјеката. Оргиналност се огледа у дефинисању методолошког поступка B2B интеграције саобраћајних пословних система, базираног на интеграцији информација и апликација и концептима cloud computing технологије. Резултати истраживања реализованих у оквиру ове докторске дисертације објављени су у више радова у часописима и саопштени на научним скуповима и то: Модел B2B интеграције саобраћајних пословних система 184 Рад прихваћен за објављивање у часопису међународног значаја на SCI листи: 1. Janković, S., Milojković, J., Mladenović, S., Despotović-Zrakić, M., Bogdanović, Z., Cloud Computing Framework for B2B Integrations in the Traffic Safety Area, Metalurgia International, ISSN 1582-2214, IF(2010)=0.154 Рад објављен у часопису националног значаја: 2. Janković, S., Interoperabilnost saobraćajnih poslovnih sistema zasnovana na integraciji B2B servisno orijentisanih aplikacija, Info M, vol. 36, str. 4-12, 2010. Радови саопштени на скупу међународног значаја штампани у целини: 3. Janković, S., Mladenović, S., Radonjić, V., Kostić-Ljubisavljević, A., Uzelac, A., Integration Platform-As-A-Service In The Traffic Safety Area, MIC-CNIT2011, Mosharaka International Conference on Communications, Networking and Information Technology, pp. 70-75, Dubai, UAE, December 16-18. 2011. 4. Janković, S., Mladenović, S., Branović, I., Milinković, S., Cloud computing u saobraćaju i transportu, III Međunarodni simpozijum Novi horizonti saobraćaja i komunikacija, Doboj, Republika Srpska, 24-25. novembar 2011. 5. Radonjic, V., Jankovic, S., Mladenovic, S., Veskovic, S., Kostic-Ljubisavljevic, A., B2B Integration of Rail Transport Systems in Cloud Computing Environment, invited paper, Proceedings of the 4th International Symposium on Applied Sciences in Biomedical and Communication Technologies - ISABEL '11, Barcelona, Spain, October 26-29, Article 135, doi: 10.1145/2093698.2093833, 2011. 6. Branović, I., Vesković, S., Mladenović, S., Milinković, S., Janković, S., SOA Architecture for Complying with EU Railway Timetable Data Exchange Format, TELSIKS’11 – 10th International Confernce on Telecommunications in Modern Satellite, Cable and Broadcasting Services, Niš, Serbia, October 5 - 8, 2011. 7. Janković, S., Mladenović, S., Mitrović, S., Pavlović, N., Aćimović, S., A model for integration of railway information systems based on cloud computing technology, ICEST 2011 - XLVI International Scientific Conference On Information, Communication And Energy Systems And Technologies, Niš, Serbia, June 29 - July 1, 2011. Радови саопштени на скупу националног значаја штампани у целини: 8. Mladenović, S., Janković, S., Integracija saobraćajnih informacionih sistema u cloud computing okruženju, PosTel 2011 XXIX simpozijum o novim tehnologijama u poštanskom i telekomunikacionom saobraćaju, 305-314, Beograd, Srbija, 6-7. decembar 2011. 9. Janković, S., Mladenović, S., Vesković, S., Milinković, S., Neki aspekti primene cloud computing tehnologije u elektronskom poslovanju železnica, SYM-OP-IS ‘11, XXXVIII Simpozijum o operacionim istraživanjima, Zlatibor, Srbija, 4-7. oktobar 2011. 10. Janković, S., Mladenović, S., Neki aspekti interoperabilnosti poslovnih sistema i njihovih aplikacija, XXXV Simpozijum o operacionim istraživanjima SYM-OP-IS ‘08, str. 71-74, Soko Banja, Srbija, 14-17. septembar 2008. Модел B2B интеграције саобраћајних пословних система 185 6. Будућа истраживања Истраживање које је спроведено у оквиру ове тезе започело је проучавањем постојећих референтних модела и радних оквира интероперабилности. Упознавање са достигнућима у овој области показало је да се научници широм света данас интензивно баве изналажењем нових модела и метода које би обезбедиле интероперабилност софтвера. С обзиром на то да се паралелно развијају нове технологије за развој софтвера, чини се да ће интероперабилност увек бити актуелно питање. Предмет даљих истраживања биће пре свега интероперабилност саобраћајних пословних субјеката, али у ширем контексту. Електронско пословање организација заступљених на пољу саобраћаја и транспорта специфично је јер подразумева комуникације разнородних субјеката: саобраћајно-транспортних предузећа, корисника транспортних услуга, организација из Владиног сектора и организација из јавног сектора. Из тог разлога намеће се потреба за истраживањем следећих модела електронског пословања у домену саобраћаја: • пословни субјекти – пословни субјекти (енгл. Business to Business, B2B), • пословни субјекти – корисници (енгл. Business to Customer, B2C), • Владa – пословни субјекти (енгл. Government to Business, G2B), • Влада – Влада (енгл. Government to Government, G2G), • Влада – грађани (енгл. Government to Citizens, G2C). Набројани модели електронског пословања односе се и на хоризонталне и на вертикалне интеграције унутар домена саобраћаја. Истраживања модела хоризонталних интеграција била би у правцу развоја Web портала и Web сервиса у облаку. Истраживања модела вертикалних интеграција ишла би у правцу развоја доменских онтологија и интеграције информација у заједничким базама података у облаку. Постизање интероперабилности пословних система је проблем који се решава на ниву: података, сервиса, процеса и читавог пословања организација. За решавање тог проблема на свим наведеним нивоима развијени су стандарди и технологије, разрађене многобројне методе, доступна развојна окружења. Међутим, на свим набројаним нивоима интероперабилности мора истовремено бити остварена и семантичка интероперабилност. Истраживање постојећих модела и метода за постизање семантичке интероперабилности, показало је да на том пољу има још увек доста простора за унапређења постојећих решења. Из тог разлога, основни правац даљих истраживања био би истраживање модела и техника за постизање семантичке интероперабилности саобраћајних пословних система. С обзиром на то да треба остварити семантичку интероперабилност унутар пет горе набројаних модела електронског пословања, будућа истраживања била би у сфери развоја заједничких информационих модела на бази доменских онтологија и модела вођених упитима у cloud computing технолошком окружењу. Модел B2B интеграције саобраћајних пословних система 186 7. Закључак Интероперабилност, у општем случају, представља способност система, софтвера или процеса да заједнички функционишу у реализацији одређеног заједничког задатка. У домену саобраћаја и транспорта неопходна је међусобна интероперабилност субјеката који припадају следећим категоријама: саобраћајно- транспортна предузећа, организације из Владиног сектора и организације из јавног сектора. Предмет проучавања ове докторске тезе је проблем интероперабилности у саобраћају и транспорту, а затим: стандарди, модели, методе и технологије које омогућавају да се постигне интероперабилно електронско пословање саобраћајних пословних система. Анализирана је улога информационо- комуникационих технологија у процесу реализације савремене транспортне услуге. Дефинисани су: појам, задаци и циљеви интероперабилности саобраћајних пословних система. Предмет проучавања била је и законска регулатива и препоруке Европске Уније које третирају интероперабилност саобраћајних пословних система. Значајно место у дисертацији заузима анализа најзначајнијих савремених решења која се примењују ради постизања интероперабилности у саобраћају и транспорту. Будући да је интеграција апликација један од начина да се постигне интероперабилност пословних система, дисертација обухвата проучавање различитих технологија интеграције апликација које данас постоје. Кључни део овог сегмента дисертације је проучавање сервисно оријентисаних архитектура B2B интеграције и технологије интегрисања апликација уз помоћ WCF сервиса. Значајан простор у оквиру тезе посвећен је проучавању постојећих модела и метода за постизање семантичке интероперабилности. Анализирани су најзначајнији приступи у коришћењу онтологија за постизање семантичке интероперабилности. Као релативно нова рачунарска парадигма, проучавана је cloud computing технологија, пре свега као технолошко окружење за реализацију решења B2B интеграције. У оквиру дисертације развијен је оригиналан модел B2B интеграције саобраћајних пословних система. Модел је заснован на комбиновању следећих метода B2B интеграције: интеграције информација, интеграције сервиса и порталне интеграције. Интеграција информација у предложеном моделу подразумева развој заједничког модела података на основу доменске онтологије. Интеграција сервиса подразумева развој и хостовање WCF сервиса cloud computing платформи. Портална интеграција састоји се у развоју и хостовању Web портала на cloud computing платформи. Web портал има вишеструку намену у реализацији различитих сценарија B2B интеграције. Он садржи заједнички кориснички интерфејс за приступ заједничкој бази података у облаку, кориснички интерфејс за приступ локалним базама података које користе пословни субјекти укључени у B2B интеграцију, као и кориснички интерфејс за генерисање упита над више локалних база података истовремено. Модел B2B интеграције саобраћајних пословних система 187 На бази предложеног модела B2B интеграције, у оквиру дисертације пројектовано је и имплементирано оригинално решење B2B интеграције пословних система из домена безбедности у саобраћају. Реализација решења састојала се од следећих фаза: развој локалних и доменске онтологије, пројектовање и креирање заједничке базе података на SQL Azure платформи, развој Web портала на Windows Azure платформи, имплементација и хостовање WCF сервиса на Windows Azure платформи. У последњој фази интегрисане су постојеће Windows и Web апликације, коришћењем набројаних компоненти са cloud computing платформе. Развој и тестирање примера решења B2B интеграције, показало је да се интероперабилност саобраћајних пословних система може успешно остварити B2B интеграцијом сервисно оријентисаних апликација, која је заснована на коришћењу cloud computing технолошког окружења и WCF сервиса. На основу резултата до којих се дошло током експерименталне анализе предложеног решења, извршена је верификација предложеног модела. Утврђено је да модел омогућава постизање интероперабилности на синтаксном, али и на семантичком нивоу. Током експеримента, показало се да предложено решење нуди висок степен ефективности и ефикасности, као и задовољавајући степен економичности. Током истраживања отворена су многа питања која се тичу проблема интероперабилности пословних субјеката у домену саобраћаја. Наметнула се потреба за развојем нових модела интероперабилног електронског пословања који ће ефикасно повезати сектор саобраћаја са Владиним сектором и корисницима транспортних услуга. Модел B2B интеграције саобраћајних пословних система 188 8. Литература [1] Acuña, C. J., Minoli, M., Marcos, E., Integrating Web Portals with Semantic Web Services, International Journal of Enterprise Information Systems, 6(1), pp. 57-67, 2010. [2] Alonso, J., Martínez de Soria, I., Orue-Echevarria, L., Vergara, M., Enterprise Collaboration Maturity Model (ECMM): Preliminary Definition and Future Challenges, Enterprise Interoperability IV, pp. 429-438, London: Springer, 2010. [3] Anicic, N., Ivezic, N., Semantic Web technologies for enterprise application integration, Computer Science and Information Systems, 2(1), pp. 119-144, 2005. [4] Antoniou, G., Van Harmelen, F., A semantic Web primer, London: Massachusetts Institute of Technology Press, 2004. [5] Antonopoulos, N., Gillam, L. (Editors), Cloud Computing: Principles, Systems and Applications, Springer-Verlag, London, 2010. [6] Asuncion, C. H., Sinderen, M. J., Pragmatic Interoperability: A Systematic Review of Published Definitions, Enterprise Architecture, Integration and Interoperability: IFIP TC 5 International Conference, pp. 164-175, Brisbane, Australia, September 20-23, 2010. [7] ATHENA, Advanced Technologies for Interoperability of Heterogeneous Enter- prise Networks and their Applications, FP6-2002-IST-1, Integrated Project, April 2003. [8] Batarlienė, N., Baublys, A., Mobile Solutions in Road Transport, Transport, 22(1), pp. 55–60, 2007. [9] Batarlienė, N., Jarašūnienė, A., Research on advanced technologies and their efficiency in the process of interactions between different transport modes in the terminal, Transport, 24(2), pp. 129–134, 2009. [10] Bean, J., SOA and Web Services Interface Design: Principles, Techniques, and Standards, Elsevier Inc., Burlington, USA, 2010. [11] Becker, D., Saxton, T.L., The Missing Piece in Achieving Interoperability – a Common Information Model ( CIM ) - Based Semantic Model, Grid-Interop Forum 2007, pp. 1-6, Becker-Saxton, 2007. [12] Berners-Lee, T., Hendler, J., Lassila, O., The Semantic Web, Scientific American, 284(5), pp. 34-43, 2001. [13] Berners-Lee, T., Semantic Web Road Map, W3C Design Issues, 1998, Available from: http://www.w3.org/DesignIssues/Semantic.html, [Accessed: August 10 2011]. [14] Berre, A., Јørgen, B., Figay, N., Guglielmina, C., Johnsen, S.G., Karlsen, D., Knothe, T., Lippe, S. The ATHENA interoperability framework, Interoperability II, pp. 1-12, 2007. [15] Betts, D., Densmore, S., Dunn, R., Narumoto, M., Pace, E., Woloski, M., Developing Applications for the Cloud on the Microsoft® Windows Azure™ Platform, Microsoft, 2010. Модел B2B интеграције саобраћајних пословних система 189 [16] Bhatia, R., Wier, M., “Safety in Numbers” re-examined: Can we make valid or practical inferences from available evidence?, Accident Analysis and Prevention, Vol. 43, pp. 235–240, 2011. [17] Borzacchiello, M. T., Casas, I., Ciuffo, B., Nijkamp, P., Geo-ICT in Transportation Science, Geospatial Technology and the Role of Location in Science, Vol. 96, pp. 267-285, 2009. [18] Branović, I., Vesković, S., Mladenović, S., Milinković, S., Janković, S., SOA Architecture for Complying with EU Railway Timetable Data Exchange Format, TELSIKS’11 – 10th International Confernce on Telecommunications in Modern Satellite, Cable and Broadcasting Services, Niš, Serbia, October 5 - 8, 2011. [19] Buccella, A., Cechich, A., Brisaboa, N. R., An Ontology Approach to Data Integration, Journal of Computer Science & Technology, pp. 62-68, 3(2), 2003. [20] Budak Arpinar, I., Aleman-Meza, B., Zhang, R., Maduko, A., Ontology-driven Web services composition platform, e-Commerce Technology, 2004. CEC 2004. IEEE International Conference on, pp. 146- 152, San Diego, USA July 6-9 2004. [21] Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I., Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility, Future Generation Computer Systems, 25(6), pp. 599-616, 2009. [22] C4ISR Architecture Working Group, C4ISR Architecture Framework, Available from: http://www.afcea.org/education/courses/archfwk2.pdf, [Accessed: 9 December 2011]. [23] Caliusco, Ma. L., Galli, Ma. R., Chiotti, O., Information Integration Problem in B2B Relationships – A State-of-the-art, Available from: http://citeseerx.ist.psu. edu/viewdoc/download?doi=10.1.1.86.8652&rep=rep1&type=pdf, [Accessed: November 11 2011]. [24] Cardoso, J., Bussler, C., Mapping between heterogeneous XML and OWL transaction representations in B2B integration, Data & KnOWLedge Engineering, 70(12), pp. 1046-1069, 2011. [25] Chappell, D., Introducing the Windows Azure Platform, Microsoft, 2010. [26] Chen, D., Daclin, N., Framework for enterprise interoperability, IFAC TC5.3 workshop EI2N06 (Enterprise Integration Interoperability and Networking), Bordeaux, France, March 21st, 2006. [27] Chen, D., Dassisti, M., Tsalgatidou, A., Interoperability Knowledge Corpus, An intermediate Report, Deliverable DI.1, Workpackage DI (Domain of Interop- erability), INTEROP NoE, 2005. [28] Chen, D., Doumeingts, G., European initiatives to develop interoperability of enterprise applications - basic concepts, framework and roadmap, Annual Reviews in Control, Vol. 27, pp. 153-162, 2003. [29] Chen, D., Doumeingts, G., Vernadat, F., Architectures for enterprise integration and interoperability: Past, present and future, Computers in Industry, Vol. 59, pp. 647-659, 2008. Модел B2B интеграције саобраћајних пословних система 190 [30] Cheng, S., Microsoft Windows Communication Foundation 4.0 Cookbook for Developing SOA Applications, Packt Publishing, Birmingham, 2010. [31] Chituc, C., Azevedo, A., Toscano, C., A framework proposal for seamless interoperability in a collaborative networked environment, Computers in Industry, Vol. 60, pp. 317-338, 2009. [32] Chou, D. et al., SOA with .NET and Windows Azure, Prentice Hall, Boston, 2010. [33] Claramunt, C., Jiang, B., Bargiela, A., A new framework for the integration, analysis and visualisation of urban traffic data within geographic information systems, Transportation Research Part C: Emerging Technologies, Vol. 8, pp. 167-184, 2000. [34] Cohena, G., Salomonb, I., Nijkampa, P., Information-communications technologies (ICT) and transport: does knowledge underpin policy?, Telecommunications Policy, Vol. 26, pp. 31-52, 2002. [35] Commerce XML, Available from: http://www.cxml.org, [Accessed: June 8 2011]. [36] Commission of the European Communities, White paper: European transport policy for 2010: time to decide, 2001, Available from: http://ec.europa.eu/transport/strategies/doc/2001_white_paper/lb_com_2001_037 0_en.pdf, [Accessed: 20 October 2011]. [37] Commission of the European Communities, White Paper: Roadmap to a Single European Transport Area – Towards a competitive and resource efficient transport system, 2011, Available from: http://eur-lex.europa.eu/LexUriServ/ LexUriServ.do?uri=COM:2011:0144:FIN:EN:PDF, [Accessed: 18 June 2011]. [38] Courage, K. G., Washburn, S. S., Kim, J. T., Development of an XMLBased Specification for Traffic Model Data Exchange, Transportation Research Record, 1804, pp. 144-150, 2002. [39] Crapo, A., Griffith, K., Khandelwal, A., Lizzi, J., Moitra, A., Wang, X., Overcoming Challenges Using the CIM as a Semantic Model for Energy Applications, Grid-Interop Forum, GridWise Architecture Council, 2010. [40] Cruz, I., Xiao, H., An ontology-based framework for XML semantic integration, The International Database Engineering and Applications Symposium (IDEAS '04), pp. 217-226, IEEE Computer Society, Washington, D.C., USA, July 7-9 2004. [41] Cruz, I., Xiao, H., The role of ontologies in data integration, Jounal of Engineering Intelligent Systems, 13(4), pp. 1-18, 2005. [42] Cudré-Mauroux, P., Emergent Semantics, New York: EPFL Press, 2008. [43] Cui, Z., Jones, D., O'Brien, P., Semantic B2B integration: issues in ontology- based approaches, ACM SIGMOD Record, 31(1), pp. 43-48, 2002. [44] Davidsson, P., Ramstedt, L., Törnquist, J., Inter-organization interoperability in transport chains using adapters based on open source freeware, The First International Conference on Interoperability of Enterprise Software and Applications Interop-ESA'05, pp. 35-42, Geneva, Switzerland, February 23-25, 2005. Модел B2B интеграције саобраћајних пословних система 191 [45] De Vergara, J.E.L., Villagrá, V.A., Berrocal, J., Asensio, J.I., Pignaton, R., Semantic management: application of ontologies for the integration of management information models, Integrated Network Management, 2003. IFIP/IEEE Eighth International Symposium on, pp. 131-134, 2003. [46] Decker, S., Erdmann, M., Fensel, D., Studer, R., Ontobroker: Ontology based Access to Distributed and Semi-Structured Information, Database Semantics: Semantic Issues in Multimedia Systems, pp. 351-369, Kluwer Academic Publisher, 1998. [47] Di Sivo, M., Ladiana, D., Decision-support tools for municipal infrastructure maintenance management, Procedia Computer Science, Vol. 3, pp. 36-41, 2011. [48] Ding, Y., IR and AI: The role of ontology, The 4th International Conference of Asian Digital Libraries, Bangalore, India, December 10-12 2001. [49] Drakulić, G., Banjanin, M.K., Miladinović, D., Drakulić, G., Dimitrijević, A., Vasiljković, L., Primena informaciono-komunikacionih tehnologija kod provajdera transportnih usluga, Telekomunikacioni forum TELFOR 2008, Beograd, Srbija, 25-27. novembar 2008. [50] Dzemydienė, D., Maskeliūnas, S., Dzemyda, I., Interoperability of information system components for monitoring of sewage and intelligent analysis of water resources, Technological and economic development of economy, 14(3), pp. 260-278, 2008. [51] Ehrig, M., Ontology Alignment Bridging the Semantic Gap, New York: Springer, 2007. [52] EIF, European Interoperability Framework, White Paper, Brussels, February 18, 2004. [53] Electrical Engineering and Computer Sciences, University of California at Berkeley, Above the Clouds: A Berkeley View of Cloud Computing, Technical Report No. UCB/EECS-2009-28, 2009, Available from: http://www.eecs. berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html, [Accessed: July 1 2011]. [54] Ellingsen, G., Røed, K., The Role of Integration in Health-Based Information Infrastructures, Computer Supported Cooperative Work, 19(6), pp. 557-584, 2010. [55] ERISA (The European Regional Information Society Association), A guide to Interoperability for Regional Initiatives, Brussels, September 2004, Available from: http://www.broadband-europe.eu/Lists/Competences/ IANIS_Guide_to_Interoperability.pdf, [Accessed: November 18 2011]. [56] Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR, New Jersey, USA, 2005. [57] Erl, T., SOA Design Patterns, Prentice Hall, Boston, 2009. [58] Erl, T., SOA: Principles of Service Design, Prentice Hall, Boston, 2008. [59] ERTICO - ITS Europe, Intelligent Transport Systems and Services for Europe, Project TRIDENT - TRansport Intermodality Data sharing and Exchange Модел B2B интеграције саобраћајних пословних система 192 NeTworks, 2003, Available from: http://www.ertico.com/assets/download/ trident/2_d12.pdf, [Accessed: 18 July 2011]. [60] Feki, M. F., Kamoun, M. A., Hammadi, S., Advanced Traveler Information System: An Agent-based Approach for Itineraries Web-Services Composition, Buletinul Universitatii Petrol Gaze din Ploiesti, Seria Matematica-Informatica- Fizica, LXI(1), pp. 51-64, 2009. [61] Furht, B., Escalante, A., Handbook of Cloud Computing, Springer Scince+Business Media, New York, 2010. [62] Gannon, T., Madnick, S., Moulton, A., Siegel, M., Sabbouh, M., Zhu, H., Semantic Information Integration in the Large: Adaptability, Extensibility, and Scalability of the Context Mediation Approach, Technical Report, CISL# 2005- 04. MIT, Cambridge, MA, 2005. [63] García Díez, M. A., Roca, J., Goebel, N., Healey A., Six Questions Every Executive in Infrastructure & Transportation Services Should Ask About Cloud Computing, Accenture Institute for High Performance, 2010, Available from: http://www.accenture.com/SiteCollectionDocuments/PDF/ Accenture_ITS_cloud_POV.pdf. [Accessed: 18 November 2011]. [64] Garcia, R., Gil, R., Facilitating business interoperability from the semantic Web, In Proceedings of the 10th international conference on Business information systems (BIS'07), Witold Abramowicz (Ed.), pp. 220-232, Springer-Verlag, Berlin, Heidelberg, 2007. [65] Garcia-sanchez, F., Fernandez-breis, E., Valencia-garcia, R., Gomez, J.M., Martinez-maqueda, D., Adding Semantics to Software-as-a-Service and Cloud Computing, 9(2), pp. 154-163, 2010. [66] Gardner, P. S., Ontologies and semantic data integration, Drug Discovery Today, 10(14), pp. 1001-1007, 2005. [67] Gelernter, J., Lesk, M., Use of Ontologies for Data Integration and Curation, The International Journal of Digital Curation, 6(1), pp. 70-78, 2011. [68] Gessa, N., An ontology-based approach to define and manage B2B interoperability, Dottorato di Ricerca in Informatica, Universit`a di Bologna, Padova, 2007, Available from: http://ebookbrowse.com/nicola-gessa-tesi-di- dottorato-pdf-d53605047, [Accessed: June 5 2011]. [69] Giannopoulos, G.A., The application of information and communication technologies in transport, European Journal of Operational Research, Vol. 152, pp. 302-320, 2004. [70] Governor, J., James Governor's Monkchips, An industry analyst blog looking at software ecosystems and convergence, Available from:http://www.redmonk.com/ jgovernor/2008/03/13/15-ways-to-tell-its-not-cloud-computing/,[Accessed: December 11 2011]. [71] Gruber, T., A translation approach to portable ontology specifications, Knowledge Acquisition, 5(2), 1993. [72] Guglielmina, C., Berre, A., ATHENA Project A4, ATHENA Intermediate Audit, Athens, Greece, September 29–30, 2005. Модел B2B интеграције саобраћајних пословних система 193 [73] Han, T., Mong Sim, K., An Ontology-enhanced Cloud Service Discovery System, Proceedings of the International MultiConference of Engineers and Computer Scientists 2010 - IMECS 2010, 17-19 March, 2010, Hong Kong. [74] Hanis, T., Noller, D., The role of semantic models in smarter industrial operations, IBM Developer Works, 2011, Available from: http://www.ibm.com/developerworks/industry/library/ind-semanticmodels/ind- semanticmodels-pdf.pdf, [Accessed: November 15 2011]. [75] Heimbigner, D., DMTF-CIM to OWL: A case study in ontology conversion, SEKE 2004 International Conference of Software Engineering and Knowledge Engineering, Canada, 2004. [76] Horridge, M., A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools, Edition 1.3, The University Of Manchester 2011, Available from: http://OWL.cs.manchester.ac.uk/tutorials/protegeOWLtutorial/ resources/ProtegeOWLTutorialP4_v1_3.pdf, [Accessed: September 18 2011]. [77] Hrin, G. R., Anghel, L. E., Tomescu, M., Iliescu, I., Savu, D., Solutions for Finding the Optimum Route between Two Urban Locations Using Public or Private Transport or Pedestrian Movement, Studies in Informatics and Control, 17(4), pp. 353-360, 2008. [78] Hsu, C., Wallace, W. A., An industrial network flow information integration model for supply chain management and intelligent transportation, Enterprise Information Systems, 1(3), pp. 327-351, 2007. [79] IDEAS Consortium, Thematic Network, IDEAS: Interoperability Development for Enterprise Aplication and Software – Roadmaps, Annex 1 – DoW, 2002. [80] IDEAS, Interoperability Developments for Enterprise Application and Software– Roadmaps, European Project IST-2001-37368, Available from: http://www.ideas- roadmaps.net, [Accessed: December 14 2011]. [81] Institute of Electrical and Electronics Engineers, IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York: IEEE Press Piscataway, 1991. [82] InteGRail Consortium, InteGRail - Intelligent Integration of Railway Systems, Available from: http://www.integrail.info/documenti/Presentation.pdf, [Accessed: 10 August 2011]. [83] INTEROP NoE, Interoperability Research for Networked Enterprises Applications and Software, Network of Excellence, IST-508011, 2005, Available from: http://www.interop-noe.org, [Accessed: December 13 2011]. [84] ISO 14258, Industrial Automation Systems - Concepts and Rules for Enterprise Models, ISO TC184/SC5/WG1, April 14, 1999. [85] Janković, S., Interoperabilnost saobraćajnih poslovnih sistema zasnovana na integraciji B2B servisno orijentisanih aplikacija, Info M, Vol. 36, str. 4-12, 2010. [86] Janković, S., Interoperabilnost saobraćajnih poslovnih sistema zasnovana na integraciji B2B servisno orijentisanih aplikacija, magistarska teza, mentor dr Božidar Radenković, Fakultet organizacionih nauka, Beograd, 2010. Модел B2B интеграције саобраћајних пословних система 194 [87] Janković, S., Mladenović, S., Branović, I., Milinković, S., Cloud computing u saobraćaju i transportu, III Međunarodni simpozijum Novi horizonti saobraćaja i komunikacija, Doboj, Republika Srpska, 24-25. novembar 2011. [88] Janković, S., Mladenović, S., Mitrović, S., Pavlović, N., Aćimović, S., A model for integration of railway information systems based on cloud computing technology, ICEST 2011 - XLVI International Scientific Conference On Information, Communication And Energy Systems And Technologies, Niš, Serbia, June 29 - July 1, 2011. [89] Janković, S., Mladenović, S., Neki aspekti interoperabilnosti poslovnih sistema i njihovih aplikacija, XXXV Simpozijum o operacionim istraživanjima SYM-OP- IS ‘08, str. 71-74, Soko Banja, Srbija, 14-17. septembar 2008. [90] Janković, S., Mladenović, S., Radonjić, V., Kostić-Ljubisavljević, A., Uzelac, A., Integration Platform-As-A-Service In The Traffic Safety Area, MIC-CNIT2011, Mosharaka International Conference on Communications, Networking and Information Technology, pp. 70-75, Dubai, UAE, December 16-18. 2011. [91] Janković, S., Mladenović, S., Vesković, S., Milinković, S., Neki aspekti primene cloud computing tehnologije u elektronskom poslovanju železnica, SYM-OP-IS ‘11, XXXVIII Simpozijum o operacionim istraživanjima, Zlatibor, Srbija, 4-7. oktobar 2011. [92] Jarulaitis, G., Conceptualizing the Multiplicity of Integration, Information Technology and Control, 36(1), pp. 110-116, 2007. [93] Jennings, R., Cloud Computing with the Windows® Azure™ Platform, Wiley Publishing, Inc., Indianapolis, USA, 2009. [94] Jevtović, B., Oklobdžija, D., Mladenović, V., Bogdanović, B., ebXML – interoperabilno radno okruženje globalnogelektronskog tržišta, ICIST 2012 2nd International Conference on Information Society Technology, February 29 – March 3, 2012, Kopaonik, Serbia. [95] Juric, M. B., Loganathan R., Sarang, P., Jennings, F., SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects, Birmingham: Packt Publishing, 2007. [96] Kalfoglou, Y., Cases on Semantic Interoperability for Information Systems Integration: Practices and Applications, New York: Information Science Reference, 2010. [97] Kalfoglou, Y., Schorlemmer, M., Ontology mapping: the state of the art, The Knowledge Engineering Review, pp. 1-31, 18(1), 2003. [98] Karacapilidis, N., Lazanas, A., Megalokonomos, G., Moraïtis, P., On the development of a Web-based system for transportation services, Information Sciences, Vol. 176, pp. 1801-1828, 2006. [99] Kokar, M., Matheus, C., Baclawski, K., Letkowski, J., Hinman, M., Salerno, J., Use cases for ontologies in information fusion, Lecture Notes in Economics and Mathematical Systems Series, London: Springer Verlag, 1995. [100] Krishnaswamy, J., Microsoft SQL Azure: Enterprise Application Development, Packt Publishing, Birmingham, 2010. Модел B2B интеграције саобраћајних пословних система 195 [101] Lampathaki, F., Mouzakitis, S., Gionis, G., Charalabidis, Y., Askounis, D. Business to business interoperability: A current review of XML data integration standards, Computer Standards & Interfaces, 31, pp. 1045-1055, 2009. [102] Lee, W., Tseng, S., Shieh, W., Collaborative real-time traffic information generation and sharing framework for the intelligent transportation system, Information Sciences, 180(1), pp. 62-70, 2010. [103] Leng, Y., Zhao, L., Novel design of intelligent internet-of-vehicles management system based on cloud-computing and Internet-of-Things, International Conference on Electronic & Mechanical Engineering and Information Technology, Vol. 6, pp. 3190-3193, 12-14 Aug. 2011. [104] Leslie, King J., Modern Information Infrastructure in the Support of Distributed Collective Practice in Transport, Computer Supported Cooperative Work, 15(2-3), pp. 111-121, 2006. [105] Li, H., Introduction to Windows Azure, Apress, New York, 2010. [106] Li, Z., Chen, C., Wang, K., Cloud Computing for Agent-Based Urban Transportation Systems, IEEE Intelligent Systems, Vol. 26, pp. 73-79, 2011. [107] Liapis, A., Christiaens, S., Collaboration Across the Enterprise: An Ontology Based Approach for Enterprise Interoperability, Semantic Enterprise Application Integration for Business Processes: Service-Oriented Frameworks, pp. 1-18, New York: Information Science Reference, 2010. [108] Linthicum, D. S., Cloud Computing and SOA Convergence in Your Enterprise, Pearson Education, Boston, 2010. [109] Linthicum, D., Next Generation Application Integration: From Simple Information to Web Services, Boston: Addison Wesley, 2003. [110] Liu, S., Cao, Y., Li, M., Kilaru, P., Smith, T., Toner, S., A Semantics-and Data- Driven SOA for Biomedical Multimedia Systems, 10th IEEE International Symposium on Multimedia 2008, pp. 533-538, 2008. [111] Marković, M., Ivić, M., Pavlović, N., Janković, S., Analysis of Simulation Model Aplication to Forecast the Railway Workers Failures, YUJOR - The Yugoslav Journal of Operations Research, 17(1), pp. 135-144, 2007. [112] Marks, E.A., Lozano, B., Executive's Guide to Cloud Computing, John Wiley & Sons, Inc., Hoboken, New Jersey, 2010. [113] Marston, S., Li, Z., Bandyopadhyay, S., Zhang, J., Ghalsasi, A., Cloud computing - The business perspective, Decision Support Systems, 51(1), pp. 176-189, 2011. [114] Matis, P., Decision Support System for Solving the Street Routing Problem, Transport, 23(3), pp. 230–235, 2008. [115] Mentzas, G., Semantic enterprise application integration for business processes: service-oriented frameworks, New York: Business Science Reference, 2010. [116] Mladenović, S., Janković, S., Integracija saobraćajnih informacionih sistema u cloud computing okruženju, PosTel 2011 XXIX simpozijum o novim tehnologijama u poštanskom i telekomunikacionom saobraćaju, 305-314, Beograd, Srbija, 6-7. decembar 2011. Модел B2B интеграције саобраћајних пословних система 196 [117] Nardon, F.B., Moura, L.A., Knowledge sharing and information integration in healthcare using ontologies and deductive databases, Medinfo, 62–66, 2004. [118] Natis, Y. V., Lheureux, B. J., Cantara, M., Pezzini, M., Gootzit, D., Cearley, D. W., Kenney, L. F., Feinberg, D., Friedman, T., Feiman, J., Key Issues for Cloud- Enabled Application Infrastructure, Available from: http://www.gartner.com/ it/content/128400/ 1128412/ key_issues_for_cloudenabled_app_inf.pdf. [119] Naudet, Y., Latour, T., Guedria, W., Chen, D., Towards a systemic formalisation of interoperability, Computers in Industry, Vol. 61, pp. 176-185, 2010. [120] New York Metropolitan Transportation Council, Transportation System Operations and Management, 2010-2035 NYMTC Regional Transportation Plan, Chapter 5, pp. 1-25, 2008, Available from: http://www.nymtc.org/rtp/documents/ CHAPTER/5_NYMTC_RTP_OperationsManagement.pdf, [Accessed: 10 November 2011]. [121] Ni, D., Leonard II, J. D., Development of TrafficXML: a Prototype XML for Traffic Simulation, Transportation Research Record, Vol. 1879, pp. 30-40, 2004. [122] Nicole, C., Interoperability between Distributed Systems and Web-Services Composition, Encyclopedia of Information Science and Technology, pp. 2210- 2215, New York: Information Science Reference, 2009. [123] Nicolle, C., Cruz, C., Graph-Based Rules for Xml Data Conversion to OWL Ontology, The 6th International Conference on Web Information Systems and Technologies WEBIST 2010, Vol. 1, pp. 175-178, Valencia, Spain, April 7-10, 2010. [124] Njeguš, A, Grubor, G., Servisno-orijentisana arhitektura i grid computing, Singidunum revija, 5(1), стр. 103-115, 2010. [125] Object Management Group, Inc., Common Object Request Broker Architecture (CORBA) Specification, Version 3.1.1, 2011, Available from: http://www.omg. org/spec/CORBA/3.1.1/Interoperability/PDF, [Accessed: 18 July 2011]. [126] Obrst, L., Ontologies for semantically interoperable systems, In Proceedings of the twelfth international conference on Information and knowledge management (CIKM '03), ACM, New York, USA, pp. 366-369, 2003. [127] Orgun, B., Dras, M., Nayak, A., Approaches for semantic interoperability between domain ontologies, The Australasian Ontology Workshop (AOW), Vol. 72, Hobart, Australia, 2006. [128] Panetto, H., Molina, A., Enterprise integration and interoperability in manufacturing systems: Trends and issues, Computers in Industry, Vol. 59, pp. 641-646, 2008. [129] Panetto, H., Scannapieco, M., Zelm, M., INTEROP NoE: Interoperability Research for Networked Enterprises Applications and Software, Lecture Notes in Computer Science, Vol. 3292/2004, pp. 866-882, 2004. [130] Peng, Z., Kim, E., A Standard-Based Integration Framework for Distributed Transit Trip Planning Systems, Journal of Intelligent Transportation Systems, 12(1), pp. 13-28, 2008. Модел B2B интеграције саобраћајних пословних система 197 [131] Petrie, C.J. (Ed.), Enterprise Integration Modeling, Cambridge: The MIT Press, 1992. [132] Pezzini, M., Lheureux, B. J., Integration Platform as a Service: Moving Integration to the Cloud, Gartner RAS Core Research Note G00210747, 7 March 2011, Available from: ftp://public.dhe.ibm.com/software/integration/cast-iron- cloud/Gartner-cloud.pdf, [Accessed: August 10 2011]. [133] Puustjärvi, J., Semantic Interoperability in Electronic Business, International Journal of Computer Science Issues, 7(5), pp. 51-63, 2010. [134] Quirolgico, S., Assis, P., Westerinen, A., Baskey, M., Stokes, E., Toward a Formal Common Information Model Ontology, WISE Workshops, Lecture Notes in Computer Science, pp. 11-21, Springer, 2004. [135] Radonjic, V., Jankovic, S., Mladenovic, S., Veskovic, S., Kostic-Ljubisavljevic, A., B2B Integration of Rail Transport Systems in Cloud Computing Environment, The 4th International Symposium on Applied Sciences in Biomedical and Communication Technologies - ISABEL '11, Barcelona, Spain, October 26-29. 2011, ACM Digital Library, New York, USA, Available from: http://dl.acm.org/citation.cfm?id=2093833, [Accessed: 10 December 2011]. [136] Rimal, B.P., Jukan, A., Katsaros, D., Goeleven, Y., Architectural Requirements for Cloud Computing Systems: An Enterprise Cloud Approach, Journal of Grid Computing, 9(1), pp. 3-26, 2010. [137] Rodero-Merino, L., Vaquero, L.M., Gil, V., Galán, F., Fontán, J., Montero, R.S. & Llorente, I.M., From infrastructure delivery to service management in clouds, Future Generation Computer Systems, 26(8), pp. 1226-1240, 2010. [138] Rosen, M., Lublinsky, B., Smith, K. T., Balcer, M. J., Applied SOA: Service- Oriented Architecture and Design Strategies, Indianapolis: Wiley Publishing, 2008. [139] Roshen, W., SOA-Based Enterprise Integration: A Step-by-Step Guide to Services-Based Application Integration, New York: The McGraw-Hill Companies, 2009. [140] Rutkauskas, R., Lipnickas, A., Ramonas, Č., Kubilius, V., New Challenges for Interoperability of Control Systems, Electronics and Electrical Engineering, 3(83), pp. 71-74, 2008. [141] Sabou, M., Extracting ontologies from software documentation: a semi-automatic method and its evaluation, Workshop on Ontology Learning and Population (ECAI-OLP), Valencia, Spain, August 22-23 2004. [142] Samtani, G., B2B Integraton: A Practical Guide To Collaborative E-Commerce, London: Imperial College Press, 2002. [143] Scale, M.-S.E., Cloud computing and collaboration, Library Hi Tech News, 26(9), pp. 10-13, 2009. [144] Sehgal, S., Erdelyi, M., Merzky, A., Jha, S., Understanding application-level interoperability: Scaling-out MapReduce over high-performance grids and clouds, Future Generation Computer Systems, 27(5), pp. 590-599, 2011. Модел B2B интеграције саобраћајних пословних система 198 [145] Seroter, R., Fairweather, E., Thomas, S. W., Sexton, M., Ramani, R., Applied Architecture Patterns on the Microsoft Platform, Packt Publishing, Birmingham, 2010. [146] Serrano Orozco, J. M., Applied Ontology Engineering in Cloud Services, Networks and Management Systems, London: Springer, 2012. [147] Shariati, M., Bahmani, F., Shams, F., Enterprise information security, a review of architectures and frameworks from interoperability perspective, Procedia Computer Science, Vol. 3, pp. 537-543, 2011. [148] Sharp, J., Windows® Communication Foundation 4 Step by Step, O’Reilly Media, Inc., Sebastopol, 2010. [149] Sheldon, B., Hollis, B., Sharkey, K., Marbutt, J., Windsor, R., Hillar, G. C., Professional Visual Basic® 2010 and .NET 4, Wiley Publishing, Inc., Indianapolis, 2010. [150] Sheth, A. P., Changing Focus On Interoperability In Information Systems: From System, Syntax, Structure To Semantics, Interoperating Geographic Information Systems, pp. 5-30, 1998. [151] Smith, D. M., Cearley, D. W., Plummer, D. C., Key Issues for Cloud Computing, Available from: http://www.gartnerinsight.com/download/ KeyIssues_CloudComputing_2010.pdf, [Accessed: December 8 2011]. [152] Staab, S. Studer, R. (Eds.), Handbook on Ontologies, Springer-Verlag, Berlin Heidelberg, 2009. [153] Stanoevska-Slabeva, K., Wozniak, T., Ristol, S. (Editors), Grid and Cloud Computing, Springer-Verlag, Berlin, Heidelberg, 2010. [154] Su, X., A Text Categorization Perspective for Ontology Mapping, Technical report, Department of Computer and Information Science, Norwegian University of Science and Technology, Norway, 2002. [155] Subashini, S., Kavitha, V., A survey on security issues in service delivery models of cloud computing, Journal of Network and Computer Applications, 34(1), pp. 1-11, 2011. [156] Szűcs, G., Developing co-operative transport system and route planning, Transport, 24(1), pp. 21–25, 2009. [157] Тhe European Commission, IDABC programme, Interoperability Framework for Pan-European E-government Services, Available from: http://ec.europa.eu/idabc/ servlets/Docd552.pdf?id=19529, [Accessed: October 8 2011]. [158] The French Republic, PREDIT - French National Program of Research, Experimentation and Innovation in land Transport, 2006, Available from: http://www.predit.prd.fr/predit3/english.html, [Accessed: 12 August 2011]. [159] The Open Group, Service-Oriented Architecture Ontology, Technical Standard, The Open Group, Berkshire, United Kingdom, 2010. [160] Törnquist, J., Gustafsson, I., Perceived benefits of improved Information exchange - a case study on rail and intermodal transports, Research in Transportation Economics, Vol. 8, pp. 415-440, 2004. Модел B2B интеграције саобраћајних пословних система 199 [161] Transport Direct, Department for Transport, United Kingdom, Transport Direct Portal, 2003, Available from: http://www.transportdirect.info/Web2/Home.aspx, [Accessed: 13 August 2011]. [162] Trinkunas, J., Vasilecas, O., Building ontologies from relational databases using reverse engineering methods, The 2007 international conference on Computer systems and technologies - CompSysTech ’07., New York, USA, 2007. [163] Turcu, Cr., Prodan, R., Cerlincă, M., Turcu, C., Cerlincă, T., RFID@B2B a Powerful Enabler of Business Transformation, Electronics and Electrical Engineering, 5(93), pp. 59-64, 2009. [164] Ullberg, J., Chen, D., Johnson, P., Barriers to Enterprise Interoperability, Second IFIP WG 5.8 InternationalWorkshop IWEI 2009, pp. 13-24, Valencia, Spain, October 13-14, 2009. [165] Uzelac, A., Janković, S., Mladenović, S., Vujanović, D., Aplikacija za podršku isporuke robe drumom, SYM-OP-IS ‘10 XXXVII Simpozijum o operacionim istraživanjima, Tara, Srbija, 21-24. septembar 2010. [166] Vernadat, F. B., Technical, semantic and organizational issues of enterprise interoperability and networking, Annual Reviews in Control, 34(1), pp. 139-144, 2010. [167] Vernadat, F.B., Interoperable enterprise systems: Principles, concepte and methods, Annual Reviews in Control, Vol. 27, pp. 137-145, 2007. [168] Verstichel, S., Ongenae, F., Loeve, L., Vermeulen, F., Dings, P., Dhoedt, B., Dhaene, T., De Turck, F., Efficient data integration in the railway domain through an ontology-based methodology, Transportation Research Part C, 19(4), pp. 617-643, 2011. [169] Vesković, S., Čičak, M., Milinković, S., Janković, S., Modelling and optimising the plan of making up freight trains with application, 10th World Conference on Transport Research, Istanbul, Turkey, July 4-8. 2004. [170] Vesković, S., Janković, S., Mladenović, S., Milinković, S., Modeliranje i optimizacija plana formiranja teretnih vozova sa aplikacijom, Železnice, 61(1-2), str. 3-20, 2005. [171] Vetere, G., Lenzerini, M., Models for semantic interoperability in service- oriented architectures, IBM Systems Journal, 44(4), pp. 887-903, 2005. [172] Vidal, V., Pinheiro, J., Sacramento, E., An Ontology-Based Framework for Heterogeneous Data Sources Integration, Revista de Informática Teórica e Aplicada, 16(2), pp. 61-64, 2009. [173] Vujasinovic, M., Barkmeyer, E., Ivezic, N., Marjanovic, Z., Interoperable Supply-Chain Applications: Message Metamodel-Based Semantic Reconciliation of B2B Messages, International Journal of Cooperative Information Systems, 19(01 & 02), pp. 31–69, 2010. [174] Vujasinovic, M., Ivezic, N., Kulvatunyou, B., Barkmeyer, E., Missikoff, M., Taglino, F., Marjanovic, Z., Miletic, I., Semantic Mediation for Standard-Based B2B Interoperability, IEEE Internet Computing, 14(1), pp. 52-63, 2010. Модел B2B интеграције саобраћајних пословних система 200 [175] Western, J., Information Technology in Transportation Key Issues and a Look Forward, Transportation in the New Millennium, 2000, Available from: http://onlinepubs.trb.org/Onlinepubs/millennium/00054.pdf, [Accessed: 18 November 2011]. [176] Xu, Z., Zhang, S., Dong, Y., 2006. Mapping between Relational Database Schema and OWL Ontology for Deep Annotation, In Proceedings of the 2006 IEEE/WIC/ACM International Conference on Web Intelligence (WI '06). IEEE Computer Society, Washington, DC, USA, 548-552, 2006. [177] Yang, Q. (K.), Wei, H., Manring, J. R., Agarwal, P., XML, SOAP and Web services: A New Option to ITS C2C Communication and Interoperability, The Transportation Research Board 82nd Annual Meeting, Washington, D.C., USA, January 12-16, 2003, Available from: http://www.ltrc.lsu.edu/TRB_82/TRB2003- 001647.pdf, [Accessed: 13 August 2011]. [178] Yang, Q. (K.), Wei, H., Barbaresso, J. C., Applying XML, SOAP and Web services to ITS Center-to-Center Integration: Software Framework and Demonstration, The Transportation Research Board 83rd Annual Meeting, Washington, D.C., USA, January 11-15, 2004. [179] Yi, S., Huang, B., Integrating Heterogeneous Traveler Information Using Web Service, Journal of Geographic Information Science, 11(1), pp. 50-60, 2005. [180] Zavattero, D., Wu, W., Use of CORBA and Object Oriented Concepts in the Gary-Chicago-Milwaukee (GCM) Gateway Traveler Information System, The Transportation Research Board 82nd Annual Meeting, Washington, D.C., USA, January 12-16, 2003, Available from: http://www.ltrc.lsu.edu/TRB_82/TRB2003- 002438.pdf, [Accessed: 13 August 2011]. [181] Zhang, B., Zhang, N., Li, H., Liu, F., Miao, K., An Efficient Cloud Computing- Based Architecture for Freight System Application in China Railway, Cloud Computing, Lecture Notes in Computer Science, Vol. 5931/2009, pp. 359-368, Springer, London, 2009. [182] Zhu, Y., Wang, J., Wang, C., Ripple: A publish/subscribe service for multidata item updates propagation in the cloud, Journal of Network and Computer Applications, 34(4), pp. 1054-1067, 2011. [183] Ziliaskopoulos, A.K., Waller, S.T., An Internet-based geographic information system that integrates data, models and users for transportation applications, Transportation Research Part C: Emerging Technologies, 8(1-6), pp. 427-444, 2000. [184] Zissis, D., Lekkas, D., Addressing cloud computing security issues, Future Generation Computer Systems, 28(3), pp. 583-592, 2012. [185] Zou, G., Chen, Y., Xiang, Y., Huang, R., Xu, Y., AI Planning and Combinatorial Optimization for Web Service Composition in Cloud Computing, Proceedings of the International Conference on Cloud Computing & Virtualization 2010 CCV 2010, pp. 28-35, 2010. Модел B2B интеграције саобраћајних пословних система 201 9. Списак слика Слика 1. Интероперабилност предузећа на четири основна нивоа ........................ 15 Слика 2. Радни оквир интероперабилности............................................................. 16 Слика 3. Интеграција знања ATHENA пројекта ....................................................... 19 Слика 4. ATHENA радни оквир интероперабилности ............................................. 20 Слика 5. ATHENA референтна архитектура интероперабилности.......................... 23 Слика 6. Европски радни оквир интероперабилности ............................................ 24 Слика 7. Графички приказ интеграције апликација помоћу интеграције пословних процеса....................................................................................................... 34 Слика 8. Електронска пословна колаборација......................................................... 40 Слика 9. BizTalk Server адаптери.............................................................................. 41 Слика 10. Request/Response патерн размене порука између сервиса и клијента .... 44 Слика 11. One-way патерн размене порука између сервиса и клијента .................. 44 Слика 12. Request/Callback патерн размене порука између сервиса и клијента..... 45 Слика 13. Publish/Subscribe патерн размене порука између сервиса и клијента .... 45 Слика 14. Најзаступљенији модели података .......................................................... 47 Слика 15. OWL ресурс има тачно једну вредност одређеног својства.................... 53 Слика 16. OWL ObjectProperty повезује један ресурс са другим ресурсом ............ 54 Слика 17. OWL DatatypeProperty повезује ресурс са rdfs:Literal или неким XML Schema уграђеним типом података. ........................................................ 54 Слика 18. Хармонизација простора сарадње ........................................................... 55 Слика 19. Онтолошки „кестен” ................................................................................ 56 Слика 20. Приступ семантичкој интероперабилности заснован на коришћењу једне онтологије....................................................................................... 57 Слика 21. Приступ семантичкој интероперабилности заснован на коришћењу више локалних онтологија ...................................................................... 57 Слика 22. Хибридни приступ семантичкој интероперабилности заснован на коришћењу више локалних онтологија и глобалног дељеног речника. 58 Слика 23. Централизовани „свако-према-сваком” модел семантичке интероперабилности ................................................................................ 59 Слика 24. Централизовани „сви-према-једном” модел семантичке интероперабилности ................................................................................ 60 Слика 25. Децентрализовани „свако-према-сваком” модел семантичке интероперабилности ................................................................................ 61 Слика 26. Децентрализовани „сви-према-једном” модел семантичке интероперабилности ................................................................................ 61 Слика 27. Архитектура интероперабилности .......................................................... 73 Слика 28. Равни интероперабилности у логистичком информационо- комуникационом систему ....................................................................... 75 Слика 29. Оквир интероперабилности у саобраћајно-транспортном сектору ....... 84 Модел B2B интеграције саобраћајних пословних система 202 Слика 30. „Одоздо-нагоре” приступ у развоју сервисно-оријентисаног решења B2B интеграције....................................................................................... 85 Слика 31. „Одозго-надоле” приступ у развоју сервисно-оријентисаног решења B2B интеграције....................................................................................... 86 Слика 32. Фаза сервисно-оријентисане анализе у развоју решења B2B интеграције .................................................................................................................. 87 Слика 33. Фаза моделирања сервиса кандидата у развоју решења B2B интеграције .................................................................................................................. 88 Слика 34. Фаза сервисно-оријентисаног дизајна у развоју решења B2B интеграције .................................................................................................................. 89 Слика 35. Аgile стратегија у развоју сервисно-оријентисаног решења B2B интеграције .............................................................................................. 90 Слика 36. Компоненте cloud computing технологије ............................................... 94 Слика 37. Компоненте предложеног модела B2B интеграције саобраћајних пословних система................................................................................... 97 Слика 38. Детаљна структура предложеног модела B2B интеграције саобраћајних пословних система................................................................................... 98 Слика 39. Архитектура система B2B интеграције саобраћајних пословних система .................................................................................................................. 99 Слика 40. Дијаграм активности: Анализа постојећег информационог система... 100 Слика 41. Креирање саобраћајног информационог модела .................................. 102 Слика 42. Дијаграм активности: Креирање онтологије......................................... 103 Слика 43. Дијаграм секвенци: Сценарио 1 B2B интеграције саобраћајних пословних система................................................................................. 104 Слика 44. Дијаграм секвенци: Сценарио 2 B2B интеграције саобраћајних пословних система................................................................................. 104 Слика 45. Дијаграм секвенци: Сценарио 3 B2B интеграције саобраћајних пословних система................................................................................. 105 Слика 46. Дијаграм секвенци: Сценарио 4 B2B интеграције саобраћајних пословних система................................................................................. 105 Слика 47. Дијаграм секвенци: Сценарио 5 B2B интеграције саобраћајних пословних система................................................................................. 105 Слика 48. Дијаграм секвенци: Сценарио 6 B2B интеграције саобраћајних пословних система................................................................................. 106 Слика 49. Локална апликација приступа локалним подацима.............................. 107 Слика 50. Локална апликација приступа подацима у облаку ............................... 107 Слика 51. Локална апликација позива сервис из облака ....................................... 108 Слика 52. Сервис из облака приступа локалним подацима .................................. 108 Слика 55. Дијаграм активности: Реализација система B2B интеграције саобраћајних пословних система .......................................................... 110 Слика 56. Интегрисање информација о безбедности саобраћаја у заједничкој бази података у облаку .................................................................................. 111 Слика 57. Интеграција информација вођена упитима........................................... 116 Модел B2B интеграције саобраћајних пословних система 203 Слика 58. Надлежности понуђача и клијента у зависности од услуге платформе ................................................................................................................ 122 Слика 59. Компоненте Microsoft Windows Azure платформе [25] ......................... 126 Слика 60. Windows Azure AppFabric платформа [25] ............................................ 128 Слика 61. SQL Azure компонента [25].................................................................... 129 Слика 62. Windows Azure компонента [25]............................................................. 130 Слика 63. Windows Azure Compute сервис [25] ...................................................... 132 Слика 64. Windows Azure Storage сервис [25] ........................................................ 133 Слика 65. Microsoft Visual Studio 2010 Windows Azure Project .............................. 134 Слика 66. Microsoft Visual Studio 2010 ASP.NET Web Role.................................... 134 Слика 67. Структура постојеће базе података Putno-pruzni prelazi у ЈППС......... 138 Слика 68. Структура постојеће базе података Crne tacke у ЈППС ........................ 139 Слика 69. Падајући мени Izveštaji из постојеће апликације OPASNA MESTA у ЈППС ...................................................................................................... 140 Слика 70. Подмени STATISTIKA O SAOBRAĆAJNIM NEZGODAMA падајућег менија Izveštaji из постојеће апликације OPASNA MESTA у ЈППС ..... 140 Слика 71. Сценарији интеграције уз помоћ интеграционе платформе као сервиса ................................................................................................................ 141 Слика 72. Креирање локалне онтологије МУП ..................................................... 144 Слика 73. Хијерархија класа локалне онтологије МУП ........................................ 144 Слика 74. Граф основних класа локалне онтологије МУП ................................... 145 Слика 75. Граф свих класа локалне онтологије МУП ........................................... 146 Слика 76. Атрибут osobinePovrsineKolovoza класе Saobracajna_nezgoda локалне онтологије МУП .................................................................................... 146 Слика 77. Атрибути и вредности атрибута једне инстанце класе Saobracajna_nezgoda.............................................................................. 147 Слика 78. Семантичко означавање вредности атрибута osobinePovrsineKolovoza класе Saobracajna_nezgoda локалне онтологије МУП ......................... 147 Слика 79. Релације класе Saobracajna_nezgoda локалне онтологије МУП .......... 148 Слика 80. Хијерархија класа локалне онтологије ЈППС ....................................... 149 Слика 81. Граф основних класа локалне онтологије ЈППС .................................. 150 Слика 82. Граф свих класа и подкласа локалне онтологије ЈППС ....................... 150 Слика 83. Граф релација између класа локалне онтологије ЈППС ....................... 152 Слика 84. Граф релација између класа локалне онтологије ЖС........................... 153 Слика 85. Граф релација између класа доменске онтологије ............................... 154 Слика 86. Microsoft SQL Azure сервер .................................................................... 155 Слика 87. Структура заједничке базе података Bezbednost u saobracaju.............. 156 Слика 88. Граф зависности табеле Putni pravac базе Bezbednost u saobracaju..... 156 Слика 89. Упити креирани над заједничком базом података Bezbednost u saobracaju............................................................................................... 157 Слика 90. Упит Ukupan broj poginulih lica po opasnim mestima ............................ 158 Модел B2B интеграције саобраћајних пословних система 204 Слика 91. Резултат упита Ukupan broj poginulih lica po opasnim mestima ............ 158 Слика 92. Креирање сервиса serbian railroad crossings који ће бити хостован на Windows Azure платформи..................................................................... 159 Слика 93. Web портал Serbian Railroad Crossings хостован као сервис на Windows Azure платформи.................................................................................... 160 Слика 94. Кориснички интерфејс за ажурирање података о саоб. незгодама ...... 161 Слика 95. Кориснички интерфејс за приказ података о саоб. незгодама на ппп.. 161 Слика 96. Кориснички интерфејс за генерисање безбедносних параметара ппп. 162 Слика 97. Кориснички интерфејс за приказ обима и структуре саобраћаја на ппп ................................................................................................................ 162 Слика 98. Структура Web апликације Preuzimanje podataka iz eksternih izvora ... 163 Слика 99. Могући стрингови конекције са базом података из облака.................. 164 Слика 100. Креирање ADO.Net Entity Data модела над SQL Azure базом података .............................................................................................................. 164 Слика 101. Ентитет Putni_pravac сервиса WCFDataServicePutnaInfrastruktura... 165 Слика 102. Ентитет PGDS(100) сервиса WCFDataServicePGDS........................... 166 Слика 103. Иницијализовање сервиса WCFDataServiceSaobracajneNezgode ....... 167 Слика 104. Страница Web апликације која приказује податке из облака добијене од сервиса WCFDataServiceSaobracajneNezgode................................ 167 Слика 105. Иницијализовање сервиса WCFDataServicePGDS.............................. 168 Слика 106. Страница Web апликације која приказује податке из SQL Server базе података ЈППС добијене од сервиса WCFDataServicePGDS ............. 168 Слика 107. Креирање конекције ка SQL Azure бази Bezbednost u saobracaju ...... 169 Слика 108. Windows апликација која извршава упите над SQL Azure базом података Bezbednost u saobracaju........................................................ 170 Слика 109. Структура табеле Red voznje po stanicama SQL Azure базе података Zeleznice ............................................................................................... 171 Слика 110. Подаци у табели Red voznje po stanicama SQL Azure базе података Zeleznice ............................................................................................... 171 Слика 111. Креирање сервиса ZelezniceSrbijeRedVoznje на Windows Azure платформи ............................................................................................ 172 Слика 112. Хостовање сервиса ZelezniceSrbijeRedVoznje на Windows Azure платформи ............................................................................................ 172 Слика 113. Web страница апликације хостоване у облаку која над локалном базом података генерише ред вожње за изабране станице поласка и доласка .............................................................................................................. 173 Слика 114. Web страница апликације хостоване у облаку која над локалном базом података генерише ред вожње за изабрану станицу поласка или доласка ................................................................................................. 174 Слика 115. Прозор апликације „Rangiranje putne mreze” за израчунавање вредности ризика деоница путева ....................................................... 175 Слика 116. Прозор апликације „Rangiranje putne mreze” за класификацију и вишекритеријумско рангирање деоница путева................................. 175 Модел B2B интеграције саобраћајних пословних система 205 10. Списак табела Табела 1. LISI референтни модел ............................................................................. 19 Табела 2. Компарација најзаступљенијих модела података.................................... 48 Табела 3. Конзистентност интероперабилности...................................................... 74 Табела 4. Димензије дељења информација као методе B2B интеграције............. 112 Табела 5. Димензије преузимања информација као методе B2B интеграције...... 114 Модел B2B интеграције саобраћајних пословних система 206 11. Прилози Прилог 1: Design View табеле Saobracajna nezgoda-put из SQL Azure базе података Прилог 2: Data View табеле Vozilo-put из SQL Azure базе података Модел B2B интеграције саобраћајних пословних система 207 Прилог 3: Упити над SQL Azure базом података Упит: Statistika za opasna mesta na putevima Упит: Ukupan broj SN po opasnim mestima na putevima Упит: Broj SN sa poginulim – po opasnim mestima Упит: Broj SN sa teskim telesnim povredama Модел B2B интеграције саобраћајних пословних система 208 Упит: Broj SN sa lakim telesnim povredama Упит: Broj SN sa materijalnom stetom – po opasnim mestima Упит: Ukupan broj poginulih lica po opasnim mestima Упит: Opasna mesta po putnim pravcima П рилог 4 . AD O .N et E ntity D ata M od el базе података P utn o -p ružni p relazi Модел B2B интеграције саобраћајних пословних система 210 12. Биографија аутора Слађана Јанковић рођена је 1978. године у Ужицу где је завршила основну и средњу школу. Дипломирала је на Саобраћајном факултету у Београду 2002. године. Добитник је Годишње награде коју Саобраћајни факултет додељује најбољим студентима у генерацији, као и Стипендије Владе Републике Србије за остварене резултате на студијама. Магистарску тезу под називом „Интероперабилност саобраћајних пословних система заснована на интеграцији B2B сервисно оријентисаних апликација” одбранила је на ФОН-у 2010. године. Од 7.12.2004. Слађана Јанковић запослена је на Саобраћајном факултету у Београду, где је бирана у звање асистента-приправника, a затим асистента за ужу научну област Информатика. Од стране Саобраћајног факултета ангажована је за извођење вежби из предмета: Програмирање и примена савремених програмских пакета (од школске 2004/05. године), Основи пројектовања база података у железничком саобраћају (од школске 2004/05. године), Основи програмирања (од школске 2006/07. године), Програмирање (од школске 2006/07. године), Базе података (од школске 2007/08. године), Базе података у транспорту и комуникацијама (од школске 2009/10), Пројектовање оптимизационих апликација (од школске 2009/10). Приликом евалуације од стране студената, њен рад је више пута био оцењиван највишим оценама. Током досадашњег рада на факултету Слађана Јанковић објавила је више радова у часописима међународног и националног значаја и учествовала на више међународних и домаћих скупова и конференција. Коаутор је једног основног уџбеника чији је издавач Саобраћајни факултет. На Саобраћајном факултету учествовала је као члан пројектног тима у неколико стручних пројеката. Служи се енглеским и руским језиком. Удата је и мајка једног детета. 211 212 213 214