What is a Service in an SOA?

A Service in an SOA meets the following criteria:

• Multiple-use
• Non-context-specific
• Composable with other components
• Encapsulated i.e., non-investigable through its interfaces
• A unit of independent deployment and versioning

Duh...

A Service is written to a specification. It does not matter what the specification is: COM, Java Beans, WSDL, etc., as long as it adheres to the specification. It is only by adhering to the specification that it becomes a Service and gains features like reusability and so forth.

Duh...

The idea in OO (Object Orientation) is that software should be written according to a mental model of the actual or imagined objects it represents.
Services, by contrast, makes no such assumptions, and instead state that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics.

Duh...

When a Service is to be accessed or shared across execution contexts or network links, some form of serialization (also known as marshalling) is employed to turn its interfaces into a bitstream.

Duh...

It takes significant effort and awareness to write a Service that is effectively reusable. The Service needs:

• to be fully documented;
• more thorough testing;
• robust input validity checking;
• to pass back useful error messages as appropriate;
• to be built with an awareness that it will be put to unforeseen uses;
• a mechanism for compensating developers who invest the (substantial) effort implied above.

Duh...

No big deal to agree with these statements, is it? Now read, for fun, the definition of a Software Component where I took these text fragments from while replacing "software component" by "Service".

So, is a software component a Service and is CBD (Component Based Development) the same as building a Service Oriented Architecture? Not quite, it is the other way around: A Service in an SOA (as SOA is currently understood) is a software component, but a component with a strong business function constraint. SOA is an instance of a component based architecture. So building an SOA has always to do with CBD, but CBD has not always to do with building an SOA as we understand an SOA.

The idea that software should be componentized, built from prefabricated components (like Services), was first published in Douglas McIlroy's address at the NATO conference on software engineering in Garmisch, Germany, 1968 titled Mass Produced Software Components. A very interesting reading. Some quotes:

• The most important characteristic of a software components industry is that it will offer families of routines for any given job.

• He will consult a catalogue offering routines in varying degrees of precision, robustness, time-space performance, and generality.

• He will expect families of routines to be constructed on rational principles so that families fit together as building blocks.

• We have to begin by thinking small.

• It will take some time to develop a useful inventory, and during that time money and talent will be needed.

• Even before founding a pilot plant, one would be wise to have demonstrated techniques for creating a parameterized family of routines for a couple of familiar purposes

• I think that the whole project is an improbable one for university research. Research-calibre talent will be needed to do the job with satisfactory economy and reliability, but the guiding spirit of the undertaking must be production oriented.

• The personnel of a pilot plant should look like the personnel on many big software projects, with the masses of coders removed.

• Very good planning, and strongly product-minded supervision will be needed.

• the level of programming here will be more abstract

• One instantly thinks of distribution by communication link.

• The catalogue will be equally important.

• Quite soon one would expect a components industry to converge on a few standard types of interface

• but again unless the standards encompass the bulk of software systems (as distinguished from users), the components industry will die for lack of market.

• I would like to see components become a dignified branch of software engineering.
  

• I would like to see standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters.

• I would like to apply routines in the catalogue to any one of a large class of often quite different machines, without too much pain.

Fascinating similarity, these quotes from a respectable 40 years old document and our modern innovative SOA-thoughts, isn't it?