FWIW I'm done editing for now - got the basic skeleton there.
--
Jeremy
On Oct 20, 2006, at 12:04 PM, Jeremy Boynes wrote:
Working on it :-) What's on the wiki atm is a work in progress - I
started with the declaration side and am just starting into the
configuration side. Input welcome.
Re the policy thing, it came from looking at the Common Annotation
attributes where they have authenticationType (which is really
about security policy) but don't mention things like whether the
resource is transactional or not (and if it can handle global tx or
just local ones). That seemed to have a direct correspondence to
policies that would apply when calling other local services so I
punted on the hope that we could reuse that rather than duplicate
it here.
--
Jeremy
On Oct 20, 2006, at 11:45 AM, Ken Tam wrote:
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]
---------------------------------------------------------------------
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]
