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

[Francis McCabe <frankmccabe@mac.com>]

Ken:
  Thanks for the thoughtful response.
  However, it still doesn't quite get my point.

  I think that *any* talk of resources is implementation talk. In  
order to deliver a service will require resources -- let us eliminate  
empty cases.
  But, to go on from that and declare that services are waldoes for  
resources loses too much.
  Focusing on the Airline example, as a customer I might imagine that  
United requires resources to fulfill its commitments; but frankly I  
don't care -- United's resources are not part of my mental space. If  
I am writing a Java program to use United's service, those resources  
have no echo in my program unless forced to by United's service  
protocol.
  The same applies to the matrix example: as a consumer I will  
measure the result by correctness and cost; not in terms of what  
algorithms were used. (There *are* cases when the algorithms/ 
implementation are of the essence; but that is another story.)
  Notwithstanding the nods of understanding around the 'waldo' view  
of services, it is fundamentally at odds with the business  
perspective. IT folk know about and are happy with SQL and Databases;  
business folk have an allergic reaction to that stuff. On the other  
hand, commitments and requests are something that BP (Business  
People) understand (more of the latter than the former at times) (and  
I have witnessed allergic reactions to these concepts from IT folk of  
course).

  We may never be able to square this circle.

  For the record, if you are going to go into implementation, then I  
prefer the agent perspective: a service is realized by an agent that  
entertains requests and makes promises -- mediated by a  
communications medium.
  The merit of that conceptualization is that it makes a very clear  
line about what is opaque and what is transparent -- it is not fuzzy  
or graduated. And that, in turn, leads to scalable systems.
  Of course, you might argue that agents are also implementation  
techniques -- and I'd agree. There may be more though, because there  
is the concept of ownership. Before you can effectively talk about  
commitments, you have to talk about ownership and responsibility.  
That is too far I suspect, but I am confident that we will get there  
in the end!

  Your <epiphany> seems to poke at a different problem; what I was  
trying to get to when I said that resources were essentially unknowable.

  Anyway, have a good w'end, see you Tuesday.
Frank


On Oct 15, 2005, at 5:53 PM, Ken Laskey wrote:

> Well, it's time to focus again in preparation for the editors  
> meeting, and I find I never finished the last response I started on  
> this.
>
> Note, as I was composing this, I think I understood the disconnect  
> in our previous discussions.  Besides the other responses, see  
> <epiphany> somewhere below.
>
> Here goes...
>
> On Oct 7, 2005, at 1:44 AM, Francis McCabe wrote:
>
>> 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.
>
> Which resource are we talking about here?  One can look at the  
> message being encrypted as a resource being acted upon but that is  
> separate from the resource/capability that does the encrypting.   
> The service delivers a package to be encrypted to the encryption  
> capability (likely existing independently from the service) and it  
> is up to the policies of the service (where the service policies  
> may also reflect some subset of capability policies) to specify  
> what about the input package needs to be specified.
>
>>
>> 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.
>
> Frank, we keep coming back to the same point:  there is a  
> capability underlying the service and in the most idealized service  
> situation the service completely hides the capability.  However,  
> that does not mean the capability does not exist and it does not  
> mean in real use there will not be times when the consumer will  
> explicitly want/need to know something about the capability.  (My  
> apologies to Joe for all the double negatives, but I do believe I  
> got them right.)  I once complained about an early spreadsheet and  
> said it was easier writing my own custom application.  In response,  
> I was asked if I also wrote my own compiler because obviously there  
> were times the commercial compiler didn't do exactly what I  
> wanted.  OK, there gets to be a point where you stop asking  
> questions about what is in the next level down, but the limits to  
> those questions are up to the service users (likely through their  
> stated policies) and not for me to limit in the RM.
>
>>
>> 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.
>>
> I think this is addressed in the ATM example in section 2.2.2.2
>
>>
>>
>>
>>
>>>
>>>
>>>
>>>> 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.
>>
> Then my description is that the service makes use of a variety of  
> capabilities and, if necessary, the description can include some  
> information on which capabilities could possibly be used and how a  
> decision is made among the alternatives.  The point is that the  
> more dynamic the service, the more a careful consumer will want to  
> know whether the logic of the service is consistent with the  
> choices the consumer would make.  Again, description/metadata  
> serves a context and while I agree there are times when detailed  
> description does not make sense for certain aspects of the system,  
> I cannot impose those limits at the RM level.
>
>>
>>
>>
>>>
>>>
>>>>  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.
>
> I would consider what you just said (perhaps with a few more  
> details) to be an adequate description.  (But I'm easy to  
> satisfy ;-) )
>
>>
>> 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 only have a ticket to the extent I can show a receipt and insist  
> they honor it, but that goes beyond SOA.
>
>>
>> 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.
>
> I think the "deeper" is the entire context of policies and  
> constraints in which you operate.  This gets back to having a  
> fuller discussion of "execution context" but that is another topic  
> to work out.
>
>>
>> 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.
>>
> Hmm, I'd be interested to know what they had in mind by resource.   
> If you are saying that when I invoke a service I may get  
> information from any number of databases, then I would say the  
> resource is the logic that decides among the database alternatives  
> and combines information retrieved from some combination of these  
> databases.  I do not intend to say that I am tracking the data back  
> to its primary source (say, a sensor in the field) but I will also  
> not say that there is not a user who will want/need that kind of  
> information.  (Dang those double negatives again!)
>
> <epiphany>
> Reading further down, I think I'm beginning to understand our lack  
> of convergence.  If a service always retrieves information from one  
> single database, the underlying capability/resource is the database  
> and the service probably has some SQL interactions with the  
> database, but we agree the details of the interaction are not  
> important.  Now, let's say there are two databases and my business  
> logic is to retrieve information from the database that was updated  
> more recently.  What are my resources?  Well, I would say I have  
> three resources at two different levels.  The immediate resource is  
> some entity that encapsulates the decision logic (here quite  
> simple) and the second level is the two databases.  But I can  
> easily say there is a third level which is the source of  
> information that goes into the database, and depending from where  
> that source gets information, possibly a fourth or deeper levels.   
> MUST the service describe all of these?  I would say no, partly  
> because I may not be able to trace all the levels (a point you are  
> making), but some users MAY require information about more levels  
> than other users.
>
> Let's try another example.  There are a number of matrix  
> multiplication algorithms, each optimized for different matrix  
> content, e.g. sparse matrices or diagonal matrices or matrices that  
> are guaranteed not to have complex numbers.  Independent parties  
> have implemented these algorithms in separate software  
> applications, where some of the applications require as input a  
> compressed or optimized representation of the matrices.  Further,  
> service providers have created services as a means to invoke the  
> various applications.  Let's assume there is one service  
> corresponding to each application.
>
> At this point, I would say that for each service, its underlying  
> capability is the respective software application it invokes.  (See  
> *** below for more thoughts on this, but for now, just keep reading.)
>
> Now, I decide to create a general service to accept any matrices  
> fully written out (i.e. with all the entries in its rows and  
> columns) and the result of invoking this service will be (1) the  
> input matrices are analyzed and the optimum matrix multiplication  
> algorithm will be identified, (2) the appropriate algorithm service  
> will be invoked that will return the result of the matrix  
> multiplication, and (3) the result will be returned to the user.   
> What is the underlying capability/resource for this service?  I  
> would say it is the entity that encapsulates the logic to perform  
> (1), (2), and (3).  Part of the service description MAY be to note  
> that invoking this service may result in using any of a number of  
> algorithms and the description MAY note something about analyzing  
> the input matrices.  It MAY note the individual algorithm services  
> that could be invoked, but I think this is unlikely.
>
> The service can remain the same over time while the underlying  
> capability changes.  For example, the underlying capability may be  
> changed to invoke a new service for one of the previously  
> documented matrix multiplication algorithms, and neither the  
> service nor its description would need to be changed.  Or, the  
> underlying capability may add use of a new matrix multiplication  
> algorithm.  In this case, the service would not change, and the  
> service interface would not change, but the service description  
> would be modified as necessary to note the new algorithm.
>
> *** Now for the further discussion on what is the resource.  Even  
> with a single service for a single application for a single  
> algorithm, I can see an argument for the paper documenting the  
> algorithm to be another level of resource.  Let's try to deal with  
> this quickly.  Identifying deeper levels of resources is like  
> defining metadata: you identify what is needed for your context and  
> appreciate there is no way in general to include all possible  
> contributing resources.  If it is enough for you to know I provide  
> a service that will return you the product of two matrices, then  
> that may be the complete extent of the service description.  If you  
> want to know what algorithms may be used by invoking my service, I  
> can give you a list as part of description.  I may or may not  
> provide references describing the algorithms.  That is up to me as  
> the service provider dealing with the demands of the potential  
> consumers of my service.
> </epiphany>
>
> Does that get us any closer to a common concept of capability/ 
> resource?  Part of my angst is that I really believe there is a  
> useful distinction and part is that I see the building of service  
> stovepipes if the capability is subsumed into the concept of  
> service because the entire idea of reuse of non-service  
> capabilities is lost.
>
>>
>>>
>>>
>>>
>>>> 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.
>
> Still have trouble with the communications perspective but does  
> <epiphany> address this?  The service description captures the  
> commitments that should be realized if the service is invoked.   
> There may be reciprocal commitments promised by the service  
> consumer -- this is all established in the execution context.  The  
> service is the trigger for action; the capability implements the  
> action.
>
>>
>>
>>>
>>>
>>>
>>>> 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.
>
> see <epiphany> for what I'm trying to characterize.
>
>>
>> 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.
>>
>
> Semantics exist outside of services.  Semantics are used by  
> services (and resources/capabilities) but are not created by them.
>
>> 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.
>
> Again, I see this as a description of the execution context.  I can  
> see situations where the same services are invoked but all the  
> commitments/expectations are not identical.  This would happen if a  
> given service is not affected by a given constraint but the users  
> would not otherwise agree to the execution context if the  
> constraint was not mutually accepted.
>
>>
>> 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.
>
> This seems more akin to moving a blown up balloon in that I am  
> moving a set of molecules but the molecules in the balloon  
> certainly rearrange during the time I move the macro-package of the  
> balloon.  I think your example best describes the molecules while  
> the service is at the level of the balloon.
>
>>
>> Frank
>>
>
> I get nods when I talk about a service accessing/reusing a  
> capability and the balancing of policies as forming an execution  
> context (especially when there is a third party imposing  
> conditions).  I want to make sure if I replace those that I won't  
> lose the nods.
>
> Ken
>>
>>>
>>>
>>>
>>>> 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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
> ---
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:        703-983-1379
> McLean VA 22102-7508
>
>
>