Today’s applications are required to continuously adapt and adjust, to be able to meet a constant change in demand. As result of an increasing amount of data, choosing the right communication method becomes a vital step. A solution that have been functional for a long time, may at any point in time be unable to reach the level it requires and instead turns into bottlenecks and inefficient solutions.Using a database as a communication method between system entities, does not have to be a bad solution. A database has it perks with being a simple solution and efficient query operations. However, using it as a queue management system, requires entities to continuously poll new table entries. This solution may not be the most suitable nor best available option. There exists communication system developed for the specific purpose of efficiently distributing messages to available parties.Implementing a message-oriented middleware enables for asynchronous communication which promotes applications to be more loosely coupled. As a result, available resources could be better utilised and improve the system performance. This degree project investigates the development and integration of two message-oriented middlewares, RabbitMQ and AcviteMQ, within an e-commerce system. The purpose is to explore the potentials of changing queue management system from a database to a message broker. The expected outcome is a more flexible job handling and, perhaps, an improvement of job processing by using a more efficient distribution.The results show that changing queue management system from the database to a message-oriented middleware could improve the performance of handling of invoice jobs. Testing the application servers of the Proceedo system, with a batch of invoice jobs, showed a potential of up to 17 percent faster process time using a message broker. This corresponds to a reduced process time of around 11 minutes for one application server and 6 minutes using two. Additionally, both brokers provide flexible message handling through functionality to priorities messages. / Dagens applikationer måste kontinuerligt anpassa och justera sig för att kunna möta en ständig förändring i efterfrågan. Resultat som blir av den ökande mängd data som behöver kunna hanteras, är kravet på att välja rätt kommunikationsmetod. En lösning som varit funktionell under lång tid, kan när som helst bli oförmögen att nå den nivå som krävs. Istället förvandlas den till en flaskhals och på så sätt bli en ineffektiv lösning.Att använda en databas som en kommunikationsmetod mellan systemenheter behöver inte vara en dålig lösning. En databas har förmåner som att att vara en enkel lösning och effektivt kunna hantera förfrågningar. När det appliceras som ett köhanteringssystem, krävs det att alla enheter kontinuerligt skickar nya förfrågningar för att hämta nya tabelluppdateringar. Denna lösning kanske inte är det mest lämpliga eller bästa tillgängliga alternativet. Det finns kommunikationssystem utvecklade för det här specifika syftet, att effektivt distribuera meddelanden till tillgängliga parter.Införandet av ett meddelandeorienterad middlewares gör det möjligt för asynkron kommunikation som främjar applikationer till att kunna vara mer löst kopplade. Som ett resultat kan tillgängliga resurser utnyttjas bättre och förbättra systemets prestanda. Detta examensprojekt undersöker utvecklingen och integrationen av två meddelandeorienterade middlewares, RabbitMQ och AcviteMQ, inom ett e-handelssystem. Syftet är att undersöka de positiva möjligheterna som finns av att by-ta köhanteringssystem från en databas till en meddelandeorienterad middleware. Det förväntade resultatet är en mer flexibel jobbhantering och kanske en förbättring av jobbearbetningen, genom att använda en effektivare meddelande distribution.Resultaten visar att bytet av köhanteringssystem, från databasen till en meddelandeorienterad middleware, kan förbättra hanteringen av fakturahandlingar. Testningen av Proceedo-systemets applikationsservrar visade potential på upp till 17 procent snabbare processtid med hjälp av en meddelande broker. Det motsvarar en hanteringstid på 11 minuter snabbare vid användande av en applikationserver och 6 minuter vid använding av två. Dessutom ger båda middlewares en mer flexibel meddelandehantering, i form av, funktionalitet att kunna prioritera meddelanden