Agreed. The overarching SOA principle focuses on separation of concerns based on lifecycle. If something changes at a different rate than something else, then the two aspects of the system should be factored into different services.
I'd say that SOA does also recommend a number of implementation constraints that support the principles: - separation of interface from implementation - explicit service descriptions - policy-driven interactions - etc Anne On Mon, Sep 8, 2008 at 8:48 AM, Mark Baker <[EMAIL PROTECTED]> wrote: > Oops, I forgot to comment on this... > > On Sun, Sep 7, 2008 at 10:46 AM, Anne Thomas Manes <[EMAIL PROTECTED]> > wrote: >> From my perspective, the overarching principle governing SOA is >> separation of concerns. This principle helps you determine how to >> factor functionality into services. > > The ability to separate concerns is, IMO, the most important and > (usually) most difficult task facing software architects. But it > isn't an architectural constraint/principle. In order for it to be a > constraint you have say *what* concerns you were separating. For > example, the separation of interface and implementation is an > architectural constraint. > > Mark. >
