Service-oriented architecture and Web services

Koko: px
Aloita esitys sivulta:

Download "Service-oriented architecture and Web services"

Transkriptio

1 Service-oriented architecture and Web services 41

2 Application integration Business-to-Consumer (B2C) client is a human user e.g., Application <-> Web browser interactions using HTTP/HTML Business-to-Business (B2B) client is another application interactions e.g., using HTTP/XML, SMTP/XML, etc. 42 Internetiä on käytetty paljon B2C-tyyppiseen kommunikointiin, jolloin sovelluksen asiakas/käyttäjä on ihminen. Käyttö voi tapahtua esimerkiksi selaimen avustuksella. Vaikkapa on-line kauppapaikat ovat esimerkkejä B2C-kommunikoinnista. Internetiä hyödynnetään kuitenkin yhä enenevissä määrin myös B2B-kommunikointiin. Tällöin sovellukset kommunikoivat keskenään. Jotta tämä olisi mahdollistaa, täytyy asiakassovelluksen ja palvelusovelluksen käyttää ennalta sovittua kommunikointimekanismia. B2B-integraatio voi olla tiivis perustuen olemassa oleviin RPC:tä (Remote Procedure Call) tukeviin komponenttiteknologioihin (esim. CORBA, RMI, DCOM) tai löyhä perustuen yksinkertaisempiin teknologioihin. Nämä löyhän integraation sallivat teknologiat ovat usein tekstipohjaisia, esimerkiksi yksinkertainen nimi-arvo pari, XML-pohjainen RPC tai SOAP (Simple Object Access Protocol) viesti. Lisäksi niiden avulla voidaan minimoida palomuuriongelmia (kun käytetään sopivaa protokollaa kuten HTTP). Tällä tosin on luonnollisesti myös kääntöpuolensa erityisesti tietoturvan näkökulmasta.

3 Needs for software integration Business point of view constantly changing requirements efficient utilization of information systems, e.g., costeffectiviness security in information exchange etc. Software engineering point of view contantly changing requirements reuse aspect needs for information exchange efficiency flexiblity etc. 43 Ohjelmistojen integroinnille on tunnetusti tarvetta ja tämä tarve on yhä kasvamassa. Asiaa voidaan tarkastella sekä ohjelmistoteknisestä näkökulmasta että liiketoiminnan näkökulmasta. Liiketoiminnan asettamat vaatimukset ovat tyypillisesti korkean tason vaatimuksia, jotka tavalla tai toisella tarkennetaan tai joista johdetaan teknisiä vaatimuksia. Vaikka linkki näiden välillä onkin, se ei aina ole kovin selvä. Näin ollen vaikka vaatimukset saattaisivatkin kuulostaa samanlaisilta, tarkoitetaan niillä usein eri asioita. Esimerkiksi tehokkuudella liiketoiminnan näkökulmasta tyypillisesti tarkoitetaan kustannustehokkuutta, kun taas ohjelmistoteknisestä näkökulmasta sillä tarkoitetaan esim. suoritusaikaa. Näiden tulkintojen välillä on luonnollisesti kuitenkin yhteys. Vastaavasti ns. metavaatimus eli kyky vastata muuttuviin vaatimuksiin tarkoittaa käytännössä eri asioita teknisesti ja liiketoiminnan näkökulmasta.

4 Integration architectures, service-oriented architectures... Integration architecture defines and describes a way to integrate software systems components or parts of software information needed and used by software systems not necessarily a service point of view Service-oriented architecture an example of integration architecture Dr. Hao He, W3C Web Services Architecture Working Group: Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. uses integration techniques service coordination (possibly dynamically) from other services 44 Seuraavaksi tutustumme lyhyesti kolmeen eri termiin: interaktioarkkitehtuuri, palveluorientoitunut arkkitehtuuri ja Web-palvelu. Interaktioarkkitehtuuri määrittelee ja kuvaa tavan liittää toisiinsa ohjelmistoja, komponentteja, ohjelmistojen osia tai ohjelmistojen tarvitsemia/käyttämiä tietoja. Se ei sinänsä siis edellytä mitään erityistä palvelunäkökulmaa. Palveluorientoitunut arkkitehtuuri (SOA) on puolestaan esimerkki interaktioarkkitehtuurista. Se on siis yksi tapa toteuttaa integraatio. On myös sanottu, että SOA ei sinällään edellytä varsinaisten integraatiotekniikoiden käyttämistä; varsinainen integraatioaspekti tulee esille vasta puhuttaessa (monimutkaisemmista) palveluiden koordinoinnista. Palveluiden koordinoinnilla tarkoitetaan useiden palveluiden kommunikointia koskevia esim. interaktioiden järjestystä koskevia sääntöjä. Sillä siis tähdätään varsinaisten liiketoimintatransaktioiden määräämiseen yksinkertaisen point-to-point kommunikoinnin sijaan. Palveluiden koordinointiin palaamme myöhemmin. Kyseisestä argumentista voi tosin olla montaa mieltä, koska myös yksikertainen palveluiden välinen (point-to-point) viestinvälitys toteuttaa löyhän integraation. Dr. Hao Hen (W3C Web Services Architecture Working Group) esittämää määritelmää palveluorientoituneesta arkkitehtuurista (SOA) pidetään yleisesti hyvänä ja ehkä parhaana määritelmänä. Hen mukaan SOA on arkkitehtuurityyli, jonka tarkoituksena on saavuttaa sovellusten välinen kommunikointi mahdollisimman löysin sidoksin. He määrittelee palvelun edelleen tehtävänä, jonka palvelun tarjoaja tekee palvelun käyttäjän puolesta pyrkien saavuttamaan ko. tehtävältä edellytetyt tulokset.

5 ... and Web services One way to implement SOA WSDL, SOAP REST-like services ebxml In practice and in research these terms get mixed every now and then people talk about integration architectures and serviceoriented architectures as they were the same thing people talk about service-oriented architectures and Web services as they were the same thing 45 Web-palvelut puolestaan tarjoavat tavan toteuttaa SOA. SOA ei sinällään ota kantaa miten kommunikointi toteutetaan. Mikäli toteutus tehdään Web-palvelukonseptin avulla, tarkoitetaan käytännössä WSDL-kielen käyttöä palvelun tietojen kuvaamiseksi ja SOAP-protokollaa varsinaisen kommunikoinnin toteuttamiseksi. Tutustumme näihin kieliin tarkemmin myöhemmin. Vaikka kyseisten kielten käytöstä ollaankin päästy käytännössä sopimukseen, on myös esitetty muita erilaisia näkemyksiä Web-palveluista. Nk. REST-like -palvelut (tai RESTful-palvelut ) toteuttavat kommunikoinnin SOAPia kevyemmin ja tehokkaammin. REST (REpresentational State Trasfer) on alun perin Roy Fieldingin väitöskirjassaan esittämä arkkitehtuurityyli hypermediajärjestelmiä varten. REST käyttää tyypillisesti HTTP-protokollaa (esim. GET ja POST operaatiot) ja se nojautuu määrättyjen standardisemantiikan omaavien korkean tason rajapintaoperaatioiden käyttöön (add, remove, set, get, ). Näin ollen resurssien tarjoamat palvelut tai operaatiot ovat ennalta määrättyjä, toisin kuin perinteisessä Web-palvelukonseptissa. Myös ebxml tarjoaa toisenlaisen, liiketoimintaorientoituneemman näkökulman Web-palveluihin. Näihin molempiin palaamme myöhemmin. Näitä kolmea käsitettä (integraatioarkkitehtuuri, SOA ja Web-palvelut) käytetään käytännössä usein hieman väärin. Esimerkiksi integraatioarkkitehtuurista ja SOAsta puhutaan lähes synonyymeinä. Sama pätee (erityisesti!) SOAn ja Web-palveluiden kohdalla. Termien käytössä kannattaakin olla väärinymmärrysten välttämiseksi huolellinen.

6 SOA - requirements and principles from software engineering point of view As loose dependencies among services as possible aim at minimizing the dependencies, esp. the artificial ones only real dependencies the unity of information should be possible to be defined inside one service, not among several services independent services Late configuration and service binding services are possibly searched at run-time connections between services are formed dynamically at runtime 46 SOAan ja sen toteuttamiseen liittyy joukko vaatimuksia ja periaatteista, joista seuraavaksi käymme läpi tärkeimpiä. SOA pyrkii ratkaisuun, jossa palveluiden välillä on mahdollisimman vähän riippuvuuksia. Jo komponenttiteknologiat pyrkivät tähän aikoinaan, mutta eivät täysin kyenneet sitä toteuttamaan. Riippuvuuksista osa erityisesti nk. keinotekoiset riippuvuudet - on haitallisempia kuin toiset. Keinotekoiset riippuvuudet ovat sellaisia, jotka eivät ole välttämättömiä ja jotka usein johtuvat esim. valituista teknologiaratkaisuista. Erityisesti näiden keinotekoisten riippuvuuksien eliminoiminen on tärkeää esimerkiksi ylläpidettävyyden, siirrettävyyden jne. kannalta. Lisäksi tiedon yhtenäisyys tulisi kyetä määrittämään yhden palvelun sisällä, ei monen palvelun kesken. Tämä sallii riippuvuuksien minimoinnin lisäksi myös palveluiden itsenäisyyden. SOA pyrkii myös palveluiden myöhäiseen konfigurointiin ja palveluihin sidontaan. Tavoitteena on erityisesti Web-palvelukonseptissa että palveluita on mahdollista etsiä dynaamisesti ajonaikana. Tämä mahdollistaa palveluiden etsimisen juuri kyseiseen tilanteeseen, kontekstiin ja tarpeeseen. Tämä puolestaan myös edellyttää, että löydettyihin (tai tiedettyihin) palveluihin voidaan muodostaa yhteydet dynaamisesti ajonaikana. Myös myöhäinen konfigurointi ja sidonta osaltaan auttavat palveluiden välisten sidontojen minimoinnissa. Toisaalta ne saattavat aiheuttaa tehokkuusongelmia ajonaikana.

7 SOA - requirements and principles from software engineering point of view Aiming at long living services potentially increases the amount of users if the service is shown to be useful better possibilities for the users to develop ways to manage error situations, interoperability problems etc. Independence from implementation methods and techniques interfaces are important, not how the services have been implemented (c.f. distributed systems) High level of abstraction parties offer services at relatively high level of abstraction 47 Palveluiden tulisi lisäksi olla mahdollisimman pitkäikäisiä. Pitkä ikä lisää potentiaalisesti käyttäjämäärää ja tunnettuutta...mikäli palvelu osoittautuu hyödylliseksi. Lyhytikäiset ja helposti/usein ei-saatavilla olevat palvelut ovat ongelmallisia muiden palveluiden kannalta: ne edellyttävät tarvittavien virheistätoipumismekanismien toteuttamista (esim. palvelun korvaaminen toisella palvelulla), mikä vähintäänkin aiheuttaa tehokkuusongelmia. Pitkäikäiset palvelut puolestaan antavat käyttäjille (asiakasohjelmat) mahdollisuuksia virheiden ja yhteistoiminnallisuusongelmien käsittelyyn. SOAn ja Web-palveluidenkin yksi tärkeimmistä vaatimuksista on toteutusriippumattomuus. Asiakasohjelman kannalta palvelun rajapinta on oleellinen, ei palvelun sisäinen toteutus (vrt. hajautustekniikat). Palveluilla tulisi lisäksi olla melko korkea abstraktiotaso. Tällä hetkellä käydään melko vilkkaasti keskustelua siitä, mikä on palvelun ja toisaalta komponentin (vrt. hajautustekniikat) ero ja mikä on oikea abstraktiotaso palveluille. Tähän ei ole olemassa yksiselitteistä vastausta, vaan asia on riippuvainen kulloisestakin tilanteesta. REST-hengen soveltamisessa palvelupohjaisiin järjestelmiin pyritään (kuten aiemmin todettiin) erityisen korkean abstraktiotason palveluihin edellyttämällä, että palvelun rajapinta tarjoaa ennalta määrätyn joukon (tai sen osajoukon) semantiikaltaan tunnettuja operaatioita. Tällöin pyritään paitsi palveluiden myös itse interaktion korkeaan abstraktiotasoon. Palveluiden ja komponenttien eroa mietittäessä asiaa kannattanee miettiä (myös) asiakassovellusten näkökulmasta. Tällöin voidaan karkeasti sanoa, että komponentteja tarkastellaan tyypillisesti niiden rakenteen kannalta, kun taas palveluita tarkastellaan niiden tarjoaman toiminnallisuuden kannalta.

8 SOA - requirements and principles from software engineering point of view Autonomy services are independent and their management is decentralized in addition to establishing connections, the independent parties may also negotiate and make agreements on the forms of communication dynamically Agile management of requirements ability to react on changing and new requirements ( a meta requirement ) Statelessness If a service needs to retail its state for a longer period of time, its availability to other clients may be impeded Managing state information can also hinder scalability Service composability it should be possible to coordinate and assemble services to form composite services 48 Yksi SOAn periaatteista on pyrkiä autonomisiin palveluihin. Tällä tarkoitetaan käytännössä sitä, että osapuolet ovat itsenäisiä eivätkä ne ole keskitetysti hallittuja. Tältä osin palvelu-orientoituneet systeemit ja ehkä erityisesti Web-palvelut eroavat hajautetuista järjestelmistä. Hajautettua hallintaa korostaen Web-palveluita kutsutaan myös ei-keskitetyiksi. Autonomisuuteen liittyy myös se, että yhteyksien muodostamisen lisäksi itsenäiset osapuolet mahdollisesti myös neuvottelevat ja tekevät sopimuksia kommunikointia koskien, mieluiten dynaamisesti. Esimerkki ketteryydestä vaatimusten hallinnassa on puolestaan kyky reagoida muuttuviin ja uusiin vaatimuksiin. Tällaista vaatimusta uusiin vaatimuksiin reagoinnista ja niiden hallinnasta kutsutaan myös meta-vaatimukseksi. Tilattomuus on myös nostettu usein esille tärkeänä SOA-suunnitteluperiaatteena. Tilattomuus liittyy oleellisesti myös muihin periaatteisiin, erityisesti tavoitteeseen pyrkiä mahdollisimman löyhiin sidontoihin. Tilattomuus tarkoittaa oleellisesti sitä, että asiakassovelluksilta tulisi edellyttää mahdollisimman vähän etukäteistietoa palvelusta. Palvelukutsu ei esimerkiksi siis saisi riippua palvelun tilasta ja mahdollisesta edellisestä palvelukutsusta. Lisäksi tilainformaation hallinta saattaa haitata sekä palvelun saavutettavuutta että skaalautuvuutta. Yhdeksi SOAn suunnitteluperiaatteeksi mainitaan usein myös palveluiden yhdistettävyys. Tämä tarkoittaa sitä, että palveluita tulisi voida yhdistellä isommiksi palveluiksi, joille niinikään pätevät kaikki SOAn mainitut SOAn vaatimukset ja periaatteet.

9 Service-Oriented Architecture (SOA) Broker Requestor Find Bind Describe, Publish Provider Dr. Hao He, W3C Web Services Architecture Working Group: Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interactive software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. 49 Tämä yleiskuva palveluorientoituneesta arkkitehtuurista on yleisesti käytetty ja sitä kutsutaan toisinaan myös Web-palvelun arkkitehtuuriksi. Sama perusarkkitehtuuri esiintyy useissa eri lähteissä, pienin nimeämismuutoksin varustettuina. Lisäksi riippuvuudet voidaan usein nähdä kaksisuuntaisiksi. SOA ei kuitenkaan ole sama asia kuten edellä todettiin - kuin Web-palvelut; Web-palvelut ovat vain yksi esimerkki SOA:n toteuttamisesta. SOA kuvaa toisin sanoen yleisen mallin eikä ole ainoastaan Webpalveluita varten. Lisäksi tässä arkkitehtuurikuvassa on ennen kaikkea kyse palvelukonseptiin liittyvistä eri rooleista ja niiden riippuvuuksista. Seuraavaksi pureudumme kaavion eri osiin tarkemmin. Esimerkkiskenaario: 1.) Palvelun tarjoaja (Provider) julkistaa palvelun (Publish) 2.) Asiakas (Requestor) etsii haluttua palvelua kutsuen rekisteripalvelua (Broker) 3.) Asiakas saa rekisteripalvelusta vastauksen, jossa kuvataan palvelu ja se miten sitä voidaan käyttää 4.) Asiakas kutsuu palvelua saadun kuvauksen perusteella

10 Provider Provides services e.g., on-line hotel reservation Describes its service (in WSDL) based on the specification prepared by a service Broker describe operation Registers its service with Broker publish operation Requestor is be able to invoke a registered operation (with bind operation) 50 Palvelun tarjoajan tulee kuvata palvelu (describe operaatio) jollain yleisesti käytössä olevalla tavalla. Käytännössä tämä tapa on Web Service Description Language (WSDL), jota käsitellään lisää myöhemmin. Palvelun kuvaus välitetään rekisteriin (publish operaatio), josta asiakkaat voivat sitä hakea. Asiakas voi myöhemmin käyttää palvelun tarjoamia (ja mahdollisesti julkaisemia) operaatioita (bind operaatio).

11 Requestor Looks for services (more precisely: asks a Broker to look for services) and uses them May also create a new service by integrating services provided by Providers e.g., a travel agency using on-line hotel reservation and flight booking services Scenario: 1) invokes Broker to get services of interest (find operation) 2) selects a service/services and then invokes the corresponding Provider(s) (bind operation) Becomes a Provider if it registers itself with Broker hierarchy of services 51 Palvelun käyttäjä (Requestor) voi etsiä haluttuja palveluita rekisteristä antamalla sopivia hakukriteerejä. Saatuaan rekisteriltä vastauksena hakuehtoihin sopivat palvelut, palvelun käyttäjä voi ottaa yhteyttä valitsemaansa palveluun. Rekisteristä saadaan käytännössä palvelujen kuvaukset (WSDL), jotka sisältävät kaiken tarvittavan tiedon: mitä operaatioita on tarjolla, mitä parametrejä ne edellyttävät ja miten palveluun otetaan yhteyttä. On kuitenkin huomioitavaa, että tämä skenaario on vain esimerkki. Palvelun käyttäjän ei luonnollisestikaan tarvitse etsiä palvelua rekisterissä mikäli sillä on jo tarvittavat tiedot palvelun käyttämiseen. Palvelun käyttäjä (Requestor) voi itse asiassa toimia myös palvelun tarjoajan roolissa (Provider): palvelun käyttäjä voi muodostaa uuden palvelun yhdistämällä muita palveluja ja rekisteröimällä tämän uuden korkeatason tai monipuolisemman palvelun. Näin voidaan muodostaa hierarkisia palveluita.

12 Broker Registers service descriptions submitted by Providers (e.g., using UDDI) publish operation Looks for services (i.e., executes a search) when asked find operation e.g., a travel search site for finding hotels according to given preferences Defines the service description format and an API for registering and searching services It is actually also a Provider 52 Rekisteri (esimerkiksi UDDI rekisteri) sisältää joukon palvelujen julkaisemia kuvauksia. Se kategorisoi kuvaukset, jotta niiden etsintä eri kriteerein olisi joustavaa. Palvelun julkaiseminen ja toisaalta palvelujen etsiminen tapahtuu määriteltyjen operaatioiden avulla. Rekisterin tulee määritellä palvelun kuvaus ja API täsmällisesti, koska niitä tulee voida käyttää muista sovelluksista käsin (ei siis tarkoitettu ihmisten luettaviksi). Myös rekisteri voidaan nähdä itse asiassa palvelun tarjoajana: sen tarjoama palvelu on palvelurekisteri, jolta voidaan kysellä muita palveluja ja niiden yhteystietoja.

13 Selectively and briefly on recent history of software engineering The development of programming languages OO paradigm Components and program distribution an abstraction level for programmers a natural way to think of and manage program concepts (classes, objects) and their relationships and thus the program structures a simple thing in principle but the component technologies themselves (RMI, (D)COM, CORBA, ) offer interesting features possibility to use components/subsystems as black boxes (the interface is essential) the programmers need to handle the interoperability problems and configuration challenges 53 Ohjelmistuotannon välineiden ja ohjelmointikielten kehityksessä abstraktiotason nosto on aina näytellyt merkittävää osaa, eikä ole mitään syytä olettaa tähän trendiin tulevan muutosta jatkossakaan. Esimerkiksi ohjelmointikielten kehitys yleisesti on pyrkinyt tarjoamaan ohjelmoijille korkeamman ja ohjelmoijaystävällisemmän abstraktiotason ohjelmien kirjoittamiseksi. Olioperustainen ohjelmistokehitys (ja olioperustaiset ohjelmointikielet) tarjosivat/tarjoavat luonnollisen tavan ajatella ohjelmien käsitteitä (luokat ja oliot) ja niiden suhteisiin perustuvaa ohjelmien rakennetta. Komponentit ja hajautustekniikat edelleen tarjoavat korkeamman abstraktiotason oliokieliinkin verrattuna. Hajautus on periaatteessa yksinkertainen asia mutta eri komponenttiteknologioilla (RMI, (D)COM, CORBA, ) on kiinnostavia ominaisuuksia. Ensinnäkin ne sallivat integroitavien komponenttien/alisysteemien käsittelemisen mustana laatikkona (rajapinta oleellinen). Komponenttien yhteiskäyttöön ja niiden konfigurointiin liittyvät ongelmat on käytännössä jätetty ohjelmoijien ratkottaviksi. Mikä tulee siis olemaan seuraava abstraktiotason nosto? Jos se on SOA, niin miten se eroaa periaatteellisella tasolla hajautustekniikoista?

14 What s new in SOA then? A pure software architecture point of view In principle, SOA is not very interesting and it does not seem to offer that much new (c.f. component technologies) However, loose coupling can be implement in an interesting way using e.g. Web service technologies an agreement on Web service standars more or less: WSDL, SOAP, and possibly others (e.g. UDDI) not just for RPC document-style communication one goal is to distribute not only the services but also their management decentralized applications SOA can be considered a step to the next abstraction level components -> services 54 Mitä uutta SOA tarjoaa olemassa oleviin ajattelutapoihin ja tekniikoihin verrattuna? Jos asiaa tarkastellaan puhtaasti ohjelmistoarkkitehtuurisesta näkökulmasta, ei SOA periaatteessa vaikuta kovinkaan kiinnostavalta eikä e näytä tarjoavan oleellisesti paljonkaan uutta (vrt. hajautusteknologiat). Edellä mainitut SOAn periaatteet ja vaatimukset voidaan hyvin pitkälle katsoa samoiksi odotuksiksi ne, joita hajautustekniikoilta aikoinaan odotettiin ja edellytettiinkin: korkea abstraktiotaso, toteutuskielija/tai alustariippumattomuus, autonomisuus, mahdollisimman löyhät sidonnat, tavoitteena itsenäiset ja pitkäikäiset komponentit, ketteryys vaatimusten hallinnassa jne. Hajautustekniikat eivät kuitenkaan kyenneet kovin hyvin vastaamaan näihin haasteisiin. SOAlta ja Web-palveluilta odotetaankin paljon näiden haasteiden näkökulmasta. Esimerkiksi löyhät sidonnat voidaan toteuttaa mielenkiintoisesti Webpalveluteknologioita hyödyntäen, joista käytännössä ollaan päästy sopimukseen (WSDL ja SOAP, näihin palataan myöhemmin). Lisäksi muitakin eroja tuntuu löytyvän. SOAa ja Web-palveluita ei ole tarkoitettu vain RPC-tyyppiseen kommunikointiin. Lisäksi tavoitteena on paitsi ohjelmiston myös niiden hallinnan hajautus. SOA voidaankin kuitenkin katsoa tietynlaiseksi hypyksi seuraavalle abstraktiotasolle (komponentit -> palvelut).

15 What s new in then SOA? A broader point of view brings the software engineering and business points of views closer to each other! not that clear before (c.f. OO and component technologies) systems consist of service that have their own business processes business processes and their comprehension as well as understanding the requirements are essential in the development of services care and attention is needed when talking about the concepts and terms: e.g. service and architecture from software engineering and business points of views 55 SOAa ei kuitenkaan kannata eikä pidä tarkastella vain puhtaasta ohjelmistotuotannollisesta näkökulmasta. SOAn ehkäpä suurin uutuusarvo on siinä, että se tuo ohjelmistoteknistä ja liiketoimintaorientoitunutta näkökulmaa lähemmäksi toisiaan, tai ainakin se mahdollistaisi tämän. Tämä ei ole ollut yhtä selvästi näkyvissä ennen (vrt. olioperustaisuus tai hajautustekniikat). SOA mahdollistaa palveluekosysteemit (kuten niitä usein kutsutaan), jotka koostuvat palveluista, joilla omat liiketoimintaprosessit. Tällöin liiketoimintaprosessien ja niiden vaatimusten ymmärtäminen oleellista palveluiden toteuttamisessa. Osittain tämän vuoksi, kuten aiemmin mainittiin, oleellisena erona komponenttiteknologioihin verrattuna on se, että komponentteja tarkastellaan yleensä niiden rakenteen kannalta, kun taas palveluita tulisi tarkastella niiden tarjoaman toiminnallisuuden kannalta. Käsitteiden kanssa on syytä kuitenkin olla huolellinen: esim. palvelu ja arkkitehtuuri tarkoittavat eri asioita ohjelmistokehityksen ja liiketoiminnan näkökulmista. Myös esimerkiksi tehokkuudella ja uudelleenkäytöllä on eri implikaatiot: ohjelmistotekniikan kannalta nämä termit ovat tuttuja, mutta liiketoiminnan näkökulmasta näillä viitataan usein tehokkaaseen informaatiojärjestelmien hyödyntämiseen ja esim. kustannus-hyötytehokkuus analyyseihin.

16 SOA and Web services Web services offer one way to implement SOA SOA and Web services aim at automatically solving problems related to interoperability, configuration etc. an agreement on the standards partly enables this challenges: a whole range of standards possible problems: nobody really knows the code, what if there is a need to understand the code. genericity/flexibility vs. automation A lot of tool support for building Web services and client applications varying features support for Web service languages and recommendations, and their different versions varies 56 Kuten aiemmin todettiin, Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin palaamme myöhemmin. On kuitenkin todettava, että Webpalvelustandardeihin liittyy myös paljon ongelmia. Toisaalta nämä standardit kehittyvät jatkuvasti ja toisaalta esimerkiksi palveluiden koordinointiin liittyen ei standardeista olla aivan vielä päästy vastaavaan yhteisymmärrykseen. Tosin juuri tällä hetkellä näyttää siltä, että tämäkin ongelma on ratkeamassa. Sanaan standardi kannattaakin yleisesti suhtautua varauksellisesti Web-palveluihin liittyvistä teknologioista puhuttaessa: kyseessä saattaa olla lähinnä ehdotus eikä varsinaisesti standardi. SOA ja Web-palvelut pyrkivät periaatteessa ratkaisemaan yhteentoimivuuteen, konfigurointiin jne. liittyvät ongelmat automaattisesti ja vieläpä ajonaikana. Esimerkiksi mikäli kutsuttavaa palvelua ei ole saatavilla tai yhteentoimivuusongelmia ilmenee, tulisi kutsuvan palvelun kyetä joko ratkomaan yhteentoimivuusongelmat tai korvaamaan ko. palvelu toisella vastaavan toiminnallisuuden omaavalla palvelulla. Tämä on kuitenkin vielä useissa tapauksissa kaukana käytännön toteutuksista siitä huolimatta, että useista standardeista onkin päästy jo yksimielisyyteen. Automaattisuuteen liittyy myös omat ongelmansa. Esimerkiksi muutosten tekeminen manuaalisesti voi olla vähintäänkin haasteellista.

17 Tällä hetkellä on olemassa runsaasti työkalutukea Web-palveluiden ja asiakassovellusten tekemiseksi ja osin generoimiseksi. Esimerkiksi palvelun rajapintakuvaus (WSDL) voidaan generoida automaattisesti palvelun rajapinnan (esim. Java) perusteella. Nämä työkalut kuitenkin poikkeavat toisistaan sekä tarjottujen ominaisuuksien että toteutustapojen suhteen. Esimerkiksi samasta rajapinnasta (esim. Java) eri työkalut generoivat erilaisia WSDL-kuvauksia. Lisäksi eri työkalujen tarjoama tuki eri Webpalvelukielille, niiden eri versiolle ja eri suosituksille vaihtelee.

18 Defining Web services W3C puts it: programmatic interfaces made available for application to application communication are referred to as Web services...or more precisely: A Web service is a collection of functions packaged as a single entity and published to the network for use by other applications -> a hierarcy of Web services: more complicated ones are aggregated from simpler ones or perhaps: XML applications mapped to programs, objects, databases, or business functions 57 Web-palveluille on esitetty lukuisia määritelmiä. Yksinkertaisimmillaan niiden on sanottu olevan sovelluksia, joihin voidaan ottaa yhteys käyttäen standarditeknologioita (kuten XML ja HTTP). On myös sanottu, että Web-palvelu on käytännössä sama asia kuin SOAP-protokollan käyttö (tästä lisää myöhemmin). Nämä eivät kuitenkaan ole kovin hyviä määritelmiä, sillä ne ovat aivan liian laajoja. W3C puolestaan määrittelee Web-palvelun (vapaasti käännettynä) joukkona ohjelmiin liittyviä rajapintoina, jotka ovat käytettävissä sovellusten välisessä kommunikoinnissa. Tämäkin määritelmä on melko yleinen. Hieman tarkemmin määriteltynä Web-palvelun on sanottu olevan joukko funktioita, jotka on pakattu yhdeksi kokonaisuudeksi ja julkaistu verkossa muiden sovellusten käytettäväksi. Tämä määritelmä on jo selvästi parempi. Oleellista tässä on se, että näitä tarjottuja funktioita voidaan yhdistellä ja pakata uusiksi palveluiksi. Se myös implikoi Web-palveluille hyvin oleellisen piirteen: Webpalveluhierarkian. Toisin sanoen yksinkertaisimmista palveluista voidaan koostaa monimutkaisempia palveluita. Toinen oleellinen asia tässä määritelmässä on palveluiden julkaiseminen. Jotta Web-palvelu olisi aidosti vapaasti etsittävissä ja käytettävissä, edellyttää se, että palveluiden käyttäjät voivat etsiä palveluita jostain yleisesti tunnetusta markkinapaikasta.

19 Viimeinen määritelmä kuvaa Web-palvelut XML-sovelluksina, jotka on sidottu joihinkin ohjelmiin, tietokantoihin tai liiketoimintafunktioihin. Web-palveluissa käytetään XML-pohjaisia kieliä, mutta palveluiden kutsuminen XML-sovelluksiksi voi olla myös harhaanjohtavaa. Tässä määritelmässä oleellista on se, että itse palvelun toiminnallisuus voi mitä vain ja se on voitu toteuttaa millä tahansa halutulla tavalla. Palvelun käyttöä varten tulee kuitenkin toteuttaa käytettäviä standardeja ymmärtävä ja käsittelevä interaktiota tukeva kerros. Web-palvelukonseptin voidaan ajatella olevan myös mekanismi back-end systeemien paketoimiseksi (wrapping). Tällaisia back-end systeemejä voivat olla vaikkapa tietokanta, legacy-systeemi jne. Käyttäessään Web-palvelua ohjelma lähettää pyynnön/kyselyn XML-muodossa ja yleensä myös vastaanottaa vastauksen niin ikään XML-muodossa. Jotta kommunikaatio olisi mahdollista, täytyy viestien formaatista ja käytettävän palvelun rajapinnasta sopia. Tämän lisäksi tulee sopia siitä mekanismista, joka määrittelee miten Web-palveluja tulee julkistaa ja miten niitä voidaan etsiä.

20 A vision of Web services Software will be assembled from a web of services Building applications just-intime Discovering and coordinating services on the Web dynamically From distributed systems to de-centralized applications PC Mobile phone PDA 58 Web-palveluiden alkuperäisen ja tavoiteltavan vision mukaisesti palveluja tulisi voida etsiä ja niitä tulisi voida käyttää dynaamisesti. Tietyn palvelun käyttöön sitominen tulisi siis olla ajonaikainen (dynaaminen) toimenpide, ei staattinen. Sovelluksia tulisi voida muodostaa olemassa olevia palveluita hyödyntäen aina kulloisenkin tarpeen mukaisesti. Nämä yhdessä edellyttävät lisäksi sen, että palveluiden koordinoinnin tulisi myös olla dynaamista. Ehkäpä yksi oleellisimmista näkökulmista on, että Web-paveluiden myötä siirryttäisiin hajautetuista järjestelmistä ei-keskitettyihin järjestelmiin. Tämä merkitsisi sitä, että tarjolla olisi verkko erilaisia (hallinnan näkökulmasta itsenäisiä ja tasavertaisia) palveluita, joita mikä tahansa sovellus voi käyttää ja mahdollisesti yhdistellä uusiksi palveluiksi. Nämä edellä esitetyt visiot ovat luonnollisesti vielä kaukana todellisuudesta. Esimerkiksi tietoturvakysymykset ja käyttöoikeudet asettavat reunaehtoja ja vaatimukia, joita ei vielä yleisellä tasolla olla täysin ratkaistu. Yksittäisiä ratkaisuja ja ratkaisuehdotuksia on esitetty, mutta yhtenäistä periaatetta ja käytäntöjä ei vielä ole. Näin ongelmiin palaamme myöhemmin.

21 Layers of Web services Application services Collaboration services (orchestration, choreographies) SOAP and its extensions (for realibility, transactions etc.), WSDL, UDDI Transport (HTTP, SMTP, FTP, JMS, IIOP, etc.) Utility services (security, transactions, QoS, etc.) 59 Kalvolla esitetyn kuvan alimpana kerroksena ovat viestinvälitysprotokollat. Vaikka Web-palveluita usein sanotaan käyttävän ja näin käytännössä hyvin usein onkin itse Webpalvelukonseptia ei ole sidottu tiettyyn viestinvälitysprotokollaan. Yhtä hyvin käytössä voisi olla esimerkiksi SMTP tai FTP. Kuvan seuraavan kerroksen muodostavat Web-palvelustandardit SOAP, WSDL ja UDDI. Näistä ensimmäistä käytetään kommunikointiin sovellusten kesken. WSDL-kieltä puolestaan käytetään kuvaamaan tarjottu Web-palvelu (tarjotut funktiot ja yhteydenottotapa). UDDI on yksi tapa toteuttaa palveluiden markkinapaikka (rekisteri), mutta muitakin vaihtoehtoja on olemassa. Palvelun mainostaminen markkinapaikassa ei palvelun pystytyksen kannalta toki ole välttämätöntä. Mikäli asiakaskunta tietää miten palveluun saa yhteyden ja miten sitä voidaan kutsua, on se tarpeetonta. Näin on usein esimerkiksi kun Web-palvelukonseptia käytetään rajoitetussa ympäristössä kuten yrityksessä. Tällöin mikäli käyttö tapahtuu palomuurien sisäpuolella, ei kommunikoinnin turvallisuuden takaamiseen tarvitse kiinnittää välttämättä huomiota.

22 Palveluverkosto (esimerkiksi toisiaan käyttävät palvelut) edellyttää palvelujen koordinointia. Koordinointipalvelut on esitetty kuvassa kolmantena kerroksena (collaboration services). Esimerkiksi sekvenssi yksittäisten palvelujen suorittamista operaatiosta voidaan haluta koostaa yhdeksi liiketoimintatransaktioksi. Palveluiden yhdistämiseen käytetään nk. orkestointi- ja koreografiakieliä. Näistä orkestrointi tarkoittaa palveluiden yhdistämistä yhdestä tietystä liiketoimintaprosessia suorittavasta näkökulmasta, kun taas palvelukoreografia sallii useita samanaikaisia ja tasavertaisia näkymiä liiketoimintaprosessiin. Näihin palataan vielä myöhemmin. Lopuksi kuvan ylimpänä kerroksena ovat itse Web-palvelut. Kuvan kaikkia eri kerroksia koskee ja tukee joukko muita hyödyllisiä palveluja (utility services). Jotkin käytetyt ratkaisut koskevat kaikkia kerroksia ja voivat siten vaikuttaa käytettäviin formaatteihin, protokolliin ja API-määrittelyihin tai vaikkapa vaikuttaa niiden valintaan. Turvallisuusaspektit ovat esimerkiksi hyvin tärkeitä Web-palvelujen kannalta (erityisesti liiketoimintakriittiset palvelut). Vaikka SOAP ei tällä hetkellä suoranaisesti tuekaan turvallista viestinvälitystä, on tämä puute huomioitu ja sen korjaamiseksi on esitetty ehdotuksia SOAP-laajennoksiksi ja esim. digitaalisten allekirjoitusten liittämiseksi SOAP viesteihin (SOAP Security Extensions: Digital Signature). Toisaalta turvallisuus alimmalla tasolla voi tarkoittaa vaikkapa SSL:n tai TLS:n käyttöä. Palvelun laadun huomioiminen (Quality of Service, QoS) puolestaan painottaa vastinaikojen, hinnan, transaktioiden ja muita liiketoimintainteraktioissa oleellisia asioita.

23 Usage examples of Web services Software migration and platform integration wrapping legacy systems to act like a Web service agreement on disagreement Agile business processes flexible integration business collaborations and agreements e.g., streamlining business operations, invoicing, shipping operations etc. Service registries and searching searching goods or services according to given requirements (e.g., best price) coordinating travel tickets or hotel reservations for a given date RPCs location transparency! And many, many more 60 Web-palvelut voivat käytännössä olla mitä tahansa. Paketoimalla vanha legacy-systeemi Webpalveluksi sovitaan käytännössä erimielisyydestä: legacy-systeemien logiikka tai toteutusta ei tarvitse muuttaa ja ne voivat olla hyvinkin eri tavoin toteutettuja. Erilaiset ketterät liiketomintaprosessit ovat myös potentiaalisia Web-palvelukonseptin käyttökohteita. Esimerkiksi liiketoimintaoperaatiot (laskutus, tilaukset jne.) voidaan tarjota Web-palveluina. Liiketoimintasopimuksien ja liiketoimintaprosessien määritykset ovat erityisesti painotettuja RosettaNet ja ebxml kosepteissa, jotka ovat tietyssä mielessä vaihtoehtoisia näkökulmia Webpalveluihin. Näihin palataan myöhemmin. Yksi palvelun muoto voi olla vaikkapa muiden palveluiden etsintään tarkoitettu rekisteri. Rekisteristä voidaan etsiä palveluita annetuin kriteerein (esim. halvin matka). Palvelu voi myös hyödyntää muita palveluita. Esimerkiksi matkanjärjestämispalvelu voi käyttää hyväkseen sekä palvelua, jonka avulla voidaan etsiä halvimmat lennot kohteeseen annetulla aikavälillä, että palvelua, joka etsii sopivimman hotellin (annettujen kriteerien mukaisesti) matkakohteessa. Web-palveluja käytetään tietyssä mielessä vastoin sen alkuperäistä käyttötarkoitusta ja visiota etäkutsujen toteuttamiseen. Se onkin tällä hetkellä yleisin käyttömuoto. Tämä voidaan tehdä siten, että kutsun muoto on kutsuttavan ohjelman sijainnista riippumaton eli se ei siis näy kutsun muodosta (location transparency). Etäkutsujen toteuttamiseen on kuitenkin jo olemassa useita eri menetelmiä.

24 Web services - a silver bullet or reinventing the wheel? A silver bullet? No Web services provides rather a new layer, not a replacement for existing computing infrastructure Web services play an important role as a tool for bridging technology domains bridging is based on standard formats Reinventing the wheel? No Web services are not language nor platform dependent like DCOM, RMI etc. Web services are dynamic and disconnected; connections are transient and temporary Web service infrastructure assumes that parties can be connected without prior knowledge of each other, i.e., any client can bind to any published service (as long as the service description and security requirements are followed) From distributed applications to de-centralized applications 61 Web-palvelu ei tarjoa mitään mullistavan uutta. Web-palvelua voidaan ajatella ylimääräisenä kerroksena, joka mahdollistaa sovellusten välisen interaktion. Se ei korvaa eikä sen ole tarkoitus korvata olemassa olevia tekniikoita (esim. hajautustekniikat) eikä olemassa olevia ohjelmistoja. Koska kyseessä on kevyt XML-pohjainen integrointi käyttäen yleisesti hyväksyttyjä standardeja, antaa Webpalvelukonsepti mahdollisuuden silloittaa eri teknologioita. Esimerkiksi palvelu voi olla toteutettu.net ympäristössä kun taas sen asiakas voi J2EE-toteutus. Web-palvelu ei kuitenkaan ole myöskään pyörän uudelleen keksimistä. Web-palveluissa ei ole kyse niinkään hajautusteknologiasta (kuten CORBA, DCOM, RMI) vaan siinä pyritään ei-keskitettyyn järjestelmään (ainakin periaatteessa). Lisäksi Web-palvelut eivät ole ohjelmointikieli- tai alustariippuvaisia kuten esimerkiksi RMI ja DCOM. Edelleen voidaan sanoa, että yhteydet on tarkoitettu transienteiksi: palveluihin kytkeydytään dynaamisesti aina tarpeen mukaan. Palvelun käyttäjän ei tarvitse tietää palvelun toteutuksen yksityiskohtia vaan sille riittää ainoastaan palvelun kuvaus. Web-palveluissa on myös oleellista se, että palvelun käyttäjän ja palvelun välillä ei tarvitse olla ennalta määriteltyä sopimusta (tämä on kuitenkin mahdollista ebxml-konseptissa) vaan periaatteessa mikä sovellus tahansa voi käyttää julkaistua palvelua, edellyttäen että palvelun kuvausta ja mahdollisia turvallisuusvaatimuksia noudatetaan. Tämä luonnollisesti pätee annetussa ympäristössä: mikäli kyseessä on esimerkiksi yrityksen sisäisessä verkossa tarjottu palvelu, voi palvelua käyttää vain sovellukset, joiden on mahdollista ottaa palveluun yhteys.

25 Formats and APIs Web Service Description Language (WSDL) a format for describing a Web service interface, data, message types, interactions patterns, and protocol mappings Simple Object Access Protocol (SOAP) a message format for invoking a Web service binds the WSDL description 62 Edellä esitetty Provider-Requestor-Broker -roolijako kuvaa erilaiset Web-palvelujen käsitteet ja konseptit. Se ei vielä ota kantaa siihen, mitkä ovat käytetyt formaatit ja APIt. Tosin myös siitä on päästy yleisesti yhteisymmärrykseen. Palvelujen kuvaukset ja viestinvälitys suoritetaan käyttäen WSDL ja SOAP -formaatteja (alunperin IBM:n ja Microsoftin ym. yhteisenä ehdotuksena). SOAP ja WSDL ovatkin jo vakiinnuttaneet asemansa. Palvelurekisteri voidaan toteuttaa esimerkiksi UDDIrekisterinä, mutta sen rinnalle on tullut muitakin kandidaattiteknologioita pääosin UDDI:n tietynlaisen rajoittuneisuuden vuoksi. WSDL ja SOAP -spesifikaatioit kehittyvät edelleen: uuden versiot seuraavat toisiaan ja niihin liittyviä muita suosituksia ja ehdotuksia (W3C) tehdään jatkuvasti. Eri versioiden käyttö luonnollisestikin johtaa yhteentoimivuusongelmiin. Lisäksi nämä spesifikaatiot sisältävät optionaalisia sääntöjä ja kaikki toteutukset eivät välttämättä toteuta samoja optionaalisia piirteitä. Tämä saattaa myös aiheuttaa yhteentoimivuusongelmia, vaikka eri osapuolet käyttäisivätkin samoja versioita. Web Service Interoperability (WS-I) yhteisö pyrkiikin pureutumaan näihin ongelmiin antamalla suosituksia näiden spesifikaatioiden käyttötavoista ja niiden eri versioiden yhteiskäytöstä. Vaikka tavoite onkin varsin hyvä, on tehtävä silti varsin haasteellinen. WS-I yhteisön roolia käsitellään tällä kurssilla myöhemmin.

26 Simple Object Access Protocol (SOAP) 63

27 SOAP As XML-RPC, used for representing cross-platform method invocations in XML Supports multiple transport protocols: HTTP (most commonly used), SMTP etc. The object in the acronym is a bit misleading object references are missing from SOAP Looses clearly to binary RPC in performance generating and parsing XML-based data takes time Current W3C recommendation is SOAP 1.2 (1st edition published 2003, 2nd edition published 2007), although version 1.1. is also still used Extensibility features can be added as layered extensions e.g., proposals for extending SOAP to carry digital signature information have been made 64 SOAPin uusin versio 1.2 on vuodelta Sitä voidaan käyttää esim. tyypilliseen (yksisuuntaiseen) pyyntö-vaste kommunikointiin, jolloin pyyntöä varten otetun HTTP-yhteyden aikana palautetaan myös vaste. Sitä voidaan käyttää myös kaksisuuntaiseen pyyntö-vaste kommunikointiin (esim. HTTPpalvelin molemmissa päissä). SOAPia voidaan käyttää etäkutsujen merkkaamiseen (vrt. XML-RPC), mutta sen käyttö ei suinkaan rajoitu siihen. Verrattuna binäärisiin formaatteihin SOAP on melko tehoton. Tämä johtuu suurelta osin SOAPin XML-pohjaisuudesta: XML:n käsittely (jäsentäminen, generointi) on melko hidasta. SOAP on riippumaton kuljetusprotokollasta. Yleisimmin käytössä on HTTP, mutta erimerkiksi SMTP tai FTP käyvät myös. Esimerkiksi asynkroninen viestinvälitys (esim. käyttämällä sopivia viestinvälitysprotokollia kuten SMTP) on toteutettavissa SOAPin avulla. SOAPin käyttömahdollisuudet eivät rajoitu pyyntö-vaste kommunikointiin. Se voi toimia yhteisenä kutsuformaattina, jonka avulla voidaan esim. integroida heterogeenisia komponenttiteknologioita (CORBA, DCOM etc.) käyttäviä järjestelmiä. Se soveltuu myös hyvin Internetiä hyödyntäviin (löyhästi kytkettyihin) B2B- ja B2C-sovelluksiin. Lisäksi SOAPin arvo kevyenä protokollana on erityisen tärkeä pienille laitteille, joissa saattaa olla vain yksinkertainen HTTP-ympäristö ja XML-jäsennin, sillä niihin ei voi sisällyttää laajoja runtime-osia. SOAPin yksi tärkeistä eduista on sen laajennettavuus. SOAPin ns. header-osa mahdollistaa sen. Sen avulla voidaan esimerkiksi viestiin liittää sovellusriippumatonta informaatiota. SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin.

28 SOAP concepts An envelope defines a framework for a SOAP message both application-specific and application-independent information can be included in the envelope contains a required Body and an optional Header Header (optional) includes application-independent information extension mechanism used e.g. for passing directives or contextual information related to the processing of the message Body (mandatory) includes application-specific information it contains the main end-to-end information e.g., request/invocation and the parameters needed 65 SOAPin pääosat ovat kirjekuori (envelope), otsikko (header) ja runko (body). Kirjekuori määrittelee kehyksen SOAP-viestille. Se sisältää otsikko- ja runko-osat. Otsikko ei SOAP-viesteissä ole pakollinen, mutta mikäli sitä käytetään, on sen oltava alussa ennen runko-osaa. SOAPin otsikko-osa (header) mahdollistaa laajennettavuuden. Sen avulla voidaan esimerkiksi viestiin liittää sovellusriippumatonta informaatiota. Tällaista informaatiota on esimerkiksi turvalliseen viestinvälitykseen liittyvät asiat ja erilainen ohjausinformaatio viestin käsittelemiseksi. SOAP kirjekuoren pakollisessa runko-osassa välitetään varsinainen sovellusspesifi tieto. Esimerkiksi pyyntö-vastaus kommunikoinnin tapauksessa siinä välitetään varsinainen pyyntö (esim. operaatiokutsu) ja vastaus. Myös virheilmoitukset merkataan runko-osaan.

29 SOAP message structure: <env:envelope xmlns:env= 2003/05/soap-envelope > <env:header> <!-- optional header blocks go here --> </env:header> <env:body> <!-- requests/responses --> <!-- or Fault elements go here --> <env:body> <env:envelope> SOAP envelope (mandatory) Header (optional) Header Entry Header Entry... Body (mandatory) Body Entry Body Entry SOAP-viestin juurielementti on Envelope. Sen alielementteinä ovat mahdollinen Header ja pakollinen Body. SOAP-viestin rakenne on varsin yksinkertainen. Viestin monimutkaisuus muodostuu Header ja Body osien sisäisestä rakenteesta. SOAP spesifikaatio sisältää paljon optionaalisia sääntöjä. Tämä voi aiheuttaa ongelmia käytännössä: kaksi SOAP toteutusta eivät välttämättä toteuta kaikkia (tai samoja) optionaalisia piirteitä, mikä puolestaan voi aiheuttaa kommunikointiongelmia.

30 SOAP envelope A namespace identifying the SOAP version used is given in Envelope element SOAP 1.2: SOAP 1.1: e.g. <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 67 Envelope-elementillä on nimiavuuruusmääre, joka spesifioi käytettävän SOAP version. Esimerkiksi <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> kertoo, että kyseessä on SOAP 1.2 versio. Lisäksi siinä voidaan antaa muita nimiavaruusmäärityksiä. Käytettävä prefiksi (tässä env) voidaan luonnollisesti valita vapaasti. SOAPin eri versioiden käyttö saattaa aiheuttaa ongelmia. Esimerkiksi SOAP 1.2:a tukeva prosessori generoi virheen (VersionMismatch) kun sille annetaan SOAP 1.1 kirjekuori sille ominaisine nimiavaruusmäärityksineen.

31 encodingstyle attribute encodingstyle attribute is used to define encoding rules used to serialize parts of a SOAP message, i.e., to prescribe how to encode application-specific data (esp. concerning RPCs) in XML SOAP 1.2 Part 2 section 3 defines example SOAP encoding rules. Usage of this encoding scheme can be marked as env:encodingstyle= using this encoding scheme is optional, also other encoding schemes can be used may appear in specific parts of the header or the body in SOAP 1.2 or anywhere (also in envelope element) in SOAP RPC:n toteuttamiseksi palvelun käyttäjän (Requestor) ja palvelun tarjoajan (Provider) tulee sopia mekanismista, jolla metodikutsu (erit. ohjelmien määrittelemät ja käyttämät tietotyypit) koodataan XML:ksi ja toisaalta miten se dekoodataan. Attribuuttia encodingstyle voidaan käyttää tämän sopimuksen määrittelemiseen. Toisin sanoen attribuuttia encodingstyle käytetään määrittelemään sarjallistamissääntöjen koodaus. Esimerkki (SOAP 1.2 Part 0: Primer): <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:header>.</env:header> <env:body> <m:chargereservation env:encodingstyle="http://www.w3.org/2003/05/soap-encoding xmlns:m="http://travelcompany.example.org/"> <m:reservation xmlns:m="http://travelcompany.example.org/reservation">... </env:body> </env:envelope> Tässä esimerkissä encodingstyle attribuutin arvo kertoo, että changereservation rakenteen sarjallistamisessa on käytetty SOAPin määrittelemiä (SOAP Part 2 section 3) koodaussääntöjä. Vaikka SOAP spesifioikin nämä säännöt, niiden käyttö on optionaalista ja sovellukset voivat käyttää muitakin koodaussääntöjä sovellusspesifin datan koodaamiseksi SOAPviestiin. encodingstyle-attribuuttia voidaan käyttää SOAP 1.2 versiossa sekä otsikko- että runko-osissa, mutta SOAP 1.1 sallii sen käytön kaikkialla myös Envelope-elementissä.

32 SOAP intermediaries A SOAP message can travel through multiple intermediaries before arriving to the final destination (message path) Useful for placing additional processing components on intermediaries without modifying the applications on the sender and ultimate destination ends A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary Initial Sender SOAP message path Final Destination Intermediary 1: Intermediary 2: 69 SOAP-viesti voi kulkea viestin lähettäjältä vastaanottajalle useamman välittäjän kautta. Välittäjien käyttö onkin kätevä tapa välittää sama viesti useammalle taholle. Se myös antaa välittäjille mahdollisuuden käsitellä viestiä annettujen sääntöjen mukaisesti. Välittäjien käyttö Webpalvelukonseptissa on hyödyllistä: välittäjät voivat tarjota lisätoiminnallisuutta ja lisäarvopalveluita. Välittäjät yleisemminkin mahdollistavat lisäprosessoinnin SOAP-pohjaisessa viestivälityksessä edellyttämättä viestin lähettäjän ja vastaanottajan modifiointeja. SOAP-viestin käsittelijöitä, joita siis voivat olla viestin lähettäjä, välittäjät ja vastaanottaja, kutsutaan SOAP-solmuksi (SOAP node).

33 Intermediary types Message path SOAP does not specify how a message path is determined and followed message senders may or may not be aware of intermediaries in the message path Forwarding intermediaries process the message according to the SOAP processing model SOAP header blocks targeted at the SOAP intermediary MUST be removed from the SOAP message prior to forwarding Active intermediaries process the message according to the SOAP processing model may undertake processing not described by header blocks in the incoming message the potential set of services provided by an active intermediary includes, but is not limited to: logging, security, content modification and tracing 70 Viestipolku kulkee viestin lähettäjältä välittäjien kautta viestin vastaanottajille. SOAP spesifikaatio ei ota kantaa siihen miten viestipolku määritellään ja miten viestit välitetään eteenpäin. Spesifikaatio kuitenkin määrittelee miten välittäjänä toimivan SOAP-solmun tulee käyttäytyä (käsitellä viesti) vastaanottaessaan SOAP-viestin. Viestin lähettäjä voi olla tietoinen viestipolun välittäjistä, mutta näin välttämättä aina ole. Välittäjiä on kahdenlaisia: passiivisia (forwarding intermediaries) ja aktiivisia (active intermediaries). Passiiviset välittäjät prosessoivat viestin SOAPin sääntöjen mukaisesti (tärkeimmät asiat esitellään seuraavaksi) ja poistaa viestistä tai tarkemmin sanottuna otsikosta - jo käsittelemänsä osat ennen viestin välittämistä eteenpäin. Aktiivinen välittäjä puolestaan sääntöjen mukaisen prosessoinnin lisäksi saattaa tarjota lisäpalveluita, joita ei ole määritelty viestissä. Tällaisia lisäarvopalveluita voivat olla esimerkiksi turvallisuuspalvelut, sisällön muuttaminen ja jäljitys.

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja 1 Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin

Lisätiedot

SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin.

SOAPin nimen Object on harhaanjohtava, koska SOAPissa ei ole objektiviittauksia. Tähän ja muihin SOAPin puutteisiin palataan niin ikään myöhemmin. 1 SOAPin uusin versio 1.2 on vuodelta 2003. Vaikka tämä versio onkin jo yleisesti käytössä ja myös W3C:n suositus, käytetään versiota 1.1 myös jonkin verran edelleen. SOAPia voidaan käyttää esim. tyypilliseen

Lisätiedot

Ohjelmistojen integroinnille on tunnetusti tarvetta ja tämä tarve on yhä kasvamassa. Asiaa voidaan tarkastella sekä ohjelmistoteknisestä näkökulmasta

Ohjelmistojen integroinnille on tunnetusti tarvetta ja tämä tarve on yhä kasvamassa. Asiaa voidaan tarkastella sekä ohjelmistoteknisestä näkökulmasta 1 Internetiä on käytetty paljon B2C-tyyppiseen kommunikointiin, jolloin sovelluksen asiakas/käyttäjä on ihminen. Käyttö voi tapahtua esimerkiksi selaimen avustuksella. Vaikkapa on-line kauppapaikat ovat

Lisätiedot

7. Product-line architectures

7. Product-line architectures 7. Product-line architectures 7.1 Introduction 7.2 Product-line basics 7.3 Layered style for product-lines 7.4 Variability management 7.5 Benefits and problems with product-lines 1 Short history of software

Lisätiedot

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo TIEKE Verkottaja Service Tools for electronic data interchange utilizers Heikki Laaksamo TIEKE Finnish Information Society Development Centre (TIEKE Tietoyhteiskunnan kehittämiskeskus ry) TIEKE is a neutral,

Lisätiedot

HOJ J2EE & EJB & SOAP &...

HOJ J2EE & EJB & SOAP &... HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

HSMT J2EE & EJB & SOAP &...

HSMT J2EE & EJB & SOAP &... HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä

OHJ-5201 Web-palveluiden toteutustekniikat. Kurssisisällöstä. Tarja Systä OHJ-5201 Web-palveluiden toteutustekniikat Kurssisisällöstä Tarja Systä 1 Yleistä Esitietovaatimukset OHJ-1400 Olio-ohjelmoinnin peruskurssi (pakollinen) OHJ-5010 Hajautettujen järjestelmien perusteet

Lisätiedot

BDD (behavior-driven development) suunnittelumenetelmän käyttö open source projektissa, case: SpecFlow/.NET.

BDD (behavior-driven development) suunnittelumenetelmän käyttö open source projektissa, case: SpecFlow/.NET. BDD (behavior-driven development) suunnittelumenetelmän käyttö open source projektissa, case: SpecFlow/.NET. Pekka Ollikainen Open Source Microsoft CodePlex bio Verkkosivustovastaava Suomen Sarjakuvaseura

Lisätiedot

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

Lisätiedot

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi MISTÄ ALUETIETOJÄRJESTELMÄSSÄ ON KYSYMYS? Asiakkaan tietojen tulisi olla saatavissa vain niiden käyttöön,

Lisätiedot

Windows Phone. Module Descriptions. Opiframe Oy puh. +358 44 7220800 eero.huusko@opiframe.com. 02600 Espoo

Windows Phone. Module Descriptions. Opiframe Oy puh. +358 44 7220800 eero.huusko@opiframe.com. 02600 Espoo Windows Phone Module Descriptions Mikä on RekryKoulutus? Harvassa ovat ne työnantajat, jotka löytävät juuri heidän alansa hallitsevat ammatti-ihmiset valmiina. Fiksuinta on tunnustaa tosiasiat ja hankkia

Lisätiedot

Luento 8: XML-tuki ohjelmointikielissä & Web-palvelut

Luento 8: XML-tuki ohjelmointikielissä & Web-palvelut Luento 8: XML-tuki ohjelmointikielissä & Web-palvelut AS-0.110 XML-kuvauskielten perusteet Janne Kalliola 1 XML-tuki ohjelmointikielissä ja Web-palvelut XML-tuki ohjelmointikielissä Java PHP C, C++ Perl.NET,

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

Web Service torilla tavataan!

Web Service torilla tavataan! Web Service torilla tavataan! Jari Putula Avarea Oy COPYRIGHT BY AVAREA 2009 1 Google Trends COPYRIGHT BY AVAREA 2009 2 1 1. Mahdollistajat 2. Web service? 3. KISS 4. Miksi? 5. Analogia 6. Ajax 7. Esimerkki

Lisätiedot

Tässä kertauksena SOA ja palvelu.

Tässä kertauksena SOA ja palvelu. 1 Tässä kertauksena SOA ja palvelu. Eri lähteet esittävät erilaisia vaatimuksia SOA-järjestelmän osasille eli palveluille. Yleisimpiä ja tärkeimpiä ovat autonomisuus, löyhä sidonta, toteutusriippumaton

Lisätiedot

Choose Finland-Helsinki Valitse Finland-Helsinki

Choose Finland-Helsinki Valitse Finland-Helsinki Write down the Temporary Application ID. If you do not manage to complete the form you can continue where you stopped with this ID no. Muista Temporary Application ID. Jos et onnistu täyttää lomake loppuun

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Network to Get Work. Tehtäviä opiskelijoille Assignments for students. www.laurea.fi

Network to Get Work. Tehtäviä opiskelijoille Assignments for students. www.laurea.fi Network to Get Work Tehtäviä opiskelijoille Assignments for students www.laurea.fi Ohje henkilöstölle Instructions for Staff Seuraavassa on esitetty joukko tehtäviä, joista voit valita opiskelijaryhmällesi

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

.NET 2006 ja sen jälkeen

.NET 2006 ja sen jälkeen .NET 2006 ja sen jälkeen Ahti Haukilehto FC Sovelto Oyj Microsoft Regional Director, Finland Superior tools, niin mitkä? Visual Studio Team System Team Foundation Server DSL Tools 2 Visual Studio Team

Lisätiedot

Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability.

Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability. Integrointi? Tavoitteena yhdistää eri tavoin toteutetut ja eri tavoin toimivat järjestelmät; integration & interoperability. Joitain motivaattoreita... 1. Enterprise Application Integration: Eri organisaatioissa

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

ATLAS-kartan esittely - Peli palveluiden yhteiskehittämisen menetelmistä Päivi Pöyry-Lassila, Aalto-yliopisto

ATLAS-kartan esittely - Peli palveluiden yhteiskehittämisen menetelmistä Päivi Pöyry-Lassila, Aalto-yliopisto ATLAS-kartan esittely - Peli palveluiden yhteiskehittämisen menetelmistä Päivi Pöyry-Lassila, Aalto-yliopisto Serve Research Brunch 24.10.2013 Esityksen sisältö ATLAS-hanke lyhyesti ATLAS-kartan kehittäminen:

Lisätiedot

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

Lisätiedot

Älykkäämmät integraatiot palveluväylän avulla

Älykkäämmät integraatiot palveluväylän avulla Älykkäämmät integraatiot palveluväylän avulla John Joro 2013 IBM Corporation Arek Oy Työeläkevakuutuksen järjestelmäkehittäjä Arek on asiakkaidensa omistama yksityinen osakeyhtiö Selkeä hallintomalli Rakennettavien

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

Lisätiedot

Use of spatial data in the new production environment and in a data warehouse

Use of spatial data in the new production environment and in a data warehouse Use of spatial data in the new production environment and in a data warehouse Nordic Forum for Geostatistics 2007 Session 3, GI infrastructure and use of spatial database Statistics Finland, Population

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

ECVETin soveltuvuus suomalaisiin tutkinnon perusteisiin. Case:Yrittäjyyskurssi matkailualan opiskelijoille englantilaisen opettajan toteuttamana

ECVETin soveltuvuus suomalaisiin tutkinnon perusteisiin. Case:Yrittäjyyskurssi matkailualan opiskelijoille englantilaisen opettajan toteuttamana ECVETin soveltuvuus suomalaisiin tutkinnon perusteisiin Case:Yrittäjyyskurssi matkailualan opiskelijoille englantilaisen opettajan toteuttamana Taustaa KAO mukana FINECVET-hankeessa, jossa pilotoimme ECVETiä

Lisätiedot

Constructive Alignment in Specialisation Studies in Industrial Pharmacy in Finland

Constructive Alignment in Specialisation Studies in Industrial Pharmacy in Finland Constructive Alignment in Specialisation Studies in Industrial Pharmacy in Finland Anne Mari Juppo, Nina Katajavuori University of Helsinki Faculty of Pharmacy 23.7.2012 1 Background Pedagogic research

Lisätiedot

Viimeinen rajoite (hypermedia as the engine of application state) tarkoittaa käytännössä sitä, että palvelimelta saadut vastaukset sisältävät URIt

Viimeinen rajoite (hypermedia as the engine of application state) tarkoittaa käytännössä sitä, että palvelimelta saadut vastaukset sisältävät URIt 195 ReST on arkkitehtuurityyli, joka tähtää yhteentoimivuuden säilyttämiseen sellaisissa hajautetuissa (hypermedia)järjestelmissä, joissa eri osapuolet kehittyvät ja muuttuvat itsenäisesti toisistaan riippumatta.

Lisätiedot

812336A C++ -kielen perusteet, 21.8.2010

812336A C++ -kielen perusteet, 21.8.2010 812336A C++ -kielen perusteet, 21.8.2010 1. Vastaa lyhyesti seuraaviin kysymyksiin (1p kaikista): a) Mitä tarkoittaa funktion ylikuormittaminen (overloading)? b) Mitä tarkoittaa jäsenfunktion ylimääritys

Lisätiedot

WAMS 2010,Ylivieska Monitoring service of energy efficiency in housing. 13.10.2010 Jan Nyman, jan.nyman@posintra.fi

WAMS 2010,Ylivieska Monitoring service of energy efficiency in housing. 13.10.2010 Jan Nyman, jan.nyman@posintra.fi WAMS 2010,Ylivieska Monitoring service of energy efficiency in housing 13.10.2010 Jan Nyman, jan.nyman@posintra.fi Background info STOK: development center for technology related to building automation

Lisätiedot

Security server v6 installation requirements

Security server v6 installation requirements CSC Security server v6 installation requirements Security server version 6.4-0-201505291153 Pekka Muhonen 8/12/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes

Lisätiedot

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj SUOMEN KUNTALIITTO Sosiaali- ja terveysyksikkö Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj ~ (operatiiviset-/tiedonjakelu-/si~llönhallinta~velluk~et)

Lisätiedot

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?

Lisätiedot

Guidebook for Multicultural TUT Users

Guidebook for Multicultural TUT Users 1 Guidebook for Multicultural TUT Users WORKPLACE PIRKANMAA-hankkeen KESKUSTELUTILAISUUS 16.12.2010 Hyvää käytäntöä kehittämässä - vuorovaikutusopas kansainvälisille opiskelijoille TTY Teknis-taloudellinen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio

Lisätiedot

Tietojärjestelmäarkkitehtuurit

Tietojärjestelmäarkkitehtuurit Tietojärjestelmäarkkitehtuurit ITK130 Johdatus ohjelmistotekniikkaan Syksy 2003 Sami Kollanus 1 Aluksi Tietojärjestelmäarkkitehtuurit vs. ohjelmistoarkkitehtuurit Pohjana Tietojärjestelmäarkkitehtuurit

Lisätiedot

TIETEEN PÄIVÄT OULUSSA 1.-2.9.2015

TIETEEN PÄIVÄT OULUSSA 1.-2.9.2015 1 TIETEEN PÄIVÄT OULUSSA 1.-2.9.2015 Oulun Yliopisto / Tieteen päivät 2015 2 TIETEEN PÄIVÄT Järjestetään Oulussa osana yliopiston avajaisviikon ohjelmaa Tieteen päivät järjestetään saman konseptin mukaisesti

Lisätiedot

Tässä ohjeessa käydään läpi sosiaalisen median verkkopalveluiden lisätoimintojen lisääminen verkkosivuillesi.

Tässä ohjeessa käydään läpi sosiaalisen median verkkopalveluiden lisätoimintojen lisääminen verkkosivuillesi. SOSIAALINEN MEDIA Tässä ohjeessa käydään läpi sosiaalisen median verkkopalveluiden lisätoimintojen lisääminen verkkosivuillesi. FACEBOOK Facebook mahdollistaa useiden erilaisten Social plugins -toimintojen

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

HITSAUKSEN TUOTTAVUUSRATKAISUT

HITSAUKSEN TUOTTAVUUSRATKAISUT Kemppi ARC YOU GET WHAT YOU MEASURE OR BE CAREFUL WHAT YOU WISH FOR HITSAUKSEN TUOTTAVUUSRATKAISUT Puolitetaan hitsauskustannukset seminaari 9.4.2008 Mikko Veikkolainen, Ratkaisuliiketoimintapäällikkö

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

LUONNOS RT 80260 EN AGREEMENT ON BUILDING WORKS 1 THE PARTIES. May 1998 1 (10)

LUONNOS RT 80260 EN AGREEMENT ON BUILDING WORKS 1 THE PARTIES. May 1998 1 (10) RT 80260 EN May 1998 1 (10) AGREEMENT ON BUILDING WORKS This agreement template is based on the General Terms and Conditions of Building Contracts YSE 1998 RT 16-10660, LVI 03-10277, Ratu 417-7, KH X4-00241.

Lisätiedot

LYTH-CONS CONSISTENCY TRANSMITTER

LYTH-CONS CONSISTENCY TRANSMITTER LYTH-CONS CONSISTENCY TRANSMITTER LYTH-INSTRUMENT OY has generate new consistency transmitter with blade-system to meet high technical requirements in Pulp&Paper industries. Insurmountable advantages are

Lisätiedot

MUSEOT KULTTUURIPALVELUINA

MUSEOT KULTTUURIPALVELUINA Elina Arola MUSEOT KULTTUURIPALVELUINA Tutkimuskohteena Mikkelin museot Opinnäytetyö Kulttuuripalvelujen koulutusohjelma Marraskuu 2005 KUVAILULEHTI Opinnäytetyön päivämäärä 25.11.2005 Tekijä(t) Elina

Lisätiedot

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena Ohjelmointikielet ja -paradigmat 5op Markus Norrena Ko#tehtävä 4 Viimeistele "alkeellinen kuvagalleria". Käytännössä kaksi sivua Yksi jolla voi ladata kuvia palvelimelle (file upload) Toinen jolla ladattuja

Lisätiedot

Data Quality Master Data Management

Data Quality Master Data Management Data Quality Master Data Management TDWI Finland, 28.1.2011 Johdanto: Petri Hakanen Agenda 08.30-09.00 Coffee 09.00-09.30 Welcome by IBM! Introduction by TDWI 09.30-10.30 Dario Bezzina: The Data Quality

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

Hajauta yhdistäen ja yhdistä hajauttaen: Web Services

Hajauta yhdistäen ja yhdistä hajauttaen: Web Services Hajauta yhdistäen ja yhdistä hajauttaen: Web Services Janne Saarela janne.saarela@profium.com 17.12.2002 Tampereen oliopäivät Esityksen sisältö Arvolupaus Johdanto teknologioihin Yhteensopivuuden taso

Lisätiedot

Tietojenkäsittelytieteiden koulutusohjelma. Tietojenkäsittelytieteiden laitos Department of Information Processing Science

Tietojenkäsittelytieteiden koulutusohjelma. Tietojenkäsittelytieteiden laitos Department of Information Processing Science Tietojenkäsittelytieteiden koulutusohjelma Tietojenkäsittelytieteet Laskennallinen data-analyysi Ohjelmistotekniikka, käyttöjärjestelmät, ihminen-kone -vuorovaikutus Teoreettinen tietojenkäsittelytiede

Lisätiedot

Päihittääkö J2EE.NETin SOAn pohjana?

Päihittääkö J2EE.NETin SOAn pohjana? Päihittääkö J2EE.NETin SOAn pohjana? Nääsvillen Oliopäivät 2004 15.12.2004 Pekka Kähkipuro Kehitysjohtaja, FT pekka.kahkipuro@sysopen.fi Sisällys Miksi SOA? Palvelukeskeinen arkkitehtuuri Ratkaiseeko SOA

Lisätiedot

API:Hack Tournee 2014

API:Hack Tournee 2014 apisuomi API:Hack Tournee 2014 #apihackfinland Twitter: @ApiSuomi API:Suomi - Suomen metarajapinta apisuomi Apisuomi kerää vertailutietoa ja arvosteluja rajapinnoista madaltaen avoimen datan uudelleenkäytön

Lisätiedot

Liikennekaari Tieto-alaryhmä. 11.5.2015 Johanna Taskinen ja Paavo Moilanen

Liikennekaari Tieto-alaryhmä. 11.5.2015 Johanna Taskinen ja Paavo Moilanen Liikennekaari Tieto-alaryhmä 11.5.2015 Johanna Taskinen ja Paavo Moilanen 1 Matkustaja joutuu muodostamaan matkaketjut monimutkaisesta kokonaisuudesta ja valitsee helpon täyden palvelun vaihtoehdon: auton

Lisätiedot

Konesali ilman rajoja Kongressi A 5.3.2013

Konesali ilman rajoja Kongressi A 5.3.2013 Konesali ilman rajoja Kongressi A 5.3.2013 t SC Orchestrator 2012 SP1 Harri Puupponen 5.3.2013 t 2012 Microsoft Corporation. All rights reserved. Sisältö Yleistä Arkkitehtuuri Uudet ominaisuudet Demoja

Lisätiedot

Web-palveluiden alusta Axis2

Web-palveluiden alusta Axis2 Web-palveluiden alusta Axis2 Aki Heikkinen Ohjaaja: Raimo Rask Itä-Suomen yliopisto, Tietojenkäsittelytieteen laitos Suullisen esittämisen seminaarin kirjallinen tukimateriaali 15. helmikuuta 2010 Tiivistelmä

Lisätiedot

Viestintään tarvitaan tiedon jakamista tietotyöläisten kesken. 26.10.2006 Ville Hurnonen

Viestintään tarvitaan tiedon jakamista tietotyöläisten kesken. 26.10.2006 Ville Hurnonen Viestintään tarvitaan tiedon jakamista tietotyöläisten kesken 26.10.2006 Ville Hurnonen Enfo Enfo on sopivan kokoinen kumppani Enfo on uusi, riittävän kokoinen palvelutalo Enfo on suomalainen toimija Enfo

Lisätiedot

Katsaus museoiden kokoelmahallintajärjestelmiin

Katsaus museoiden kokoelmahallintajärjestelmiin Katsaus museoiden kokoelmahallintajärjestelmiin Tiedonhallintakeskus Vesa Hongisto 11.2.2009 In his book Smart Selection and Management of Association Computer Systems, Thomas J. Orlowski states: Think

Lisätiedot

Hankkeen toiminnot työsuunnitelman laatiminen

Hankkeen toiminnot työsuunnitelman laatiminen Hankkeen toiminnot työsuunnitelman laatiminen Hanketyöpaja LLP-ohjelman keskitettyjä hankkeita (Leonardo & Poikittaisohjelma) valmisteleville11.11.2011 Työsuunnitelma Vastaa kysymykseen mitä projektissa

Lisätiedot

Rekisteröiminen - FAQ

Rekisteröiminen - FAQ Rekisteröiminen - FAQ Miten Akun/laturin rekisteröiminen tehdään Akun/laturin rekisteröiminen tapahtuu samalla tavalla kuin nykyinen takuurekisteröityminen koneille. Nykyistä tietokantaa on muokattu niin,

Lisätiedot

TIE-20200 Ohjelmistojen suunnittelu

TIE-20200 Ohjelmistojen suunnittelu TIE-20200 Ohjelmistojen suunnittelu Luento 1: Virtuaalifunktiot, Template method 1 Yleistä asiaa Muistakaa harkkatyöilmoittautuminen 23 ryhmää (mm. lihansyöjäkirahvi), vajaita ryhmiäkin on 44 henkeä vielä

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

The role of 3dr sector in rural -community based- tourism - potentials, challenges

The role of 3dr sector in rural -community based- tourism - potentials, challenges The role of 3dr sector in rural -community based- tourism - potentials, challenges Lappeenranta, 5th September 2014 Contents of the presentation 1. SEPRA what is it and why does it exist? 2. Experiences

Lisätiedot

More than logistics software

More than logistics software More than logistics software MITÄ TEEMME What we do Logistiikka järjestelmä tullivarastoille ja huolinta yrityksille Logistics system for customs warehouses and expediting companies All inclusive ohjelmisto

Lisätiedot

* lotta.laine@cancer.fi for more information. Sakari Nurmela

* lotta.laine@cancer.fi for more information. Sakari Nurmela Finnish families and holidays in the Sun Views among parents of underaged children about sunprotection on holiday trips Lotta Laine*, Liisa Pylkkänen, and Tapani Koskela Cancer Society of Finland Finnish

Lisätiedot

Lakimies PDF. ==>Download: Lakimies PDF ebook

Lakimies PDF. ==>Download: Lakimies PDF ebook Lakimies PDF ==>Download: Lakimies PDF ebook Lakimies PDF - Are you searching for Lakimies Books? Now, you will be happy that at this time Lakimies PDF is available at our online library. With our complete

Lisätiedot

Paikkatiedon semanttinen mallinnus, integrointi ja julkaiseminen Case Suomalainen ajallinen paikkaontologia SAPO

Paikkatiedon semanttinen mallinnus, integrointi ja julkaiseminen Case Suomalainen ajallinen paikkaontologia SAPO Paikkatiedon semanttinen mallinnus, integrointi ja julkaiseminen Case Suomalainen ajallinen paikkaontologia SAPO Tomi Kauppinen, Eero Hyvönen, Jari Väätäinen Semantic Computing Research Group (SeCo) http://www.seco.tkk.fi/

Lisätiedot

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn

Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Kaikki analogiset järjestelmät digitaalisiksi ja verkkokäyttöisiksi - jo tänään Kustannustekkuutta ja joustavuutta työskentelyyn Terveydenhuollon 29. ATK-päivät Jyväskylä 25-27.5.2003 Verkostoitumisen

Lisätiedot

Ajankohtaisia SOA tutkimusteemoja

Ajankohtaisia SOA tutkimusteemoja Ajankohtaisia SOA tutkimusteemoja Paavo Kotinurmi Ohjelmistoliiketoiminnan ja -tuotannon laboratorio Sisältö Miten integraatiostandardit pohjana SOA-palveluille? Mitä on semanttinen SOA ja mitä SOAn haasteita

Lisätiedot

Rakentamisen 3D-mallit hyötykäyttöön

Rakentamisen 3D-mallit hyötykäyttöön Rakentamisen 3D-mallit hyötykäyttöön 1 BIM mallien tutkimuksen suunnat JAO, Jyväskylä, 22.05.2013 Prof. Jarmo Laitinen, TTY rakentamisen tietotekniikka Jarmo Laitinen 23.5.2013 Jarmo Laitinen 23.5.2013

Lisätiedot

KODAK EIM & RIM VIParchive Ratkaisut

KODAK EIM & RIM VIParchive Ratkaisut ATK Päivät 2006 Mikkeli KODAK EIM & RIM VIParchive Ratkaisut 29.-30.5. 2006 Stefan Lindqvist HCIS Sales Specialist Health Care Information Systems Kodak Health Group 3/24/2013 1 Arkistoinnin haasteita

Lisätiedot

A new model of regional development work in habilitation of children - Good habilitation in functional networks

A new model of regional development work in habilitation of children - Good habilitation in functional networks A new model of regional development work in habilitation of children - Good habilitation in functional networks Salla Sipari, PhD, Principal Lecturer Helena Launiainen, M.Ed, Manager Helsinki Metropolia

Lisätiedot

Strategiset kyvykkyydet kilpailukyvyn mahdollistajana Autokaupassa Paula Kilpinen, KTT, Tutkija, Aalto Biz Head of Solutions and Impact, Aalto EE

Strategiset kyvykkyydet kilpailukyvyn mahdollistajana Autokaupassa Paula Kilpinen, KTT, Tutkija, Aalto Biz Head of Solutions and Impact, Aalto EE Strategiset kyvykkyydet kilpailukyvyn mahdollistajana Autokaupassa Paula Kilpinen, KTT, Tutkija, Aalto Biz Head of Solutions and Impact, Aalto EE November 7, 2014 Paula Kilpinen 1 7.11.2014 Aalto University

Lisätiedot

Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat

Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat Tarua vai totta: sähkön vähittäismarkkina ei toimi? 11.2.2015 Satu Viljainen Professori, sähkömarkkinat Esityksen sisältö: 1. EU:n energiapolitiikka on se, joka ei toimi 2. Mihin perustuu väite, etteivät

Lisätiedot

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit 7 Viestipohjaisten yritysjärjestelmien suunnittelumallit Hohpe G., Woolf B.: Enterprise Integration Patterns. Addison-Wesley 2004. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Viestinvälitykseen

Lisätiedot

papinet -sanomastandardit

papinet -sanomastandardit papinet -sanomastandardit Tapio Räsänen Puutavaralogistiikan kehittämishaasteita 14.6.2007 1 papinet on An international paper and forest products industry e-business initiative. A set of standard electronic

Lisätiedot

Software Signing System System overview and key domain concepts

Software Signing System System overview and key domain concepts Software Signing System System overview and key domain concepts Copyright 2004 F-Secure Corporation. All rights reserved. Contents 1 System overview...1 2 Main domain concepts...2 3 Roles and user groups...3

Lisätiedot

Tork Paperipyyhe. etu. tuotteen ominaisuudet. kuvaus. Väri: Valkoinen Malli: Vetopyyhe

Tork Paperipyyhe. etu. tuotteen ominaisuudet. kuvaus. Väri: Valkoinen Malli: Vetopyyhe etu Monikäyttöpaperi hoitaa useimmat pyyhintätehtävät Sopiva lasipintojen pyyhintään Sopii käsien kuivaamiseen Elintarvikekäyttöön hyväksytty Tork Easy Handling, pakkaus, jota on helppo kantaa mukana,

Lisätiedot

Lab SBS3.FARM_Hyper-V - Navigating a SharePoint site

Lab SBS3.FARM_Hyper-V - Navigating a SharePoint site Lab SBS3.FARM_Hyper-V - Navigating a SharePoint site Note! Before starting download and install a fresh version of OfficeProfessionalPlus_x64_en-us. The instructions are in the beginning of the exercise.

Lisätiedot

Integration of Finnish web services in WebLicht Presentation in Freudenstadt 2010-10-16 by Jussi Piitulainen

Integration of Finnish web services in WebLicht Presentation in Freudenstadt 2010-10-16 by Jussi Piitulainen Integration of Finnish web services in WebLicht Presentation in Freudenstadt 2010-10-16 by Jussi Piitulainen Who we are FIN-CLARIN University of Helsinki The Language Bank of Finland CSC - The Center for

Lisätiedot

Hand-out kooste26.3.2009

Hand-out kooste26.3.2009 Hand-out kooste26.3.2009 Human Capital Management IT Viikko-seminaari 26.3.2009 Sanomatalo Arc Technology Oracle - Xenetic Aamupäivän agenda 09.10-10.10 Arc Technology 10.10-10.25 Kahvitauko ja verkottuminen

Lisätiedot

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen TURVAVÄYLÄSEMINAARI Erilaiset kenttäväylät ja niiden kehitys 13.11.2002 Jukka Hiltunen Miksi väylätekniikkaa? 1. luonnolliset perusteet: : kehittyneiden kenttälaitteiden ja ylemmän tason laitteiden välille

Lisätiedot

Kestävä kehitys, vastuullisuus. Työryhmän kokous 26.10

Kestävä kehitys, vastuullisuus. Työryhmän kokous 26.10 Kestävä kehitys, vastuullisuus Työryhmän kokous 26.10 Agenda Kooste haastattelukierrokselta (toimitetaan myöhemmin) Toimintasuunnitelma 2016, alustava ehdotus Raportti 2016 muoto ja sisältö, alustava ehdotus

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

Lyhyt johdatus ketterään testaukseen

Lyhyt johdatus ketterään testaukseen TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys

Lisätiedot

Avoimen datan liiketoimintamallit. Matti Rossi, Aalto University School of Business

Avoimen datan liiketoimintamallit. Matti Rossi, Aalto University School of Business Avoimen datan liiketoimintamallit Matti Rossi, Aalto University School of Business Bio Tietojärjestelmätieteen professori Aalto-Yliopiston kauppakorkeakoulussa Vähemmistöomistaja MetaCase Consulting oy:ssä

Lisätiedot

CIO muutosjohtajana yli organisaatiorajojen

CIO muutosjohtajana yli organisaatiorajojen CIO muutosjohtajana yli organisaatiorajojen 03.06.2009 Antti Koskelin CIO Konecranes Group 2009 Konecranes Plc. All rights Konecranes overview Business Agenda CIO Agenda Mindset for modern CIO Konecranes

Lisätiedot

Sähkönjakeluverkon hallinnan arkkitehtuuri. Sami Repo

Sähkönjakeluverkon hallinnan arkkitehtuuri. Sami Repo Sähkönjakeluverkon hallinnan arkkitehtuuri Sami Repo Miksi? Energiansäästö Muut lämmitysmuodot korvautuvat lämpöpumpuilla Nollaenergiarakentaminen (ZEB) Sähköautot Lämmityskuormien ohjaaminen hinnan perusteella

Lisätiedot

Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa

Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa Osa II OUGF / 12.5.2004 c Sisält ltö Mitä uutta? Yleistä lisensoinnista Lisensointiin liittyviä ongelmia Hankinnassa muistettavia asioita

Lisätiedot

Millainen on onnistunut ICT-projekti?

Millainen on onnistunut ICT-projekti? Millainen on onnistunut ICT-projekti? Ohjelmistotuotannon lehtori Tero Tensu Ahtee Ohjelmistotekniikan laitoksella 1990- Projektityö-kurssilla 1991- pesunkestävä yliopistohampuusi ei päivääkään oikeissa

Lisätiedot

3 9-VUOTIAIDEN LASTEN SUORIUTUMINEN BOSTONIN NIMENTÄTESTISTÄ

3 9-VUOTIAIDEN LASTEN SUORIUTUMINEN BOSTONIN NIMENTÄTESTISTÄ Puhe ja kieli, 27:4, 141 147 (2007) 3 9-VUOTIAIDEN LASTEN SUORIUTUMINEN BOSTONIN NIMENTÄTESTISTÄ Soile Loukusa, Oulun yliopisto, suomen kielen, informaatiotutkimuksen ja logopedian laitos & University

Lisätiedot

FPGA-piirien käyttökohteet nyt ja tulevaisuudessa Tomi Norolampi

FPGA-piirien käyttökohteet nyt ja tulevaisuudessa Tomi Norolampi FPGA-piirien käyttökohteet nyt ja tulevaisuudessa Tomi Norolampi ESITYKSEN SISÄLTÖ Flexibilis Oy lyhyesti FPGA FPGA-teknologian nykytilanne ja tulevaisuus Kaupallinen näkökulma Uudelleenkonfiguroinnin

Lisätiedot

Teknologinen muutos ja yliopistojen tulevaisuus. Tievie-seminaari Helsinki 22.11.2001 Antti Auer

Teknologinen muutos ja yliopistojen tulevaisuus. Tievie-seminaari Helsinki 22.11.2001 Antti Auer Teknologinen muutos ja yliopistojen tulevaisuus Tievie-seminaari Helsinki 22.11.2001 Antti Auer Verkko-opetuksen neljä strategiaa (mukailtu Collis & Gommer, 2001 artikkeleista) Instituutio määrittelee

Lisätiedot

Specifica(on by Example Vaa(mukset ja testaus ke9erissä projekteissa. Marko Taipale

Specifica(on by Example Vaa(mukset ja testaus ke9erissä projekteissa. Marko Taipale Specifica(on by Example Vaa(mukset ja testaus ke9erissä projekteissa Marko Taipale Mitä on ke*erä (testaus) Mitä on Specifica(on by Example Omat kokemukset Agile / Lean Mitä on ke9erä (testaus) Mitä

Lisätiedot

Ostamisen muutos muutti myynnin. Technopolis Business Breakfast 21.8.2014

Ostamisen muutos muutti myynnin. Technopolis Business Breakfast 21.8.2014 Ostamisen muutos muutti myynnin Technopolis Business Breakfast 21.8.2014 Taking Sales to a Higher Level Mercuri International on maailman suurin myynnin konsultointiyritys. Autamme asiakkaitamme parantamaan

Lisätiedot

Sakari Olli Tieturi OY. SOA - ajattelutapa vai teknologia

Sakari Olli Tieturi OY. SOA - ajattelutapa vai teknologia SOA - ajattelutapa vai teknologia Tieturi OY Sakari Olli FM Ohjelmistoarkkitehtuureiden sekä teknologioiden asiantuntija Tieturi OY Suomen johtava koulutusyritys Konsultointipalveluiden tarjoaja aiheina

Lisätiedot

Wopti ja Tuutti - hajautetun sisällönhallinnan kehittäminen

Wopti ja Tuutti - hajautetun sisällönhallinnan kehittäminen Wopti ja Tuutti - hajautetun sisällönhallinnan kehittäminen Valtakunnallinen opetustarjonta halutuilla kriteereillä WSrajapinta Yliopiston X WS-rajapinta Yliopiston Y WS-rajapinta Yliopiston Z Yliopiston

Lisätiedot