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>
