Discoverable
For services to be of use to anyone they must be discoverable. Discoverability is usually taken to refer to the ability of consumers to find a relevant service by attributes (tags) at runtime via a service registry. In other words, consumers go to a service "yellow pages" and find, at runtime, services that best meet their needs.

In my humble opinion, this sort of runtime discoverability has not yet taken off despite all the hype. Service contracts are complex beasts that include non-trivial functional interfaces and runtime policies such as security and operational service-level agreements. Then there are the capacity management and funding considerations involved in service adoption. Such runtime discoverability is more suited to a market place were variation and competition thrive, than to internal corporate landscapes where reuse and lower total cost of ownership is a key driver.

However, services very much need to be discoverable in the sense that they are well publicized to the consumer community. Services will not be reused if they are not known about. Service registries must contain everything the consumer will want to know about the service, e.g., name, description, functional interface, locations, owner, operational and performance criteria, security model, invocation mechanism, cost, etc. but must equally importantly include tags that will make searches possible.

Having such a service registry is not enough though. Governance is required to ensure that development communities using the registry; governance not just in the stick sense, i.e., thou shalt use the registry or else, but also in the carrot sense - here's why it benefits you and here's how easy it is to do. It is important to capture the hearts and minds of both development and business communities. Reuse is like recycling: fine in principle, with everyone keen to do it, until it becomes inconvenient.

Stateless
A service is said to be stateless if the consumer of that service can make use of any operating instance of that service. This is achieved by services not storing any internal data (state) that would be required if the consumer happened to invoke another instance of that service.

In general this goal is achieved by ensuring that all service data (including state) is kept in an external store common to all instances of that service.

However, for performance reasons, service implementers are often inclined to cache back-end system query results or consumer session data. The reason for this is that the back-end systems and data stores that are accessed by services often become points of contention and a source of bottlenecks, so avoiding the need to query those systems through caching at the service tier is attractive.

Service-tier caching requires that cached data is available at all service instances, and that these instances are kept in sync both with each other and the underlying data store. Achieving this requires fairly sophisticated cache management software with cache refresh, propagation and invalidation mechanisms, as well as volatility analysis of the data being cached - the less volatile data is, the more suitable it will be for caching.

JEE applications servers such as WebLogic and JBoss offer HTTP and stateful EJB session state caching that can be replicated across a cluster and persisted to a variety of data stores for failover purposes. In addition, consumer connections to servers can be made "sticky" so that a given consumer will always return to the same server and only be redirected to another server in a failover scenario. This is fine as long as either the state is replicated or the consumer is happy to lose some conversational state in the rare instance that a server becomes unavailable. It is also possible to store consumer state on the client, either via client cookies or via URL rewriting. WebLogic, for example, can be configured to use either depending on whether client browser cookies are enabled or not. Note that session state replication limits the linear horizontal scaleability of clusters.

A viable and arguable simpler alternative to all of the above (where network latency between service and data tiers is not an issue) is to perform caching in the data tier using, for example, a DBMS feature such as Oracle RAC, which provides a cluster of processes with data caches to improve performance and resilience.

Statelessness is a key characteristic of services, which is essential for a scalable and fault-tolerant SOA. State may be introduced if required but only after careful consideration as it will require complex and potentially less fault tolerant cache management facilities.

Distributed
Services should be distributable, that is they need not and indeed should not run in the same process as the consumer. Services that run in the same process offer no possibility of runtime reuse to other consumers.

In order to achieve this goal, you minimally need two things: a remoting framework and location transparency.

1. Remoting Framework
A remoting framework is the mechanism whereby consumers are able to locate and invoke remote services. Typically for SOA this means web services, though less interoperable protocols such as JEE and .NET may also be used, for example, where performance is a critical criterion. However, such decisions should not be taken lightly - the ability to interoperate is key to achieving reuse across the enterprise.

2. Location Transparency
Location transparency refers to the ability of a consumer to use a service without knowing where that service is running. This may be achieved to a degree through the use of DNS names hiding IP addresses, or creating server clusters fronted by an IP load balancer virtual service address. However, both of these still bind the consumer to a logical instance of the service. In contrast, a service registry provides additional decoupling in that consumers are searched for by attribute (e.g., name and version number) rather than being bound by name.

Location transparency is also required of the service implementation. Services should not be tied to any particular location, both for capacity planning reasons where it may be required to move services between servers to support load, but also for portability reasons. Achieving environment independence is achieved by running services in a container such as JEE or Spring that insulates the services from the underlying infrastructure, as well as ensuring that services are stateless.

Manageable
For a service to be manageable, the operating organization and infrastructure need to be capable of managing services. I won't repeat what I wrote previously in my article on applying ITIL to Service Management (http://soa.sys-con.com/node/702159), but I will say that in terms of runtime manageability it is important that services perform consistent, traceable, and monitorable error and audit logging, and can be monitored in terms of SLA adherence.

Summary
For those of you who are still awake, well done and thank you. Hopefully you have a better appreciation of the complexity involved in achieving some of these "little" service characteristics that are so often quoted.

SOA is non-trivial, and anyone who tells you otherwise is trying to sell you something.