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

[Ken Laskey <klaskey@mitre.org>]

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.

> 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.)

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

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

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

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

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

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