implementations, architectures and modeling

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

Been trying to nail down -- mostly for my benefit -- what an RM was.

Personally, while appreciating the effort, I do not buy the "RM is so  
abstract it can't be implemented" view point. There are simply too  
many ways that you can fail to implement something.

However, consider the following sequence:

1. You have an artifact ( something that was designed and  
constructed). Say a web service.
2. How do you *know* you have an artifact: you describe it of course.  
You say how it was designed and built -- you outline aspects of its  
architecture.
3. How can you describe something without first having an idea of it  
-- its conceptualization. E.g. a car. Without the concept of a car,  
the only way you can describe a car is through some combination of  
its components and function (it has wheels and you can use it to go  
to the Dry cleaners).

Clearly, IMO, there is a parallel here: we have actual Web services  
and other distributed systems that have been built and paid for (too  
much in some cases :)

We have also been reasonably successful in describing these things.

We are now at the point of trying to nail down the concept of  
services, which is what a reference model is really for: to help give  
a name to the elephant in the tent.

This is why it is so important to be able to succinctly and clearly  
define what a service is. Like with the car industry, once you have  
the concept of a service we can go on to specialize it and  
differentiate it into things like Web services, in-car entertainment  
services [:)] etc.

Frank