Should a service only be considered a service if it's reusable? The answer to
this question, as asserted by this pattern, is a firm "no." While agnostic
services (services providing multi-purpose logic with reuse potential, as per
the Agnostic Context pattern), receive the most attention during service
modeling and design phases, it can often be short-sighted to focus only on
agnostic service logic.
Non-agnostic logic represents any type of functionality that is unique to a
given business process or task. In other words, non-agnostic logic is
single-purpose in nature and therefore has no reuse expectations. One of the
most common forms of non-agnostic logic relates to the composition of other
When combining various services into a larger service composition, a parent
layer of business decision-driven functions often emerges to establish the
overarching w... (more)
Enterprise-wide harmonization is a desirable and ideal target state that
fully supports pretty much everything SOA and service-orientation stand for.
For those that have achieved such a state, bless your standardized hearts.
You have accomplished something that has eluded many others. However, not
attaining this state does not mean you cannot successfully adopt SOA.
In some circles it has become common to view an SOA initiative as an
all-or-nothing proposition that demands an uncompromising commitment to an
enterprise-wide transformation effort. For those that subscribe to this vi... (more)
Like data normalization, the Service Normalization pattern is intent on
reducing redundancy and waste in order to avoid the governance burden
associated with having to maintain and synchronize similar or duplicate
bodies of service logic."
You can see it introduces the Pattern on our publisher page.
When designing data architectures, you can easily end up with different
databases or even different database tables containing the same or similar
data. This has been the root of many well documented data maintenance and
quality issues that helped establish data normalization as widel... (more)
A service inventory is a living body of services that individually will need
the freedom to evolve independently over time. What we learned when
documenting the SOA design pattern catalog is that there are patterns that
emerged not only at design-time but also during this post-implementation
evolutionary stage in a service's lifecycle.
There is one common scenario that repeatedly surfaced in many projects:
When we model and design services during early stages of SOA adoption we are
constrained by current infrastructure and technology. These constraints
require that we limit the s... (more)
Services are useful, but they come with a price tag. The cost of developing a
service is higher than the cost of developing a traditional
(non-service-oriented) application, primarily due to the extra work and
infrastructure required. Another common concern when creating and consuming
services is the possibility of a performance hit. Together these issues hint
that even if you've decided to wholeheartedly adopt SOA, you may not want or
need to move all your functionality into services. This is where the
application Service Encapsulation becomes a focal point as we ne... (more)