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

[Davies Marc <Marc.Davies@uk.fujitsu.com>]

Now you've hit the important point for me Miko - SOA isn't *just* services
(despite our recent conversation thread), its architecture. My view is that
the services are the *realisation* of good architecture and a collective
approach toward building a loosely-coupled, multi-tiered and flexible
environment where its possible to gain cost synergies and re-use
flexibility, avoiding the seemingly endlessly recurring scenario of
large-scale enterprise with its bulky, silo-maintained and poorly integrated
(while being tightly coupled!) typical non-SOA environment.

I think Duane's example of the Internet perfectly underscores this principle
- inasmuch as the Internet is a collection of millions of services - it is
(IMHO) *not* an SOA - unless we're talking Service Oriented Anarchy :-)

... it doesn't conform to architectural disciplines, anyone can code how
they want, anyone can deploy what they want, there are no checks to ensure
services deliver on their promised capability (I could go on). Sure, its an
excellent example of how millions of services can be operating - but, its
also an illustration of how millions can end up delivering very poor
service, to analogise - if you google the 'wrong' search string - you end up
with 1 million 'hits' = meaningless

Essentially, this is my rationale for finding Steve's document so very
useful as a benchmark pointing us forward, as (for a change) it doesn't seem
to be the tail wagging the dog - i.e. its top-down approach assures the kind
of alignment with business goals which I think SOA is trying to achieve,
abstraction (at all levels) is an important element of SOA and in this
context defines (to me) the importance of blueprints; properly done they
represent a model that ensures a solution is customer (i.e. business
processes, goals and fundamentals) focussed, rather than technology driven.

Regards,
Marc.


-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com] 
Sent: 01 November 2005 02:33
To: Duane Nickull; Jones, Steve G; Beack, Theo; Davies Marc; Ken Laskey
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services

I deprecated the microservice antipattern because it was a "I know it when I
see it" antipattern, but hard to codify. I added a comment to the "Too many
cooks" antipattern to get a similar point across. I just see too many people
focused on the "S" part of SOA and maybe not enough on the "A". Present
company excluded, of course.

	-----Original Message----- 
	From: Duane Nickull [mailto:dnickull@adobe.com] 
	Sent: Mon 10/31/2005 4:42 PM 
	To: Miko Matsumura; Jones, Steve G; Beack, Theo; Davies Marc; Ken
Laskey 
	Cc: soa-blueprints@lists.oasis-open.org 
	Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services
	
	

	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