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
***********
