In other words has someone just “right-clicked”
on a JavaBean (or C# object) and selected “Create Web Service” from
the menu, or was there actually planning and intent? I’ve actually
seen organisations where just this sort of exercise has been undertaken
creating the thousands of web services problem.
Number is part of the issue, its
indicative of a bad approach when organisations create thousands of DISTINCT
(as opposed to instances) of web services. But the Service should have a qualitative
impact on the “real-world” or provide a useful function (e.g. mathematical
calculation) this stuff is in the SOA-RM as being the basis of service.
In terms of numbers I’d say that volume
is an important indicator of bad
practice, not a definitive guide but its getting a more and more common
statement “We’ve got hundreds of web services and it hasn’t
helped us at all”. Clearly its possible to have lots of top quality
services, in the same way as in theory its possible for people to write decent
multi-threaded code but in practice both are normally indicators of problems.
Ken Laskey [mailto:firstname.lastname@example.org]
Sent: 25 October 2005 21:47
To: Miko Matsumura
Subject: Re: [soa-blueprints]
The question is less one of number than independence. Does the original
interface (method call) provide a capability that is useful beyond the object
with which it is connected and can it be used without being part of a sequence
with other methods from the same object?
On Oct 25, 2005, at 4:10 PM, Miko Matsumura wrote:
This is a good topic, thanks for
introducing it, Steve.
The number of services *is* a quantitative
measure, but perhaps not a very helpful one? =)
I'm pretty sure there's an antipattern
here, and I think perhaps there could be some kind of way to assess this. I
think another variable in this mix is the extent to which the registry
repository in question can help with respect to discovery and classification as
well as governance. The thing that worries me is when I see people assuming
that fine grained (object level) services will be reused, when the reality is that
OO didnt generate that much reuse from even the guy in the next cubicle, let
alone across the company or across the planet.
I think this is less of a gross number of
services antipattern so much as a coarse-grained vs fine-grained antipattern...
From: Duane Nickull
Sent: Tuesday, October
25, 2005 12:57 PM
I disagree with this anti-pattern.
I am not sure that the number of services
is really a quantitative measure of SOA. A grid computing cluster
administrator may be able to rationalize such behavior, although it may seem
absurd in other areas such as Amazon deploying a service for each book it
carries vs. deploying one service that allows the consumer to parameterize the
Perhaps a better measure would be the
development of some test criteria to ascertain whether a contemplated service
is a good candidate for repurposing beyond a small number of consumers.
This should be based on alignment with LOB and presumably different
implementers will have different criteria for quantifying such.
From: Miko Matsumura [mailto:email@example.com]
Sent: Tuesday, October 25, 2005 12:41 PM
Subject: RE: [soa-blueprints]
I just added a "microservice"
antipattern where programmers put 10000000 WSDLs into a registry just because
their IDE lets them do so.
Sent: Tuesday, October 25, 2005 11:54 AM
Subject: RE: [soa-blueprints]
Good idea. I put up the first drafts of
them at: http://blueprints.jot.com/WikiHome/SOA+Anti-Patterns/SOA%20Anti-Patterns
Let me know if I correctly eloborated and
named them for you.
From: Jones, Steve G [mailto:firstname.lastname@example.org]
Sent: Tuesday, October 25, 2005 11:21 AM
Subject: [soa-blueprints] Anti-Blueprints
The SOA Blueprints will lay down a “best
practice” set of guidelines and templates for delivering SOA. This
will definitely be a positive thing and help expand and firm up people’s
understanding of SOA. One thing that the group states that it will do is
define standards and guidelines, does this mean that allied to our blueprints
we must also consider the “anti-blueprints” (analogous to
anti-patterns) that must be avoided. So for instance focusing on process
over service (bad), only thinking of web services (bad) etc etc. Defining
the blueprints give guidance towards success criteria, but should we also give
guidance on failure criteria for acceptance of a system as being
Not sure whether this should be in the TC as its laying down
best practice, and not to increase the already large workload… but it
needs to be somewhere.
If you’ve started with an enterprise “best
practice” process map you are NEVER going to be SOA and 90% probability
your system will be inflexible or fail.
Web Service point to point is STILL point to point, doing a
bad practice in XML doesn’t make it better
Splitting into two separate tiers of Service and Process
with separate rules and governance results in divergent solutions
Creating “business” services based on the belief
that IT understands the business results in services that meet neither IT nor
Building your own proprietary XML-RPC stack to give yourself
The last could still be SOA from one perspective, but
I’ve yet to see it done well when the driver was a belief that its better
done in house than using standards. When we get the official Wiki it
could be something to document via that route.
CTO, Application Development Transformation
T +44 870 906 7026| 700 7026| www.capgemini.com
Join the Collaborative Experience
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group. It is intended only
for the person to whom it is addressed. If you are not the intended recipient,
you are not authorized to read, print, retain, copy, disseminate, distribute,
or use this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
|This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.|