[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opacity calumny
Frank, To agree even more violently, this raises (and I allude to a little in the draft) the question of how to provide a means to publish metadata as it is found to be needed but in a way that supports a consistent use of the metadata in evaluating an entity against unambiguously stated a/c/p, which themselves can be augmented and will evolve to meet business needs of the users (where if I am a design engineer, my business need is to find the technically correct solution engine). This represents a much ignored need as well as a terrible run-on sentence. :-) Ken At 04:10 PM 7/11/2005, Frank McCabe wrote: >Ken: > > I think we are in violent agreement. The essence of the Java >execution engine example is that it is precisely that the >implementation is important -- not whether or not its good style!! > > Incidentally, if it is important to know who wrote the >implementation, then that too should be part of the public description. > > Perhaps another aspect concerns the on-the-wire vs. resource model >of service semantics. In the resource pov, issues of implementation >(transparent or otherwise) figure prominently. In the on-the-wire >pov, you only look at the message traffic; and do not even consider >the implementation. > > They are related of course: a message is valid if it is well formed >(in some communication language) and if the implied predicate is >satisfied (there really is money in your bank account). > > But, a Service Oriented Semantics (SOS) would focus on the on-the- wire > interpretation and require that the service participants >faithfully reflect the messages in their systems. I.e., it is similar >to the model/proof theory distinction: provided that the service >implementation is a correct Interpretation of the communication, the >participants can focus on the Formulae being communicated. > >That all being said, there are definite limits to descriptions. I.e., >there will always be unstated (unstateable?) assumptions that are >required to be shared for successful interactions. > >Frank > >On Jul 11, 2005, at 12:49 PM, Ken Laskey wrote: > >>Frank, >> >>Opacity/transparency is not a dimension on which to distinguish >>services; it is more of a fallacy that we may need to explain our >>way around. This ties in very much with what I've tried to say >>about metadata and how metadata characterizing an instance is often >>the basis upon which the instance is evaluated in the context of >>assumptions, constraints, and policies (a/c/p) of providers and >>consumers. In some circumstances, the amount of information that >>needs to be published about an entity may maintain little in the >>way of its opacity, but that is more likely related to a/c/p than >>it is to WSDL. >> >>See more inline. >> >>At 03:23 PM 7/11/2005, Frank McCabe wrote: >> >>>I read the revised section on services. And an issue that made me >>>uneasy before has resurfaced -- about opacity. >>> >>>I think that the opacity/transparency dimension is not a good basis >>>for distinguishing services. I am aware of the intuition: that >>>somehow when you use a service you should not have to worry about the >>>implementation. But what does it mean to say: "the implementation is >>>hidden from the service consumer"? If the service is to add lists of >>>numbers then its implementation is hidden provided numbers are added >>>up correctly. (I.e., we should not care about whether its in C++ or >>>C#; multi-threaded or federated). >> >>So here the service adds numbers and while we can imagine what is >>happening, we care no more of the specific than we do when we punch >>numbers into a calculator. >> >> >>>But, some services are explicitly about implementation issues: >>>security services, workload distribution services, java remote >>>execution engine services etc. etc. I.e., it is of the essence that >>>to use a Java remote execution service, you have to send it a java >>>class to execute. In that sense, the implementation is critical. >> >>But you call a java remote execution engine when you have an >>appropriate java class to execute. If it is a general service that >>is implemented as a java remote execution then the WS interface >>should more likely be a collector of information that (inside the >>service) is rewritten as the necessary java class. You could >>require a java class as input but I'm not sure that would be >>considered "good style". >> >> >>>A clearer distinction is public/private. A service is characterized >>>by a public description of its functionality. The public description >>>should be sufficient to be able to successfully interact with the >>>service; and no additional information should be required. >> >>Not really because what you consider part of the private >>information I might consider very pertinent to deciding whether >>your service is suitable for my purposes, i.e. I need it to be >>public. For an extreme example, I used to work for your company >>and I know one of your developers is clearly incompetent and I'd >>never use anything that idiot touched. >> >>The challenge is in defining "should be sufficient to be able to >>successfully interact with the service". I think we need to >>discuss opacity in these terms because it is strongly connected >>with SOA and may be more useful as a vague concept than as an >>absolute measure. >> >> >>>Frank >>> >> >>Ken >> >> >> >> >> >> >>-- >> >>---------------------------------------------------------------------- >>----------- >> / Ken >>Laskey >>\ >> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >> | 7515 Colshire Drive fax: >>703-983-1379 | >> \ McLean VA >>22102-7508 / >> >>---------------------------------------------------------------------- >>------------ >> >> > -- --------------------------------------------------------------------------------- / Ken Laskey \ | MITRE Corporation, M/S H305 phone: 703-983-7934 | | 7515 Colshire Drive fax: 703-983-1379 | \ McLean VA 22102-7508 / ----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]