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