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] Issue - 66 - Zero or multiple matches of correlation set


>     * Privacy "over the wire" due to the sensitive nature of the
>       contents of the message.
>     * Tamper-proofness for certain messages due to trust issues.
>     * Non-repudiation of receipt.
>     * Authorization of the requestor (i.e., purchasing agent or similar
>       authority).

these are all things that, if they had to be, could be implemented currently
by a BPEL script, or the services which it <invoke>s.  dealing with an out
of order message is not, since it will never arrive at a BPEL process.

danny

----- Original Message ----- 
From: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>
To: "Satish Thatte" <satisht@microsoft.com>
Cc: <wsbpel@lists.oasis-open.org>
Sent: Wednesday, September 24, 2003 11:49 AM
Subject: Re: [wsbpel] Issue - 66 - Zero or multiple matches of correlation
set


> Satish Thatte wrote:
>
> >As for the RosettaNet example, I agree that there are cases where
> >additional policies regarding unexpected messages may apply when the
> >message is properly authenticated and validated.  There are also
> >policies that have to do with SLAs and signatures/non-repudiation, etc.
> >I believe these policies should not be expressed within BPEL.
> >
>
> I may be guilty of revisiting ground we have already covered, but I
> would like to point out that there are very good business reasons that a
> business process should specify some requirements that will affect
> messaging QoS features. For business reasons I may require:
>
>     * Privacy "over the wire" due to the sensitive nature of the
>       contents of the message.
>     * Tamper-proofness for certain messages due to trust issues.
>     * Non-repudiation of receipt.
>     * Authorization of the requestor (i.e., purchasing agent or similar
>       authority).
>
> These are all things that the business analyst may require, yet our
> business modelling language has no place for them. They are not complete
> expressions of policies, but a set of requirements / restrictions needed
> when such policies are implemented.
>
> It has been suggested elsewhere on this list that the use CPP/A could
> address this issue, but this fails to capture the business-level
> requirements in the process model itself. Shouldn't our business process
> modelling language have some business-oriented features? Features that
> could guide (but not fully define) the QoS supplied by the messaging and
> security infrastructure?
>
> -Ron
>



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