Quick question -- is there a proposal in the works for how to represent such resources in the SCDL or component type? The main motivation for this question comes from the following in the wiki:
"Access to resources is subject to Policy constraints in the same manner as access to other local services" My reading of this suggests that resources can have policy constraints applied to them in a manner similar to the way such constraints are applied to service and reference elements, which would imply that some kind of mapping to SCDL would be appropriate. Does that seem right to others? On 10/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
There was some discussion about this on the Java spec call today and I have agreed to write up a proposal for how this can work. I plan to start this on our wiki - if anyone is interested please jump in. http://wiki.apache.org/ws/Tuscany/SpecProposals/Resources -- Jeremy On Oct 9, 2006, at 5:19 AM, scabooz wrote: > Hi guys, > > Special attention for Jim toward the end of this. > > There have been some branches in this email thread. > Apologies if I don't inject at the right point in the chain, but > much of the discussion is not related to the point I want to > make. I need to react to something that's been discussed > along the way. > > The notion that a property somehow represents a contract > between the implementation and the container is quite a > stretch IMHO. The real purpose of a property is to > configure a business service so that the component > behaves as the business would expect. I can see your > perspective when viewed from the aspect of someone > developing the runtime. It is certainly true that the container > has responsibility for creating properties, BUT it has the exact > same responsibility for injecting business services onto > references. So, the argument you're making for using properties > to hold references to system services holds on water. > > However, I do have sympathy with the idea that there are > built-in services which SCA business component > implementations can use. These built-in services live in > a kind of "no man's land" right now. On one hand > we have properties (which are defined by the both the > Java spec spec and the assembly spec as described by XML > schema) that are used to provide parameterization of business > logic and we have business services that are assembled into > compositions of SOA services. I agree with Jim that we > should maintain a clear separation of purpose between > property and reference. After thinking on this for a while, > I've decided that the spec has correctly defined the property > concept, therefore the use of property to hold references > to "system services" is inappropriate and actually > violates the spec. This comes across more harshly than > I am intending. Jim, I think you need to raise this issue > in the spec group, if you really think that properties > should have the semantics you want. Despite the > current lack of compliance language in the specs, I think > it's still very clear where the boundaries of properties are. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
