--- In [email protected], JP Morgenthal <[EMAIL PROTECTED]> wrote: > > Interesting timing of your question Rob. I pose the blog entry > Gervas posted from me as a partial response to your question. > However, I would be careful about the statement "Services do not > have UIs" as all services have interfaces. I'll go so far as to > say that a service could have a human interface in addition to a > UI.
I guess we disagree. The nature of UIs (or human interfaces) is such that they would tend to make the service stateful and too context specific. Those aspects are better managed, IMO, by service clients which are typically built for a given audience and context. > That said, I would be careful to differentiate platform from > architecture. Agreed. Now if Linthicum would refrain from claiming that a platform will drive SOA, that'd be cool! :-) > To me Chrome is the platform and SOA is the architecture that > something running on that platform might access. This one gives me the heebies a little. A platform doesn't "access" an architecture, IMO. Chrome, or any browser, would be the implementation detail of a particular architecture component. It isn't separate from the architecture. It is a part of it. It is the host platform of a service client. I subscribe to the view that SOA isn't an architecture at all. It is a style. The architecture, which will follow SO and other principles, is the EA, the AA, etc. To help clear up confusion, would it be helpful if we stop referring to SOA as a thing that is instantiated/implemented? SO is a characteristic of a BA, EA, AA, etc. It isn't an architecture itself. Would promoting this view help move things away from equating SOA with specific technologies/implementations? -Rob
