[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]