Web service interoperability (WS-I)

Koko: px
Aloita esitys sivulta:

Download "Web service interoperability (WS-I)"

Transkriptio

1 Web service interoperability (WS-I) 151

2 Web service interoperability organization (WS-I) Founded See: Assists in creating and deploying interoperable Web services Interoperability problems with Web services multiple resources to support implementations of Web services vendor platforms many specifications and their many versions specifications can and are extended and interpreted for various purposes no single interpretation of the term Web service 152 WS-I organisaatio on lyhyessä ajassa saanut paljon jäseniä ja yhteistyökumppaneita. WS-I perustettiin 2002, mutta suurimmat Web-palvelujen toteuttamista tukevien työkalujen ja standardien tarjoajat ovat jo nyt mukana. Web-palvelujen toteuttamiseen käytettäviä standardeja kehitetään samanaikaisesti eri organisaatioissa, kuten W3C, OASIS, OAG (Open Applications Group) jne. WS-I pyrkii toimimaan näiden standardien integroijana ja antamaan ohjeistusta standardien käytöstä. Web-palveluiden käytössä esiintyy yhteentoimivuuusongelmia monista eri syistä. Yksi perussyy on se, että Web-palvelustandardit sisältävät paljon optionaalisia elementtejä ja ne ovat osin laajennettavia. Tämä mahdollistaa näiden standardien tulkinnan eri tavoin. Näin on tehtykin eri Webpalvelutyökaluissa. Ongelma on hieman vastaavanlainen mutta ei kuitenkaan yhtä huomattava kuin XMI:n kohdalla. Toisaalta myös termin Web-palvelu erilaiset tulkinnat aiheuttavat luonnollisesti ongelmia.

3 WS-I goals Encourage adaption provide a forum for end users to communicate requirements raise awareness of the standards Accelerate deployment and achieve/improve interoperability integrate specifications provide guidelines and recommendations for using the standards e.g., Basic Profile 1.0 (August 2003), Basic Profile 1.1 (August 2004) and Basic Profile 1.2 draft (March 2007) deliver testing tools and sample applications provide a collaboration forum for developers 153 WS-I:n tavoite on tarjota tukea sekä työkalujen että Web-palvelujen tuottajille: työkalujen tuottajat saavat tietoa asiakkaiden (Web-palvelujen tuottajat) yhteentoimivuusvaatimuksista ja ongelmista, ja palvelujen tuottajille taas tarjotaan työkaluja ja ohjeistusta (esim. best practices ) palvelujen toteuttamiseksi. Lisäksi WS-I pyrkii kannustamaan ja rohkaisemaan Web-palvelukonseptin ja standardien käyttöönottoa. Ohjeistuksen lisäksi WS-I tarjoaa työkaluja ja esimerkkisovelluksia.

4 Profiles A profile for Web services is a set of (certain versions of) specifications with guidelines and conventions for using them together Basic Profile 1.0 is for SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and XML Schema Basic Profile 1.1 is derived from Basic Profile 1.0 by incorporating to-date errata and moving those requirements related to message serializations to the Simple SOAP Binding Profile A testing tool to check profile conformance The specifications will evolve, which challenges the work and means that the profiles need to evolve as well 154 WS-I:n ehkä tunnetuin kontribuutio on Basic Profile, joka määrittelee miten Web-palvelustandareja (WSDL, UDDI, SOAP) ja erityisesti niiden tiettyjä versioita - tulisi käyttää, jotta yhteentoimivuusongelmat tulisi minimoitua. Basic Profile pyrkii siis tavallaan tilkkimään niitä aukkoja, jotka spesifikaatiot jättävät avoimiksi. Basic Profile suosituksesta on julkaistu versiot 1.0 ja 1.1. Versio 1.0 määrittelee sääntöjä SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 ja XML Schema standardien käyttämiseksi ja yhteensovittamiseksi. Versio 1.1 on version 1.0 laajennos siten, että tunnetut version 1.0 virheet on korjattu ja joitain SOAP-viestejä koskevia sarjallistamisvaatimuksia on siirretty erilliseen Simple SOAP Binding Profile suositukseen. Maaliskuussa on julkaistu myös Basic Profile 1.2 draft, mutta sitä ei ole vielä hyväksytty viralliseksi profiiliksi. Sen vuoksi versiota 1.2. ei käsitellä tarkemmin. WS-I tarjoaa myös työkalusetin WS-I Testing Tools, jonka avulla voidaan tarkastaa ovatko esimerkiksi käytetyt SOAP-viestit tai WSDL-kuvaukset Basic Profile suosituksen mukaisia. Useimmat suurimmista Web-palvelutyökalujen tuottajista tarjoavat jo uusimmissa työkaluversioissaan tukea WS-I profiilille. Tämä tuki saattaa olla esimerkiksi erillinen optio, joka tarvittaessa ottaa huomioon Basic Profile suosituksen (esimerkiksi työkalu generoi Basic Profile suosituksen mukaisen WSDL-dokumentin toteutetun palvelun rajapinnan perusteella). Basic Profile, kuten myös WS-I:n tarjoamat työkalut, ovat kaikille vapaasti saatavilla. Kuitenkin ainoastaan WS-I:n jäsenet voivat tarjota näitä työkaluja sekä muuta materiaalia WS-I:lle jaettaviksi. Jäsenet lisäksi voivat osallistua näiden suositusten suunnitteluun ja kehittämiseen. Basic Profile suosituksesta tullee uusia versioita, koska itse spesifikaatioiden kehitys jatkuu edelleen.

5 In EEWES research group at TUT, a tool has been developed that transforms WSDL document into a UML model (class diagram) and checks the conformance of that UML model against WS-I Basic Profile 1.0 and 1.1 rules represented as a UML profile 155 Tampereen teknillisen yliopiston ohjelmistotekniikan laitoksella EEWES-projektissa ( ) on tutkittu mm. UML:n roolia Web-palveluiden suunnittelussa. Projektissa on kehitetty esimerkiksi työkalu, jonka avulla WSDL-dokumentit voidaan kuvata UML-luokkakaavioina. Työkalu muodostaa dokumentista sekä matalan tason instanssikaavion sekä abstrahoidun version, joka kuvaa dokumentin loogista rakennetta. Instassikaaviossa jokaista WSDL-dokumentin elementtiä (esim. porttype) vastaa luokka luokkakaaviossa (oikeampi kaaviotyyppi olisi oliokaavio, mutta käytännön käytettyyn CASE-työkaluun liittyvistä ongelmista johtuen ko. instanssikaavio kuvataan luokkakaaviona). Kyseisen elementin attribuutit annetaan vastaavasti luokan attribuutteina. Abstrahoidussa luokkakaaviossa kutakin elementtityyppiä vastaa luokka (esim. aina vain yksi porttype luokka) ja niiden esiintymiskerrat kuvataan assosiaatioiden kertautumismääreinä. Lisäksi projektissa on kuvattu WS-I Basic Profile 1.0 suosituksen mukaiset WSDL:ää ja SOAP-sidontaa koskevat säännöt UML-profiileina OCL:ää hyödyntäen. UML-profiili kuvataan luokkakaaviona ja se määrää tiettyjä sääntöjä, jotka kunkin profiilin mukaisen mallin tulee ottaa huomioon (UMLspesifikaatiosta löytyy tarkempaa informaatiota UML-profiileista). Projektissa (hyödyntäen aiempien tutkimusprojektien tuloksia) on lisäksi toteutettu työkalu, jonka avulla annettu WSDL-dokumenttia kuvaava luokkakaavio voidaan validoida ko. profiilia vasten. Ts., työkalu etsii WSDL-kuvauksesta mahdollisia profiilin vastaisia kohtia. Löydetyt virheet listataan erillisessä editorissa (Error Browser), josta voidaan myös navigoida virheen sisältämiin kohtiin luokkakaaviossa.

6 Kuvassa on esitetty esimerkkiajo, jossa annettu WSDL-dokumentti on ensin muutettu luokkakaavion muotoon. Osa tästä Rational Rose CASE-työkaluun importoidusta luokkakaaviosta näkyy taustalla. Kuvan etualalla näkyy Error Browser selain, jossa on listattu kaikki havaitut virheet. Virhekoodeina (WSI2114 ja WSI2123) käytetään Basic Profile suosituksen mukaisia koodeja. Samoja koodeja käytetään myös WS-I Testing Tools työkalusetissä. Näin ollen näiden kahden työkalusetin antamia tuloksia voidaan helposti verrata keskenään. Käyttäjä on valinnut yhden virheistä, jolloin virheen sisältämä elementti (esitetty luokkana) tulee automaattisesti valituksi mallista. Toteutettu työkalusetti eroaa WS-I Testing Tools työkalusetistä mm. siinä, että WS-I Testing Tools ei tarjoa vastaavia navigointi- ja visualisointimahdollisuuksia.

7 Designing and realizing SOA 156

8 Service-Oriented Modeling and Architecture (SOMA) A method to model and design SOA, proposed by IBM Implements IBM s other method, service-oriented analysis and design (SOAD), through identification, specification and realization of the three SOA main elements: services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services More information A. Arsanjani, Service-Oriented Modeling and Architecture: How to Identify, Specify and Realize Services for your SOA, IBM developerworks, N. Bierberstein, S. Bose, M. Fiammante, K. Jones, and R. Shah, Service- Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, ISBN-13: , Oct A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce-Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June IBM:n SOMA on menetelmä, jonka tarkoituksena on tukea SOA-pohjaisten järjestelmien suunnittelua, mallintamista ja toteuttamista. Koska se on yksi ensimmäisistä ja ehkä myös laajimmin tunnetuista suunnittelumenetelmistä ja koska tällaisten menetelmien tarve (ja niiden puute) on laajalti havaittu, käsitellään SOMAa seuraavaksi esimerkinomaisesti. On kuitenkin syytä korostaa, että SOMAa ei menetelmänä voida missään nimessä kutsua (edes de facto) standardiksi. SOMA toteuttaa IBM:n toisen menetelmän SOAD, joka on kehitetty palveluorientoituneiden järjestelmien analyysi- ja suunnittelumenetelmäksi. Tämä menetelmä pohjautuu perinteisiin olio- ja komponenttipohjaisten järjestelmien analyysi- ja suunnittelumenetelmiin ja laajentaa niitä SOAn kannalta oleellisilla näkökulmilla. SOMA koostuu kolmesta päävaiheesta: SOAn peruselementtien tunnistaminen, spesifiointi ja realisointi. Nämä peruselementit ovat palvelut, palvelut realisoivat palvelukomponentit (service components) sekä palveluiden yhdistämiseen käytettävät vuot.

9 SOMA - Designing SOA systems The design strategy for a SOA does not start from the bottom-up" as is often the case with a Web services-based approach. You must remember that SOA is more strategic and business-aligned. (Ali Arsanjani, Service-oriented modeling and architecture, IBM developerworks, 2004). Activities of a service consumer (i.e. a user of a service, which can be a client or a service): Service identification, service categorization, choreography or composition, quality of service (QoS) Activities of a service provider: Component identification, component specification, service realization, service management, standards implementation, service allocations to components, layering the SOA, technical prototyping, product selection, architectural decisions (state, flow, dependencies) 158 A. Arsanjani korostaa artikkelissaan Service-oriented modeling and architecture, IBM developerworks, 2004, että suunniteltaessa SOA-pohjaisia järjestelmiä tulisi välttää bottom-up tyyppistä lähestymistapaa, jossa siis lähdetään yksityiskohdista (esim. olemassa olevasta koodista) ja valitaan/identifioidaan palvelut näiden yksityiskohtien perusteella tai johdattamana. Tällainen lähestymistapa harvoin johtaa parhaaseen mahdolliseen lopputulokseen. Arsanjani tähdentää, että sen sijaan tulisi muistaa, että SOAlla on strategista merkitystä ja sen tulisi huomioida myös liiketoimintaorientoitunut näkökulma. Tällöin siis top-down tai mahdollisesti näiden kahden lähestymistavan (top-down ja bottom-up) yhdistelmä olisi parempi. Kuten Arsanjani edelleen toteaa, bottom-up lähestymistapaa käytetään paljon Web-palvelujärjestelmiä toteutettaessa (service mining, software migration). Se ei silti liene se oikea tai paras lähestymistapa myöskään Webpalvelujärjestelmiä jotka myös ovat SOA-pohjaisia toteutettaessa. Kalvolla on listattu SOA-pohjaisen järjestelmän suunnittelussa huomioitavat palvelun käyttäjän (consumer) ja palvelun tarjoajan (provider) tehtävät ja roolit. Tässä palvelun käyttäjä (consumer) on erotettu termistä asiakas (client). Käyttäjä on palvelua käyttävä taho ja se voi olla josko asiakas tai palvelu. Huomaa, että palvelun käyttäjän aktiviteetit muodostavat alijoukon palvelun tarjoajan aktiviteeteista. Palvelun tarjoaja esimerkiksi myös tunnistaa, kategorisoi jne. palveluita. Palvelun käyttäjä spesifioi ensin ne palvelut, joita se tarvitsee (tyypillisesti etsimällä niitä tietyin kriteerein) ja varmistuttuaan sen jälkeen siitä, että etsittyjen palvelujen (kriteerit) ja toisaalta tarjotun/löydetyn palvelun spesifikaatiot vastaavat toisiaan (vaaditulla tavalla), se ottaa yhteyttä ko. palveluun. Palvelun tarjoajan puolestaan tulee julkaista tarjoamansa palvelut, sekä toiminnallisuuden että laatuattribuuttien (QoS) osalta. Tämä implisiittinen sopimus palvelun tarjoajan ja käyttäjän välillä voi mahdollisesti kypsyä eksplisiittiseksi SLA-sopimukseksi, joka on neuvoteltavissa joko elektronisesti (esim. ebxml, jota käsitellään myöhemmin) tai muutoin.

10 The layers of a SOA (A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce- Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June Service consumer Service provider Consumer Business process composition choreography business state machines Services Atomic Composite Service components Operational systems Packaged application Channel Business to business Custom application OO application Integration (enterprise service bus) Quality of service (security, management, and monitoring infrastructure services) Information architecture (metamedia and business intelligence) 159 Governance and policies Kalvon SOAn kerroksia havainnollista kuva on piirretty mukaellen kuvaa, joka on esitetty artikkelissa A. Asanajani, L.-J. Zhang, M Ellis, A. Allam, and K. Channabasavaiah, S3: A Serivce-Oriented Reference Architecture, IT Professional, IEEE Computer Society, May/June Kirjoittajat toteavat, että kuvan yhdeksan kerrosta ovat suhteellisen itsenäisiä, minkä vuoksi organisaatio voi valita palvelun tarjoajan ja käyttäjän integraation asteen. Esimerkiksi liiketointaprosessikerros ei välttämättä esiinny SOA-ratkaisussa. Tällöin palvelun käyttäjä ja tarjoaja voivat kommunikoida suoraan. Operatiivisten järjestelmien kerros (Operational systems) sisältää kaikki ne toimivat käytettävät sovellukset ja/tai niiden osat, jotka tukevat liiketoiminta-aktiviteetteja. Näihin sovelluksiin kuuluvat esimerkiksi legacy-järjestelmät, tietokannat ja vaikkapa pakatut sovellukset ja ratkaisut kuten ERP- tai CRM-ratkaisut. Palvelukerros (Services) puolestaan sisältää kaikki SOAan kuuluvat palvelut, sekä sellaiset jotka palvelun tarjoaja tarjoaa että käytettävät palvelut. Jokaisesta palvelusta tulee olla tieto tarjottavista operaatioista, kontaktipisteestä, kutsuprotokollan yksityiskohdista sekä palvelun semantiikasta (esim. liiketoimintakonteksti). Web-palvelujen tapauksessa kolme ensimmäistä saadaan WSDL-dokumentista. Seuraavassa liiketoimintaprosessikerroksessa (Business process) organisaatio koostaa palvelukerroksen palveluista prosesseja. Lopuksi kuluttajakerroksessa (Consumer) hoidetaan interaktiot käyttäjän tai muiden SOA-ekosysteemiin kuuluvien ohjelmien kanssa. Tämän kerroksen kautta organisaatio voi toisaalta välittää dataa sovelluksille ja käyttäjille tiettyjen preferenssien

11 mukaan ja toisaalta se voi nopeasti luoda liiketoimintaprosesseille ja sovelluksille front-end-liitännän, jonka avulla se voi mukautua erilaisiin ulkopuolisiin muutoksiin. Edellä mainittujen kerrosten lisäksi Asanajari et al. määrittävät neljä muuta edellisiä kerroksia hallinnoivia ja niihin vaikuttavia kerroksia. Integraatiokerros (Integration) integroi käytännössä kerrokset 2-4 (Service components, Services, Business processes). Integrointi voidaan toteuttaa vaikkapa ESB-ratkaisuna. Tämän kerroksen avulla organisaatio voi reitittää, välittää ja kuljettaa palvelukutsuja palvelun pyytäjältä konkreettiselle palvelulle. Laatuattribuuttikerros (Qualit of service, QoS) huolehtii ei-funktionaalisista vaatimuksista liittyen luotettavuuteen, saavutettavuuteen, hallittavuuteen, skaalautuvuuteen ja turvallisuuteen. Informaatioarkkitehtuurikerros (Information architecture) voi esimerkiksi sisältää tietoa ja/tai referenssejä koskien teollisuuden alalle spesifejä tai teollisuusalojen välisiä tietorakakenteita ja XML-pohjaisia metadata-arkkitehtuureja (XML Schema). Tämä kerros sisältää SOA-ekosysteemissä tarvittavan metadatan. Viimeisenä kerroksena Asanajani et al. esittävät hallintakerroksen (Governance and policies). Tämä kerros on vastuussa SOAekosysteemin hallinnoinnista koko liiketoimintaoperaatioiden elinkaaren ajan. Tämä kerros määrittää myös periaatteet ja säännöt SLA-sopimuksille (esim. kapasiteetti, tehokkuus, turvallisuus). Hallinnoinnin merkitys SOA-pohjaisille ratkaisuille onkin viime aikoina saanut paljon huomiota. Kuten kaikille järjestelmille, se on tärkeää myös SOA-pohjaisille ratkaisuille.

12 Designing and implementing Web services 160

13 Designing Web services Designing Web service capabilities for an application and designing the business logic of it are two different things Business logic design and implementation does not depend on Web service technologies e.g. an existing legacy system To design Web service capabilities, one needs to decide on what kind of interface with which service operations the Web service should have? how to receive and process requests? how to delegate the requests to the business logic? how to formulate and send responses? how to manage error situations and how to report about them? 161 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Webpalveluna. Tämä jako on oleellinen myös Web-palveluita suunniteltaessa. Itse palvelun toiminnallisuuden (puhutaan yleisesti myös liiketoimintalogiikasta) suunnittelun ei tarvitse riippua siitä onko se tarkoitettu käytettäväksi Web-palveluna eikä näin ollen myöskään riipu Webpalveluteknologioista. Se voi esimerkiksi olla olemassa oleva ohjelmisto, jota haluttaisiin hyödyntää Web-palveluna. Osaa, joka mahdollistaa ko. sovelluksen hyödyntämisen Web-palveluna, suunniteltaessa tulee päättää millainen on asiakassovelluksille näkyvä rajapinta (operaatiot), millaista interaktioita halutaan tukea, miten tämä interaktio muutetaan interaktioksi toiminnallisuuden toteuttavan osan kanssa, miten virhetilanteet raportoidaan asiakassovellukselle jne. Joissain tapauksissa tässä sovelluslogiikan päälle ajateltavassa ja asiakkaalle näkyvässä kerroksessa halutaan myös esikäsitellä viestejä ennen kuin ne välitetään itse sovelluslogiikan toteuttavalle osalle. Lisäksi palvelun käytön analysointi (esim. viestien monitorointi) voidaan toteuttaa tässä kerroksessa.

14 Service implementation Service client Service interaction layer Service processing layer A layered view of a Web service (from Designing Web Services with the J2EE(TM) 1.4 Platform : JAX-RPC, SOAP, and XML Technologies by Inderjeet Singh, Sean Brydon, Greg Murray, Vijay Ramachandran, Thierry Violleau, and Beth Stearns, Sun Microsystems, 2004.) 162 Palvelun interaktiokerros (interaction layer) koostuu asiakkaille näkyvästä ja niiden käyttämästä palvelun kontaktirajapinnasta (endpoint interface), viestien ja vastausten (SOAP) tulkinnan ja käsittelyn toteuttavasta logiikasta sekä integraatiosta sovelluslogiikan toteuttavan kerroksen kanssa. Vaikka kuvassa palvelun interaktiokerros ja varsinainen sovelluslogiikka on kuvattu yhtenä kokonaisuutena (Web-palvelu), saattavat ne käytännössä olla joko toteutettu tiiviisti integroituina tai selkeästi toisistaan erotettuina kokonaisuuksina, jotka on tavalla tai toisella integroitu toisiinsa. Interaktiokerroksen tehtävänä on tulkita ja käsitellä (SOAP-)kutsut, delegoida kutsut sovelluslogiikkakerrokselle, muokata vastaukset tarvittavaan muotoon (SOAP) ja lähettää vastaukset asiakassovellukselle. Palvelun sovelluslogiikan toteuttavan kerroksen tehtävänä on toteuttaa varsinainen palvelun toiminnallisuus.

15 Developing Web service interfaces 1) Java (or some other language) -> WSDL generating WSDL documents from an existing set of Java interfaces for the Web service + An easy approach + One need not to be aware of WSDL details - The developer looses some control over WSDL file creation - Comes with the cost of less flexibility - may be hard to evolve the service interface without forcing a change in the corresponding WSDL document, -> changing the WSDL might require rewriting the service s clients 2) WSDL -> Java - requires more from the designer, including more knowledge of WSDL and WS-I requirements 163 Web-palveluiden toteuttamiseen käytetään yleisesti kahta tapaa: (1) generoidaan WSDL-kuvaukset automaattisesti olemassa olevasta rajapintamäärittelystä ( Java->WSDL ) tai (2) generoidaan suunnitellusta WSDL-kuvauksesta palvelun rajapinnan toteuttavaa koodia ( WSDL->Java ). Java->WSDL tapa on näistä kahdesta helpompi ja yksinkertaisempi. Lisäksi sitä käytettäessä toteuttajan ei tarvitse välttämättä tuntea WSDL-kieltä. Toisaalta se tarkoittaa myös sitä, että Webpalvelua ajatellaan käytettävän RPC-tyyppiseen kommunikointiin: generoitu WSDL heijastelee suoraan valittua rajapintakoodia. Web-palvelukonseptia tulisi voida käyttää RPC-tyyppisen kommunikoinnin lisäksi dokumenttipohjaiseen kommunikointiin. Lisäksi RPC:n toteuttamiseen on olemassa useita tekniikoita eikä se vastaa Web-palvelukonseptin perustarkoitusta. Java->WSDL menetelmän huono puoli on myös joustamattomuus ja huono ylläpidettävyys: mikäli palvelun rajapintaan tehdään muutoksia, tulee WSDL generoida uudelleen, mikä puolestaan saattaa aiheuttaa muutoksia asiakaspäähän. Koska palvelulla on potentiaalisesti useita asiakkaista, ovat kaikki muutokset, jotka edellyttävät muutoksia myös asiakaspäähän ei-toivottuja. Versionhallinta ja ylläpidettävyys onkin yksi suurista haasteista Web-palveluille tällä hetkellä. Toinen tapa toteuttaa Web-palveluita, WSDL->Java vaatii taas enemmän palvelun toteuttajalta ja suunnittelijalta. Se vaatii esimerkiksi WSDL-kielen sekä WS-I suositusten tuntemista. Toisaalta huolellinen suunnittelu voi johtaa parempaan lopputulokseen.

16 Designing Web service clients Various kinds of clients may use Web services, e.g. heavy and rich client applications or light-weight clients such as wireless devices The client application should support the communication method (e.g. SOAP/HTTP) chosen locate the service(s) generate messages (e.g. SOAP) from native calls parse respond messages and transform them to native calls and/or map the data to its object model 164 Asiakasohjelman näkökulmasta Web-palvelu toimii mustana laatikkona: asiakasohjelma on kiinnostunut vain palvelun rajapinnasta, ei siitä miten se on toteutettu. Asiakasohjelmat voivat olla hyvin erilaisia kevyistä (esim. mobiililaitteet) aina monimutkaisempiin asiakassovelluksiin. Asiakassovelluksen tulee luonnollisesti tukea palvelun tukemaa kommunikointimenetelmää. Näistä yleisin on SOAP/HTTP. Asiakassovelluksen tulee myös tarvittaessa pystyä paikallistamaan palvelu. Ratkaisuissa, joissa tiedetään mitä palveluita käytetään, ei palveluja luonnollisesti tarvitse erikseen etsiä. Lisäksi asiakassovellus toteuttaa SOAPia käytettäessä SOAP-arkkitehtuurin asiakaspään. Tämä tarkoittaa käytännössä ns. proxyn toteuttamista, jonka avulla asiakassovellus kommunikoi palvelun kanssa. Sen tulee esimerkiksi generoida SOAP-viestejä natiivikutsuista tai WSDLkuvauksista ja toisaalta tulkita palvelun lähettämät SOAP-muotoiset vastaukset natiivikutsuiksi.

17 Designing Web service clients There are three methods for communication with a Web service, each of them relying on a kind of a client-side proxy that represents a Web service and is used for accessing the service s functionality: static stubs (static proxies) dynamic proxies dynamic invocation interface (DII) this is the only approach that does not rely on a (full) WSDL description at development time, but supports locating it at run-time from a service registry 165 Asiakasohjelmaa suunniteltaessa ja toteutettaessa ensimmäinen tehtävä on selvittää käytettävän Webpalvelun kuvauksen (WSDL) sijainti ja valita osin sen perusteella kommunikoinnin toteutustapa. Näitä tapoja on kolme. Kaikki niistä nojaavat tavalla tai toisella jonkinlaisen asiakaspään proxyn käyttöön. Proxy edustaa Web-palvelua ja sitä käytetään haluttaessa käyttää itse palvelua. Näistä tavoista ensimmäinen, ns. staattinen tapa, tarkoittaa sitä, että proxyn koodi tulee kääntää toteutusvaiheessa ja jopa ennen asiakassovelluksen kääntämistä. Tällä tyylillä toteutetut asiakasohjelmat saattavat mennä helpostikin toimintakyvyttömiksi mikäli palvelussa, johon ne ovat yhteydessä, tapahtuu muutoksia. Staattinen tapa on kuitenkin eri tavoista yksinkertaisin ja helpoin. Sekä staattinen että dynaaminen tapa edellyttää, että palvelun kuvaus (WSDL) on olemassa, sillä proxyn (dynaaminen tai staattinen) generointi tapahtuu WSDL-dokumentin tietojen perusteella. Dynaaminen tapa on kuitenkin joustavampi kuin staattinen tapa. Se tarjoaa periaatteessa saman toiminnallisuuden, mutta tekee sen dynaamisesti. Kolmas tapa, ns. dynaaminen kutsurajapinta, on näistä tavoista ainoa, joka sallii puhtaan SOA:n mukaisen kommunikoinnin, ts. WSDL-dokumentin etsimisen ajonaikana esimerkiksi etsimällä sitä palvelurekisteristä. Seuraavaksi tutustumme näihin tapoihin hieman tarkemmin.

18 Communicating using static stubs Static stub classes that enable the service and the client to communicate are generated during development time The platform-specific stub class is generated for a WSDL description prior to the client s deployment and compilation represents the service endpoint interface converts requests to (e.g.) SOAP messages and sends them to the service convertssoap responsesbackto a form understandable by the client software -> stub acts as a proxy for the service endpoint 166 Staattisessa tavassa siis myös proxyn koodi kirjoitetaan ja käännetään staattisesti ennen ajamista. Tämä koodi tyypillisesti generoidaan olemassa olevasta WSDL-kuvauksesta. Yleisimmin käytetyt työkalusetit tarjoavat siihen valmiit työkalut. Tässä on huomioitavaa siis se, että käytettävän palvelun WSDL-kuvaus tulee olla tiedossa jo asiakaspäätä toteutettaessa. Staattinen proxy edustaa asiakaspäälle palvelun rajapintaa. Kuten edellä mainittiin, sen tulee generoida SOAP-viestit ja toisaalta sen tulee purkaa SOAP-muotoiset vastaukset asiakassovelluksen ymmärtämään muotoon. Näin ollen se toimii proxyna Web-palvelulle.

19 Communicating using static stubs Worth using when services and especially their WSDL documents are unlikely to change over time + Easy to use (working with generated classes) - Creates dependencies between the client and the service -> problems, if the service changes - Requires that the stub classes are generated prior to the compilation of the client application 167 Staattista tapaa kannattaa käyttää silloin kun WSDL-kuvaukset on tiedossa ja niihin ei odoteta tulevan muutoksia. Tässä tapauksessa on siis erityisen hankalaa kaikki palvelun evoluutiosta aiheutuvat ja sen kutsurajapintaan heijastuvat muutokset. Tämä tapa on myös suhteellinen helppo toteuttajan kannalta, koska suuri osa koodista voidaan generoida automaattisesti. Toisaalta tämä tapa aiheuttaa riippuvuuksia asiakkaan ja palvelun välille. Web-palvelun perusidea on tehdä asiakas- ja palvelusovellukset mahdollisimman riippumattomiksi ja siten olla todellinen edistysaskel verrattaessa olemassa oleviin hajautusteknologioihin. Tällaiset riippuvuudet ovat aina hankalia palvelua muutettaessa. Lisäksi tämä tapa edellyttää, että proxy luokat generoidaan ennen asiakassovelluksen kääntämistä.

20 Communicating using dynamic proxies Corresponding to the static stub approach, but things are carried out dynamically: instead of requiring early compilation of the stub class (prior to the compilation of the client application), an equivalent dynamic proxy is generated at runtime Client-side developers need a (client-side) interface that matches the service endpoint -> clients program to that interface Like in the static approach, a WSDL description is needed for proxy generation + Portable, vendor-independent code can be written Java classes to serve as value types might also be needed Useful approach if portability is desired and if services are exptected to change only occationally - There might be a performance overhead 168 Dynaaminen tapa vastaa hyvin pitkälle staattista tapaa, mutta proxyn luominen tehdään dynaamisesti ajonaikana. Tämä menetelmä edellyttää palvelun rajapintaa vastaavan asiakaspään rajapinnan olemassaoloa. Dynaaminen proxy generoidaan sitä hyödyntäen. Lisäksi saatetaan tarvita Java-luokkia, jotka edustavat käytettäviä tyyppejä. Näillä luokilla tulee olla kentille (tyypeille) omat set- ja getmetodit. Dynaaminen tapa tuottaa luonnollisesti staattista tapaa siirrettävämpiä toteutuksia. Koska myös tämä tapa edellyttää WSDL-kuvauksen olemassaolon (ja palvelun rajapintaa vastaavan asiakaspään rajapinnan olemassaolon), saattavat palvelun muutokset tuottaa ongelmia. Ongelmat ovat kuitenkin oletettavasti pienempiä kuin staattista tapaa käytettäessä. Dynaaminen tapa tosin voi aiheuttaa hitautta ajonaikana juuri sen dynaamisuudesta johtuen.

21 Communicating using DIIs A client can call a service without knowing the exact service name (operations) and address at compile time More difficult for a developer to use, since a more complex interface (compared to static stubs and dynamic proxy approaches) needs to be used This interface is more prone to class cast errors - Performance overhead + Useful when a complete WSDL document is not available, esp. when ports are not specified + Useful when the service is expected to be changed frequently 169 Viimeinen asiakaspään toteutustapa, dynaaminen kutsurajapinta, on näistä kolmesta eri tavoista joustavin mutta myös haastavin ja monimutkaisin. Käytettävä rajapinta on huomattavasti monimutkaisempi verrattaessa staattiseen ja dynaamiseen tapaan. Lisäksi ko. rajapinta on käytännössä alttiimpi tyyppimuunnoksista aiheutuville ongelmille. Dynaaminen kutsurajapinta on ainoa tapa, joka toteuttaa SOA:n puhtaasti: se on tavoista ainoa, joka sallii palvelun kutsumisen ilman, että sen rajapinta (tarjotut operaatiot) ja osoite on tiedossa käännösaikana. Näin ollen se sallii esimerkiksi palvelun etsimisen ajonaikana palvelurekisteristä. Dynaaminen kutsurajapinta on puhtaasti dynaaminen tapa: se ei edellytä lainkaan käytettävään palveluun liittyvän koodin luomista asiakasohjelmaa luotaessa. Tässäkin tapauksessa tai erityisesti tässä tapauksessa tehokkuusongelmia saattaa ilmetä varsinaisia palvelukutsuja tehtäessä. Tämä tapa on erityisen hyödyllinen silloin, kun palvelun rajapinnan oletetaan muuttuvan usein. Lisäksi tämä on ainoa tapa, joka ei edellytä täydellisen WSDL-kuvauksen olemassaoloa.

22 Legacy systems as Web services 170

23 Legacy systems Old, valuable systems that are often designed and implemented using methods and programming languages that are no longer in use legacy means something valuable and something inherited There is a growing need to access legacy systems in current net-centric applications and Web services 171 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ä saattaa olla puutteellista. Sana legacy itsessään tarkoittaa jotain perittyä ja arvokasta. Nämä ominaisuudet pätevät myös legacy-järjestelmiin. Legacy-järjestelmien modifiointi on usein erittäin vaikeaa eikä useinkaan kannattavaa. Syitä tähän on monia: systeemit on toteutettu vanhoilla ohjelmointikielillä suurella todennäköisyydellä ko. systeemien arkkitehtejä, suunnittelijoita ja koodaajia on vaikea tavoittaa (sikäli kun käytettyjen ohjelmointikielten osaajia ylipäätään on mahdollista löytää) mikäli modifiointeja tarvitaan, niin ne (erityisesti arkkitehtuuritason muutokset) käytännössä vaativat niin paljon työtä, että usein voi olla helpompaa rakentaa uusi järjestelmä usein legacy-järjestelmän statuksen saavuttaneet systeemit toimivat kohtuullisesti (koska niiden elinikä on osoittautunut odotettua pidemmäksi) eikä suuret rakenteelliset tai toiminnalliset muutokset ole aina välttämättömiä. esimerkiksi proseduraalisten ohjelmien konvertoiminen oliopohjaisiksi on osoittautunut usein huonoksi ideaksi: vaikka uusi oliopohjainen ratkaisu toimisikin, (a) se saattaa olla hitaampi tai (b) ohjelmoijat yksinkertaisesti hylkäävät uuden ratkaisun, koska se ei vastaa heidän ymmärrystään algoritmien rakenteesta tai ohjelman arkkitehtuurista.

24 Legacy systems It has proven to be often too costly, too risky, and too time consuming to reimplement the legacy systems from scratch. Wrapping the legacy system is often the best solution for enabling its reuse, e.g. transforming it to a Web service minimal changes to the source enables the reuse of current functions in new applications isolates the particular implementation from the user of the function/feature 172 Edellä mainituista syistä legacy-järjestelmien korvaaminen uusilla tai muilla olemassa olevilla järjestelmillä on usein varsin riskialtista. Lisäksi erityisesti uuden järjestelmän rakentaminen on usein hyvin aikaa vievää ja näin ollen kallista. Tämän vuoksi se ei aina ole edes realistinen vaihtoehto. Vanhoja legacy-järjestelmiä ei näin ollen käytännössä haluta useinkaan heittää pois vaan ne halutaan tavalla tai toisella käytettäväksi uudessa muuttuneessa ympäristössä. Usein paras tapa on kääriä (wrap) ne. Kääriminen edellyttää vain hyvin suhteellisen pieniä muutoksia ko. ohjelmaan, sallii olemassa olevan toiminnallisuuden ja toteutuksen käytön ja erottaa toteutetut ominaisuudet niiden käyttäjistä. Käärimistekniikoita käsitellään tarkemmin kurssilla Ohjelmien ylläpito ja evoluutio.

25 Requirements and expectations for wrapping Legacy systems/applications must include functions with high business value and good technical quality (e.g. robustness) The systems and their functionalities must be bounded, and they should have manageable APIs The system to be wrapped should have (enough) expected value in the future Wrapping should be worth the effort, compared to re-engineering the system building a new system from the scratch replacing the system with another alternative 173 Jotta kääriminen olisi varteenotettava vaihtoehto, edellytetään myös käärittävältä ohjelmalta tiettyjä ominaisuuksia. Käärittävän ohjelman tulee ensinnäkin olla käärimisen arvoinen. Sillä tulee toisin sanoen olla tarpeeksi arvokkaita (esimerkiksi luotettavuuden tai tehokkuuden näkökulmasta) ominaisuuksia, joita halutaan käyttää jatkossakin. Käärittävän ohjelmalla tulee myös olla riittävän hyvä ja käytettävä API ja käytettävät ominaisuudet tulee olla selkeästi identifioitavissa ja kutsuttavissa ko. APIa käyttäen. Näiden lisäksi verrattaessa vaihtoehtoisiin ratkaisuihin, kuten ohjelman uudelleen kirjoittaminen tai sen korvaaminen toisella ohjelmalla, käärimisen tulee paras ratkaisu arvioitaessa työmäärää ja hyötyä sekä niiden suhdetta (cost-benefit).

26 Wrapping considerations There might be a need for not corresponding wrapper and application interfaces e.g. when data structures that client uses are not isomorfic with the data structures legacy system uses e.g. when providing a higher level wrapper interface a wrapper s operation might be decomposed to several application calls XML wrapping might cause some overhead but is flexible Use design patterns, e.g., Wrapper, Adapter, Facade, Bridge 174 Käärimisen ei välttämättä aina haluta tarjoavan täsmälleen vastaavaa rajapintaa kuin alkuperäinen ohjelma, erona vain käytettävä kieli (esim. SOAP-rajapinta C++ -ohjelmalle). Voidaan esimerkiksi haluta, että uuden rajapinnan kutsuttava operaatio käyttää legacy-ohjelman useampaa operaatiota. Tällöin rajapinnassa tai tarkemmin ottaen interaktiokerroksessa voidaan käyttää ns. mukauttajia tai välittäjiä, jotka tekevät tarvittavat muutoksen. Mukauttajien käyttöä edellyttää myös tilanteet, joissa asiakasohjelman käyttämät tietorakenteet voivat erota legacy-ohjelman käyttämistä tietorakenteista. Kääreen erottaminen legacy-ohjelmasta - tai yleisemmin interaktiokerroksen erottaminen liiketoimintalogiikasta kannattaa suunnitella joustavaksi ratkaisuksi. Tähän tarkoitukseen voi käyttää esimerkiksi Façade, Wrapper, Adapter ja Bridge suunnittelumalleja. Suunnittelumalleja käsitellään tarkemmin Ohjelmistoarkkitehtuurit kurssilla ja käärimisen yksityiskohtiin puolestaan perehdytään Ohjelmistojen ylläpito ja evoluutio kurssilla. XML-kääre aiheuttaa käytännössä hitautta, koska se esimerkiksi edellyttää aina myös XML-jäsentäjän käyttöä. Toisaalta XML-kääreellä on etunsakin. Käärittäessä ohjelma esimerkiksi Internetiä hyödyntäväksi Web-palveluksi, voidaan sitä käyttää laajalti muista ohjelmista käsin.

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k

Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa k 1 Web-palvelu voidaan ajatella jaettavaksi kahteen erilliseen kokonaisuuteen: itse palvelun toiminnallisuuden toteuttava osa ja osa, joka mahdollistaa ko. toiminnallisuuden hyödyntämisen Web-palveluna.

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

Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti

Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti 1 Edellä esitetty tapa toteuttaa palvelupohjaisia järjestelmiä edustaa nk. top-down lähestymistapaa. Oleellisesti siinä siis edetään systemaattisesti abstrakteimmalta tasolla tarkentaen yhä yksityiskohtaisemmalle

Lisätiedot

Web service interoperability (WS-I)

Web service interoperability (WS-I) Web service interoperability (WS-I) 96 Web service interoperability organization (WS-I) Founded 2.6.2002 See: www.ws-i.org Assists in creating and deploying interoperable Web services Interoperability

Lisätiedot

7.4 Variability management

7.4 Variability management 7.4 Variability management time... space software product-line should support variability in space (different products) support variability in time (maintenance, evolution) 1 Product variation Product

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

Enterprise Architecture TJTSE Yrityksen kokonaisarkkitehtuuri

Enterprise Architecture TJTSE Yrityksen kokonaisarkkitehtuuri Enterprise Architecture TJTSE25 2009 Yrityksen kokonaisarkkitehtuuri Jukka (Jups) Heikkilä Professor, IS (ebusiness) Faculty of Information Technology University of Jyväskylä e-mail: jups@cc.jyu.fi tel:

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

SOA SIG SOA Tuotetoimittajan näkökulma

SOA SIG SOA Tuotetoimittajan näkökulma SOA SIG SOA Tuotetoimittajan näkökulma 12.11.2007 Kimmo Kaskikallio IT Architect Sisältö IBM SOA Palveluiden elinkaarimalli IBM Tuotteet elinkaarimallin tukena Palvelukeskeinen arkkitehtuuri (SOA) Eri

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

TietoEnator Pilot. Ari Hirvonen. TietoEnator Oyj. Senior Consultant, Ph. D. (Economics) presentation TietoEnator 2003 Page 1

TietoEnator Pilot. Ari Hirvonen. TietoEnator Oyj. Senior Consultant, Ph. D. (Economics) presentation TietoEnator 2003 Page 1 TietoEnator Pilot Ari Hirvonen Senior Consultant, Ph. D. (Economics) TietoEnator Oyj presentation TietoEnator 2003 Page 1 Sallikaa minun kysyä, mitä tietä minun tulee kulkea? kysyi Liisa. Se riippuu suureksi

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

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3

Lisätiedot

IoT-platformien vertailu ja valinta erilaisiin sovelluksiin / Jarkko Paavola

IoT-platformien vertailu ja valinta erilaisiin sovelluksiin / Jarkko Paavola IoT-platformien vertailu ja valinta erilaisiin sovelluksiin 10.3.2017 / Jarkko Paavola Prosessi state-of-the-art -tilan määrittelemiseksi Vaatimusmäärittely platformille Arkkitehtuuri Valittiin IIC:n (http://www.iiconsortium.org/)

Lisätiedot

On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31)

On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) Juha Kahkonen Click here if your download doesn"t start automatically On instrument costs

Lisätiedot

2 Description of Software Architectures

2 Description of Software Architectures 2 Description of Software Architectures 2.1 Significance of architectural descriptions 2.2 Context of architectural descriptions 2.3 Levels of architectural descriptions 2.4 Viewpoints and types in architecture

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

RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS

RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS RAIN RAKENTAMISEN INTEGRAATIOKYVYKKYYS Loppuseminaari 11.12.2018 YIT:n pääkonttori, Helsinki RAIN hankkeen loppuseminaari 11.12.2018 Käyttäjälähtöinen tiedonhallinta (WP 4) Professori Harri Haapasalo OY

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

1 Introduction. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2006

1 Introduction. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2006 1 Introduction 1.1 What is software architecture? 1.2 Why is software architecture important? 1.3 Architecting process 1.4 Architecture-oriented programming 1.5 Conclusions 1 1.1 What is software architecture?

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

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

Security server v6 installation requirements

Security server v6 installation requirements CSC Security server v6 installation requirements Security server version 6.x. Version 0.2 Pekka Muhonen 2/10/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes Contents

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

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

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

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

in condition monitoring

in condition monitoring Etäteknologioiden automaatiosovellukset Using e-speak e in condition monitoring tutkija professori Hannu Koivisto Sisältö Tausta Globaali kunnonvalvontajärjestelmä E-speak globaalissa kunnonvalvontajärjestelmässä

Lisätiedot

A Service-Oriented Architecture (SOA) View of IHE Profiles

A Service-Oriented Architecture (SOA) View of IHE Profiles A Service-Oriented Architecture (SOA) View of IHE Profiles HL7 IHE meeting 20.8.2009 Timo Itälä SoberIT, TKK Juha Mykkänen, KuY 2 SoberIT IHE ja SOA (palveluarkkitehtuuri) SOA (service-oriented architecture)

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

Salasanan vaihto uuteen / How to change password

Salasanan vaihto uuteen / How to change password Salasanan vaihto uuteen / How to change password Sisällys Salasanakäytäntö / Password policy... 2 Salasanan vaihto verkkosivulla / Change password on website... 3 Salasanan vaihto matkapuhelimella / Change

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

Collaborative & Co-Creative Design in the Semogen -projects

Collaborative & Co-Creative Design in the Semogen -projects 1 Collaborative & Co-Creative Design in the Semogen -projects Pekka Ranta Project Manager -research group, Intelligent Information Systems Laboratory 2 Semogen -project Supporting design of a machine system

Lisätiedot

Sisällysluettelo Table of contents

Sisällysluettelo Table of contents Sisällysluettelo Table of contents OTC:n Moodlen käyttöohje suomeksi... 1 Kirjautuminen Moodleen... 2 Ensimmäinen kirjautuminen Moodleen... 2 Salasanan vaihto... 2 Oma käyttäjäprofiili... 3 Työskentely

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

National Building Code of Finland, Part D1, Building Water Supply and Sewerage Systems, Regulations and guidelines 2007

National Building Code of Finland, Part D1, Building Water Supply and Sewerage Systems, Regulations and guidelines 2007 National Building Code of Finland, Part D1, Building Water Supply and Sewerage Systems, Regulations and guidelines 2007 Chapter 2.4 Jukka Räisä 1 WATER PIPES PLACEMENT 2.4.1 Regulation Water pipe and its

Lisätiedot

Efficiency change over time

Efficiency change over time Efficiency change over time Heikki Tikanmäki Optimointiopin seminaari 14.11.2007 Contents Introduction (11.1) Window analysis (11.2) Example, application, analysis Malmquist index (11.3) Dealing with panel

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

Results on the new polydrug use questions in the Finnish TDI data

Results on the new polydrug use questions in the Finnish TDI data Results on the new polydrug use questions in the Finnish TDI data Multi-drug use, polydrug use and problematic polydrug use Martta Forsell, Finnish Focal Point 28/09/2015 Martta Forsell 1 28/09/2015 Esityksen

Lisätiedot

VBE2 Työpaketit Jiri Hietanen / TTY

VBE2 Työpaketit Jiri Hietanen / TTY VBE2 Työpaketit Jiri Hietanen / TTY 1 WP2.1 Technology review and VBE platform 2 Tavoitteet In In charge: charge: Method: Method: Jiri Jiri Hietanen, Hietanen, TUT TUT Analysis Analysis of of existing

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

.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

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

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA, Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat

Lisätiedot

Olet vastuussa osaamisestasi

Olet vastuussa osaamisestasi Olet vastuussa osaamisestasi Ohjelmistoammattilaisuuden uudet haasteet Timo Vehmaro 02-12-2015 1 Nokia 2015 Mitä osaamista tulevaisuudessa tarvitaan? Vahva perusosaaminen on kaiken perusta Implementaatio

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

You can check above like this: Start->Control Panel->Programs->find if Microsoft Lync or Microsoft Lync Attendeed is listed

You can check above like this: Start->Control Panel->Programs->find if Microsoft Lync or Microsoft Lync Attendeed is listed Online Meeting Guest Online Meeting for Guest Participant Lync Attendee Installation Online kokous vierailevalle osallistujalle Lync Attendee Asennus www.ruukki.com Overview Before you can join to Ruukki

Lisätiedot

Katselupalvelujen INSPIRE-yhteensopivuuden testaus

Katselupalvelujen INSPIRE-yhteensopivuuden testaus Katselupalvelujen INSPIRE-yhteensopivuuden testaus Infrastruktuuri-ryhmä 19.10.2011 Jani Kylmäaho 1 Miksi? Sisältö Yleisimmät ongelmat rajapintapalvelujen yhteensopivuudessa WMS-standardiin Yleisimmät

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

Domain spesifinen mallinnus ja generointi käytännössä. Petri Savolainen

Domain spesifinen mallinnus ja generointi käytännössä. Petri Savolainen Domain spesifinen mallinnus ja generointi käytännössä Petri Savolainen Agenda o Taustaa o DSM yleisesti o Meidän versiomme DSM:ästä o Case Muistaako kukaan? o Helppoa o Tuottavaa o Businessongelman ratkomista

Lisätiedot

1. SIT. The handler and dog stop with the dog sitting at heel. When the dog is sitting, the handler cues the dog to heel forward.

1. SIT. The handler and dog stop with the dog sitting at heel. When the dog is sitting, the handler cues the dog to heel forward. START START SIT 1. SIT. The handler and dog stop with the dog sitting at heel. When the dog is sitting, the handler cues the dog to heel forward. This is a static exercise. SIT STAND 2. SIT STAND. The

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

Voice Over LTE (VoLTE) By Miikka Poikselkä;Harri Holma;Jukka Hongisto

Voice Over LTE (VoLTE) By Miikka Poikselkä;Harri Holma;Jukka Hongisto Voice Over LTE (VoLTE) By Miikka Poikselkä;Harri Holma;Jukka Hongisto If you are searched for a book by Miikka Poikselkä;Harri Holma;Jukka Hongisto Voice over LTE (VoLTE) in pdf form, then you have come

Lisätiedot

WP3 Decision Support Technologies

WP3 Decision Support Technologies WP3 Decision Support Technologies 1 WP3 Decision Support Technologies WP Leader: Jarmo Laitinen Proposed budget: 185 000, VTT 100 000, TUT 85 000. WP3 focuses in utilizing decision support technologies

Lisätiedot

Microsoft Lync 2010 Attendee

Microsoft Lync 2010 Attendee VYVI MEETING Lync Attendee 2010 Instruction 1 (15) Microsoft Lync 2010 Attendee Online meeting VYVI MEETING Lync Attendee 2010 Instruction 2 (15) Index 1 Microsoft LYNC 2010 Attendee... 3 2 Acquiring Lync

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

CASE POSTI: KEHITYKSEN KÄRJESSÄ TALOUDEN SUUNNITTELUSSA KETTERÄSTI PALA KERRALLAAN

CASE POSTI: KEHITYKSEN KÄRJESSÄ TALOUDEN SUUNNITTELUSSA KETTERÄSTI PALA KERRALLAAN POSTI GROUP CASE POSTI: KEHITYKSEN KÄRJESSÄ TALOUDEN SUUNNITTELUSSA KETTERÄSTI PALA KERRALLAAN TIINA KATTILAKOSKI POSTIN TALOUDEN SUUNNITTELU Mistä lähdettiin liikkeelle? Ennustaminen painottui vuosisuunnitteluun

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

FinFamily PostgreSQL installation ( ) FinFamily PostgreSQL

FinFamily PostgreSQL installation ( ) FinFamily PostgreSQL FinFamily PostgreSQL 1 Sisällys / Contents FinFamily PostgreSQL... 1 1. Asenna PostgreSQL tietokanta / Install PostgreSQL database... 3 1.1. PostgreSQL tietokannasta / About the PostgreSQL database...

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

The CCR Model and Production Correspondence

The CCR Model and Production Correspondence The CCR Model and Production Correspondence Tim Schöneberg The 19th of September Agenda Introduction Definitions Production Possiblity Set CCR Model and the Dual Problem Input excesses and output shortfalls

Lisätiedot

Copernicus, Sentinels, Finland. Erja Ämmälahti Tekes,

Copernicus, Sentinels, Finland. Erja Ämmälahti Tekes, Copernicus, Sentinels, Finland Erja Ämmälahti Tekes, 24.5.2016 Finnish Space industry in the European context European Space industry has been constantly growing and increasing its direct employment in

Lisätiedot

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

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 811122P (5 op.) 12.12.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan

Lisätiedot

VUOSI 2015 / YEAR 2015

VUOSI 2015 / YEAR 2015 VUOSI 2015 / YEAR 2015 Kansainvälisen opetuksen ja tutkimustoiminnan kehittäminen Developing international teaching and research activities Rehtorin strateginen rahoitus vuosille 2014-2016 / Strategic

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

Visualisoinnin aamu 16.4 Tiedon visualisointi. Ari Suominen Tuote- ja ratkaisupäällikkö Microsoft

Visualisoinnin aamu 16.4 Tiedon visualisointi. Ari Suominen Tuote- ja ratkaisupäällikkö Microsoft Visualisoinnin aamu 16.4 Tiedon visualisointi Ari Suominen Tuote- ja ratkaisupäällikkö Microsoft 1 Visualisoinnin aamu 8:00 Ilmoittautuminen ja aamukahvi 8:45 Tiedon visualisointi Ari Suominen, Tuote-

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

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

Infrastruktuurin asemoituminen kansalliseen ja kansainväliseen kenttään Outi Ala-Honkola Tiedeasiantuntija

Infrastruktuurin asemoituminen kansalliseen ja kansainväliseen kenttään Outi Ala-Honkola Tiedeasiantuntija Infrastruktuurin asemoituminen kansalliseen ja kansainväliseen kenttään Outi Ala-Honkola Tiedeasiantuntija 1 Asemoitumisen kuvaus Hakemukset parantuneet viime vuodesta, mutta paneeli toivoi edelleen asemoitumisen

Lisätiedot

Innovative and responsible public procurement Urban Agenda kumppanuusryhmä. public-procurement

Innovative and responsible public procurement Urban Agenda kumppanuusryhmä.   public-procurement Innovative and responsible public procurement Urban Agenda kumppanuusryhmä https://ec.europa.eu/futurium/en/ public-procurement Julkiset hankinnat liittyvät moneen Konsortio Lähtökohdat ja tavoitteet Every

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

Information on preparing Presentation

Information on preparing Presentation Information on preparing Presentation Seminar on big data management Lecturer: Spring 2017 20.1.2017 1 Agenda Hints and tips on giving a good presentation Watch two videos and discussion 22.1.2017 2 Goals

Lisätiedot

KOMPETENSSIT. Koulutus Opiskelija Tuuttori. Business Information Technologies. NQF, Taso 6 - edellyttävä osaaminen

KOMPETENSSIT. Koulutus Opiskelija Tuuttori. Business Information Technologies. NQF, Taso 6 - edellyttävä osaaminen Koulutus Opiskelija Tuuttori Business Information Technologies NQF, Taso 6 - edellyttävä osaaminen Ammattikorkeakoulututkinto ja alempi korkeakoulututkinto Hallitsee laaja-alaiset ja edistyneet oman alansa

Lisätiedot

XPages käyttö ja edut Jarkko Pietikäinen toimitusjohtaja, Netwell Oy

XPages käyttö ja edut Jarkko Pietikäinen toimitusjohtaja, Netwell Oy IBM Collaboration Forum ٨.٣.٢٠١١ XPages käyttö ja edut Jarkko Pietikäinen toimitusjohtaja, Netwell Oy ٢٠١١ IBM Corporation Domino-sovelluskehitys Nopea kehitysympäristö (Rapid application development,

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

BLOCKCHAINS AND ODR: SMART CONTRACTS AS AN ALTERNATIVE TO ENFORCEMENT

BLOCKCHAINS AND ODR: SMART CONTRACTS AS AN ALTERNATIVE TO ENFORCEMENT UNCITRAL EMERGENCE CONFERENCE 13.12.2016 Session I: Emerging Legal Issues in the Commercial Exploitation of Deep Seabed, Space and AI BLOCKCHAINS AND ODR: SMART CONTRACTS AS AN ALTERNATIVE TO ENFORCEMENT

Lisätiedot

On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31)

On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) On instrument costs in decentralized macroeconomic decision making (Helsingin Kauppakorkeakoulun julkaisuja ; D-31) Juha Kahkonen Click here if your download doesn"t start automatically On instrument costs

Lisätiedot

Group 2 - Dentego PTH Korvake. Peer Testing Report

Group 2 - Dentego PTH Korvake. Peer Testing Report Group 2 - Dentego PTH Korvake Peer Testing Report Revisions Version Date Author Description 1.0 Henrik Klinkmann First version Table of Contents Contents Revisions... 2 Table of Contents... 2 Testing...

Lisätiedot

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

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

Other approaches to restrict multipliers

Other approaches to restrict multipliers Other approaches to restrict multipliers Heikki Tikanmäki Optimointiopin seminaari 10.10.2007 Contents Short revision (6.2) Another Assurance Region Model (6.3) Cone-Ratio Method (6.4) An Application of

Lisätiedot

ProAgria. Opportunities For Success

ProAgria. Opportunities For Success ProAgria Opportunities For Success Association of ProAgria Centres and ProAgria Centres 11 regional Finnish ProAgria Centres offer their members Leadership-, planning-, monitoring-, development- and consulting

Lisätiedot

Missä mennään BI? Mikko Kontio

Missä mennään BI? Mikko Kontio Missä mennään BI? Mikko Kontio Source: EMC - Big Data in 2020 % Business Intelligence Business Analytics set of theories, methodologies, architectures, and technologies that transform raw data into meaningful

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

C++11 seminaari, kevät Johannes Koskinen

C++11 seminaari, kevät Johannes Koskinen C++11 seminaari, kevät 2012 Johannes Koskinen Sisältö Mikä onkaan ongelma? Standardidraftin luku 29: Atomiset tyypit Muistimalli Rinnakkaisuus On multicore systems, when a thread writes a value to memory,

Lisätiedot

.NET ajoympäristö. Juha Järvensivu 2007

.NET ajoympäristö. Juha Järvensivu 2007 .NET ajoympäristö Juha Järvensivu juha.jarvensivu@tut.fi 2007 Käännösprosessi C# lähdekoodi C# kääntäjä CILtavukoodi JITkäännös Ajettava natiivikoodi Kehitysympäristössä ohjelmoijan toimesta Ajonaikana.NET

Lisätiedot

Microsoft Visual J++ ohjelmointiympäristö

Microsoft Visual J++ ohjelmointiympäristö Microsoft Visual J++ ohjelmointiympäristö Ohjelmistotuotantovälineet seminaarin alustus Raine Lehto Helsingin yliopisto Tietojenkäsittelytieteen laitos 08.11.2000 Helsinki Sisällys 1 Johdanto...2 2 Sovelluskehys

Lisätiedot

Tietorakenteet ja algoritmit

Tietorakenteet ja algoritmit Tietorakenteet ja algoritmit Taulukon edut Taulukon haitat Taulukon haittojen välttäminen Dynaamisesti linkattu lista Linkatun listan solmun määrittelytavat Lineaarisen listan toteutus dynaamisesti linkattuna

Lisätiedot

KONEISTUSKOKOONPANON TEKEMINEN NX10-YMPÄRISTÖSSÄ

KONEISTUSKOKOONPANON TEKEMINEN NX10-YMPÄRISTÖSSÄ KONEISTUSKOKOONPANON TEKEMINEN NX10-YMPÄRISTÖSSÄ https://community.plm.automation.siemens.com/t5/tech-tips- Knowledge-Base-NX/How-to-simulate-any-G-code-file-in-NX- CAM/ta-p/3340 Koneistusympäristön määrittely

Lisätiedot

Capacity Utilization

Capacity Utilization Capacity Utilization Tim Schöneberg 28th November Agenda Introduction Fixed and variable input ressources Technical capacity utilization Price based capacity utilization measure Long run and short run

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

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

Esitykset jaetaan tilaisuuden jälkeen, saat linkin sähköpostiisi. Toivottavasti vastaat myös muutamaan kysymykseen tapahtumasta Have a lot of fun!

Esitykset jaetaan tilaisuuden jälkeen, saat linkin sähköpostiisi. Toivottavasti vastaat myös muutamaan kysymykseen tapahtumasta Have a lot of fun! SUSEtoberfest 2017 #SUSEtoberfest @SUSESuomi Wifi saatavilla SSID:Korjaamonavoin salasana: korjaamo Finceptum koulutuksen ständi Lasse Paavola SUSE ja Micro Focus Secure -tiimi Esitykset jaetaan tilaisuuden

Lisätiedot

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Oracle10 g Web Services Sisältö Service Oriented Architecture (SOA) Web Services Service Oriented Architecture Service Oriented

Lisätiedot

Attribuuttipohjainen käyttövaltuuksien hallinta Case Dreamspark Premium

Attribuuttipohjainen käyttövaltuuksien hallinta Case Dreamspark Premium Attribuuttipohjainen käyttövaltuuksien hallinta Case Dreamspark Premium Jari Kotomäki Aalto University IT Käyttövaltuuksien hallinta eli auktorisointi Prosessi, jossa on kyse käyttäjän tunnistamisen (autentikoinnin,

Lisätiedot

Smart specialisation for regions and international collaboration Smart Pilots Seminar

Smart specialisation for regions and international collaboration Smart Pilots Seminar Smart specialisation for regions and international collaboration Smart Pilots Seminar 23.5.2017 Krista Taipale Head of Internaltional Affairs Helsinki-Uusimaa Regional Council Internationalisation

Lisätiedot

Internet of Things. Ideasta palveluksi IoT:n hyödyntäminen teollisuudessa. Palvelujen digitalisoinnista 4. teolliseen vallankumoukseen

Internet of Things. Ideasta palveluksi IoT:n hyödyntäminen teollisuudessa. Palvelujen digitalisoinnista 4. teolliseen vallankumoukseen Internet of Things Ideasta palveluksi 17.4.2015 IoT:n hyödyntäminen teollisuudessa Palvelujen digitalisoinnista 4. teolliseen vallankumoukseen We are where our clients are CGI in Finland and globally Close

Lisätiedot

Liikenteen hankeaihioita

Liikenteen hankeaihioita Hermia Oy Tamlink Oy Liikenteen hankeaihioita Hannu Hakala Artemis Call 2011 - työpaja Artemis haluaa the design, development and deployment of ubiquitous, interoperable and cost-effective, powerful, safe

Lisätiedot

Käyttöliittymät II. Käyttöliittymät I Kertaus peruskurssilta. Keskeisin kälikurssilla opittu asia?

Käyttöliittymät II. Käyttöliittymät I Kertaus peruskurssilta. Keskeisin kälikurssilla opittu asia? Käyttöliittymät II Sari A. Laakso Käyttöliittymät I Kertaus peruskurssilta Keskeisin kälikurssilla opittu asia? 1 Käyttöliittymät II Kurssin sisältö Käli I Käyttötilanteita Käli II Käyttötilanteet selvitetään

Lisätiedot