ITONK1 Obligatorisk opgave 2 Badger Brewery Surveillance System

Ingeniørhøjskolen i Århus 2. juni 2006 IKT Dalgas Avenue 2 8000 Århus C ITONK1 Obligatorisk opgave 2 Badger Brewery Surveillance System Studerende: Henrik Brix Andersen, 01079 Tomas Stæhr Berg, 03539 Benjamin Hedegaard Sørensen, 02284 Underviser: Stefan Wagner

Badger Brewery Surveillance System i Indhold 1 Indledning 1 1.1 Formål............................................... 1 1.2 Dokumentets opbygning..................................... 1 2 Synopsis 2 2.1 Introduktion............................................ 2 2.2 Funktionalitet........................................... 2 2.3 Systemoversigt.......................................... 3 2.4 Use Cases............................................. 3 3 Design 6 3.1 Problemstillinger og Teknologivalg............................... 6 3.2 Deployment diagram....................................... 7 3.3 Delsystemer............................................ 8 4 Perspektivering 13 4.1 Teknologisammenligning..................................... 13 4.2 Styrker og svagheder....................................... 13 4.3 Konklusion............................................ 14 Litteratur 15

Badger Brewery Surveillance System 1 1 Indledning For at få et bedre kendskab til områderne indenfor objektorienteret netværkskommunikation skal der i kurset ITONK1 arbejdes med 2 obligatoriske opgaver. Disse 2 opgaver behandler brugen af web services og Java RMI. Dette dokument beskriver den anden af disse 2 opgaver. 1.1 Formål Formålet med denne opgave er at opnå praktisk erfaring med en række teknologier og begreber indenfor objektorienteret netværkskommunikation. Begreber: Åbenhed & heterogenitet Transparency Datapersistens Webservices Teknologier: Apache Tomcat m. AXIS Web service deployment Java web service klienter.net web service klienter Java RMI Ved at arbejde med disse emner i et konkret projekt, opnåes en praktisk forståelse af teknologiernes styrker og svagheder. 1.2 Dokumentets opbygning Dette dokument indeholder følgende kapitler: Indledning: Synopsis: Design: Perspektivering: Introduktion til opgaven. Systemoversigt og beskrivelse af kravmassen ud fra use case diagrammer. Problemstillinger ved et distribueret system samt beskrivelse af det endelige design ud fra UML-diagrammer. Diskussion af systemet som helhed, mulige udvidelser og forbedringer. Sammenligning af teknologier.

Badger Brewery Surveillance System 2 2 Synopsis Denne synopsis beskriver et distruberet overvågningssystem til bryggerier. Systemet hedder Badger Brewery Surveillance System og er udviklet af firmaet Badger A/S i Danmark. 2.1 Introduktion Den stigende efterspørgsel på kvalitetsøl kræver større og mere driftsikre bryggerier. En forudsætning for at kunne udvide er central og skalerbar overvågning af produktionen. Badger Brewery Surveillance System kan overvåge et ubegrænset antal gæringstanke og levere måledata til alle slags applikationer. 2.2 Funktionalitet Badger Brewery Surveillance System består af fire distribuerede enheder: Tank Server Modtagelse af målinger. Dynamisk opdatering af Tank Reading Stations. Målinger for de sidste 24 timer, summeret pr. time. Anvender en relationel database til persistens. Tank Reading Stations Aflæsning af temperatur og tryk for en gæringstank. Målingerne indrapporteres til Tank Server. Mulighed for at køre uden målere tilsluttet (simulering). Dynamisk opdatering af indstillinger fra serveren. Admin Client Giver administratorer mulighed for at tildele et navn, et alarm niveau og en fysisk adresse til hver målestation. Brugeradministration: Oprettelse, ændring og sletning af brugere samt tildeling af rettigheder (User/Admin). User Client Overblik over alle målestationer. Visning af sidste foretagede målinger. Opdateres hvert 30. sekund. Indikering af overskridelse af alarm værdier Graf over historiske data.

Badger Brewery Surveillance System 3 2.3 Systemoversigt Figur 2.1 viser systemet, som det kunne se ud i færdig distribueret form. Figur 2.1: Systemoversigt Målestationerne er placeret i bryggeriets produktion, og forbundet via Local Area Network til Tank serveren. Denne server eksponerer både en web service og et Java RMI-interface til indrapportering fra målestationerne. Målinger, målestation data og bruger data gemmes i en database. Administration af målestationer og aflæsning af målinger kan foregå lokalt på bryggeriet eller udefra via internettet. Funktionaliteten, der eksponeres over internettet, passerer igennem bryggeriets firewall. Denne funktionalitet er lavet som web service, da Java RMI ikke er praktisk ved anvendelse af firewall [Wagner 2005]. 2.4 Use Cases Dette afsnit indeholder en oversigt over hvilke use cases, der er tilknyttet enhederne i systemet. 2.4.1 Aktører Aktørerne i tabel 2.1 interagerer med enhederne i systemet. Aktør Type Tank Server Subsystem Tank Reading Station Subsystem User Client Subsystem Admin Client Subsystem User Fysisk person Administrator Fysisk person Thermometer Probe PICO TH03 Pressure Probe Virtuel trykmåler Database Relationel database Tabel 2.1: Aktører

Badger Brewery Surveillance System 4 2.4.2 Tank Server Use Cases Figur 2.2: Tank Server Use Cases På figur 2.2 ses use cases og aktører for Tank Serveren. Målestationer har mulighed for at tilkoble sig serveren og efterfølgende indrapportere målinger. User Client kan hente en liste over målestationer, aktuelle og historiske målinger. Admin Client har mulighed for opdatering (oprette/ændre) brugere og målestationer. Tank Serveren sender disse opdateringer til målestationerne. 2.4.3 Tank Reading Station Use Cases Figur 2.3: Tank Reading Station Use Cases

Badger Brewery Surveillance System 5 Målestationer kan tilkoble sig serveren og efterfølgende indsende målinger som vist på figur 2.3 på foregående side. Målestationer kan kun foretage temperatur- og trykmålinger. Stationerne kan modtage opdateringer fra Tank Server. 2.4.4 User Client Use Cases Figur 2.4: User Client Use Cases Brugeren har mulighed for at logge ind i systemet og efterfølgende se historiske og aktuelle målinger som vist på figur 2.4. 2.4.5 Admin Client Use Cases Figur 2.5: Admin Client Use Cases Administratoren har mulighed for at logge ind i systemet, og efterfølgende oprette, ændre og slette brugere og målestationer som vist på figur 2.5.

Badger Brewery Surveillance System 6 3 Design I dette afsnit beskrives hvilke designvalg vi har truffet. Afsnittet giver også et overblik over designet af de fire enheder: Tank Server, Tank Reading Station, User Client og Admin Client i form af klassediagrammer. 3.1 Problemstillinger og Teknologivalg 3.1.1 Klienter/Server Web service teknologien giver mulighed for at skrive klienter i flere sprog (heterogenitet). For at afprøve denne mulighed har vi valgt at implementere en række målestationer i forskellige sprog. Java RMI giver mulighed for tovejskommunikation mellem server og målestation. Servere: Apache Tomcat m. AXIS/SOAP (web service). Java konsolapplikation (RMI med callback). Målestationer: J2SE konsolapplikation (web service). J2SE grafisk applikation (generering af 24 timers test data, men kun simulering) (web service). J2SE grafisk applikation (generering af 24 timers test data) (RMI)..NET 2.0 grafisk applikation (web service)..net CF grafisk applikation (kun simulering) (web service). User Client: J2SE grafisk applikation (web service). Admin Client: J2SE grafisk applikation (web service). 3.1.2 Designvalg 3.1.2.1 Middleware Et af kravene til opgaven er, at der anvendes en kombination af web services og Java RMI som middleware. Vi har valgt at serveren stiller 3 web services og et RMI interface til rådighed. Hver web service/interface er en afgrænset del af serverfunktionaliteten, som er tilpasset hver enkelt aktør. Ved at bruge web service teknologien opnår vi åbenhed og heterogenitet i forhold til server og klienter. Web service teknologien løser også en del af problemerne med transparency. Klienterne anvender dog hardcoded IP-adresser, da vi ikke kan tilmelde serveren til skolen DNS-server. Systemet er med andre ord ikke Location Transparent [Wagner 2005]. Java RMI-interfacet duplikerer funktionaliteten af den ene web service og udvider denne med callbacks fra serveren til klienten. Denne tovejskommunikation mellem server og klient, anvender vi til dynamisk opdatering af klientens alarm-indstillinger.

Badger Brewery Surveillance System 7 3.1.2.2 Arkitektur Designet tager udgangspunkt i en lagdelt struktur som vist på figur 3.1. Øverste lag implementeres i Admin Client, User Client og Tank Reading Stations. Lagene under implementeres på Tank Serveren. Denne struktur giver en klar seperation af funktionalitet med veldefinerede grænseflader [Wagner 2005]. Dette tillader udskiftning af de enkelte lag, uden det har indflydelse på de omkringliggende lag. Figur 3.1: Lagdelt struktur Server side præsentationslaget er samlet i fire facader og stilles til rådighed som tre web services og et RMI interface. 3.1.2.3 Persistens Persistenslaget anvender JDBC som data access lag og Microsoft SQL Server som backend. Da databasen indeholder få tabeller, anser vi det for overkill at benytte et framework til mapningen mellem objekter og tabeller. 3.2 Deployment diagram Inden gennemgangen af klassediagrammerne for de enkelte subsystemer vil vi se på deployment samt hvilke pakker, der udgør subsystemerne. Figur 3.2: Deployment diagram

Badger Brewery Surveillance System 8 På figur 3.2 på foregående side genkendes de fire enheder og den lagdelte struktur. Serverpakkerne i web service klienterne er server-stubbe, som er autogenereret med WSDL2Java-værktøjet. Stubbene er genereret ud fra facadeklasserne i præsentationslaget på serveren. Java RMI anvender stubbe genereret på runtime. 3.3 Delsystemer Dette afsnit indeholder en beskrivelse samt klassediagrammer for de enkelte dele i systemet. 3.3.1 Tank Server Figur 3.3: Tank Server klassediagram På figur 3.3 ses lagdelingen af serveren. Øverst Server side presentation laget i form af fire facader, som anvender server-side business-laget. På det midterste lag har vi kontrolklasser for målinger, brugeradministration og målestationer.

Badger Brewery Surveillance System 9 Det nederste lag sørger for persistens af domæneklasserne. Alle lagene benytter sig af domæne modellen, som bliver eksponeret igennem de tre web services. Til RMI-klienten distribueres domænemodellen manuelt. 3.3.2 Tank Reading Station Figur 3.4: Tank Reading Station klassediagram Alle web service-baserede målestationer er bygget op efter klassediagrammet på figur 3.4. TankStation- Server pakken er klientstubben genereret med WSDL2Java-værktøjet. Figur 3.5: Tank Reading Station RMI klassediagram

Badger Brewery Surveillance System 10 Java RMI målestationen er bygget op efter klassediagrammet på figur 3.5 på forrige side. Klienten benytter serveren igennem TankStationFacadeJRMI-interfacet. Serveren laver callback til klienten igennem Update-interfacet. 3.3.3 Admin Client Figur 3.6: Admin Client klassediagram Grundstrukturen i Admin Client er MVC-patternet, hvor kontrolklassen i form af event handlers, er lagt ind i viewet. Modelklassen stiller data fra web servicen til rådighed overfor viewet som vist på figur 3.6. Viewet er således helt afkoblet fra web servicen. AdminClientServer pakken er klientstubben genereret med WSDL2Java-værktøjet.

Badger Brewery Surveillance System 11 3.3.4 User Client Figur 3.7: User Client klassediagram Ligesom i Admin Client er grundstrukturen i User Client MVC-patternet, som vist på figur 3.7. Kontrolklassen indeholder en tråd, der sørger for at opdatere modellen hvert 30. sekund. UserClientServer pakken er klientstubben genereret med WSDL2Java-værktøjet. 3.3.5 Datamodel Dette afsnit beskriver datamodellen. Vi har identificeret følgende objekter i det fysiske domæne: Administrator Bruger Temperaturmåling Trykmåling Målestation På figur 3.8 på næste side ses modelleringen af objekterne. Klasserne bruges alle som value-klasser og er samlet i en DomainModel-pakke.

Badger Brewery Surveillance System 12 Figur 3.8: Domæne model klassediagram Databasen skal kunne persistere objekterne, og vi har fastlagt et databasedesign som vist på figur 3.9. Figur 3.9: Database E/R diagram Klasserne Pressure og Temperature arver begge fra den abtrakte klasse Measurement. I databasen implementeres dette i to tabeller; Temperature og Pressure. User- og Administrator-klasserne arver fra Account-klassen. Dette er implementeret i én tabel. En bit adskiller de to typer. Operationer på databasen afvikles via stored procedures, og har således minimal afhængighed mellem databasedesignet og persistenslaget.

Badger Brewery Surveillance System 13 4 Perspektivering I dette afsnit sammenligner vi de to middlewares, web service og JRMI, med afsæt i det gennemførte projekt. Til sidst ser vi på produktets styrker og svagheder. 4.1 Teknologisammenligning Java RMI Web service Kommunikation Mulighed for Callbacks og dermed tovejskommunikation. Request-Response og dermed envejskommunikation. Heterogenitet Javaspecifikt, men kan dog bruges Sproguafhængigt. fra andre sprog via RMI-IIOP. IDL Bruger Java-interfaces som IDL. Bruger sprogneutralt IDL (WSDL) baseret på XML. Access transparency Autogenerering af stubbe/skeletter på runtime. Generering af stubbe ud fra WSDL før compiletime. Objektreferencer Mulighed for referencer til distribuerede objekter på server (By reference). Objekter serialiseres (By value). Tabel 4.1: Teknologisammenligning 4.2 Styrker og svagheder 4.2.1 Styrke: Distribueret Hvis systemet ikke var distribueret, skulle brygmesteren aflæse temperatur og tryk ved hver enkelt målestation. Nu samles målingerne centralt, og kan tilgåes såvel onsite som remote via internettet. 4.2.2 Styrke: Spontaneous Networking Systemet er opbygget så målestationerne kan melde sig til serveren hver gang de starter op. Første gang en målestation tilmelder sig, får den udleveret et ID, som gemmes lokalt. Efterfølgende kan målestationen identificeres ud fra dette ID. På denne måde kan nye målestationer selv tilmelde sig systemet, og administratoren kan på et passende tidspunkt konfigurere de nye enheder. Målestationer kan afmelde sig fra serveren. Hvis en målestation går ned, afmelder serveren dog automatisk stationen. Dette gør produktet mere robust. 4.2.3 Styrke: Firewall-friendly Admin Client og User Client kan bruges remote over internettet uden problemer med firewalls. Havde vi valgt Java RMI til disse klienter, ville det kræve speciel konfiguration af firewallen.

Badger Brewery Surveillance System 14 4.2.4 Svaghed: Location Transparency Systemet er ikke location transparent. For at opnå location transparency kunne der benyttes DNS eller en anden form for centralt styret navngivning. Derved kunne serveren have et symbolsk navn, og placeres et vilkårligt sted på netværket. I Java RMI anvendes Registry som naming service. Klienterne skal dog stadig kende maskinen, hvor Registry-servicen kører for at få fat i server objekterne. 4.3 Konklusion Vi har udviklet en proof-of-concept distribueret løsning bestående af en server og tre typer klienter. Vi har med succes anvendt web service og Java RMI i praktis og vi er godt tilfredse med produktet.

Badger Brewery Surveillance System 15 Litteratur [Wagner 2005] [Purdue 2006] Wagner, Stefan: Engineering Distributed Objects principles and applications, Vol. 1 & 2. 2005 Purdue University Online Writing Lab (OWL): Using Modern Language Association (MLA) Format. 2006. http://owl.english.purdue.edu/handouts/ research/r_mla.html

Badger Brewery Surveillance System 16 Figur 1: Screenshot