[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] service composition scenarios
Hi Christopher: I would rephrase this as "One of many intents and values of SOA is to enable POA". I do not think it is an exclusive goal of all SOA's. Even though the two circles do not overlap, if you described the entire architecture represented, I believe you could make a statement such as " This architecture concurrently embraces SOA and POA concepts" (Qualifier: Based on our current understanding of these things). I agree with your axiom "You can have SOA without having POA" and believe the inverse is true. I would request that you add this axiom to the "Relationship to POA" section of the strawman on the wiki (it is non normative near the end). We do need to discuss further. Completely agree. I think we have just scratched the surface. Maybe after we finish the SOA RM, we should start another TC to work on a POA RM ;-) Christopher Bashioum wrote: >Duane, > >The ultimate intent and value of SOA is to enable POA. My concern here is >that if we separate the POA out of the SOA, we remove the intent of SOA. >Since SOA is really more about an orientation applied when architecting, >removing the intent is removing the heart from SOA. > >I see that your picture states that the two can exist concurrently, but >because they are separate circles implies that they can also not exist >concurrently. I.e., you can have an SOA without having a POA. > >Maybe what you mean by POA is a more concrete "thing" (i.e., POA is an >orchestration engine added to an SOA), in which case I'm fine with what you >propose, but if I do understand it correctly I think we need to discuss >further. > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: Wednesday, April 20, 2005 7:07 PM >Cc: SOA-RM >Subject: Re: [soa-rm] service composition scenarios > >Frank: > >This is how I see the distinction and relationship between the two. > >Duane > >Francis McCabe wrote: > > > >>It seems that you see this as an atoms and molecules distinction. I >>can see that that would make sense. >> >>On the POA front, that is a new distinction to me. I always assumed >>that SOA was equivalent to POA; but I am willing to be educated! >> >>I agree completely that >> >>"a service should not care whether it is being consumed as a single >>service or as part of some process. " >> >>Why I think we might need to embrace POA is to be able to account for >>service intermediaries. >> >>On reflection, I would agree that the WSA is much more a POA than a SOA >> >>Frank >> >>On Apr 20, 2005, at 2:43 PM, Duane Nickull wrote: >> >> >> >>>Frank: >>> >>>I think I understand your point of view now. The scenario you >>>describe above sounds similar to how I interpret Martin's process >>>management concept. We wrote an architectural pattern for process as >>>a layer over top of SOA to illustrate that service consumers may >>>consume more than one services as a functional work unit. There were >>>two basic patterns for consumption of multiple services - serial and >>>parallel. (see attached). >>> >>>The basic premise is that each service is an autonomous, oblivious >>>atom. The layer of logic that maps out the >>>orchestration/choreography/rules of consuming more than one service >>>is the "POA" concept. This equates to the process management concept >>>Martin referred to. From a services perspective, I submit that a >>>service should not care whether it is being consumed as a single >>>service or as part of some process. There is no distinction that the >>>service itself has to be aware of. Note: If a service is to be used >>>as part of a process involving serial or parallel consumption of >>>multiple services, AND there is some sort of ACID policy, the service >>>probably needs to have functions for both "put()" and "commit()". >>> >>>This would be in alignment with the W3C WSA and WS* architecture. >>> >>>I can see that there is an open question regarding the scope of SOA. >>>Does it include the service consumer (either normative or in a non >>>normative manner). If it does, should the concept be discussed since >>>process management is part of the service consumers functionality, >>>not the service itself. My taking is that for the SOA Reference >>>model, this is probably out of bounds, but still open to discussion >>>on this matter. I think that this is probably the basis for a second >>>reference model called Process Oriented Architecture (which suffers >>>from the same ambiguity as SOA due to the multiple perceptions of >>>what it really is. >>> >>>Nevertheless, it may be good to make note of this to help facilitate >>>understanding of how POA relates and dovetails into SOA. I have some >>>axioms in mind: >>> >>>1. Architecture may be both SOA and POA concurrently. (based on our >>>limited assumptions and understanding of what each of those are) >>>2. A service does not need to distinguish from services requests that >>>are part of a process involving more than one service vs. a single >>>call. Any logic, choreography and/or orchestration for "transparent >>>service consumption's" MUST be kept away from the service itself. 3. >>>(however) Services MAY logically be in alignment with the types of >>>services required for a Service Consumer to execute a process >>>involving multiple services, either in parallel or serial invocation. >>> >>>We may need to consider how we can explain this is a section. For >>>now, perhaps it can be added as place holder. >>> >>>My $0.02 CAD worth. >>> >>>Duane >>> >>> >>>Francis McCabe wrote: >>> >>> >>> >>>>Duane: >>>> All your comments are fine. However, there is still the case of >>>>what I have referred to as the "transparent service combination". >>>> In that case, the services are combined, perhaps without the >>>>knowledge of the owners of those services, in a transparent manner >>>>-- where it is obvious that there are component services. >>>> >>>> A transparent service would typically not have a *single* provider >>>>-- or owner. The scenario is something like this: provider A offers >>>>a full meta description of service A, B likewise. A third party >>>>offers a transparent service as a combination of A & B. This third >>>>party need not have any a priori connection to either A or B. >>>> >>>> This is like the difference between a playlist and the MP3 file >>>>itself. The playlist tells you which tracks to play without >>>>embodying the music itself. You can trade playlists, merge them, >>>>etc. independently of the underlying music files. >>>> >>>>Finally, there is another situation. Even supposing the intervention >>>>of an offering agent for a combined service, there are likely to be >>>>cases where the abstraction breaks down -- in error cases for >>>>example. In that case you will get faults along the lines of "you >>>>did not get your book because the Fedex dog ate it" >>>> >>>>Frank >>>> >>>>On Apr 20, 2005, at 12:54 PM, Duane Nickull wrote: >>>> >>>> >>>> >>>>>TC: >>>>> >>>>>Although this may not be part of the core RM, this is probably an >>>>>interesting discussion to have. The concept of service composition >>>>>has been raised a few times on the list. I wanted to state a few >>>>>observations about this concept. Please see attached diagram for >>>>>details. >>>>> >>>>>1. Services are opaque by nature. That means that the service >>>>>consumer cannot see anything beyond the interface (service >>>>>interface) it uses. If one service is actually aggregating two >>>>>other services, the service consumer cannot and should not know >>>>>this. From a service consumers viewpoint, a service is merely an >>>>>agent or interface that offer some function(s). Whether those >>>>>functions are mapped to a set of classes in some native language or >>>>>another service is not important or relevant (other than the >>>>>service metadata stating what invoking the service means or does) >>>>> >>>>>2. The service function (for service A) is described in the service >>>>>description specific to that service. If completing the function >>>>>depends on two or more serial or parallel paths of execution >>>>>successfully completing behind the service interface (like calling >>>>>services B and C) within a certain time frame, that is not relevant >>>>>to state in the service description for service A. The service >>>>>consumer is only concerned with the service's ultimate success or >>>>>failure. Mapping the functionality to success and failure is the >>>>>responsibility of the service provider. >>>>> >>>>>Do you agree with this? This supports the notion of opaqueness. >>>>> >>>>>3. # 1 and # 2 above are mandatory to comply with a services >>>>>autonomous nature as described in the W3C WSA and subsequent >>>>>services architectures. A service alone must determine whether the >>>>>service succeeds or fails. If a service consumer can see any >>>>>specifics behind the service, this violates several of the core >>>>>principles of SOA. If visibility beyond the offered service is >>>>>required, then the service does nor meet the demand of the service >>>>>consumer. Accordingly, the service provider and consumer should >>>>>discuss and re engineer. >>>>> >>>>>When implementing, more complex patterns of service invocation can >>>>>be facilitated while keeping these three axioms. If a transaction >>>>>sequence is needed, a service interface can offer two services - a >>>>>put() and a commit(). >>>>> >>>>>Duane >>>>> >>>>>-- >>>>>*********** >>>>>Senior Standards Strategist - Adobe Systems, Inc. - >>>>>http://www.adobe.com >>>>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ >>>>>Adobe Enterprise Developer Resources - >>>>>http://www.adobe.com/enterprise/developer/main.html >>>>>*********** >>>>> >>>>><compositeServiceA.png> >>>>> >>>>> >>>> >>>> >>>> >>>-- >>>*********** >>>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com >>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ >>>Adobe Enterprise Developer Resources - >>>http://www.adobe.com/enterprise/developer/main.html >>>*********** >>> >>><parallelServicePattern.png><serialServicePattern.png> >>> >>> >> >> > > > -- *********** Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ Adobe Enterprise Developer Resources - http://www.adobe.com/enterprise/developer/main.html ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]