|
Web services are an enabling technology upon which you can build an
SOA, but Web services can also be used in many non-SOA ways. For
example, in a Java application you could wholesale swap use of EJB/RMI
with Web services inside a single application and the application may be
no closer to being part of an SOA.
An SOA is an architecture which allows services to be reused across
projects and application teams. Successful reuse has fundamental
requirements like the ability to version services without impacting
consumers -- something traditional distributed systems have been poor at
in real world scenarios. In contrast, Web services make reuse much
easier because of the self describing nature of messages (consumers that
don't understand part of the message can safely ignore it) and because
of the ability to seamlessly introduce intermediaries between consumers
and providers to, for example, add a layer of additional security
outside the application or to execute a zero-downtime version rollover
while consumers continue to use the service.
The easiest way to objectively measure how close you are to having an
SOA is to measure the number of different reuses of services in your
environment (not the number of services themselves). That is, if you
have a hundred Web services, each used by only one consumer, you couldn't
really consider your environment an SOA yet (there's no reuse). If, on
the other hand, you have only one service, but it's used by a hundred
different consumer applications, you can safely say you have an SOA.
Cheers.
|
