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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: Re: [sca-assembly] Fwd: Conversational services



On Jan 6, 2009, at 9:05 AM, David Booz wrote:

As we have them today == "magic" != the kind of shared context approach I'd rather see.

I think of magic as a type of illusion that people don't necessarily understand how it works (otherwise it wouldn't be entertaining). I don't believe conversations fall into that category as most enterprise developers understand the concept of instance routing. As evidence of this, here are a few programming models that require an understanding of instance routing:

1. EJB
2. .NET/WCF
3. JSF Managed Beans
4. Seam
5. Guice
6. Spring
7. Apache Beehive
8. Web Beans
9. JAX-WS

etc.,etc.

Why are conversations "magic" can callbacks or binding.sca not?


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.

Optional compliance is one approach we should consider. However, as Simon points out, this may introduce complexity in some of the other specifications. One other point related to that is the current "tweaks" I proposed greatly simplify callbacks. As I mentioned, I would be open to looking at how we could make conversations an optional compliance point. For these reasons, I think it is worth pursuing this further by continuing to focus on the technical issues. 

Jim 


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

<graycol.gif>Simon Nash ---01/06/2009 10:09:31 AM---Just one comment on this long and very interesting thread (other text removed for readability).

<ecblank.gif>
From:
<ecblank.gif>
Simon Nash <oasis@cjnash.com>
<ecblank.gif>
To:
<ecblank.gif>
sca-assembly@lists.oasis-open.org
<ecblank.gif>
Date:
<ecblank.gif>
01/06/2009 10:09 AM
<ecblank.gif>
Subject:
<ecblank.gif>
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 






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