Chris, SOA business service is the business capability as well as a service is a means of capability is written 3 years ago in OASIS SOA Reference Model standard (which is considered as 'practically useless' because it does not dictate you how to write the code; but it dictates you how to THINK and communicate services BEFORE you writing the code)
I recommend you to look into this standard as well as into the OASIS SOA Reference Architecture, Public Review Draft 2 (should be currently available, or just in a few days, from OASIS ) - Michael ________________________________ From: Chris Deweese <[email protected]> To: [email protected] Sent: Thu, October 15, 2009 9:08:07 PM Subject: RE: [service-orientated-architecture] [ZapFlash] Are Services Nouns or Verbs? That’s some great, practical advice Anne. I found that once I started talking about services as business capabilities, communication between IT and the business became easier. It then becomes simpler to look at the broad capability i.e., policy management, and group the more granular operations with the service/capability they belong to. Good stuff! Chris --- Christopher Deweese Microsoft MVP, Solutions Architect http://christopherD eweese.com/ Twitter: @cdeweese "Architecture is a 12-letter word for planning." -Kshemendra Paul, Federal Chief Architect From:service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Anne Thomas Manes Sent: Thursday, October 15, 2009 6:37 AM To: service-orientated- architecture@ yahoogroups. com Subject: Re: [service-orientated -architecture] [ZapFlash] Are Services Nouns or Verbs? I concur with Steve. But let me elaborate a bit more on the noun versus verb idea. ZapThink equates "noun" to "entity". In some cases I recommend building services that represent entities. But most often I recommend building services that represent capabilities, which are nouns. Which brings us around to a discussion of granularity. In the ZapThink example, the service capability should be "policy management". "approvePolicy" is too fine-grained to be a service. It might be an operation in the policy management service. But I strongly discourage the idea the a service should be defined (as a rule) at the level of granularity of a business process task. Services implement capabilities (nouns). Business processes use those capabilities. But the relationship is not one-to-one. Anne On Thursday, October 15, 2009, Steve Jones <jones.steveg@ gmail.com> wrote: > > > > > > > > > > > > > > > > > > > -1 million from me. > > Creating "Task" based "services" which represent a single action is not SOA. > Back to the SOA RM. The CAPABILITIES are the things that do the real world > effect while the SERVICE provides the mechanism of access. A Service > therefore contains ONE OR MORE Capabilities. > > Its absolutely nothing to do with OO and everything to do with IT folks not > actually knowing that when a Business says Process they are not always > talking about a series of linear steps. Concepts like value networks and > high-level processes like "Shop" are the BUSINESS map around this. BPEL/BPMN > and other TECHNOLOGY solutions are IT implementation elements for a certain > subsection of problems. > > Everything in this post is about technology implementation and none of it > (IMO) is about Business Architecture. > > To be very clear from my perspective (and taking into account that I've just > flown from the UK and done a full days work in Australia) I'm not thinking > about OO in any way shape or form when I talk about Services containing > capabilities and the capabilities being the elements that MAY be IMPLEMENTED > via a Process and that the SERVICE is the mechanism via which a Process > IMPLEMENTATION can invoke another Capability which may, or may not, be > IMPLEMENTED using a process technology such as BPEL. > > From bitter, bitter experience I've found that a process driven way of > defining services ends up with poor processes that tend to bleed across > organisational boundaries which thus become cumbersome and difficult to > change. It also leads to a profusion of services which a tightly bound to a > given process context and thus results in a proliferation of services with > names like addCustomerForWestC oastDistribution . addCustomerforCentr > alDistribution and addCustomerforCentr alDistributionTo WestCoast. > > Define your BUSINESS services, then decide on the right technology to > implement the CAPABILITIES of the business services. If this means you have > a profusion of Web Service interfaces because your BPM tool has a 1-to-1 > mapping of WS-to-BPEL then its a bugger but you still have the containing > conceptual business service to provide the governance and consistency to > ensure that proliferation is managed within the right context. > > The people who drive "service" definition from process tend to be people who > see technology as a stack with Business Process at the top. This is a > marketing exercise from the vendors not a representation of how business > actually operates. > > Steve is now going to sleep > > 2009/10/14 rschmelzer <rschmel...@zapthink .com <javascript:_ e({}, 'cvml', > 'rschmelzer@ zapthink. com');>> > > > > > > > > > > > > > > > > > > > > Are Services Nouns or Verbs? > Document ID: ZAPFLASH-20091014 | Document Type: ZapFlash > By: Jason Bloomberg | Posted: Oct. 14, 2009 > > > ZapThink revels in stirring up controversy almost as much as we enjoy > clarifying subtle concepts that give architects that rare "aha!" moment > as they finally discern the solution to a particularly knotty design > problem. Last month's Process Isomorphism <http://www.zapthink .com/report. > html?id=ZAPFLASH -2009915> > ZapFlash, therefore, gave us a particular thrill, because we received > kudos from enterprise architects for streamlining the connections > between Business Process Management (BPM) and Service-Oriented > Architecture (SOA), while at the same time, several industry pundits > demurred, disagreeing with our premise that Services should correspond > one-to-one with tasks or subtasks in a process. Maybe we got it wrong, > and inadvertently mislead our following of architects? Or perhaps the > pundits were off base, and somehow ZapThink saw clearly a best practice > that remained obscure to other experts in the field? > Upon further consideration, the true answer lies somewhere in > between these extremes. Now, we're not reconsidering the conclusions of > the Process Isomorphism ZapFlash. Rather, further explanation and > clarification is warranted. As with any best practice, Process > Isomorphism doesn't apply in every situation, and not every Service > should correspond to a process task or subtask. That being said, there > is also a good chance that some of our esteemed fellow pundits might > not be opining from a truly Service-oriented perspective, as many of > their comments hint at an object-oriented (OO) bias that may be too > limiting in the SOA context. In fact, understanding which Services the > Process Isomorphism pattern applies to, and how other Services support > such Services goes to the heart of how to think about Services from a > SOA perspective. > > > The Object-Oriented Context for Services > In the early days of > Web Services, as various standards committee members tried to hash out > how core standards should support the vision of SOA, the SOAP standard > for message transport was an acronym for the "Simple Object Access > Protocol." The reasoning at the time was that Services were interfaces > to objects, and hence Service operations should correspond to object > methods, also known as remote procedures. SOAP was nothing more than a > simple, XML-based way of access those methods. Over time, however, > people realized that taking this Remote Procedure Call (RPC) approach > to Service interfaces is too limiting: it leads to tightly coupled, > synchronous interactions that constrain the benefits such Services > could offer. Instead, the industry settled on document > style <http://www.zapthink .com/report. html?id=ZAPFLASH -2006712> > as being the preferred interface style, which expects requests and > responses to conform to schemas that are included in the Service > contracts by reference, where the underlying Service logic is > responsible for validating interactions against the relevant schemas. > Document style interfaces provide greater loose coupling than > their RPC-style cousins because many changes to a Service need not > adversely impact existing Service consumers, and furthermore, document > style interfaces facilitate asynchronous interactions where a request > need not correlate immediately with a response. In fact, the W3C > eventually dropped the "Simple Object Access Protocol" definition of > SOAP altogether, and now SOAP is just SOAP, instead of being an > abbreviation of anything. > However, document style interfaces still allow for operations, > only now they're optional rather than mandatory as is the case with > RPC-style interfaces. The fact that operations are optional is a > never-ending sense of confusion for students in our Licensed ZapThink > Architect <http://www.zapthink .com/eventreg. html> > course, perhaps because of the object-oriented pattern of thinking many > of today's techies follow, often without realizing it. How would you > ever know what a Service is supposed to do, the reasoning goes, if you > don't call an operation on that Service? The answer is straightforward: > if a Service has no operations, then what it's supposed to do is > understood from the context of the Service itself. For example, an > insurance company may want a Service that simply approves a pending > insurance policy. If we have a > > > > > > > > > > > > > > > > > > > > > > >
