Objects, Components, Models and Services

re: Objects, Components, Models and Services

jd — Mon, 17 May 2004 23:07:00 GMT

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 :)

re: Objects, Components, Models and Services

Michael Platt — Mon, 17 May 2004 23:11:00 GMT

Hum, I think I agree with you. The class is the design time artifact (eg the plans).

re: Objects, Components, Models and Services

Who? Me? — Tue, 18 May 2004 00:08:00 GMT

Maybe a "Glass house of architects" :P

re: Objects, Components, Models and Services

Darrell — Tue, 18 May 2004 10:12:00 GMT

Your definition of a component is kind of circular. A component is an assembly, which is made up of however many objects. What makes the collection of objects a component? Because they are in the same assembly!

Once you get to runtime, components certainly are what you say they are. However, that definition does not provide developers with any guidance on how to group objects (or classes, per above comments) into components.

There is probably some split for each of these concepts into design-time activities and run-time activities.

re: Objects, Components, Models and Services

Todd Girvin — Wed, 19 May 2004 02:24:00 GMT

Models are things we construct to represent the real world. Diagrams show views of models from some viewpoint. To see a diagram of the conceptual model of architecture according to IEEE, and the relationships of model, views, and viewpoints, go here: http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf

UML is just a diagramming language.

I like your definition of components, even though it's uncommon. I've always used the name "module" for that, but it's equally vague and overused.

re: Objects, Components, Models and Services

Tom — Wed, 19 May 2004 19:50:00 GMT

Remember that these terms have the same meaning when we think about the world around us:

Object – is a thing of interest to us, a material thing outside the mind, it is a boundary that allows us to understand something, e.g. Rover my dog is an object of interest to me, but Rover’s intestines may be of interest to my Vet.

Component – is an element of structure, i.e. it is the part or thing that something is made up of. Rover’s intestines are a component of rover and Rover himself may be a component of some dog like social structure: the group of local mongrels… Again this is about meaningful boundaries.

In the real word these boundaries overlap depending on perspective.
The problem of agreeing a single meaning for these terms in an IT problem space, where people have different perspectives of the space, and the same person will have different perspectives on the space depending on their relation with the space, can never be solved while people are people.

Service – oddly a service can be about the inappropriateness of the other two labels. What I mean is that a service is a product that cannot be understood as either a component or object: it is more about activity than about structure.

All three are related because in the IT world components and objects collaborate to deliver services. They make up the structure that enables activity.

re: Objects, Components, Models and Services

Tom — Wed, 19 May 2004 20:00:00 GMT

.. 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....

re: Objects, Components, Models and Services

Michael Platt — Thu, 20 May 2004 00:40:00 GMT

I agree with these comments, models are indeed just representations and so perspectives are all important. That is why I said what my background (and hence viewpoint) is, without that context then it is really difficult to come to agreement on what these higher level of abstraction models are as it depends on viewpoints. That's why it was such a suprise to me that my understanding of a component wasnt the standard developers understanding.
I went to a talk about ontologies yesterday and that reinforced my concern about understanding and meaning of "high level" abstractions being very dependant on viewpoints. I'll bolg about this in more detail.
Thanks everyone for the feedback and comments, most thought provoking.

re: Objects, Components, Models and Services

Mehran Nikoo — Thu, 20 May 2004 03:31:00 GMT

I think your definition for object is a better match for "Class". The class is the design-time component that developer works with. "Object" is an instance of the class, or in other words the "Class" is a template for the "Objects".

Szyperski (which happens to work for Microsoft Research) has the following definition:
Object
- is a unit of instantiation, has a unique identity
- may have state and this can be externally observable
- encapsulates its state and behavior

and component:
- is a unit of independent deployment
- is a unit of third-party composition
- has no externally observable state

Your take on components (.dll or .exe files) is mostly correct, but components are not exactly same as .dll or .exe files, for example you can have satellite assemblies, consisting of multiple .dll files but you can't deploy the satellite assembly without the language-neutral one)

Services are much more controversial. Although Web Services are the most popular way of implementing services, but a service doesn't have to be a "Web Service", and you can have a Web Service which is not a service (for example a SQL Server stored procedure published as web service!). Many people use web services as a transport protocol so IMHO we shouldn't "Services" and "Web Services" interchangeably.

re: Objects, Components, Models and Services

Michael Platt — Thu, 20 May 2004 14:45:00 GMT

I don’t get this definition, why differentiate between a unit of instantiation and a unit of deployment? Only the deployment folks care about units of deployment, I (as an application architect trying to get the app to scale) or the dev's I work with (who are trying to understand what the app should do) don’t care. My definition of component is closer to Szyperski's Object definition.
I agree about web services not necessarily being web services.

re: Objects, Components, Models and Services

Mehran Nikoo — Fri, 21 May 2004 00:29:00 GMT

This is the way I think:

Assume we have got a class named Customer and another one named Order. At run-time when I instantiate an instance of "Order" class, I am actually working with an object. This object has a unique identity (which separates it from any other instance of the same Order class) and so is the unit of instantiation.

Now when it comes to packaging my application, I decide to create a single .NET assembly and put Order and Customer classes in that assembly. When I compile the application I will get a .dll file (e.g. MyOrderProcessing.dll). MyOrderProcessing.dll is a unit of deployment, it means that we can't deploy part of a .dll file so the .dll file is the smallest unit we can deploy.

Another reason why it is better to define the Components as unit of deployment is that this way people know they shouldn't use components to logically group classes together (namespaces are a much better option to logically group classes).

We could argue whether or not we as application developers/architects need to care about deployment. Although ideally we shouldn't (architecture and design should be technically independent of deployment environment) but we are not there yet. For example if you decide to separate two sections of your applications so that you can scale out, then defintely you need to put them in separate components, otherwise you can't break down the component.

Also there are some limitation imposed by other applications. For example consider COM+. When you create an application in COM+, you can specify whether you want the application to work as a server application or a library application, which impacts the process model. This impacts performance (e.g. marshalling) and security model so when designing the classes, we need to think about the way we want to deploy the software. I would like to see a time when we don't have to do this as architecting an application is complex enough, but again I don't believe we are there yet.

I hope new initiatives from Microsoft like DSI will help us in getting there :)

re: Objects, Components, Models and Services

Free Credit Report Online — Thu, 01 Jul 2004 04:49:00 GMT

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.