SOA:s fyra lärosatser

Ok, här kommer något om tjänsteorienterad arkitektur (SOA). Ett stickspår kanske, men intressant och .Net-relaterat i allra högsta grad.

Först några definitioner: SOA brukar definieras som en affärsdriven approach till systemarkitektur baserad på ett antal sammankopplade tjänster. En tjänst är en fristående och återanvändbar modul, som har ett väl definierat gränssnitt och som inte gör några antaganden om anropande applikation eller underliggande plattform. Tjänsteorienterad design har uppstått genom evolution från komponentorienterade och meddelandeorienterade system, och är ett komplement till objektorientering.

Don Box formulerade i för ett par år sedan SOA:s fyra lärosatser (eller hur ska man annars översätta "tenet"), vilka kan fungera som fundamentala design guidelines för all tjänsteorienterad systemutveckling. Jag tar dem på engelska:

1. Boundaries are explicit

Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.

2. Services are autonomous

Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will received malformed or malicious messages. Services should be built not to fail, using (for example) redundancy and failover techniques.

3. Services share schema and contract, not class

Services interact solely on their expression of structures using schema, and behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine the verification of incoming messages, which allows us to protect the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.

4. Service compatibility is determined based on policy

Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.

Ganska akademiskt, javisst, men kloka ord som definitivt är värda att begrunda. Och när man funderar närmare på dem så är det uppenbart sunt förnuft. Sats 1 och sats 3 handlar om att skapa robusthet och tillhandahålla abstraktion genom att göra ett kontrakt av specificerade meddelanden (jmfr COM interfaces och "chunky methods" – gamla principer i ny tappning). Sats 2 är fundamental för alla tjänster: en tjänst måste fungera autonomt, det vill säga oberoende av vem som anropar, och utan implicita antaganden om hur meddelandet ser ut. Det innebär till exempel att en tjänst ska validera inkommande meddelanden och verifiera klientens behörighet. Sats 4 handlar om att tjänster använder policys för att deklarera sina förmågor (capabilities) och anspråk (requirements) – målet är att nå kompabilitet på en semantisk nivå.

Läs mer:

• Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo -- MSDN Magazine, January 2004 (Don Box)
• Service Orientation and Its Role in Your Connected Systems Strategy (Mike Burner)

Technorati tags: soa, service orientation, architecture, design