[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Anti-Blueprints
Steve, I
agree with the statement that SOA is not WS (and vice versa). Likewise I also
agree that governance and the adherence to standards is paramount to the
successful implementation of an SOA. Yet,
I know that many organizations face a deep cultural change
when implementing an SOA and the kind of discipline we are talking about doesn’t always come easy. I
think few organizations get everything right the first time round, especially
the governance and standards aspects.
This
is where I think the blueprints can play an important role in guiding organizations when implementing SOA,
while avoiding some of the pitfalls they are bound to
face. Regards Theo From: Davies Marc [mailto:Marc.Davies@uk.fujitsu.com] Sent: Thursday, October 27, 2005 06:52 To: Beack, Theo; Jones, Steve G; Ken Laskey; Miko Matsumura Cc: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints Sorry Theo but, I think
Steve is on to something with anti-patterns and I *do* consider the number of services to give
an indication of approach. In
particular your comment: - it might even
be a cultural barrier; developers might think using services is a
waste of time and prefer to integrate their apps in another
way …Implicitly indicates
to me that (in that example) this is not an SOA environment. An SOA journey
must have strong centralised (architectural) control ensuring developers do not
just ‘do it’ how they think is the best way forward for “their” application
(which in reality of course, isn’t their application – it’s the business’
application, a fault many of us have suffered from at some point in our careers,
I’m sure :o) SOA is not WS (IMHO),
SOA does mean strong Governance and adherence to standards, and this may
frequently upset Developers! M. Marc
Davies Fujitsu
Business Unit
Chief Technology Officer Architecture
& Design Group Core
Services E-mail:
marc.davies@uk.fujitsu.com Telephone:
-Hot Desking- This e-mail
is only for the use of its intended recipient. Its contents are confidential and
may be privileged. Fujitsu Services does not guarantee that this e-mail has not
been intercepted and amended or that it is
virus-free. From: Beack, Theo
[mailto:Theo.Beack@softwareagusa.com] I don't consider
the number of services to be an accurate indication of either a good
or bad approach. I think that one has to be more precise in measuring the
relative maturity of the services that exist. Factors that can help one
determine the "maturity index" of the SOA implementation might
include: - level of
reuse, - scope of the
services, - service
granularity, - adherence to
architectural blueprints, The
statement “We’ve got hundreds of web services and it hasn’t
helped us at all” is only a symptom of a potentially
larger (or real) problem. The lack of reuse can be caused by factors
such as: -
developers might find it difficult to find the
appropriate services, - several
conflicting services might exist that provides similar
functionality, - instability or lack
of performance of services & infrastructure might cause developers to
abandon the use of services, - it might even
be a cultural barrier; developers might think using services is a
waste of time and prefer to integrate their apps in another
way In my experience many
organizations create services without doing any planning. Many tools allow them
to do this in a very easy manner and developers could easily created a large
collection of services, without any planning. Following a good services
design approach might be an important step to create truly reusable services.
Determining the purpose of the service, who the primary consumers will be, usage
patterns, interfaces required for the various consumers, service security,
documentation, proper metadata, etc. all of these aspects of a service should be
considered and might play an important part in making it a usefull and widely
used service. Regards Theo From: Jones, Steve G
[mailto:steve.g.jones@capgemini.com] 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. Steve From: Ken Laskey
[mailto:klaskey@mitre.org] 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?
Ken On Oct 25, 2005, at 4:10 PM, Miko Matsumura wrote:
------------------------------------------------------------------------------------------
Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]