[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [soa-rm] changing shared state to shared view
Sorry about being late in responding but had troubles with accessing the mailing list... Frank, here is what I was talking with you about at OMG... -----Original Message----- From: Dale Moberg Sent: Tuesday, April 18, 2006 11:00 AM To: 'Duane Nickull'; Chiusano Joseph Subject: RE: [soa-rm] changing shared state to shared view Some rejoinders (and agreements) noted below. Not sure that this perfectly conveys the intended point, but let me see if it moves it anywhere closer to a RM generalized in one tiny way... Btw, I see RM issues as tied to what is essential to a concept, as opposed to what is just a frequently found feature of kinds of instances of the concept (the old Aristotelian accidental properties). Duane N. says: In the context of BPSS, perhaps this makes some sense, but in the abstract world of SOA RM, it is flawed. Dale> I don't think that my concern is a RA detail because a prohibition on services disclosing state about managed resources would be an arbitrary restriction to the concept of a service. But maybe so... let me build my case in favor of RM relevance. Duane: Orthogonal to process, managed service transparency conceptually keeps certain details of state hidden and internal to a specific service and known only to the environment behind the service. Dale> I confess to a little uncertainly on how that is to be parsed but I am mostly in agreement that there are many (most) aspects of a service that are and should be hidden and internal. But "many/most" does not add up to "all"; and you must say that all resource details must be hidden and internal to say that conceptually services do not leak information about their state via other services. I recall your fondness for java metaphors. Certainly though there are no friends in java (RA1) as in C++ (RA2), there are distinctions falling between the most restricted and the least restricted-- namely, package private and protected. The details about restricted visibility are certainly architectural detail. The idea of levels of access of member methods or variables is, however, general and found across languages (RAs) (at least within a certain class of languages). In saying there is only the information returned in the signature of the service that is public and the rest is private/hidden/internal, you overlook other approaches to the layering of accessibility. If this is so, it is a flaw within the RM context, and not a matter of specialization in RAs. But perhaps the TC has decided to build all or none accessibility into the idea of a service. I just think that all-or-none accessibility is just one specific version of a more general idea of resource/state/capability accessibility that can have many forms. Duane: Even in the BPSS world, you would be forced to admit that you only should care about the externally visible state properties, given the hidden internal ones are irrelevant if you can never see them anyways. Dale> Partially true, but that means that there are some aspects of resources that are visible and are made visible by other services. Internal ones are not necessarily irrelevant even though they are not displayed in all their specificity. For example, an acceptanceAcknowledgementException may be based on some disk out of space condition that is not revealed. Such a detail does show up in an abstracted away as a technical failure state that is, however, visible in a management level service. Duane: Assuming anything behind a service which has not been exposed is probably not a good practice IMO. You may cite this as flawed but it has also been generally accepted as a principle in WS-*. WS-Coordination, WS-Transaction, WS-ResourceFramework, the idea of an EPR in WS-Addressing, a lot of the grid services management work... We have to disagree here. Also, good practice is RA level description to me. Not sure why this kind of consideration should be raised if this is a RM issue. Duane: This discussion you point at below was recently discussed in great detail within the WS-RX group (which surprisingly was almost exactly the same conversation we had in ebXML messaging about 4 years ago). The question was about message ordering where one philosophy was that the service interface should provide delivery assurances WRT messages being delivered to the application destination in order. This presumed a certain architecture behind a service which is not optimal and actually flies against the general philosophy of SOA/OO et al whereby one should write the interface and not care how the interface is functionally enabled. Yes - as you point out - in certain cases, the service provider might opt to make these things visible, but this is at the discretion of the service provider. When made visible, they are externally visible properties. The internal state may still be different and no one on the outside should ever be the wiser. Dale: Discuss another day. Duane: For lack of a better word, the concept we are trying to capture is the "externally visible properties" of state alignment between consumer and providers. Given this is concrete, it probably will not be resolved in the RM, but probably more relevant to an RA. Dale: I think the concept is a specialization of accessibility to a resource especially when exposed over multiple services. The externally visible realm can, at one extreme, be highly restricted (your buttoned down atomic service interface is one of those extremes). Or the resource can possibly have a debugger service method exposed in which case all the innards are readable and writable (presumably this is a method that is way at the other extreme of accessibility!) In between, there are the multiple-method variously accessible resources in which abstracted aspects of resource state are externally visible). I am not sure that "view" is the correct word. I am sure we will get it sorted. I hope you will consider providing active input on the RA - we could use more people with the depth of experience you possess. Cheers Duane ******************************* Adobe Systems, Inc. - http://www.adobe.com Vice Chair - UN/CEFACT http://www.uncefact.org/ Chair - OASIS SOA Reference Model Technical Committee Personal Blog - http://technoracle.blogspot.com/ ******************************* -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Wednesday, April 12, 2006 10:45 AM To: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org Subject: RE: [soa-rm] changing shared state to shared view Duane writes: "State alignment is flawed IMO. You cannot see past the interface therefore how do you know (or why care) that someone's state is aligned with yours. As long as the externally visible properties are synced with your requirements, you should not care what their actual state is." BPSS modeled some open-edi and RNIF ideas that assume layering of message processing. There are several layers of interfacing defined, and not one monolithic layer called overall "service" So your reasoning starts out from a false premise: you can see behind "the interface" to higher layers. For example, if signals for AcceptanceAck and AcceptanceAckException are used, then there is a layer at which the validity of the request is acknowledged (from the standpoint of it being one for which some response is to be performed). Because the backends for the responding long-running processes often optimize after all orders are in (and do not merely use greedy algorithms) for resource utilization decisions, there is a separation of process into stages/layers each of which can be conducted somewhat independently. You may insist that architectures "should not care about intermediate processing stage decisions," but that will fit only a certain class of processing architectures. I personally think SOA-RM should describe situations where intermediate states can be accessed (status services, forward progress services, etc) that are possibly of interest to the requesting process making use of the entry point service. What prevents those intermediate services from disclosing information about other services, in particular the entry point service? While nothing more is learned about each service on its own than through its inferface, a sufficiently general SOA should allow for services that supply info on other services.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]