[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services
The carefulness comes to how many people are trying to speak with the same letters and what the interpretation of those letters are within their vocabulary. Spanish, French and English all use the same letters but do the words mean the same thing? My personal feeling is that the letters need to be formed into a sort of terse word vocabulary that can be the basis of what the service is and what it will provide. It is a very similar process to coming up with a business strategy and probably takes a lot of the same mechanics to define. For example, buy, sell and trade are much more descriptive and constraining than b,u,y,s,e,l,l,t,r,a,d,e (duplicate). I do see where you are going with this, just cautioning the making the reduction stick to the pan so to speak. Here is an example of a terse way to break down an enterprise (such as Coalogic). http://blueprints.jot.com/WikiHome/Eriksson-Penker+based+break-down I used the Eriksson-Penker style diagram to create it. - Dan -----Original Message----- From: Miko Matsumura [mailto:mmatsumura@infravio.com] Sent: Tuesday, November 01, 2005 6:27 AM To: Davies Marc; Duane Nickull; Jones, Steve G; Beack, Theo; Ken Laskey Cc: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services +1 One theme of a talk I am giving lately is about how we describe SOA. When we talk about SOA "Reuse" we are talking about a potential for reuse that is fundamentally unlike what most people think of when they hear that word. For example, I am currently "reusing" the alphabet to write this email. This suggests dynamic and fluid expressions of remote and instantiated services, not of classical class reuse such as OO. In order to achieve such "reuse", there are serious architectural hurdles. At the ground floor, hurdles include things like service description and discovery and interoperability standards. This allows your SOA to make simple two word "sentences" where one service consumes another. As you start to "talk" about subjects that deliver value for your organization (business services), you begin to need things like security and governance. I know these are not well specified, but bear with me. In order to form more complex "sentences" involving business value, you will need to have additional architectural support including a way to manage provisioning, versioning, dependency mapping, service level agreements and probably other things I'm not thinking of presently. Another potentially useful tool at this stage are service contracts, which allow for the externalization of relationship-specific delivery preferences from the services themselves. At the most expressive and dynamic, you most likely will need some kind of business process language, some tooling support and within the domain/organization/contextual frame a level of semantic integrity or a mechanism to achieve semantic integration. Here be some serious dragons. The saving grace is most likely that most organizations can dramatically limit the scope of valid topics and "sentences" which can be built on top of their SOA. Thus instead of being a "semantic web" problem of vast complexity, it becomes more like a problem of plumbing--do the hot and cold pipes fit together? Probably more philosophical than I should get in a "blueprinting" group, but there you are. Best, Miko -----Original Message----- From: Davies Marc [mailto:Marc.Davies@uk.fujitsu.com] Sent: Tue 11/1/2005 5:27 AM To: Miko Matsumura; Duane Nickull; Jones, Steve G; Beack, Theo; Ken Laskey Cc: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints - Number of services 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]