My quibble with SOA patterns is that they tend to be common sense and hardly worth documenting.
A colleague was talking about the Federation Pattern and when I asked what it was, it turns out that it's something we've been happily doing for years.
Thomas Erl describes it in SOA Principles of Service Design as:
"A federated IT environment is one where resources and application are united while maintaing their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extent it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
"In support of increasing federation, standardization becomes part of the up-front attention each service receives at design time. Ultimately this leads to an environment where enterprise-wide solution logic becomes naturally harmonized, regardless of the nature of its underlying implementation."
Erl hints that there are greater costs in the attention each federated service demands at design time. Most of the development time in an over-federated suite of applications is the tedious work of writing yet more mapping code and config that allows the interoperability.
What this threshold must be assessed on a case-by-case basis. As ever with architecture, your mileage my vary.
A colleague was talking about the Federation Pattern and when I asked what it was, it turns out that it's something we've been happily doing for years.
Thomas Erl describes it in SOA Principles of Service Design as:
"A federated IT environment is one where resources and application are united while maintaing their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extent it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
"In support of increasing federation, standardization becomes part of the up-front attention each service receives at design time. Ultimately this leads to an environment where enterprise-wide solution logic becomes naturally harmonized, regardless of the nature of its underlying implementation."
Erl hints that there are greater costs in the attention each federated service demands at design time. Most of the development time in an over-federated suite of applications is the tedious work of writing yet more mapping code and config that allows the interoperability.
What this threshold must be assessed on a case-by-case basis. As ever with architecture, your mileage my vary.
No comments:
Post a Comment