Jag håller på att sammanställa en exempelapplikation för en konferens som vi skall ha på jobbet. Jag har försökt att göra ett enkelt exempel, men som ändå får med de vanligaste arkitekturproblemen som man måste tampas med när man bygger en SOA-lösning.
Jag har tänkt mig använda det här exemplet också på min blog för att kunna diskutera olika delar inom SOA. Därför vill jag börja med att beskriva applikationen och lägga grunden för många intressanta diskussioner.
PS. Är ni intresserade av att jag kommer och håller en konferens med "Hands-On"
så här gärna av er. Förlåt säljsnacket ;-)
Översikt
Exempelapplikationens namn är Rumba. Det är ett system för att hantera evenemang. Den del som just den här applikationen gör är följande:
- Lista vilka evenemang som är möjliga att anmäla sig till.
- Anmäla / avanmäla till ett evenemang.
- Administratörer skall kunna se vilka som är anmälda till ett evenemang och
även kunna ta bort och lägga till personer till ett evenemang.
Förutsättningar
- Man behöver inte vara "inloggad" för att se vilka evenemang som finns att
anmäla sig till. - Endast de som redan finns registrerade som användare skall kunna anmäla
sig till ett evenemang. (Detta görs i något annat system.) - En användare kan ha två olika roller, OrdinaryUser eller AdminUser.
Den tekniska arkitekturen
EventReg
Detta är en publik Web service.
EventRegMachine
Själva motorn i systemet. I den första versionen så sparas alla evenemang som xml-filer, en fil för varje evenemang och en generell fil, vilket håller ihop alla andra filer.
Authentication
En Web service som exponerar användarinformationen som ligger lagrat i ett Active Directory.
Audit
Alla händelser måste loggas för att man skall kunna spåra alla saker som händer. Händelserna sparas i en SQL Server. Eftersom denna uppdatering inte behöver ske synkront, så kommer en meddelandekö att användas som kommunikationskanal emot den här tjänsten.
Comments