Process Broker A joint project between DSV and Viewlocity/Visuera,

En presentation över ämnet: "Process Broker A joint project between DSV and Viewlocity/Visuera,"— Presentationens avskrift:

1 Process Broker A joint project between DSV and Viewlocity/Visuera,
sponsored by Nutek Broker Application A Application B Application C Application D Hej, jag heter Erik Perjons, och jag jobbar vid data- och systemvetenskapliga institutionen, som är en gemensam institution för Stockholms universitet och KTH. Jag ska presentera ett projekt som vi kallar Process Broker, som är ett gemensamt projekt mellan KTH och företaget Viewlocity. Viewlocity utvecklar och säljer olika lösningar för integration av applikationer. När vi startade det här projektet hette Viewlocity Frontec AMT, och var den del av Frontec som sysslade med utveckling av produkter för integration. Under projektets gång kom Frontec AMT att byta namn till Viewlocity, få amerikanska investerare och flytta sitt huvudkontor till Atlanta i USA. Själva utvecklingen kom dock att ligga kvar i Sverige. Om den senaste utvecklingen för Viewlocity kommer Janne Törnebohm att berätta något senare.

2 Architectures of Application Integration
Application B Application A Application E Application D Application F Application C Application A Application B Application C Application D Point to point Det finns olika lösningar, arkitekturer, för att skapa den här integrationen mellan applikationer. En sådan lösning, eller arkitektur, är punkt-till-punkt-lösningen, som innebär att varje applikation ska integreras med varje annan applikation som den ska kommunicera med. Problemet med den här lösningen är att ju fler applikationer som integreras, desto svårare blir det att hålla ordning på och underhålla alla gränssnitt som finns.

3 Architectures of Application Integration
Message Broker Application A Application B Application C Application D Many to many - Message Brokers Point to point Intelligent routing Message Translation Rules Processing Repository Services Message Warehousing Adapters En annan lösning är då att introducera en central message broker, en meddelandemäklare, som applikationerna kommunicerar med. Message brokern tar emot ett meddelande från en applikation, analyserar det och skickar det vidare till rätt applikationer. Vidare så sköter message brokern konvertering av olika meddelande- och dataformat så att olika typer av applikationer, som körs på olika plattformar, kan kommunicera med varandra. En vidareutveckling av message brokern är process brokern, på svenska: processmäklare eller, som det ibland kallas, processhanteringssystem. I en process brokern samlas all interaktionslogik mellan applikationer, dvs i vilken ordning som applikationerna kommunicerar med varandra. Process Brokern gör det också möjligt att föra ned allt mer av applikationslogiken i process brokern, om man vill. Viktig är också att den här logiken representeras/beskrivs grafiskt med hjälp av ett processmodeller. På så sätt kan man få en överblick över processerna och därmed kan de lättare förändras. En grundtanke med process broken är att man både ska modellera interaktionen, dvs processerna, och exekvera dem. Det ska också gå att simulera processer i process brokern för att pröva olika processmodelleringsalternativ. Det är sådana här process brokers som det här projektet syftar till att undersöka, särskilt då beskrivningstekniker, dvs processmodelleringsspråk, och metoder för att modellera processerna.

4 Architectures of Application Integration
Message Broker Application A Application B Application C Application D Many to many - Message Brokers Point to point Application A Application B Application C Process Broker Person A Many to many - Process Brokers En annan lösning är då att introducera en central message broker, en meddelandemäklare, som applikationerna kommunicerar med. Message brokern tar emot ett meddelande från en applikation, analyserar det och skickar det vidare till rätt applikationer. Vidare så sköter message brokern konvertering av olika meddelande- och dataformat så att olika typer av applikationer, som körs på olika plattformar, kan kommunicera med varandra. En vidareutveckling av message brokern är process brokern, på svenska: processmäklare eller, som det ibland kallas, processhanteringssystem. I en process brokern samlas all interaktionslogik mellan applikationer, dvs i vilken ordning som applikationerna kommunicerar med varandra. Process Brokern gör det också möjligt att föra ned allt mer av applikationslogiken i process brokern, om man vill. Viktig är också att den här logiken representeras/beskrivs grafiskt med hjälp av ett processmodeller. På så sätt kan man få en överblick över processerna och därmed kan de lättare förändras. En grundtanke med process broken är att man både ska modellera interaktionen, dvs processerna, och exekvera dem. Det ska också gå att simulera processer i process brokern för att pröva olika processmodelleringsalternativ. Det är sådana här process brokers som det här projektet syftar till att undersöka, särskilt då beskrivningstekniker, dvs processmodelleringsspråk, och metoder för att modellera processerna.

5 Description techiques (BML)
För att göra det hela mer konkret ska jag visa ett något förenklat exempel. En kund beställer en vara eller tjänst hos ett företag och beställningen ska uppdateras i en applikation, App A. Om något går fel i den här kommunikationen ska en operatör notifieras. Vi tänker oss nu att denna kommunikationen modelleras upp med hjälp av ett processmodelleringsspråk, i det här fallet BML, som en gång i tiden utvecklats vid Frontec AMT och som vidareutvecklats inom ramen för det här projektet. Janne Törnbohm kommer senare att beskriva BML mer i detalj. Kunden sänder beställningen in till process brokern och hela meddelandet eller delar av det skickas vidare till App A. Process brokern har då också strukturerat och konverterat om meddelandet om så behövs. Sedan sätts en timer igång. App A skickar tillbaka ett svar och process brokern sänder information till kunden om att ordern har mottagits och är under behandling. Om inte App A svarat före en viss tid kommer dock timern att gå ut och processinstansen att välja den undre vägen i processmodellen. Kunden kanske får information om att systemet inte var tillgängligt för tillfället och att han eller hon måste återkomma senare. En operatör notifieras också om att App A inte svarat. Fördelen med sådana här processmodeller är att man först kan låta verksamhetsansvariga vara med och bestämma hur affärslogiken ska se hur, dvs hur applikationerna ska kommunicera med kunderna. Sedan kan modellerna byggas på, meddelandena specificeras osv av designers, innan processerna är färdiga att exekveras. Det är också möjligt att grafiskt övervaka instanser av processerna och se hur lång ett viss specifik order behandlats, precis som i ett workflowhanteringssystem.

6 Description techiques (BML)

7 Description techiques (BML)

8 Course at KTH/Stockholm University in Application and Process Integration Using SPM Modelling Business Process vs. IS/eBusiness Processes More about methodology för Application Integration Using speech act theory and RosettaNet Validation techniques for process diagrams Course at KTH/Stockholm University in Application and Process Integration Using SPM Modelling Business Process vs. IS/eBusiness Processes More about methodology för Application Integration Using speech act theory and RosettaNet Validation techniques for process diagrams Telecom system I det här projektet har genomförts två fallstudier. Den här figuren visar en model över ett system, i vilket en europeisk mobiltelekom-operatör velat integrera ett 15-tal av sina applikationer med hjälp av en process broker. Modellen består av ett 30-tal processer som alla beskriver olika tjänster eller delar av tjänster som kunden ska kunna erbjudas. Som vi ser blir modellerna komplexa i ett sådant här stort system. Vi har därför i det här projeketet utvecklat metoder för att hantera den här komplexiteten. Hur ska man göra när man modellerar så att det sker på ett strukturerat sätt. Vi har också skapat metoder som gör det möjligt för olika intressenter att kunna se olika vyer av modellerna. Verksamhetsansvariga kanske bara vill se den grundläggande affärslogiken, medan de tekniska ansvariga även måste se hur undantag och fel ska hanteras i systemet. Vad vi gjort är att vi utvecklat metoder som gör det möjligt för designers att börja med att skapa relativt enkla modeller som beskriver den centrala kommunikationen med kund. Dessa modeller kan sedan på ett strukturerat sätt byggas på med allt mer detaljer och med allt mer komplexitet. Vi har också utvecklat metoder för att verifiera och validera modellerna, så att inte symboler glöms bort eller att modellerna blir formellt felaktiga. Vidare så har vi utvecklat processmönster för e-handel. På så sätt kan designern snabbare skapa e-handelsmodeller och erbjudas alternativa lösningar under designprocessen.

9 Telecom system

10 Common Models for Different Stakeholders
Analysis Design Operations Den här bilden visar tanken att samma modeller, eller samma processmodelleringsspråk, kan användas av olika intressenter, till exempel verksamhetsansvariga, tekniska designers och operatörer. Därmed underlättas kommunikation mellan dem och verksamhetsansvariga kan lättare övervaka att det verkligen skapas system som stödjer den affärslogik som man vill ha.

11 Process Broker Message Broker Broker Services Process Design
Process Visualisation Process Simulation Process Execution Process Monitoring Process Broker Intelligent routing Message Translation Rules Processing Repository Services Message Warehousing Adapters Den här bilden visar några av de viktigaste funktionerna hos message brokern och process broken. De ska också illustrera att process broken ligger på en högre abstraktionsnivå än message broken. Process broken visualiserar och abstraherar komplexiteten. Därigenom får användaren en bättre överblick över hur systemet fungerar. Message Broker

12 Results and Further research
Academic results: - Description techniques (BML, UML, EPC) - Methods for application and process integration - A number of published scientific papers - Finished and ongoing Lic´s and ongoing Ph D´s - Further co-oparation with other universities and companies Avslutningsvis. Vi har studerat BML, kommit med förslag på förbättringar. Vi har jämfört BML med andra processmodelleringspåk och börjat skissa på metoder för att kunna översätta mellan dem. Vi har utvecklat metoder för att modellera processer på ett strukturerat sätt och metoder för att verifiera/validera modellerna. Det har publicerats 5 artiklar till internationella konferenser eller tidskrifter. Det har submittats 3 artiklar och ytterligare 2 skrivs det på för tillfället. En tutorial har producerats vid en konferens. Vid DSV har en ny kurs startats som handlar om applikationsintegration. Andra kurser har förändrats som resultat av projektet. Vi har tre licentiatavhandlingar på gång, som alla planeras bli klara till någon gång efter nyår. I samband med projketet har också inletts samarbete med andra högskolor, Skövde, Mitthögskolan och Mälardalens och andra institutioner vid KTH, som NADA, som förhoppningsvis leder till framtida gemensamma projket. Även samarbete med företag, som webbgirot. Further research: - Knowledge management for processes (process library) - Exception handling - Storing and distribution of processes

13 Payment system

14 Payment system