Det är rätt lätt att förstå hur man skall bygga en tjänst, både dess kontrakt, med hjälp av Xsd, och dess insida, alltså implementeringen av denna. Men det blir direkt mycket svårare när man har fler tjänster som skall samverka inom en organisation. Frågor som bland annat brukar infinna sig är:
- Hur stor skall tjänsten vara. Hur mycket skall den innehålla och ha ansvaret för?
- Finns det olika typer av tjänster och hur hänger de i sådana fall ihop?
- Hur återanvänder man tjänster?
- Osv..
Sammanfattningsvis kan man säga att det är först nu som den svåra biten kommer när det gäller att implementera SOA i en organisation. Vissa skulle till och med säga att det först är när vi gör detta som vi verkligen har en tjänstebaserad arkitektur.
Boken Enterprise SOA – Service-Oriented Architecture Best Practices har ett mycket intressant förslag på hur man delar upp tjänster i olika tjänstetyper, där de olika typerna har olika karaktäristiska. Dessa typer är en bra hjälp när man börjar skissa upp en tjänstebaserad arkitektur i en organisation.
Först vill jag kortfattat beskriva detta förslag som en matris och sedan diskutera en implementation utifrån detta. Köp gärna boken om ni vill ha en djupare presentation av matrisen.
Tjänstetyperna
(Klicka på bilden för att se en större variant.)
Det finns fyra typer av tjänster. Dessa är:
- Basic Service
- Intermediary Service
- Process-Centric Service
- Public Enterprise Service
Basic Service är den grundläggande typen av tjänst. Det är faktiskt den enda typen av tjänster som måste finnas i SOA för att vara en sådan arkitektur. Dessa tjänster är de grundläggande byggstenarna i arkitekturen. De är de lättaste att återanvända. De brukar ofta vara ett verksamhetsobjekt såsom Order, Produkt eller något liknande.
Intermediary Service är en tjänstetyp som på ett eller annat sätt förmedlar information eller funktionalitet. Det kan vara gateways mellan olika implementeringstekniker, adapters emot äldre system som organisationen redan har. Facade är en servicetyp som som aggregerar underliggande tjänster med ett gemensamt gränssnitt. (Det finns en annan arkitekturbild av SOA som Microsoft ofta förmdelar, där det finns tre nivåer, Process service -> Activity service -> Entity service. Vår facadetyp är ungefär samma sak som en activity service i det diagrammet.)
Process-Centric Service är den mest avancerade tjänstetypen. Den typen har ansvar för processer och just därför är denna typ den enda tjänsten som kan hålla state. Detta för att bland annat klara av "longrunning transactions".
Public Enterprise Service är en tjänstetyp som exponerer tjänster till andra utanför organisationen.
Exemplet
Det här exemplet utgår ifrån en påhittad Internetbokhandel med namnet Lexia. De har flera distributörer av sina produkter, i dagsläget tre, och de använder sig också av ett externt fraktbolag för att leverera produkter till kunderna. Lexia har tre gränssnitt emot kunder, anställda och partners: En webbapplikation som är själva internetbokhandeln, en windowsapplikation som används av anställda och en webbtjänst som partners använder sig av för att kommunicierar med företaget. Lexia har också ett gammalt CRM-system som skall integreras i den nya lösningen.
(Klicka på bilden för en större variant)
Innan jag beskriver de olika tjänstetyperna vill jag uppmärksamma er på att jag har lagt till två lager till: Legacy Layer och External Layer. Jag tycker också att det är bra att se sådana beroenden i diagrammet.
Basic Services
Lexias Basic Services är CustomerService, ShoppingCart, OrderService och ProductService. Alla dessa tre är datacentrerade tjänster. Deras största ansvar är att lagra informationen.
Intermediary Services
CustomerMergerService är en Functional-Adding Service emot det gamla CRM-Systemet. Den har till uppgift att dels vara en gränsnitt mellan det gamla systemet och företagets nya arkitektur. En annan viktigt uppgift som den också har är att den utökar funktionaliteten hos CRM-Systemet. Det är nämligen så att viss funktionalitet och information som behövs för att hantera kunderna i webbapplikationen saknas i det gamla systemet. Av det skälet har en ny CustomerService skapats och CustomerMergerService kopplar ihop dessa båda med ett gemensamt gränssnitt. I framtiden kommer det gamla CRM-systemet avvecklas och ersättas fullt ut av CustomerService.
De tre tjänsterna BiblioAdapterService, BrontusAdapterService och CDtoGOAdapterService interna representationer för de externa tjänsterna som dessa tre distributörer har. Det är dessa tjänster som har till ansvar att synkronisera och hantera produktkatalogerna ifrån respektive distributör. Dessa tjänster tar också hand om beställningar emot distributörerna. Man skulle kunna bygga in dem i ProductService, men för att göra det enklare att föra in nya distributörer så byggs de upp som egna tjänster istället.
OrderHandlingService är en Facade Service som sammanfogar de Basic Services som behövs för att hantera en order. Till exempel finns den en metod i den här tjänsten som heter MakeOrder. Den anropar ett flertal andra tjänster CreditCardService, ShoppingCartService, OrderService och ProductService för att kunna utföra den aktiviteten.
Process-Centric Services
Lexia har en processervice för att hantera ordrar. Den här tjänsten håller state genom att ha en databas där all information om en order sparas. (Den här servicen kan också implementeras som en BizTalk-process.)
Public Enterprise Services
LexiaExternalService ger partner möjlighet att kommunicera med Lexia på det här sättet. Exempelvis så är det via den här tjänsten som som distributörer meddelar att det finns nya produktkataloger att hämta.
Sammanfattning
Detta är en mycket kortfattad beskrivning av den här arkitekturen. Jag kommer i framtida inlägg diskutera problem och lösningar som inträffar när man skall implementera denna. Det finns nämligen mycket att diskutera och fundera över.
Ett tiotal av mina kollegor på Know IT skall åka bort ett par dagar i slutet av maj för att implementera hela den här arkitekturen. Vi kommer att implementera den i olika versioner av Visual Studio, vissa delar i Java, och vissa delar i Mono. Det skall bli mycket spännande. Jag hoppas kunna återkomma med nya erfarenhter utifrån det projektet.
Vi gjorde en liknande workshop förra året, där vi också lärde oss mycket, speciellt om att jobba med "Contract First". Jag har skrivit om det i tidigare inlägg. Kolla under kategorin Rumba.
Comments