Interesting, but my initial reaction is that the notion of a container implies a level of isolation and focus that, IMO, should not exist.
Components in an architecture are not constrained by SO principles only. A service provider will be constrained not only by SO items, but also by principles that guide/constrain its implementation. A service consumer will likely have far more than just SO concerns. IMO, SOA does not stand on its own. It is not a distinct level of architecture. It is not an instantiation of anything. It is a set of characteristics and attributes. A Cape Cod house has distinct characteristics and attributes. But it is still a house and has many more concerns than just Cape Cod-ness. :-) So too does this apply to BA, EA, etc. SO applied to BA, EA, is interesting. SOA as a term/notion by itself has no level and no context. The container is the BA, EA, etc. Not SOA. People that say they've implemented an SOA are off the mark, IMO. What they've really implemented is an EA, an AA or an integration architecture that follows SO principles. Most are probably the latter. As always, just my 2 cents. -Rob --- In [email protected], JP Morgenthal <[EMAIL PROTECTED]> wrote: > > Actually, I like where this thread is going. We could easily > make the assertion that SOA is the container itself and that the > items contained in the architectural container encompass > service-orientation. Hence, we can focus on what we want to put > in the container and stop arguing about what the container is > called. Thus, SOA asserts itself as a thing, but has no > discriminate attributes, but is the aggregation of the contained > items' attributes. > > The other interesting side-effect of making this assertion is that > there's a 1:1 correlation between the concept of SOA as a > container and a physical service container that would be used to > implement an SOA design. > > Now, all we need to do is start a debate on what we want to put in > the SOA container. > > JP
