Re: [sca-assembly] Fwd: Conversational services

[Simon Nash <oasis@cjnash.com>]

David Booz wrote:
> As we have them today == "magic" != the kind of shared context approach 
> I'd rather see. And that unfortunately we don't have enough time left to 
> standardize so I'd rather have nothing in the spec and have a go at a 
> proper model during the next version of SCA. I was not differentiating 
> between specs, I was speaking in general because I see the problem as 
> larger and more abstract than a specific tweak here or there in a 
> technical proposal. We don't have to standardize everything we want in 
> the first go, but what we do standardize had better be bedrock/core and 
> solid. It's easier to add to a standard than to have to change it. It's 
> better to standardize in small bits. The fact that standards take time 
> is good thing, not a bad thing.
> 
> The compliance point is that an SCA runtime MAY support the 
> conversational intent, the endsConversation marker, 
> conversationViolation fault, and whatever other tweaks we make to the 
> current "magic" in the model. I don't see what testability has to do 
> with it. We aren't going to test everything that's a MUST let alone the 
> MAYs.
> 
OK, for "testable" please read "well specified".

If different vendor implmentations "support" these assembly-level
artifacts, but attach completely different semantics to them, I
don't that's very useful.  I think of an optional compliance point
as something that's well-specified and implementable, but doesn't
need to be supported by every implementation.  Therefore, I would
expect that different implementations that claim support for some
optional compliance point would use the same meaning and semantics
for it.  If not, I don't see any value of having this feature be
part of the SCA specs.  It should just be a vendor extension.

   Simon

> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Inactive hide details for Simon Nash ---01/06/2009 10:09:31 AM---Just 
> one comment on this long and very interesting thread (othSimon Nash 
> ---01/06/2009 10:09:31 AM---Just one comment on this long and very 
> interesting thread (other text removed for readability).
> 
> 
> From:	
> Simon Nash <oasis@cjnash.com>
> 
> To:	
> sca-assembly@lists.oasis-open.org
> 
> Date:	
> 01/06/2009 10:09 AM
> 
> Subject:	
> Re: [sca-assembly] Fwd: Conversational services
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Just one comment on this long and very interesting thread
> (other text removed for readability).
> 
>   Simon
> 
> David Booz wrote:
>  > Thanks for the reply.
>  >
>  > See inline *<dab> </dab>*
>  >
>  > Dave Booz
>  > STSM, BPM and SCA Architecture
>  > Co-Chair OASIS SCA-Policy TC and SCA-J TC
>  > "Distributed objects first, then world hunger"
>  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>  > e-mail:booz@us.ibm.com
>  >
>  > Inactive hide details for Jim Marino ---12/23/2008 01:24:11 PM---Thanks
>  > Dave. I'll try to comment inline inline.Jim Marino ---12/23/2008
>  > 01:24:11 PM---Thanks Dave. I'll try to comment inline inline.
>  >
>  >
>  > From:
>  > Jim Marino <jim.marino@gmail.com>
>  >
>  > To:
>  > OASIS Assembly <sca-assembly@lists.oasis-open.org>
>  >
>  > Date:
>  > 12/23/2008 01:24 PM
>  >
>  > Subject:
>  > Re: [sca-assembly] Fwd: Conversational services
>  >
> (cut)
>  >
>  >              >> Another way I have seen conversations propagated is how
>  >             Microsoft Durable Services work using service-provider
>  >             tokens. In this model, they have decoupled the
>  >             conversational model from how correlation is transmitted (in
>  >             SOAP headers via WsHttpContextBinding, or using cookies via
>  >             BasicContextBinding). With this approach, one issue is that
>  >             the SCA infrastructure will have to wait for a back channel
>  >             message containing the token before a second invocation is
>  >             delivered.
>  >             Two problems here. 1) This is a new protocol, that is not
>  >             standardized, and 2) you will have to define how this works
>  >             for each binding spec.
>  >
>  > Aren't we already doing this for callbacks?
>  > *<dab> We don't do protocols in SCA. We aren't standardizing the
>  > callback over WS semantic.We have an example of one way that a stateless
>  > callback could be done over WS. There is no requirement that any vendors
>  > do it this way. </dab>*
>  > *<dab> If you're suggesting that conversations as we have them today
>  > could be an optional compliance point then I would probably agree to
>  > that.... </dab>*
>  >
> If you mean "as we have them today in all the SCA specs", I would
> be very concerned about this because of the complexity it would add
> (e.g., in the SCA Java spec).  If you mean "as we have them today
> in the assembly spec", the complexity isssue is less significant,
> but what would the compliance point be?  The assembly spec defines
> some syntax for indicating that services are conversational, but it
> doesn't define any testable semantics for conversational services.
> 
>   Simon
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
>