RE: [soa-blueprints] Anti-Blueprints - Number of services

["Duane Nickull" <dnickull@adobe.com>]

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