Jeff Schneider linked to and commented on Judith Hurwitz’s ten principles of SOA, which somehow made me write down the first 10 SOA statements that came to my mind. Thanks to Hartmut and Marcel for early feedback … let me know what you think.
1. An SOA is primarily aimed at being an architecture for enterprise-wide usage. It is usable within a single application that is being decomposed using a services approach, but doing this makes the most sense when the ultimate goal is to arrive at a service landscape. For structuring applications internally, other technologies may be more appropriate.
2. A key concept within an SOA is loose coupling. Loose coupling has multiple dimensions, such as location, time, binding and address lookup, versioning, protocols and capabilities. It will not always be achievable, nor even desirable, to have loose coupling in all dimensions.
3. A service, as the primary concept within an SOA, encapsulates a business function that is accessed by means of messages, or documents, that are sent to it to request some function, which may possibly return a result message/document. With regards to their functionality, services are defined solely based on the type of documents they accept and emit. The number and type of documents a service can process define its “interface”, which some people prefer to call its “contract”.
4. The non-functional characteristics of a service are defined by means of a policy. Examples of aspects defined by policy are which security mechanism to apply, what transport or transfer protocol to use, and whether to perform reliable message delivery or not.
5. If you use Web services, you’re not necessarily doing SOA. Especially when you follow the examples and use the tools of the first generation, you can use Web services to build some of the worst RPC-style distributed computing systems ever.
6. You can do SOA without using Web services, but in general, that’s a bad idea. There are many benefits you can gain from Web services over distributed object technologies such as CORBA or DCOM, or messaging systems such as MQ or JMS, most notably with regards to loose coupling, interoperability, standards support and vendor independence.
7. A service, by definition, has a contract with its consumers, not with a runtime environment. This is one of the main aspects distiniguishing a service from a component (document-based interfaces being a close second).
8. In an advanced SOA, metadata plays a critical role in managing, administering, evaluating, optimizing, and evolving the services and their relationships. Whether metadata is created and maintained centrally and pushed towards the service endpoints, collected and cached in a central location, or maintained in a decentralized fashion, is a matter of choice.
9. Services can be combined and composed to build new services, or orchestrated to fully support a complete business process. Whether this is done using some programming language, or some engine with an associated declarative process specification language, is largely irrelevant.
10. Within an SOA, the focus is on the services, their contracts and policies, the standards being used, communication patterns and conventions, etc., not on any particular product. If an SOA effort relies on some vendor’s specific product instead of generally available standards, it misses one of the key points. You can’t buy an SOA.
Wrt to point 9:
The notion of defining a Business Process over a set of services in an SOA is an attractive way of utilising the services to achieve a measurable objective. But the way it is realised is of importance. One could realise a BP in an application server that is controlling the services (orchestration) or one could realise it as a script in which each service performs exactly what is required of it relative to the description of the BP. The former is server centric and so has an impact on the robustness of the system and the coupling of the BP to the services. The latter is higher up the stack and can be used to derive the former but can also be used to inform the services of their expected behavior and so yield a more distributed solution - more robust and looser coupling.