- From: He, Hao <Hao.He@thomson.com.au>
- Date: Wed, 13 Aug 2003 08:46:42 +1000
- To: "Www-Ws-Arch@W3. Org" <www-ws-arch@w3.org>
- Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB046AE6F5@sydthqems01.int.tisa.com.au>
As discussed in the f2f, the current text on SOA is unclear. I have taken the action item to write more on SOA. Hao Service oriented architecture An SOA is a style of software architecture, which centralises on the concept of service. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. The end results are usually the change of state for the consumer but can also be the change of state for the provider or for both. A service is considered "safe" if it does not cause any change of state to its provider. A service is defined by a contract between a provider and a consumer. A contract typically prescribes the means of service consumption and expected end results from a consumer's prospect. Additionally, quality of service may also be specified. The main purpose of SOA is to achieve loose coupling among software agents through the following constraints: 1. Simple and ubiquitous interfaces to all participating software agents. Zero or minimum application semantics is encoded at the interfaces. The interfaces should be universally available for all providers and consumers. 2. Descriptive messages constrained by an extensible schema. Zero or minimum system behaviours are prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services being introduced without breaking existing services. An SOA, 1. MUST provide a mechanism that enables the communication between a provider and a consumer under the context of a service sought by the consumer. 2. MUST define service contracts between providers and consumers. Optional constraints: 1. Stateless messaging. Each message that a consumer sends to a provider must contain all information necessary for the provider to process the message. This constraint makes a service provider more scalable because it does not store state information about consumers. 2. Stateful messaging. Both the consumer and the provider share the same consumer specific context, which is either included or referenced by messages exchanged between the provider and the consumer. This constraint makes the communication between a provider and a consumer more efficient but reduces the overall scalability of the service provider because it must remember the shared context for each consumer. It increases the coupling between a service provider and a consumer and makes switching service providers more difficult. 3. Idempotent messaging. Duplicated messages received by a software agent cause exactly the same effects as a single unique message does. This constraint allows providers and consumers to improve the overall service reliability by simply repeating messaging if faults are encountered.
Attachments
- text/plain attachment: InterScan_Disclaimer.txt
Received on Tuesday, 12 August 2003 18:44:48 UTC