OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Spam: Re: [ws-caf] policy ai


Green, Alastair J. wrote:

>Hi Greg,
>
>Seems to me that the statement "will accept a context" (Supports) has to
>relate to an operation on an endpoint. That fact needs to be
>communicated somehow -- either by a static declaration or other form of
>shared configuration, or by a dynamic endpoint location mechanism that
>precedes operation invocation. The ability to state or express the
>policy is insufficient without the communication of the policy. 
>  
>
Ultimately it has to be enforced for an operation, but associating it 
to, say, a port would be the equivalent of saying "all operations on 
this port".

How the policy is expressed and communicated in practice is really an 
detail of the deployment: could be bound to uddi,  via a policy document 
obtained through a metadata exchange handshake, or directly embedded in 
the WSDL.

At this point, the status of WS-Policy and associated specs is a 
blocking factor for just about every TC/wg/whatever, not just this one. 
I suggest we follow the WS-RX TC model and move forward with the 
assumption that those specs or some alternative will find their way to a 
standards body in the near future, though I realize this is a highly 
imperfect model.

>This is probably a question of ignorance on my part about what's out
>there in terms of other standardization efforts, so apologies for lack
>of omniscience ;-), but how do you see that part of the problem being
>accomplished in practice for an app endpoint? We went round this from
>various angles in BTP 1.1 and came up with the view, if I recall
>correctly, that there were no mature general approaches to this problem.
>That may have been wrong, or it may have been outdated by continuing
>work elsewhere.
>
>Thanks,
>
>Alastair
>
>-----Original Message-----
>From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
>Sent: 26 July 2005 19:03
>To: Green, Alastair J.
>Cc: Mark Little; ws-caf
>Subject: Re: Spam: Re: [ws-caf] policy ai
>
>
>Green, Alastair J. wrote:
>
>  
>
>>I took the phrase "reasoning about the relationships" to be of wider
>>significance -- similar language has been used in your and Greg's
>>discourse on the (alleged) need to know what the endpoints are up to,
>>and thence to the idea of an ACID-only protocol, which I think is a
>>rather stunted beast. 
>>
>>The fact that the declarative use of the transaction context on receipt
>>by a bean is a private matter is one example of the ability to be
>>largely ignorant of what transactions means to the interlocutor, but
>>still be able to make use of them.
>>
>>On the narrow point, it seems that any way of marking an endpoint as
>>being capable of receiving a context is better than none. 
>>
>>In that respect I think that fixing on something that actually works is
>>better than trying to second-guess the next three twists and turns on
>>the secondary roads running through WS-Land. 
>>
>>Is there a way of doing this which will work with current WSDL and not
>>just 2.0?
>>
>> 
>>
>>    
>>
>I'm not sure why this needs to be related to any version of WSDL per se:
>
>we will need to bind to some policy language; I presume that at some 
>point that will be based on WS-Policy.
>
>Apologies for brevity on these threads, I'm on travel.
>
>Greg
>
>  
>
>>Alastair
>>
>>Alastair J. Green
>>CEO and CTO
>>Choreology Ltd
>>68 Lombard Street
>>London EC3V 9LJ
>>www.choreology.com
>>
>>+44 870 739 0050
>>+44 870 739 0051 (fax)
>>+44 795 841 2107 (mobile)
>>
>>
>>-----Original Message-----
>>From: Mark Little [mailto:mark.little@arjuna.com] 
>>Sent: 26 July 2005 15:31
>>To: Green, Alastair J.
>>Cc: Greg Pavlik; ws-caf
>>Subject: Spam: Re: [ws-caf] policy ai
>>
>>
>>
>>Green, Alastair J. wrote:
>>
>> 
>>
>>    
>>
>>>AJG: This is, I think, a slight overstatement :-). You can reason, but
>>>only within limits -- and without requiring omniscience. 
>>>
>>>[stuff deleted]
>>>
>>>   
>>>
>>>      
>>>
>>I think Greg's point was more that a user of an EJB cannot tell what
>>    
>>
>the
>  
>
>>transactional requirements are for the EJB. There's no equivalent of 
>>CosTransactions::TransactionalObject and because IIOP is not mandated, 
>>there's no way of delving within the object's IOR at the client side.
>>
>>Mark.
>>
>> 
>>
>>    
>>
>
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]