> If your EC changes, you cannot guarantee service SLA and, > sometimes, service behavior and results.
Well I'm definitely coming at all of this from a DDD mindset and (as you know) in DDD you have bounded contexts each of which can own their own models/database schemas etc. Ultimately there might be one database shared by multiple bounded contexts (simple cases), or different databases, or different databasse on different servers. In fact to me giving a bounded context (or business service) control of its own environment, including how the data is managed, is useful from the SLA perspective (and general autonomy). I'm not saying its necessarily part of SOA, but I think of it as a useful part of the implementation of services. > Ownership of resources is typical application-oriented approach: > applications try to occupy and own all possible entities they > depend on at run-time. Service-oriented approach is based on > separation of concerns and responsibilities placed on the top of > competition in QoS. Tell me that I am wrong. Can't tell you that, I don't entirely follow though. I guess I don't fully understand what you mean by "you should never MANAGE data you service works with, you have to process/massage/transform the data, not manage, and by no means - manage data store.".
