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

["Miko Matsumura" <mmatsumura@infravio.com>]

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