In a blog entry xOP some months ago, I outlined what I felt about OOP, COP and AOP and their relationships to each other. In recent discussion with Dave Fellows and James Greenwood some more things about components and object became clear. This posting is a summary of the discussions (from my point of view).

Statements to Services, some definitions

Services are built with Components. Components are built with Objects, Objects are built with methods and have properties/state, Methods are build with Statements (those last two from James). [ Replace ‘are’ with ‘should be’ or ‘could be’ as appropriate ]. There is an implicit functional extension for each of these ‘built with’ transitions.

The interesting thing here is that earliest programming languages concerned groups of statements almost exclusively. Later languages introduced methods (then known as functions in languages of old). In the 80’s and 90’s when objects and OOP came into being instances and alike were conceptualized. In the mid 90’s components, COP, and patterns per se emerged as sensible ways to construct more sophisticated applications. At the end of the 90’s services were added to applications to allow them to be laced together. Services have definite connotations of marshaling and remoteness. Aspects, though invented on the same timeline, seem to me to be a tool through which services (amongst other things) should be delivered rather than a shift in the way applications are designed and modeled.

Publication points

Objects are used by developers building an application for a given language and can be published to other developers as part of an API or if reuse is a goal.

Developers building an application may make or avail of components. There is still one language involved, and often published to an audience is more likely that with objects. More than objects, components are deliberately coded to an abstract concept. A developer using a component cares more about API than implementation, and it is a typical characteristic that a deployer of an application can swap in alternate implementations of components.

Services are always published to an audience (developers using various languages on many distant systems). They typically expose a facadified component model that distant audience. Implementation is almost irrelevant compared to location.

Aspects are nearly never published to any audience. They are used to tangentially fit functionality to objects and components. Nobody ever publishes an API based on aspects, though I am sure Jon Tirsen will correct me ;-)

Development of applications

Service Oriented Design is talked about in a number a places on the web. A coherent story is at A Basic Design Model for Service-Oriented Design. Microsoft often talk of WSDL driven development, which is in the same space.

My particular view is that test driven design for an evolving component model is best. When doing so, consider what (thru a little AOP smoke and mirrors) can be delivered in terms of service or adaption for the component model. Care less about the implementation detail of things like the persistence at the outset, but care a lot about the component patterns and transparency.