This is why I'm not a big fan. This just reads like adding the word "service" into each layer actually makes it service oriented. The mixture of group areas and very specific process elements (which are really capabilities) just blurs what is important and creates an EOA (Everything Oriented Architecture) rather than having a consistent mental model that is recognisable at different levels of granularity.
Recommending that Services can in effect be anything you put the word "Service" into doesn't (IMO) help. Steve 2009/10/29 LAWRENCE <[email protected]> > > > We recommend that Services can be both nouns or verbs. > Our layered Service Architecture approach provides for processes, broad > capabilities, entities (which we call Core Business Services), utilities, > underlying, and infrastructure to be provided as services. > > See an example in our wiki > http://cbdi.wikispaces.com/Service+Specification+Architecture > > or Appendix A1 of our CBDI-SAE Meta Model for SOA for definitions of each > type http://www.cbdiforum.com/public/CBDI_SAE_META_MODEL_FOR_SOA_V2.0.pdf > > Lawrence > > > --- In > [email protected]<service-orientated-architecture%40yahoogroups.com>, > Steve Jones <jones.ste...@...> 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 addCustomerForWestCoastDistribution. > > addCustomerforCentralDistribution and > > addCustomerforCentralDistributionToWestCoast. > > > > 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...@...> > > > > > > > > > > > > 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 an > approvePolicy > > > Service, the consumer can simply request that Service with the policy > number > > > of the policy it wants to approve. > > > > > > *Nouns vs. Verbs* > > > The insurance policy example brings up a fundamental question. Which is > the > > > Service, the insurance policy entity or the approve policy task? In > other > > > words, should Services be nouns or verbs? It's possible to design > Services > > > either way, as Entity Services, which predictably represent business > > > entities, or as Task Services, that represent specific actions that > > > implement some step in a process, in other words, verbs. Which approach > is > > > better? > > > > > > If you look at the question of whether Services should be nouns or > verbs > > > from the OO perspective, then Services are little more than interfaces > to > > > objects, and hence it's best to think of Services as nouns and their > > > operations as the verbs. For example, following the OO approach, we > might > > > have an insurance policy object with several operations, including one > that > > > approves the policy, as the following pseudocode illustrates: > > > > > > myPolicy = new Policy (); > > > ... > > > successOrFailure = myPolicy.approve (); > > > > > > The first statement above instantiates a particular policy, while the > > > second one approves it, and returns either success or failure. > > > > > > Now, it is certainly possible to create a Policy Service as an Entity > > > Service that has an approve operation that works more or less like the > > > example above, with one fundamental difference: because Services are > > > fundamentally stateless, you don't instantiate them. Here, then, is > > > pseudocode that represents how an Entity Service would tackle the same > > > functionality: > > > > > > request to create new policy, specifying create policy operation --> > > > Policy Service --> response with policy number 12345 > > > ... > > > request to approve policy 12345, specifying approve policy operation > --> > > > Policy Service --> response with success or failure > > > > > > Note that we're representing Service interactions as input and output > > > messages that contain documents, where in this case, the input > documents > > > specify operations. In this example, there is no object in the OO sense > > > representing policy 12345 and maintaining the state information that > > > indicates whether or not that particular policy is approved or not. > Instead, > > > the underlying Service implementation maintains the state information. > There > > > is only the one Policy Service, and it accepts requests in the form of > XML > > > documents and returns responses, also in the form of XML documents. If > a > > > request calls the create policy operation, then the Policy Service > knows to > > > create the policy, while a request that specifies the approve policy > > > operation follows the same pattern. > > > > > > Note that the fact that the Policy Service has a document style > interface > > > gives us two advantages: first, we can make certain changes to the > Service > > > like adding new operations without adversely impacting existing > consumers, > > > and second, its stateless nature enables asynchronous interactions, > where > > > instead of returning success or failure of the approve request, > perhaps, the > > > Service returns a simple acknowledgement of the request (or perhaps no > > > response at all), and then notifies the consumer at some point in the > future > > > that the policy has been approved, either through a one-way > notification > > > event or possibly as a response to a further query. > > > > > > *Task Services as Verbs* > > > While there is a significant role for Entity Services in SOA, it is > > > important to break free from OO-centric thinking and consider other > types of > > > Services as well that serve other purposes. In fact, there is another > way of > > > offering the same functionality as the Entity Service above where the > > > Services represent verbs rather than nouns, what we call Task Services. > Here > > > is the pseudocode for this situation: > > > > > > request to create new policy --> createNewPolicy Service --> response > with > > > policy number 12345 > > > ... > > > request to approve policy 12345 -- > approvePolicy Service --> response > > > with success or failure > > > > > > In this example, neither Task Service has any operations, but rather > the > > > functionality of each Service is understood from the context of the > Service. > > > After all, what would an approvePolicy Service do but approve policies? > If > > > you read the Process Isomorphism ZapFlash, the benefits of delivering > > > capabilities as Task Services is clear. If you design each Task Service > to > > > represent tasks or subtasks in business processes, then it's possible > to > > > build a Service-Oriented Business Application (SOBA) that is isomorphic > to > > > the process it implements. > > > > > > *Combining Entity and Task Services* > > > A casual reading of the Process Isomorphism ZapFlash might lead you to > > > think we were suggesting that all Services should be Task Services. > However, > > > in spite of the fact that architects with OO backgrounds often rely too > > > heavily on Entity Services, such Services do play a critical role in > most > > > SOA implementations. Remember that in the enterprise context, Services > > > expose existing, legacy capabilities and data that are typically > scattered > > > across different applications and data stores, limiting the > enterprise's > > > agility and leading to high integration maintenance costs, poor data > > > quality, reduced customer value, and other ills all too familiar to > anybody > > > working within a large organization's IT department. SOA provides best > > > practices for addressing such issues by abstracting such legacy > capabilities > > > in order to support flexible business processes. > > > > > > Both Entity and Task Services help architects connect the dots between > > > legacy capabilities on the one hand, and flexible process requirements > on > > > the other, as the figure below illustrates: > > > > > > *Process, Task, and Entity Service Layers* > > > > > > In the figure above, the bottom row contains Entity Services, which > > > directly abstract underlying legacy capabilities. Above the Entity > Services > > > lie the Task Services, which may actually be abstractions of individual > > > operations belonging to underlying Entity Services. The top layer > contains > > > Process Services, which are typically compositions of Task Services. In > > > other words, Process Services are interfaces to SOBAs, and when those > SOBAs > > > are compositions of properly designed Task Services, they will exhibit > > > process isomorphism. > > > > > > The essential question for the architect is which capabilities to > abstract > > > in which Service layer. Take for example the Address Change Task > Service. > > > Changing addresses is a common example of a particularly challenging > task in > > > many large organizations, because address information is typically > > > maintained by different applications and data stores in a haphazard, > > > inconsistent manner. To make matters worse, there may be addresses > > > associated with customers, policies, or other business entities. > > > > > > When architecting the Customer Entity Service, the core design > principle is > > > to pull together the various instances of customer-related information > and > > > functionality across the as-is legacy environment into a single, > > > consolidated representation. Such a Service will likely have an update > > > address operation, and the Customer Entity Service's logic will > encapsulate > > > whatever individual queries and API calls are necessary to properly > update > > > customers' addresses across all relevant systems. > > > > > > The Address Change Task Service, then, abstracts the Customer Entity > > > Service's update address operation, as well as whatever other address > change > > > operations other Entity Services might have. The Service logic behind > this > > > Task Service understands, for example, that insured properties in > polices > > > have addresses and customers have addresses, and these addresses are > related > > > in a particular way, but are by no means equivalent. > > > > > > *The ZapThink Take* > > > As is usually the case, architects have several options at their > disposal, > > > and knowing which option is appropriate often depends on the business > > > problem, an example of the "right tool for the job" principle. If the > > > business problem is process-centric, say, a need to streamline or > optimize > > > the policy issuance process, then implementing SOBAs as compositions of > Task > > > Services will facilitate process flexibility. In other cases, the > business > > > problem is more information-centric than process-centric, for example, > > > putting consolidated customer information on a call center rep's > screen. In > > > such instances the architect's focus may be on an Entity Service, > because > > > the rep is dealing with a particular customer and must be able to > interact > > > with that customer in a flexible way. > > > > > > The big picture of the SOA architect's challenge, of course, is > delivering > > > agility in the face of heterogeneity. On the one hand, the IT shop > contains > > > a patchwork of legacy resources, and on the other hand, the business > > > requires increasingly agile processes. Understanding which capabilities > > > belong in Entity Services and which belong in Task Services is a > critical > > > part of the best practice approach to SOA. > > > > > > > > > > >
