Partager via

Objects, Components, Models and Services

  • Article

I was in a meeting with a group of architects the other day (should that be a gaggle of architects? Or perhaps a whoop!) about SOA. Everyone was pretty much in agreement about what it was and when it should be used so in order to liven things up I threw in the old architectural saw:

What’s the difference between an Object, Component, Model and a Service?

Interestingly enough there was little agreement. Indeed there was not much agreement about the difference between an object and a component which always amazes me as we have had OO and Component based designs around for at least 10 years. There were the usual OO based definitions and strange, contorted positioning around how components fit in with OO which then just collapsed when Services were introduced.

I have my own definition for what Objects, Components and Services are which works well for me and I have always used. In fact it was only a couple of years ago that I realised my definitions were not what everyone else uses however as the definition used by the majority (of developers I might add) doesn’t seem to work too well I will stick with mine.

So what is my definition? To understand it you have to understand my background and viewpoint which, without going back to my childhood (this not being a session with my analyst!), is very much embedded systems / OS runtime / message based. So to me a component is the actual DLL or exe instantiated in the system at run time and executing the designed functionality. It is what the machine works with and understands. An Object is a design time artefact for the developer to work with before compilation into one or more (or less) components. It is what the developer works with and understands.

If you are debugging functionality you work with objects, if you are tuning systems or into locking and transactions then you work with components.

So with that simple and clear understanding of what Components and Objects are Services and Models become much easier. Services are just groups of components providing higher level functionality and communicating with messages (as all good systems should IMHO). They exist at run time as groups of components working together as a web service; that is they are what the systems (one or more machines) work with and understand. Finally UML type models are just a higher level of design abstraction than Objects, that is they are a design time artefact for architects which are conceptually a group of Objects (ok so that isn’t as good as I would like but you get the idea).

Well I have been using this model of what components, objects and services are for a long time and it works for me. It’s simple and has a easily understood demarcation line (before and after run time). Finally both models are valuable, one to help understand what the machine is doing and one to understand what the developer is doing, both of which can be pretty incomprehensible at times J.

So does anyone have a better set of definitions? Why is my model wrong? Interested in your thoughts, it certainly is about time we got a common understanding of what these things are, especially as we are now building on top of them. Of course that will get rid of one of my favourite architectural questions; but then I have a lot more!

Comments

  • Anonymous
    May 17, 2004
    Hi!

    Just to say that i agree with all you definitions except objet. For me, an object is a class that defines a real world independent object.

    Example: the class of a car are the plans to build it. The actual runtime object are the cars we see riding the streets.

    hope that helps :)
  • Anonymous
    May 17, 2004
    Hum, I think I agree with you. The class is the design time artifact (eg the plans).
  • Anonymous
    May 17, 2004
    Maybe a "Glass house of architects" :P
  • Anonymous
    May 18, 2004
    The comment has been removed
  • Anonymous
    May 18, 2004
    The comment has been removed
  • Anonymous
    May 19, 2004
    The comment has been removed
  • Anonymous
    May 19, 2004
    .. a model is any representation of the world that allows us to think about a particular aspect of the world we may be interested in....
  • Anonymous
    May 19, 2004
    The comment has been removed
  • Anonymous
    May 19, 2004
    The comment has been removed
  • Anonymous
    May 20, 2004
    The comment has been removed
  • Anonymous
    May 20, 2004
    The comment has been removed
  • Anonymous
    June 30, 2004
    So, why do definitions matter? I think as long as the team or company have a common understanding (or misunderstanding) of each term's definition than effective code can be written.