I
thought this was common sense? :)
But
definitely should be in the anti-patterns.
-
Dan
-----Original Message-----
From: John Harby
[mailto:]
Sent: Tuesday, November 01, 2005 6:27
AM
To:
Subject: Re:
[soa-blueprints] Anti-Blueprints - Number of services
One metric that I think is relevant is message design. The notion of
distributing fine grained objects has been flagged as an anti-pattern by many
including Fowler (
http://www.sdmagazine.com/documents/s=815/sdm0304a/). For example, If I
have one service method which returns an employee number and another which
returns the employee name then since these will both be frequently required by
consumers, I should provide a way for consumers to retrieve both rather than
subject them to multiple unnecessary invocations.
On 11/1/05, Davies
Marc <>
wrote:
Now
you've hit the important point for me Miko - SOA isn't *just*
services
(despite our recent conversation thread), its architecture. My
view is that
the services are the *realisation* of good architecture and
a collective
approach toward building a loosely-coupled, multi-tiered and
flexible
environment where its possible to gain cost synergies and
re-use
flexibility, avoiding the seemingly endlessly recurring scenario
of
large-scale enterprise with its bulky, silo-maintained and poorly
integrated
(while being tightly coupled!) typical non-SOA
environment.
I think Duane's example of the Internet perfectly
underscores this principle
- inasmuch as the Internet is a collection of
millions of services - it is
(IMHO) *not* an SOA - unless we're talking
Service Oriented Anarchy :-)
... it doesn't conform to architectural
disciplines, anyone can code how
they want, anyone can deploy what they
want, there are no checks to ensure
services deliver on their promised
capability (I could go on). Sure, its an
excellent example of how
millions of services can be operating - but, its
also an illustration of
how millions can end up delivering very poor
service, to analogise - if
you google the 'wrong' search string - you end up
with 1 million 'hits' =
meaningless
Essentially, this is my rationale for finding Steve's
document so very
useful as a benchmark pointing us forward, as (for a
change) it doesn't seem
to be the tail wagging the dog - i.e. its
top-down approach assures the kind
of alignment with business goals which
I think SOA is trying to achieve,
abstraction (at all levels) is an
important element of SOA and in this
context defines (to me) the
importance of blueprints; properly done they
represent a model that
ensures a solution is customer (i.e. business
processes, goals and
fundamentals) focussed, rather than technology
driven.
Regards,
Marc.
-----Original
Message-----
From: Miko Matsumura [mailto: ]
Sent:
01 November 2005 02:33
To: Duane Nickull; Jones, Steve G; Beack, Theo;
Davies Marc; Ken Laskey
Cc:
Subject:
RE: [soa-blueprints] Anti-Blueprints - Number of services
I
deprecated the microservice antipattern because it was a "I know it when
I
see it" antipattern, but hard to codify. I added a comment to the "Too
many
cooks" antipattern to get a similar point across. I just see too
many people
focused on the "S" part of SOA and maybe not enough on the
"A". Present
company excluded, of
course.
-----Original
Message-----
From: Duane Nickull
[mailto:
]
Sent: Mon
10/31/2005 4:42 PM
To: Miko
Matsumura; Jones, Steve G; Beack, Theo; Davies Marc;
Ken
Laskey
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints - Number of
services
All:
I still have problems with
the "number of services is a
measurement
of
whether something
is a pattern/anti-pattern for SOA" conversation.
If you agree that the internet
is a large SOA, it has more than
10,000,000 services and I do not think that anyone would state
that
is
not an SOA due to the
large number of services. I would not be
willing
to state that the
internet is architected errantly since it has
too
many
services. Number of
services has no static bearing on good vs.
bad
design IMO. The
requirements vary specific to scenario and YMMV.
Some thoughts on what may not
be SOA (*thoughts only)
1. A
service that is orphaned and has no associated mechanism
for
being
discovered by any
consumer is probably not SOA, even though it is a
service itself. One of
the core tenets of SOA is that
concrete
services
must have some
mechanism to declare they exist and are available
and
to
communicate such to
potential consumers.
A service
availability and discovery concept is in the
core
reference
model (*EDITORS
DRAFT only).
2. A service with a
set of metadata too slim to provide a
potential
consumer with the
information and/or pointers to information it
requires
to make a service
invocation request is not SOA. This may
include
many
mechanisms including
out of band human-to-human contact to
figure
out
more intricate
details.
A service discovery
concept is in the core reference
model.
3. A set of multiple
services that functionally duplicate each
other
and
one of the services is
not used by any active or planned future
consumer
MAY be a poor practice,
but is still probably SOA.
4. A
service that does not have a mechanism to allow a
potential
consumer to discover its
policies may not be SOA. Even if a service
has
no specific policies, that
is still a conceptual policy.
5.
A set of services that advertise or claim they act on a
specific
resource but in fact do not
do anything, are likely not SOA.
6. A service that has no
interaction possible is likely not
SOA.
7. An always on synchronous
socket from one physical endpoint
to
another
may not be
SOA. Not sure how to qualify this or if it is relevant
to
the price of tea in
China...
So
what!
While this is an
interesting conversation, I also think it
may
detract
from the work of
building the following items:
1.
A metamodel for expressing architectural blueprints;
and
2. A catalog of SOA blueprints
and a system for locating ones
that
are
applicable to a specific
scenario.
Duane
