Arhitektura za podporo heterogenih poslovnih modelov s ... · ˇ ˆ Povzetek Spletne storitve ne prinašajo revolucionarnega koncepta in izhajajo iz obstojeih zamisli raunalniških

UNIVERZA V LJUBLJANI Fakulteta za ra�unalništvo in informatiko

MAGISTRSKA NALOGA

Arhitektura za podporo heterogenih poslovnih modelov s spletnimi storitvami

Damjan Kova�

Mentor: prof. dr. Saša Divjak

Somentor: izr. prof. dr. Denis Tr�ek

Ljubljana, februar 2006

��

�

Vsebina KRATICE, OKRAJŠAVE, SIMBOLI................................................................................................................ 5 POVZETEK .......................................................................................................................................................... 6 ABSTRACT........................................................................................................................................................... 8 1. UVOD............................................................................................................................................................... 10 2. SPLETNE STORITVE................................................................................................................................... 13

2.1 XML 1.0 ..................................................................................................................................................... 13 2.2 IMENSKI PROSTORI XML............................................................................................................................. 15 2.3 XML INFOSET ............................................................................................................................................. 16 2.4 SOAP.......................................................................................................................................................... 18 2.5 XML SCHEMA DEFINITION (XSD).............................................................................................................. 21 2.6 WEB SERVICES DESCRIPTION LANGUAGE (WSDL) .................................................................................... 24 2.7 UNIVERSAL DESCRIPTION, DISCOVERY, AND INTEGRATION (UDDI) .......................................................... 25

3. INTEROPERABILNOST (POVEZLJIVOST) SPLETNIH STORITEV ................................................. 29 3.1 SKLOPI SPECIFIKACIJ ................................................................................................................................... 29 3.2 METAPODATKI (METADATA) ...................................................................................................................... 31

3.2.1 WS-Policy ........................................................................................................................................... 31 3.2.2 WS-PolicyAssertions........................................................................................................................... 32 3.2.3 WS-PolicyAttachment ......................................................................................................................... 33 3.2.4 WS-MetadataExchange ...................................................................................................................... 33

3.3 IZMENJAVA SPORO�IL (MESSAGING)........................................................................................................... 34 3.3.1 WS-Addressing ................................................................................................................................... 34 3.3.2 MTOM (Message Transmission Optimization Mechanism) ............................................................... 34 3.3.3 WS-Eventing ....................................................................................................................................... 35

3.4 VARNOST (SECURITY) ................................................................................................................................. 35 3.4.1 WS-Security ........................................................................................................................................ 37 3.4.2 WS-Trust ............................................................................................................................................. 41 3.4.3 WS-SecureConversation ..................................................................................................................... 42 3.4.4 WS-SecurityPolicy .............................................................................................................................. 43 3.4.5 WS-Federation.................................................................................................................................... 44

3.5 ZANESLJIVOST (RELIABLE MESSAGING) ..................................................................................................... 44 3.6 TRANSAKCIJE (TRANSACTIONS) .................................................................................................................. 45

3.6.1 WS-Coordination................................................................................................................................ 46 3.6.2 WS-AtomicTransaction....................................................................................................................... 47 3.6.3 WS-BusinessActivity ........................................................................................................................... 48

4. WS-I BASIC PROFILE 1.0............................................................................................................................ 49 4.1 BASIC PROFILE - SCENARIJI UPORABE ......................................................................................................... 49 4.2 UPORABA BASIC PROFILE 1.0...................................................................................................................... 50

4.2.1 Izdelava spletnih storitev .................................................................................................................... 50 4.2.2 Izdelava odjemalcev spletne storitve .................................................................................................. 51

5. WEB SERVICES ENHANCEMENTS 2.0 (WSE 2.0) ................................................................................. 53 6. POSLOVNI VIDIK SPLETNIH STORITEV .............................................................................................. 55

6.1 ELEKTRONSKO POSLOVANJE ....................................................................................................................... 55 6.1.1 Oblike elektronskega poslovanja........................................................................................................ 56 6.1.2 Dinami�no elektronsko poslovanje..................................................................................................... 57 6.1.3 Storitveno usmerjena arhitektura (SOA) ............................................................................................ 58

7. POSLOVNI MODELI .................................................................................................................................... 61 7.1 RELACIJA MED TEHNOLOGIJO IN DODANO VREDNOSTJO .............................................................................. 62 7.2 VRSTE POSLOVNIH MODELOV...................................................................................................................... 64 7.3 KLASIFIKACIJA POSLOVNIH MODELOV ........................................................................................................ 70 7.4 VPELJAVA POSLOVNIH MODELOV ZA E-POSLOVANJE................................................................................... 71 7.5 DEFINICIJA POSLOVNIH MODELOV ZA VREDNOTENJE SPLETNIH STORITEV .................................................. 74

��

�

8. PROTOTIP ZA KONTROLO DOSTOPA IN VREDNOTENJE (OBRA�UN) SPLETNIH STORITEV.............................................................................................................................................................................. 77

8.1 ANALIZA PROBLEMSKE DOMENE ................................................................................................................. 78 8.1.1 Splošen diagram primera uporabe ..................................................................................................... 78 8.1.2 Diagram stanj..................................................................................................................................... 80 8.1.3 Diagram aktivnosti za proženje (klic) spletnih storitev ...................................................................... 82 8.1.4 Kontrola dostopa do storitve in merjenje (beleženje)......................................................................... 84 8.1.5 Vrednotenje (obra�un) porabe ........................................................................................................... 87 8.1.6 Stati�ni vidik problemske domene ...................................................................................................... 89 8.1.7 Podatkovni model ............................................................................................................................... 94

9. SKLEP ............................................................................................................................................................. 98 ZAHVALA......................................................................................................................................................... 100 PRILOGE .......................................................................................................................................................... 101

PRILOGA 1: PAKET “WSCONTROLUI” (WSCONTROL.UI.WEB) ..................................................................... 102 PRILOGA 1.1: PAKET “WSCONTROLUI” (WSCONTROL.UI.WEB.CONSUMER) ............................................... 103 PRILOGA 2: PAKET “WEBCONTROLS” (WSCONTROL.UI.WEB.WEBCONTROLS)............................................ 104 PRILOGA 3: PAKET “COMMON” (WSCONTROL.COMMON) ............................................................................. 105 PRILOGA 4: PAKET “EXCEPTIONS” (WSCONTROL.EXCEPTIONS) .................................................................... 106 PRILOGA 5: PAKET “EXCEPTIONHANDLING” (WSCONTROL.EXCEPTIONHANDLING) ..................................... 107 PRILOGA 6: PAKET “BUSINESSENTITIES” (WSCONTROL.BUSINESSENTITIES) ................................................ 108 PRILOGA 7: PAKET “CUSTOMTOKENMANAGER” (WSCONTROL.FRAMEWORK.CUSTOMTOKENMANAGER) .. 109 PRILOGA 8: PAKET “SOAPINTERCEPTOR” (WSCONTROL.FRAMEWORK.SOAPINTERCEPTOR) ...................... 110 PRILOGA 9: PAKET “BUSINESSLOGIC” (WSCONTROL.BUSINESSLOGIC) ........................................................ 111 PRILOGA 10: PAKET “EXPRESSIONEVALUATOR” (WSCONTROL.FRAMEWORK.EXPRESSIONEVALUATOR)..... 112 PRILOGA 11: PAKET “DATAHELPER” (WSCONTROL.DATAHELPER) .............................................................. 113 PRILOGA 12: FIZI�NI PODATKOVNI MODEL ZA MS SQL SERVER® 2000 ........................................................ 114 PRILOGA 13: EKRAN S FUNKCIJAMI ZA VLOGO PONUDNIKA STORITEV ............................................................ 115 PRILOGA 14: EKRAN S FUNKCIJAMI ZA VLOGO ODJEMALCA STORITEV............................................................ 116

VIRI IN LITERATURA................................................................................................................................... 117 IZJAVA.............................................................................................................................................................. 122

Kazalo slik Slika 1: Klju�ne tehnologije XML za spletne storitve .......................................................................... 13

Slika 2: Predstavitev dokumenta XML v Infoset abstraktnem modelu................................................. 18

Slika 3: Vzorec izmenjave sporo�il SOAP (zahteva/odgovor) ............................................................. 18

Slika 4: Primer vmesne to�ke SOAP..................................................................................................... 20

Slika 5: Primerjava OO koncepta in XSD............................................................................................. 22

Slika 5: Podatkovni model XML v celoti.............................................................................................. 24

Slika 6: Sporo�ila, operacije, vmesniki, vezi ........................................................................................ 24

Slika 7: Relacije med elementi UDDI................................................................................................... 26

Slika 8: Sklopi specifikacij za interoperabilne storitve ......................................................................... 30

Slika 9: Politika WS-Policy................................................................................................................... 31

Slika 10: Digitalni podpis...................................................................................................................... 36

Slika 11: Razvoj specifikacij WS-Security ........................................................................................... 37

Slika 12: Tipi�en potek sporo�il z varnostnimi žetoni .......................................................................... 38

Slika 13: Protokol WS-ReliableMessaging ........................................................................................... 45

��

�

Slika 14: Transakcijski koordinator ...................................................................................................... 46

Slika 15: Interakcija aplikacij preko svojih koordinatorjev................................................................... 46

Slika 16: Stanja protokola za dokon�anje (completion)........................................................................ 48

Slika 17: Stanja protokola 2PC ............................................................................................................. 48

Slika 18. Izhodni cevovod WSE 2.0...................................................................................................... 53

Slika 19. Vhodni cevovod WSE 2.0...................................................................................................... 54

Slika 20. Osnovne entitete in operacije znotraj modela SOA ............................................................... 60

Slika 21. Hierarhi�na struktura poslovne logike ................................................................................... 62

Slika 22. Poslovni model kot posrednik med tehni�no in ekonomsko domeno .................................... 64

Slika 23. Možna razvrstitev poslovnih modelov ................................................................................... 65

Slika 24. Možna klasifikacija poslovnih modelov ................................................................................ 70

Slika 25. Logi�ni model umestitve poslovnega modela ........................................................................ 75

Slika 26. Konkretna definicija poslovnega modela ............................................................................... 76

Slika 27. Arhitektura programskega prototipa ...................................................................................... 78

Slika 28. Komuniciranje akterjev s sistemom ....................................................................................... 80

Slika 29. Diagram stanj spletne aplikacije ............................................................................................ 81

Slika 30. Proces klica spletne storitve ................................................................................................... 83

Slika 31. Diagram zaporedja za kontrolo dostopa do storitve............................................................... 85

Slika 32. Proces izvajanja vrednotenja (obra�una) porabe.................................................................... 89

Slika 33. Arhitektura programskega prototipa ...................................................................................... 92

Slika 34. Konceptualni podatkovni model ............................................................................................ 95

Kazalo tabel Tabela 1: Vloge v SOAP 1.2 ................................................................................................................. 21

Tabela 2: Osnovni opis klju�nih elementov WSDL.............................................................................. 25

Tabela 3: Imenski prostori znotraj WS-Security ................................................................................... 37

Kazalo primerov Primer 1: Zahteva SOAP preko HTTP.................................................................................................. 19

Primer 2: Odgovor SOAP preko HTTP ................................................................................................ 20

Primer 3: Enostavna shema XML ......................................................................................................... 23

Primer 4: Instan�ni dokument XML ..................................................................................................... 23

Primer 5: Osnovni skelet definicije WSDL........................................................................................... 25

Primer 6: Primer definicije za tModel ................................................................................................ 27

Primer 7: Primer definicije za businessEntity ............................................................................. 27

Primer 8: Poizvedba UDDI ................................................................................................................... 28

Primer 9: Struktura WS-Policy.............................................................................................................. 31

Primer 10: Enostaven izraz z operatorji ................................................................................................ 32

��

�

Primer 11: Zahteva GET ....................................................................................................................... 33

Primer 12: Referenca kon�ne to�ke....................................................................................................... 34

Primer 13: Element wsse:Security ........................................................................................................ 38

Primer 14: Digitalni podpis znotraj sporo�ila SOAP ............................................................................ 39

Primer 15: Šifrirano sporo�ilo SOAP.................................................................................................... 41

Primer 16: Zahteva za X.509 certifikat ................................................................................................. 41

Primer 17: Odgovor z X.509 certifikatom............................................................................................. 42

Primer 18: Deljeni varnostni kontekst................................................................................................... 42

Primer 19: Varnostna politika za overjanje – avtentikacijo .................................................................. 43

��

�

Kratice, okrajšave, simboli B2B – Business-to-Business B2C – Business-to-Consumer BPEL4WS – Business Process Execution Language for Web Services COM – Component Object Model CORBA – Common Object Request Broker Architecture DCOM – Distributed COM HTTP – Hypertext Transfer Protocol IIS – Internet Information Services JMS – Java Message Service MSMQ – Microsoft Message Queuing MTOM – Message Transmission Optimization Mechanism OASIS – Organization for the Advancement of Structured Information Standards PKI – Public Key Infrastructure RMI – Remote Method Invocation RPC – Remote Procedure Call SOA – Service Oriented Architecture SOAP – Simple Object Access Protocol SQL – Structured Query Language UDDI – Universal Description, Discovery and Integration UML – Unified Modeling Language URI – Uniform Resource Identifier W3C – World Wide Web Consortium WSDL – Web Service Description Language WS-I – Web Services Interoperability Organization XML – Extensible Markup Language XSD – XML Schema Definition

��

�

Povzetek Spletne storitve ne prinašajo revolucionarnega koncepta in izhajajo iz obstoje�ih zamisli ra�unalniških komunikacij in porazdeljene obdelave podatkov. Po osnovni definiciji so spletne storitve samostojne programske enote, ki nudijo storitve (“usluge”) preko standardno predpisanega protokola SOAP (Simple Object Access Protocol). Tehni�no gledano so spletne storitve skupek razli�nih tehnologij, ki vklju�ujejo tudi XSD (XML Schema Definition), WSDL (Web Service Description Language), UDDI (Universal Description, Discovery and Integration), katerih osnova je razširljiv ozna�evalni jezik XML (Extensible Markup Language). Jezik XML služi fleksibilnemu podajanju in izmenjavi poljubnih informacij oz. vsebin. Osnovne tehnologije spletnih storitev ne omogo�ajo zadostne povezljivosti (interoperabilnosti) med razli�nimi platformami, heterogenimi aplikacijami in programskimi jeziki. V ta namen so neodvisne organizacije W3C (World Wide Web Consortium), WS-I (Web Services Interoperability Organization) in OASIS (Organization for the Advancement of Structured Information Standards) izdelale in sprejele dolo�ena priporo�ila, specifikacije in standarde, ki se nanašajo na razli�ne vsebinske sklope: � metapodatki, � izmenjava sporo�il, � varnost, � zanesljivost, � transakcije. V za�etnih poglavjih se osredoto�imo na tehni�no poglobljen pregled spletnih storitev, predvsem v smislu povezljivosti – interoperabilnosti. Te podajajo odprti standardi za sodobne porazdeljene aplikacije e-poslovanja, predvsem s podro�ja varnosti (WS-Security) in poslovnih transakcij (WS-AtomicTransactions, WS-BusinessActivity). Priporo�ila in smernice za izdelavo skladnih povezljivih spletnih storitev podaja priporo�ilo WS-I Basic Profile 1.0, ki ga je smiselno upoštevati. Velja poudariti, da je precej specifikacij v fazi nenehnega spreminjanja, dopolnjevanja in izboljšav. Poznavanje tehni�nih specifikacij spletnih storitev predstavlja izhodiš�e za poglobitev v osrednjo vsebino – poslovni vidik spletnih storitev z namenom, kako z njimi ustvariti dodano vrednost. Spletne storitve lahko obravnavamo kot poslovni u�inek, ki ga je potrebno prenesti na trg in kupce. Osnovo predstavlja e-poslovanje oz. njegova izpeljanka dinami�no e-poslovanje. To temelji na uporabi (spletnih) storitev znotraj skupne infrastrukture in odprtih standardov. V ospredje postavlja storitev kot osnovno enoto za u�inkovito interakcijo med poslovnimi subjekti (B2B – business-to-business, B2C – business-to-customer). Storitev naj bi v osnovi predstavljala poslovno funkcijo ali njen del (skupina sorodnih opravkov, s katerim neposredno opravimo nalogo združbe), njeno izvajanje pa je omogo�eno tudi zunanjim poslovnim subjektom. Dinami�no e-poslovanje temelji na konceptu storitveno usmerjene arhitekture (SOA – Service Oriented Architecture). SOA v splošnem pomeni zbirko storitev, ki izvajajo neko aktivnost znotraj enega ali ve� poslovnih procesov oz. v ožjem pogledu znotraj nekaterih poslovnih funkcij. Kot koncept definira poglavitne elemente in njihove medsebojne relacije (spletna storitev, ponudnik, odjemalec storitev). To omogo�a identifikacijo potrebnih elementov prototipa programskega sistema za ustvarjanje dodane vrednosti s spletnimi storitvami. Za njeno ustvarjanje oz. realizacijo je potreben ustrezen

��

�

poslovni model, ki povezuje potenciale tehnologije z realiziranimi ekonomskimi u�inki oz. dodano vrednostjo. V literaturi obstaja veliko definicij poslovnih modelov, najbolj splošna pravi, da je poslovni model mehanizem za poslovanje – na kakšen na�in in katere poslovne u�inke (izdelke, storitve) izdelovati oz. ponujati, da z njimi podjetje ustvarja dodano vrednost. Nekateri izmed množice poslovnih modelov, predvsem transakcijski in naro�niški, so uporabni znotraj arhitekture SOA. Za boljše razumevanje dolo�enih vrst poslovnih modelov je smiselna tudi njihova klasifikacija glede na razli�ne vidike. Poslovni modeli ne podajajo neposredne povezave med spletnimi storitvami in dodano vrednostjo, izvedba je odprta. Tu je glavni prispevek pri�ujo�ega dela, kjer je potrebno izdelati logi�ni model kot izhodiš�e za na�rt programskega prototipa za vrednotenje spletnih storitev. Predstavljeno delo povzema oz. se naslanja na obstoje�e študije in raziskave, ki se ti�ejo spletnih storitev, dinami�nega e-poslovanja, storitveno usmerjene arhitekture in poslovnih modelov. Zanimivo je podro�je, ki se osredoto�a na uvajanje dinami�nega e-poslovanja in spletnih storitev v obstoje�e poslovanje podjetja, ki ponuja nekatere uporabne prijeme za temo naloge. Pri zasnovi logi�nega modela poslovnega modela, kot vmesnega �lena med spletnimi storitvami in dodano vrednostjo, ponujajo dobro izhodiš�e viri, ki se ti�ejo predvsem dolo�enih parametrov kakovosti (QoS – Quality of Service) spletnih storitev in razli�nih metrik za merjenje in nadzor izvajanja, kot tudi varnostnih dejavnikov. Zasnovani logi�ni model smiselno povezuje potrebne gradnike (poslovni modeli, spletne storitve, ponudnik storitev, odjemalec storitev, dodana vrednost) v zaokroženo celoto in je osnova za na�rt programskega prototipa. Programski prototip kot glavni prispevek tega je na�rtovan z modelirnim jezikom UML (Unified Modeling Language). V osnovi temelji na transakcijskem in naro�niškem poslovnem modelu. Po principu koncepta SOA vsebuje razli�ne vloge, poudarek pa je tudi na varnosti. Sistem okvirno pokriva ve� sklopov oz. funkcij: imenik spletnih storitev, delo z uporabniki, merjenje porabe in agregacija podatkov, kontrola dostopa, obra�un porabe spletnih storitev, generiranje poro�il. Sistem je zasnovan modularno na programski platformi .NET v programskem jeziku C# kot dinami�na spletna aplikacija ASP.NET. Kot podatkovni strežnik je uporabljen Microsoft SQL Server 2000. Predstavljeno delo podaja enega od možnih na�inov kako uporabiti tehnologijo spletnih storitev za ustvarjanje dodane vrednosti preko uporabe razli�nih poslovnih modelov. Predvsem gre za princip, da je poslovni model na�in za ustvarjanje dodane vrednosti in je sestavljen iz vrednostnih enot, ki jih je mogo�e meriti in ustrezno ovrednotiti (obra�unati). Programska rešitev je podlaga za nadaljnje izboljšave in razmišljanje na podro�ju uporabe tehnologije spletnih storitev. Klju�ne besede: spletna storitev, odprti standardi, povezljivost, elektronsko poslovanje (e-poslovanje), dinami�no e-poslovanje, storitveno usmerjena arhitektura, dodana vrednost, poslovni model, varnost.

��

�

Abstract Web services do not introduce any novel concepts since they emerge from the existing principles of computer communications and distributed data processing. According to the standard definition, they are autonomous software units, which offer services via SOAP (i.e., Simple Object Access Protocol). From the technical point of view, web services represent a group of heterogeneous technologies, including XSD (i.e., XML Schema Definition), WSDL (i.e., Web Service Description Language), and UDDI (i.e., Universal Description, Discovery, and Integration). All of these are based on XML (i.e., Extensible Markup Language), a language used for handling and exchanging various data. Typically, the basic web services technologies do not facilitate sufficient interoperability among individual computer platforms, heterogeneous applications, and programming languages. Consequently, several recommendations have been put forward and endorsed by some independent organizations, such as W3C (i.e., World Wide Web Consortium), WS-I (i.e., Web Services Interoperability Organization), and OASIS (i.e., Organization for the Advancement of Structured Information Standards). These specifications and standards pertain to: • metadata, • messaging, • security, • reliable messaging, and • transactions. I begin this thesis by examining the technical aspects of interoperable web services. They are presented through open standards for robust e-business applications with the focus on security (i.e., WS-Security) and business transactions (i.e., WS-Atomic Transactions, WS-Business Activity). Whilst the recommendations and guidelines regarding the development of interoperable web services by WS-I Basic Profile 1.0 should also be taken into account, it is worth noting that many specifications are subject to ongoing change and improvement. A study of the business aspect of web services with an emphasis on economic value added, which is the main thrust of our discussion, necessitates the knowledge about the technical specifications of web services. A web service can be regarded as a business effect that needs to be transferred to the market and its customers for which e-business, specifically its derivative dynamic e-business, provides a solid foundation. The latter is based on the use of web services within a common infrastructure and open standards, with a service as the key interaction unit among business subjects (i.e., B2B, business-to-business, and B2C, business-to-customer). It is intended to represent a business function or its part and can be performed by a third-party business subject. The underlying concept of dynamic e-business is that of service-oriented architecture (i.e., SOA), which denotes a collection of services carrying out tasks within one or more business processeses or functions; it defines the core elements (i.e., a web service, a service provider, and a service consumer) and their relationships. This, in turn, enables the identification of the units required for generating added value with web services within a software prototype. The realization of added value is based on the so-called business model, which establishes a connection between the technical potential and the realization of economic value. According to the broadest among numerous definitions that have been offered thus far, a business model is a mechanism for conducting business, i.e. it determines the type of business

��

�

effect (products, services) to be offered on the market to achieve added value. Certain business models, e.g. subscription and transaction models, are applicable within SOA. However, in order to understand specific models, a classification with regard to their different dimensions seems commonsensical. Given that such models do not establish any direct link between web services and added value, the development of which thus remains open, an overarching aim of this thesis is to design a logical model as a starting point for a software prototype for the provision of web services. The author of the paper gives an overall review of the earlier studies and research into web services, dynamic e-business, SOA, and business models. The area which covers the introduction of dynamic e-business and web services into the existing business enterprise, in particular, provides several useful pointers for this study. With regard to the design of logical representation of a business model as a direct connection between web services and added value, the studies on quality parameters of web services (i.e., QoS - Quality of Service) and on various metrics for execution and security control seem valuable. Within the designed logical model, all the fundamental elements (i.e., business models, web services, service provider, service consumer, and added value) are assembled to form a solid integrity underpinning software design. The methodology adopted for designing the software prototype solution is that of UML (i.e., Unified Modeling Language). The prototype is based on the transaction and subscription business models; in accordance with SOA, it incorporates a number of business roles and security aspects of web services. The software solution pertains to several sections and functions, i.e. web services registry, users management, data measuring and aggregation, access control, and report generation. It is designed and implemented as a multitiered application on the .NET platform using the C# programming language and the ASP.NET presentation layer; Microsoft SQL Server 2000 is used as a relational database server. To sum up, this study suggests a feasible solution for the application of web services technology to generate added value by using different business models. It is predominantly based on the assumption that a business model is a method of creating added value and that it is formed of value units that can be measured and properly evaluated. Finally, a software prototype is a sound foundation for further studies and improvements in web service technologies. Key words: web service, open standards, interoperability, electronic business (e-business), dynamic e-business, service-oriented architecture, added value, business model, security.

�� !

�"

1. Uvod Živimo v �asu, kjer smo pri�a nenehnemu razvoju informacijske tehnologije. Ta ho�e zadovoljiti kar najve� zahtev kompleksnega poslovnega sveta. E-poslovanje (angl. e-business) postaja naš vsakdan. Veliko vlogo igra svetovni splet (internet) kot osnovna (angl. core) komunikacijska platforma za izmenjavo informacij in sporo�il. Osnovna ideja sloni na tehnologiji izmenjave informacij prek spletne komunikacijske infrastrukture. Spletne storitve ne prinašajo revolucionarnega koncepta, temve� gradijo na obstoje�ih zamislih porazdeljenega komuniciranja in obdelave podatkov. Tehni�no gledano so spletne storitve skupek razli�nih tehnologij, katerih osnova je razširljiv ozna�evalni jezik XML. Jezik v osnovi predstavlja semanti�no sredstvo za izmenjavo informacij ali vsebin, arhitektura spletnih storitev pa je dejansko bolj kompleksna. Spletne storitve predstavljajo poglavitno tehnologijo za elektronsko poslovanje, lahko jih predstavimo kot osnovne enote dolo�enih poslovnih procesov znotraj ali med podjetji. Dinami�no e-poslovanje pomeni naslednjo generacijo obstoje�ega e-poslovanja, ki se osredoto�a predvsem na integracijo lo�enih informacijskih sistemov med razli�nimi poslovnimi subjekti (B2B, B2C) z uporabo spletnih (internetnih) tehnologij/standardov in skupne infrastrukture s težnjo po optimalni u�inkovitosti. Spletne storitve vsebujejo nabor standardov, ki omogo�ajo povezljivost (interoperabilnost) heterogenih aplikacij in informacijskih sistemov. Vpeljava oz. prevzem spletnih storitev za dinami�no e-poslovanje podjetja je odvisen od razli�nih faktorjev. Chen in ostali [90] so razvili ustrezen simulacijski model glede na razli�ne faktorje (organizacijske, tehnološke) in scenarije, s poudarkom na maksimizaciji u�inkovitosti spletnih storitev. Študija je dobro izhodiš�e za postopno uvajanje dinami�nega e-poslovanja v podjetje. Današnji trend v informacijski tehnologiji je prehod iz podatkovne v storitveno usmerjene integracije informacijskih sistemov. Storitev naj bi v osnovi predstavljala poslovno funkcijo (skupina sorodnih opravkov, s katerimi neposredno opravimo posebno nalogo združbe [81]) ali njen del, njeno izvajanje pa je omogo�eno tudi drugim poslovnim subjektom zunaj podjetja (intergracija B2B, B2C), kar omogo�a racionalizacijo poslovanja (predvsem nižanje stroškov). Storitveno usmerjena arhitektura (SOA) je preko spletnih storitev osnova za dinami�no e-poslovanje. SOA v splošnem pomeni zbirko storitev, ki izvajajo neko aktivnost znotraj enega ali ve� poslovnih procesov oz. v ožjem pogledu znotraj nekaterih poslovnih funkcij. Pogled na spletne storitve in posledi�no dinami�no e-poslovanje poraja vprašanje, kako ustvariti vrednost v ekonomskem smislu? �e ho�emo najti ustrezno povezavo med spletnimi storitvami in dodano vrednostjo, se je potrebno nasloniti na pojem poslovnih modelov. V literaturi obstaja veliko definicij poslovnih modelov, v splošnem pa lahko re�emo, da je poslovni model mehanizem za poslovanje – na kakšen na�in in katere poslovne u�inke (izdelke, storitve) izdelovati oz. ponujati, da z njimi podjetje ustvarja dodano vrednost. Potrebno je definirati in uporabiti take poslovne modele, da z uporabo spletnih storitev prinašajo dodano vrednost. Izhodiš�ni koncept predstavlja storitveno usmerjena arhitektura. Baghadi [91] podaja zanimiv koncept za vpeljavo spletnih storitev v obstoje�e poslovanje podjetja. Predlaga poslovni model z ve� nivoji abstrakcije kot ogrodjem za specifikacijo in izvedbo množice skladnih spletnih storitev v skladu z arhitekturo SOA. Ta abstrakcija dolo�a ustrezne elemente poslovanja na razli�nih nivojih in njihovo medsebojno odvisnost. Ti elementi so poslovni dogodki, vhodi, izhodi, produkcijski sistem, logisti�ni sistem, poslovni subjekti, upravljanje/kontrola in informacijski sistem. Naslednji korak v ogrodju je agregacija atributov naštetih elementov znotraj obstoje�ega poslovanja, ki poteka preko koncepta

�� !

��

dolo�anja dejanske odvisnosti (angl. factual dependency) med atributi elementov. Odvisnost dolo�a skupine (agregate) atributov, katerim lahko dolo�imo enak vmesnik za posamezne poslovne elemente. To posledi�no pomeni, da vsak agregat dolo�a svojo spletno storitev (preko opisnega jezika WSDL). Koncept dejanske odvisnosti omogo�a specifikacijo standardnih vmesnikov, kar je v skladu z arhitekturo SOA in šibko povezanih komunikacijskih to�k. Omenjen model oz. koncept vpeljave ustrezno definiranih spletnih storitev v poslovanje podjetja nudi dobro izhodiš�e za ustvarjanje dodane vrednosti preko storitveno usmerjene arhitekture. Naslednji korak je iskanje primerov in možnosti za obra�un spletnih storitev preko ustreznih poslovnih modelov. Zanimiv aspekt storitveno usmerjene arhitekture je tudi pojem kvalitete storitve (angl. QoS – Quality of Service), ki pomeni stopnjo zadovoljstva uporabnika ob uporabi storitve [92]. Gledano tehni�no je QoS množica mehanizmov za zagotavljanje vnaprej dolo�enih parametrov za kakovost storitve. Avtor Syed [92] podaja predvsem možne rešitve za razli�ne tehnologije prenosa govora preko razli�nih protokolov: � VoIP (Voice over Internet Protocol); � VoFR (Voice over Frame Relay); � VoATM (Voice over Asynchronous Transfer Mode). Sicer omenjene tehnologije niso predmet tega dela, lahko pa v splošnem izluš�imo pomembne parametre, ki so uporabni tudi pri spletnih storitvah na splošno (�eprav so lahko tudi zgoraj omenjene tehnologije implementirane kot spletne storitve). Ti parametri so generi�ne dimenzije kot npr. cena, �as izvajanja, odzivnost, razpoložljivost in zanesljivost. Njihove vrednosti so odvisne od ponudnika storitev, nekatere pa se izra�unajo na podlagi kontrole in merjenja. Dobro izhodiš�e za definicijo parametrov in njihovih vrednosti podajata Keller in Ludwig [93] z merjenjem in kontrolo dolo�ene množice parametrov QoS za spletne storitve, kar predstavlja t.i. pogodbo o kakovosti storitev (angl. Service Level Agreement) med ponudnikom in uporabnikom storitev. Omenjeni �lanek [93] skuša predstaviti generi�no programsko ogrodje za spremljanje parametrov QoS v okviru pogodbe SLA za spletne storitve – WSLA (Web Service Level Agreement). Upravljanje s kakovostjo storitev je osnovano na slede�ih kategorijah informacij: � Metrika virov: informacije so pridobljene neposredno iz virov na strani ponudnika storitev

(npr. strežniki, mrežna oprema, aplikacije). Primer: število klicev, �as izpada, �as delovanja storitev.

� Sestavljena metrika: informacije se pridobijo iz metrik posameznih virov po dolo�enih algoritmih (npr. razli�na povpre�ja, minimum, maksimum). Primer: maksimalen odzivni �as, povpre�na razpoložljivost storitve.

� Parametri SLA: vsak parameter je povezan z z ustrezno metriko in posledi�no pove ali le-ta ustreza predpisanim kriterijem (na strani uporabnika, ponudnika). Vsak parameter se nanaša na dolo�eno metriko, le-ta pa je agregat ene ali ve� ostalih metrik (metrika virov, sestavljana metrika).

� Poslovna metrika: povezuje parametre SLA z ustreznimi poslovnimi vidiki ponudnika in uporabnika storitev.

Generi�no ogrodje je sestavljeno iz posameznih faz, od katerih je pomembno omeniti fazo za merjenje in poro�anje o kakovosti storitev. Pravzaprav je funkcionalnost znotraj faz izdelana preko spletnih storitev, kjer se lo�ijo:

�� !

��

a) Storitev za merjenje: meri vrednosti za posamezne parametre SLA. Ti parametri so npr. �as izvajanja, odzivni �as, razpoložljivost. Vrednosti se dobijo iz merjenja razli�nih virov ali prestrezanja klicev spletnih storitev.

b) Storitev za vrednotenje pogojev: izvaja vrednotenje izmerjenih vrednosti parametrov glede na pogoje definirane v pogodbi SLA. V primeru prekora�itev, se proži ustrezo opozorilo.

Nekatere zna�ilnosti in ideje ogrodja SLA [93], predvsem fazo merjenja dolo�enih parametrov, lahko do neke mera uporabimo za naš sistem vrednotenja spletnih storitev za razli�ne poslovne modele. Sistem mora podpirati osnovne principe storitveno usmerjene arhitekture SOA kot osnovo za ustvarjanje dodane vrednosti – ta se generira preko obra�unavanja porabe spletnih storitev v skladu z razli�nimi poslovnimi modeli. Zanimiv pristop in na�in vrednotenja spletnih storitev v hibridnih okoljih, kjer so storitve te�ejo na mobilnih ali fiksnih ra�unalniških virih, podaja �lanek [94]. Osnovo predstavlja arhitektura, ki temelji agentih. Združuje razli�ne vrste agentov – uporabniki, ponudniki, storitve in viri. Agenti so samostojne programske entitete (enote), ki so usmerjene k cilju, so avtonomne, znajo sodelovati med seboj ter sprejemati dolo�ene odlo�itve. Arhitektura predvideva agente, ki skrbijo za spletne storitve in vire ter njihovo optimalno izkoriš�enost. Optimalni izvajalni plan spletnih storitev se dolo�i preko razli�nih kriterijev (cenovni model izvajanja, zanesljivost) po posameznih virih. Vsak vir ima seznam atributov in omejitev, ki jih algoritem upošteva. Prav tako ima tudi vsaka storitev seznam atributov in zahteve po virih, da se lahko izvede. Dolo�ena pravila služijo kot na�in obra�unavanja za našo rešitev, predvsem vrednotenje kriterijev za izvajanje storitve na dolo�enem viru, �e le ta izpolnjuje ustrezne pogoje. Zanimiva ideja je podana tudi v �lanku [95], ki podaja model za ponavaljajo�e spremljanje izvajanja poslovnih procesov. Ta je sestavljen iz množice komponent, ki so implementirane kot spletna storitev – CAWS (Continuous Auditing Web Service). Ta je v interakciji s poslovnimi procesi, ki so opisani z jezikom BPEL4WS (Business Process Execution Language for Web Services). To je jezik za formalno specifikacijo poslovnih procesov in protokolov za interakcijo med posameznimi spletnimi storitvami. Gre predvsem za na�in modeliranja poslovnih procesov s povezovanjem razli�nih spletnih storitev in spremljanje njihovega izvajanja – merjenja in agregacija vhodnih in izhodnih podatkov preko posebnega mehanizma, ki je tudi spletna storitev (CAWS). Za naš model oz. rešitev je uporabna predvsem ideja za možne na�ine merjenja in agregiranja podatkov kot osnova za vrednotenje spletnih storitev. Uporaben pogled in koncept glede varnosti pri merjenju podatkov za vrednotenje podaja �lanek [97]. V splošnem ne obstaja nek generi�en uporaben model vrednotenja (obra�unavanja) spletnih storitev, predvsem v smislu navezave in upoštevanja poslovnih modelov. Uvod podaja samo možna izhodiš�a za nadaljno razmišljanje. V nadaljevanju skušamo osnovati splošen model vrednotenja spletnih storitev, ki podpira razli�ne poslovne modele. Pri tem uporabimo nekatere ideje in prijeme iz navedenih virov in �lankov. Izhajamo iz tehni�nega ozadja spletnih storitev (pregled razli�nih standardov in sklopov sprecifikacij WS-*) z osredoto�enjem na podro�je varnosti. Osnovo za vrednotenje predstavljajo razli�ni poslovni modeli.

��#$��%��

��

2. Spletne storitve Spletne storitve so sodoben na�in porazdeljenega ra�unalništva na svetovnem spletu. So evolucija starejših komponentnih tehnologij za porazdeljeno komunikacijo, kot npr. oddaljeno klicanje procedur – RPC (Remote Procedure Call), predmetno zasnovani RPC, kot so DCOM (Distributed Component Object Model), CORBA (Common Object Request Broker Architecture), Java RMI (Remote Method Invocation), sporo�ilni sistemi (MSMQ, MQSeries, JMS). Vse tehnologije so še vedno v rabi, vendar so glede na zasnovo precej omejene, predvsem kar se ti�e odprtosti in povezljivosti (angl. interoperability), kar je osnovna zahteva in težnja poslovnih rešitev. To se kaže predvsem v dveh aktualnih podro�jih: intergracija (povezava) obstoje�ih poslovnih aplikacij – EAI (Enterprise Application Intergration) in povezave med podjetji – B2B (Business-to-Business). Sicer obstaja mnogo razli�nih definicij spletnih storitev, vendar so v osnovi približno enake. Spletna storitev je samostojna programska enota [3, 4]: � ki nudi neko storitev preko odprtega standardnega spletnega protokola – protokol SOAP

(Simple Object Access Protocol); � njeni podatki so predstavljeni v predpisanem standardu (ustrezen tipski sistem), za

predstavitev se uporabljajo sheme XML – standard XSD (XML Schema Definition); � zunanjemu svetu je opisana preko standardnega opisnega jezika, ki opisuje vmesnike in

njeno obnašanje; opisni jezik temelji na XML in se imenuje WSDL (Web Services Description Language);

� na voljo je kon�nim uporabnikom preko posebnega mehanizma za odkrivanje (lociranje); mehanizem se imenuje UDDI (Universal Discovery Description and Intergration).

Zna�ilnost spletnih storitev je “pogodba preko žice” (angl. wire contract), ki je klju�ni vmesnik za komunikacijo med aplikacijami. Vmesnik je definiran na razli�nih tehnologijah, vsaka pa predstavlja mozaik znotraj platforme spletnih storitev. Klju�ne tehnologije XML prikazuje slika 1.

#��&��'(%��)%�*��+,-��$��%�� V nadaljevanju sledi kratek opis posameznih gradnikov spletnih storitev, podrobnejši pregled specifikacij in priporo�il pa je vsebovan po posameznih poglavjih.

2.1 XML 1.0 Jezik XML (eXtensible Markup Language) [1, 2] je bil zasnovan z namenom definicije novih formatov dokumentov za svetovni splet - WWW (World Wide Web) in izhaja iz jezika

Ži�ni protokoli (Wire protocols) Opisni jeziki (Description languages)

Mehanizmi za odkrivanje (Discovery mechanisms)

Serializirana sporo�ila

Sestavljanje, vezava na transportni protokol

Prenosljiv sistem podatkovnih tipov

Opis kon�nih to�k

Register kon�nih to�k UDDI

WSDL

XSD

SOAP

XML 1.0 + Namespaces

��#$��%��

��

SGML (Standard Generalized Markup Language). XML je meta-jezik: namenjen je opisu podatkov in je osnova za definicijo drugih jezikov. Je tekstovno orientiran format za opisovanje strukture dokumentov s pomo�jo ozna�evalnih zaznamkov (angl. markup tag) – besede znotraj znakov “<” in “>”. Zaznamki niso v naprej definirani. XML standardizira organizacija W3C. Poudariti velja, da XML ni programski jezik in sam po sebi ne zna ni�esar narediti. Namenjen je shranjevanju, strukturiranju, preverjanju in pošiljanju razli�nih podatkov, ki so lahko strukturirani ali nestrukturirani. �e v splošnem podamo definicijo kaj XML je: � je na�in zapisa podatkov in informacij; � je prosto razširljiv (poljubni zaznamki); � programsko in platformno neodvisen; � je tekstovni format (možnost enostavnega urejanja); � osnova za definicijo drugih ozna�evalnih jezikov (WML, XSD), protokolov; � tehnologija za prenos in manipulacijo podatkov. Predstavitev podatkov v jeziku XML podaja priporo�ilo organizacije W3C [2]. Sintaksa XML je relativno preprosta, nata�no podana, nedvoumna in zelo stroga v primerjavi z ozna�evalnim jezikom HTML. Osnovni kontrukti jezika XML so elementi in atributi. Primer enostavnega dokumenta XML, ki vsebuje podatke o osebi (vrstice so oštevil�ene zaradi lažje preglednosti in niso del dokumenta XML): 1 <?xml version=”1.0” encoding=”utf-8” ?> 2 <oseba emso=”2212322645432”> 3 <ime>Janez</ime> 4 <priimek>Novak</priimek> 5 <naslov> 6 <ulica>Pod topoli 22</ulica> 7 <posta>1000 Ljubljana</posta> 8 </naslov> 9 </oseba>

� vrstica 1: deklaracija XML (opisuje verzijo, znakovno kodiranje, ustreza specifikaciji

XML 1.0 + Namespaces); � vrstica 2: korenski element <person>, ki vsebuje atribut emso; � vrstica 3, 4, 5: podrejeni elementi; � vrstica 9: konec korenskega elementa. Še nekaj pravil glede skladnje XML: � deklaracija XML je posebnost definirana v specifikaciji, ni nujna; �e obstaja, nima

zapiralnega zaznamka; � vsak dokument XML ima samo en korenski element, ki je sestavljen iz para: odpiralni,

zapiralni zaznamek, vsi ostali elementi so podrejeni korenskemu elementu (pravilno gnezdenje podrejenih elementov);

� elementi vedno vsebujejo odpiralni in zapiralni zaznamek, so razširljivi, imajo relacije, nosijo vsebino, vsebino nosijo tudi atributi;

� zaznamki XML so velikostno ob�utljivi (male, velike �rke); � vrednosti atributov morajo biti vedno obdane v narekovaje (dvojni ali enojni). Standard XML 1.0 vpeljuje princip dobre oblikovanosti (angl. well-formedness) dokumentov, ki pomeni, da je dokument zapisan v pravilni skladnji XML.

��#$��%��

��

2.2 Imenski prostori XML Imenski prostor (angl. namespace) je množica imen, kjer so vsa posamezna imena unikatna in ni možno, da ima en imenski prostor dvoje enakih imen. Imenske prostore sre�amo v vseh sodobnih programskih jezikih (C++, C#, Java,..). Znotraj XML se imenski prostori uporabljajo za prepre�evanje konfliktov pri imenovanju elementov in atributov. Sama specifikacija XML 1.0 ne vsebuje imenskih prostorov, zato so se pojavile težave, ker so vsa imena znotraj dokumentov XML pripadala globalnemu imenskemu prostoru. Poglejmo primer znotraj dveh dokumenotv XML 1.0 in konflikte zaradi dvoumnosti. a) Dokument XML, ki opisuje študenta na fakulteti: <student> <id>239929</id> <ime>Jakob Novak</ime> <jezik>Java</jezik> <ocena>9.5</ocena> </student>

b) Dokument XML, ki opisuje študentko, ki se u�i španski jezik: <student> <id>239929</id> <ime>Lucija Marolt</ime> <jezik>Španski</jezik> <ocena>4.0</ocena> </student>

Znotraj obeh dokumentov so enaki elementi, vendar nosijo razli�ne informacije. V primeru a) element <id> pomeni vpisno številko, v primeru b) pa EMŠO. Poleg tega tudi elementa <jezik> in <ocena> ne nosita primerljivih vrednosti. Za raz�lenjevalnik XML sta dokumenta popolnoma enaka, ker jih ne more razlikovati po samih vrednostih elementov. Kako torej odpraviti konflikt zaradi možnosti nerazlikovanja? Rešitev je uporaba razli�nih imenskih prostorov za primer a) in b). Specifikacijo XML 1.0 je potrebno razširiti še s podporo imenskih prostorov, tako dobimo specifikacijo “XML 1.0 + Namespaces” [6], ki je osnova za ostale tehnologije XML. Konflikt lahko rešimo na dva na�ina: s privzetim imenskim prostorom, ki velja za vse podrejene elemente in predponami, ki dolo�ajo pripadnost dolo�enemu imenskemu prostoru. Na ta na�in je možno enoli�no razlikovati dokumenta a) in b). � Privzeti imenski prostor a) <student xmlns=”http://www.it.edu/stud”>

<id>239929</id> <ime>Jakob Novak</ime> <jezik>Java</jezik> <ocena>9.5</ocena> </student>

b) <student xmlns=”http://jezik-sola.si”>

<id>239929</id> <ime>Lucija Marolt</ime> <jezik>Španski</jezik> <ocena>4.0</ocena> </student>

��#$��%��

��

� Predpona, ki dolo�a pripadnost imenskemu prostoru a) <d:student xmlns:d=”http://www.it.edu/stud”>

<d:id>239929</d:id> <d:ime>Jakob Novak</d:ime> <d:jezik>Java</d:jezik> <d:ocena>9.5</d:ocena> </d:student>

b) <j:student xmlns:j=”http://jezik-sola.si”> <j:id>239929</j:id> <j:ime>Lucija Marolt</j:ime> <j:jezik>Španski</j:jezik> <j:ocena>4.0</j:ocena> </j:student>

Kot je razvidno iz primerov, je imenski prostor definiran z posebnim atributom xmlns: � definira imenski prostor elementa; � imenski prostor je unikatni niz in ne nek dejanski vir; � povezuje predpono s kvalificiranim imenom imenskega prostora; � vedno se nahaja v odpiralnem zaznamku; � skladnja: xmlns:predpona=”imenski prostor”, pripadnost se prenese na podrejene

elemente; � kvalificirano ime (angl. Qualified Name – QName) elementa je sestavljeno iz dveh delov:

ime imenskega prostora in lokalnega imena oz. QName = <predpona>:<lokalno ime>; � xmlns je druga�en atribut od ostalih, njegova vrednost se ne preverja. Velja, da privzete imenske prostore lahko razveljavimo, tako da postavimo atribut xmlns=”” znotraj katerega od podrejenih elementov. Predpono lahko redefiniramo znotraj katerega od podrejenih elementov, vendar velja samo znotraj elementa. Primer: <j:student xmlns:j=”http://jezik-sola.si”> <j:id>239929</j:id> <j:ime xmlns:j=”http://druga-jezik.sola.si”>Lucija Marolt</j:ime> <j:jezik>Španski</j:jezik> <j:ocena>4.0</j:ocena> </j:student>

XML 1.0 + Namespaces zahteva, da so imenski prostori podani v obliki URI (Uniform Resource Identifier), definirani v RFC 2396. Glede na specifikacijo obstajajo dve obliki URI (obe se lahko uporabljata za imenovanje imenskih prostorov): a) URL (Uniform Resource Locators), primer: http://www.it.edu/stud; b) URN (Uniform Resource Names), primer: urn:www-it-edu:stud. Pomembno je, da je niz znakov URI, ki ozna�uje imenski prostor, edinstveno (unikatno) ime. Najve�krat se za URI imenskih prostorov uporabi spletna domena podjetja (organizacije).

2.3 XML Infoset Podatkovni model XML je definiran preko XML Information Set-a (Infoset). Predstavlja abstraktno predstavitev dokumenta XML v obliki hierarhi�nega drevesa. Dokument je sestavljen iz množice informacijskih delov, ki so abstraktna predstavitev njegovih komponent. Ti deli so: dokument, elementi, atributi, ukazi za procesiranje, komentarji, znaki, imenski prostori, neraz�lenjene entitete. Bistvo XML Infoset-a je definicija pomembnih informacij znotraj dokumenta XML (informacijska vrednost). Npr. infoset ne razlikuje med dvema

��#$��%��

��

oblikama za prazen element: <test></test> je po XML infoset-u enakovredno <test/>. Podrobnejša specifikacija je opisana v [7, 8]. Infoset je sestavljen iz elementov in atributov. Najpomebnejšo lastnost predstavlja element [children], ki vsebuje seznam vseh informacijskih delov, ki so neposredni nasledniki korenskega dela. Eden od teh delov je vedno izhodiš�ni (korenski) element dokumenta; vsebovan je v lastnosti [document element]. Osnovno infomacijsko vrednost znotraj infoseta predstavljajo elementi in atributi. Elementi lahko vsebujejo enostavne ali strukturirane vrednosti, atributi pa samo enostavne. Element (element information item) vsebuje lastnosti: � [parent]: pove kdo je nadrejeni del elementa; � [children]: seznam neposrednih naslednikov; � [local name]: lokalno ime elementa; � [namespace name]: imenski prostor (je prazno, �e element ne pripada imen. prostoru); � [attributes]: seznam atributov (neurejen seznam). Atribut (attribute information item) vsebuje lastnosti: � [local name]: lokalno ime atributa; � [namespace name]: imenski prostor (je prazno, �e atribut ne pripada imen. prostoru); � [normalized value]: enostavna vrednost atributa; � [owner element]: kateremu elementu pripada. Tekstovna vrednost elementov in atributov je podana preko znakov (characters information item), ki vsebuje lasnosti: � [parent]: element, ki mu vrednost pripada; � [character code]: vrednost znaka preko ISO 10646 kodne tabele. Naslednji enostavni dokument XML lahko predstavimo v obliki infoset-a, kot ga prikazuje slika 2. <?xml version=”1.0” encoding=”UTF-16” ?> <ns:student xmlns:ns=”urn:studenti”> <ns:id>239929</ns:id> <ime>Lucija Marolt<ime> <ns:jezik>Španski</ns:jezik> <ns:ocena xmlns:ns=”urn:ocene”>4.0</ns:ocena> </ns:student>

��#$��%��

��

#��&��!��!�'��%��+,-�.%/��%��!��'

Za procesiranje dokumentov XML preko abstraktnega modela obstaja vrsta tehnologij, ki se razlikujejo glede na�in dostopa in predstavitve informacij: � DOM (Document Object Model): celotni dokument XML se raz�leni v drevo; preko

vozliš� znotraj drevesa je možno branje in modifikacija dokumenta XML. Ve� o programskem vmesniku podaja vir [59].

� SAX (Simple API for XML): v nasprotju z DOM, se ne naloži celotni dokument, ampak se dokument procesira (bere) sekven�no po posameznih delih (vozliš�ih). Ob branju vozliš�a se proži dogodek, ki obdela informacijo.

� XPath: poizvedovalni (angl. query) jezik za iskanje delov in vzorcev znotraj dokumenta XML.

� XSL (XML Stylesheet Language): jezik za pretvarjanje dokumentov XML. Omogo�a definiranje pravil za tranformacijo izvornega v ponorno drevo. Transformacija se dolo�i preko povezav med vzorci, ki so izrazi XPath, in defniranimi predlogami (angl. templates). Ve� o jeziku XSLT podaja vir [60].

2.4 SOAP SOAP [9] je standardni komunikacijski protokol za spletne storitve. Sintaksa SOAP je opisana z jezikom XML, semantika pa je podana s shemami in imenskimi prostori. XML se uporablja za opis podatkov in protokolarnih elementov. V splošnem protokol SOAP definira na�in pošiljanja sporo�il XML iz to�ke A v to�ko B; posledni�no (vendar ne obvezno) tudi pošiljanje odgovora iz to�ke B v to�ko A (model zahteva/odgovor – angl. request/response) – slika 3.

#��&0��%��$�(��#1��2��)��3!*��4

��'%��$��

��

��

'�%&��'!�%��

��'!�%�

��

'�%&��'!�%��

�!

��

��

��

'�%&��'!�%��

��

��

'�%&��%�

��%�

� ��

��

� ��

-'��,��

� ��

5$�%��

� ��

��"

#1��$ ��

#1��$��%��

#1��$�(��

�

�#1��!*��

��#$��%��

��

Pošiljanje sporo�il je omogo�eno preko sporo�ilnega ogrodja XML, ki je: � razširljivo: z razli�nimi razširitvami, ki omogo�ajo varnost, usmerjanje, zanesljivost; � lahko uporablja razli�ne transportne mrežne protokole: najbolj obi�ajen je HTTP

(HyperText Transfer Protocol), lahko pa tudi SMTP (Simple Mail Transfer Protocol), TCP (Transmission Control Protocol), MSMQ (Microsoft Message Queuing), MQ Series;

� neodvisno od programskih modelov: SOAP ni v osnovi samo protokol RPC, ampak ponuja razli�ne vzorce izmenjave sporo�il (MEP – Message Exchange Pattern).

Sporo�ilo (ogrodje) SOAP je sestaljevno iz ve�ih klju�nih elementov (vsi so iz imenskega prostora http://schemas.xmlsoap.org/soap/envelope/ - velja za SOAP verzija 1.1 [10]): � Ovojnica (angl. envelope): je vedno korenski element sporo�ila, vsebuje vse ostale

elemente. � Glava (angl. header): opcijski element, vsebuje dodatne kontrolne informacije za

procesiranje sporo�ila (overjanje – avtentikacija, usmerjanje,..). Elementi znotraj tega elementa se imenujejo zaglavni bloki (angl. header blocks).

� Telo (angl. body): vsebuje glavno informacijo sporo�ila (podatki), lahko vsebuje poljubno število elementov iz razli�nih imenskih prostorov.

� Napaka (angl. fault): element znotraj telesa v primeru, �e pride do napake. Vsebuje elementa faultcode (klasifikacija napake s kvalificiranim imenom) in faultstring (opis napake) ter opcijsko detail (podroben opis za diagnostiko).

Vzorec sporo�ila SOAP je v splošnem naslednji: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header>   </soap:Header> <soap:Body>  </soap:Body> </soap:Envelope>

Primer konkretnega sporo�ila SOAP (zahteva in odgovor) podajata primera 1 in 2 (spodaj leže�i komunikacijski protokol je HTTP). Gre za klic enostavne spletne storitve Multiply(a,b), ki vra�a produkt dveh števil. POST /webservices/numbers.asmx HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: "http://damjan/webservice/Multiply" Content-Length: 316 Connection: Keep-Alive Host: damjan:8080 <?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <Multiply xmlns="http://damjan/webservice"> <a>5</a> <b>4</b> </Multiply> </soap:Body> </soap:Envelope>

��&6�)��#1��$��788�

��#$��%��

�"

HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: 351 <?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <MultiplyResponse xmlns="http://damjan/webservice"> <MultiplyResult>20</MultiplyResult> </MultiplyResponse> </soap:Body> </soap:Envelope>

��&1!*��#1��$��788�

Trenutna verzija protokola na trgu je SOAP 1.2 (obstaja kot priporo�ilo organizacije W3C) [12], ki precej razširja predhodno verzijo SOAP 1.1 [10]. SOAP 1.2 prinaša nov razširitveni mehanizem, ki temelji na konceptu lastnosti in vzorcev za izmenjavo sporo�il (MEP – Message Exchange Patterns) - dolo�a vzorce za izmenjavo sporo�il med vmesnimi to�kami (vozliš�i) SOAP. Verzija SOAP 1.2 nudi naslednje nove zna�ilnosti: a) Vmesne to�ke in pot sporo�il Sporo�ilo lahko potuje do kon�nega prejemnika preko vmesnih to�k, ki opravljajo dodatno procesiranje na poti (pomagajo ali dopolnjujejo kon�nega uporabnika). Vmesna to�ka isto�asno predstavlja sprejemnika in pošiljatelja sporo�il SOAP. Slika 4 prikazuje primer vmesne to�ke, ki overja (avtenticira) uporabnika in preverja integriteto sporo�ila.

#��&��%��(��#1��

b) Ovojnica in bloki Sporo�ilo SOAP je sestavljeno iz ovojnice, ki je dejansko dokument XML (kot SOAP 1.1). Posebnost je, da sporo�ilo lahko vsebuje ni� ali ve� protokolnih glav spodaj leže�ega protokola (HTTP) – npr. naslov kon�ne to�ke. Ovojnica SOAP lahko vsebuje ni� ali ve� glav SOAP, ki so lahko metapodatki, podatki za vmesne to�ke ali dolo�eni aplikacijski podatki za kon�no to�ko. c) Vloge in naslavljanje Glave SOAP se usmerjajo na vmesne to�ke preko attribute role, ki predstavlja neko vlogo v obliki URI. Vsaka vmesna to�ka ima lahko ni� ali ve� vlog. Specifikacija SOAP 1.2 [11, 12] definira tri posebne vloge, ki jih prikazuje tabela 1.

Kratko ime Ime Opis next “http://www.w3.org/2003/05/soap-

envelope/role/next” Vsaka vmesna in kon�na to�ka igra vlogo.

none “http://www.w3.org/2003/05/soap-envelope/role/none”

Nobena to�ka ne igra vloge.

ultimateReceiver “http://www.w3.org/2003/05/soap- Vlogo igra samo kon�na

� � 1��*�%��%�$ ��

0��%��%��%��(��

�%(%�$��%��

��#$��%��

��

envelope/role/ultimateReceiver” to�ka.

8��&0�*��#1�� Atribut role ima lahko lahko tudi druga�ne vrednosti, kot jih prikazuje tabela 1. Primer: <ns:myHeaderBlock role=”http://www.host.com/logging”/>. V primeru, da je atribut role izpuš�en, je vrednost atributa enaka ultimateRecevier, ki vedno predstavlja kon�no to�ko. Poudariti velja, da je telo SOAP vedno namenjeno kon�ni to�ki. d) Procesni model Pri procesiranju sporo�ila SOAP mora vmesna/kon�na to�ka upoštevati ve� logi�nih korakov: 1) Ugotoviti, katere vloge to�ka igra (lahko ugotovi vnaprej, s pregledom sporo�ila, vloge so

lahko razli�ne za razli�na sporo�ila). 2) Preveriti ali lahko razume vse obvezne bloke (prekiniti procesiranje, �e jih ne). 3) Procesirati bloke, ki so naslovljeni nanjo (glave in telo, �e je kon�na to�ka). 4) Odstraniti bloke, ki jih je sprocesirala. 5) Dodati bloke, �e je potrebno (rezultat procesiranja; podatke, ki jih zahtevajo to�ke). 6) Poslati sporo�ilo naslednji to�ki. e) Razširitveni mehanizem Ta mehanizem omogo�a razširljivost sporo�il SOAP z zaglavnimi bloki. V glavo se lahko dodajo poljubni bloki, ki lahko veljajo za: � aplikacijsko semantiko (prenos specifi�nih aplikacijskih podatkov); � protokolarno semantiko (varnost, zanesljivost, transakcije,..); � bloki se lahko verzionirajo preko razli�nih imenskih prostorov; � neznani bloki se ignorirajo, razen �e so obvezni (pomembno procesiranje se mora izvesti); � blok je obvezen, �e vsebuje atribut mustUnderstand=”true”, npr.: <ns:myHeaderBlock

mustUnderstand=”true”/>.

2.5 XML Schema Definition (XSD) Standard XML Schema [13] definira sistem podatkovnih tipov in strukturo dokumentov XML. Brez sistema podatkovnih tipov je dokument XML navadna tekstovna datoteka (vsi podatki so tekstovni oz. predstavljajo nize). XML Schema je nadomestil starejši sistem DTD (Data Type Definition), saj ponuja bistveno ve�jo funkcionalnost in fleksibilnost, poleg tega uporablja skladnjo XML. Dokument XML, ki je skladen s pripadajo�o shemo, je instan�ni dokument in je hkrati tudi veljaven (je razširitev pojma dobra oblikovanost, ki upošteva samo pravila skladnje XML 1.0 + Namespaces). Veljaven dokument pomeni, da je skladen in preverjen na podano shemo. S pojmom instan�ni dokumet se ponuja povezava z objektno-orientiranim (OO) konceptom (razred-objekt) - slika 5.

��#$��%��

��

#��&��11�%��$��%+#9

Standard XML Schema nudi sistem vgrajenih podatkovnih tipov in sicer: � primitivni podatkovni tipi (string, integer, int, boolean, byte, double, date,..),

skupno 19; � izpeljani podatkovni tipi (normalizedString, unsignedInt, ID, token,..), skupno 25. Vsi tipi so iz imenskega prostora http://www.w3.org/2001/XMLSchema. Vsak podatkovni tip ima definiran vrednostni in leksikalni prostor. Vrednostni prostor opisuje množico vrednosti, ki jih instanca tipa lahko zasede. Npr. vrednostni prostor tipa byte vsebuje vrednosti od -128 do 127, tipa boolean pa vrednosti “true” in “false”. Leksikalni prostor opisuje možne na�ini serializacije (predstavitve) vrednosti. Npr. vrednost true tipa boolean je lahko predstavljena kot “true” ali “1”, vrednost false pa kot “false” ali “0”, vrednost 10 tipa double je lahko predstavljena “10”, “10.0”, “10.000”, “0.01E3”. Lahko vidimo, da je velikost leksikalnega prostora vedno ve�ja ali enaka od velikost vrednostnega prostora podatkovnega tipa. XML Schema omogo�a definicijo enostavnih in kompleksnih tipov, dedovanje (kot pri OO) z razširjanjem in dedovanje z omejitvijo. Korenski element sheme XML je vedno element xs:schema (xs ozna�uje imenski prostor http://www.w3.org/2001/XMLSchema). Podrobnejši opis pravil je podan v [13, 14]. a) Definicija preprostih tipov Vsebujejo lahko samo tekstovno vsebino, nimajo podrejenih elementov ali atributov. Lo�imo definicijo elementov in atributov. � definicija preprostega tipa za element: <xs:element name=”ime” type=”tip” />.

Primer: <xs:element name=”author” type=”xs:string” />. � definicija preprostega tipa za atribut: <xs:attribute name=”ime” type=”tip” />.

Primer: <xs:attribute name=”id” type=”xs:int” />. b) Izpeljava preprostih tipov Izpeljava je možna iz obstoje�ih tipov (primitivni, izpeljani) sheme XSD ali iz svojih tipov. Izpeljava vedno poteka z omejevanjem vrednostnega prostora osnovnega tipa (element xs:simpleType). Omejevalnih atributov je ve�. Primer izpeljave novega tipa myInteger: <xs:simpleType name=”myInteger”> <xs:restriction base=”xs:integer”> <xs:minInclusive value=”10000” /> <xs:maxInclusive value=”99999” /> </xs:restriction> </xs:simpleType>

Razred Shema XML

Objekti

Instan�ni dokumenti XML

��#$��%��

��

c) Definicija kompleksnih tipov Kompleksni tipi vsebujejo podrejene elemente, za izpeljavo rabi element xs:complexType. Skladnja je slede�a: <xs:element name=”ime”> <xs:complexType>.. vsebina elementa ..</xs:complexType> </xs:element>

Primer: <xs:element name=”employee”> <xs:complexType> <xs:sequence> <xs:element name=”firstname” type=”xs:string”/> <xs:element name=”lastname” type=”xs:string”/> </xs:sequence> </xs:complexType> </xs:element>

Sledi primer zelo enostavne sheme XML (primer 3) in njen veljavni instan�ni dokument XML (primer 4). <?xml version="1.0"?> <xs:schema targetNamespace="http://osebe.com/oseba.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="oseba"> <xs:complexType> <xs:sequence> <xs:element name="ime" type="xs:string" /> <xs:element name="priimek" type="xs:string" /> </xs:sequence> <xs:attribute name="id" type="xs:int" /> </xs:complexType> </xs:element> </xs:schema>

��&:%��%��)��+,-

<?xml version="1.0"?> <oseba xmlns="http://osebe.com/oseba.xsd" id="99"> <ime>Janez</ime> <priimek>Novak</priimek> </oseba>

��&.%��%(%�!�'��%�+,-

XML Schema uvaja koncept PVSI - Post Schema Validation Infoset, ki predstavlja tipsko znan podatkovni model. XSD procesor sprejeme XML Infoset kot vhod in ga ob preverjanju veljavnost transformira v obliko PSVI, ki predstavlja orginalni vhodni infoset z dodanimi informacijami in lastnostmi. Elementi in atributi postanejo strogo tipizirani (imajo znan podatkovni tip). Podatkovni model XML Infoset z razširitvijo XML Schema prikazuje slika 5.

��#$��%��

��

#��&�!��%��!��+,-��

2.6 Web Services Description Language (WSDL) Tehnologija XML preko spletnih storitev omogo�a dostop do razli�nih virov (angl. resources), kot so razli�ne aplikacije in zbirke podatkov. Arhitektura spletnih storitev to omogo�a preko standardnih mehanizmov za izmenjavo sporo�il XML. Spletna storitev oz. v splošnem servis deluje kot posrednik med sporo�ili XML in virom; ponuja neke vrste vmesnik XML, ki ga mora odjemalec pravilno razumeti za uporabo spletne storitve. To je možno preko opisnega jezika WSDL [15, 17], ki ponuja sintakso v jeziku XML. Definira celotno obnašanje spletne storitve (vrste sporo�il, izmenjava sporo�il kot operacije, vmesniki, vezi (bindings) med vmesniki in protokolom ter kon�nimi to�kami). Slika 6 podaja okvirno predstavitev naštetih pojmov.

#��&#$�(��$��%��

��

��

��

!��"

��%�%��%��

;��%��%�$!��%��!��

8�$��%�%$!��%��!��

��

��

�$�(��

#,8�788�8<�

��2��'��4

=. =. =.

�%(%��(��

��

$��$��

��%�� %��

$��$��

��

��#$��%��

��

Tretnutno obstaja na trgu verzija WSDL 1.1 in je v celoti podprt standard. V nastajanju je WSDL 2.0 [16], ki je trenutno delovni osnutek organizacije W3C. Definicijska datoteka WSDL je obi�ajen dokument XML, korenski element definitions pripada imenskemu prostoru http://schemas.xmlsoap.org/wsdl/, XSD za WSDL je dostopna na istem naslovu. Element definitions lahko vsebuje razli�ne podrejene elemente kot types, message, portType, binding in service. Primer 5 podaja osnovno strukturo WSDL, ki je sestavljena iz abstraktnih in konkretnih definicij. <definitions name="MathService" targetNamespace="http://example.org/math/" xmlns="http://schemas.xmlsoap.org/wsdl/">  <types> ... </types> <message> ... </message> <portType> ... </portType>  <binding> ... </binding> <service> ... </service> </definitions>

��&1�%�%��!�/�%��>#9-

Elementi types, message, portType so abstraktne definicije vmesnika spletne storitve (ta vmesnik se lahko uporabi v programski kodi), ostala dva binding in service opisujeta konkretna pravila kako se abstraktni vmesnik preslika v sporo�ila na žici. Ti detajli so ve�inoma pod nadzorom infrastrukture in ne programske kode. Tabela 2 podaja osnovni opis elementov znotraj WSDL. Podrobnejši opis in primeri podaja vir [17]. Element Opis types Vsebuje abtraktne definicije tipov z XSD. message Definicija abstraktnega sporo�ila, ki je lahko sestavljeno iz ve�ih delov, vsak del

je lahko druga�nega tipa. portType Abstraktna množica operacij, ki jih nudi ena ali ve� kon�nih to�k (vmesnik);

operacija je definirana kot izmenjava sporo�il. binding Konkretni protokol in specifikacija podatkovnega formata za posamezen

vmesnik (portType). service Zbirka sorodnih kon�nih to�k; kon�na to�ka je definirana kot kombinacija vezi

(binding) in naslova (URI).

8��&1�%�%�$��'(%�)��%��>#9-

2.7 Universal Description, Discovery, and Integration (UDDI) UDDI je mehanizem (infrastruktura) s katerim se da spletne storitve locirati glede na dolo�ene lastnosti in registrirati [22]. V osnovi UDDI definira aplikacijski vmesnik (API) SOAP za iskanje in povpraševanje po centraliziranih registrih spletnih storitev. Tudi sam register obstaja v obliki spletne storitve in omogo�a programski dostop. Trenutna verzija UDDI je 3.0 [21], vendar se ve�ino opisov nanaša na UDDI 2.0 [19]. UDDI je pod okriljem organizacije OASIS1, ki skrbi za vse nove specifikacije.

1 http://www.oasis-open.org

��#$��%��

��

Spletne storitve je potrebno za uporabo prek UDDI najprej registrirati. Register nudi ogrodje za opis storitev preko entitet. Velja poudariti, da je možno opisati katerokoli spletno storitev ne glede na tehnologijo v kateri je storitev narejena. Za opis obstaja pet struktur (elementov) XML, ki lahko vsebujejo opis iz poslovne ali tehni�ne perspektive. Natan�en opis je podan v [20]. Slika 7 prikazuje relacije med temi elementi.

#��&=��!��%�� 99. � businessEntity: Nosi informacije o ponudniku storitve, ki je prestavljen kot entiteta

(ime ponudnika, kratek opis), in zbirko vseh storitev, ki jih ponudnik ponuja. Vsebuje lahko ve� elementov businessService.

� businessService: Nosi podrobne informacije o spletni storitvi. Vsebuje lahko ve� elementov bindingTemplate.

� bindingTemplate: Nosi tehni�ne informacije o vstopni to�ke storitve in njeni implementaciji. Vsebuje reference na tModels (tehni�ni modeli), ki dolo�ajo specifikacije vmesnika storitev.

� tModel: Opisuje abstraktno specifikacijo storitve (npr. lokacija do WSDL) ali njeno klasifikacijo. Za klasifikacijo uporablja preddefinirane modele in standarde: SIC (Standard Industrial Classification codes), NAICS (North American Industry Classification System), UNSPC (Universal Standard Products and Services Classification) ter ISO 3166 Geographic Classification. Obstaja pa tudi možnost dodajanja svojih klasifikacijskih shem.

� publisherAssertion: Vsebuje informacije o relacijah med entitetami znotraj registra. Vsi elementi imajo dodeljen svoj unikatni klju� v obliki GUID (Global Unique Indentifier), ki ga generira UDDI register ob prvem vnosu. Ta klju� rabi za kasnejši dostop do instanc elementov. V splošnem znotraj registra UDDI lo�imo dve vrsti informacij [18]: � množica abstraktnih protokolov, tModels, ki opisujejo obnašanje dolo�ene spletne

storitve; � informacija o implementaciji spletne storitve preko businessEntity. Primer 6 prikazuje izsek definicije elementa tModel, ki vsebuje svoj unikatni klju�, ime in opis. Vsebuje tudi naslov URL, kjer se nahaja definicija storitve preko datoteke WSDL. Le-ta ni shranjena v registru ampak na drugem zunanjem viru, predvsem zaradi varnosti. Na koncu vsebuje množico kategorizacij preko elementoy categoryBag. <tModel tModelKey=“AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA“> <name>http://company.com/e-checkin-interface</name> <description xml:lang=“en”> Standard service interface definition for credit checkin services </description> <overviewDoc> <description xml:lang=“en”> WSDL Service Interface Document

"��?

��/��%��

"��?

�

�

"��?

"��?

��?

�

#��$

#��%��

#�� &'��

��

��#�� (��

��#$��%��

��

</description> <overviewURL> http://company.com/services/credit-checkin.wsdl </overviewURL> </overviewDoc> <categoryBag> ... </categoryBag> </tModel>

��&��!�/�%��tModel

Primer 7 prikazuje definicijo ponudnika spletnih storitev, prikazani klju�i GUID so izmišljeni. Vsebovani so prej opisani elementi, bindingTemplate preko atributa tModelKey referencira zgornji tModel. Element categoryBag pa referencira na drug tModel, ki predstavlja klasifikacijo. <businessEntity xmlns="urn:uddi-org:api" businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"> <name>Contoso Finance Services</name> <description xml:lang="en">Corporate Finance</description> <businessServices> <businessService businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB" serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC"> <name>Credit Check</name> <bindingTemplates> <bindingTemplate serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC" bindingKey="DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD"> <accessPoint URLType="http">http://company.com/services/credit-checkin.aspx</accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="UUID:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"/> <tModelInstanceDetails> </bindingTemplate> </bindingTemplates </businessService> <businessServices> <categoryBag> <keyedReference tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634" keyName="Consumer credit gathering or reporting services" keyValue="84.14.16.01.00"/> </categoryBag> </businessEntity>

��&��!�/�%��businessEntity

UDDI API definira tudi množico sporo�il za iskanje in upravljanje z informacijami znotraj registra. Pozvedbe so vsebovane v sporo�ilih SOAP, ki vsebuje ustrezne vnaprej definirane elemente (ukaze). Npr. poizvedbe omogo�ajo: � iskanje ponudnikov storitev preko imena, klju�a, kategorije: find_business(); � iskanje sorodnih ponudnikov preko klju�a: find_relatedBusiness(); � iskanje spletnih storitev preko kju�a, imena, povezanih predlog: find_service(),

find_binding(); � iskanje ponudnikov in storitev preko tehni�nega modela: find_tModel(). Po izvršitvi poizvedbe je potrebno najdene zapise prebrati preko ukazov get_xx, npr. get_businessDetail(), get_serviceDetail(), get_bindingDetail(), get_modelDetail(). Podrobna specifikacija in primeri so podani v [19, 21, 18]. Primer 8 prikazuje enostaven primer sporo�ila SOAP za poizvedbo znotraj registra UDDI – iskanju ponudnika za dolo�en klju�.

��#$��%��

��

<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <find_business xmlns="urn:uddi-org:api_v2" generic="2.0"> <categoryBag> <keyedReference keyValue="51121" tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2" /> </categoryBag> </find_business> </Body> </Envelope>

��&��!�� 99.

��.%��$��%��2$��4�$��%�)��

��

3. Interoperabilnost (povezljivost) spletnih storitev Specifikacije in standardi XML, opisani v poglavju 2, so osnova za implementacijo spletnih storitev, vendar se tu zgodba ne kon�a. Zelo pomemben pogoj postaja interoperabilnost (povezljivost) spletnih storitev: delovanje na razli�nih platformah (Microsoft .NET, Java), operacijskih sistemih, razli�nih programskih jezikih in delovanje v povezavi z drugimi spletnimi storitvami. Za doseganje te skladnosti je potrebno upoštevati dolo�ena priporo�ila in pravila. Na podro�ju spletnih storitev obstaja mnogo specifikacij in standardov, vendar sami po sebi ne omogo�ajo interoperabilnosti. V ta namen je bila s strani ve�jih podjetij IT (IBM, Sun, Microsoft,..) ustanovljena samostojna odprta organizacija WS-I: Web Services Interoperability Organization1. Njena glavna naloga je podpora interoperabilnosti spletnih storitev na razli�nih platformah, aplikacijah in programskih jezikih. WS-I ne piše protokolnih specifikacij, ampak sedi pod standardizacijskimi organizacijami in predlaga kako naj se implementacije obnašajo v spornih slu�ajih glede na specifikacije izdane s strani organizacije OASIS2 in W3C3. WS-I nudi klju�na vire za razvoj interoperabilnih storitev, ki so isto�asno skladne z industrijsimi standardi in priporo�ili WS-I. Glavni viri so [53]: � Profili: množica klju�nih specifikacij spletnih storitev, ki v obliki priporo�il omogo�ajo

interoperabilnost. Klju�ni profil je WS-I Basic Profile 1.0, ki nudi nabor priporo�il in zahtev pri uporabi standardov XML, SOAP, WSDL in UDDI.

� Orodja za testiranje: rabijo za kontrolo in analizo interkacij s spletnimi storitvami, predvsem, �e izmenjana sporo�ila ustrezajo priporo�ilom WS-I. Glavna orodji sta Web Services Communication Monitor in Web Service Profile Anaylizer.

� Primeri uporabe in scenariji: uporaba poslovnih in tehni�nih zahtev iz realnih poslovnih okolij.

� Vzor�ne aplikacije: nudijo primere implementacije aplikacij in rešitev, ki so zgrajene na osnovi primerov uporabe in scenarijev.

Organizacija OASIS (Organization for the Advancement of Structured Information Standards) je neprofitni konzorcij, ki je zadolžen za razvoj in združevanje standardov e-poslovanja (varnost spletnih storitev, ebXML, PKI,..). Organizacija W3C (World Wide Consortium) razvija predvsem specifikacije, ki se nanašajo na svetovni splet (HTML, HTTP, CSS, DOM, XML, XPath,..).

3.1 Sklopi specifikacij Klju�ni standardi spletnih storitev so osnova za ostale specifikacije, na katerih slonijo protokoli za interoperabilnost. Sklope specifikacij prikazuje slika 8.

1 http://www.ws-i.org 2 http.//www.oasis-open.org 3 http://www.w3c.org

��.%��$��%��2$��4�$��%�)��

�"

#��&#��$��$��/��%��$��%��

Sklopi vsebujejo naslednje specifikacije (nekatere so že opisane v poglavju 2): ♦ XML

- XML 1.0 - Imenski prostori XML - XML Infoset

♦ Metapodatki (Metadata) - WSDL - UDDI - WS-Policy - WS-PolicyAssertions - WS-PolicyAttachments - WS-MetadataExchange

♦ Izmenjava sporo�il (Messaging) - SOAP - WS-Addressing - MTOM - WS-Eventing

♦ Varnost (Security) - WS-Security - WS-SecureConversation - WS-SecurityPolicy - WS-Trust - WS-Federation

♦ Zanesljivost (Reliable Messaging) - WS-ReliableMessaging

♦ Transakcije (Transactions) - WS-AtomicTransaction

��

�)��*�%��+��2,��*�%*4

�� ,�

2,��!��4

��2#��'��@4

-��*�%��2=��,��*�%*4

'��,��*�28��%��%�4

��.%��$��%��2$��4�$��%�)��

��

- WS-BusinessActivity - WS-Coordination

Sledi okvirni opis posameznih sklopov (specifikacije WS-*), podrobnejši pregled bi bistveno presegel okvir tega dela, zato so podane samo klju�ne zna�ilnosti.

3.2 Metapodatki (Metadata) Sklop dolo�a specifikacije, ki podrobneje opisujejo spletne storitve, vire in izmenjavo sporo�il.

3.2.1 WS-Policy Specifikacija dolo�a gramatiko za izražanje zmožnosti, zahtev in splošnih zna�ilnosti entitet, ki nastopajo znotraj sistema spletnih storitev [23]. WS-Policy dolo�a politiko kot zbirko razli�nih alternativ (izbir), kjer je vsaka alternativa zbirka trditev politike (angl. policy assertions). Trditev lahko predstavlja osebno preferenco, zahtevo, zmožnost, obnašanje ali drugo splošno zna�ilnost; npr. shemo za overjanje (avtentikacijo), transportni protokol, zna�ilnosti kakovosti storitve (QoS – Quality of Service), politiko tajnosti. Slika 9 prikazuje strukturo politike WS-Policy [24].

#��&��>#A��@

WS-Policy omogo�a definiranje politik v jeziku XML; predstavitev polike v XML infosetu se imenuje izraz politike (angl. policy expression), ki se navezuje na predmet politike (angl. policy subject) – predstavlja entiteto, npr. sporo�ilo, kon�no to�ko spletne storitve. Mehanizem za povezavo izraza politike z enim ali ve� predmeti se imenuje na priponka police (angl. policy attachment). Strukturo dokumenta (izraz politike) za WS-Policy prikazuje primer 9. Imenski prostor zadnje specifikacije [23] (v �asu pisanja tega dela) za predpono wsp je http://schemas.xmlsoap.org/ws/2004/09/policy, za predpono wsu pa http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-

1.0.xsd. <wsp:Policy xmlns:wsp="..." xmlns:wsu="..." wsu:Id="..." Name="..." TargetNamespace="..."> <Assertion wsp:Usage="..." wsp:Preference="..." /> <Assertion wsp:Usage="..." wsp:Preference="..." /> <Assertion wsp:Usage="..." wsp:Preference="..." /> ... </wsp:Policy>

��&#��'��'��>#A��@

Atribut wsp:Usage je obvezen in dolo�a na�in uporabe. Vsebuje lahko naslednje vrednosti:

��$%��2��@��)��%�4

��2��@4

#$��%��

8�!��2��@��%4

8�!��2��@��%4

��!��2#'��4

��.%��$��%��2$��4�$��%�)��

��

� wsp:Required: trditev mora ustrezati predmetu; �e le-ta ne izpolnjuje kriterijev trditve, pride do napake.

� wsp:Rejected: trditev eksplicitno ni podprta; �e je prisotna, povzro�i napako. � wsp:Optional: trditev lahko ustreza predmetu, ni pa nujno. � wsp:Observed: trditev velja za vse predmete; tisti ki zahtevajo dostop do storitve, so

obveš�eni, da bo politika uporabljena. � wsp:Ignored: trditev je procesirana, vendar se ignorira. V primeru, ko je na voljo ve� razli�nih trditev, se lahko uporabi atribut wsp:Preference, ki pove preferenco preko celega števila; ve�je število pomeni ve�jo preferenco. �e je atribut izpuš�en, se predpostavi, da je njegova vrednost enaka 0. WS-Policy definira množico operatorjev politike (angl. policy operators), s katerimi lahko združujemo ve� trditev. Privzeti operator, �e ni navedeno druga�e, je wsp:All, ki dolo�a izpolnjevanje vseh trditev. Seznam vseh operatorjev: � wsp:All: vsi podrejeni elementi morajo biti upoštevani. � wsp:ExactlyOne: natanko en podrejen element mora biti upoštevan. � wsp:OneOrMore: vsaj en podrejen element mora biti upoštevan. � wsp:Policy: pomeni isto kot wsp:All. Primer 10 podaja enostaven izraz za politiko, kjer predmet preferira drugo trditev. <wsp:Policy xmlns:wsp="..." xmlns:wsu="..." xmlns:janez="..."> <wsp:ExactlyOne wsp:Usage="wsp:Required"> <wsp:All wsp:Preference="1"> <janez:Food>Kalamari</janez:Food> <janez:Drink>Cockta</janez:Drink> </wsp:All> <wsp:All wsp:Preference="2"> <janez:Food>Pizza</janez:Food> <janez:Drink>Laško pivo</janez:Drink> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>

��"&:%��%��$��

3.2.2 WS-PolicyAssertions Specifikacija [25] definira štiri splošne trditve politike, ki se lahko uporabijo na poljubnem predmetu. Te trditve so: � wsp:TextEncoding: dolo�a znakovno kodiranje. <wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="iso-8859-5" />

� wsp:Language: dolo�a naravni jezik. <wsp:Language Language=”en-US” />

� wsp:SpecVersion: dolo�a verzijo specifikacije preko URI. <wsp:SpecVersion wsp:Usage="wsp:Required" URI="http://schemas.xmlsoap.org/ws/2002/04/secext"/>

� wsp:MessagePredicate: dolo�a stavek XPath za testiranje sporo�ila; npr. sporo�ila, ki

upoštevajo pravilo, morajo imeti natanko en <Security> element. <wsp:MessagePredicate wsp:Usage="wsp:Required"> count(wsp:GetHeader(.)/wsse:Security) = 1 </wsp:MessagePredicate>

��.%��$��%��2$��4�$��%�)��

��

3.2.3 WS-PolicyAttachment Specifikacija [26] definira mehanizme za povezavo politike s predmeti (entitetami). Natan�no dolo�a referenciranje politike iz elementov XML, definicij WSDL in entitet UDDI. Možne variante povezave (pripenjanja) politik so naslednje [26]: � Na element XML: preko globalnega atributa wsp:PolicyURIs (vsebuje seznam politik

lo�enih s presledki) in elementa wsp:PolicyRefeference (vsebuje URI politike). <MyElement wsp:PolicyURIs="http://www.fabrikam123.com/policies#DSIG http://www.fabrikam123.com/policies#TOK" />

� Zunanja politika: povezava je neodvisna od definicije predmeta (ki je ponavadi kon�na

to�ka storitve), omogo�ena je preko elementa wsp:PolicyAttachment. Predpona wsa dolo�a imenski prostor http://schemas.xmlsoap.org/ws/2004/08/addressing.

<wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:Address>http://company.com/endpoint</wsa:Address> </wsa:EndpointReference> </wsp:AppliesTo> <wsp:PolicyReference URI="http://company.com/policy.xml" /> </wsp:PolicyAttachment>

� Preko WSDL: politika se lahko lahko vklju�i preko elementa wsp:Policy, ki mora biti

podrejen elementu wsdl:definitions. Da je možno procesirati politiko znotraj dokumenta WSDL, je potreben dodaten element wsp:UsingPolicy.

� Preko UDDI: obstajata dva pristopa; prvi je neposredno referenciranje politike znotraj

entitet UDDI, drugi pa registracija politike kot tehni�ni model (tModel) in referenca teh modelov znotraj entitet UDDI, ki uporabljajo politiko.

3.2.4 WS-MetadataExchange Specifikacija [27] dolo�a mehanizme za pridobivanje razli�nih metapodatkov kon�nih to�k. Obstajajo trije tipi parov sporo�il SOAP tipa zahteva/odgovor, ki vra�ajo razli�ne metapodatke za dolo�eno kon�no to�ko/imenski prostor: WS-Policy, WSDL in XML Schema. Pridobivanje metapodatkov poteka preko zahteve GET. Primer 11 prikazuje tako sporo�ilo (branje metapodatkov o politiki). Kon�na to�ka je dolo�ena preko elementa wsa:To, ki je del specifikacije WS-Addressing. <s12:Envelope xmlns:s12="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/03/mex" > <s12:Header> <wsa:Action>http://schemas.xmlsoap.org/ws/2004/03/mex/GetPolicy/Request</wsa:Action> <wsa:MessageID>uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9</wsa:MessageID> <wsa:ReplyTo><wsa:Address>http://www.example.com/MyEndpoint</wsa:Address></wsa:ReplyTo> <wsa:To>http://www.example.org/YourEndpoint</wsa:To> </s12:Header> <s12:Body><wsx:GetPolicy/></s12:Body> </s12:Envelope>

��&6�)��B:8

��.%��$��%��2$��4�$��%�)��

��

3.3 Izmenjava sporo�il (Messaging) Sklop dolo�a specifikacije, ki podrobneje dolo�ajo sporo�ila (oblika, format) kot osnovo za komunikacijo med spletnimi storitvami.

3.3.1 WS-Addressing Specifikacija [28] dolo�a transportno neodvisne mehanizme za naslavljanje virov (kon�nih to�k); dolo�a pošiljatelje in sprejemnike sporo�il. Vse informacije so shranjene v sporo�ilu samem in so neodvisne od transportnega protokola. Npr. pri uporabi protokola HTTP se fizi�na lokacija URL kon�ne to�ke in logi�na akcija (SOAPAction) nahaja v glavi protokola HTTP in ne v SOAP sporo�ilu. WS-Addressing te omejitve odpravlja in dodaja nove zmožnosti, ki so neodvisne od transporta. WS-Addressing v osnovi ponuja dva mehanizma za pošiljanje informacij: reference kon�nih to�k (angl. endpoint references) in informacijske glave (angl. message information headers). Kon�na to�ka spletne storitve je naslovljiva entiteta ali vir, kamor se lahko pošiljajo sporo�ila. Referenca kon�ne to�ke vsebuje informacije za identifikacijo/naslavljanje kon�ne to�ke (vira). Referenca je sestavljena iz mrežnega naslova (element wsa:Address) in lastnosti reference (element wsa:ReferenceProperties), ki vsebuje druge naslovne informacije. Predpona wsa predstavlja imenski prostor (trenutna specifikacija) http://schemas.xmlsoap.org/ws/2004/08/addressing. Primer 12 podaja referenco kon�ne to�ke. <wsa:EndpointReference xmlns:wsa=”http://schemas.xmlsoap.org/ws/2003/03/addressing” xmlns:m=”http://example.net/ws/weather/forecasts” xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy”> <wsa:Address>http://example.org/weather/us</wsa:Address> <wsa:ReferenceProperties><m:Info>Services.Weather.Wind</m:Info></wsa:ReferenceProperties> <wsp:Policy> . . . </wsp:Policy> </wsa:EndpointReference>

��&=�/��%��%(%��(��

Informacijske glave so dodatni elementi v glavi sporo�ila SOAP. Elementi so naslednji: � wsa:MessageID: identifikator sporo�ila v obliki URI. � wsa:RelatesTo: relacija sporo�ila z drugim sporo�ilom; tip relacije je podan preko oblike

QName. � wsa:To: naslov prejemnika sporo�ila. � wsa:Action: logi�no ime akcije, ki jo vsebuje sporo�ilo. � wsa:From: naslov kon�ne to�ke, od kjer je sporo�ilo poslano. � wsa:ReplyTo: naslov kon�ne to�ke za odgovor. � wsa:FaultTo: naslov kon�ne to�ke za napake.

3.3.2 MTOM (Message Transmission Optimization Mechanism) Priporo�ilo [29] definira mehanizme za optimizacijo prenosa sporo�il SOAP s kodiranjem delov sporo�ila, vendar je predstavitev še vedno v obliki XML infoset-a. Optimizacija je možna samo za elemente, kjer je vsebina predstavljena kot podatkovni tip xsd:base64Binary. MTOM dolo�a tudi mehanizme za vklju�evanje priponk (angl. attachments) v sporo�ila SOAP.

��.%��$��%��2$��4�$��%�)��

��

3.3.3 WS-Eventing Specifikacija [30] definira protokol za dogodkovno orientirano izmenjavo sporo�il po konceptih WS-Addressing specifikacije. Spletna storitev lahko nastopa kot izvor/ponor dogodkov. Spletna storitev je naro�nik dogodkov pri storitvi, ki je izvor dogodkov. Naro�nik sprejema sporo�ila o dogodkih. Specifikacija definira operacije za upravljanje naro�anja na vire dogodkov in konstrukcijo dogodkovnih sporo�il. Obstaja ve� mehanizmov za pošiljanje dogodkov na ponor: asinhroni in “potisni” (angl. push) princip.

3.4 Varnost (Security) Spletne storitve so brez u�inkovite varnosti malo uporabne. Glede na to, da je protokol SOAP osnovni na�in za komunikacijo med storitvami, je potrebna ustrezna varnost ravno tukaj. Varnost spodaj leže�ih transportnih protokolov ni ve�ji problem, saj obstaja precej standardov, ki se lahko uporabljajo tudi za varnost spletnih storitev: SSL (Secure Socket Layer), novejši TLS (Transport Layer Security), IPSec (Internet Protocol Security). Osnovna omejitev teh mehanizmov je, da lahko delujejo samo med dvema kon�nima to�kama (angl. point-point) po principu zahteva/odgovor, standardna implementacija pa je samo na protokolu HTTP, kar je precejšnja omejitev. V ta namem je nastalo ve� specifikacij za varnost spletnih storitev, vse temeljijo na osnovnih tehnologijah SOAP, WSDL, XML digitalni podpis [40], XML enkripcija [39] ter SSL/TLS. Pri varovanju informacij je potrebno zagotoviti naslednje [31]: � Verodostojnost – overjanje (angl. authenticity): zmožnost, da lahko identificiramo vir

informacije in se prepri�amo o tem, od kod informacija prihaja. � Celovitost (angl. integrity): zmožnost, da informacija od svojega nastanka pa do trenutka,

ko jo sprejemamo, ni bila spremenjena. � Zaupnost (angl. confidentiality): dostop do informacije ima le tisti posameznik ali

skupina, ki ji je informacija namenjena. � Nezanikanje (angl. non-repudiation): to lastnost ima informacija, �e tisti, ki jo je

pripravil, pozneje ne more zanikati, da je res njen avtor. Poglavitne tehnologije, ki zagotavljajo zgoraj naštete lastnosti, so vezane na simetri�no in asimetri�no kriptografijo, infrastrukturo javnih klju�ev (PKI – Public Key Infrastructure) in digitalni podpis (angl. Digital Signature). Poglejmo osnovne zna�ilnosti naštetih pojmov. 1. Kriptografija Kriptografija je matemati�na disciplina, ki se ukvarja s šifriranjem (preoblikovanjem) podatkov. Kriptografsko metodo, po katerem je treba sporo�ilo šifrirati, definirata algoritem in klju�. Algoritem je postopek za šifriranje, klju� pa si delita pošiljatelj in prejemnik (simetri�na kriptografija). Kriptografske algoritme delimo v dve skupini: a) Simetri�ni: pošiljatelj in prejemnik se vnaprej pred samim komuniciranjem dogovorita

kateri algoritem in klju� (enak na obeh straneh) bosta uporabljala pri šifriranju/dešifriranju. Ta vrsta algoritmov je zelo hitra, zelo varna, žal pa je vnaprejšnja izmenjava kju�ev neprikladna. Primer algoritmov: DES (Data Encryption Standard), AES (Advanced Encryption Standard), IDEA (International Data Encryption Standard).

b) Asimetri�ni: uporablja dva razli�na klju�a, zasebnega in javnega. Vsak potencialni

naslovnik si izbere svoj zasebni klju� in iz njega izpelje javni klju� in ga javno distribuira. En klju� podatke šifrira, drugi dešifrira. Pomembna lastnost je, da klju�, ki zaklene

��.%��$��%��2$��4�$��%�)��

��

podatke, ne more le-teh tudi odkleniti, tisti klju�, ki podatke odklene, ne more le-teh zakleniti. Asimetri�ni algoritmi so precej po�asnejši od simetri�nih, vendar se znebijo omejitve, da se morajo komunicirajo�e strani sestati vnaprej, saj se javni klju�i lahko javno distirbuirajo. Primeri algoritmov: RSA (faktorizacija celih števil), ECC (kriptosistemi z elipti�nimi krivuljami).

Za kriptografijo znotraj sporo�il SOAP se uporablja standard XML Encryption [39]. 2. Infrastruktura javnih klju�ev - PKI Sama asimetri�na kriptografija ni dovolj za izmenjavo javnih klju�ev. Vir težav je v tem, da prejemnik javnega klju�a ne more ugotoviti, komu ta klju� dejansko pripada. Težavo rešuje PKI, kjer sta osrednja elementa certifikat in overovitelj (CA – Certifikate Authority). Certifikat je skupek javnega klju�a ter identifikacijskih podatkov lastnika tega klju�a. Zapisano je tudi kdo ga je izdal, rok veljanosti in kje je seznam vseh certifikatov, ki jih je overovitelj pred�asno preklical (CRL – Certificate Revocation List). Vsi omenjeni podatki so digitalno podpisani s strani overovitelja. Danes se v ve�ini primerov uporablja standard X.509 v3, ki predpisuje le certifikate z dolo�enim rokom trajanja. 3. Digitalni podpis V primeru, da pošiljatelj sporo�ila doda še to isto sporo�ilo, dešifrirano s svojim zasebnim klju�em, lahko prejemnik poskusi sporo�ilo šifrirati s pošiljateljevim javnim klju�em. �e se sporo�ili ujemata, je to dokaz, da sporo�ilo pripada pošiljatelju. Tehni�ni pogoj, ki ga mora izpolnjevati kriptografski asimetri�ni algoritem za izvedbo digitalnega podpisa je:

D(E(P)) = E(D(P)) = P

P prestavlja sporo�ilo, D zasebni dekripcijski klju�, E javni enkripcijski klju�. Bolj podroben potek digitalnega podpisa prikazuje slika 10. Uporabo digitalnega podpisa v sporo�ilih SOAP definira standard XML Signature [40].

#��"&9�*��%�$!$��

8��$��%�$�(��;�;��

1��*�%��%�$�(��

�@��C�%D?4�E/9�F�9G�HIJ��G�K*�LD%�!G*M��%�,!N��*,�O

6* (�%�$�(��6* (��%�2)��)4/'%��2�)��!�4

IJ��G�F�' H�HM�HIJ�P?A�I/!��QG�>�:�P3/9�G%�?F��*/�K*=$R

9�*��%�$!$��(%��%��$��

� $��%��'(��%��

��%��!�*��%�*�$!$��2��%;4

��!�*��%�$!$��2��%�4

IJ��G�F�' H�HM�HIJ�P?A�I/!��QG�>�:�P3/9�G%�?F��*/�K*=$R

9�*��%�$!$��(%�!��$�� @��C�%D?4�E/

9�F�9G�HIJ��G�K*�LD%�!G*M��%�,!N��*,�O

6* (�%�$�(��

� ��%��'(2��!��$�%4

8��$��%�$�(��;�;��

��$�(��6* (��%�2)��)4/'%��2�)��!�4

�@��C�%D?4�E/9�F�9G�HIJ��G�K*�LD%�!G*M��%�,!N��*,�O

6* (�%�$�(��,��.//.

��.%��$��%��2$��4�$��%�)��

��

3.4.1 WS-Security WS-Security je osnova za vse ostale varnostne specifikacije [33, 34, 35]. Dolo�a razširjene varnostne mehanizme znotraj glave SOAP, kar omogo�a pošiljanje varnostnih žetonov (angl. security tokens) za varno identifikacijo (avtorizacijo) in verodostojnost (overjanje) odjemalcev, poleg tega zagotavlja celovitost in zaupnost sporo�il. Slika 11 prikazuje stanje varnostnih specifikacij danes, ve�ina jih je še v razvoju.

#��&=��$��/��>#A#��'��@

Specifikacijo WS-Security so nadomestile druge specifikacije preko standardizacije znotraj organizacije OASIS: Web Services Security SOAP Message Security [36], Web Services Security UsernameToken Profile [37] in Web Services Security X.509 Certificate Token Profile [38]. Specifikacije funkcionalno razširjajo sporo�ila SOAP (verzija 1.1 in 1.2) z varnostnimi elementi za zagotavljanje celovitosti (preko digitalnega podpisa XML) in zaupnosti (preko enkripcije XML) sporo�il. Dolo�a tudi mehanizme za dodajanje varnostnih žetonov znotraj sporo�ila SOAP. Žetoni so lahko lahko kombinacija uporabniškega imena in gesla, certifikat X.509 ali vstopnica Kerberos [45]. V splošnem je specifikacija odprta, podpira vse znane varnostne modele (PKI, SSL, Kerberos), razli�ne formate digitalnega podpisa in razli�ne kriptografske algoritme. Formati varnostnih žetonov so podani v lo�enih specifikacijah. Specifikacija definira element <wsse:Security> znotraj glave SOAP (primer 13). Omogo�a dodajanje varnostnih informacij za dolo�enega naslovnika (vmesna ali kon�na to�ka). Imenski prostori, ki so uporabljeni znotraj specifikacije, prikazuje tabela 3. Predpona Imenski prostor ds http://www.w3.org/2000/09/xmldsig# S11 http://schemas.xmlsoap.org/soap/envelope/ S12 http://www.w3.org/2003/05/soap-envelope wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-

wssecurity-secext-1.0.xsd wsu http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-

wssecurity-utility-1.0.xsd

8��&.��%��$��%��>#A#��'��@

<?xml version="1.0" encoding="utf-8"?> <S11:Envelope xmlns:S11="..." xmlns:wsse="..."> <S11:Header> <wsse:Security>

��

#1��%��

>#A#��'��@

>#A#��'��@��@ >#A8�'�� >#A#��'��<%��%

>#A��@ >#AG�!��% >#A�'�)��%

��.%��$��%��2$��4�$��%�)��

��

••• </wsse:Security> </S11:Header> <S11:Body> ••• </S11:Body> </S11:Envelope>

��&:��%�R��&#��'��@

3.4.1.1 Varnostni žetoni Vprašanje verodostojnosti (overjanja – avtentikacije) se rešuje prek varnostnih žetonov. Predvsem odgovarja na vprašanje: Koga avtoriziram? Tipi�en potek sporo�il z varnostnim žetonom prikazuje slika 12. Žetone priskrbi servis žetonov (angl. token service).

#��&8�$�(�%$��$�(��%��%��S��%� �eprav so varnostni žetoni lahko poljubni, specifikacija [36] definira razli�ne vrste žetonov za overjanje uporabnika: a) Žeton z uporabniškim imenom in geslom: definiran je z elementom wsse:UsernameToken znotraj wsse:Security, ki vsebuje uporabniško ime wsse:Username in geslo wsse:Password. Geslo se lahko pošlje kot navaden tekst ali kodirano preko zgoš�evalne (hash) funkcije (SHA-1, MD5) - tip je dolo�en preko atributa Type, ki ima lahko vrednosti wsse:PasswordText (privzeto) ali wsse:PasswordDigest. <wsse:UsernameToken> <wsse:Username>Janez</wsse:Username> <wsse:Password Type=”wsse:PasswordText”>MojeGeslo</wsse:Password> </wsse:UsernameToken>

b) Žeton z X.509 v3 certifikatom: definiran je preko elementa wsse:BinarySecurityToken znotraj wsse:Security. Žeton znotraj sporo�ila SOAP predstavlja javni klju� certifikata. Tip žetona za X.509 je podan preko atributa ValueType, ki ima vrednost wsse:X509v3. Na�in kodiranja znotraj sporo�ila je do�en z atributom EncodingType, ki ima lahko vrednost wsse:Base64Binary in wsse:HexBinary. Certifikat sam po sebi to�no dolo�a uporabnika, sicer pa lahko s certifikatom tudi digitalno podpišemo del sporo�ila s privatnim klju�em. <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> KkFPleDjCCB ... </wsse:BinarySecurityToken>

c) Žeton s Kerberos [45] vstopnico (angl. ticket): definiran je tudi preko elementa wsse:BinarySecurityToken, vrednost atributa ValueType pa je lahko enaka wsse:Kerberosv5TGT (granting ticket) ali wsse:Kerberosv5ST (service ticket).

��!*��

��!��S��%��S��%��*�!!��$�(��'#1��

��!$��%$ ��%��$�(��

��)��S��%

1!��$��%��

#��S��%�

#$��%��

��.%��$��%��2$��4�$��%�)��

��

<wsse:BinarySecurityToken ValueType="wsse:Kerberosv5ST" EncodingType="wsse:Base64Binary"> QMwcAG ... </wsse:BinarySecurityToken>

Varnostni žetoni so lahko vstavljeni direktno v glavo sporo�ila SOAP ali pa so naslovljeni znotrah lo�enih lokacij. V ta namem obstaja element SecurityTokenReference, ki vsebuje lokacijo URI, kjer se žeton nahaja.

3.4.1.2 Celovitost (integriteta) Celovitost sporo�il SOAP je rešena preko standarda XML Signature [40], ki omogo�a digitalni podpis dokumentov XML. Osnovni element je Signature, ki dolo�a kje se podpis za�ne in kon�a. Vsebuje še podrejene elemente, ki natan�no opisujejo digitalni podpis. �e je podpisov znotraj enega dokumenta ve�, vsak element Signature vsebuje identifikacijsko vrednost preko atributa wsu:Id. Klju�ni podrejeni elementi so SignedInfo, SignatureValue in KeyInfo. Primer 14 prikazuje digitalni podpis znotraj sporo�ila SOAP. <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..."> <S11:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" wsu:Id="X509Cert"> KkFPle ... </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14N"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#MessageBody"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue> aOb4Luuk... </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> A9qqIrtE3xZ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Cert"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S11:Header> <S11:Body wsu:Id="MessageBody"> ••• </S11:Body> </S11:Envelope>

��&9�*��%�$!$��%��$�(��#1��

Element Signature vsebuje ve� podrejenih elementov: � ds:SignedInfo: informacija o podpisu, je najkompleksnejši element, ker vsebuje najve�

podrejenih elementov in referenc. Vsebuje klju�no informacijo o podpisu. � ds:CanonicalizationMethod: normalizacijski algoritem (npr. normiranje za�etnih in

kon�nih presledkov) za podatke, ki bodo digitalno podpisani. Pomembno je, da je dokument XML za digitalni podpis v predpisani standardni obliki.

� ds:SignatureMethod: algoritem za digitalni podpis. � ds:Reference: kazalec URI na podatke znotraj dokumenta oz. na spletna sredstva, kjer so

podatki za podpis. Sklic se lahko nanaša na poljubno datoteko, bodisi na disku, krajevnem

��.%��$��%��2$��4�$��%�)��

�"

omrežju ali spletu. Znotraj sporo�ila SOAP tipi�no kaže na podatke znotraj telesa in dele znotraj glave.

� ds:DigestMethod: algoritem za zgoš�evanje (vsebuje kazalec na opis). � ds:DigestValue: vrednost (rezultat) zgoš�evalnega algoritma. � ds:SignatureValue: vrednost (rezultat) je seznam bajtov, ki nastane s podpisom

podatkov. � ds:KeyInfo: dolo�a javni klju� za validacijo digitalnega podpisa. Lahko je dolo�en kot

referenca na certifikat, ki vsebuje javni klju� (kot v primeru 14) ali pa je vsebovan znotraj podrejenih elementov ds:KeyName in ds:KeyValue.

Kot je razvidno s primera je postopek podpisa slede�: normalizacija podatkov za podpis, zgoš�evanje (hash) podatkov, digitalni podpis zgoš�enih podatkov.

3.4.1.3 Zaupnost Za zaupnost sporo�il se uporablja standard XML Encryption [39]. Omogo�a šifriranje celotnega ali posameznih delov sporo�ila SOAP kot tudi njegovih priponk. Za šifriranje podatkov se lahko uporabi simetri�ni ali asimetri�ni algoritem. Pri simetri�nem pošiljatelj in naslovnik za šifriranje/dešifriranje uporabljata enak klju�. Pri asimetri�nem algoritmu se uporablja par privatni in javni klju� (X.509 certifikat). Z javnim klju�em se podatki šifrirajo, s privatnim pa dešifrirajo. Glavni elementi, ki jih dolo�a standard so EncryptedData, EncryptedKey in ReferenceList. Primer 15 prikazuje sporo�ilo SOAP, ki vsebuje šifrirane podatke kot tudi šifriran simetri�ni klju�. Pri simetri�ni enkripciji se klju� zaradi ve�je varnosti pošilja šifriran z javnim klju�em prejemnika sporo�ila. Ko prejemnik prejme sporo�ilo, ga lahko dešifrira s svojim privatnim klju�em, potem pa uporabi simetri�ni klju� za dejansko dešifriranje podatkov. <S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <S11:Header> <wsse:Security> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName> CN=Key13, C=US </ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> ir4DfG . . . </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#EncryptedBody"/> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </S11:Header> <S11:Body> <xenc:EncryptedData wsu:Id="EncryptedBody"> <xenc:EncryptionMethod Algorithm=”http://www.w3.org/2001/04/xmlenc#tripledes-cbc”/> <xenc:CipherData> <xenc:CipherValue> r5KipsDV . . .

��.%��$��%��2$��4�$��%�)��

��

</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </S11:Body> </S11:Envelope>

��&5�/��%�$�(��#1��

V primeru se vsi poglavitni elementi nahajajo v telesu sporo�ila: � xenc:EncryptedData: vsebuje informacije o šifriranju in šifrane podatke preko svojih

podrejenih elementov. � xenc:EncryptionMethod: dolo�a algoritem za šifriranje podatkov (simetri�ni ali

asimetri�ni). � xenc:ChipherData: preko podrejenega elementa xenc:ChipherValue vsebuje šifrirane

podatke v formatu base64. Informacija o klju�u, ki je šifiran, se nahaja v glavi sporo�ila (element xenc:EncryptedKey), šifriran je preko javnega klju�a z algoritmom RSA (element xenc:EncryptionMethod). Ostali elementi so še: � xenc:KeyInfo: informacija o klju�u; ime klju�a (element xenc:KeyName). � xenc:ChipherData: enak pomen kot pri xenc:EncryptedData elementu zgoraj, le da ta

vsebuje šifrano vrednost klju�a. � xenc:ReferenceList: podaja seznam referenc (element xenc:DataReference) na dele

sporo�ila SOAP, ki uporabljajo ta klju� oz. so šifrirani s tem klju�em.

3.4.2 WS-Trust Specifikacija [41] dolo�a mehanizme za pridobivanje varnostnih žetonov preko dolo�enih servisov žetonov (npr. za X.509 certifikat od ustreznega overovitelja CA, za Kerberos vstopnice ustrezni distribucijski center – Kerberos Key Distribution Center (KDC)). Specifikacija dolo�a model zaupanja med udeleženci komunikacije. Sporo�ilo SOAP, ki predstavlja zahtevo za žeton, vsebuje znotraj telesa element wst:RequestSecurityToken; predpona wst predstavlja imenski prostor http://schemas.xmlsoap.org/ws/2004/04/trust. Primer 16 prikazuje zahtevo za X.509 certifikat. <S11:Envelope xmlns:s="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:wst="..."> <S11:Header> <wsse:Security> <wsse:UsernameToken wsu:Id="MyCert"> <wsse:Username>Mojca</wsse:Username> <wsse:Password>mojegeslo</wsse:Password> </wsse:UsernameToken> </wsse:Security> </S11:Header> <S11:Body> <wst:RequestSecurityToken> <wst:TokenType>wsse:X509v3</wsse:TokenType> <wst:RequestType>wsse:ReqIssue</wsse:RequestType> <wst:Base> <wst:Reference URI="#MyCert"/> </wst:Base> </wst:RequestSecurityToken> </S11:Body> </S11:Envelope>

��&6�)��+��"��/��

��.%��$��%��2$��4�$��%�)��

��

Odgovor, ki ga vrne ustrezni servis žetonov (CA, KDC), je sestavljen iz elementa wst:RequestSecurityTokenResponse, ki je vsebovan znotraj telesa sporo�ila SOAP. Primer 17 prikazuje odgovor na zahtevo za X.509 cefitikat (primer 16). Odgovor vsebuje cerfitikat znotraj elementa wsse:BinarySecurityToken. <S11:Body> <wst:RequestSecurityTokenResponse> <wst:RequestedSecurityToken> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> KkFPle ... </wsse:BinarySecurityToken> </wst:RequestedSecurityToken> </wst:RequestSecurityTokenResponse> </S11:Body>

��&1!*��+��"��/��

3.4.3 WS-SecureConversation Specifikacija [42] dolo�a mehanizem za varno komunikacijo preko ve�ih sporo�il SOAP med kon�nimi to�kami. To omogo�a preko deljenega (shared) varnostnega konteksta, ki vsebuje klju�e in druge informacije. Klju� za šifriranje je odvisen od varnostnega konteksta znotraj dolo�ene seje. Varnostni kontekst se deli v okviru seje med vsemi kon�nimi to�kami, ki komunicirajo. Kontekst je dolo�en preko elementa wsc:SecurityContextToken, wsc predstavlja imenski prostor http://schemas.xmlsoap.org/ws/2004/04/security/sc/sct. Vsak kontekst ima enoli�no oznako (atribut wsu:Id) in ime (element wsc:Identifier) znotraj katerega so našteti eden ali ve� klju�ev. Sklicevanje na kontekst je preko elementa wsse:SecureTokenReference (enako kot na varnostni žeton). Primer 18 prikazuje varnostni kontekst, ki je vzpostavljen med dvema kon�nima to�kama. Vsebuje šifirirani deljeni klju� za šifriranje telesa sporo�ila SOAP. <S11:Envelope xmlns:S11="..." xmlns:ds="..." xmlns:wsse="..." xmlns:wsc="..."> <S11:Header> ... <wsse:Security> <wsc:SecurityContextToken wsu:Id="MyID"> <wsc:Identifier>uuid:652d2aaa-4857-4d8c-865c-f9549e5806f0</wsc:Identifier> </wsc:SecurityContextToken> <ds:Signature> ... <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#MyID"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S11:Header> <S11:Body wsu:Id="MsgBody"> <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> QQQ </tru:StockSymbol> </S11:Body> </S11:Envelope>

��&9��%��%��%��%��

��.%��$��%��2$��4�$��%�)��

��

Obstajajo trije na�ini vzpostavitve deljenega varnostnega konteksta med kon�nimi to�kami, ki komunicirajo: a) Kontekst je dodeljen preko servisa žetonov: iniciator pošlje zahtevo po žetonu preko

elementa wst:RequestSecurityToken (wst predstavlja imenski prostor za speficikacijo WS-Trust), servis mu vrne odgovor z elementom wst:RequestSecurityTokenResponse, ki vsebuje varnostni kontekst (žeton) wst:RequestedSecurityToken in deljeni šifrirani simetri�ni klju� wst:RequestedProofToken.

b) Kontekst kreira eden od udeležencev komunikacije: iniciator kreira varnostni žeton in ga pošlje drugem udeležencu preko sporo�ila SOAP z elementom wst:RequestSecurityTokenResponse. Ta kot v prejšnjem primeru vsebuje elementa wst:RequestedSecurityToken in wst:RequestedProofToken.

c) Kontekst se kreira preko pogajanja med udeležencema: iniciator pošlje sporo�ilo z elementom wst:RequestSecurityToken drugemu udeležencu, le ta mu vrne odgovor z wst:RequestSecurityTokenResponse, ki kot v prejšnjih primer vsebuje elementa wst:RequestedSecurityToken in wst:RequestedProofToken.

Varnostni kontekst vedno vsebuje deljeni simetri�ni klju�, ki se lahko uporabi za šifiriranje in digitalni podpis sporo�il. Specifikacija zaradi ve�je varnosti priporo�a uporabo izpeljanega klju�a (element wst:ComputedKey), ki je unikaten glede na kontekst. Algoritem za izpeljavo klju�ev temelji na specifikaciji TLS (Transport Level Security).

3.4.4 WS-SecurityPolicy Specifikacija [43] temelji na WS-Policy z dodatnimi elementi, ki se ti�ejo varnostne politike. Ti elementi so ozna�eni kot trditve, ki vsebujejo ustrezne varnostne zahteve, kot npr. vrsta overjanja (žetoni), algoritmi za digitalni podpis (celovitost), algoritmi za šifriranje (zaupnost), deli sporo�ila, ki so šifrirani in podobno. Elementi varnostne politike so vsebovani znotraj elementa wsp:Policy (glej poglavje 3.2.1) in so naslednji (wsse dolo�a imenski prostor uporabljen v specifikaciji WS-Security): � wsse:SecurityToken: dolo�a kakšne vrste varnostnih žetonov lahko sprejme spletna

storitev, opcijsko tudi katerim izdajateljem žetonov se lahko zaupa. � wsse:Integrity: dolo�a razli�ne lastnosti digitalnega podpisa (npr. zgoš�evalni

algoritem, kateri deli sporo�ila so za podpis). � wsse:Confidentiality: dolo�a kako je izvedeno šifiranje sporo�ila (algoritem, deli

sporo�ila, informacija o klju�u). � wsse:Visibility: dolo�a kateri deli sporo�ila morajo biti nešifrirani oz. vidni za

procesiranje na vmesni ali kon�ni to�ki. Primer 19 prikazuje varnostno politiko, ki za overjanje zahteva varnostni žeton v obliki Kerberos vstopnice. <wsp:Policy xmlns:wsp="...” xmlns:wsse="..."> <wsse:SecurityToken wsp:Usage="wsp:Required"> <TokenType>wsse:Kerberosv5ST</TokenType> </wsse:SecurityToken> </wsp:Policy>

��&0��%��%�$��%��T��%��

��.%��$��%��2$��4�$��%�)��

��

3.4.5 WS-Federation Specifikacija [44] dolo�a mehanizme, ki omogo�ajo združevanje razli�nih varnostnih domen preko posredovanja identitet, atributov in overjanja med sodeluje�imi spletnimi storitvami. Za osnovo uporablja specifikacije WS-Security, WS-Policy, WS-Trust in WS-SecureConversation. Federacija (angl. federation) predstavlja zbirko domen, ki so vzpostavile medsebojno zaupanje (angl. trust). Nivo zaupanja je lahko razli�en, vendar tipi�no vsebuje overjanje in avtorizacijo. Obstaja ve� razli�nih scenarijev za vzpostavitev federacije (osnovni in izpeljani).

3.5 Zanesljivost (Reliable Messaging) Sklop dolo�a specifikacijo za zagotavljanje zanesljivosti pri prenosu sporo�il.

3.5.1 WS-ReliableMessaging Specifikacija [47, 46, 48] definira mehanizme oz. protokol za zanesljiv prenos sporo�il med izvorom in ponorom �ez nezanesljiva komunikacijska omrežja. Mehanizmi so neodvisni od transportnih protokolov. Protokol zagotavlja, da bo poslano sporo�ilo dostavljeno na ponor. To zagotovilo se imenuje jamstvo dostave (angl. delivery assurance). Izvor in ponor sta kon�ni to�ki ter nosita odgovornost za jamstvo dostave, v nasprotnem primeru se proži napaka. Obstajajo štiri osnovna jamstva dostave, ki jih zagotavljajo kon�ne to�ke: � AtMostOnce: sporo�ila bodo dostavljena najve� enkrat brez podvojitev, druga�e se proži

napaka na vsaj eni kon�ni to�ki; možno je, da nekatera sporo�ila v sekvenci niso dostavljena.

� AtLeastOnce: vsako poslano sporo�ilo bo dostavljeno, druga�e se proži napaka; možno je, da so nekatera sporo�ila dostavljeno ve�krat.

� ExactlyOnce: vsako poslano sporo�ilo bo dostavljeno brez podvojitev, druga�e se proži napaka. To jamstvo je logi�na konjunkcija predhodnih dveh jamstev.

� InOrder: sporo�ila bodo dostavljena v vrstnem redu kot so bila poslana. To jamstvo se lahko kombinira z ostalimi jamstvi.

Slika 13 prikazuje možen na�in pošiljanja sporo�ila med dvema kon�nima to�kama.

��.%��$��%��2$��4�$��%�)��

��

#��&��>#A=��,��*�%*

Najprej se vzpostavijo predpogoji – izmenjava politike, identifikacija kon�nih to�k ter vzpostavitev zaupanja (WS-Trust). Izvor zahteva kreiranje nove sekvence, ponor kreira sekvenco in vrne globalni enoli�ni identifikator GUID (Global Unique Identifier). Izvor za�ne pošiljati sporo�ila za�enši z MessageNumber=1 (na sliki pošlje 3 sporo�ila). Drugo sporo�ilo se na poti izgubi. V zadnje tretje sporo�ilo izvor doda žeton LastMessage. Ponor kot odgovor pošlje potrditev sprejema sporo�il 1 in 3. Izvor ponovi prenos drugega sporo�ila z dodanim elementom AckRequested (zahteva potrditev ponora), gre za novo sporo�ilo na transportnem nivoju z isto številko, ponor ga prepozna kot ekvivalent prejšnjega sporo�ila. Ponor ob sprejemu drugega sporo�ila pošlje potrditev izvoru, le-ta pošlje sporo�ilo za konec sekvence, kar pomeni, da ne bo ve� pošiljal sporo�il. Vsi zaseženi viri se sprostijo. Elementi WS-ReliableMessaging protokola so naslednji (vsi pripadajo imenskemu prostoru http://schemas.xmlsoap.org/ws/2004/03/rm, predpona wsrm): � wsrm:Sequence: omogo�a jamstvo dostave za sporo�ila, ki so poslana v zaporedju

(sekvenci). Vsaka sekvenca ima unikatni identifikator (element Indentifier), vsako sporo�ilo mora imeti element MessageNumber, ki se pove�uje za 1. Opcijska elementa sta še LastMesssage in wsu:Expires (predpona wsu predstavlja imenski prostor http://schemas.xmlsoap.org/ws/2002/07/utility).

� wsrm:SequenceAcknowledgement: ponor obvesti izvor o uspešnem prejemu sporo�il. � wsrm:AckRequested: izvor zahteva, da mu ponor pošlje potrditev. � wsrm:CreateSequence: izvor zahteva kreiranje sekvence, ponor lahko pošlje odgovor

CreateSequenceResponse ali CreateSequenceRefused (napaka). � wsrm:TerminateSequence: izvor obvesti ponor, da je sekvenca sporo�il kon�ana.

3.6 Transakcije (Transactions) Sklop dolo�a specifikacije, ki se nanašajo na transakcije v porazdeljenih okoljih. Mehanizmi zagotavljajo, da se izmenjava ve�je množice sporo�il med ve�imi udeleženci izvrši kot logi�na celota, v nasprotnem primeru se vse izvedene akcije razveljavijo.

�

�%(%��(��

�%(%��(��;

0�$��$��!$*��

CreateSequence()

CreateSequenceResponse(Identifier=http://test.com/abc)

Sequence(Identifier=http://test.com/abc, MessageNumber=1)

Sequence(Identifier=http://test.com/abc, MessageNumber=2)

Sequence(Identifier=http://test.com/abc, MessageNumber=3, LastMessage)

SequenceAcknowledgement(Identifier=http://test.com/abc, AcknowledgementRange=1,3)

Sequence(Identifier=http://test.com/abc, MessageNumber=2, AckRequested)

SequenceAcknowledgement(Identifier=http://test.com/abc, AcknowledgementRange=1...3)

TerminateSequence(Identifier=http://test.com/abc)

��.%��$��%��2$��4�$��%�)��

��

3.6.1 WS-Coordination Specifikacija [50] dolo�a razširljivo ogrodje za protokole (koordinatorje), ki koordinirajo akcije med porazdeljenimi aplikacijami. Omogo�a kreiranje transakcijskih kontekstov za izvajanje aktivnosti med storitvami in registracijo koordinacijskih protokolov. Specifikacija definira tudi strukturo transakcijskega konteksta in pogoje za prenašanje konteksta med sodelujo�imi viri. Koordinator je sestavljen iz ve�ih komponent (slika 14): � Servis za aktivacijo (angl. Activation service) z operacijo CreateCoordinationContext,

ki omogo�a aplikaciji kreiranje koordinacijske instance oz. transakcijskega kontesta CoordinationContext.

� Servis za registracijo (angl. Registration service) z operacijo, ki omogo�a aplikaciji registracijo za udeležbo v koordinacijskem protokolu.

� Množica servisov za koordinacijske protokole za vsak podprt koordinacijski tip.

#��&8��%��!�%�� Aplikacija uporabi servis za aktivacijo, da kreira kontekst za dolo�eno aktivnost. Ko je kontekst kreiran, se le-ta pošlje vsem udeleženim aplikacijam. Kontekst vsebuje potrebne informacije za registracijo transakcije. Ko aplikacija prejme kontekst, lahko uporabi servis za registracijo znotraj prvotne aplikacije. Slika 15 prikazuje interakcijo dveh aplikacij (Aplikacija1, Aplikacija2) z svojima koordinatorjema (KoordinatorA, KoordinatorB). Ve� informacij podaja vir [49].

#��&.%��$��$��)��!�%��

��U��+

<��<�!�%��%<%��J�

0��

��%��)��,��%��*�

��%��)��&��*�

��%��)��,��

��%��)��,��1

=�*��

#$��%��

(��,��*�� (��,��*�2

0�� (

#��

#��*��=��

#��$��U�

0�� 3

#��;

#��*��=�;

#��$��U�

��<��<�!�%��%<%��J��$�V0�%�<�J�

��$��$ ��$��$��$�(��'��<�J�

��<��<�!�%��%<%��J��<�J�

0�%�<�J;

��=�*��$��U0�%�U�

��U

��=�*��$��U�U�0�%�U�

��.%��$��%��2$��4�$��%�)��

��

1) Aplikacija1 pošlje koordinatorju KoordinatorA CreateCoordinationContext za

koordinacijo tipa Q, nazaj dobi kontekst CtxA, ki vsebuje identifikator aktivnosti A1, koordinacijski tip Q in referenco kon�ne to�ke na servis za registracijo RsA koordinatorja KoordinatorA.

2) Aplikacija1 pošlje Aplikacija2 sporo�ilo, ki vsebuje kontekst CtxA. 3) Aplikacija2 pošlje CreateCoordinationContext s kontekstom CtxA svojemu

koordinatorju KoordinatorB. Ta kreira svoj lastni kontekst CtxB, ki vsebuje isti identifikator aktivnosti kot CtxA, vendar svoj servis za registracijo RsB.

4) Aplikacija2 dolo�i koordinacijski protokol za koordinacijski tip Q in potem registrira udeležbo v koordinacijskem protokolu Y koordinatorja KoordinatorB, ta izmenja reference kon�nih to�ke za aplikacijo Aplikacija1 in servis za protokol Yb. To oblikuje logi�no povezavo med referencami kon�nih to�k, ki jih lahko uporabi protokol Y.

5) KoordinatorB izvede registracijo na servis registracije RsA koordinatorja KoordinatorA, sledi izmenjava referenc kon�nih to�k za servis protokolov Yb in Ya. To oblikuje logi�no povezavo med referencami kon�nih to�k, ki jih lahko uporabi protokol Y.

3.6.2 WS-AtomicTransaction Specifikacija [51] podaja definicijo atomarnega koordinacijskega tipa za koordinacijo aktivnosti, ki deluje po principu “vse ali ni�”. Definira tri koordinacijske protokole: dokon�anje (angl. completion), kratka dvofazna potrditev (angl. volatile two-phase commit, 2PC), dolgotrajna dvofazna potrditev (angl. durable 2PC). Atomarne transakcije imajo lastnost, da se izvedejo vse ali nobena. Ko aplikacija zaklju�i z aktivnostjo, zahteva od koordinatorja, da ugotovi rezultat transakcije. Koordinator ugotovi ali je bilo kaj napak pri izvajanju preko glasovanja vseh udeležencev v transakciji. �e vsi odgovorijo, da so uspešno izvedli aktivnost, koordinator vse izvedene aktivnosti potrdi (angl. commit). �e kateri od udeležencev odgovori negativno, ali �e sploh ne odgovori, potem koordinator prekine vse izvedene akcije (angl. rollback) – velja stanje pred izvedbo transkacije. Gre za protokol z dvema fazama: faza priprave (angl. prepare) in faza potrditve/prekinitve (angl. commit/rollback). Vsi udeleženci (viri) morajo biti tekom transakcije aktivni. Atomarni koordinacijski kontekst (glej WS-Coordination) mora vsebovati vsa sporo�ila aplikacij, ki so udeležene v transakciji. Atomarna transakcija doda ustrezno semantiko operaciji CreateCoordinationContext na servisu za aktivacijo: � �e zahteva vsebuje element CurrentContext, se ciljni koordinator podredi koordinatorju,

ki je dolo�en znotraj elementa CurrentContext; � �e zahteva ne vsebuje elementa CurrentContext, ciljni koordinator kreira novo

transakcijo. Specifikacija WS-AtomicTransaction dolo�a slede�e protokole za atomarne transakcije: 1. Dokon�anje (angl. completion): aplikacija (iniciator) sporo�i koordinatorju naj bodisi

poskusi potrditi ali prekiniti transakcijo. Po kon�ani transakciji se aplikaciji vrne status. Slika 16 prikazuje abstraktni diagram stanj.

��.%��$��%��2$��4�$��%�)��

��

#��&#��%��$��!�%(�%��2��$��%4

2. Dvofazno potrjevanje (angl. two phase commit - 2PC): protokol koordinira registrirane

udeležence za odlo�itev o potrditvi (commit) ali prekinitvi (rollback) in zagotavlja, da so vsi udeleženci obveš�eni o kon�nem izidu transakcije. Slika 17 prikazuje abstraktni diagram stanj.

#��&#��%��$��<

3.6.3 WS-BusinessActivity Specifikacija [52, 49] predpisuje definicijo koordinacijskega tipa poslovnih aktivnosti (angl. business activity), ki je uporabljen v ogrodju WS-Coordination. Poslovna aktivnost uporablja ve� atomarnih transakcij za prehod iz enega konsistentnega stanja v drugega, pri tem uporablja ve� virov za daljše �asovno obdobje. Specifikacija definira dva koordinacijska protokola: � BusinessAgreementWithParticipantCompletion: udeleženec se registrira za uporabo

protokola, ki ga nadzoruje njegov koordinator. Udeleženec mora to�no vedeti, kdaj je kon�al akcije znotraj poslovne aktivnosti.

� BusinessAgreementWithCoordinatorCompletion: udeleženec se registrira za uporabo protokola, ki ga nadzoruje njegov koordinator. Udeleženec je odvisen od svojega koordinatorja, le-ta mu sporo�i kdaj je prejel vse zahteve za izvedbo akcij znotraj proslovne aktivnosti.

*�%��%��*�%��!�%��

(#��

4��#��,

��

��%*

<�$��%* :%!�!

G�� G��

*�%��!�%��

4�� $��

(#��

(#��

4��#��,

��

<��%* :%!�!

��%*

��$��!��$��%*��

*�%��'!��S�%��

��>#A.;��/��"

��

4. WS-I Basic Profile 1.0 Namen priporo�ila WS-I Basic Profile 1.0 [54] (trenutno obstaja že verzija 1.1 [55]) organizacije WS-I je na�rtovanje in implementacija spletnih storitev, ki so interoperabilne - povezljive med razli�nimi platformami, operacijskimi sistemi in programskimi jeziki ter drugimi spletnimi storitvami. Cilj priporo�ila ni definicija novih standardov, ampak uporaba obstoje�ih osnovnih specifikacij (XML 1.0, XML Schema, SOAP 1.1, WSDL 1.1, UDDI 2.0) za spletne storitve, za katere podaja ustrezne smernice, interpretacije, scenarije uporabe in priporo�ila [56]. Kompatibilnost z novejšimi verzijami specifikacij je zagotovljena (npr. SOAP 1.2, WSDL 1.2, WSDL 2.0). Podrobnejši obseg WS-I Basic Profile 1.0 obsega trenutne veljavne specifikacije: � Simple Object Access Protocol (SOAP) 1.1 (http://www.w3.org/TR/SOAP/); � Extensible Markup Language (XML) 1.0 (Second Edition) (http://www.w3.org/TR/REC-

xml); � RFC2616: Hypertext Transfer Protocol — HTTP/1.1 (http://www.ietf.org/rfc/rfc2616); � RFC2965: HTTP State Management Mechanism (http://www.ietf.org/rfc/rfc2965); � Web Services Description Language (WSDL) 1.1 (http://www.w3.org/TR/wsdl.html); � XML Schema Part 1: Structures (http://www.w3.org/TR/xmlschema-1); � XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2); � UDDI Version 2.04 API Specification, Dated 19 July 2002

(http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm); � UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002

(http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm); � UDDI Version 2 XML Schema (http://uddi.org/schema/uddi_v2.xsd); � RFC2818: HTTP Over TLS (http://www.ietf.org/rfc/rfc2818); � RFC2246: The TLS Protocol Version 1.0 (http://www.ietf.org/rfc/rfc2246); � The SSL Protocol Version 3.0 (http://wp.netscape.com/eng/ssl3/draft302.txt); � RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

(http://www.ietf.org/rfc/rfc2459).

4.1 Basic Profile - scenariji uporabe Scenariji uporabe definirajo uporabo spletnih storitev v razli�nih tipih interkacije med odjemalcem in ponudnikom spletne storitve. Scenariji odražajo osnovno realno uporabo spletnih storitev, ki se lahko med sabo združujejo v bolj kompleksne bloke. Definirani so trije scenariji uporabe: a) Enosmerni (one-way) Odjemalec pošlje sporo�ilo sporo�ilo SOAP ponudniku spletne storitve. Ponudnik sporo�ilo sprejme in ga izvede (klic storitve), vendar ne generira odgovora. b) Sinhrona zahteva/odgovor Odjemalec pošlje sporo�ilo SOAP ponudniku, le ta sporo�ilo izvede in potem generira odgovor, ki ga pošlje odjemalcu. c) Osnovni asinhroni klic nazaj (callback) Gre za uporabo dveh sinhronih parov zahteva/odgovor in je sestavljen iz štirih korakov. Odjemalec pošlje sporo�ilo SOAP – za�etno zahtevo ponudniku. Le ta odgovori s sporo�ilom – za�etni odgovor, ki predstavlja potrditev sprejema za�etne zahteve. Nato ponudnik pošlje

��>#A.;��/��"

�"

kon�no sporo�ilo SOAP – kon�na zahteva (angl. callback), ki je rezultat za�etne zahteve odjemalca. Odjemalec potrdi prejem in pošlje sporo�ilo – kon�ni odgovor.

4.2 Uporaba Basic Profile 1.0 WS-I Basic Profile 1.0 dolo�a specifi�ne zahteve, ki jih morajo upoštevati osnovne specifikacije spletnih storitev za doseganje skladnosti, kar je osnova za interoperabilnost. Te zahteve so podane kot izjave [56], ki se nanašajo na tri vrste dejstev: � SPORO�ILO (MESSAGE): elementi protokola, ki se izmenjujejo preko omrežja, vplivajo

na spletne storitve (npr. sporo�ila SOAP/HTTP). � OPIS (DESCRIPTION): opis tipov, sporo�il, vmesnikov in njihovih konkretnih

protokolov ter povezav s kon�nimi to�kami spletnih storitev (npr. WSDL). � REGDATA: elementi registra, ki so povezani z registracijo in iskanjem spletnih storitev

(npr. UDDI). Primer izjave [54]:

R1001: �e SPORO�ILO vsebuje element soap:Fault, MORAJO biti njegovi podrejeni elementi nekvalificirani.

Vir [56] priporo�a uporabo pravil za skladnost z Basic Profile 1.0 pri izdelavi spletnih storitev in odjemalcev v okolju Microsoft.NET s programskim jezikom C#, zato se nanašajo na specifi�nost samega okolja. Ve� o tehnologiji .NET je na voljo na spletnem naslovu http://msdn.microsoft.com/netframework/default.aspx. Priporo�ila se nanašajo na izdelavo spletnih storitev in izdelavo njenih odjemalcev. Ker je vseh priporo�il precej [56], se bomo omejili samo na nekatere. Primeri so podani v programskem jeziku C#.

4.2.1 Izdelava spletnih storitev a) Preusmeritev zahteve �e preusmerjamo (angl. redirect) zahtevo na drugo spletno storitev, je potrebno uporabiti HTTP statusno kodo 307 (Temporary Redirect); ne smemo uporabiti ukaza Context.Response.Redirect, ker le-ta ne vra�a pravilne statusne kode. Eksplicitno je potrebno postaviti kodo in podati glavo HTTP Location (pravilo R1130). Primer: [WebMethod] public string HelloWorld() { Context.Response.StatusCode = 307; Context.Response.AddHeader("Location","<redirect URL>"); return null; }

b) Glava SOAP Basic Profile 1.0 zahteva, da mora spletna storitev vse zaglavne bloke, ki so obvezni (mustUnderstand=”true”), najprej preveriti preden jih procesira. Tudi �e spletna storitev nima definiranih zaglavnih blokov (jih ne pri�akuje), lahko odjemalec vseeno pošlje obvezne bloke. Ti bloki morajo biti preverjeni (pravila R1025, R1027, R2739, R2753, R2725). Primer prikazuje kako preveriti predvideni zaglavni blok “myHeader” in vse neznane bloke s strani odjemalca.

��>#A.;��/��"

��

public MyHeaderType myHeader; public SoapUnknownHeader[] unknownHeaders; [WebMethod] [SoapHeader("myHeader", Required=false)] [SoapHeader("unknownHeaders", Required=false)] public string HelloWorld() { bool isHeadersValid = true; // Preveri, �e je blok ozna�en kot obvezen if (myHeader.MustUnderstand == true) { // Validiraj informacijo, ki jo ima blok if (<validacija myHeader> == false) { myHeader.DidUnderstand = false; isHeadersValid = false; } } // Preveri vse neznane bloke, �e so ozna�eni kot obvezni foreach (SoapUnknownHeader header in unknownHeaders) { if (header.MustUnderstand) { header.DidUnderstand = false; isHeadersValid = false; } } if (isHeadersValid == false) { // Izhod iz metode pred procesiranjem return null; } // Izvedi normalno predvideno procesiranje ... }

c) Obravnavanje izjem (napak) Vsaka sprožena izjema znotraj spletne storitve .NET, ki ni tipa SoapException, se avtomatsko pretvori v ta tip preko ogrodja .NET. Izjema tipa SoapException se potem pretvori v sporo�ilo SOAP, ki ga nosi element soap:Fault; to sporo�ilo se vrne odjemalcu. Basic Profile 1.0 ima nekaj omejitev glede lastnosti Code in Detail znotraj izjeme SoapException. Za lastnost Code je priporo�ena uporaba kvalificirane kode znotraj imenskega prostora ali pa uporaba vrednosti, ki jih nudi sam tip SoapException: VersionMismatchFaultCode, MustUnderstandFaultCode, ClientFaultCode in ServerFaultCode (pravilo R1004). Ob podajanju lastnosti Detail, mora biti korenski element kreiran preko vrednosti, ki jih ima SoapException.DetailElementName (pravilo R1000, R1001). Primer: XmlDocument doc = new XmlDocument(); XmlNode detail = doc.CreateNode(XmlNodeType.Element, SoapException.DetailElementName.Name, SoapException.DetailElementName.Namespace); // Dodamo dodatne podrejene elemente throw new SoapException("MyFault", SoapException.ServerFaultCode, "MyActor", detail);

4.2.2 Izdelava odjemalcev spletne storitve Odjemalec je v ogrodju .NET dostopa do spletne storitve preko posredniškega (proxy) razreda, ki je dedovan iz razreda SoapHttpClientProtocol. Posredniški razred se generira na podlagi opisa spletne storitve v jeziku WSDL.

��>#A.;��/��"

��

a) Zagotovitev skladnosti Za zagotavljanje skladnosti z Basic Profile 1.0 je potrebno v posredniški razred dodati zaglavni blok za skladnost, ki ne sme biti obvezen (pravila R0004, R0005, R0006, R0007). Primer prikazuje definicijo zaglavnega bloka ClaimHeaderValue: ... // Dodamo deklaracije znotraj proxy razreda public ClaimHeaderType ClaimHeaderValue; // Ta atribut dodamo pred spletno metodo (WebMethod) [SoapHeaderAttribute("ClaimHeaderValue")] .. // Ta razred dodamo na konec [XmlRoot("Claim",Namespace="http://ws-i.org/schemas/conformanceClaim/", IsNullable=false)] public class ClaimHeaderType : SoapHeader { [XmlAttribute()] public string conformsTo = "http://ws-i.org/profiles/basic/1.0"; }

b) Format sporo�il Privzet format ob klicu spletnih storitev je Unicode UTF-8. To nastavitev lahko redefiniramo preko lastnosti RequestEncoding razreda SoapHttpClientProtocol; Basic Profile 1.0 dovoljuje le uporabo vrednosti UTF8Encoding in UnicodeEncoding (UTF-16). c) Enosmerne (one-way) operacije Basic Profile 1.0 zahteva, da odjemalec ignorira odgovor SOAP v primeru enosmerne operacije. Prav tako mora v primeru napake odjemalec ignorirati podrobnosti (lastnost Detail) izjeme SoapException (pravilo R2750).

��>��#��:%)�%��%��"2>#:��"4

��

5. Web Services Enhancements 2.0 (WSE 2.0) WSE 2.01 za Microsoft.NET predstavlja razširitev obstoje�ega mehanizma za spletne storitve znotraj ogrodja .NET, predvsem v smeri razvoja interoperabilnih spletnih storitev. Vsebuje svoj predmetni model v obliki lastne knjižnice razredov .NET, ki jo predstavlja datoteka (zbir) Microsoft.Web.Services2.dll. WSE 2.0 podpira naslednje specifikacije: � WS-Security; � WS-SecureConversation; � WS-Trust; � WS-Policy; � WS-SecurityPolicy; � WS-Addressing; � WS-Attachments. WSE 2.0 pri pošiljanju sporo�il SOAP ni odvisen od transportnega protokola; podprto je pošiljanje preko protokolov HTTP in TCP. Arhitekturno je WSE predstavljen kot cevovod (angl. pipeline), ki vsebuje ustrezne vhodne/izhodne filtre za procesiranje zaglavnih blokov SOAP. Glavna razreda za delo s sporo�ili tipa zahteva/odogovor sta RequestSoapContext in ResponseSoapContext, ki omogo�ata dostop do vseh klju�nih delov spletne storitve. Prednik je razred SoapContext, ki omogo�a delo z zaglavnimi bloki SOAP. Slika 18 prikazuje izhodni cevod WSE; izhodni filtri preko informacij znotraj SoapContext generirajo ustrezne zaglavne bloke SOAP. Obratni proces prikazuje slika 19, ki prikazuje vhodni cevod. Vhodni filtri procesirajo zaglavne bloke vstopnega sporo�ila SOAP in informacije shranijo znotraj razreda SoapContext.

#��.�)!%��!>#:��"

1 WSE 2.0 je prosto dosegljiv na http://msdn.microsoft.com/webservices/building/wse/default.aspx

=��$%��#�$<%��J�

#�$<%��J�

<��!

.�)!%�/��

.�)!%�/��

.�)!%�/��

��B��

B��

B��

��>��#��:%)�%��%��"2>#:��"4

��

#��0)!%��!>#:��"

=�H'��#�$<%��J�

#�$<%��J�

<��!

0)!%�/��

0)!%�/��

0)!%�/��

��B��

B��

B��

��%��!��$��%�)��

��

6. Poslovni vidik spletnih storitev Predstavljene tehnologije spletnih storitev prinašajo samo tehni�ne specifikacije. �e gledamo na zadevo z druge (poslovne) perspektive, se postavi slede�e vprašanje: kako z omenjeno tehnologijo ustvariti vrednost v ekonomskem smislu? Odgovor na to vprašanje povezuje dva medsebojno lo�ena svetova: tehni�ni, ki nudi tehnologijo in poslovni, ki skuša ustvariti dodano vrednost. Vir [80] govori, da sta preživetje in razvoj podjetja odvisna od 4P (product, place, price, promotion), torej od pravilne izbire poslovnih u�inkov, trgov, kupcev in pospeševanje dejavnosti. Znotraj te trditve lahko z razmislekom uvrstimo tudi spletne storitve – nastopajo kot poslovni u�inek oz. izdelek, ki ga je potrebno prenesti na trg in kupce. Sicer je ta trditev precej grobo izhodiš�e za povezavo tehni�nega in poslovnega sveta. Vsekakor se je treba osredoto�iti na pojem elektronskega poslovanja in kasneje poslovnih modelov, ki so skupni imenovalec med tehnologijo in poslovanjem. Vir [67] navaja, da spletne storitve v veliki meri omogo�ajo avtomatizacijo toka informacij med razli�nimi poslovnimi subjekti (znotraj podjetja, med podjetji), kar pomeni boljšo povezavo med njimi in posledi�no ve�je sodelovanje, zmanjšanje stroškov in izboljšavo poslovnih procesov. Velik poudarek je na integraciji razli�nih sistemov, aplikacij, podatkovnih baz znotraj podjetja in med podjetji. Spletne storitve predstavljajo u�inkovit most brez ve�jih posegov v obstoje�e sisteme. Vse to kaže na veliko uporabnost spletnih storitev v poslovnem svetu. Vpeljava spletnih storitev v podjetje in povezava z obstoje�e tehnologijo ni enkratni linearni prehod. Lahko omenimo, da obstajajo trije principi planiranja in vpeljave spletnih storitev v podjetje, ki so si med seboj precej podobni. V osnovi spadajo v podro�je prenovitve poslovnih procesov (BPR – Business Process Reengineering), kar pa ni podro�je tega dela [67]: � Pokrivanje (leverage) obstoje�e tehnologije: spletne storitve lahko uporabljajo obstoje�o

tehnologijo; nova tehnologija prekriva staro. Bistveno je pridobiti dodano vrednost iz obstoje�e tehnologije s pomo�jo vpeljave spletnih storitev.

� Investicija v fazah: pri uporabi ve�jih starejših sistemov in aplikacij lahko podjetje pridobi korist tako, da prenovi svoje osnovne poslovne procese in z njimi povezane podporne sisteme. S pristopom uporabe spletnih storitev, niso potrebne tako korenite spremembe kot v primeru klasi�ne vpeljave. Investicije potekajo v fazah.

� Postopno vstavljanje novih elementov: temelji na prepri�anju, da lahko z spletnimi storitvami uporabimo obstoje�e sisteme brez celotne prenovitve in da ni potreben strah pred konkurenco z novejšo tehnologijo.

6.1 Elektronsko poslovanje Vpliv svetovnega spleta – interneta je pozvro�il malo gospodarsko “revolucijo”, ki sega v poslovne procese v taki meri, da spreminja poslovne subjekte (podjetja) in ustvarja nove. Gre za poslovanje, v katerem je mogo�e, da za�ne majhno specializirano podjetje tekmovati z velikim v isti panogi in je pri tem lahko zelo upešno. Kot primer lahko omenimo podjetja, ki se ukvarjajo s spletno trgovino (angl. e-commerce). Tu je zabrisana razlika med velikimi in majhnimi. Vsako majhno podjetje lahko prek svetovnega spleta vstopi na ve�miljonski trg z minimalnimi investicijami v informacijsko infrastrukturo. Spletne storitve z odprtimi standardi so klju�ni (angl. core) del elektronskega poslovanja v tehni�nem smislu. V tem poglavju bomo na kratko podali osnovne definicije in zna�ilnosti elektronskega poslovanja v širšem poslovnem smislu. Elektronsko poslovanje (angl. e-

��%��!��$��%�)��

��

business) je zelo široko podro�je, ki zajema tehni�ne, ekonomske, pravne in organizacijske okvire. Tako danes govorimo ne le o elektronsko trgovini in elektronskem poslovanju, temve� o elektronski ekonomiji ali tudi digitalni ekonomiji, ekonomiji znanja, novi ekonomiji. Pojem elektronsko poslovanje izhaja iz angleškega izraza “electronic commerce”, ki pa ima ožji pomen. Svetovna trgovinska organizacija elektronsko trgovanje opredeljuje kot proizvodnjo, distribucijo, trženje, prodajo ali dostavo blaga in storitev po elektronski poti. Konkretna transakcija elektronskega trgovanja lahko vsebuje ve� elementov oziroma sestavin poslovnih transakcij, med katerimi sta najbolj dolo�ujo�a dostava blaga in storitev ter pla�ilo po elektronski poti. Ve�ina opredelitev elektronskega poslovanja definira ta pojem v širšem smislu, kot je sam pojem e-commerce. Elektronsko poslovanje je širši pojem in se nanaša na vse, pri �emer s pomo�jo svetovnega spleta (interneta) lahko omogo�amo ve�jo u�inkovitost, hitrost, inovacije in ustvarjanje nove vrednosti v organizacijah. Uporaba svetovnega spleta spremeni poslovna razmerja med podjetjem in strankami, med podjetji, znotraj enega samega podjetja ali celo med samimi strankami. Podobno definicijo podaja vir [82], ki pravi, da imenujemo elektronsko poslovanje “vse, kar danes delamo v sklopu svoje poslovne dejavnosti s pomo�jo ra�unalniških aplikacij in ra�unalniških omrežij”. Ta pojem zajema: elektronsko ban�ništvo, elektronsko trženje, elektronsko trgovanje, spletno trgovino, svetovanje na daljavo, ra�unalniško podprto skupinsko delo ter delo, pouk in dražbe na daljavo. Pri tem so pomembni trije elementi: na�in dela (elektronska izmenjava podatkov), vsebina poslovanja, ki se skoraj neomejena (prodaja blaga in storitev, pla�evanja, izmenjava dokumentov,..) ter udeleženci poslovanja. Vir [83] poudarja, da pomeni elektronsko poslovanje povezovanje informacijske tehnologije, predvsem svetovnega spleta s poslovnimi procesi, ki spreminjajo organizacije in ustvarjajo nove. Informacijskta tehnologija je pove�ala u�inkovitost in produktivnost poslovnih procesov, ni jih pa spremenila. Spremenilo jih je elektronsko poslovanje, ki zajema vrsto razli�nih elektronskih procesov v verigi od dobavitelja do potrošnika (npr. elektronsko trgovanje in maloprodaja, elektronsko ban�ništvo, elektronske finance in investicije, elektronska uprava, elektronsko izobraževanje,..). Zanimiva definicija [84] pravi, da elektronsko poslovanje vklju�uje vse aplikacije podjetja, ki podpirajo njegovo poslovanje prek svetovnega spleta, kot tudi organizacijsko pripravljenost na tako vrsto poslovanja. To pomeni, da je treba posodobiti stare poslovne modele v lu�i sodobnih informacijskih tehnologij, ki podpirajo elektronsko poslovanje in na ta na�in maksimizirajo vrednost za stranke teh podjetij. Novi modeli elektronskega poslovanja morajo biti fleksibilni in usmerjeni proti kupcu. Tukaj se pojavi nujnost izgradnje novega poslovnega modela elektronskega poslovanja kot osnova za razvoj elektronske trgovine in elektronskega poslovanja. Ob tem lahko omenimo, da je e-poslovanje tudi bistveni element za razvoj nove ekomonije, saj omogo�a razvoj novih storitev in izdelkov z veliko vgrajenega znanja. Nova ekonomija (angl. digital economy) je definirana kot neko navidezno obmo�je, v katerem se odvija poslovanje, kjer se ustvarja in izmenjuje vrednost ter prihaja do transakcij. Transakcija v poslovnem smislu pomeni, da dve strani trgujeta med seboj s stvarmi, ki imajo vrednost.

6.1.1 Oblike elektronskega poslovanja Glede na odnose med poslovnimi subjekti so se v e-poslovanju oblikovale tri osnovne vrste poslovanja:

��%��!��$��%�)��

��

� Podjetje-podjetje (B2B): predstavlja najve�ji delež e-poslovanja in zajema vse povezave

med podjetji od vzpostavljene povezave med prodajalci in dobavitelji (naro�ila, pla�ila) in elektronskega ban�ništva.

� Podjetje-potrošnik (B2C): zajema podro�ja, ki temeljijo na poslovanju z uporabo spletnih strani (uporaba ban�nih storitev, nakupovanje, delo, izobraževanje,..).

� Javna in državna uprava – podjetja in posamezniki (e-vlada): lo�imo poslovanje s podjetji (npr. dav�ne napovedi, javna naro�ila) – A2B (Administration to Business) in poslovanje s prebivalci – A2C (Administration to Customer). To podro�je je zelo zahtevno, saj zahteva lokalni dostop do omenjenih storitev za vsakega prebivalca.

V resnici obstaja devet možnih kombinacij poslovanja med razli�nimi poslovnimi subjekti: � Javna uporava: A2A, A2B, A2C. � Podjetje: B2B, B2A, B2C. � Potrošnik: C2C, C2B, C2A.

6.1.2 Dinami�no elektronsko poslovanje Poslovni proces združbe je v okviru poslovanja neko povsem dolo�eno delovanje s katerim se združba ukvarja, ki ga lahko raz�lenimo na delne poslovne procese ali poslovne funkcije; pojem funkcije pa je opredeljen kot skupina strokovno sorodnih opravkov za neposredno opravljanje naloge združbe [81]. E-poslovanje postaja vedno bolj kompleksno, predvsem v smeri avtomatizacije dolo�enih poslovnih procesov in povezanih transakcij (obdelava in izvedba naro�il, logistika, oskrbovalne verige). To zahteva razli�ne interakcije med ra�unalniškimi sistemi, poslovnimi aplikacijami in programskimi komponentami. Podjetje IBM [74] je tako vrsto poslovanja ozna�ilo kot dinami�no e-poslovanje. To bazira na integraciji in uporabi skupne infrastrukture, ki jo nudijo odprti spletni standardi, za kar najbolj optimalno interakcijo med poslovnimi subjekti (B2B, B2C). Dinami�no e-poslovanje temelji na nekaterih osnovnih principih in priporo�ilih, kot so npr.: � integracija med programskimi viri naj bo rahlo povezana (angl. loosely coupled); � vmesniki za storitve naj bodo objavljeni in dostopni na univerzalen na�in; � komuniciranje preko sporo�il mora temeljiti na odprtih standardih; � pove�anje razpoložljivosti porazdeljenih programskih virov (komponent) naj bi izboljšalo

u�inkovitost poslovnih procesov; � ponovno uporabljive (reusable) programske komponente (CBSE – Component Based

Software Engineering) naj bi znižale stroške in pove�ale produktivnost za uporabnike storitev;

� programska oprema se lahko trži in obravnava kot storitev. Za upoštevanje naštetih principov mora obstajati ustrezna skupna arhitektura, ki je podprta z odprtimi standardi na svetovnem spletu (internetu). Dinami�no e-poslovanje postavlja v ospredje storitev kot osnovno enoto za interakcijo med poslovnimi subjekti. Odgovor za to naj bi bila storitveno usmerjena arhitektura (SOA – Service Oriented Architecture) [76], ki združuje tako tehnologijo, kot tudi poslovne in organizacijske prvine v zaokroženo celoto. Temelj predstavljajo spletne storitve, zelo velik poudarek pa je tudi na metodah za uvedbo, najboljši praksi za posamezna podro�ja, na�inih za opisovanje in modeliranje poslovnih procesov.

��%��!��$��%�)��

��

Avtor A. Sahai [71] poudarja pomembnost spletnih storitev, ki v smislu e-poslovanja predstavljajo množico dolo�enih poslovnih procesov. Posledi�no je zelo pomembno, da so poslovni procesi in spletne storitve nadzorovane v smislu zajemanja – merjenja ustreznih podatkov. Ti podatki služijo za izdelavo logi�nih modelov, ki so posledi�no osnova za razli�ne analize za vodstvene delavce in tudi merjenja v smislu zagotavljanja in kontrole ustrezne kakovosti storitev, ki je dolo�ena v pogodbi o kakovosti (SLA – Service Level Agreement). Pri zasnovi dobre infrastrukture e-poslovanja je vsekakor potrebno upoštevati navedene ugotovitve.

6.1.3 Storitveno usmerjena arhitektura (SOA) Razvoj programske opreme skozi posamezna obdobja je šel �ez ve� evolucijskih faz. Eno prvo uporabnih na�el pri programiranju je bilo ponovna uporaba že napisane programske kode - koncept modularnega programiranja (koda je razbita na funkcije, module). Zaradi težjega vzdrževanje se je kasneje pojavil koncept predmetno orientiranega razvoja programske opreme. Osnovno enoto prestavlja razred, ki defnira neko stanje in množico operacij. Višji nivo abstrakcije predstavlja komponentni razvoj programske opreme, katere glavna zna�ilnost je možnost ponovne uporabe in lažje vzdrževanje zaradi uporabe vnaprej predpisanih vmesnikov. Ta koncept razvoja je še vedno aktualen in se lahko dopolnjuje s starejšimi koncepti. Današnja programska oprema je v smislu e-poslovanja zelo kompleksna; predvsem so v ospredju vprašanja, ki se ti�ejo porazdeljenih aplikacij, integracije z obstoje�imi sistemi, razli�ne platforme, protokoli in naprave. Storitveno usmerjena arhitektura (SOA) [77] naj bi v ve�ji meri reševala omenjena vprašanja. Sicer pa koncept SOA ni nov, uporabljen je bil že v komponentnih tehnologijah, kot so npr. DCOM in CORBA. SOA v splošnem pomeni zbirko storitev, ki komunicirajo med seboj. Komunikacija lahko pomeni prenašanje enostavnih podatkov ali pa usklajevanje dveh ali ve� storitev, ki izvajajo neko aktivnost. Za razumevanje SOA je potrebno razumevanje dolo�enih pojmov, ki se pojavljajo znotraj konteksta SOA - to so storitev (angl. service), sporo�ilo (angl. message), dinami�no lociranje (angl. dynamic discovery) in spletne storitve (angl. web services) [77, 78]. 1. Storitev Storitev je kontekstu SOA izpostavljen del funkcionalnosti, ki vsebuje tri lastnosti: a) Vmesnik oz. pogodba do uporabe storitev, ki je neodvisna od platforme: odjemalec

lahko od kjerkoli, na poljubnem operacijskem sistemu (platformi) uporablja storitev. b) Storitev se lahko dinami�no locira in proži: obstaja nek skupni repozitorij (imenik,

register) storitev, ki omogo�a iskanje po razli�nih kriterijih. Odjemalec na podlagi poizvedbe najde množico storitev, ki ustrezajo njegovim kriterijem.

c) Storitev je samostojna – vzdržuje lastno stanje: vsaka zahteva za proženje (izvedbo)

storitve nosi svoje stanje, ki je potrebno, da se storitev izvede. To stanje obstaja samo v �asu izvajanja storitve in je neodvisno od stanja ali konteksta druge storitve.

2. Sporo�ilo Odjemalci storitve komunicirajo s ponudniki storitev preko sporo�il. Storitve imajo definiran vmesnik, ki je dejansko pogodba za komunikacijo s storitvijo. Vmesnik dolo�a obnašanje storitve ter obliko vhodnih in izhodnih sporo�il. Pomembna lastnost sporo�ila je, da je

��%��!��$��%�)��

��

neodvisno od platforme. Glede na zahteve je najustreznejša tehnologija za izvedbo sporo�il opisni jezik XML (glej poglavje 2.1) in povezane tehnologije (XSD, SOAP). Vmesnik do storitev pa predstavlja jezik WSDL (glej poglavje 2.6). 3. Dinami�no lociranje To je pomembnejši del SOA, ki omogo�a lociranje storitev glede na razli�ne kriterije in kategorije. Storitve dinami�nega lociranja nudijo repozitoriji (imeniki) storitev in igrajo vlogo posrednika med odjemalci in ponudniki storitev. Ponudniki registrirajo svoje storitve v imeniku, odjemalci pa izvajajo iskanje znotraj imenika storitev in pridejo do ponudnika. V svetu spletnih storitev je UDDI tehnologija, ki nudi dinami�no lociranje storitev (glej poglavje 2.7). Imeniki storitev znotraj SOA dolo�ajo ve� zna�ilnosti: � skalabilnost storitev (storitve se lahko dodajajo naknadno); � razdružuje odjemalce storitev od njihovih ponudnikov; � posodabljanje storitev; � iskanje storitev po razli�nih kategorijah in kriterijih; � odjemalci lahko poljubno izbirajo ponudnike storitev (niso vezani na dolo�enega

ponudnika). 4. Spletne storitve Spletne storitve so klju�na tehnologija znotraj SOA. Razlog je v tem, da so spletne storitve zgrajene na skladu odprtih standardov in platformno neodvisnih protokolov (HTTP, XML, UDDI, WSDL, SOAP). Ti protokoli izpolnjujejo klju�ne zahteve arhitekture SOA. Spletne storitve so lahko osnovno gradivo za porazdeljene aplikacije ali za množico medsebojno povezanih poslovnih procesov. Glede na podane definicije osnovnih pojmov v kontekstu SOA, je potrebno omeniti tudi katere so osnovne entitete in operacije, ki so vsebovane znotraj modela SOA. V grobem so entitete naslednje: � Ponudnik storitev (angl. service provider): ponuja vmesnik in storitve, ki izvajajo

dolo�eno množico poslovnih opravil (nalog). � Register storitev (angl. service registry): vsebuje opise storitev, ki jih nudi eden ali ve�

ponudnikov; vsaka storitev je uvrš�ena v ustrezno poslovno kategorijo ter opisana z dolo�enimi atributi. Za iskanje nudi dolo�ene iskalne mehanizme.

� Odjemalec storitev (angl. service consumer): preko iskalnega mehanizma znotraj registra storitev locira in proži storitve, ki nudijo rešitve za specifi�no poslovno podro�je.

Interakcija med omenjenimi entitetami poteka preko treh osnovnih operacij (slika 20): � Objavi (angl. publish): ponudnik storitev objavi svoje storitve znotraj registra storitev;

objava poteka preko specifikacije UDDI; � Najdi (angl. find): odjemalec storitev znotraj registra preko vmesnika UDDI najde

(locira) specifi�no storitev, ki je opisana z jezikom WSDL in vsebuje kon�no to�ko URI storitve na strani ponudnika;

� Poveži (angl. bind): odjemalec storitve se na podlagi najdenih informacij poveže na storitev in jo lahko neposredno proži.

��%��!��$��%�)��

�"

#��"�1�%�%��%��%$��%��!��#1�

Koncept SOA je nastal kot rezultat razli�nih predhodnih konceptov razvoja porazdeljene programske opreme za obvadovanje vse ve�je kompleksnoti, kar je znotraj (dinami�nega) e-poslovanja vse bolj aktualno. Poleg tega je preko koncepta SOA možna integracija razli�nih aplikacij na enostavnejši na�in kot v preteklosti, upošteva pa tudi podro�ja razpoložljivosti (angl. availability), zanesljivosti (angl. reliability) in skalabilnosti (angl. scalability). Lahko re�emo, da je SOA v vseh pogledih dobra izbira za arhitekturo skalabilnih programskih rešitev e-poslovanja [78]. Za dobro implementacijo koncepta SOA je nujno upoštevanje odprtih standardov in posledi�no nekaterih osnovnih tehnologij, ki so podrobneje opisane v za�etnih poglavjih (XML, SOAP, WSDL, UDDI). Ker so spletne storitve zgrajene na teh tehnologijah, so osnova koncepta SOA in posledi�no same ideje dinami�nega e-poslovanja.

REGISTER STORITEV

ODJEMALEC

STORITEV

PONUDNIK STORITEV

(nudi storitve) poveži (bind)

najdi (find) UDDI + WSDL

objavi (publish) UDDI + WSDL

opis storitve (WSDL, URI)

storitev (WSDL)

��%��!��

��

7. Poslovni modeli Vpeljavo koncepta SOA za e-poslovanje v podjetje obsega ve�je število poslovnih procesov, ki jih izvajajo zaposleni, lahko pa so avtomatizirani. Poslovni proces obsega množico aktivnosti, vsaka aktivnost je lahko izvedena ali izpostavljena kot dolo�ena operacija [71]. Poslovni proces je kot izrazna oblika delovanja združbe (podjetja) klju�en za ustvarjanje poslovnih u�inkov [81]. Za u�inkovito izvajanje poslovnih procesov pri e-poslovanju, je potrebno uporabiti ustrezne poslovne modele. Izbira poslovnih modelov ne obsega samo informacijske infrastrukture (tehnologije), ampak tudi samo organizacijsko strukturo podjetja kot so npr. spremembe delovnih nalog, razmerja med strankami/dobavitelji, na�ini trženja in prodaje poslovnih u�inkov. Obstaja ve� razli�nih definicij poslovnih modelov, vendar se razumevanje in usmerjenost od avtorja do avtorja razlikuje. V najbolj osnovnem pomenu je poslovni model na�in poslovanja s katerim združba (podjetje) lahko preživi in ustvarja dodano vrednost (dohodek) [73]. Dobro izhodiš�e za razumevanje poslovnih modelov je definicija študije P. Timmersa [64], ki pravi da je poslovni model: � zgradba (arhitektura) poslovnega sistema, storitve ali toka informacij, ki poleg opisa

samega poslovnega sistema vklju�uje tudi opredelitev udeležencev z opisom njihovih vlog;

� opis za klju�ne priložnosti oz. koristi za razli�ne poslovne udeležence; � opis virov, ki prinašajo dohodek (dodano vrednost).

Ta definicija poudarja kaj je potrebno raziskati za razvoj dobrega poslovnega modela – udeležence in njihove vloge, poleg tega pa je velik poudarek tudi na izdelkih oz. storitvah. Tukaj lahko potegnemo vzporednice s konceptom SOA, ki izpostavlja zelo podobne zna�ilnosti. Zanimivo definicijo poslovnega modela navaja vir [72] oz. [69], ki navaja, da mora model upoštevati slede�e vidike: � Inovacije: kakšno poslovanje, inovacije izdelkov/storitev podjetje ponuja na trgu. � Skrb za stranke: katere so ciljne stranke, kako jim ponuditi in prodati izdelke/storitve in

pridobiti njihovo zaupanje. � Upravljanje infrastrukture: kako u�inkovito podjetje izvaja infrastruturne in logisti�ne

vidike, s kom in na kakšen na�in (vrednostna veriga). � Finan�ni vidik: kakšen je dohodkovni model (transakcijski, naro�niški, oglaševalski,

provizijski,..) in stroškovni model (stroški poslovnih u�inkov, stroški raziskav in razvoja, stroški trženja in prodaje, splošni in administrativni stroški).

Poslovni model sam po sebi še ne zagotavlja kako bo prispeval k realizaciji poslovnih ciljev znotraj združbe, kjer je poslovni cilj “udeleženec” oz. ima dolo�eno vlogo znotraj modela. Vir [68] navaja, da se je pri definiciji poslovnih modelov potrebno osredoto�iti na konkretne vzpostavljene teorije. Ena izmed teh je sistemska dinamika, ki temelji na sistemski teoriji in omogo�a modeliranje kompleksnih poslovnih sistemov. Združba oz. podjetje se lahko pojmuje kot samostojen družbeni sistem, ki je vpet v okolje in odvisen od izmenjave informacij. Poslovni model kot pojem pomeni samo abstraktno predstavitev poslovanja v realnosti. Poslovni model ne predstavlja opisa kompleksnega družbenega sistema z vsemi njegovimi

��%��!��

��

udeleženci, razmerji in procesi, temve� podaja opis temeljne logike poslovnega sistema za ustvarjanje dodane vrednosti (dohodka), ki obstaja v konkretnih procesih. Poslovni model lahko razumemo tudi kot vmesni �len med strategijo in poslovnimi procesi. Strategija dolo�a pozicijo podjetja, definira in formulira namene in cilje, medtem ko poslovni procesi izvajajo in izpolnjujejo smernice strategije. Slika 21 predstavlja poslovni model kot konceptualno in arhitekturno izvedbo (implementacijo) poslovne strategije, ki predstavlja osnovo za izvedbo poslovnih procesov in informacijskih sistemov [68, 69]. Strategijo uresni�uje poslovni model, ki sloni na razli�nih poslovnih procesih in dolo�a kako so ti procesi izvedeni. Poslovni procesi so neposredno povezani in odvisni od spodaj leže�e informacijske-komunikacijske infrastrukture (ICT – Information and Communication Technology). Velja poudariti, da lahko dolo�eni poslovni modeli pridejo do izraza šele z uporabo ustrezne sodobne informacijske tehnologije. Spremembe na višjem nivoju piramide (najbolj vpliva na poslovanje) izrazito vplivajo na vse nižje nivoje. Poslovni model je lahko uspešen samo v primeru, da so poslovni procesi ustrezno podprti z operativnim nivojem ICT.

#��7��)�(%��'��'��$��%��*��

7.1 Relacija med tehnologijo in dodano vrednostjo Za ustvarjanje dodane vrednosti preko tehnologije mora obstajati ustrezen mehanizem. Ta mehanizem je nedvomno poslovni model z opisom zgradbe – arhitekture, ki pove na kakšen na�in in katere poslovne u�inke izdelovati oz. ponujati, da z njimi podjetje ustvarja dodano vrednost. Vir [63] poudarja, da dober poslovni model povezuje potenciale tehnologije z realizacijo ekonomske dodane vrednosti. Poslovni model dolo�a skladen dinami�en mehanizem, ki preko procesa transformacije pretvarja vhod (zna�ilnosti in potenciali tehnologije) v izhod (dodana vrednost) s pomo�jo strank (kupcev) in trgov. �eprav se ne omenja veliko, je ta mehanizem odvisen tudi od same organizacijske strukture in operativne infrastrukture znotraj podjetja. Poslovni model je torej vmesni �len med razvojem tehnologije in ustvarjanjem dodane vrednosti. Pri prou�evanju se je potrebno osredoto�iti na [63]: a) Razlo�iti vrednost, ki jo nudi (vsebuje) nova tehnologija Na za�etku procesa je potrebno dolo�iti kakšne poslovne u�inke (izdelke, storitve) ponuditi na trg ter kakšne stranke (kupci) jih bodo uporabljali. Poslovni model mora za podani predlog

.%/��%��'%��2.<84

��%�$��

��%��!��

#��*��W�(��%��

��)��'�%�%��

.��!��%�%��

1$��%�A�%/��'��'�%�%��

0$��%��$��%��

��%��!��

��

specificirati skupino strank ali tržni segment ter vire za ustvarjanje poslovnih u�inkov. Vrednost uporabljene tehnologije se lahko kaže v zmožnosti zmanjšanja stroškov ter zmožnosti za nove poslovne u�inke in rešitve, ki jih je stranka pripravljena pla�ati. Omeniti je potrebno tudi t.i. tehni�no negotovost, ki je odvisna od same tehnologije (predvsem zrelost in nivo razumevanja njenih zna�ilnosti) ter od zunanjega trga. b) Identificirati tržni segment Gre za dolo�itev skupine uporabnikov (kupcev), za katere je tehnologija uporabna in kakšen je njen namen oz. katere njene zna�ilnosti uporabiti. Glede na to je potrebno dolo�iti mehanizme za generiranje dodane vrednosti (dohodka) znotraj podjetja. Gre za t.i. sestavo dohodkov: na�in kako bodo kupci lahko pla�evali, prodajne cene, na�in oz. razmerje kako ustvarjeno dodano vrednost razdeliti med kupce, podjetje in dobavitelje. Obstaja ve� razli�nih opcij oz. poslovnih modelov: najem, zara�unavanje transakcij, oglaševanje, naro�niški model. c) Definirati strukturo vrednostne verige (angl. value chain) Gre za definiranje elementov vrednostne verige v podjetju: od izdelave poslovnih u�inkov, do njihove razpe�ave; preko vsakega elementa verige naj bi se praviloma ustvarila neka dodana vrednost. Pri ustvarjanju dodane vrednosti se vrednostna veriga lahko razširi v vrednostno mrežo (angl. value network), katere del so zunanji poslovni subjekti: dobavitelji, stranke, tretje stranke (angl. third party). Vrednostna veriga (mreža) igra pomembno vlogo pri zajemanju dodane vrednosti od inovacije poslovnih u�inkov, pa do njihove komercializacije. Vir [64] podaja pristop kako dolo�iti arhitekturo poslovnih modelov preko razbijanja in sestavljanja vrednostnih verig, kjer se identificirajo elementi znotraj verige in na�ini integracije informacij. Princip je slede�: � Razbijanje vrednostne verige: identificirajo se elementi, vir [64] jih razlikuje devet

(primarni elementi): vhodna logistika, operativa, izhodna logistika, trženje in prodaja, storitve, tehnološki razvoj, nabava, upravljanje s �loveškimi viri, infrastruktura.

� Vzorci interakcij med elementi: ti so lahko v razmerju 1-1, 1-mnogo, mnogo-1 ter mnogo-mnogo. V kontekstu ti vzorci pomenijo število razli�nih udeležencev (subjektov), ki so v medsebojnem razmerju (interakciji).

� Sestavljanje vrednostne verige: gre za razli�ne kombinacije integracij elementov, ki so v interakciji v razli�nih vzorcih.

d) Oceniti strukturo stroškov in možnosti za dobi�ek Glede vrednosti, ki jo nudi tehnologija, izbranega tržnega segmenta in vrednostne verige je potrebno oceniti velikost stroškov. Velja, da ima splošni trg veliko konkurenco, zato so stroški veliki, obenem pa nudi ve�jo odprtost pri izboru tehnologije. Osredoto�enje na ciljni trg zoži možnost uporabe tehnologije in s tem posledi�no stroškov. e) Dolo�iti pozicijo podjetja (združbe) znotraj vrednostne mreže Gre za dolo�itev mesta podjetja znotraj mreže v povezavi z dobavitevlji in strankami, obenem pa tudi za identifikacijo morebitnih konkurentov. f) Oblikovanje strategije podjetja Potrebna je strategija, ki bo podjetje držalo v prednosti pred morebitno konkurenco. Glede na opisane zna�ilnosti poslovni model preslikuje vložke (angl. inputs) znotraj tehni�ne domene v u�inke (angl. outputs) znotraj ekonomske domene (slika 22).

��%��!��

��

#��%��!��$��!%��!��)%�(%�%��%��!��%

Za dobro definicijo poslovnega modela je nujno, da se vodstveni delavci zavedajo povezave tehni�ne in ekonomske domene, ki sta praviloma v stanju velike tehni�ne in tržne negotovosti. Zaradi kompleksnosti in obsežnosti obeh domen, je skoraj nujno, da so v podjetju zaposleni lo�eni strokovnjaki za vsako domeno.

7.2 Vrste poslovnih modelov Poslovni modeli, ki so nastali ob novem na�inu poslovanja, so raznovrstni: nekateri so enostavni, drugi bolj kompleksni. Podjetje lahko poslovne modele medsebojno tudi kombinira kot del svoje poslovne strategije. Njihova identifikacija in razvrstitev nista enostavni. Tudi klasifikacija, o kateri bo govora v nadaljevanju, ni enotna. Vsak avtor navaja svojo, med seboj se precej razlikujejo in so težko združljive. Vir [85] razvrš�a poslovne modele tako, kot je prikazano na sliki 23.

'� ��+��%��5,�2�%$'��4&

��S%��*��%��

,��,��+��,�2'�$'��4&

��!%��%��!��(��

��%�� 6

��!%��)%�*��S%��*��%��!%��%��*�� %!��(��!%��%��S��*��

Merjeno v tehni�ni domeni Merjeno v ekonomski domeni

��%��!��

��

#��,S%��$��%�)�!��

Avtor M. Rappa [73, 65] navaja naslednje skupine poslovnih modelov: 1. Posredniški model (Brokerage Model) Posredniki so ustvarjalci trgov, ki pripeljejo kupce in prodajalce skupaj ter podprejo in olajšajo izvršitev kup�ij (transakcij). Na ta na�in ustvarjeni trgi so lahko takšni, da se tu sre�ujejo razli�ni poslovni subjekti: podjetje s podjetjem (B2B), podjetje s potrošnikom (B2C) ali potrošnik s potrošnikom (C2C). Posrednik ustvari svoj zaslužek z zara�unavanjem provizije od vsake transakcije, ki jo omogo�i. Obstaja ve� tipov posrednikov (za kupce, prodajalce, interesne skupine), opravljajo pa razli�ne funkcije (združevanje potreb in storitev, mehanizem za ponudbe in povpraševanja). Njihova glavna naloga je zmanjševanje stroškov tako na strani kupca kot prodajalca. Posredniški model lahko zavzema veliko število razli�nih oblik, nekatere izmed njih so: a) Borza ponudbe in povpraševanja Deluje na razli�nih podro�jih storitev, ki nudijo transakcijske procese. Primer je finan�no borzno posredništvo, kjer stranke oddajajo nakupna in prodajna naro�ila za nakup oz. prodajo vrednostnih papirjev. Posrednik zara�una prodajalcu ali kupcu provizijo za opravljene transakcije. Drugi primeri so še posredniki pri razli�nih transakcijah: nakup letalskih vozovnic, rezervacije hotelov, informacije o prevozih, potovalne ponudbe “last minute”,.. b) Iskalni agent Programska oprema (agent, “robot”), ki po svetovnem spletu iš�e najugodnejšo ceno za to�no dolo�eno blago ali storitev, ki si jo je izbral kupec, ali pa iš�e izdelek, ki ga je težko najti. Podoben primer predstavlja tudi agencija za iskanje zaposlitev, ki lahko deluje kot iskalni agent. Posrednik zara�una storitev iskanja iskalcu, kot tudi “najugodnejšemu” ponudniku.

��7��+,�6� �� W��'$��%�$��!%�� %'!%��%��%��%�)��2.#�4

Menjava na spletu (online exchange):

� Dražbe � Ustvarjalci trgov � Finan�ne menjave

'�� *�7%�� )��,��*��

��!��"� ;��*�%��%��$��!�

'&�%��!�� "� #$��%��*��%�� W�$��!%�$�!��%$��!�$!��

�� ,��*�#�*��

%��#��)��,�� )��*��

!��8��%� ��"

Ve� trgov

En trg

Osredoto�enost na vsebino in skupnost Osredoto�enost na transakcije

��%��!��

��

c) Elektronska dražba Elektronski mehanizmi dražbe omogo�ajo izvajanje dražb prek svetovnega spleta za posameznike ali trgovce. Dohodek prireditelja dražbe izvira iz obra�unavanja transakcijskih pristojbin in oglaševanja. Nižji stroški omogo�ajo ponudbo manjših koli�in ter nižje vrednosti. Dodatna korist za dobavitelja je v nižjih stroških prodaje, za kupca pa v nižjih splošnih stroških nakupov in nižjih cenah za kupljeno blago ali storitev. d) Model za distributerje Model deluje kot katalog, ki povezuje veliko število proizvajalcev z grosisti in trgovci na drobno. Obi�ajno so to modeli tipa podjetje–podjetje (B2B). Posrednik podpre sklepanje kup�ij (transakcij) med prodajalci in njihovimi poslovnimi partnerji. Kupcem omogo�a prihranek �asa pri nakupih, znižuje pa tudi stroške nabave. e) Elektronski trgovski center Elektronski trgovski center združuje ve� spletnih trgovin pod skupnim okvirom – znano blagovno znamko in ima obi�ajno skupni na�in elektronskega pla�evanja. Dohodki krovnega gostitelja elektronskega trgovskega centra izvirajo iz �lanarine, oglaševanja in pristojbin za transakcije, �e trgovski center obdeluje tudi naro�ila oziroma zagotavlja transakcije pla�ilnega sistema trgovin. 2. Model reklam Je razširitev obstoje�ih tradicionalnih reklamnih modelov, ki predvaja reklamo, v tem primeru je to spletna stran, ki daje na razpolago vsebino, do katere je dostop obi�ajno, ne pa vedno, zastonj. Poleg vsebine lahko ponudi tudi storitve, kot na primer elektronsko pošto ali klepetalnico. Reklamiranje je lahko glavni ali pa edini vir dohodka. Ponudnik spletne strani je lahko njen avtor ali pa samo predvaja vsebino, ki je bila narejena drugje. Obstaja ve� razli�ic reklamnega modela: a) Portal Je spletna stran, ki mora zagotavljati splošno in raznoliko vsebino; to so ponavadi iskalniki ali imeniki. Model dobro deluje le pri visokem številu obiskov, kar omogo�a dobi�konosno reklamiranje. b) Pla�ilo za pozornost Ta model pla�uje obiskovalcem za gledanje vsebine in izpolnjevanje obrazcev. Tak tržni pristop vzbujanja pozornosti je najbolj privla�en za podjetja, ki želijo imeti dokaj kompleksna reklamna sporo�ila, ki sicer ne bi pritegnila potrošnikovega zanimanja. c) Brepla�ni model Ta model ponuja uporabnikom dolo�eno storitev brezpla�no, na primer dostop do svetovnega spleta, elektronske voš�ilnice, postavitev in vzdrževanje spletne strani. Takšni modeli, angleško imenovani Freebies, zagotavljajo visoko obiskanost spletnih strani, kar daje podjetjem priložnost reklamiranja. 3. Ponudnik informacij Gre za ponudnika, ki zbira podatke o potrošnikih in njihovih nakupovalnih navadah. To so ponavadi dragocene informacije, še posebno, �e so ustrezno analizirane in urejene. Nekatera podjetja so zmožna delovati, tako da zbirajo in nato prodajajo informacije ostalim podjetjem.

��%��!��

��

4. Elektronska trgovina Elektronska trgovina je trgovsko podjetje, ki ustvarja vrednost s trgovanjem z uporabo obstoje�ih in novih digitalnih tržnih kanalov. Lahko jih razumemo kot spletne vzporednice tradicionalnim na�inom prodaje proizvodov, storitev in informacij. Podjetje pridobiva dohodek z maržami od prodaje in oglaševanja. Prodaja lahko temelji na dražbi ali na klasi�nem na�inu prodaje; v nekaterih primerih gre lahko le za spletno prodajo izdelkov in storitev brez vzporednic s klasi�no prodajo. Koristi, ki jih imajo potrošniki, so predvsem nižje cene, udobnost izbiranja, kupovanja in dostave. To vrsto poslovanja uvrš�amo med skupino B2C. Obstaja ve� tipov elektronske trgovine: a) Virtualni trgovec Deluje samo prek svetovnega spleta in ponuja blago ali storitve, ki so tradicionalne ali pa zna�ilne samo za splet. b) Kataloška prodaja Zanjo je zna�ilen prehod od naro�anja prek elektronske pošte k naro�anju s pomo�jo spletnih strani. Spletni katalog zagotavlja boljše informacije o izdelku, pooseblja in s tem krepi stik s kupci, na voljo je 24 ur na dan, zagotavlja izdelke po ugodnejših cenah in skrajšuje �as za obdelavo naro�ila. c) Klasi�na in elektronska trgovina Pri tej vrsti poteka oboje: klasi�na zidana trgovina in spletna trgovina. Pri tem modelu obstaja verjetnost za konflikt znotraj distribucijskega kanala. d) Bitni trgovec (Bit Vendor) To je trgovec, ki se ukvarja izklju�no z digitalnimi proizvodi in storitvami ter v svoji naj�istejši obliki vodi prodajo in distribucijo prek svetovnega spleta. 5. Model proizvajalca Ta model temelji na možnosti, ki jo ponuja svetovni splet, da proizvajalci dosežejo kupce neposredno in tako skrajšajo distribucijski kanal (odstranitev posrednikov, veletrgovcev in trgovcev na drobno, kjer je to mogo�e). Na ta na�in prihranjeni stroški se lahko (ali pa tudi ne) prenesejo na kupce. Obstajajo slede�e razli�ice tega modela: a) Nakupni model Proizvajalec prodaja izdelke ali storitve neposredno potrošniku, brez vmesnih kanalov. b) Najemniški model V zameno za dolo�en znesek najemnine ima potrošnik pravico do uporabe izdelkov in/ali storitev proizvajalca, ki je dolo�ena v najemniških pogojih (pogodbi). Po preteku pogodbe se izdelki, �e ni dolo�eno druga�e, praviloma vrnejo proizvajalcu. Lep primer tega modela predstavlja podjetje Xerox za primer njihovega kopirnega stroja Model 914 [63]. c) Model licenciranja Proizvajalec proda potrošniku pravico do uporabe izdelkov ali storitev, pravice lastništva pa še vedno nosi proizvajalec. Ta model je pogost v podjetjih, ki proizvajajo programsko opremo in jo lahko dajo na uporabo preko licence.

��%��!��

��

6. Model mreže partnerstev V nasprotju s portalom, ki ima cilj �im ve�je število obiskovalcev, ta model daje možnost nakupa na ve� partnerskih spletnih straneh tako, da finan�no stimulira (v obliki odstotka od prodaje) partnerja, ki ima svojo spletno stran. Pridruženi partnerji imajo na svoji spletni strani ikono, ki obiskovalce s klikom poveže z želenim trgovcem. Ta model je za spletne strani zelo prikladen in je na svetovnem spletu zelo popularen. Obstaja ve� razli�ic: a) Izmenjava reklamnih pasic Pridruženi partnerji imajo na svojih straneh reklamne pasice dolo�enega trgovca, ki je njihov partner. Z vsako reklamno pasico partner zasluži dolo�en znesek. b) Pla�ilo na klik oz. obisk (Pay-per-Click) Za vsak obisk/klik ciljne spletne strani, lastnik le-te pla�a dolo�en znesek pridruženemu partnerju. c) Delitev deleža od prodaje Trgovec nudi pridruženemu partnerju dolo�en delež (provizijo) od vrednosti prodaje za vsak klik kupca na spletni strani partnerja. 7. Javni model Ta model temelji na zvestobi in predanosti njegovih uporabnikov. Je nasprotje z modelom, ki za uspešno delovanje zahtevajo veliko število uporabnikov. Uporabniki spletne strani za uspešno delovanje posve�ajo veliko �asa in predanosti. Vrednost se ustvarja s prodajo izdelkov, prostovoljnimi prispevki in reklamiranjem. Obstaja ve� razli�ic: a) Model odprte kode Zajema izdelavo programske opreme na prostovoljni (neprofitni) osnovi, kjer sodeluje globalna skupnost razvijalcev in si med seboj delijo kodo in izkušnje. Namesto licenciranja kode, se prihodek ustvarja s povezanimi storitvami kot so priro�niki, uporabniška dokumentacija, podpora, sistemske integracije. b) Model prostovoljnih prispevkov Temelji na skupini uporabnikov, ki podpirajo spletno stran s prostovoljnimi prispevki ali iš�ejo finan�no pomo� pri organizacijah, ki podpirajo cilje in poslanstvo te skupine uporabnikov. c) Mreže znanja To so ekspertne spletne strani zasnovane v obliki foruma. Zagotavljajo vir znanja in informacij, ki temelji na poklicnem strokovnem znanju ali izkušnjah drugih uporabnikov. 8. Naro�niški model V tem modelu se uporabnikom za dostop do spletne strani in njenih vsebin zara�una naro�nina, ki je lahko dnevna, mese�na, letna oz. je dolo�ena v naro�niški pogodbi med ponudnikom in uporabnikom. Visoka vrednost vsebine oz. storitev na spletni strani je za ta model nujno potrebna. V nekaterih primerih gre lahko za kombinacijo brezpla�ne vsebine in storitev, ki na spletne strani pritegne dolo�eno število uporabnikov, ter vsebine katere je potrebno pla�ati. Obstaja ve� razli�ic:

��%��!��

��

a) Storitve za vsebine Nudijo razli�ne vrste vsebin kot so besedila, avdio/video vsebine za uporabnike, ki za njih pla�ujejo naro�nino. b) Ponudniki (spletnih) storitev Za naro�nino (mese�no, letno) nudijo dostop do omrežja ter povezanih in dodatnih storitev, ki pa jih lahko obra�unavajo razli�no. 9. Uslužnostni (utility) model Ta model temelji na merjenju porabe in posledi�no pla�ilu za izmerjeno koli�ino porabe. V nasprotju z naro�niškim modelom, kjer se pla�uje za dolo�eno obdobje, se v tem modelu pla�uje glede na dejansko porabo vsebine oz. storitev. Enote porabe so razli�ne, npr. minute, koli�ina podatkov, število transakcij,.. V okviru uslužnostnega modela se pojavlja tudi pojem uslužnostnega ra�unalništva (angl. Utility Computing), ki pomeni dostavo ustrezne infrastrukture, aplikacij in poslovnih procesov na zahtevo v varnem, porazdeljenem in skalabilnem ra�unalniškem okolju preko uporabe svetovnega spleta [65]. Obstajata dve razli�ici uslužnostnega modela: a) Merjena poraba Gre za merjenje porabe in posledi�no zara�unavanje za izmerjeno porabo storitev. b) Merjena naro�nina Naro�niki lahko kupijo dostop do storitev in vsebine v merljivih enotah (npr. število minut, število prenešenih strani,..). Za informativno primerjavo pa avtor P. Timmers v študiji Evropske unije [64] navaja slede�e poslovne modele: � elektronska trgovina, � elektronska nabava, � elektronska dražba, � elektronska pošta, � storitve tretje stranke v poslovanju, � virtualne skupnosti, � ponudnik storitev v vrednostni verigi, � povezovalec v vrednostni verigi, � platforma za sodelovanje, � posredovanje informacij, storitve zagotavljanja zaupanja in druge storitve. Nekatere od naštetih vrst lahko uvrstimo v skupine poslovnih modelov, ki jih je navedel avtor M. Rappa [73]. Hkrati se poslovni modeli na svetovnem spletu tudi hitro spreminjajo in razvijajo, saj elektronsko trgovanje in elektronsko poslovanje omogo�ata nastajanje novih uspešnih poslovnih modelov, ki se uveljavljajo s pomo�jo podjetniške inovativnosti, prilagodljivosti, dobre izbire partnerjev ter dobro izpeljano poslovno strategijo. Tako lahko v prihodnosti pri�akujemo nove zanimive variacije. Dovršeni poslovni modeli, zlasti v elektronskem trgovanju, se lahko smatrajo kot intelektualna lastnina, ki je zavarovana s patentom. V našem primeru arhitekture SOA za kontrolo dostopa spletnih storitev pridejo v poštev predvsem poslovni modeli, ki temeljijo na transakcijah in merjenju.

��%��!��

�"

7.3 Klasifikacija poslovnih modelov Predstavljene modele elektronskega poslovanja v prejšnji to�ki lahko razvrstimo glede na razli�ne kriterije oz. dimenzije. Izbrani kriteriji prikazujejo, v kolikšni meri je podjetje usmerjeno k elektronskem poslovanju in katere vrste potreb trga oziroma poslovanja podpira na elektronski na�in. Razli�ni avtorji [70, 69, 68, 72, 64, 86] podajajo razli�ne dimenzije (ve�inoma nastopajo v parih) za klasifikacijo modelov; ve�ina jih predlaga dimenziji: funkcija integracije in stopnja inovacije. Nekateri predlagajo tudi dimenzije kot so: ekonomska kontrola (hierarhi�no in samoorganizacijsko) in integracija vrednosti, mo� prodajalcev in kupcev ter bolj splošni dimenziji cilj in namen. Avtor P. Timmers [64] razvrš�a poslovne modele med dve dimenziji: � Stopnja inovacije: ta se razteza od tradicionalnega na�ina poslovanja, ki je elektronsko

podprt, do bolj inovativnih na�inov, kot so npr. najem zunanjih izvajalcev (angl. outsorcing) za izvajanje dolo�enih funkcij preko svetovnega spleta, ki jih je pred tem podjetje opravljajo sámo ali za opravljanje funkcij, ki pred tem še niso obstajale.

� Funkcija integracije: razvrš�a modele po številu funkcij, ki jih vklju�ujejo in povezujejo,

od modelov z eno samo funkcijo (npr. e-trgovine), do modelov, ki vsebujejo ve� funkcij (npr. integracija vrednostne verige).

Slika 24 prikazuje okvirno klasifikacijo nekaterih predstavljenih poslovnih modelov. V spodnjem levem kotu je osnovna e-trgovina, ki je samo elektronska razli�ica tradicionalnega na�ina prodaje. Stopnja inovacije je nizka, gre samo za eno funkcijo – funkcijo trženja prek svetovnega spleta. Sicer že funkcija elektronskega trženja prinaša marsikatere koristi tako za kupce (ugodnost, informacije, ve�ja udobnost in manj vznemirjenja) kot prodajalce (hitrejše prilagajanje tržnim pogojem, nižji stroški, razvijanje odnosov, zajemanje uporabnikov) [79]. Elektronska trgovina je le ena od možnih elektronskih tržnih poti. Druga skrajnost na sliki 24 je na desnem zgornjem kotu. Modeli, ki se uvrš�ajo v to podro�je, v tradicionalni obliki težko obstajajo ali pa jih sploh ni. Mo�no so odvisni od informacijske tehnologije, ki je osnova za pretok informacij in posledi�no ustvarjanja dodane vrednosti na osnovi integracije informacijskih tokov.

#��,S%��/��$��%�)�!��

�A��*��%�

�A��*��%��

�A!��S��

��'��%��'$%��

��$%'!��$�$�� %��

�%��*��!%��%��*�

Stopnja inovacije

funk

cija

inte

grac

ije

��%��!��

��

Vir [69] navaja, da novejši avtorji �lenijo poslovne modele na njihove atomarne elemente. Vir [68] dolo�a šest splošnih elementov: � poslanstvo (angl. mission): cilji, vizija, strategija, predlogi za ustvarjanje vrednosti; � struktura (angl. structure): poslovni udeleženci in vodstvo; � procesi (angl. processes): osredoto�enost na stranke, mehanizmi koordinacije; � dohodki (angl. revenues): viri dohodkov, poslovna logika oz. inteligenca; � pravna sredstva (angl. legal issues); � tehnologija: predvsem IT. Z okvirnim upoštevanjem naštetih elementov je možno poslovni model razdeliti na sedem pod-modelov [68]: vrednostni model, model virov, produkcijski model, modela odnosa s strankami (distribucijski, prodajni in storitveni podmodel), prihodkovni model, model kapitala in tržni model. Vsi ti podmodeli so v medsebojni interakciji in kot celota tvorijo poslovni sistem. Za gradnjo poslovnih modelov obstaja veliko študij, teorij in metodologij. Vsem je skupno, da podajajo dolo�ene smernice katerih se je potrebno držati pri gradnji dobrega poslovnega modela. Gre za t.i. ontologijo poslovnih modelov (angl. Business Model Ontology), ki pomeni konceptualizacijo in formalizacijo atomarnih elementov, relacij, strokovnega besednjaka in semantike znotraj domene poslovnega modela. Ena izmed študij [69] predvideva štiri glavne elemente (nosilce), ki so v tesnem medsebojnem razmerju in se delijo na manjše enote. Glavni elementi so (bolj podrobno v [69]): � inovacije izdelkov in storitev (angl. product inovation); � upravljanje odnosov s strankami (angl. customer relationship); � upravljanje z infrastruktro (angl. infrastructure management); � finan�ni vidiki (angl. financials). V našem primeru uporabe oz. vpeljave arhitekture SOA (preko spletnih storitev) v podjetje, je najbolj zanimiv element “inovacije izdelkov in storitev” (SOA dejansko pomeni “inovacijo” in nov pogled na poslovanje), je sestavljen iz slede�ih elementov: a) Predlog za ustvarjanje vrednosti (angl. Value Proposition): nanaša se na vrednost, ki jo

lahko podjetje nudi dolo�eni skupini uporabnikov, ker zadovoljuje njihove potrebe. Arhitektura SOA nudi precej priložnosti za ustvarjanje vrednosti tako za podjetje, kot uporabnike (npr. nudenje razli�nih storitev na osnovi razli�nih poslovnih modelov).

b) Ciljni uporabnik (angl. Target Customer): definicija obsega uporabnikov oz. trga, ki je

zanimiv za podjetje oz. predstavlja tržno nišo. c) Zmožnosti (angl. Capabilites): za predstavitev vrednostnih predlogov uporabnikom, mora

podjetje uporabiti razli�ne vzvode oz. možnosti (ponavljajo�i vzorci akcij za nudenje izdelkov in storitev na trg).

7.4 Vpeljava poslovnih modelov za e-poslovanje Vpeljava ustreznega poslovnega modela za ustvarjanje nove dodane vrednosti in posledi�no specifi�ne informacijske tehnologije (v našem primeru koncept SOA), vpliva na razli�ne dejavnike poslovanja v podjetju. Vir [70] navaja, da vpeljava novih poslovnih modelov vpliva na slede�e vidike:

��%��!��

��

a) Organizacijski Pri razvoju novih izdelkov, storitev ali prenovitvi poslovanja, se vedno premalo poudarja vpliv napora zaposlenih na samo organizacijsko strukturo. Ta se kaže v spremembah narave in strukture dela znotraj in med organizacijskimi stopnjami. Lahko pride tudi do oblikovanja novih formalnih razmerij med zaposlenimi, partnerji in zunanjimi izvajalci. b) Socialni Novi poslovni modeli vodijo do novih delovnih praks in vplivajo na samo delo in zaposlovanje. Vedno je potrebno analizirati, kakšne nove izkušnje in sposobnosti so potrebne za izvajanje poslovnega modela. Glede na potrebe je potrebno zaposliti nov strokovni kader (angl. knowledge workers). Predvsem na podro�ju vpeljave modelov za e-poslovanje je potrebno intenzivno izobraževanje zaposlenih in dose�i ravnovesje med delovno prakso in poslovno uspešnostjo. c) Osebni Vpeljava novega poslovnega modela je kompleksna odlo�itev, ki vpliva tako na stranke, kot na zaposlene. Odlo�itev ni odvisna samo od racionalnosti, ampak je tudi u�inek interakcije razli�nih posledic vrednotenj, ki bi nastale z uporabo novega poslovnega modela. Razlike v razumevanju vrednotenja se kažejo med uporabniki, ki pripadajo razli�nim socialno-demografskim skupinam, kulturi in osebnim zna�ajem. d) Tehni�ni Hiter napredek informacijskih in komunikacijskih tehnologij omogo�a bistveno hitrejše uvajanje/sprejetje poslovnih modelov za e-poslovanje. Informacijska tehnologija omogo�a dodatne zmožnosti kot npr. dodatni distribucijski in dobavni kanali, sodelovanje v navideznih trgovskih skupnostih, razširitev klasi�ne vrednostne verige v vrednostne mreže. V splošnem gre za lažje dinami�no lokacijo, uporabo virov in storitev znotraj porazdeljenega poslovnega okolja. V splošnem mora biti vpeljava novega poslovnega modela in posledi�no podporne informacijske tehnologije opravi�ljiva. V primeru, da nova tehnologija ne bo prinašala nove vrednosti, njena vpeljava ni smiselna. Nasprotno pa inovativna uporaba IT v organizaciji vodi do izboljšane, koordinacijsko intenzivne organizacijske strukture, ki omogo�a koordinacijo aktivnosti na na�in, ki prej sploh ni bil možen. To pa omogo�a dvig organizacijskih sposobnosti in odzivnosti, kar posledi�no vodi do strateških prednosti. Okvirno gledano lahko v našem primeru vpeljave nekaterih poslovnih modelov preko koncepta SOA (t.i. spletnih storitev) lo�imo dve kategorije upravi�enosti, ki so povezane z vpeljavo nove tehnologije [75]. Prva kategorija ni nujno vedno povezana z ustvarjanjem nove dodane vrednosti, je pa pomembna za rast in preživetje podjetja: � racionalizacija poslovanja preko pove�anja operativne u�inkovitosti skozi nove

komunikacijske kanale in posledi�no znižanjem operativnih stroškov; � krajšanje oskrbovalnih verig (angl. supply chain) zaradi nove možnosti, da poslovni

partnerji lahko direktno dostopajo do notranjih poslovnih procesov v podjetju; � skrajšanjše �asa za ponudbo novih izdelkov in storitev na trgu; � iskanje novih prodajnih in tržnih kanalov. Druga kategorija je povezana z ustvarjanjem nove dodane vrednosti v podjetju, ki se kaže predvsem na: � pridobivanje novih strank;

��%��!��

��

� razširitev obstoje�ih odnosov s poslovnimi partnerji in pridobivanje novih; � usmerjanje obstoje�e ponudbe izdelkov in storitev na nove kanale. Ta kategorija je v smislu storitveno usmerjenega podjetja povezana z eno od klju�nih vlog (entitet) koncepta SOA (glej poglavje 6.1.3) – ponudnikom storitev (service provider), ki ponuja vmesnik in storitve, ki izvajajo dolo�eno množico poslovnih opravil (nalog). Izvajanje storitev pomeni poslovanje v ekonomskem smislu. Ta vloga je tudi izhodiš�e za naš primer zasnove sistema za vrednotenje – obra�un spletnih storitev, ki so v domeni posrednika. Ostale entitete, ki nastopajo v miselnem modelu SOA, so še register storitev (vsebuje opise storitev) in odjemalec (uporabnik) storitev, ki predstavlja stranko. Vrednost, ki se ustvarja, je obojestranska: storitve zadovoljijo potrebe uporabnika, ta pa je v zameno pripravljen pla�ati posredniku storitev (podjetju). Posrednik storitev mora upoštevati katerega od obstoje�ih poslovnih modelov, lahko pa dolo�i tudi svojega lastnega. V našem primeru se bomo osredoto�ili na bolj splošne poslovne modele, ki pa jih najdemo v razli�nih specifi�nih modelih, opisanih v poglavju 7.2. Posplošeni modeli so naslednji: a) Transakcijski model: temelji na zara�unavanju vsake transakcije (storitev predstavlja

transakcijo), ki je bodisi enostavna (npr. klik na spletni strani) ali kompleksna (npr. prenos gotovine med dvema ban�nima ra�unoma). Obstajati mora poslovna relacija med dvema entitetama - ponudnikom in odjemalcem storitev. Ponudnik mora definirati dogovor, kako bo vrednotil dostop do storitev, se katerim se mora strinjati tudi odjemalec storitve. Ena od možnosti je beleženja vsakega dostopa do storitve (transakcije) in posledi�no zara�unavanje le-tega na neko periodi�no obdobje. Druga možnost je pla�ilo pred uporabo storitve (npr. preko kreditne kartice). Transakcijski model je osnova specifi�nim modelom (glej poglavje 7.2): posredniški model (borza ponudbe in povpraševanja, elektronska dražba, model za distributerje, elektronski trgovski center), elektronska trgovina, model mreže partnerstev (pla�ilo na klik), uslužnostni model (merjena poraba, merjena naro�nina).

b) Naro�niški model: osnovan je na prihodkovnem modelu, ki temelji na vzpostavljenem

uporabniškem ra�unu (angl. user accout) oz. pogodbi med posrednikom in odjemalcem storitve z dolo�enimi pogoji uporabe. Uporabnik (odjemalec) storitve se lahko registrira bodisi za uporabo storitev znotraj dolo�enega �asovnega obdobja, bodisi na vnaprej dolo�eni koli�ini uporabe storitev. Ponudnik storitev lahko dolo�i ve� naro�niških nivojev za razli�ne skupine uporabnikov.

c) Najemniški model: temelji na prihodkovnem modelu, ki je zna�ilen za ve�je uporabnike

(odjemalce), ki zahtevajo ve�ji obseg uporabe storitev in posledi�no bolj specifi�ne pogoje uporabe. Ponudnik storitev lahko zara�unava po koli�ini transakcij ali po številu odjemalnih to�k na strani uporabnika. Ta model zasledimo (glej poglavje 7.2) pri modelu proizvajalca (najemniški model), omeniti velja tudi model licenciranja, ki temelji na prodaji pravic (licence) za uporabo storitev.

d) Registracijski model: temelji na konceptu zara�unavanja vidnosti/oglaševanja storitev

(angl. pay-to-be-seen) na dolo�enih mestih (npr. portal, specializirani javni imeniki UDDI). Lastnik javnega imenika zara�una registracijsko �lanarino ponudnikom za objavo njihovih storitev. Ta model neposredno ne vklju�uje odjemalca storitev, ampak v njegovi vlogi nastopa ponudnik storitev, ki uporablja storitve registracije za objavo svojih storitev.

��%��!��

��

Ena oblika tega modela je navzo�a v modelu reklam (portal, pla�ilo za pozornost, brezpla�ni model).

Predstavljeni poslovni modeli so precej splošni in se lahko uporabijo v razli�nih tržnih segmentih. Omeniti velja ponujanje programske opreme kot storitve in ustvarjanje dodane vrednosti preko predstavljenih poslovnih modelov.

7.5 Definicija poslovnih modelov za vrednotenje spletnih storitev Poslovni model kot abstrakni pojem sam po sebi ne omogo�a ustvarjanje dodane vrednosti. Spletne storitve kot tehnološki vložek v ustrezni poslovni model lahko privedejo do ekonomskega u�inka – dodane vrednosti (glej poglavje 7.1). Pojavi se vprašanje na kakšen na�in predstaviti poslovni model za uporabo preko spletnih storitev. Ve�ina literature podaja splošne definicije in ogrodja poslovnih modelov za namene e-poslovanja, �emur so namenjene spletne storitve. V predhodnih poglavjih so podani osnovni pojmi in izhodiš�a poslovnih vidikov za podro�je e-poslovanja. Za tehni�ne smernice lahko vzamemo dinami�no elektronsko poslovanje (poglavje 6.1.2) in storitveno usmerjeno arhitekturo (poglavje 6.1.3). Za predstavitev poslovnih modelov se naslonimo na poglavje 7.4, kjer so opisani nekateri poslovni modeli, ki jih skušamo implementirati v prototipu sistema za vrednotenje – obra�un spletnih storitev. V našem miselnem modelu nastopajo razli�ni elementi – entitete: � poslovni model; � spletna storitev; � ponudnik storitev; � odjemalec storitev; � dodana vrednost. Naša naloga je smiselno povezati entitete v logi�ni model za generiranje dodane vrednosti. Poslovni model lahko razumemo kot predpis kako ustvarjati dodano vrednost preko ponujanja spletnih storitev. V splošnem lahko v model vklju�imo tudi pojem poslovnega procesa, ki ga do dolo�ne abstrakcije sestavlja zaporedje operacij na spletnih storitvah. Vsaka storitev prispeva del dodane vrednosti skozi specifi�en poslovni model, ki ji pripada. Ob dostopu do spletne storitve pa morajo obstajati atomarne enote, ki jih je mogo�e meriti in glede na izmerjeno koli�ino obra�unati. Pridemo do ugotovitve, da je poslovni model v našem miselnem modelu sestavljen iz enot, ki jih je mogo�e meriti in posledi�no obra�unati. V to pravilo lahko vklju�imo tudi enote, ki niso merljive, imajo pa vnaprej predpisano vrednost. Vsaka spletna storitev pripada ponudniku storitev, ki ji tudi dolo�i po kakšnem pravilu (poslovnem modelu) se obra�unava. Odjemalec mora za uporabo (proženje) spletnih storitev imeti sklenjeno pogodbo s ponudnikom ter veljavno naro�niško razmerje. Za predstavitev modela povezav med entitetami lahko uporabimo razredni diagram (glej poglavje 8.1.6) modelirnega jezika UML [88]. Entitete so predstavljene kot razredi, ki so osnovni gradniki razrednega diagrama. Slika 25 prikazuje logi�ni model umestitve poslovnega modela za ustvarjanje dodane vrednosti.

��%��!��

��

1..1ponuja

0..*pripada

*ima predpisan

0..*dolo�a vrednost

0..*proži

0..*izvede operacijo

* 1..*

0..*vsebuje

1..*je del

1..*uporabi (dolo� i)

0..*ustvarja vrednost

0..1izvaja 0..*

je del poslovanja

Dodana v rednost

Odjemalec Ponudnik

Poslov ni model

Spletna storitev

Enota

Merlj iv a enota Nemerlj iv a enota

Poslov ni proces

Naro�niško razmerje

Pogodba

#��-*�(%��!��'��$��%�*��!��

Logi�ni model predstavlja enega od možnih na�inov za predstavitev poslovnega modela kot vmesnega �lena med spletnimi storitvami in dodano vrednostjo za ponudnika. Osredoto�enost je na dodani vrednosti, ki jo pridobi ponudnik storitev. �e razmislimo: dodana vrednost se ustvarja tudi na strani odjemalca, praviloma v druga�ni obliki (racionalizacija poslovanja, zmanjšanja stroškov, zadovoljstvo) – glej predhodno poglavje 7.4. Naš model je osredoto�en samo na ustvarjanje dodane vrednosti za ponudnika, ki je izražena v denarni obliki – odjemalec za uporabo storitev pla�a ponudniku po pravilu, kot ga dolo�a poslovni model. Predstavljeni logi�ni model še vedno premalo natan�no podaja konkretno predstavitev poslovnega modela. Poslovni model vsebuje množico enot (metrika), katerih koli�ino lahko merimo in ustrezno ovrednotimo – obra�unamo (npr. podatki, dostopi, transakcije) ali pa je njihova cena (teža) dolo�ena brez merljive koli�ine (npr. naro�nina). Dopuš�ati je potrebno možnost, da se storitev ovrednoti oz. obra�una z razli�nimi poslovnimi modeli z izbiro dolo�enih vrednostnih enot znotraj modelov. S tem razmišljanjem lahko postavimo bolj natan�no definicijo poslovnega modela – slika 26.

��%��!��

��

1..1se vrednoti

0..*pripada

1..1vsebuje

*pripada

1..*upošteva

1..1je del

0..*vsebuje

1..1sestavlja

1..1ima vrednost

0..*pripada

*vsebuje

*je del

Spletna storitev

ImeKon�naTo�ka

Poslov ni model

ImeModelaOpis

Vrednost

CenaEnote

Vrednostna enota

ImeEnoteVirPodatkovOpis

Merlj iv a enota Nemerlj iv a enotaObra�un

SkupajEnotSkupnaCena

#��%��%�!�/�%��$��%�*��!�� Spletni storitvi se dolo�i vrednost – pravila na osnovi izbranega poslovnega modela in vrednostnih enot, ki mu pripadajo. Ta vrednost je oblika dodane vrednosti, ki se skozi obra�un transformira v denarno obliko. Vsekakor je ta definicija še vedno abstraktna, vendar ponuja osnovno idejo za konkretno realizacijo sistema za vrednotenje spletnih storitev preko poslovnih modelov.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

8. Prototip za kontrolo dostopa in vrednotenje (obra�un) spletnih storitev Preko izhodiš� in ugotovitev znotraj prejšnjih poglavij, predvsem tehni�nih specifikacij in ekonomskega pogleda na spletne storitve skozi izbrane poslovne modele, lahko do neke mere zasnujemo programski prototip, ki vklju�uje tako tehni�ne, kot poslovne vidike spletnih storitev. S tehni�nega vidika se osredoto�imo predvsem na varnost (poglavje 3.4), s poslovnega (poglavje 6, 7) pa na podporo razli�nim poslovnim modelom za ustvarjanje dodane vrednosti – izhodiš�e predstavlja poglavje 7.5. Programski prototip za kontrolo dostopa in vrednotenje spletnih storitev v veliki meri temelji na principih in priporo�ilih dinami�nega elektronskega poslovanja (poglavje 6.1.2) in posledi�no storitveno usmerjene arhitekture (poglavje 6.1.3). Vsebuje osnovne entitete: ponudnik, odjemalec in register storitev. Osnova za vrednotenje je naro�niški in transakcijski poslovni model ter kombinacija obeh. Poudarek je tudi na tehni�nih vidikih dostopa do spletnih storitev (verodostojnost, celovitost, zaupnost) z uporabo razli�nih standardov sklopa WS-Security (glej poglavje 3.4.1). V grobem naj bi prototip omogo�al razli�ne funkcije za vloge odjemalca in ponudnika storitev (nekatere funkcije so skupne): a) odjemalec storitev � registracija uporabnika; � prijava v sistem; � pregled spletnih storitev; � sklenitev pogodbe s ponudnikom storitev; � sklenitev naro�niškega razmerja; � dolo�itev omejitev dostopa; � uporaba (proženje) spletnih storitev; � pregled dostopov in porabe spletnih storitev (poro�ila). b) ponudnik storitev � prijava v sistem; � upravljanje s šifranti; � upravljanje odjemalcev; � odobritev pogodb z odjemalci; � definicija poslovnih modelov; � upravljanje spletnih storitev; � upravljanje naro�niških razmerij; � pregled dostopov in porabe spletnih storitev (poro�ila); � obra�un porabe spletnih storitev. Vsi procesi oz. funkcije za posamezne vloge so dostopne preko enotne spletne aplikacije, proces uporabe (proženja) spletnih storitev – le ta vsebuje številne korake (overjanje – avtentikacija, avtorizacija, preverjanje pogojev za dostop, merjenje porabe), pa je izveden z lo�enim programskim modulom za prestrezanje paketov SOAP. Okvirno zgradbo prototipa prikazuje slika 27.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

#��)��'��$�*��*�$��$�

Celotni prototip je izveden na programski platformi Microsoft .NET1 v programskem jeziku C#2 in spletni tehnologiji ASP.NET3. Za uporabo dolo�enih standardov WS-Security je uporabljen dodatek (komponenta) WSE2 [58] (Microsoft Web Services Enhancements 2). Programski prototip je razvit s pomo�jo orodja Microsoft Visual Studio .NET 2003.

8.1 Analiza problemske domene Znotraj tega poglavja skušamo bolj podrobno analizirati in predstaviti zgradbo programskega prototipa – sistema z jezikom UML (Unified Modeling Language) [87, 88, 89] za objektno modeliranje programske opreme in informacijskih sistemov. Kompleksni sistem najlažje predstavimo skozi množico neodvisnih pogledov na sistem in vsak problem, ki ga rešujemo, lahko obravnavamo z razli�nih zornih kotov. Predstavljeni so posamezni procesi in funkcije preko ustreznih diagramov UML, le-ti so narejeni s pomo�jo orodja CASE Sybase PowerDesigner Evaluation 114, ki nudi podporo jeziku UML v celoti, omogo�a pa tudi podatkovno modeliranje.

8.1.1 Splošen diagram primera uporabe Z diagramom primera uporabe prikažemo kaj mora sistem delati. Diagram primera uporabe (angl. use case diagram) sestavljajo naslednji elementi [88, 87]:

a) Akter (angl. actor): � lahko predstavlja vlogo, ki jo uporabnik izvaja v sistemu; � lahko je to nek drug sistem ali podatkovna baza, ki komunicira z našim sistemom. UML notacija za akterja je naslikan možic.

1 http://msdn.microsoft.com/netframework/technologyinfo/overview/ 2 http://msdn.microsoft.com/library/en-us/csspec/html/csharpspecstart.asp 3 http://msdn.microsoft.com/library/en-us/cpguide/html/cpconCreatingASPWebApplications.asp 4 http://www.sybase.com/products/developmentintegration/powerdesigner

��%��,A$*!��A��A$��%��!��A��A��!��$�A$�(��A��('%

�9(��)��,A��%��2��%��4A��A��%��$��

��%��&�,�

(��'!��"

��%�

�� ,�%��5��,

�� ,�%

1!��

�%'!%��

788�

788�

#1��

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

b) Primer uporabe (angl. use case): predstavlja zaporedje akcij, ki ji akter izvaja s pomo�jo sistema z namenom, da bi dosegel dolo�en cilj. Primer uporabe v bistvu prikazuje kaj mora sistem delati, ne pa kako bo to izvedel. UML notacija za primer uporabe je elipsa.

c) Konstrukti, ki prikazujejo posebna dogajanja: � Include: z konstruktom include prikažemo, da nek primer uporabe eksplicitno

vklju�uje obnašanje nekega drugega primera uporabe. Konstrukt prikažemo z usmerjeno povezavo od primera uporabe, ki vsebuje drug primer uporabe. UML notacija za ta konstrukt je na puš�ici napisan tekst: << include >>.

� Extend: z konstruktom extend prikažemo, da nek primer uporabe implicitno vklju�uje obnašanje nekega drugega primera uporabe, prikažemo ga z usmerjeno povezavo. S tem konstruktom prikažemo dogajanje, ki se izvaja v posebnih primerih oz. pod posebnimi pogoji. UML notacija za ta konstukt je na puš�ici napisan tekst: << extend >>.

Diagram primerov uporabe opisuje procese, kot jih vidi akter (uporabnik). To pomeni, da mora vsaj eden od akterjev uporabljati proces (množico procesov) in mora od procesa/ov dobiti merljiv rezultat, ki ga modeliramo kot primer uporabe. Tak na�in modeliranja procesov omogo�a procesno orientacijo modeliranja sistema. V splošnem je diagram primerov uporabe graf, ki vsebuje akterje, množico primerov uporabe znotraj zaklju�enega sistema, povezave med akterji in primeri uporabe ter generalizacijo med primeri uporabe.

Diagram uporabe na sliki 28 prikazuje akterja (vloge) – odjemalca in ponudnika storitev ter njihovo povezavo oz. komunikacijo s posameznimi primeri uporabe - ti povedo kaj izvajajo, ne pa kako. To predstavlja okvirno dogajanje znotraj sistema. Nekateri primeri uporabe vsebujejo druge primere uporabe; npr. primer Naro�niška razmerja vsebuje Omejitve dostopa.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

�"

<<include>>

<<include>>

<<include>>

Odjemalec

Ponudnik

Registracija

Prijava v sistem

Pogodbe s ponudniki

Pregled storitev

Naro�niška razmerja

Poro� i la

Proženje storitev

Šifranti

Odjemalci

Pogodbe z odjemalci

Poslovni modeli

Omejitve dostopa

Merjenje

Preverjanje dostopa

Spletne storitve

Obra�un

#��'%��%�� Nekateri primeri uporabe so v nadaljevanju opisani z razli�nimi diagramskimi tehnikami UML.

8.1.2 Diagram stanj Dinami�no obnašanje sistema opišemo z uporabo diagrama stanj (angl. statechart diagram). Diagram opisuje vsa možna stanja objekta znotraj dolo�enega konteksta in na�in njegovega spreminjanja kot posledico dogodkov, ki vplivajo na objekt. V osnovi je diagram stanj graf stanj in prehodov med njimi; izdelamo ga lahko za dolo�en razred, primer uporabe ali celoten sistem. Diagram stanj sestavljajo naslednji elementi [88]: � Stanje (angl. state): je položaj v katerem se nahaja objekt v nekem trenutku svojega

življenja. Ko je objekt v nekem stanju lahko izvaja kakšno aktivnost, �aka na nek dogodek ali pa izpolnjuje enega ali ve� pogojev. Stanje lahko vsebuje tudi ve� podstanj. Specificira lahko tudi interne akcije in aktivnosti, ki jih objekt izvaja, ko se nahaja v dolo�enem stanju; ima obliko: ime-dogodka seznam-argumentov / akcija ali aktivnost. UML notacija za stanje je zaobljen pravokotnik.

� Prehod (angl. transition): predstavlja spremembo, ki povzro�i, da objekt iz enega stanja

preide v drugo stanje. Prehod se zgodi, ko se zgodi nek dogodek zanimiv za objekt. Lahko se zgodi tudi brezpogojno, ponavadi takrat, ko so vse aktivnosti povezane z objektom

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

zaklju�ene in je objekt pripravljen na prehod v naslednje stanje. Objekt lahko tudi prehaja v isto stanje. UML notacija za prehod je puš�ica.

� Varnostni pogoj (angl. guard condition): je pogoj, ki mora biti izpolnjen, da se zgodi

prehod v novo stanje. Pogoj je podan v oglatih oklepajih ob prehodu. Okvirni diagram prehajanja stanj za spletni del aplikacije prototipa prikazuje slika 29. Prikazana so glavna stanja v katerih se nahaja sistem in možne prehode med njimi. Z modela so razvidna glavna stanja, v katere prehaja uporabnik.

�akanje na prijavo

potrditev prijave [username!=empty && password!=empty && provider = (true || false)]

uporabnik obstaja [username && password OK]

uporabnik ne obstaja [username && password NOT OK]

�akanje na prijavo

[uporabnik = CONSUMER]

[uporabnik = PROVIDER]

pregled pregled

izbira [Provider]

[KeyCollection]

[Consumer][Contract]

[BusinessModel][Service]

[Subscription]

[Report]

[Bil ling]

izbira [Consumer]

[Service]

[Contract]

[Subscription]

[Report][Logout]

[Logout]

uporabnik odjavljen

akcija

akcija

akcija

akcija

akcija

akcija

akcija

akcija

akcija

akcija

akcija

akcija

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira

izbira [Login]

izbira [Register]

uporabnik registriran

Prijav a

entry / pri javna maska

Prev erjanje uporabnika

entry / preberi ali je ponudnikdo / preberi ime in gesloexit / preveri ime in geslo

Uporabnik prijav ljen

do / kreiraj uporabniški žeton

Napa�ni uporabnik

do / izpis napake

Funkcije za odjemalca

do / izpis menujevFunkcije za ponudnika

do / izpis menujev

Izbor funkcije

do / �akaj na izbor

Šifranti

do / prikaz šifrantov

Odjemalci

do / prikaz odjemalcev

Pogodbe

do / prikaz pogodb

Poslov ni modeli

do / prikaz modelov

Spletne storitv e

do / prikaz storitev


do / izpis razmerij

Poro�ila

do / izbira vrste poro� i l

Obra�un

do / izbira obra�una

Spletne storitv e

do / prikaz storitev

Pogodbe

do / prikaz pogodb


do / prikaz ramzmerij

Poro�ila

do / izbira poro� i la

Odjav a

do / briši uporabniški žeton

Za�etna stran

Registracija

entry / prikaz obrazcaexit / shrani podatke

#��9��*��%��$��%��$��

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

1. Za�etno stanje predstavlja zagon oz. dostop do spletne aplikacije (ta se nahaja na ustreznem naslovu URL). Uporabniku so na volju prehodi v stanja: Registracija in Prijava.

2. Stanje Registracija nudi registracijo novega uporabnika – odjemalca znotraj sistema. Ob

uspešnem vpisu podatkov, se nov uporabnik lahko prijavi preko stanja Prijava. Stanje Preverjanje uporabnika preveri oz. overi (avtenticira) prijavo; v primeru neobstoja uporabnika sledi izpis napake in prehod v prešnje stanje Prijava.

3. Po uspešnem overjanju uporabnika se znotraj sistema kreira �asovno omejen uporabniški

žeton (angl. authentication ticket). Glede na vlogo prijavljenega uporabnika (odjemalec, ponudnik) sistem ustrezno ponudi nabor funkcij (stanje Funkcije za odjemalca/ponudnika).

4. Uporabnik preko menijev izbere ustrezno funkcijo, pri �emer je nabor funkcij za

ponudnika precej širši. Ob prehodu v ustrezno stanje oz. izboru funkcije so na voljo tudi ustrezne akcije (dodajanje, ažuriranje,..), ki pa v modelu niso vidne. Vsako stanje oz. funkcija omogo�a tudi prehod v drugo stanje.

5. Obe vlogi uporabnika imata vedno na voljo funkcijo oz. prehod v stanje Odjava, ki izvede

odjavo trenutnega uporabnika iz sistema – briše (uni�i) uporabniški žeton in naredi prehod v za�etno stanje Prijava oz. se zaklju�i cikel znotraj grafa stanj – pridemo v kon�no stanje.

8.1.3 Diagram aktivnosti za proženje (klic) spletnih storitev Primer uporabe Proženje spletnih storitev (vsebuje tudi Merjenje in Preverjanje dostopa) lahko predstavimo z diagramom aktivnosti. Z njim predstavimo podrobnosti, ki jih objekti izvajajo. Diagram aktivnosti (angl. activity diagram) sestavljajo naslednji elementi [87, 88, 89]: � Aktivnost (angl. activity): to je dogajanje, ki ga objekt izvaja. Aktivnost se lahko prekine,

lahko pa se jo tudi razdeli na druge aktivnosti. Aktivnost uporabimo za modeliranje korakov v izvedljivem algoritmu – postopku.

� Akcija (angl. action): je množica nekih izvajajo�ih funkcij, katerih izvedba spremeni

vrednost posameznih atributov objekta ali pa vrne vrednost dolo�enim objektom. V nasprotju z aktivnostjo, se akcije ne more prekiniti. Na splošno velja da se aktivnost izvaja kar nekaj �asa, medtem ko akcija porabi za svojo izvršitev zelo malo �asa. UML notacija je za akcijo in aktivnost enaka. To je podaljšana elipsa.

� Odcep (angl. branch) in zlitje (angl. merge): odcep je odlo�itvena to�ka kjer nastanejo dve

ali ve� možnih poti. Vsaka razdružna to�ka ima varnostni pogoj. �e je pogoj izpolnjen, se izvede ena možna pot, druga�e pa druga. Zlitje pa je to�ka, kjer se ve� razdruženih združi. UML notacija je za oba konstrukta enaka. To je lik v obliki romba.

� Razdružitev (angl. fork) in združitev (angl. join): razdružitev predstavlja to�ko, kjer se tok

aktivnosti razbije v ve� tokov, ki se lahko paralelno izvajajo in so med seboj neodvisni. Pri združitvi pa se ve� tokov aktivnosti združi v enega. UML notacija je za oba enaka. To je odebeljena �rta, ki se ji re�e tudi sinhronizacijska �rta (angl. synchronization bar).

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

� Pokon�na �rta, steza (angl. swimlane): s pomo�jo pokon�nih �rt na diagramu lahko

sledimo kdo (ali kateri del organizacije) izvaja dolo�en tok aktivnosti. S pokon�nimi �rtami uredimo aktivnosti v vertikalna obmo�ja, lo�ena s �rto. Vsako obmo�je predstavja odgovornosti posameznega razreda ali osebe.

Slika 30 prikazuje diagram aktivnosti za proces proženja spletne storitve s strani odjemalca. Pred izvedbo metode na razredu, ki predstavlja spletno storitev, so potrebne številne aktivnosti, ki skrbijo za overjanje (avtentikacijo), avtorizacijo, preverjanje pogojev za dostop, merjenje (beleženje) dostopov in agregacijo podatkov. Proces klica spletne storitve je kot celota v ve�ji meri linearni algoritem, paralelnosti takoreko� ni.

Odjemalec WSE2 Pipeline CustomTokenManager SOAPInterceptor BusinessLogic WebServ ice

[Da] [Ne]

[UsernameToken]

[X509]

[Brez]

[Da]

[Da]

[ne ustreza] [brez || ustreza]

[Da]

[Ni možen]

[Brez]

[Ni omogo�en]

[Ne]

[Ne]

[Omogo�en]

[Da]

[Možen]

[Ne]

Instanciranje posrednika WS

Dolo�itev kon�ne to�ke

Dodaj v arnostni žeton

Preveri SOAP paket

Žeton

Pošlj i SOAP zahtevo

Tip žetonaPrev eri žeton

Iš�i uporabnika za žeton

Žeton OK

SOAP napaka : 1

Preveri X509

X509 veljaven

Prev eri WS-Policy

WS-Policy

Beri v elikost SOAP telesa

Beri žeton

Obstaja

Preveri dostop do storitve

Dostop

Preveri storitev

Anonimni dostop

Beleženje dostopa

Izv edi metodo

Ažuriranje dostopa

SOAP �ez izhodni filter

SOAP napaka : 2

Beri velikost DIME priponk

Beleži anonimne

#��"��$��%��

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

Diagram aktivnosti prikazuje visokonivojski pogled na proces (lahko ga obravnavamo kot model delovnih tokov) sinhronega proženja spletne storitve znotraj programskega prototipa. Steze prikazujejo odgovorne subjekte (vloga, paket, razred) za posamezne aktivnosti. Glavno vlogo igra paket WSE2 [58] (glej poglavje 5), ki podpira ve�ino varnostnih specifikacij WS-Security. Paket CustomTokenManager izvaja aktivnosti avtorizacije uporabniških žetonov glede na lo�eno shrambo uporabnikov (odjemalcev). Prestreznik paketov SOAP SOAPInterceptor skrbi za avtorizacijo in beleženje dostopa preko nivoja poslovne logike BusinessLogic.

8.1.4 Kontrola dostopa do storitve in merjenje (beleženje) Prejšnji diagram aktivnosti prikazuje visokonivojski pogled na množico aktivnosti pri proženju spletne storitve. Nekatere izmed njih lahko opišemo podrobneje z UML diagramom zaporedja (angl. sequence diagram), ki je še vedno precej splošen. Diagram zaporedja prikazuje dinamiko modeliranega sistema na na�in, ki je zelo blizu vsakemu, tudi strokovno manj podkovanemu uporabniku. Prikazuje interakcije na osnovi �asovnega zaporedja – kako objekti sodelujejo in izmenjujejo sporo�ila. Diagram ima dve dimenziji: vertikalno (prikazuje �as) in horizontalno (prikazuje razli�ne objekte). Ima štiri klju�ne elemente oz. zna�ilnosti [87, 88, 89]: � Objekti (angl. objects) se vedno nahajajo na zgornjem robu diagrama. � Življenjska �rta objekta (angl. lifeline) je vertikalna �rta, ki predstavlja obstoj objekta v

dolo�enem �asu. � Aktivacija (angl. activation) prikazuje �asovno periodo, v kateri objekt izvaja akcijo.

Akcijo lahko izvaja direktno ali skozi ustrezno metodo. Prikažemo kot visok tanek pravokotnik, katerega vrh je poravnan s �asom za�etka, njegovo dno pa s �asom zaklju�ka.

� Sporo�ilo (angl. message) je komunikacija med objekti, ki pogojuje akcije, ki jih objekti

izvajajo eden nad drugim ali sami nad sabo. Sporo�ilo prikažemo kot horizontalno puš�ico iz življenjske �rte enega objekta v življensko �rto drugega objekta.

Proces oz. primer uporabe Kontrola dostopa ter Merjenje lahko bolj podrobno opišemo z omenjenim diagramom – slika 31. Velja omeniti, da diagram prikazuje proces, ki se izvede šele po uspešnem overjanju (avtentikaciji) uporabniškega žetona, �e le ta obstaja, za kar sta odgovorna paketa WSE2 Pipeline in CustomTokenManager (slika 30). Diagram zaporedja na sliki prikazuje vse objekte, ki so v ve�ini primerki dolo�enih razredov oz. tudi abstraktne entitete (odjemalec, relacijska podatkovna baza RDBMS). Odjemalec pošlje zahtevo SOAP, ki se na strani strežnika deserializira preko vhodnega cevovoda WSE2 Pipeline (opravi morebitno overjanje varnostnih žetonov) v ustrezen primerek razreda SoapContext, ki predstavlja kontekst trenutnega klica spletne storitve. Izvajalno okolje ASP.NET instancira primerek razreda SOAPInterceptor, ki skrbi za vse nadaljnje aktivnosti znotraj omenjenega konteksta: pri sprejemanju SOAP zahteve se proži dogodek OnPreRequest(), ob pošiljanju SOAP odgovora pa OnPostRequest(). Za dostop do podatkov

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

skrbi primerek vmesnika IDataHelper, ki nudi transparenten dostop do razli�nih relacijskih podatkovnih strežnikov (MS SQL, Oracle).

Deserial iziraj

[SoapContext!=null]: OnPreRequest( )

[SecurityToken!=null]: CheckServiceLogin( )

[SecurityToken!=null && UserInfo!=null]: Check( )

CheckService( )

ExecuteReader( )

Podatki o odjemalcu

SQL

Podatki

Instanca UserInfo

ExecuteReader( ) SQL

Podatki

Podatki o storitviTip dostopa

Beri podatke o naro�niškem razmerju

Eksplicitne omejitve

SQL

Podatki

Ažuriraj eksplicitne omejitve na razmerju

Omejitve ažurirane

Preveri prekora� i tev za eksplicitne omejitve

Beri logi�ne izraze za omejitve

Nabor logi�nih izrazov(IP, Date, TotalDataIn, TotalDataOut, Hits)

SQL

Podatki

SQL

Podatki

Evaluate( )

ConstructEvaluator( )

RezultatRezultat

[Rezultat == false]: SOAPException

[SecurityToken!=null && UserInfo==null]: CheckService( )

Instanca ServiceInfo

[ServiceInfo == null]: SOAPException

[SecurityToken==null]: CheckService( )

Instanca ServiceInfo[ServiceInfo==null || AccessType!=ANONYMOUS]: SOAPException

BeginLog( )

ExecuteNonQuery( )

Status

SQL

StatusPodatki vpisani

Klic metode

Rezultat

OnPostRequest( )

EndLog( )

ExecuteNonQuery( ) SQL

StatusStatusPodatki ažurirani

Rezultat

Searial izacija SOAP

SOAP odgovor

SOAP zahteva

Odjemalec

:SOAPInterceptor

:SoapContext

:Pipeline :User :AccessCheck

:Service : 1

:ExpressionEvaluator :IDataHelper

<<Boundary>>RDBMS

:DataLogger:Service : 2

:WebService

Deserial iziraj

[SoapContext!=null]: OnPreRequest( )

[SecurityToken!=null]: CheckServiceLogin( )

[SecurityToken!=null && UserInfo!=null]: Check( )

CheckService( )

ExecuteReader( )

Podatki o odjemalcu

SQL

Podatki

Instanca UserInfo

ExecuteReader( ) SQL

Podatki

Podatki o storitviTip dostopa

Beri podatke o naro�niškem razmerju

Eksplicitne omejitve

SQL

Podatki

Ažuriraj eksplicitne omejitve na razmerju

Omejitve ažurirane

Preveri prekora� i tev za eksplicitne omejitve

Beri logi�ne izraze za omejitve

Nabor logi�nih izrazov(IP, Date, TotalDataIn, TotalDataOut, Hits)

SQL

Podatki

SQL

Podatki

Evaluate( )

ConstructEvaluator( )

RezultatRezultat

[Rezultat == false]: SOAPException

[SecurityToken!=null && UserInfo==null]: CheckService( )

Instanca ServiceInfo

[ServiceInfo == null]: SOAPException

[SecurityToken==null]: CheckService( )

Instanca ServiceInfo[ServiceInfo==null || AccessType!=ANONYMOUS]: SOAPException

BeginLog( )

ExecuteNonQuery( )

Status

SQL

StatusPodatki vpisani

Klic metode

Rezultat

OnPostRequest( )

EndLog( )

ExecuteNonQuery( ) SQL

StatusStatusPodatki ažurirani

Rezultat

Searial izacija SOAP

SOAP odgovor

SOAP zahteva

#��9��*��$��!��%��!��$�!��

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

Dogodek OnPreRequest() po uspešni avtorizaciji uporabniškega žetona (metoda CheckServiceLogin() na primerku razreda User) izvede metodo Check() na primerku razreda AccessCheck, ki predstvlja celotno logiko za preverjanje pogojev za klic spletne storitve. Metoda Check() izvede ve� korakov preverjanja: 1. Preverjanje veljavnosti spletne storitve na kon�ni to�ki preko metode

Service.CheckService() – vrne informacijo o tipu dostopa (anonimni, preko varnostnega žetona). V primeru, da je omogo�en anonimni dostop, se preverjanje zaklju�i – dostop do storitve je možen.

2. Preverjanje veljavnosti naro�niškega razmerja za ciljno storitev overjenega uporabnika.

Razmerje vsebuje tudi nabor eksplicitnih omejitev, ki se jih upošteva pri dostopu: � MaxTime (sec): najve�ji možni �as trajanja izvajanja spletne storitve (t.i. procesorski �as);

� MaxDataIn (bajti) : zgornja meja koli�ine vhodnih podatkov znotraj telesa SOAP; � MaxDataOut (bajti): zgornaj meja koli�ine izhodnih podatkov znotraj telesa SOAP; � MaxHits: zgornja meja za število dostopov (klicev) do spletne storitve; � MaxTx: zgornja meja za število opravljenih transakcij znotraj spletne storitve.

V primeru, da je dosežena katera od zgornjih mej in so prekora�itve prepovedane, je dostop do storitve onemogo�en.

3. Vrednotenje (evaluacija) logi�nih izrazov za omejitve. Znotraj vsakega naro�niškega razmerja lahko definiramo poljubno število logi�nih izrazov preko definiranih parametrov za razli�ne kategorije:

� Omejitev za naslov IP (Internet Protocol): možen je dostop samo z dolo�enega naslova

IP (simboli�na parametra ClientIP in ClientHostName). Primer izraza: ClientIP == “127.0.0.1”.

� Datumske omejitve: dostop je vezan na trenutni datum (simboli�ni parameter Date). V

ta namen obstaja ve� pred-definiranih datumskih funkcij: - IsWorkDay(Date), IsSunday(Date), IsSaturday(Date), IsWeekendDay(Date); - Hour(Date): omejimo uro dostopa; primer: Hour(Date) > 7 And Hour(Date) < 16.

� Podatkovne omejitve: dostop je vezan na agregirano koli�ino vhodno/izhodnih

podatkov v bajtih (simboli�na parametra TotalDataIn in TotalDataOut) oz. na koli�ino podatkov znotraj telesa SOAP (simboli�ni parameter RequestDataLength). Primer izraza: TotalDataIn <100000 And RequestDataLength <1000.

� Omejitve glede števila dostopov (simboli�ni parameter Hits). Primer izraza: Hits <

100.

Vrednotenje izrazov izvaja razred ExpressionEvaluator preko metode Evaluate(), ki v �asu izvajanja dinami�no zgradi programsko kodo v jeziku C# in jo dinami�no izvede (preko mehanizmov .NET Reflection1 in CodeDOM2). Pri grajenju programske kode se med drugim uporabijo tudi ustrezni regularni izrazi.

1 http://msdn.microsoft.com/library/en-us/cpguide/html/cpconreflectionoverview.asp 2 http://msdn.microsoft.com/library/en-us/cpguide/html/cpconusingcodedom.asp

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

Primerek razreda SOAPInterceptor v primeru zavrnitve dostopa do storitve proži napako SOAPException. To se zgodi tudi v primeru, �e je spletna storitev na kon�ni to�ki neveljavna. Primerek razreda DataLogger preko metode BeginLog() beleži vhodne podatke paketa SOAP (naslov IP, �as za�etka dostopa, koli�ina vhodnih podatkov znotraj telesa SOAP in morebitnih priponk DIME1). Sledi proženje metode na spletni storitvi WebService, ki vrne rezultat v obliki izhodnega paketa SOAP SoapContext. Proži se dogodek OnPostRequest(), ki izvede metodo EndLog() na primerku razreda DataLogger. Izvede se ažuriranje in agregiranje podatkov (�as konca dostopa, koli�ina izhodnih podatkov, število dostopov, število transakcij). Metoda poskrbi tudi za podatkovno integriteto preko ra�unanja kontrolne vrednosti vseh podatkov z zgoš�evalno funkcijo (algoritem MD5). Rezultat, ki ga vsebuje SoapContext, se preko cevovoda Pipeline serializira v odgovor SOAP in vrne odjemalcu.

8.1.5 Vrednotenje (obra�un) porabe Proces vrednotenja porabe spletnih storitev lahko poenostavljeno predstavimo z diagramom sodelovanja. Proces obra�una se izvaja periodi�no (dnevno, tedensko, mese�no,..), vendar zaradi poenostavitve ga proži ponudnik storitev na zahtevo. Slika 32 prikazuje proces izvajanja obra�una, ki ga iniciira Ponudnik storitev. Po uspešnem overjanju (avtentikaciji) ponudnika storitev (preko razreda User) v spletni vmesnik, se naloži spletna stran, ki je primerek razreda BillingPage. Obra�un se lahko izvede za izbranega ali za vse uporabnike. Seznam odjemalcev za trenutnega ponudnika vrne metoda GetConsumerListForProvider() razreda User. Slika prikazuje potek za izbranega uporabnika. Obra�un izvaja primerek razreda Billing (je del poslovne logike) preko metode RateConsumer(). Obra�un nadzoruje transakcija, ki je primerek vmesnika IDbTransaction, saj se mora obra�un zgoditi v celoti ali pa se sploh ne zgodi. Algoritem obra�una je slede�i: 1. Obra�unaj vsako storitev izbranega odjemalca; 2. Preveri prekora�itve eksplicitnih omejitev na naro�niškem razmerju in �e obstajajo, jih

ustrezno obra�unaj: � �e obstaja prekora�itev, jo ustrezno obra�unaj; � zapiši oz. ažuriraj obra�unsko postavko prekora�itve v podatkovni tabeli;

3. Preberi poslovne modele za obra�un za storitev:

� vsak poslovni model sestavljajo obra�unske enote, ki so lahko: - dostopi (angl. hits) - transakcije (angl. transactions) - naro�nina (angl. subscription fee) - vhodni podatki (angl. data in) - izhodni podatki. (angl. data out)

� vsaka enota (razen naro�nine) ima ustrezne agregirane vrednosti (merjene enote), ki so rezultat beleženja;

1 Direct Internet Message Encapsulation - WSE2 mehanizem za prenašanje priponk preko protokola SOAP

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

� pred obra�unom porabljenih enot, izra�unuaj razpršilne funkcije MD5 (preko primerka razreda Hash) nad vsemi agregiranimi vrednostmi;

� v primeru, da nova in stara vrednost razpršilne funkcije ne sovpadajo, je prišlo do kršitve integritete podatkov – proži napako in razveljavi obra�un;

� izvedi obra�un porabljenih enot in ažuriraj obra�unske postavke za vsako enoto v podatkovno tabelo;

4. Zaklju�i obra�un in obvesti uporabnika.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

Vnos imena in geslaCheckWebLogin( )

Uporabnik

[Uporabnik != OK]: Napaka

[Uporabnik = OK]: Avtentikacija

KlicGetConsumerListForProvider( )

Seznam odjemalcev

Izberi uporabnika

GetLastProcessedDate( )

Datum zadnjega obra�una

RateConsumer(CosumerId)

Beri vse storitve

Seznam storitev

Izvedi za vsako storitev

Beri prekora� i tve

Prekora� i tve

Obra�unaj prekora� i tve

Ažuriraj postavko

Postavka ažurirana

Beri obra�unske modele

Seznam modelov

Izvedi za vse modele

Beri agregirane vrednosti

Vrednosti

GetHash(vrednosti, MD5)

Hash niz

Primerjaj original in novi hash

[OriginalHash != NoviHash]: Napaka intergritete

[OriginalHash == NoviHash]: Beri agregirano enoto

Izra�unaj znesek porabe

Ažuriraj postavko

Postavka ažurirana

Število ažuriranih zapisov

BeginTransaction( )

Commit( )

[OriginalHash != NoviHash]: Rollback( )

Obra�un kon�an

Ponudnik

:Login :Bil lingPage :User :Bill ing :IDataHelper

:Hash

:IDbTransaction

Vnos imena in geslaCheckWebLogin( )

Uporabnik

[Uporabnik != OK]: Napaka

[Uporabnik = OK]: Avtentikacija

KlicGetConsumerListForProvider( )

Seznam odjemalcev

Izberi uporabnika

GetLastProcessedDate( )

Datum zadnjega obra�una

RateConsumer(CosumerId)

Beri vse storitve

Seznam storitev

Izvedi za vsako storitev

Beri prekora� i tve

Prekora� i tve

Obra�unaj prekora� i tve

Ažuriraj postavko

Postavka ažurirana

Beri obra�unske modele

Seznam modelov

Izvedi za vse modele

Beri agregirane vrednosti

Vrednosti

GetHash(vrednosti, MD5)

Hash niz

Primerjaj original in novi hash

[OriginalHash != NoviHash]: Napaka intergritete

[OriginalHash == NoviHash]: Beri agregirano enoto

Izra�unaj znesek porabe

Ažuriraj postavko

Postavka ažurirana

Število ažuriranih zapisov

BeginTransaction( )

Commit( )

[OriginalHash != NoviHash]: Rollback( )

Obra�un kon�an

#��%��!%��%��2��('%�4$��

8.1.6 Stati�ni vidik problemske domene To poglavje skuša podati stati�ni vidik arhitekture programskega prototipa. Prejšnja poglavja prikazujejo predvsem dinami�no obnašanje in interakcije med posameznimi deli sistema. Za opis stati�nega strukture uporabimo razredni diagram (angl. class diagram) – prikazuje razrede, njihovo strukturo, metode, atribute in relacije med razredi. Kot že omenjeno, ne prikazuje dinami�nih informacij [87].

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

�"

Lo�iti velja med razrednim in objektnim diagramom (angl. object diagram). Medtem, ko je razredni diagram graf elementov modela, je diagram objektov graf primerkov (instanc) razreda – je primerek razrednega diagrama. Prikazuje natan�no stanje sistema v dolo�enem trenutku. Pri oblikovanju razrednih diagramov moramo upoštevati dolo�ena pravila glede objektnega modeliranja [87, 88, 89]. Objekt (angl. object) je stvar ali koncept iz realnega sveta. Ima tri osnovne lastnosti: � Identiteta (angl. identity): oznaka ali ime. � Stanje (angl. state): ponazorjeno je z atributi in njihovimi vrednostmi v dolo�enem

trenutku. � Obnašanje (angl. behaviour): predstavljajo metode, ki spreminjajo vrednosti atributov

objekta. Razred (angl. class) je zbirka objektov, ki imajo enake karakteristike ali zna�ilnosti. Ima slede�e lastnosti: � Identiteta (oznaka, ime), ki je v dolo�enem trenutku unikatna (angl. unique). Ime objekta

lahko vsebuje ime razreda, kateremu objekt pripada. � Razred nima stanja tako kot objekt, vendar pa definira atribute, ki pripadajo vsakemu

objektu razreda. � Obnašanje, ki je v nasprotju z objektom, dolo�eno z operacijami. Operacija predstavlja

servis, ki ga kli�e objekt z namenom, da bo vplival na svoje obnašanje; metoda je implementacija tega servisa. Vsaka operacija dolo�enega razreda je predstavljena z vsaj eno metodo iz cele skupine metod vseh objektov tega razreda.

Objekt, ki pripada konkretnemu razredu, se ponavadi imenuje instanca (primerek) razreda (angl. instance class). Razred je abstrakcija, objekt pa konkretna predstavitev te abstrakcije. Razredi in povezave (angl. relationship) a) Asociacija (angl. association) Asociacija je strukturirana povezava med razredi. Lahko je obojestransko ali pa enostransko usmerjena. Praviloma je asociacija binarna, kar pomeni, da povezuje dva razreda. Prikažemo jo z polno �rto in praviloma ima: � Ime, ki pove naravo relacije. � Vloge (roles), ki so obrazi, s katerimi se razredi predstavljajo ostalim razredom. � Števnost (multiplicity), ki pove, koliko objektov, pridruženih posameznemu razredu, je

lahko prikazano s posamezno povezavo. Specifikacijo števnosti prikažemo kot tekstovni niz, ki je med intervaloma lo�en s pikama (spodnja meja..zgornja meja). Spodnja in zgornja meja sta celostevil�ni vrednosti in dolo�ata obmo�je med vklju�no spodnjo in zgornjo mejo. Znak * uporabimo za zgornjo mejo in pomeni neskon�no zgornjo mejo.

b) Vsebovanost – agregacija (angl. agregation) To je posebna vrsta asociacije. Eden ali ve� manjših razredov je del (angl. part) enega ve�jega celotnega (angl. whole) razreda. Po UML je razred zraven oznake, ki je v obliki diamanta, celotni razred (skupek), razred nasproti pa delni razred. Agregacija z mo�nim lastništvom se

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

imenuje kompozicija. Posebnost: �e na agregirani povezavi ni števnosti, potem velja 1..n pri delnem razredu ter 1 pri celotnem razredu. c) Generalizacija (angl. generalization) Je relacija med glavnim ali super razredom (staršem) in bolj specifi�no verzijo tega razreda (podrazredom ali otrokom). Podrazred podeduje vse atribute in operacije od enega ali ve� glavnih razredov. Pri tem je pomembno opozoriti še na dve zna�ilnosti, ki se ti�ejo generalizacije in sicer: � Mnogoli�nost ali polimorfizem (angl. polymorphism): pomeni, da lahko objekt podrazreda

redefinira katerokoli operacijo, ki jo podeduje od svojih nadrejenih razredov. � Zamenljivost (angl. substitutability): objekt podrazreda je lahko povsod tam, kjer je

uporabljen, zamenjan z objektom nadrejenega razreda. d) Odvisnost (angl. dependency) Odvisnost prikazuje pomensko relacijo med dvema ali ve�imi elementi modela. Prikazana je kot usmerjena povezava od izvornega do ciljnega elementa modela. Pomeni, da je izvorni element odvisen od ciljnega. e) Paket (angl. package) Paket je visokonivojska enota, ki je sestavljena iz množice sorodnih razredov, oz. skupina modelnih elementov grupiranih po pomenu z namenom zmanjšanja kompleksnosti. Odvisnost med dvema paketoma obstaja, �e obstaja odvisnost med dvema elementoma v paketih. f) Vmesnik (angl. interface) Vmesnik je uporaba tipa za opis zunanje vidnega obnašanja razreda, komponente ali paketa. Vmesnik predstavimo s pomo�jo malega krogca z imenom tipa. Vmesnik lahko dolo�a eno ali ve� operacij. Vmesnik je z razredi, komponentami ali paketi, ki ga podpirajo (implementirajo), povezan s polno �rto. To pomeni, da razred, komponenta ali paket implementira vse operacije, ki jih dolo�a vmesnik. Z opisanimi pravili lahko okvirno predstavimo posamezne elemente problemske domene. V splošnem lahko posamezne koncepte predstavimo s poslovnimi pravili. Sicer približno stati�no povezavo med objekti že podajajo nekateri prej prikazani diagrami (akcijski, diagram zaporedja, sodelovanja), ki jih lahko uporabimo kot izhodiš�e za gradnjo razrednih diagramov. Visokonivojski paketni diagram na sliki 33 prikazuje arhitekturo programskega prototipa. Vsak paket praviloma predstavlja logi�no zaklju�eno programsko knjižnico razredov (DLL – Dynamic Link Library) oz. zbir (angl. assembly), ki so specifi�ni za platformo .NET. Slika 33 predstavlja razširjen model na sliki 27 – programski prototip je sestavljen iz dveh lo�enih delov1: � spletni vmesnik (nivo uporabniškega vmesnika); � prestreznik SOAP (nivo za procesiranje paketov SOAP + nivo spletnih storitev). Oba dela sta neodvisna, isto�asno pa uporabljata oz. dostopata do paketov znotraj nivoja poslovne logike.

1 Celotni programski prototip sestavlja ve� kot 26000 vrstic programske kode

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

ASP.NET User Interface Layer

Business Logic Layer

Data Access Layer

Data Layer

Oracle RDBMSMS SQL Server

RDBMS

Web Serv ices Layer SOAP Framework Layer

<<Assembly>>

ExpressionEv aluator

<<Assembly>>

CustomTokenManager

<<Assembly>>

BusinessEntities : 1<<Assembly>>

Exceptions : 1

<<Assembly>>

WebControls

<<Assembly>>

ExceptionHandling : 1

<<Assembly>>

DataHelper

<<Assembly>>

SOAPInterceptor

<<Assembly>>

BusinessLogic

<<Assembly>>

Microsoft.ApplicationsBlock.ExceptionManagement

<<Assembly>>

Common : 1

<<Assembly>>

Microsoft.ApplicationBlocks.Data

<<Assembly>>

WebServ ices

<<Assembly>>

Common : 2

<<Assembly>>

WSControlUI

<<Assembly>>


<<Assembly>>

BusinessEntities : 2

<<Assembly>>

Microsoft.Web.Serv ices2 : 1

<<Assembly>>

Exceptions : 2

<<Assembly>>

Common : 3

<<Assembly>>

Exceptions : 3

<<Assembly>>

System.Data.SqlClient<<Assembly>>

System.Data.OracleClient

<<Assembly>>

Exceptions : 4

<<Assembly>>

Microsoft.Web.Serv ices2 : 2<<Assembly>>

Exceptions : 5

<<Assembly>>


#��)��'��$�*��*�$��$� Kot prikazuje slika 33, je prototip sestavljen iz ve� logi�nih celot – nivojev (angl. layers), nekateri paketi oz. zbiri pa dostopni iz ve�ih nivojev (npr. poslovne entitete):

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

1. Nivo uporabniškega vmesnika (ASP.NET UI Layer) Predstavlja razrede, gradnike in logiko za spletni uporabniški vmesnik v tehnologiji ASP.NET, kjer je praviloma vsaka spletna stran (spletni obrazec) predstavljena iz dveh delov: datoteka s kodo HTML in datoteka s programsko kodo za logiko (angl. Code Behind). Nivo vsebuje slede�e pakete oz. zbire: � WSControlUI: vsebuje spletne obrazce (angl. WebForms) s pripadajo�imi razredi – vsak

obrazec predstavlja svoj razred, katerega programska koda je lo�ena od strani, kjer so definirani elementi uporabniškega vmesnika (stran .aspx).

� WebControls: vsebuje razrede, ki prestavljajo izpeljane spletne gradnike s specifi�no funkcionalnostjo. Gradniki se znajo upodobiti v ustrezni kodi HTML za prikaz v spletnem brskalniku.

� Common: zbir vsebuje podporne razrede (za branje nastavitev, ra�unanje razpršenih vrednosti nizov,..).

� Exceptions: razredi, ki predstavljo uprabniške izjeme oz. napake (angl. exceptions). � ExceptionHandling: vsebuje razrede s programsko logiko za upravljanje z izjemami oz.

napakami; gre za možnost publiciranja napak na razli�ne vire (tekostovna datoteka, e-pošta, Windows EventLog), kar rabi za diagnosticiranje, preverjanje in obveš�anje o pravilnosti delovanja programskega prototipa. Na�in delovanja publiciranja napak se nastavi v konfiguracijski datoteki.

� BusinessEntities: poslovne entitiete, ki se prenašajo med nivojem uporabniškega vmesnika in nivoja poslovne logike. Ve�ina njih deduje od osnovnega razreda System.Data.DataSet, ki je narejen tako, da ga je mogo�e preprosto in hitro prenašati med nivoji porazdeljene aplikacije, ne glede na to, ali so ti v istem procesu, ve� procesih ali celo ve� strežnikih.

2. Nivo spletnih storitev (Web Services Layer) Predstavlja nivo s spletnimi storitvami, ki jih ponuja ponudnik storitev. Gre za lo�eno ASP.NET aplikacijo, ki te�e v drugem procesu kot nivo uporabniškega vmesnika. � WebServices: razredi, ki predstavljajo spletne storitve – vsi dedujejo od osnovnega razreda

System.Web.Services.WebService, ki nudi osnovno infrastrukturo spletnih storitev v ogrodju .NET.

� Microsoft.Web.Services2: zbir z razredi, ki nudijo funkcionalnost za razli�ne specifikacije WS-* (glej poglavje 5).

3. Nivo za procesiranje paketov SOAP (SOAP Framework Layer) Nivo vsebuje razrede za prestrezanje in procesiranje paketov SOAP in ustrezne podporne razrede. Ta nivo je v veliki meri odvisen od zbira za WSE2 (Microsoft.Web.Services2) predvsem za prestrezanje in procesiranje paketov SOAP. � CustomTokenManager: vsebuje razred CustomUsernameTokenManager za overjanje

žetonov tipa UsernameToken znotraj paketa SOAP. � SOAPInterceptor: vsebuje razred za prestrezanje vhodnih in izhodnih paketov SOAP, kar

predstavlja poglavitni del (jedro) programskega prototipa za kontrolo dostopa do spletnih storitev.

4. Nivo poslovne logike (Business Logic Layer) Nivo vsebuje celotno poslovno logiko (poslovna pravila) za nivo uporabniškega vmesnika kot tudi za nivo procesiranje paketov SOAP (beleženje in avtorizacija dostopov, obra�un). � BusinessLogic: vsebuje množico razredov z ustreznimi pravili obnašanja. Za nivo

uporabniškega vmesnika so to predvsem pravila za branje in shranjevanje (ažuriranje) poslovnih entitet v persistentni vir podatkov (relacijska podatkovna baza), za procesiranje paketov SOAP pa razli�ne metode za avtorizacijo in beleženje ustreznih parametrov.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

� ExpressionEvaluator: vsebuje razred za vrednotenje logi�nih izrazov v �asu izvajanja (angl. runtime). Paket se uporablja v metodah za avtorizacijo dostopa do spletnih storitev, ki imajo definirane logi�ne izraze za dolo�en nabor parametrov. Mehanizem, ki ga uporablja razred za vrednotenje, je CodeDOM za dinami�no grajenje programske kode in .NET Reflection za njeno izvajanje in vrednotenje.

� Microsoft.ApplicationsBlock.ExceptionManagement: nudi nabor razredov in vmesnikov, ki ponujajo osnovno ogrodje za manipulacijo in obravnavanje napak oz. izjem znotraj programske platforme .NET (je del t.i. dobrih razvojnih vzorcev in prakse (angl. patterns & practices) podjetja Microsoft1). Ta zbir predstavlja osnovno ogrodje za ExceptionHandling, ki skrbi za upravljanje z izjemami na predhodnjih višjih nivojih.

5. Nivo za dostop do podatkov (Data Access Layer) Ta nivo nudi funkcionalnost za dostop do razli�nih podatkovnih virov – v našem primeru relacijskih podatkovnih strežnikov. Trenutna implementacija nudi transparenten dostop do dveh podatkovnih strežnikov: Microsoft SQL Server 2000 in Oracle 8.x. Ne glede na izbrani podatkovni strežnik, je funkcionalnost vidna navzen vedno enaka – dostopna je preko definiranega vmesnika. Višji nivo poslovne logike tako niti ne ve, s katerim podatkovnim strežnikom ima opravka – dostop do podatkov je transparenten. � DataHelper: vsebuje vmesnik in pripadajo�e razrede za dostop do podatkovnih strežnikov

MS SQL Server (razred DataHelperMsSql) in Oracle (razred DataHelperOracle). Aktivni podatkovni strežnik je dolo�en v konfiguracijski datoteki ali pa se dolo�i preko ustreznega parametra.

� Microsoft.ApplicationBlocks.Data: vsebuje razrede z naborom metod za dostop do podatkovnih strežnikov MS SQL Server in Oracle. Tudi ta zbir oz. paket je del dobrih razvojnih vzorcev in prakse za dostop do podatkov znotraj ogrodja .NET.

� System.Data.SqlClient: je del distribucijskega ogrodja .NET in predstavlja nabor razredov za dostop do podatkovnega strežnika Microsoft SQL Server preko objektnega modela ADO.NET2.

� System.Data.Oracle: tudi ta zbir je del ogrodja .NET – nudi pa nabor razredov za dostop do podatkovnega strežnika Oracle, prav tako preko objektnega modela ADO.NET.

6. Nivo podatkov (Data Layer) Nivo predstavlja trajno shrambo za podatke. V našem primeru je to relacijski podatkovni strežnik; implementacija prototipa podpira dva relacijska strežnika: MS SQL Server in Oracle. Shema oz. podatkovni model je predstavljen v naslednjem poglavju. Velja poudariti, da je opis stati�ne strukture precej splošen in se ne spuš�a v same razrede znotraj posamenih zbirov (paketov), ker bi opis bistveno presegel predviden obseg tega dela. Podrobnejši razredni diagrami znotraj nekaterih opisanih paketov (zbirov) so na voljo v poglavju Priloge.

8.1.7 Podatkovni model Nekatere stati�ne strukture – predvsem poslovne entitete in razredi poslovne logike, so v veliki meri pogojeni s podatkovnim modelom, kjer se shranjujejo stanja poslovnih entitet. Poleg tega podatkovni model odraža poslovna pravila in logiko, ki mora veljati med podatki. V našem primeru nastopa ve�je število entitet (storitev, odjemalec, poslovni model,..), ki jih

1 http://msdn.microsoft.com/library/en-us/dnpatterns/html/MSpatterns.asp 2 http://msdn.microsoft.com/library/en-us/cpguide/html/cpconoverviewofadonet.asp

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

je potrebno ustrezno povezati med seboj. Slika 34 prikazuje konceptualno shemo podatkovnega modela (CDM – Conceptual Data Model), ki prikazuje posamezne entitete in relacije med njimi (ERD – Entity Relationship Diagram).

Serv ice

ServiceIDServiceNameDescriptionEndpointURIWsdlURIValidFromValidToEnabledKeyUDDIPlatformWSPolicyServiceWSPolicyClientX509SubjectServerX509CertIDServerX509SubjectClientX509CertIDClient

<pi> IVA200VA200VA300VA300DTDTBLVA200VA20TXTTXTVA300VA200VA300VA200

ServiceID <pi>

UserData

UserDataIDLoginNamePwdHashNameCompanyCompanyURIEmailAddressZipCityCountryValidFromValidToEnabled

<pi> IVA200VA1000VA200VA200VA200VA200VA200VA50VA50VA100DTDTBL

UserDataID <pi>

Prov ider

ProviderID <pi> I

ProviderID <pi>

Consumer

ConsumerIDServiceLoginServicePwdHash

<pi> IVA200VA1000

ConsumerID <pi>

Contract

ContractIDValidFromValidToApproved

<pi> IDTDTBL

ContractID <pi>

BusinessModel

ModelIDModelNameDescriptionEnabled

<pi> IVA200VA200BL

ModelID <pi>

Prov ision

ProvisionIDUnitUnitPrice

<pi> IVA50DC10,2

ProvisionID <pi>

LogData

LogDataIDClientIPClientHostNameBeginDateEndDateDataAmountDataInDataOutHashValue

<pi> IVA50VA200DTDTIIIVA2000

LogDataID <pi>

BillingModel

BillingModelIDModelNameDescriptionEnabled

<pi> IVA200VA200BL

BillingModelID <pi>

BillingItem

Bill ingItemIDTotalUnitsTotalPriceBeginDateEndDateProcessedDate

<pi> IIDC10,2DTDTDT

Bill ingItemID <pi>

Subscription

SubscriptionIDBeginDateEndDateCanExceedExceedFeeExceedCountMaxTimeMaxDataInMaxDataOutMaxHitsMaxTxEnabled

<pi> IDTDTBLDC10,2IIIIIIBL

SubscriptionID <pi>

Restriction

RestrictionIDRestrictionNameDescriptionEnabled

<pi> IVA200VA200BL

RestrictionID <pi>

Parameter

ParameterIDParameterNameParameterSourceParameterType

<pi> IVA50VA200VA50

ParameterID <pi>

RestrictionRule

RuleIDExpressionBoolOperator

<pi> IVA2000VA10

RuleID <pi> BillingData

Bill ingDataIDCreditCardTypeCreditCardNumberCreditCardExpiresBil lNameAddressZipCityCountryBankNameAccountNumber

<pi> IVA50VA50DTVA200VA200VA50VA50VA100VA200VA200

Bil l ingDataID <pi>

AccessType

AccessTypeIDAccessTypeEnabled

<pi> IVA20BL

AccessTypeID <pi>

Prov isionUnit

ProvisionUnitIDUnitUnitSourceDescription

<pi> IVA50VA50VA200

ProvisionUnitID <pi>

SumData

SumDataIDTotalTimeTotalDataInTotalDataOutTotalHitsTotalTxHashValue

<pi> IIIIIIVA2000

SumDataID <pi>

#��%��$�'��%�$!��%��!��

Model CDM je entitetni diagram, ki je neodvisen od ciljnega podatkovnega strežnika. Pri generiranju ciljne relacijske podatkovne baze se entitete preslikajo v fizi�ne tabele, relacije pa v referen�ne integritete med tabelami.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

Entitete s slike 34 lahko lo�imo v razli�ne skupine: 1. Šifranti

� AccessType: tip dostopa do storitve (anonimni, varnostni žeton,..). � BillingModel: obra�unski model oz. interval (dnevni, tedenski, mese�ni,..). � Restriction: tipi omejitev za dostop do spletnih storitev (datum, podatki, naslov IP,

število dostopov). � Parameter: parametri za omejitev dostopa do spletnih storitev.

2. Uporabniki sistema (odjemalci, ponudniki) � UserData: skupni podatki za obe skupine uporabnikov (generalizacija) – nadrejena

entiteta. � Provider: podatki o ponudniku storitev (specializacija nadrejene entitiete UserData). � Consumer: podatki o odjemalcu storitev (specializacija nadrejene entitiete UserData). � BillingData: podatki za izstavljanje ra�unov (faktur) uporabnikom – odjemalcem.

3. Uporaba storitev

� Contract: pogodba med ponudnikom in odjemalcem storitev, je osnova za dostop do storitev, dolo�a pa tudi dogovorjen obra�unski model (interval).

� Subscription: naro�niško razmerje za uporabo storitev z ustreznimi atributi za omejevanje dostopa (eksplicitne omejitve).

� RestrictionRule: vsako naro�niško razmerje lahko vsebuje eno ali ve� dodatnih omejitev, ki so podani kot logi�ni izrazi in se vrednotijo v �asu proženja spletnih storitev.

4. Poslovni modeli

� BusinessModel: podatki oz. opis poslovnih modelov; lahko ga obravnavamo kot vrsto šifranta.

� ProvisionUnit: vsak poslovni model vsebuje eno ali ve� obra�unskih enot, so lahko merljive ali pa ne.

5. Spletne storitve

� Service: vsebuje podatke o spletni storitvi – lokacijo (kon�no to�ko), definicijo WSDL ter atribute veljavnosti. V primeru, da je storitev uvrš�ena v dolo�en register UDDI, vsebuje tudi unikaten klju� storitve v registru UDDI (glej poglavje 2.7).

� Provision: predstavlja na�in vrednotenja (obra�unavanja) po izbranem poslovnem modelu; storitev se lahko obra�una po razli�nih obra�unskih enotah znotraj poslovnega modela, kjer se za vsako enoto dolo�i cena. Ta enititeta je poglavitna pri periodi�nem izvajanju obra�una.

6. Dostopi do storitev (beleženje)

� LogData: vsebuje nabor podatkov, ki se beležijo ob vsakem klicu spletne storitve. Ob tem se vedno izra�una oz. upošteva pravilnost integritete podaktkov (preko ustrezne razpršilne funkcije). Entiteta je osnova za generiranje poro�il in agregacijo vrednosti.

� SumData: predstavlja agregirane vrednosti entitete LogData za vsako naro�niško razmerje; le to se ažurira ob vsakem dostopu. Razlog je v predvsem v hitrosti vrednotenja (obra�una) in možnosti spremljanja nekaterih podatkov v “realnem �asu” tako za ponudnika, kot tudi za odjemalca storitev. Tudi ta entiteta vsebuje mehanizem za integriteto podatkov.

��$��%��!��$��%��!%��%��2��('%4�$��%�)��

��

7. Obra�un � BillingItem: vsebuje obra�unane vrednosti za posameznega odjemalca in spletno

storitev v dolo�enem obdobju. Podatki so osnova za generiranje in izstavitev ra�una (fakture) odjemalcem.

��#��$

��

9. Sklep V tem delu je skozi tehni�ni in poslovni vidik izpeljan prototip programskega ogrodja oz. arhitektura za podporo poslovnim modelom preko spletnih storitev. Vsekakor sam prototip ni univerzalen, ampak predstavlja eno od možnih študij oz. izvedb na podlagi trenutne informacijsko – komunikacijske tehnologije in je v splošnem uporaben za razli�ne poslovne modele. Za razumevanje obravnavane problematike je nujno poglobljeno poznavanje tehni�nih osnov spletnih storitev oz. povezanih tehnologij. Temeljni del spletnih storitev predstvlja jezik XML. Preko pregleda temeljnih pojmov, specifikacij in podatkovnega modela XML (imenski prostori, infoset, XSD) smo prišli do temeljnega dela spletnih storitev – protokola SOAP in ostalih klju�nih tehnologij WSDL in UDDI. Za uspešno uporabo spletnih storitev v poslovnem svetu so omenjene specifikacije premalo – njihovo uporabnost pove�a pojem interoperabilnosti (povezljivosti). To pomeni predvsem povezljivost razli�nih platform (starejših, novejših), programskih jezikov in vsekakor poudarek na varnosti. Povezljivost spletnih storitev dolo�a množica specifikacij, standardov in priporo�il WS-* izdanih s strani organizacij WS-I in OASIS. Velja poudariti, da je precej specifikacij v fazi nenehnega spreminjanja in izboljšav. Tehni�ne osnove spletnih storitev smo uporabili kot izhodiš�e za poglobitev v druga�no vsebino – poslovni vidik spletnih storitev, predvsem z namenom kako z njimi ustvariti dodano vrednost. Izhodiš�no osnovo predstavlja e-poslovanje oz. njegova izpeljanka dinami�no e-poslovanje, ki temelji na uporabi (spletnih) storitev znotraj skupne infrastrukture in odprtih standardov. V ospredje postavlja storitev kot osnovno enoto za u�inkovito interakcijo med poslovnimi subjekti (B2B, B2C). Poglavitni �len za uvedbo dinami�nega e-poslovanja sloni na konceptu storitveno usmerjene arhitekture (SOA). Ta definira poglavitne elemente in njihove medsebojne relacije (spletne storitve, ponudnik, odjemalec storitev). To ponuja za�etni poligon za identifikacijo potrebnih elementov sistema za realizacijo dodane vrednosti s spletnimi storitvami. Za njeno realizacijo je v splošnem potreben ustrezen mehanizem – poslovni model, ki povezuje potenciale tehnologije z realizacijo ekononmskih u�inkov – dodane vrednosti. Nekateri izmed množice poslovnih modelov, predvsem transakcijski in naro�niški, so uporabni znotraj arhitekture SOA. Sicer ne podajajo neposredne povezave med spletnimi storitvami in dodano vrednostjo, realizacija je odprta in tukaj je potrebno dolo�iti osnovne gradnike (entitete) za sistem spletnih storitev za podporo omenjenih poslovnih modelov- entitete so poslovni model, spletna storitev, ponudnik storitev, odjemalec storitev in dodana vrednosti. Slede�i korak je smiselna povezava naštetih entitet v logi�ni model, ki predstavlja enega od možnih na�inov predstavitve poslovnega modela kot vmesnega �lena med spletnimi storitvami in dodano vrednostjo. Predvsem gre za princip, da je poslovni model dolo�en predpis za ustvarjanje dodane vrednosti preko uporabe spletnih storitev. V osnovi je poslovni model sestavljen iz vrednostnih enot, ki jih je mogo�e meriti in ustrezno ovrednotiti (obra�unati) za vsako spletno storitev. Predstavljeni model je osnova za na�rt programske arhitekture za vrednotenje spletnih storitev znotraj razli�nih poslovnih modelov. Vsekakor je nujno upoštevati tudi tehni�ne specifikacije in standarde spletnih storitev, predvsem glede varnosti. Implementirana programska rešitev na programski platformi .NET predstavlja prototip in ni univerzalna rešitev. Obenem velja poudariti, da bi ekvivalenten prototip lahko razvili tudi na platformi J2EE, vendar zaradi

��#��$

��

boljše podpore specifikacijam in standardom WS-*, je smotrneje uporabiti .NET in dodatek WSE2 za podporo standardom WS-* (glej poglavje 5). V �asu pisanja tega dela je na voljo že naslednja verzija dodatka WSE3, ki podpira nove specifikacije in standarde za interoperabilne spletne storitve. Ta je samo korak od nove univerzalne komunikacijske platforme Indigo1 podjetja Microsoft, ki bo vsebovala vse poglavitne tehnologije za gradnjo porazdeljenih rešitev, predvsem v smislu storitveno usmerjenih arhitektur. Pri�ujo�e delo podaja enega od možnih na�inov kako uporabiti tehnologijo spletnih storitev za ustvarjanje dodane vrednosti preko uporabe razli�nih poslovnih modelov. Programska rešitev je samo ideja in podlaga za nadaljnje izboljšave, npr. opis poslovnih modelov in razli�nih metrik za vrednotenje preko ustreznega formalnega opisnega jezika, kar bi naredilo sistem bistveno bolj fleksibilen in odprt (dobro izhodiš�e predstavlja �lanek [93]). Možna izboljšava bi bila tudi v smislu povezovanja ve� spletnih storitev [96] za izvajanje dolo�enih poslovnih procesov preko jezika BPEL4WS.

1 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/introindigov1-0.asp

6�)��

�""

Zahvala Iskreno se zahvaljujem somentorju izr. prof. dr. Denisu Tr�ku in mentorju prof. dr. Saši Divjaku za vso izkazano zaupanje, strokovno vodstvo, vedno koristne nasvete, pripombe in vsestransko pomo� pri izdelavi magistrske naloge. Obenem se zahvaljujem tudi vsem prijateljem, ki so me spodbujali, da sem zaklju�il to delo. �eprav besede v takih primerih nekako izgubijo svojo mo�, se svojim Staršem in Bratu zahvaljujem za vse. Ampak prav vse!

Damjan Kova�

��*�

�"�

Priloge Priloga 1: Paket “WSControlUI” (WSControl.UI.Web) Priloga 1.1: Paket “WSControlUI” (WSControl.UI.Web.Consumer) Priloga 2: Paket “WebControls” (WSControl.UI.Web.WebControls) Priloga 3: Paket “Common” (WSControl.Common) Priloga 4: Paket “Exceptions” (WSControl.Exceptions) Priloga 5: Paket “ExceptionHandling” (WSControl.ExceptionHandling) Priloga 6: Paket “BusinessEntities” (WSControl.BusinessEntities) Priloga 7: Paket “CustomTokenManager” (WSControl.Framework.CustomTokenManager) Priloga 8: Paket “SOAPInterceptor” (WSControl.Framework.SOAPInterceptor) Priloga 9: Paket “BusinessLogic” (WSControl.BusinessLogic) Priloga 10: Paket “ExpressionEvaluator” (WSControl.Framework.ExpressionEvaluator) Priloga 11: Paket “DataHelper” (WSControl.DataHelper) Priloga 12: Fizi�ni podatkovni model za Microsoft SQL Server® 2000 Priloga 13: Ekran s funkcijami za vlogo ponudnika storitev Priloga 14: Ekran s funkcijam za vlogo odjemalca storitev Priloga 15: CD medij z izdelano programsko opremo

��*�

�"�

Priloga 1: Paket “WSControlUI” (WSControl.UI.Web)

tabMenu

uds

user

rrds

restrictionRule

keyCol

<<Unresolv ed Class>>

Page(UI)

<<Unresolved Class>>HttpApplication

(Web)

<<Unresolved Class>>UserControl

(UI)

UserDataSet(BusinessEntities)

++++

DataSetUserDataConsumerProvider

: DataSet: DataTable: DataTable: DataTable

+++++

UserDataSet ()get_DataSet ()get_UserData ()get_Consumer ()get_Provider ()


User(BusinessLogic)

----------------

SQL_VALIDSQL_CONSUMER_COLSQL_CONSUMER_COL_IDSQL_CONSUMER_ALLSQL_CONSUMER_ROW_IDSQL_USERDATAC_ALLSQL_USERDATAC_ROW_IDSQL_CONSUMERDISPLAY_ALLSQL_CONSUMERDISPLAY_ROW_IDSQL_PROVIDER_COLSQL_PROVIDER_COL_IDSQL_PROVIDER_ALLSQL_PROVIDER_ROW_IDSQL_USERDATAP_ALLSQL_USERDATAP_ROW_IDSQL_CONSUMERLIST_ROW

: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string

+++++++++++++++

User ()GetConsumerList (..)GetConsumer (..)GetConsumer (..)GetConsumerDisplayData (..)GetProviderList (..)GetProvider (..)GetProvider (..)GetConsumerListForProvider (..)CheckWebLogin (..)CheckServiceLogin (..)ProcessConsumer (..)ProcessConsumer (..)ProcessProvider (..)ProcessProvider (..)

: DataSet: UserDataSet: UserDataSet: DataSet: DataSet: UserDataSet: UserDataSet: DataSet: string: UserInfo: string: string: string: string

RestrictionRuleDataSet(BusinessEntities)

++

DataSetRestrictionRule

: DataSet: DataTable

+++

RestrictionRuleDataSet ()get_DataSet ()get_RestrictionRule ()


RestrictionRule(BusinessLogic)

------

SQL_RESTRICTRULE_ALLSQL_RESTRICTRULE_ROW_IDSQL_RESTRICTRULE_ROW_PARIDSQL_RESTRICTRULE_ROW_RESIDSQL_RESTRICTRULE_ROW_SUBIDSQL_RESTTRICRULE_ROW_SUBID_PARID_RESID

: string: string: string: string: string: string

+++++++-

RestrictionRule ()GetRestrictionRule (..)GetRestrictRuleByParameterId (..)GetRestrictRuleByRestrictionId (..)GetRestrictRuleBySubscriptionId (..)GetRestrictRule (..)Process (..)Process (..)

: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: string: string

KeyCollection(BusinessLogic)

-----------

SQL_VALIDSQL_ACCESSTYPE_ALLSQL_ACCESSTYPE_ROW_IDSQL_BILLINGMODEL_ALLSQL_BILLINGMODEL_ROW_IDSQL_BUSINESSMODEL_ALLSQL_BUSINESSMODEL_ROW_IDSQL_PARAMETER_ALLSQL_PARAMETER_ROW_IDSQL_RESTRICTION_ALLSQL_RESTRICTION_ROW_ID

: string: string: string: string: string: string: string: string: string: string: string

+++++++-----

KeyCollection ()GetAccessType (..)GetBill ingModel (..)GetBusinessModel (..)GetRestriction (..)GetParameter (..)Process (..)ProcessAccessType (..)ProcessBill ingModel (..)ProcessBusinessModel (..)ProcessRestriction (..)ProcessParameter (..)

: KeyCollectionDataSet: KeyCollectionDataSet: KeyCollectionDataSet: KeyCollectionDataSet: KeyCollectionDataSet: string: string: string: string: string: string

BasePage

-##----###########

actionDATETIME_FORMATDATE_FORMATsRolesUserNameiCurrentConsumerIdiCurrentProviderIdActionCopyrightInfoIsAuthenticatedUserRoleProviderIdConsumerIdIsConsumerIsProviderUserNameDisplayUserNameAbsoluteUrl

: WSControlUI.BasePage.PageAction: string: string: string: string: int: int: WSControlUI.BasePage.PageAction: string: bool: string: int: int: bool: bool: string: string: string

+#-##++########++++++++++

BasePage ()OnLoad (..)ResolveUser ()GetSortOrder ()Render (..)get_Action ()set_Action (..)GetValue (..)GetValue (..)JavascriptMsgBox (..)JavascriptRedirect (..)HandleException (..)GetNumRows (..)GetInsertedKeys (..)ShortenString (..)get_CopyrightInfo ()get_IsAuthenticated ()get_UserRole ()get_ProviderId ()get_ConsumerId ()get_IsConsumer ()get_IsProvider ()get_UserName ()get_DisplayUserName ()get_AbsoluteUrl ()

: void: void: string: void: WSControlUI.BasePage.PageAction: void: object: string: string: string: void: int: int[]: string: string: bool: string: int: int: bool: bool: string: string: string

DefaultPage

-#-

Page_Load (..)OnInit (..)InitializeComponent ()

: void: void: void

Global

- components : System.ComponentModel.IContainer

+########-

Global ()Application_Start (..)Session_Start (..)Application_BeginRequest (..)Application_EndRequest (..)Application_AuthenticateRequest (..)Application_Error (..)Session_End (..)Application_End (..)InitializeComponent ()

: void: void: void: void: void: void: void: void: void

Login

##

sessionInfoalertInfo

: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.HtmlControls.HtmlGenericControl

-#-


: void: void: void LogoutForm

-#-


: void: void: void

MenuControl

#-----------+++++++++++

menuDatasXmlFilebEnabledsCatNamesCssClasssBgColorsMouseOverColorsMouseOutColoriSelectedItemIndexsSelectedItemColoriWidthsLinkCssXmlFileEnabledCategoryNameCssClassBgColorMouseOverColorMouseOutColorSelectedItemIndexSelectedItemColorWidthLinkCss

: System.Web.UI.HtmlControls.HtmlGenericControl: string: bool: string: string: string: string: string: int: string: int: string: string: bool: string: string: string: string: string: int: string: int: string

++++++++++++++++++++++--#-

get_XmlFile ()set_XmlFile (..)get_Enabled ()set_Enabled (..)get_CategoryName ()set_CategoryName (..)get_CssClass ()set_CssClass (..)get_BgColor ()set_BgColor (..)get_MouseOverColor ()set_MouseOverColor (..)get_MouseOutColor ()set_MouseOutColor (..)get_SelectedItemIndex ()set_SelectedItemIndex (..)get_SelectedItemColor ()set_SelectedItemColor (..)get_Width ()set_Width (..)get_LinkCss ()set_LinkCss (..)Page_Load (..)MenuTable (..)OnInit (..)InitializeComponent ()

: string: void: bool: void: string: void: string: void: string: void: string: void: string: void: int: void: string: void: int: void: string: void: void: Table: void: void

RegisterPage

#######################--###-

txtNametxtCompanytxtCompanyURItxtEmailtxtAddresstxtZIPtxtCitytxtCountrytxtLoginNametxtPwdtxtServiceLogintxtServicePwdtxtValidFromalertInfocbSavetxtValidTojsInforqvalNamerqvalAddressrqvalLoginNamerqvalServiceLoginrqvalValidFromtabMenuudsusersTitlesXmlFileiIndexpageAction

: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.Button: System.Web.UI.WebControls.TextBox: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.RequiredFieldValidator: System.Web.UI.WebControls.RequiredFieldValidator: System.Web.UI.WebControls.RequiredFieldValidator: System.Web.UI.WebControls.RequiredFieldValidator: System.Web.UI.WebControls.RequiredFieldValidator: WSControlUI.TabControl: UserDataSet: User: string: string: int: WSControlUI.BasePage.PageAction

-#--

Page_Load (..)OnInit (..)InitializeComponent ()cbSave_Click (..)

: void: void: void: void

RestrictionRulePage

####-##---

dgridProvUnitalertInfojsInfodlistRestrictRulerrdsdtRestrictiondtParameterrestrictionRulekeyColiSubscriptionId

: System.Web.UI.WebControls.DataGrid: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DataList: RestrictionRuleDataSet: DataTable: DataTable: RestrictionRule: KeyCollection: int

---######---#------

Page_Load (..)GetRestrictionList ()GetParameterList ()GetRestrictionName (..)GetParameterName (..)GetRestrictionSelIndex (..)GetParameterSelIndex (..)GetBoolOperator ()GetBoolOperatorSelIndex (..)BindGrid (..)GetData (..)ProcessData (..)OnInit (..)InitializeComponent ()dlistRestrictRule_DeleteCommand (..)dlistRestrictRule_EditCommand (..)dlistRestrictRule_CancelCommand (..)dlistRestrictRule_ItemCreated (..)dlistRestrictRule_UpdateCommand (..)

: void: DataTable: DataTable: string: string: int: int: DataTable: int: void: RestrictionRuleDataSet: string: void: void: void: void: void: void: void

TabControl

#-----+++++

tabDatasXmlFilesMenuIdiSelectedTabIndexsItemIdbEnabledXmlFileEnabledMenuIdSelectedTabIndexItemId

: System.Web.UI.HtmlControls.HtmlGenericControl: string: string: int: string: bool: string: bool: string: int: string

++++++++++--#-

get_XmlFile ()set_XmlFile (..)get_Enabled ()set_Enabled (..)get_MenuId ()set_MenuId (..)get_SelectedTabIndex ()set_SelectedTabIndex (..)get_ItemId ()set_ItemId (..)Page_Load (..)TabItems (..)OnInit (..)InitializeComponent ()

: string: void: bool: void: string: void: int: void: string: void: void: LiteralControl: void: void

Consumer Prov ider

��*�

�"�

Priloga 1.1: P

aket “WS

ControlU

I” (WS

Control.U

I.Web.C

onsumer)

cds

contract

user

keyCol

crds

service

subds

subscription

service

BasePage(WSControlUI)

-##----###########

actionDATETIME_FORMATDATE_FORMATsRolesUserNameiCurrentConsumerIdiCurrentProviderIdActionCopyrightInfoIsAuthenticatedUserRoleProviderIdConsumerIdIsConsumerIsProviderUserNameDisplayUserNameAbsoluteUrl

: WSControlUI.BasePage.PageAction: string: string: string: string: int: int: WSControlUI.BasePage.PageAction: string: bool: string: int: int: bool: bool: string: string: string

+#-##++########++++++++++

BasePage ()OnLoad (..)ResolveUser ()GetSortOrder ()Render (..)get_Action ()set_Action (..)GetValue (..)GetValue (..)JavascriptMsgBox (..)JavascriptRedirect (..)HandleException (..)GetNumRows (..)GetInsertedKeys (..)ShortenString (..)get_CopyrightInfo ()get_IsAuthenticated ()get_UserRole ()get_ProviderId ()get_ConsumerId ()get_IsConsumer ()get_IsProvider ()get_UserName ()get_DisplayUserName ()get_AbsoluteUrl ()

: void: void: string: void: WSControlUI.BasePage.PageAction: void: object: string: string: string: void: int: int[]: string: string: bool: string: int: int: bool: bool: string: string: string

PageAction

ContractDataSet(BusinessEntities)

++

DataSetContract


+++

ContractDataSet ()get_DataSet ()get_Contract ()


Contract(BusinessLogic)

-------

SQL_VALIDSQL_CONTRACT_ALLSQL_CONTRACT_ROW_IDSQL_CONTRACT_ROW_CONSUMERIDSQL_CONTRACT_ROW_PROVIDERIDSQL_CONTRACTDISPLAY_ALLSQL_CONTRACTDISPLAY_ROW_PROVIDERID

: string: string: string: string: string: string: string

++++++++

Contract ()GetContract (..)GetContractByConsumerId (..)GetContractByProviderId (..)GetContractDisplayByProviderId (..)CheckContract (..)Process (..)Process (..)

: ContractDataSet: ContractDataSet: ContractDataSet: DataSet: int: string: string

User(BusinessLogic)

----------------



+++++++++++++++



KeyCollection(BusinessLogic)

-----------



+++++++-----

KeyCollection ()GetAccessType (..)GetBil l ingModel (..)GetBusinessModel (..)GetRestriction (..)GetParameter (..)Process (..)ProcessAccessType (..)ProcessBill ingModel (..)ProcessBusinessModel (..)ProcessRestriction (..)ProcessParameter (..)


ConsumerReportDataSet(BusinessEntities)

++++++++

DataSetServiceDataProvisionDataLogDataSumDataSubscriptionDataBil lingDataRestrictionData

: DataSet: DataTable: DataTable: DataTable: DataTable: DataTable: DataTable: DataTable

+++++++++

ConsumerReportDataSet ()get_DataSet ()get_ServiceData ()get_ProvisionData ()get_LogData ()get_SumData ()get_SubscriptionData ()get_Bil lingData ()get_RestrictionData ()


Serv ice(BusinessLogic)

----------

SQL_VALIDSQL_SERVICE_ALLSQL_SERVICE_ROW_IDSQL_SERVICE_ROW_URISQL_SERVICE_ROW_PROVIDERIDSQL_SERVICE_ROW_CONTRACTIDSQL_SERVICEDISPLAY_ALLSQL_SERVICEDISPLAY_ROW_IDSQL_SERVICEMODELNAME_ROW_IDSQL_SERVICELIST_ROW

: string: string: string: string: string: string: string: string: string: string

++++++++++++

Service ()GetService (..)GetService (..)GetServiceByProviderId (..)GetServiceByContractId (..)GetServiceDisplay (..)GetServiceModelName (..)GetServiceListForConsumer (..)CheckService (..)CheckService (..)Process (..)Process (..)

: ServiceDataSet: ServiceDataSet: ServiceDataSet: ServiceDataSet: DataSet: DataSet: DataSet: ServiceInfo: ServiceInfo: string: string

SubscriptionDataSet(BusinessEntities)

++

DataSetSubscription


+++

SubscriptionDataSet ()get_DataSet ()get_Subscription ()


Subscription(BusinessLogic)

-------

SQL_VALIDSQL_SUBSCRIPTION_ALLSQL_SUBSCRIPTION_ROW_IDSQL_SUBSCRIPTION_ROW_CONTRACTIDSQL_SUBSCRIPTION_ROW_SERVICEIDSQL_SUBS_ROW_CONSUMERIDSQL_SUBS_ROW_PROVIDERID


+++++++++

Subscription ()GetSubscription (..)GetSubscriptionByContractId (..)GetSubscriptionByServiceId (..)GetSubscriptionDisplayConsumer (..)GetSubscriptionDisplayProvider (..)SubscriptionExists (..)Process (..)Process (..)

: SubscriptionDataSet: SubscriptionDataSet: SubscriptionDataSet: DataSet: DataSet: bool: string: string

ContractPage

###----##

alertInfodgridContractjsInfocdscontractuserkeyColdtProviderListdtBil l ingModelList

: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DataGrid: System.Web.UI.HtmlControls.HtmlGenericControl: ContractDataSet: Contract: User: KeyCollection: DataTable: DataTable

-######---#--------

Page_Load (..)GetProviderList ()GetProviderName (..)GetProviderSelIndex (..)GetBil l ingModelSelIndex (..)GetBil l ingModelList ()GetBil l ingModelName (..)BindGrid (..)GetData (..)ProcessData (..)OnInit (..)InitializeComponent ()dgridContract_SortCommand (..)dgridContract_ItemCreated (..)dgridContract_ItemDataBound (..)dgridContract_CancelCommand (..)dgridContract_EditCommand (..)dgridContract_DeleteCommand (..)dgridContract_UpdateCommand (..)

: void: DataTable: string: int: int: DataTable: string: void: ContractDataSet: string: void: void: void: void: void: void: void: void: void

ReportPage

######-

alertInforptServiceReportjsInfoddlServiceIdcbReportdTotalPricecrds

: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.Repeater: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DropDownList: System.Web.UI.WebControls.Button: decimal: ConsumerReportDataSet

-######--#-#-

Page_Load (..)GetProvisionData (..)GetLogData (..)GetSumData (..)GetBill ingData (..)GetSubscriptionData (..)GetRestrictionData (..)GetServices ()BindDDL ()OnInit (..)Initial izeComponent ()dgridBil l ingData_ItemDataBound (..)cbReport_Click (..)

: void: DataView: DataView: DataView: DataView: DataView: DataView: DataTable: void: void: void: void: void

Serv icePage

###-

alertInfodlistServicejsInfoservice

: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DataList: System.Web.UI.HtmlControls.HtmlGenericControl: Service

---##-####-

Page_Load (..)BindGrid (..)GetData (..)GetModelNames (..)OnInit (..)Initial izeComponent ()SortServiceName (..)SortAccessType (..)SortProvider (..)SortValidFrom (..)dlistService_ItemCommand (..)

: void: void: DataSet: string: void: void: void: void: void: void: void

SubscriptionPage

##############--###-

panelGridcbSavepanelFormalertInfodgridSubscriptionjsInfoddlServiceIdtxtMaxTimetxtMaxDataIntxtMaxDataOuttxtMaxHitstxtMaxTxlblContractIdrqvalServiceIdsubdssubscriptionrqvalBeginDatetxtBeginDatetxtEndDateservice

: System.Web.UI.WebControls.Panel: System.Web.UI.WebControls.Button: System.Web.UI.WebControls.Panel: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DataGrid: System.Web.UI.HtmlControls.HtmlGenericControl: System.Web.UI.WebControls.DropDownList: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.Label: System.Web.UI.WebControls.RequiredFieldValidator: SubscriptionDataSet: Subscription: System.Web.UI.WebControls.RequiredFieldValidator: System.Web.UI.WebControls.TextBox: System.Web.UI.WebControls.TextBox: Service

-----#-----

Page_Load (..)BindDDL (..)BindGrid (..)GetData (..)ProcessData (..)OnInit (..)Initial izeComponent ()dgridSubscription_SortCommand (..)dgridSubscription_ItemCreated (..)dgridSubscription_DeleteCommand (..)cbSave_Click (..)

: void: void: void: DataSet: string: void: void: void: void: void: void

��*�

�"�

Priloga 2: Paket “WebControls” (WSControl.UI.Web.WebControls)

Control(UI)

ControlDesigner(Design)

ListLink

++++---------

ParentListChildListDataRelationEnabledUseReferenceLibraryReferenceLibraryUrlLibraryScriptscriptKeyscriptArrayNameparentListControlchildListControlrelationparentKeys

: String: String: String: Boolean: bool: String: String: String: String: ListControl: ListControl: System.Data.DataRelation: System.Collections.Hashtable

++++++++##+########+++#####--

get_ParentList ()set_ParentList (String value)get_ChildList ()set_ChildList (String value)get_DataRelation ()set_DataRelation (String value)get_Enabled ()set_Enabled (Boolean value)LoadViewState (object savedState)CreateControlCollection ()DataBind ()CreateLink ()OnPreRender (System.EventArgs e)SaveViewState ()ValidateProperties ()ValidateControlPropertiess ()ValidateDataProperties ()RegisterClientScript ()RegisterLibraryScript ()get_UseReferenceLibrary ()get_ReferenceLibraryUrl ()get_LibraryScript ()RegisterRelationScript ()RegisterArrayScript ()RegisterStartupScript ()LoadLinkViewState (object savedState)SaveLinkViewState ()saveChildItemsViewState (Object parentKey)loadChildItemsViewState (Triplet savedState)

: String: void: String: void: String: void: Boolean: void: void: System.Web.UI.ControlCollection: void: void: void: object: void: void: void: void: void: bool: String: String: void: void: void: void: object: Triplet: NameValueCollection

ListLinkDesigner

+ AllowResize : bool

++

GetDesignTimeHtml ()get_AllowResize ()

: string: bool

��*�

�"�

Priloga 3: Paket “Common” (WSControl.Common)

CommonHelper

-++++

CommonHelper ()String2MemoryStream (string _sInput)GetFileContents (string _sFile)GetFileContents (string _sFile, System.Text.Encoding encoding)FormatString (bool _bFlag, string _sSource, object[] _oArgs)

: System.IO.MemoryStream: string: string: string

ConfigHelper

-++

ConfigHelper ()GetConfigValue (string _sConfigFile, string _sKeyName)UpdateConfigValue (string _sConfigFile, string _sKeyName, string _sValue)

: string: void

<<enumeration>>HashType

+++++

MD5SHA1SHA256SHA384SHA512

: int: int: int: int: int

Hash

++++-----

Hash ()GetHash (string _sValue, HashType _hashType)CheckHash (string _sOriginal, string _sHash, HashType _hashType)GetString (byte[] _value)GetMD5 (string _value)GetSHA1 (string _value)GetSHA256 (string _value)GetSHA384 (string _value)GetSHA512 (string _value)

: string: bool: string: string: string: string: string: string

Settings

-----+++++++

sConnectionStringsDbmsTypesBaseUrlsLogAnonymoussCachingEnabledConnectionStringDbmsTypeBaseUrlIsProviderIsConsumerLogAnonymousAccessCachingEnabled

: string: string: string: string: string: string: string: string: bool: bool: bool: bool

--++++++++++

Settings ()Settings ()get_ConnectionString ()set_ConnectionString (string value)get_DbmsType ()set_DbmsType (string value)get_BaseUrl ()set_BaseUrl (string value)get_IsProvider ()get_IsConsumer ()get_LogAnonymousAccess ()get_CachingEnabled ()

: string: void: string: void: string: void: bool: bool: bool: bool

��*�

�"�

Priloga 4: Paket “Exceptions” (WSControl.Exceptions)

AccessException

++#

AccessException (string message)AccessException (string message, Exception inner)AccessException (SerializationInfo info, StreamingContext context)

BadDataException

++#

BadDataException (string message)BadDataException (string message, Exception inner)BadDataException (SerializationInfo info, StreamingContext context)

DataWarningException

++#

DataWarningException (string message)DataWarningException (string message, Exception inner)DataWarningException (SerializationInfo info, StreamingContext context)

SystemException

ApplicationException

��*�

�"�

Priloga 5: Paket “ExceptionHandling” (WSControl.ExceptionHandling)

exceptionLogInfo

IExceptionPublisher(Microsoft.ApplicationsBlocks.ExceptionManagement)

+ Publish (..) : void

EmailPublisher

----

sFromsTosSmtpServersSubject

: string: string: string: string

+-

EmailPublisher ()Publish (..) : void

Ev entLogPublisher

+-

EventLogPublisher ()Publish (..) : void

ExceptionHelper

-+

ExceptionHelper ()HandleException (..) : void

ExceptionLog

--

APP_NAMEexceptionLogInfo

: string: ExceptionLogInfo

+++-+++++

ExceptionLog ()ExceptionLog (..)Fil lExceptionDetail (..)GetExceptionMethod (..)Fil lAditionalInfo (..)GetExceptionDetailText ()LogToEventLog ()LogToTextFile (..)SendToEmail (..)

: void: string: void: string: void: void: void

ExceptionLogInfo

---------------+++++++++++++++

dtDateTimesMessagesExceptionClasssMethodsApplicationsApplicationVersiondtApplicationDateTimesStackTracesNotesexcErrorsMachineNamesAppDomainNamesThreadIdentitysWindowsIdentitysUserNameDateTimeMessageExceptionClassMethodApplicationApplicationVersionApplicationDateTimeStackTraceNotesMachineNameAppDomainNameThreadIdentityWindowsIdentityUserNameException

: DateTime: string: string: string: string: string: DateTime: string: string: Exception: string: string: string: string: string: DateTime: string: string: string: string: string: DateTime: string: string: string: string: string: string: string: Exception

++++++++++++++++++++++++++++++++

ExceptionLogInfo ()ExceptionLogInfo (..)get_DateTime ()set_DateTime (..)get_Message ()set_Message (..)get_ExceptionClass ()set_ExceptionClass (..)get_Method ()set_Method (..)get_Application ()set_Application (..)get_ApplicationVersion ()set_ApplicationVersion (..)get_ApplicationDateTime ()set_ApplicationDateTime (..)get_StackTrace ()set_StackTrace (..)get_Notes ()set_Notes (..)get_MachineName ()set_MachineName (..)get_AppDomainName ()set_AppDomainName (..)get_ThreadIdentity ()set_ThreadIdentity (..)get_WindowsIdentity ()set_WindowsIdentity (..)get_UserName ()set_UserName (..)get_Exception ()set_Exception (..)

: DateTime: void: string: void: string: void: string: void: string: void: string: void: DateTime: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: Exception: void

TextFilePublisher

- sTextFile : string

+-

TextFilePublisher ()Publish (..) : void

��*�

�"�

Priloga 6: Paket “BusinessEntities” (WSControl.BusinessEntities)

ConsumerReportDataSet

++++++++

DataSetServiceDataProvisionDataLogDataSumDataSubscriptionDataBill ingDataRestrictionData


+++++++++

ConsumerReportDataSet ()get_DataSet ()get_ServiceData ()get_ProvisionData ()get_LogData ()get_SumData ()get_SubscriptionData ()get_Bil l ingData ()get_RestrictionData ()


ContractDataSet

++

DataSetContract


+++

ContractDataSet ()get_DataSet ()get_Contract ()


KeyCollectionDataSet

++++++

DataSetAccessTypeBill ingModelBusinessModelRestrictionParameter

: DataSet: DataTable: DataTable: DataTable: DataTable: DataTable

+++++++

KeyCollectionDataSet ()get_DataSet ()get_AccessType ()get_Bil l ingModel ()get_BusinessModel ()get_Restriction ()get_Parameter ()


Prov iderConsumerReportDataSet

+++++++

DataSetContractDataLogDataSumDataSubcriptionDataRestrictionDataBil l ingData

: DataSet: DataTable: DataTable: DataTable: DataTable: DataTable: DataTable

++++++++

ProviderConsumerReportDataSet ()get_DataSet ()get_ContractData ()get_LogData ()get_SumData ()get_SubcriptionData ()get_RestrictionData ()get_Bil l ingData ()

: DataSet: DataTable: DataTable: DataTable: DataTable: DataTable: DataTable

Prov iderServ iceReportDataSet

++++++

DataSetServiceDataProvisionDataLogDataSumDataBil lingData


+++++++

ProviderServiceReportDataSet ()get_DataSet ()get_ServiceData ()get_ProvisionData ()get_LogData ()get_SumData ()get_Bil l ingData ()


Prov isionDataSet

+++

DataSetProvisionUnitProvision

: DataSet: DataTable: DataTable

++++

ProvisionDataSet ()get_DataSet ()get_ProvisionUnit ()get_Provision ()

: DataSet: DataTable: DataTable

RestrictionRuleDataSet

++

DataSetRestrictionRule


+++

RestrictionRuleDataSet ()get_DataSet ()get_RestrictionRule ()


Serv iceDataSet

++

DataSetService


+++

ServiceDataSet ()get_DataSet ()get_Service ()


Serv iceInfo

-----------------+++++++++++++++++

iServiceIdiAccessTypeIdsServiceNamesDescriptionsEndpointURIsWsdlURIdtValidFromdtValidTobEnabledsKeyUDDIsPlatformsWSPolicyServicesWSPolicyClientsX509SubjectServersX509CertIDServersX509SubjectClientsX509CertIDClientServiceIdAccessTypeIdServiceNameDescriptionEndpointURIWsdlURIValidFromValidToEnabledKeyUDDIPlatformWSPolicyServiceWSPolicyClientX509SubjectServerX509CertIDServerX509SubjectClientX509CertIDClient

: int: int: string: string: string: string: DateTime: DateTime: bool: string: string: string: string: string: string: string: string: int: int: string: string: string: string: DateTime: DateTime: bool: string: string: string: string: string: string: string: string

+++++++++++++++++++++++++++++++++++

ServiceInfo ()get_ServiceId ()set_ServiceId (int value)get_AccessTypeId ()set_AccessTypeId (int value)get_ServiceName ()set_ServiceName (string value)get_Description ()set_Description (string value)get_EndpointURI ()set_EndpointURI (string value)get_WsdlURI ()set_WsdlURI (string value)get_ValidFrom ()set_ValidFrom (DateTime value)get_ValidTo ()set_ValidTo (DateTime value)get_Enabled ()set_Enabled (bool value)get_KeyUDDI ()set_KeyUDDI (string value)get_Platform ()set_Platform (string value)get_WSPolicyService ()set_WSPolicyService (string value)get_WSPolicyClient ()set_WSPolicyClient (string value)get_X509SubjectServer ()set_X509SubjectServer (string value)get_X509CertIDServer ()set_X509CertIDServer (string value)get_X509SubjectClient ()set_X509SubjectClient (string value)get_X509CertIDClient ()set_X509CertIDClient (string value)

: int: void: int: void: string: void: string: void: string: void: string: void: DateTime: void: DateTime: void: bool: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void

SubscriptionDataSet

++

DataSetSubscription


+++

SubscriptionDataSet ()get_DataSet ()get_Subscription ()


UserDataSet

++++

DataSetUserDataConsumerProvider


+++++

UserDataSet ()get_DataSet ()get_UserData ()get_Consumer ()get_Provider ()


UserInfo

----------------++++++++++++++++

iUserDataIdiConsumerIdiProviderIdsLoginNamesPwdHashsServiceLoginsServicePwdHashsNamesCompanysCompanyUrisAddresssZipsCitysCountrydtValidFromdtValidToUserDataIdConsumerIdProviderIdLoginNameLoginPasswordServiceLoginServicePasswordNameCompanyCompanyUriAddressZipCityCountryValidFromValidTo

: int: int: int: string: string: string: string: string: string: string: string: string: string: string: DateTime: DateTime: int: int: int: string: string: string: string: string: string: string: string: string: string: string: DateTime: DateTime

+++++++++++++++++++++++++++++++++++

UserInfo ()get_UserDataId ()set_UserDataId (int value)get_ConsumerId ()set_ConsumerId (int value)get_ProviderId ()set_ProviderId (int value)get_LoginName ()set_LoginName (string value)get_LoginPassword ()set_LoginPassword (string value)get_ServiceLogin ()set_ServiceLogin (string value)get_ServicePassword ()set_ServicePassword (string value)get_Name ()set_Name (string value)get_Company ()set_Company (string value)get_CompanyUri ()set_CompanyUri (string value)get_Address ()set_Address (string value)get_Zip ()set_Zip (string value)get_City ()set_City (string value)get_Country ()set_Country (string value)get_ValidFrom ()set_ValidFrom (DateTime value)get_ValidTo ()set_ValidTo (DateTime value)IsConsumer ()IsProvider ()

: int: void: int: void: int: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: string: void: DateTime: void: DateTime: void: bool: bool

DataSet

��*�

�"�

Priloga 7: Paket “CustomTokenManager” (WSControl.Framework.CustomTokenManager)

CustomUsernameTokenManager

++#

CustomUsernameTokenManager ()CustomUsernameTokenManager (XmlNodeList _nodes)AuthenticateToken (UsernameToken _token) : string

UsernameTokenManager

��*�

��"

Priloga 8: Paket “SOAPInterceptor” (WSControl.Framework.SOAPInterceptor)

SOAPInterceptor

--------

inputCtxoutputCtxiDataInLengthiDataOutLengthsUserNameiLogDataIdiSubscriptionIdbAnonym

: SoapContext: SoapContext: int: int: string: int: int: bool

+++----++-+

SOAPInterceptor ()Init (HttpApplication _httpApp)Dispose ()OnPreRequest (object _sender, EventArgs _args)OnPostRequest (object _sender, EventArgs _args)CheckService (Uri _serviceUri)ThrowSoapException (HttpContext _context, string _sMessage, string _sCode, string _sActor, string _detail)OnPreRequest ()AccessCheck ()ThrowSoapException ()OnPostRequest ()

: void: void: void: void: ServiceInfo: void: void: bool: void: void

IHttpModule

��*�

��

Priloga 9: Paket “BusinessLogic” (WSControl.BusinessLogic)

dh

IDataHelper(DataHelper)

+++++

DbmsDatabaseNameServerVersionDataSourceConnectionString

: DbmsType: string: string: string: string

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

get_Dbms ()GetConnection ()GetConnection (..)GetDbCommand ()GetLastColumnValue (..)GetNextColumnValue (..)GetDBMSTimestamp (..)MaskSqlValue (..)DBMSCurrentDateFunction ()CheckRequiredColumns (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetSqlStatement (..)RetrieveDataReader (..)RetrieveDataReader (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)Fil lDataSet (..)Fil lDataSet (..)Fil lDataSet (..)AnyRowChanges (..)GetInsertStatement (..)GetInsertStatement (..)GetInsertStatement (..)GetSqlStatement (..)get_DatabaseName ()get_ServerVersion ()get_DataSource ()get_ConnectionString ()set_ConnectionString (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)UpdateDataset (..)GetSpParameterSet (..)GetSpParameterSet (..)CacheParameterSet (..)GetCachedParameterSet (..)

: DbmsType: IDbConnection: IDbConnection: IDbCommand: int: int: string: string: string: void: string: string: string: string: string: IDataReader: IDataReader: DataTable: DataTable: DataTable: DataTable: DataSet: DataSet: DataSet: DataSet: void: void: void: bool: string: string: string: string: string: string: string: string: void: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: int: int: int: int: int: int: int: int: int: object: object: object: object: object: object: object: object: object: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: void: IDbDataParameter[]: IDbDataParameter[]: void: IDbDataParameter[]

AccessCheck

-+

iSubscriptionIdSubscriptionId

: int: int

+++

AccessCheck ()Check (..)get_SubscriptionId ()

: bool: int

Billing

- UNIT_SOURCE : IList

+-+++-

Bil l ing ()GetUnitSource ()GetLastProcessedDate ()Rate (..)RateConsumer (..)RateConsumer (..)

: IList: DateTime: int: int: int

BusinessLogicBase

--#

htdhDataHelper

: Hashtable: IDataHelper: IDataHelper

#+#

BusinessLogicBase ()get_DataHelper ()JoinResults (..)

: IDataHelper: string

Contract

-------

SQL_VALIDSQL_CONTRACT_ALLSQL_CONTRACT_ROW_IDSQL_CONTRACT_ROW_CONSUMERIDSQL_CONTRACT_ROW_PROVIDERIDSQL_CONTRACTDISPLAY_ALLSQL_CONTRACTDISPLAY_ROW_PROVIDERID


++++++++

Contract ()GetContract (..)GetContractByConsumerId (..)GetContractByProviderId (..)GetContractDisplayByProviderId (..)CheckContract (..)Process (..)Process (..)

: ContractDataSet: ContractDataSet: ContractDataSet: DataSet: int: string: string

DataLogger

+++

DataLogger ()BeginLog (..)EndLog (..)

: int: int

KeyCollection

-----------



+++++++-----

KeyCollection ()GetAccessType (..)GetBil l ingModel (..)GetBusinessModel (..)GetRestriction (..)GetParameter (..)Process (..)ProcessAccessType (..)ProcessBill ingModel (..)ProcessBusinessModel (..)ProcessRestriction (..)ProcessParameter (..)


Prov ision

-------

SQL_PROVISIONUNIT_ALLSQL_PROVISIONUNIT_ROW_IDSQL_PROVISIONUNIT_ROW_MODELIDSQL_PROVISION_ALLSQL_PROVISION_ROW_IDSQL_PROVISION_ROW_SERVICEIDSQL_PROVISION_ROW_MODELID


++++++++++

Provision ()GetProvisionUnit (..)GetProvisionUnitByModelId (..)GetProvision (..)GetProvisionByServiceId (..)GetProvisionByModelId (..)ProcessProvision (..)ProcessProvision (..)ProcessProvisionUnit (..)ProcessProvisionUnit (..)

: ProvisionDataSet: ProvisionDataSet: ProvisionDataSet: ProvisionDataSet: ProvisionDataSet: string: string: string: string

Report

------------------

SQL_CSERVICEDATASQL_CPROVISIONDATASQL_CLOGDATASQL_CSUMDATASQL_CSUBSCRIPTIONDATASQL_CBILLINGDATASQL_CRESTRICTIONSQL_PSSERVICEDATASQL_PSPROVISIONDATASQL_PSLOGDATASQL_PSSUMDATASQL_PSBILLINGDATASQL_PCCONTRACTDATASQL_PCLOGDATASQL_PCSUMDATASQL_PCSUBSCRIPTIONDATASQL_PCRESTRICTIONDATASQL_PCBILLINGDATA

: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string: string

+++++++-

Report ()GetConsumerData (..)GetConsumerData (..)GetProviderServiceData (..)GetProviderServiceData (..)GetProviderConsumerData (..)GetProviderConsumerData (..)SummarizeTable (..)

: ConsumerReportDataSet: ConsumerReportDataSet: ProviderServiceReportDataSet: ProviderServiceReportDataSet: ProviderConsumerReportDataSet: ProviderConsumerReportDataSet: void

RestrictionRule

------

SQL_RESTRICTRULE_ALLSQL_RESTRICTRULE_ROW_IDSQL_RESTRICTRULE_ROW_PARIDSQL_RESTRICTRULE_ROW_RESIDSQL_RESTRICTRULE_ROW_SUBIDSQL_RESTTRICRULE_ROW_SUBID_PARID_RESID

: string: string: string: string: string: string

+++++++-

RestrictionRule ()GetRestrictionRule (..)GetRestrictRuleByParameterId (..)GetRestrictRuleByRestrictionId (..)GetRestrictRuleBySubscriptionId (..)GetRestrictRule (..)Process (..)Process (..)

: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: RestrictionRuleDataSet: string: string

Serv ice

----------

SQL_VALIDSQL_SERVICE_ALLSQL_SERVICE_ROW_IDSQL_SERVICE_ROW_URISQL_SERVICE_ROW_PROVIDERIDSQL_SERVICE_ROW_CONTRACTIDSQL_SERVICEDISPLAY_ALLSQL_SERVICEDISPLAY_ROW_IDSQL_SERVICEMODELNAME_ROW_IDSQL_SERVICELIST_ROW

: string: string: string: string: string: string: string: string: string: string

++++++++++++

Service ()GetService (..)GetService (..)GetServiceByProviderId (..)GetServiceByContractId (..)GetServiceDisplay (..)GetServiceModelName (..)GetServiceListForConsumer (..)CheckService (..)CheckService (..)Process (..)Process (..)

: ServiceDataSet: ServiceDataSet: ServiceDataSet: ServiceDataSet: DataSet: DataSet: DataSet: ServiceInfo: ServiceInfo: string: string

Subscription

-------

SQL_VALIDSQL_SUBSCRIPTION_ALLSQL_SUBSCRIPTION_ROW_IDSQL_SUBSCRIPTION_ROW_CONTRACTIDSQL_SUBSCRIPTION_ROW_SERVICEIDSQL_SUBS_ROW_CONSUMERIDSQL_SUBS_ROW_PROVIDERID


+++++++++

Subscription ()GetSubscription (..)GetSubscriptionByContractId (..)GetSubscriptionByServiceId (..)GetSubscriptionDisplayConsumer (..)GetSubscriptionDisplayProvider (..)SubscriptionExists (..)Process (..)Process (..)

: SubscriptionDataSet: SubscriptionDataSet: SubscriptionDataSet: DataSet: DataSet: bool: string: string

User

----------------



+++++++++++++++



AccessType

++

ANONYMOUSSECURITYTOKEN

: int: int

BusinessModel

++

TRANSCATIONALSUBSCRIPTION

: int: int

ConsumerType

+ ANONYMOUS : int

BillingType

+++

MONTHLYWEEKLYDAILY

: int: int: int

Prov isionUnit

+ EXCEED : int

��*�

��

Priloga 10: Paket “ExpressionEvaluator” (WSControl.Framework.ExpressionEvaluator)

parameterCollection

boolOperator

BoolOperator

++++

AndOrAndNotOrNot

: int: int: int: int

ExpressionEvaluator

--------++

OPERATOR_TRANSLATORRE_ANDRE_ORRE_ANDNOTRE_ORNOTcompiledCodeparameterCollectioncodeParameterCollectionCode

: Hashtable: string: string: string: string: object: ParameterCollection: string: ParameterCollection: string

+--++++-

ExpressionEvaluator (ParameterCollection _parameterCollection)ConstructEvaluator (ParameterCollection _parameterCollection)ModifyExpression (string _expression, string _pattern, string _operator)Evaluate ()get_ParameterCollection ()set_ParameterCollection (ParameterCollection value)get_Code ()TranslateBoolOperatorToCSharp ()

: void: string: bool: ParameterCollection: void: string: Hashtable

Parameter

-----+++++

parameterNameparameterTypeexpressionboolOperatorparameterValueNameTypeExpressionValueOperator

: string: Type: string: BoolOperator: object: string: Type: string: object: BoolOperator

+++++++++++++

Parameter (string _parameterName, Type _parameterType, string _expression, object _parameterValue, BoolOperator _boolOperator)Parameter ()get_Name ()set_Name (string value)get_Type ()set_Type (Type value)get_Expression ()set_Expression (string value)get_Value ()set_Value (object value)get_Operator ()set_Operator (BoolOperator value)GetBoolOperator (string _sOperator)

: string: void: Type: void: string: void: object: void: BoolOperator: void: BoolOperator

ParameterCollection

++

indexerParameterindexerParameter

: Parameter: Parameter

++++++

ParameterCollection ()get_indexerParameter ()set_indexerParameter (Parameter value)get_indexerParameter ()Add (Parameter parameter)Remove (Parameter parameter)

: Parameter: void: Parameter: int: void

CollectionBase

��*�

��

Priloga 11: Paket “DataHelper” (WSControl.DataHelper)

onlyInstanceonlyInstance

DataHelperFactory

- sDbmsType : string

-++

DataHelperFactory ()GetInstance (..)GetInstance ()

: IDataHelper: IDataHelper

DataHelperMsSql

----+++++

CONNECTION_STRINGTIMESTAMP_FORMATonlyInstanceconnectionStringConnectionStringDbmsDatabaseNameServerVersionDataSource

: string: string: DataHelperMsSql: string: string: DbmsType: string: string: string

--++++-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-++++

DataHelperMsSql ()DataHelperMsSql (..)GetInstance ()GetInstance (..)get_ConnectionString ()set_ConnectionString (..)GlobalReplace (..)get_Dbms ()get_DatabaseName ()get_ServerVersion ()get_DataSource ()GetConnection ()GetConnection (..)GetDbCommand ()GetLastColumnValue (..)GetNextColumnValue (..)GetDBMSTimestamp (..)MaskSqlValue (..)DBMSCurrentDateFunction ()CheckRequiredColumns (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetInsertStatement (..)GetInsertStatement (..)GetSqlStatement (..)GetSqlStatement (..)RetrieveDataReader (..)RetrieveDataReader (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)FillDataSet (..)FillDataSet (..)FillDataSet (..)AnyRowChanges (..)GetInsertStatement (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteXmlReader (..)ExecuteXmlReader (..)ExecuteXmlReader (..)ExecuteXmlReader (..)ExecuteXmlReader (..)ExecuteXmlReader (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)UpdateDataset (..)ConvertFromIDbDataParameter (..)GetSpParameterSet (..)GetSpParameterSet (..)CacheParameterSet (..)GetCachedParameterSet (..)

: DataHelperMsSql: DataHelperMsSql: string: void: string: DbmsType: string: string: string: IDbConnection: IDbConnection: IDbCommand: int: int: string: string: string: void: string: string: string: string: string: string: string: string: IDataReader: IDataReader: DataTable: DataTable: DataTable: DataTable: DataSet: DataSet: DataSet: DataSet: void: void: void: bool: string: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: int: int: int: int: int: int: int: int: int: object: object: object: object: object: object: object: object: object: XmlReader: XmlReader: object: object: object: object: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: void: SqlParameter[]: IDbDataParameter[]: IDbDataParameter[]: void: IDbDataParameter[]

DataHelperOracle

----+++++

CONNECTION_STRINGTIMESTAMP_FORMATonlyInstanceconnectionStringConnectionStringDbmsDatabaseNameServerVersionDataSource

: string: string: DataHelperOracle: string: string: DbmsType: string: string: string

--++++-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----++++

DataHelperOracle ()DataHelperOracle (..)GetInstance ()GetInstance (..)get_ConnectionString ()set_ConnectionString (..)GlobalReplace (..)get_Dbms ()get_DatabaseName ()get_ServerVersion ()get_DataSource ()GetConnection ()GetConnection (..)GetDbCommand ()GetLastColumnValue (..)GetNextColumnValue (..)GetDBMSTimestamp (..)MaskSqlValue (..)DBMSCurrentDateFunction ()CheckRequiredColumns (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetInsertStatement (..)GetInsertStatement (..)GetSqlStatement (..)GetSqlStatement (..)RetrieveDataReader (..)RetrieveDataReader (..)RetrieveDataReader (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)Fi llDataSet (..)Fi llDataSet (..)Fi llDataSet (..)AnyRowChanges (..)GetInsertStatement (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)UpdateDataset (..)TranslateDbParameters (..)TranslateDbParameters (..)TranslateDbParameters (..)ConvertFromIDbDataParameter (..)GetSpParameterSet (..)GetSpParameterSet (..)CacheParameterSet (..)GetCachedParameterSet (..)

: DataHelperOracle: DataHelperOracle: string: void: string: DbmsType: string: string: string: IDbConnection: IDbConnection: IDbCommand: int: int: string: string: string: void: string: string: string: string: string: string: string: string: IDataReader: IDataReader: IDataReader: DataTable: DataTable: DataTable: DataTable: DataSet: DataSet: DataSet: DataSet: void: void: void: bool: string: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: int: int: int: int: int: int: int: int: int: object: object: object: object: object: object: object: object: object: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: void: void: void: void: OracleParameter[]: IDbDataParameter[]: IDbDataParameter[]: void: IDbDataParameter[]

<<enumeration>>DbmsType

++++

MsSqlOracleOleDbOdbc

: int: int: int: int

<<enumeration>>

SqlActionStatus

+++

InsertUpdateDelete

: int: int: int

IDataHelper

+++++

DbmsDatabaseNameServerVersionDataSourceConnectionString

: DbmsType: string: string: string: string

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

get_Dbms ()GetConnection ()GetConnection (..)GetDbCommand ()GetLastColumnValue (..)GetNextColumnValue (..)GetDBMSTimestamp (..)MaskSqlValue (..)DBMSCurrentDateFunction ()CheckRequiredColumns (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetAutoIncrementCol (..)GetSqlStatement (..)RetrieveDataReader (..)RetrieveDataReader (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataTable (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)RetrieveDataSet (..)FillDataSet (..)FillDataSet (..)FillDataSet (..)AnyRowChanges (..)GetInsertStatement (..)GetInsertStatement (..)GetInsertStatement (..)GetSqlStatement (..)get_DatabaseName ()get_ServerVersion ()get_DataSource ()get_ConnectionString ()set_ConnectionString (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteReader (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteNonQuery (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteScalar (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)ExecuteDataset (..)UpdateDataset (..)GetSpParameterSet (..)GetSpParameterSet (..)CacheParameterSet (..)GetCachedParameterSet (..)

: DbmsType: IDbConnection: IDbConnection: IDbCommand: int: int: string: string: string: void: string: string: string: string: string: IDataReader: IDataReader: DataTable: DataTable: DataTable: DataTable: DataSet: DataSet: DataSet: DataSet: void: void: void: bool: string: string: string: string: string: string: string: string: void: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: IDataReader: int: int: int: int: int: int: int: int: int: object: object: object: object: object: object: object: object: object: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: DataSet: void: IDbDataParameter[]: IDbDataParameter[]: void: IDbDataParameter[]

��*�

��

Priloga 12: Fizi�ni podatkovni model za MS SQL Server® 2000

UserDataID = UserDataIDUserDataID = UserDataID

ConsumerID = ConsumerID

ServiceID = ServiceID

ContractID = ContractID

ProviderID = ProviderID




ParameterID = ParameterID

RestrictionID = RestrictionID

UserDataID = UserDataID



Bill ingModelID = Bil lingModelID

AccessTypeID = AccessTypeID

ProviderID = ProviderID

ModelID = ModelID

SubscriptionID = SubscriptionID

ProvisionUnitID = ProvisionUnitID

ModelID = ModelID

SubscriptionID = SubscriptionID

ProvisionUnitID = ProvisionUnitID

Serv ice

ServiceIDAccessTypeIDProviderIDServiceNameDescriptionEndpointURIWsdlURIValidFromValidToEnabledKeyUDDIPlatformWSPolicyServiceWSPolicyClientX509SubjectServerX509CertIDServerX509SubjectClientX509CertIDClient

intintintvarchar(200)varchar(1000)varchar(300)varchar(300)datetimedatetimebitvarchar(200)varchar(20)texttextvarchar(300)varchar(200)varchar(300)varchar(200)

<pk><fk1><fk2>

UserData

UserDataIDLoginNamePwdHashNameCompanyCompanyURIEmailAddressZipCityCountryValidFromValidToEnabled

intvarchar(200)varchar(1000)varchar(200)varchar(200)varchar(200)varchar(200)varchar(200)varchar(50)varchar(50)varchar(100)datetimedatetimebit

<pk>

Prov ider

UserDataIDProviderID

intint

<fk><pk>

Consumer

UserDataIDConsumerIDServiceLoginServicePwdHash

intintvarchar(200)varchar(1000)

<fk><pk>

Contract

ContractIDProviderIDBil lingModelIDConsumerIDValidFromValidToApproved

intintintintdatetimedatetimebit

<pk><fk2><fk3><fk1>

BusinessModel

ModelIDModelNameDescriptionEnabled

intvarchar(200)varchar(1000)bit

<pk>

Prov ision

ProvisionIDServiceIDProvisionUnitIDModelIDUnitPrice

intintintintdecimal(10,2)

<pk><fk1><fk2><fk3>

LogData

LogDataIDServiceIDConsumerIDClientIPClientHostNameStartDateEndDateDataInDataOutHashValue

intintintvarchar(50)varchar(200)datetimedatetimeintintvarchar(2000)

<pk><fk1><fk2> BillingModel

Bil lingModelIDModelNameDescriptionEnabled


<pk>

BillingItem

Bill ingItemIDServiceIDConsumerIDProvisionUnitIDTotalUnitsTotalPriceStartDateEndDateProcessedDate

intintintintintdecimal(10,2)datetimedatetimedatetime

<pk><fk1><fk2><fk3>

Subscription

SubscriptionIDContractIDServiceIDBeginDateEndDateCanExceedExceedFeeExceedCountMaxTimeMaxDataInMaxDataOutMaxHitsMaxTxEnabled

intintintdatetimedatetimebitdecimal(10,2)intintintintintintbit

<pk><fk2><fk1>

Restriction

RestrictionIDRestrictionNameDescriptionEnabled


<pk>

Parameter

ParameterIDParameterNameParameterSourceParameterType

intvarchar(50)varchar(200)varchar(50)

<pk>

RestrictionRule

RuleIDParameterIDRestrictionIDSubscriptionIDExpressionBoolOperator

intintintintvarchar(2000)varchar(10)

<pk><fk1><fk2><fk3>

BillingData

Bil lingDataIDUserDataIDCreditCardTypeCreditCardNumberCreditCardExpiresBil lNameAddressZipCityCountryBankNameAccountNumber

intintvarchar(50)varchar(50)datetimevarchar(200)varchar(200)varchar(50)varchar(50)varchar(100)varchar(200)varchar(200)

<pk><fk>

AccessType

AccessTypeIDAccessTypeEnabled

intvarchar(20)bit

<pk>

Prov isionUnit

ProvisionUnitIDModelIDUnitUnitSourceDescription

intintvarchar(50)varchar(50)varchar(200)

<pk><fk>

SumData

SumDataIDSubscriptionIDTotalTimeTotalDataInTotalDataOutTotalHitsTotalTxHashValue

intintintintintintintvarchar(2000)

<pk><fk>

��*�

��

Priloga 13: Ekran s funkcijami za vlogo ponudnika storitev

��*�

��

Priloga 14: Ekran s funkcijami za vlogo odjemalca storitev

0��%��'��

��

Viri in literatura [1] Osnove XML, Gama System d.o.o., Ljubljana, marec 2004. [2] Bray, T., et al.: Extensible Markup Language (XML) 1.0 (Third Edition), W3C

Recommendation 04 February 2004, W3C, 2004, http://www.w3.org/TR/REC-xml. [3] Skonnard, A.: The Birth of Web Services, MSDN Magazine, October 2002, Microsoft

Corporation, 2004, http://msdn.microsoft.com/msdnmag/issues/02/10/xmlfiles/default.aspx.

[4] Wolter, R.: XML Web Services Basics, Microsoft Corporation, december 2001, http://msdn.microsoft.com /library/en-us/dnwebsrv/html/webservbasics.asp.

[5] Obasanjo, D.: Understanding XML, Microsoft Corporation, julij 2003, http://msdn.microsoft.com/library/en-us/dnxml/html/understxml.asp.

[6] Skonnard, A.: Understanding XML Namespaces, Microsoft Corporation and CMP Media LLC, julij 2002, http://msdn.microsoft.com/library/en-us/dnxml/xml_namespaces.asp.

[7] Cowan, J., et al.: XML Information Set (Second Edition), W3C Recommendation, 4 February 2004, W3C, 2004, http://www.w3.org/TR/xml-infoset.

[8] Gudgin, M.: Understanding Infosets, Microsoft Corporation, julij 2002, http://msdn.microsoft.com/library/en-us/dnxml/html/xmlinfoset.asp.

[9] Skonnard, A.: Understanding SOAP, DevelopMentor, marec 2003, http://msdn.microsoft.com/library/en-us/dnsoap/html/understandsoap.asp.

[10] Box, D., et al.: Simple Object Access Protocol (SOAP) 1.1, W3C Note, May 2000, W3C, 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

[11] Mitra, N.: SOAP Version 1.2 Part 0: Primer, W3C Recommendation 24 June 2003, W3C, 2003, http://www.w3.org/TR/soap12-part0/.

[12] Gudgin, M. et al.: SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation 24 June 2003, W3C, 2003, http://www.w3.org/TR/soap12-part1/.

[13] Van der Vlist, E.: XML Schema, O’Reilly & Associates, Inc., 2002. [14] Skonnard, A.: Understanding XML Schema, DevelopMentor, marec 2003,

http://msdn.microsoft.com/library/en-us/dnxml/html/understandxsd.asp. [15] Christensen, E., et al.: Web Services Description Language (WSDL) 1.1, W3C Note 15

March 2001, W3C, 2001, http://www.w3.org/TR/wsdl. [16] Chinnici, R., et al.: Web Services Description Language (WSDL) Version 2.0 Part 1:

Core Language, W3C Working Draft 3 August 2004, W3C, http://www.w3.org/TR/wsdl20.

[17] Skonnard, A.: Understanding WSDL, Northface University, oktober 2003, http://msdn.microsoft.com/library/en-us/dnwebsrv/html/understandwsdl.asp.

[18] Januszewski, K.: The Importance of Metadata: Reification, Categorization and UDDI, Microsoft Corporation, september 200, http://msnd.microsoft.com /library/en-us/dnuddi/html/impmetadata.asp.

[19] Bellwood, T., et al.: UDDI Version 2.04 API Specification, UDDI Commitee Specification, 19 July 2002, OASIS Open, 2002, http://uddi.org/pubs/ProgrammersAPI_v2.htm.

[20] Riegen, C., et al.: UDDI Version 2.03 Data Structure Reference, UDDI Commitee Specification, 19 July 2002, OASIS Open, http://uddi.org/pubs/DataStructure_v2.htm

[21] Bellwood, T., et al.: UDDI Version 3.0.1, UDDI Spec Technical Commitee Specification, OASIS Open, http://uddi.org/pubs/uddi_v3.htm.

[22] Svoboda, Z.: Web Services Publishing, TheServerSide.COM, oktober 2002, http://www.theserverside.com/articles/article.tss?l=SystinetUDDI.

0��%��'��

��

[23] Bajaj, S. et al.: Web Services Policy Framework (WS-Policy), BEA Systems Inc., IBM Corporation, Microsoft Corporation, SAP AG, Sonic Software, Verisign Inc., september 2004, http://msdn.microsoft.com/ws/2004/09/policy/.

[24] Skonnard, A.: Understanding WS-Policy, Skonnard Consulting, avgust 2003, http://msdn.microsoft.com/library/en-us/dnwebsrv/html/understwspol.asp.

[25] Box, D. et al.: Web Services Policy Assertions Language (WS-PolicyAssertions), Version 1.1, BEA Systems Inc., IBM Corporation, Microsoft Corporation, SAP AG, maj 2003, http://msdn.microsoft.com/ws/2002/12/PolicyAssertions/.

[26] Bajaj, S., et al.: Web Service Policy Attachment (WS-PolicyAttachment), BEA Systems Inc., IBM Corporation, Microsoft Corporation, SAP AG, Sonic Software, Verisign Inc., september 2004, http://msdn.microsoft.com/ws/2004/09/policyattachment/.

[27] Ballinger, K., et al.: Web Services Metadata Exchange (WS-MetadataExchange), BEA Systems Inc., IBM Corporation, Microsoft Corporation, SAP AG, marec 2004, http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf.

[28] Box, D., et al.: Web Services Addressing (WS-Addressing), BEA Systems Inc., IBM Corporation, Microsoft Corporation, SAP AG, Sun Microsystems, avgust 2004, http://msdn.microsoft.com/ws/2004/08/ws-addressing/.

[29] Gudgin, M., et al.: SOAP Message Transmission Optimization Mechanism, W3C Candidate Recommendation, avgust 2004, http://www.w3.org/TR/soap12-mtom/.

[30] Box, D., et al.: Web Services Eventing (WS-Eventing), BEA Systems Inc., Computer Associates International Inc., IBM Corporation, Microsoft Corporation, Sun Microsystems Inc., TIBCO Software Inc., avgust 2004, http://msdn.microsoft.com/ws/2004/08/ws-eventing/.

[31] Žagar, K. (2002): Varnost pri e-poslovanju, Sistem, Nove tehnologije za poslovni svet, priloga revije Monitor 12 (12): 16-20, Mladina d.d., Ljubljana, december 2002.

[32] Seely, S.: Understanding WS-Security, Microsoft Corporation, oktober 2002, http://msdn.microsoft.com/library/en-us/dnwssecur/html/understw.asp.

[33] Chappel, D.: New Technologies Help Make Your Web Services More Secure, MSDN Magazine, April 2003, Microsoft Corporation, 2003, http://msdn.microsoft.com/msdnmag/issues/03/04/ws-security/default.aspx.

[34] Ferguson, D., et al.: Secure, Reliable, Transacted Web Services: Architecture and Composition, IBM Corporation, Microsoft Corporation, september 2003, http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsoverview.asp.

[35] Della-Libera, G., et al.: Security in a Web Services World: A Proposed Architecture and Roadmap, IBM Corporation, Microsoft Corporation, april 2002, http://msdn.microsoft.com/library/en-us/dnwssecur/html/securitywhitepaper.asp.

[36] Nadalin, A., et al.: Web Services Security: SOAP Message Security 1.0 (WS-Security 2004), OASIS Standard 200401, March 2004, OASIS Open, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.

[37] Nadalin, A., et al.: Web Sevices Security Username Token Profile 1.0, OASIS Standard 200401, March 2004, OASIS Open, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf.

[38] Hallam-Baker, P., et al.: Web Services Security X.509 Certifikate Token Profile 1.0, OASIS Standard 200401, March 2004, OASIS Open, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf.

[39] Imamura, T., et al.: XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002, W3C, 2002, http://www.w3.org/TR/xmlenc-core/.

[40] Bartel, M., et al.: XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002, W3C, 2002, http://www.w3.org/TR/xmldsig-core/.

0��%��'��

��

[41] Anderson, S., et al.: Web Services Trust Language (WS-Trust), Version 1.1, BEA Systems Inc., Computer Associates International Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Netegrity Inc., Oblix Inc., OpenNetwork Inc., RSA Security Inc., VeriSign Inc., maj 2004, http://msdn.microsoft.com/ws/2004/04/ws-trust/ .

[42] Anderson, S., et al.: Web Services Secure Conversation Language (WS-SecureConversation), Version 1.1, BEA Systems Inc., Computer Associates International Inc., IBM Corporation, Layer 7 Technologies, Microsoft Corporation, Netegrity Inc., Oblix Inc., OpenNetwork Inc., RSA Security Inc., VeriSign Inc., maj 2004, http://msdn.microsoft.com/ws/2004/04/ws-secure-conversation/.

[43] Della-Libera, G., et al.: Web Services Security Policy Language (WS-SecurityPolicy), Version 1.0, IBM Corporation, Microsoft Corporation, RSA Security Inc., Verisign Inc., december 2002, http://msdn.microsoft.com/ws/2002/12/ws-security-policy/.

[44] Bajaj, S., et al.: Web Services Federation Language (WS-Federation), Version 1.0, IBM Corporation, Microsoft Corporation, RSA Security Inc., BEA Systems Inc., Verisign Inc., julij 2003, http://msdn.microsoft.com/ws/2003/07/ws-federation/.

[45] Della-Libera, G., et al.: Web Services Security Kerberos Binding, IBM Corporation, Microsoft Corporation, december 2003, http://msdn.microsoft.com/ws/2003/12/wsskb/.

[46] Cohen, S., et al.: Reliable Messaging in a Service Oriented Architecture, Microsoft Corporation, marec 2004, http://msdn.microsoft.com/ws/2004/03/ws-rm-soa/.

[47] Box, D., et al.: Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap, IBM Corporation, Microsoft Corporation, marec 2003, http://msdn.microsoft.com/ws/2003/03/ws-rm-exec-summary/.

[48] Bilorusets, R., et al.: Web Services Reliable Messaging Protocol (WS-ReliableMessaging), BEA Systems Inc., IBM Corporation, Microsoft Corporation, TIBCO Software Inc., marec 2004, http://msdn.microsoft.com/ws/2004/03/ws-reliablemessaging/.

[49] Cabrera Felipe, L., et al.: Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity, Microsoft Corporation, junar 2004, http://msdn.microsoft.com/ library/en-us/dnwebsrv/html/wsacoord.asp.

[50] Cabrera Felipe, L., et al.: Web Services Coordination (WS-Coordination), BEA System Inc., IBM Corporation, Microsoft Corporation, september 2003, http://msdn.microsoft.com/ws/2003/09/wscoor/.

[51] Cabrera Felipe, L., et al.: Web Services Atomic Transaction (WS-AtomicTransaction), BEA System Inc., IBM Corporation, Microsoft Corporation, september 2003, http://msdn.microsoft.com/ws/2003/09/wsat/.

[52] Cabrera Felipe, L., et al.: Web Services Business Activity Framework (WS-BusinessActivity), BEA Systems Inc., IBM Corporation, Microsoft Corporation, junar 2004, http://msdn.microsoft.com/ws/2004/01/wsba/.

[53] Ehnebuske, D., et al.: WS-I Overview, Web Services-Interoperability Organization (WS-I), 2003, http://www.ws-i.org/docs/20030115.wsi.introduction.doc

[54] Ballinger, K., et al.: Basic Profile Version 1.0a, Final Specification, Date: 2003/08/08, Web Services-Interoperability Organization (WS-I), 2003, http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html.

[55] Ballinger, K., et al.: Basic Profile Version 1.1, Final Material, 2004-08-08, Web Services-Interoperability Organization (WS-I), 2004, http://www.ws-i.org/Profiles/BasicProfile-1.1.html.

[56] Building Interoperable Web Services: WS-I Basic Profile 1.0, Microsoft Corporation, avgust 2003, http://msdn.microsoft.com/library/en-us/dnsvcinter/html/WSI-BP_MSDN_LandingPage.asp.

0��%��'��

��"

[57] Skonnard, A.: What’s New in WSE 2.0, MSDN Magazine, August 2004, Microsoft Corporation, 2004, http://msdn.microsoft.com/msdnmag/issues/04/08/xmlfiles/toc.asp.

[58] Powell, M.: Programming with Web Services Enhancements 2.0, Microsoft Corporation, maj 2004, http://msdn.microsoft.com/library/en-us/dnwse/html/programwse2.asp.

[59] Smith, D.: WS-Security Drilldown in Web Services Enhancements 2.0, Microsoft Corporation, avgust 2004, http://msdn.microsoft.com/library/en-us/dnwse/html/wssecdrill.asp.

[60] Horrel, S.: Web Services Enhancements 2.0 Support for WS-Policy, DevelopMentor, julij 2004, http://msdn.microsoft.com/library/en-us/dnwse/html/wse2wspolicy.asp.

[61] Le Hors, A., et al.: Document Object Model (DOM) Level 3 Core Specification, Version 1.0, W3C Recommendation 07 April 2004, W3C, 2004, http://www.w3.org/TR/DOM-Level-3-Core.

[62] Clark, J.: XSL Transformations (XSLT), Version 1.0, W3C Recommendation 16 November 1999, W3C, 1999, http://www.w3.org/TR/xslt.

[63] Chesbrogh, H.; Rosenbloom, R. S. (2002): The role of the business model in capturing value from innovation: evidence from Xerox Corporation’s technology spin-off companies, Industrial and Corporate Change 11 (3): 529 – 555, ICC Association, 2002.

[64] Timmers, P. (1998): Business Models for Electronic Markets, Journal on Electronic Markets 8 (2): 3 – 8.

[65] Rappa, M. A. (2004): The utility business model and the future of computing services, IBM Systems Journal 43 (1): 32 – 42.

[66] Gottschalk, K., Graham, S., Kreger, H., Snell, J. (2002): Introduction to Web services architecture, IBM Systems Journal 41 (2): 170-177.

[67] Hagel, J. (2002): Edging into Web Services, The Mckinsey Quarterly, Number 4: 6-15, 2002.

[68] Petrovic, O., Kittl, C., Teksten, R.D. (2001): Developing Business Models for eBusiness, International Conference on Electronic Commerce 2001, Vienna, October 31. – November 4.

[69] Osterwalder, A., Pigneur, Y. (2002): An e-Business Model Ontology for Modeling e-Business, 15th Bled E-Commerce Conference – Constructing the e-Economy, Bled, Slovenia, June 17-19, 2002.

[70] Vasilopoulou K., Pouloudi N., Patronidou S. and Poulymenakou A. (2002): Business models: A Proposed Framework, In Proceedings of the e-Business and e-Work Annual Conference, Prague, Czech Republic, 16-18 October, 2002.

[71] Sahai, A., Machiraju, V., Casati, F. (2002): An Adaptive and Extensible Model for managing Web Services and Business Processes, HP Openview Conference, Malaga, Spain, June 2002.

[72] Pigneur, Y. (2004): The E-business Model Handbook, Université de Lausanne, http://inforge.unil.ch/yp/Pub/00-ebmh.pdf.

[73] Rappa, M. (2004): Managing the digital enterprise – Business models on the Web, http://digitalenterprise.org/models/models.html.

[74] Gisolfi, D. (2001): Web services architect, Part 1: An introduction to dynamic e-business, IBM Corporation, 2001, http://www-106.ibm.com/developerworks/library/ws-arc1/.

[75] Gisolfi, D. (2001): Web services architect, Part 2: Models for dynamic e-business, IBM Corporation, 2001, http://www-106.ibm.com/developerworks/library/ws-arc12.html.

[76] He, H. (2003): What is Service-Oriented Architecture?, September 30, 2003, http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html.

[77] Sprot, D., Wilkes, L. (2004): Understanding Service-Oriented Architecture, Microsoft Corporation, 2004, http://msdn.microsoft.com/library/en-us/dnmaj/html/aj1soa.asp.

0��%��'��

��

[78] Hashimi, S. (2003): Service-Oriented Architecture Explained, O’Reilly Media, Inc., 2004, http://www.ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html.

[79] Kotler, P. (1996): Marketing Management – Trženjsko upravljanje: analiza, na�rtovanje, izvajanje in nadzor, Slovenska knjiga, Ljubljana, 1996.

[80] Mihel�i�, M. (1997): Ekonomika poslovanja za inženirje, Fakulteta za ra�unalništvo in informatiko, Ljubljana, 1997.

[81] Mihel�i�, M. (2002): Poslovne funkcije, Fakulteta za ra�unalništvo in informatiko, Ljubljana, 2002.

[82] Jerman-Blaži�, B. (2001): Elektronsko poslovanje na internetu, Gospodarski vestnik, Ljubljana, 2001.

[83] Cunningham, P., Fröschl, F. (1999): Electronic Business Revolution, Springer, Berlin, 1999.

[84] Sri�a, V., Mueller, J. (2001): Put k elektroni�kom poslovanju, Sinergija nakladništvo, Zagreb, 2001.

[85] Martinez, P. (2000): Models made “e”, IBM Corporation, 2000, http://www.ibm.com/services/innovation/gsee510160000f.pdf.

[86] Dubosson-Torbay, M., Osterwalder, A., Pigneur, Y. (2001): E-Business Model Design, Classification, and Measurements, Thunderbird International Business Review 44 (1), 2002.

[87] CVI, UL Fakulteta za ra�unalništvo in informatiko, UM Fakulteta za elektrotehniko, ra�unalništvo in informatiko, IPMIT: Enotna metodologija razvoja informacijskih sistemov – IV zvezek, Ljubljana, 2001.

[88] Kendall, S. (2001): UML Explained, Addison-Wesley Professional, 2001. [89] Fowler, M., Kendall, S. (1997): UML Distilled, Applying the Standard Object Modeling

Language, Addison-Wesley, 1997. [90] Chen, N. K., Sen, S., Shao Benjamin, B. M., (2005): Strategies for effective Web services

adoption for dynamic e-businesses, Decision Support Systems, In Press, Corrected Proof, Available online 17 June 2005, Elsevier B. V., 2005.

[91] Baghadi, Y., (2005): A business model for deploying Web services: A data-centric approach based on factual dependencies, Information Systems and E-Business Management 3 (2): 151 – 173, Springer-Verlag GmbH, 2005.

[92] Ahsan, M. Syed, (2005): A framework for QoS computation in web service and technology selection, Computer Standards & Interfaces, In Press, Corrected Proof, Available online 3 October 2005, Elsevier B.V., 2005.

[93] Keller, A,. Ludwig, (2003): The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services, Journal of Network and Systems Management 11 (1): 57 – 81, Springer Science Business Media B.V., 2003.

[94] Maamar, Z., Sheng, Z. Q., Benatallah, B., (2004): On Composite Web Services Provisioning in an Environment of Fixed and Mobile Computing Resources, Information Technology and Management 5 (3-4): 251 – 270, Springer Science Business Media B.V., 2004.

[95] Murthy, S. U., Groomer, S. M., (2004): A continous auditing web services model for XML-based accounting systems, International Journal of Accounting Information Systems 5 (2): 139 – 163, Elsevier B. V., 2004.

[96] Benatallah, B., Dumas, M., Sheng Z. S., (2005): Facilitating the Rapid Development and Scalable Orchestration of Composite Web Services, Distributed and Parallel Databases 17 (1): 5 – 37, Springer Science Business Media B. V., 2005.

[97] Naor, M., Pinkas, B., (1998): Secure accounting and auditing on the Web, Computer Networks and ISDN Systems 30 (1-7): 541 – 550, Elsevier Science B. V., 1998.

.��

��

Izjava Podpisani Damjan Kova� izjavljam, da sem magistrsko nalogo izdelal samostojno pod mentorstvom prof. dr. Saše Divjaka in somentorstvom izr. prof. dr. Denisa Tr�ka. Izkazano pomo� drugih sodelavcev sem navedel v zahvali.

Damjan Kova�

Documents

Arhitektura za podporo heterogenih poslovnih modelov s ... · ˇ ˆ Povzetek Spletne storitve ne prinašajo revolucionarnega koncepta in izhajajo iz obstojeih zamisli raunalniških