Larry,

>>Ugh.. definitions.. <g>
>>
>>Well, I had read your description where you asserted that each component in a stateless environment must be able to, in my words, survive on its own. Doesn't that also imply that it can pick up where it left off - whether you use tokens or some other method(s) to keep track of a transaction in progress?
>>
>>If so I'd want to say that MSMQ/Queued Components are, in so many words, stateless.
>>
>>Am I making sense or just plain confused? <g>
>
>Sure you're making sense....sortof. ;-)
>
>Yes MSMQ/Queued Components are stateless. And yes, statelessness is a requirement of disconnected components. But the converse is not true.
>
>Logical Example
>A dog is a mammal.
>I am a mammal.
>Am I a dog? No. (no comments from the peanut gallery).
>
>Mammal and statelessness are base attributes. Am I making sense?

I think we agree here. I don't think that a stateless application must be n-tier but it helps. Nor does an n-tier app need to be stateless.

I do think that an effective n-tier application will typically be easier to move to the web though, which is what I seem to recall that this part of this thread is all about.

Two different beasts IMO...