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 book title.
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.
Duane
From: Miko Matsumura
[mailto:]
Sent: Tuesday, October 25, 2005
12:41 PM
To: ;
;
Subject: RE: [soa-blueprints]
Anti-Blueprints
I just added a
"microservice" antipattern where programmers put 10000000 WSDLs into
a registry just because their IDE lets them do so.
Miko
From:
[mailto:]
Sent: Tuesday, October 25, 2005
11:54 AM
To: ;
Subject: RE: [soa-blueprints]
Anti-Blueprints
Steve,
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.
Thanks,
Dan
-----Original
Message-----
From: Jones, Steve G
[mailto:]
Sent: Tuesday, October 25, 2005
11:21 AM
To:
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
“SOA”.
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.
My top 5 are
1)
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.
2)
Web Service point to point is STILL point to point, doing a
bad practice in XML doesn’t make it better
3)
Splitting into two separate tiers of Service and Process
with separate rules and governance results in divergent solutions
4)
Creating “business” services based on the belief
that IT understands the business results in services that meet neither IT nor
business goals
5)
Building your own proprietary XML-RPC stack to give yourself
“control“
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.
Steve
___________________________________________________________
Steve Jones | Capgemini
CTO, Application Development Transformation
T +44 870 906 7026| 700 7026| www.capgemini.com
m:
txt: +44 (0) 7891157026
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.
