RE: [soa-rm] SOA Definition - the graphic

["Duane Nickull" <dnickull@adobe.com>]

I would like to request any further input on this prior to the editors
meeting next week.  

Also - PLEASE get your comments in on 09 by Friday at the latest (now is
better) so Don can format them for the meeting.

Duane

-----Original Message-----
From: Francis McCabe [mailto:frankmccabe@mac.com] 
Sent: Thursday, October 06, 2005 10:45 PM
To: Ken Laskey
Cc: SOA-RM
Subject: Re: [soa-rm] SOA Definition - the graphic

Hey ho ...

On Oct 6, 2005, at 8:59 PM, Ken Laskey wrote:

> and we're off,,,
>
> On Oct 6, 2005, at 9:44 PM, Francis McCabe wrote:
>
>
>> Well, here goes ....
>>
>> 1. There is something fundamentally unknowable about the acted  
>> upon resources.
>>
>
> The only thing known about it is what is expressed about it through  
> the service description.  That description, of course, could simply  
> reference the metadata of the resource itself.  Alternately, the  
> service description may say nothing about the resource, but that  
> does not mean the resource does not exist.

There are plenty of services for whom it is not possible to properly  
characterize a resource. A simple example is a service that performs  
encryption -- it operates on messages without taking anything else  
into account.

Another example is a broker acting on behalf a dynamically varying  
set of clients. (Its possible to set it up so that the description of  
this *resource* will take longer to parse than using the broker.)  
There might be a database that the broker relies on, but that  
database is none of anyone else's business.

Another example is the ATM: it offers a service; that service is a  
conduit to the bank which has its own service. When someone uses an  
ATM are they using its service or the bank's? The ATM may not know  
which banks it can deal with -- it just knows someone who knows  
someone who might know.




>
>
>> Certainly the user of a service never gets to see this. But even  
>> the service provider will often have a hard time pointing to this.
>>
>>
>
> I would be uncomfortable using a service where the service provider  
> didn't understand the underlying resource.  I had a situation with  
> an auto loan where the loan company plugged numbers into a GUI but  
> had no idea what was being calculated.  They got an answer and were  
> very satisfied even though the answer was wrong.  I tried to  
> explain the algorithm to them but they were so focused on the GUI  
> that showed an answer that they couldn't understand they needed to  
> solve a different problem.  Make the GUI a WSDL and I could have  
> said they were misusing the service because of ignorance of the  
> underlying resource.  (BTW, I refused to pay further on the loan  
> and many years later they simply gave me the title.)
>

I was not referring to this kind of ignorance. I was trying to  
capture the case where the resources that are referenced in a service  
invocation are inherently dynamic and -- for practical purposes --  
not easily described.



>
>>  If you are updating a database, but the database is replicated,  
>> then which is the resource that you are modifying in response to a  
>> service request?
>>
>
> I don't think I could come up with a better example to illustrate  
> why remembering the underlying resource is important.  What is the  
> latency for replication?  When you modify something, what are you  
> modifying?  When you go back later, what are you going back to?

Well, the computational mechanism that delivers a service may be  
relying on a distributed web of resources that includes replicate  
databases; so that no description is stable long enough for it to  
have currency.

This is not a theoretical toy -- its actually how some large  
Enterprise systems are set up to operate. Database replication was  
perhaps too simple a scenario.

But even there, consider the airline case. You book a ticket. The  
database gets wiped clean by a virus. Do you still have a ticket? Of  
course you do; it is not the customer's fault the airline was cheap.

I would be equally unhappy as you were with your experience with the  
car loaners if United told me that because I wasn't in their database  
I didn't have a seat. I am sure that that is one reason why people  
were hesitant about using eTickets: they didn't quite trust the  
airline's databases. Its also why its always a good idea to bring  
along paper documentation of your eTicket.

That means that there is something deeper going on when you use a  
service than manipulating resources.

This whole thing was one of the trout ponds in the W3C -- when the  
WSDL WG wanted to include a reference to *the* resource in the  
service description.

>
>
>> What happens if you swap one database out for another? There are  
>> more examples here; but the essence is that it can be extremely  
>> difficult to pinpoint the resource.
>>
>>
>
> Indeed, the examples are endless and can be more disturbing.  The  
> intent is to raise awareness that there is a resource and to allow  
> that providing some level of transparency to the resource may be a  
> policy condition.  Thus, pinpointing the resource is a possible  
> need, not a requirement.
>
>
>>  On the other hand, its not necessary, so why bother?
>>
>>
>
> I think you've ably demonstrated how necessary the concept is and  
> why someone MAY want information (metadata?) on the resource to be  
> available.
>
>
>> 2. There *is* something else that is both measurable and more  
>> important: what can we expect as a result of a service interaction.
>>
>>
> Definitely needed and definitely needs to be verifiable/measurable  
> but not sure at the present stage of technology that it will be  
> machine readable.

Not all descriptions are machine readable. But communications are  
inherently more measurable than resources.

>
>
>>  To fully capture these expectations will, I believe, require a  
>> grounding in the philosophy of signaling systems. However, from a  
>> simplistic PoV, you can think of the owner of the service making  
>> commitments to future actions as a result of service interactions.  
>> (Well, both the owner of the service and the owner of the service  
>> using agent.)
>>
>>  I.e., a service is better viewed as a communications vehicle by  
>> which service providers and consumers can exchange future  
>> commitments; these themselves being expressed often as further  
>> communications.
>>
>>
> That last seems one leap of faith too far.  The effect of using a  
> service can be an exchange of information, and in fact one can  
> argue such an exchange defines a service if you think of messages  
> being the primary information exchange of SOA.  However, if service  
> is the communications vehicle, then service becomes the pipe rather  
> than the fitting bound to one end.  I don't think that will fly.   
> The service is intrinsically bound to one end (i.e. the resource)  
> and different consumers bind to that.  I don't have a different  
> service if I have a different consumer but I do (should?) have a  
> consistent resource if I'm using the same service.

That assumes that there is a one true resource at the end of the  
service. I don't that that generalizes.

>
>
>> 3. Why do I bang on about this? Because I have seen some scenarios  
>> where the simple resource model doesn't capture what is going on  
>> and because the communications perspective *does* capture it.
>>
>
> Can you give some examples?

see above.
>
>
>> Also, while a service owner might not be a fundamental concept of  
>> the RM (it got voted down); it is still there for 99.99% of  
>> business owners :)
>>  The only negative I can see for the communications perspective is  
>> that it can be harder to grok.
>>
>>
>
> I am always uncomfortable with people harping on the 80-20 solution  
> because that other 20 can spell disaster.  OTOH, a solution that is  
> a bit more robust but cannot readily be grokked by a large portion  
> of the audience is of less value than a solution which is more  
> easily understood but less complete.

Well, people seem to grok pi-calculus ;-) That is of the same order  
of complexity as communications based semantics. But I digress.

Essentially my point is this:

1. Although appealing at first, the view of services manipulating  
resources does not even make it to the 80-20 level. There are too  
many situations where it is either impossible to characterize the  
resource or meaningless to do so.

2. The view of semantics couched in terms of expected communications  
can capture the resource manipulation case. It can also capture the  
cases where the resource is less obvious.

3. It is more symmetric with the service interface description --  
which can be seen as expectations *going in* to use a service -- and  
results -- which are expectations *going out* of using a service. The  
same kinds of descriptions that define what you need in order to use  
a service are good for describing the future communications.

4. Finally, it is an interesting thought experiment to 'follow' an IP  
packet as it makes its way from one Java program to another Go!  
program. At each stage there is a communication of data from one  
location to another:

a. The character gets copied into a buffer.
b. The buffer is partitioned into fixed size blocks.
c. The buffer data is copied into an operating system memory block.
d. The memory block is latched onto another memory block, which  
happens to have two readers: the CPU and the network adaptor.
e. The wires between the network adaptor and the router hum briefly.
f. More memory shuffles occur within the router/switch
g. ....
z. A character gets taken out of a buffer in another place.

If you look carefully, its actually quite difficult to *see* the IP  
packet moving; because at every stage it is different data that is  
being copied from place to place -- literally different data as the  
bit pattern on the Ethernet is often in a different form at the  
different places.

However, it turns out that the most practical conceptualization of  
this is as a moving packet of data. But that is an interpretation we  
use to simplify our lives -- data cannot actually move: the pattern  
can only be copied and transformed in various ways.

We call a system function -- send -- and somewhere else another  
system function -- recv -- and auto-magically the pattern we receive  
has a strong relationship to the pattern we send.

Frank

>
>
>> Frank
>>
>>
>
> Ken
>
>
>> On Oct 6, 2005, at 12:57 PM, Duane Nickull wrote:
>>
>>
>>
>>
>>> Let the flames begin....
>>>
>>> *******************************
>>> Adobe Systems, Inc. - http://www.adobe.com
>>> Vice Chair - UN/CEFACT
>>> Chair - OASIS SOA Reference Model Technical Committee
>>> *******************************
>>>
>>>
>>> <SOA-RM-Model-August2005.png>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>