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: [ws-caf] acid policy assertions proposal


This seems reasonable. What did you have in mind for the extensibility 
elements?

Mark.

 

Greg Pavlik wrote:

> Policy Assertions
>
>
> Web services endpoints that support the ACID transaction protocol may 
> wish to advertise policies indicating their capabilities and 
> requirements. This specification defines an assertion indicating that 
> the ACID protocol must be used in communication with the service with 
> which the policy is associated.
>
> The ACID policy assertion is defined by the following schema, which is 
> defined for the target namespace of the acid protocol:
>
> <xsd:element name=”TXAssertion”>
>
> <xsd:complexType>
>
> <xsd:sequence>
>
> <xsd:any namespace=”##other” processContents=”lax” minOccurs=”0” 
> maxOccurs=”unbounded”/>
>
> </xsd:sequence>
>
> <xsd:attribute name=”optional” type=”xsd:boolean” use=”optional” />
>
> <xsd:anyAttribute namespace=”##other” processContents=”lax”/>
>
> </xsd:complexType>
>
> </xsd:element>
>
> The assertion mandates that an acid:Context MUST be present as a SOAP 
> header on a message sent to the service advertising the policy. A 
> value of true for the optional attribute modifies the assertion 
> semantic to indicate that an acid:Context MAY be included as a SOAP 
> header when submitted as a request. A value of false indicates that an 
> acid:Context must be included as a SOAP header on a message sent to 
> the service; it is semantically equivalent to the assertion without an 
> optional attribute.
>
>
> A service that advertises an acid:TXAssertion guarantees to process 
> the SOAP header in an implementation specific way. It does not 
> guarantee to perform all work performed in the context of the 
> application invocation in an ACID transaction. For example, a service 
> may be implemented as an EJB or COM+ component that suspends all 
> transactions related to the operation of the implementation. In this 
> case, the semantics of the Web services interchange are obeyed: the 
> header must be processed, but the service does not perform 
> transactional work.
>
> An example of a policy assertion specifying that an acid:Context MUST 
> be present on any incoming SOAP requests follows:
>
> <acid:TXAssertion/>
>
> or
>
> <acid:TXAssertion optional=”false”/>
>
> An example of a policy assertion specifying that an acid:Context MAY 
> be present on any incoming SOAP requests follows:
>
> <acid:TXAssertion optional=”true”/>
>
> Services can communicate policies in an implementation specific 
> manner. The semantics of a service that does not advertise an ACID 
> policy assertion are undefined.
>
>


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