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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: Re: [wsbpel] Q: guidelines for reliability?


Martin Chapman wrote:
Message
Couple of points on this.
 
1. Neither Reliability specs are standards at the moment. One is proprietary technology and the other (WS-Reliability) is going through the standards
    process in a sister OASIS group (WS-RM TC).
 
2. While I agree the actual mechanism should not be baked into a spec, unless the chosen approach is communicated somehow there will be zero chance of interoperability.
    It seems that some QOS info should be conveyed, but whether this is in a BPEL document or in an underlying WSDL document is not clear.
This is a general problem regardless. We have to wait until deployment time to ensure that compatible bindings are selected..

Your suggestion about QoS data is interesting. Should BPEL messaging activities be able to include some general QoS information (for instance, that an encrypted transport be used for sensitive transactions). Such things are arguably part of the business process, as opposed to deployment descriptor. "Abstract" QoS requirements from the process would help the deployer to select the right bindings to achieve the QoS desired by the business process designer without necessarily getting into messy technical details.  Something like:
<receive partnerLink = "buyer"
         portType    = "lns:PaymentPT"
         operation   = "acceptPayment"
         variable    = "PaymentInformation"
         portOptions = "secureTransport serverAuthenticate" />
where portOptions is an optional attribute containing a list of  QoS related tokens that are suitably abstract.
  • secureTransport.  The message is encrypted on the wire
  • serverAuthenticate. The BPEL engine must authenticate itself (SSL/TLS)
  • bothAuthenticate.
  • reliable. Once-and-only-once delivery.
  • ...
These could be used by the deployer when selecting or creating the appropriate bindings for the abstract operation "acceptPayment".

This still wouldn't help the interoperability problem -- two deployers for two different engines that must interoperate must "exchange notes" to assure compatible bindings are chosen. This starts to become a very CPA-like exercise.

-Ron


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