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

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

Yes, absolute number is not a good measurement of whether someone is doing a good job implementing or not. I think enough people have bonked this antipattern to suggest that it is poorly stated, let me take a crack at refactoring it, and if I cant, then I'll take it out. I do think there's a pony in there, I just need to articulate it better... Something like it may pop up in the context of an actual blueprint...
 
The good thing about antipatterns is that their job isnt to say "SOA" or "Not SOA", and their job isn't even to say "This style never works". I think the phrase Steve used was "Here be dragons", and I think that says it well.  I think that many antipatterns apply only in certain cases. 
 
The exercise of patterns/antipatterns in a vaccuum has been useful as a warmup activity, but we will really see what sticks once we have jumped into the proverbial swimming pool.
 
 
Miko
 

	-----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